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

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í...

[quote=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.
...
[/quote]

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

This message was edited 1 time. Last update was at 20/05/2008 17:38:04

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,

This message was edited 2 times. Last update was at 22/05/2008 13:08:55

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

É 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.

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

JavaGuru Membro desde: 31/01/2003 10:21:32 Mensagens: 204 Offline

Marcio Duran wrote: 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.

É 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.

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!

Virtual Machine Man Membro desde: 23/01/2008 11:14:35 Mensagens: 637 Offline

le-silva wrote: Quando vejo suas mensagens nesse "bom" português, sabe do que tenho medo? Do seus códigos!

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

This message was edited 1 time. Last update was at 02/06/2008 15:31:39

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...

*

*

JavaGuru Membro desde: 31/01/2003 10:21:32 Mensagens: 204 Offline

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

Custo fechado + Data fixa + Escopo aberto

Documentação?

Cliente presente, user stories, design simples de código, testes unitários, e um bom wiki resolve boa parte dos casos.

This message was edited 1 time. Last update was at 02/06/2008 15:59:49

Roger-- wrote:

ftrapnell wrote: ...

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 wrote: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.