Documentação no processo de desenvolvimento de software. Precisamos gerar tudo isso?

Acho que isso depende muito das necessidades e do perfil da equipe. Aqui na empresa, temos uma equipe de cerca de 15 desenvolvedores (fora o pessoal da infra-estrutura, de análise e planejamento, etc) e usamos um processo parecido com o RUP. Resultado: se o software for pequeno, passamos mais tempo documentando e gerenciando configuração do que desenvolvendo. Tem ainda a desvantagem de que, se o software muda, tem que mudar a documentação também. Porém, quando precisamos relembrar tudo o que desenvolvemos, basta darmos uma rápida olhada na documentação. Acho que as vantagens de um processo como o RUP só aparecem em projetos grandes com equipes grandes.
Ultimamente tenho lido coisas sobre o XP e tenho achado muito interessante 8) Infelizmente me falta tempo pra estudar mais
Abraços

Tudo isso é um grande ‘depende’.

Em alguns lugares vc precisa disso tudo pq tem burocratas e eles gostam de papel. Quanto mais papel, melhor.

Como ferramenta de análise sim, como documentação não. UML=Linguagem=Comunicação. Como desenvolvimento de software é altamente dependente de comunicação [Cockburn], a UML pode ser importante só por ser uma especificação padronizada. Se você rabiscar coisas que seu cliente e sua equipe entendam já é suficiente.

Alguém saberia me dizer o que é “Especificação Funcional”? Que metodologia defende isso? Não me lembro de nenhuma literatura importante que cite esse nome. Me parece coisinha que algum metodologista tupiniquim “conhecido” inventou.

O código é essencial. A facilidade de manutenção e evolução do sistema é essencial. Um sorriso grande na cara dos Stakeholders também é essencial. Se o que você faz não colabora pra nenhuma dessas coisas ela é dispensável.

Recomendo a leitura do meu artigo na MundoJava deste mês que aborda Modelagem Ágil.

Abraços!

Rodrigo Y.

fabeen:

Fala Galera,

Nos últimos dias, estive lendo o livro Getting Real(Caindo na Real http://gettingreal.37signals.com/GR_por.php) do pessoal da 37Signals (http://www.37signals.com/), onde eles descrevem seu modelo de desenvolvimento de software. Este baseado em simplicidade, com foco em resultados e principalmente em agilidade.

Um dos pontos que me chamou muito a atenção, foi a crítica que o autor faz em torno de “documentos” ou “artefatos” se assim preferir chamar, geradas em processos de desenvolvimento de software como RUP por exemplo.

Diante do assunto gostaria de saber a opinião de vocês :

• UML é realmente importante ?

• Especificações funcionais são realmente funcionais ?

• O que é realmente essencial e por que ?
  

37signals virou é um mito nos EUA. Não porque fez o RoR, mas porque faz dinheiro e tem muitos clientes satisfeitos. Eu acreditaria no que eles falam… Opinião pessoal minha, não é a palavra final no assunto e respeito completamente quem pensa o contráio: [B]UML É INÚTIL[/B].

Quantos livros você já leu que mostram diagramas UML? Muitos né? Imagine se cada autor criasse a sua própria notação (lembra da guerra dos métodos?)

Se saber usar não é inútil não. Um dos maiores desafios em projetos é achar uma Ubiquitous language para que os homens de negócio discutam com os homens técnicos. UML pode ser uma Ubiquitous language, assim como outras alternativas. BPM é uma tendência forte, certo? Muitos conceitos alí sairam da UML. Também vejo bastante a UML como uma boa ferramenta de ensino OO (meu curso UML é muito sobre isso).

saoj, você tem trabalhado em frameworks genéricos a algum tempo certo? Sabe porque na documentação de todos os frameworks open source não existe um só diagrama UML? Sabe porque você não sente necessidade de uma ubitiquos language? Porque quando você discute com usuários a Ubiquitous language é Java, eles são técnicos e não precisam de uma abstração.

Infelizmente analistas financeiros, engenheiros civis, médicos e etc… (caras que lidei nos meus projetos) não sabiam e não tinham interesse de aprender Java, eu precisava de uma Ubiquitous language mais abstrata. As vezes era UML. As vezes era uma planilha excell. As vezes eram rabiscos em papel.

Ok, me excedi um pouco. Como forma de comunicação talvez seja uma boa. O que eu acho meio non-sense é ter que desenvolver um sistema todo em UML para só depois partir para a implementação em si.

Tem razão… Olhei só por um lado e fui radical na minha conclusão.

Eu meio que fui forçado a aprender a gostar de UML. Nenhum projeto aqui (onde trabalho) sai sem a modelagem e alguns diagramas. Não sou nenhuma autoridade no assunto, mas na prática aprendi a gostar porque, além de ficar mais fácil colocar na cabeça o que exatamente o produto deve ser capaz de fazer (detalhar um caso de uso esclarece muito os requisitos), fica mais fácil também decidir com o cliente se o produto final é o que ele quer mesmo.

rodrigoy:

saoj:

[B]UML É INÚTIL[/B].

Se saber usar não é inútil não. Um dos maiores desafios em projetos é achar uma Ubiquitous language para que os homens de negócio discutam com os homens técnicos. UML pode ser uma Ubiquitous language, assim como outras alternativas. BPM é uma tendência forte, certo? Muitos conceitos alí sairam da UML. Também vejo bastante a UML como uma boa ferramenta de ensino OO (meu curso UML é muito sobre isso).

Sinceramente acredito que UML é bem pobre se usada para definir uma Ubiquitous language [1]. Sou muito mais um Wiki onde o pessoal de negócio e os desenvolvedores colaboram para chegar a um consenso do que depender de uma notação pré-definida para isso.

Por outro lado UML é bem rica para demonstrar OO, como você disse.

[1]Ubiquitous language

Existem casos onde UML é extremamente importante, pelo menos na nossa equipe, que é na criação do SGDB
é criado uma UML com os relacionamentos de tabelas etc…
assim facilita em muito o trabalho com ele

s4nchez:

rodrigoy:

saoj:

[B]UML É INÚTIL[/B].

Se saber usar não é inútil não. Um dos maiores desafios em projetos é achar uma Ubiquitous language para que os homens de negócio discutam com os homens técnicos. UML pode ser uma Ubiquitous language, assim como outras alternativas. BPM é uma tendência forte, certo? Muitos conceitos alí sairam da UML. Também vejo bastante a UML como uma boa ferramenta de ensino OO (meu curso UML é muito sobre isso).

Sinceramente acredito que UML é bem pobre se usada para definir uma Ubiquitous language [1]. Sou muito mais um Wiki onde o pessoal de negócio e os desenvolvedores colaboram para chegar a um consenso do que depender de uma notação pré-definida para isso.

Por outro lado UML é bem rica para demonstrar OO, como você disse.

[1]Ubiquitous language

Concordo com você Ivan, acredito para que seja mais fácil o entendimento através de materiais expostos em uma espécie de Wiki ou Blog de um projeto. Acredito que palavras são mais eficientes quando falamos de comunicação. Um exemplo bacana de implementação desse modelo seria a experiência passada pelo “Shoes” http://blog.fragmental.com.br/2007/08/15/introduzindo-agilidade-num-ambiente/.

s4nchez:

rodrigoy:

saoj:

[B]UML É INÚTIL[/B].

Se saber usar não é inútil não. Um dos maiores desafios em projetos é achar uma Ubiquitous language para que os homens de negócio discutam com os homens técnicos. UML pode ser uma Ubiquitous language, assim como outras alternativas. BPM é uma tendência forte, certo? Muitos conceitos alí sairam da UML. Também vejo bastante a UML como uma boa ferramenta de ensino OO (meu curso UML é muito sobre isso).

Sinceramente acredito que UML é bem pobre se usada para definir uma Ubiquitous language [1]. Sou muito mais um Wiki onde o pessoal de negócio e os desenvolvedores colaboram para chegar a um consenso do que depender de uma notação pré-definida para isso.

Por outro lado UML é bem rica para demonstrar OO, como você disse.

[1]Ubiquitous language

Sim, um Wiki pode ser muito bom para gerenciar o conhecimento do projeto, mas a Ubiquitous Language não é o Wiki, mas sim a maneira como você coloca as coisas no Wiki. Meu próximo artigo na MundoJava vai explorar Domain-Driven Design, mas não só os Domain Patterns e sim as práticas.

O problema de você ter um modelo textual é que ele é muito longe da implementação. A UML não é executável, porém, é “implementável” com um mapeamento muito baixo entre a Ubiquitous Language e o código. Apesar de nem todos homens de negócio se sentirem confortáveis com a UML [Nilsson], quando posso utilizá-la sinto que é uma boa opção.

DSLs como BPMN e até JPDL podem ser outras boas opções, principalmente porque são executáveis.

Não se você usar algo como FitNesse

Faz tempo que quero dizer (ou perguntar sobre isso):

Essa documentação gigante não poderia servir como um contrato entre você e o cliente?
Se ele assinar não tem porque reclamar que alguma coisa não era o que ele queria.

Sei lá hein… nunca trabalhei com isso

dedejava:

Faz tempo que quero dizer (ou perguntar sobre isso):

Essa documentação gigante não poderia servir como um contrato entre você e o cliente?
Se ele assinar não tem porque reclamar que alguma coisa não era o que ele queria.

Sei lá hein… nunca trabalhei com isso :(

Não só pode como é isso que muita gente visa quando o escopo é definido em contrato.

Ao meu ver isso ao invés de proteger as partes, apenas as limita. Se você se prender ao que foi assinado você provavelmente perderá muitas oportunidades de melhorar o software à medida que ele for evoluindo. E neste caso ambas as partes sairão perdendo: o cliente acaba com funcionalidades inúteis e a equipe de desenvolvimento frustada com o que produziu.

Por isso que acredito em contratos de escopo flexível, onde o cliente é obrigado a dar seu feedback para guiar o desenvolvimento.

De qualquer modo essa é uma decisão de negócios, onde na maioria dos casos a opinião do desenvolvedor influencia muito pouco…

Você tem razão cara.
O “desenvolvedor” desenvolveu o que tá no contrato (nesse caso a documentação), mas vai saber se é o que o cliente quis.

Esse texto que o criador do tópico mostra é muito legal… depois de ler ele que perdi um pouco da mentalidade do que aprendi de Engenharia na faculdade… totalmente mais prazeroso.

Galera,

Ao meu ver, realmente acho que temos que partir para soluções mais ágeis, mesmo porque o tempo é escasso na maioria dos projetos. Porém ainda sou contra eliminar toda a documentação, muitas vezes, em um projeto, e mesmo depois da entrega aparecem discussões sobre as funcionalidades que um produto deveria contemplar ou não… Ou mesmo quando se necessita realizar um retrabalho para correção, ou implementação de novas funcionalidades, ou até mesmo numa migração do sistema para uma outra plataforma. Nessas ocasiões, poder abrir uma documentação clara, organizada e atualizada é o melhor dos mundos. Ou seja, é aquela velha história, melhor gastar mais tempo no desenvolvimento e ser mais ágil na solução de problemas futuros durante uma correção de erros, problemas ou situações mais críticas com o cliente.

A seguinte situação sempre acaba ocorrendo, você se depara com uma solicitação do cliente, dizendo que uma funcionalidade deveria estar contemplada em um produto que já foi entregue, testado, e em produção, porém a funcionalidade não existe. O cara que desenvolveu o produto não está mais na empresa, o cara que trabalhou junto ao cliente pegando os requisitos está em outro projeto e não pode (nem quer) te ajudar, você só tem a documentação do projeto a recorrer, uma especificação qualquer daquele produto, por mais simples que seja (UML, texto, Wiki, papel de pão), se estiver completa e atualizada te salva a pele e te dá uma agilidade maior para atender ou negar o pedido do cliente.

Trabalhei em poucos projetos organizados com um processo de desenvolvimento, mais com certeza a qualidade é diferenciada. Porém a maioria dos projetos é no heroísmo… cada um faz o seu, o mais rápido possível, mesmo que esteja dando pau, pelo menos entregue algo, tudo mascarado com planilhas e gantts mostrando um “falso controle”… zero de documentação de especificação ou escopo, e quando der pau, reze para não cair na sua mão… Acho uma abordagem horrível mais é o que mais se faz por aí…

ftrapnell:

…

Ao meu ver, realmente acho que temos que partir para soluções mais ágeis, mesmo porque o tempo é escasso na maioria dos projetos. Porém ainda sou contra eliminar toda a documentação, muitas vezes, em um projeto, e mesmo depois da entrega aparecem discussões sobre as funcionalidades que um produto deveria contemplar ou não… Ou mesmo quando se necessita realizar um retrabalho para correção, ou implementação de novas funcionalidades, ou até mesmo numa migração do sistema para uma outra plataforma. Nessas ocasiões, poder abrir uma documentação clara, organizada e atualizada é o melhor dos mundos. Ou seja, é aquela velha história, melhor gastar mais tempo no desenvolvimento e ser mais ágil na solução de problemas futuros durante uma correção de erros, problemas ou situações mais críticas com o cliente.
…

Acho que no caso citado, não existe melhor documentação do que testes. Os testes não deixam de ser documentos que contemplam as funcionalidades disponiveis do sistema e melhor ainda, provam que estão funcionando (ou não). Pra mim uma tradução direta de ter uma “documentação clara, organizada e atualizada” e ter os testes organizados e “cobrindo” toda a aplicação.

Roger Leite

Engraçado como tudo gira em torno da comunicação.

Nosso principal desafio em todos os projetos é saber comunicar-se dentro do próprio time, com os clientes, domain experts, product owner, etc. Um subset da UML junto a um whiteboard já seria eficaz para uma discussão sobre o sistema, não necessariamente precisa ter todos os mínimos detalhes da UML (linha tracejada ou nao, triangulo preenchido ou nao, etc). Só que o sucesso disso está em todos falarem a mesma língua (ubiquitous language). DDD e BDD estão aí justamente pra atacar esses pontos.

O que sempre pega é o DoD (Definition of Done), o que faz muito necessário testes no estilo BDD, testando o comportamento da aplicação, de fácil visualização inclusive por quem não é técnico.

Saber UML é obrigatório para que você entenda pelo menos as publicações aí fora. Mas não acredito que seja obrigatório gerar todos artefatos do mundo para um projeto, temos apenas que gerar o mínimo necessário (documentar regras de negócio, o DoD, disponibilizar os testes de aceitação e, se possível, fazer o cliente escrever os testes de aceitação).

Abraços,

:idea: Não é a UML que é Inútil.Mas Inútil é transformar, a liguagem de Programação, em Idioma de Programação.

:arrow: É por isso que quando você embarca em projetos, as pessoas não tem um sincronismo melhor no projeto porque cada um entende sua aplicação ao seu modo, ai vem as loucuras de FrameWorks não-funcionais, descabidos em uma espécie de vendas a toda proa.

:arrow: E concordo, UML não é documentação mesmo.

Marcio Duran:

:idea: Não é a UML que é Inútil.Mas Inútil é transformar o liguagem de Programação em Idioma de Programação, bem ai sim para que vou querer UML, se já posso conversar com as minhas aplicações por igual.

:arrow: É por isso que quando você embarca em projetos as pessoas não tem um sincronismo melhor no projeto porque cada um entende aplicação ao seu modo, e ai nasce esses loucuras de FrameWorks não-funcionais, descabidos por ai, vendendo a torto e a rodo em uma espécie de vendas a toda proa.

:arrow: E concordo, UML não é documentação mesmo, mas é sim o que se tem de mais precioso no contexto do Projeto.

Quando vejo suas mensagens nesse “bom” português, sabe do que tenho medo? Do seus códigos!

:idea: Código ? Será que lhe entendi ? - Você deve ser Analista de Sistemas Digitador, acertei ?

Baseado em conhecimentos acadêmicos, e algumas horas em projetos, eu diria que quanto melhor especificado o projeto estiver, melhor.
Melhor para quem vai gerenciar (gerente de projeto poderá recusar uma mudança no escopo evitando apertar o tempo de entrega ou o custo do projeto), melhor para o cliente (que tem especificado tudo aquilo que ele necessita, com a ajuda de bons analistas de negócios e de muita conversa com quem mete a mão na massa, literalmente) e melhor para quem vai desenvolver, pois não terá que refazer, alterar, quebrar a cabeça com algo que não valerá a pena.

Agora, o que usar para melhor especificar, aí vai de casa empresa. A maioria pouco faz…

• :!:*

Hammm… depois de mais de 10 anos desenvolvendo software, sinto lhe dizer que você está errado!

Documentação?

Roger–:

ftrapnell:

…

Ao meu ver, realmente acho que temos que partir para soluções mais ágeis, mesmo porque o tempo é escasso na maioria dos projetos. Porém ainda sou contra eliminar toda a documentação, muitas vezes, em um projeto, e mesmo depois da entrega aparecem discussões sobre as funcionalidades que um produto deveria contemplar ou não… Ou mesmo quando se necessita realizar um retrabalho para correção, ou implementação de novas funcionalidades, ou até mesmo numa migração do sistema para uma outra plataforma. Nessas ocasiões, poder abrir uma documentação clara, organizada e atualizada é o melhor dos mundos.
…

Acho que no caso citado, não existe melhor documentação do que testes.

Testes ajudam a testar (passo a redundancia) se as alterações não quebraram o sistema, mas os testes não o ajudam a saber como a aplicação funciona. Para que vc altera a aplicação vc tem que entender como ela funciona. Como ela for organizada, qual é a arquitetura, qual é a filosofia de desenvolvimento, o design ,etc… Sem uma documentação que fala sobre isto, a alteração é muito mais dificil e às vezes impossivel. Acho que era isso que o ftrapnell se referia. Documentação para que terceiros entendam o
sistema. Estes terceiros não são o owner nem os desenvolvedores que trabalharam no projeto.

xGambit:

Baseado em conhecimentos acadêmicos, e algumas horas em projetos, eu diria que quanto melhor especificado o projeto estiver, melhor.
Melhor para quem vai gerenciar (gerente de projeto poderá recusar uma mudança no escopo evitando apertar o tempo de entrega ou o custo do projeto), melhor para o cliente (que tem especificado tudo aquilo que ele necessita, com a ajuda de bons analistas de negócios e de muita conversa com quem mete a mão na massa, literalmente) e melhor para quem vai desenvolver, pois não terá que refazer, alterar, quebrar a cabeça com algo que não valerá a pena.

Agora, o que usar para melhor especificar, aí vai de casa empresa. A maioria pouco faz…

Exatamente, porém é bom adicionar que especificação pode ser feita por testes, e geralmente esta é uma ótima técnica. Testes funcionais verificam se os requisitos são obedecidos, testes de integração veriicam a arquitetura e testes unitários dizem como as classes se comportam.

Yoshi, eu sempre me senti mais à vontade com as Especificações Técnicas, onde as funcionalidades do módulo são descritas passo a passo, com a imagem da modelagem (bem normalizada, é claro), com as ações de cada botão (seus respectivos eventos e fluxos alternativos), etc.
Pode ser muito imbecil de minha parte, mas até hoje não consegui entender os diagramas de sequencia, justamente devido à uma falta de padronização (cada um escreve de uma forma, e ninguém entende nada). Também muito estranhamente, até hoje não conheci alguém que use UML total na prática.

Qual seria a melhor forma de explicitar tecnicamente, para o programador, o que ele exatamente deve desenvolver, quais tabelas deverão ser populadas, como cada componente deverá se comportar, etc ?