As Empresas Seguem as Fases do Desenvolvimento de

Software Utilizando-se de Uma Metodologia Adequada

As empresas ganham muito tempo em desenvolver sem ter a documentao.
Em casos que a o sistema j da rea de domnio da empresa, os
programadores so experientes e conhecem o ramo em que vo desenvolver o
tempo ser bem menor do que realizar a documentao antes e depois
programar. Mas, contudo, porm, entretanto (rsrsrs) se precisarem realizar
alguma modificao ou correo e o programador no lembrar ou for um
programador que no participou do desenvolvimento ser mais difcil ele
entender como foi desenvolvido e onde dever ser feita a alterao. Se a
documentao estiver feita ele ir estud-la para depois realizar a alterao
com segurana, sem medo de mexer em um local e "estragar" outro.
Analisar o contexto dessa discusso, sem a elaborao de documentao
alguma a equipe de desenvolvimento do sistema apenas ter o retrabalho de
explicar ou entender o cdigo-fonte pra quem possa dar manutenes futuras.
Mesmo que mnima, necessria alguma maneira de documentar o software.
Algumas metodologias utilizam pouco a documentao, como o caso das
metodologias geis, que adotam o slogan: "Do More, Write Less" onde a nica
maneira de documentar o que est sendo desenvolvido guardando os papis
de solicitao de funcionalidade que o cliente quer que tenha no sistema, mas
concordo com o que o nosso colega postou, um sistema inteiro sem
documentao alguma como uma mercadoria sem nota fiscal.
Quanto a pergunta se mais rpido, a resposta como disse, ser sim, agora se
mais eficaz, a resposta ser no, por esse e outros motivos que j comentei.
Concluindo, pode-se ganhar tempo no desenvolvimento mas poder perder
muito mais tempo na manuteno do sistema.O mais impressionante que
direto so inventadas novas metodologias de desenvolvimento de software e
as empresas continuam errando em seus projetos. Desenvolver sem
documentao algo que cada dia que passa est mais difcil. semelhante
venda de mercadorias sem nota fiscal.
Um das dificuldades a deteco de problemas oriundos do desenvolvimento
do software sem a sua documentao completa.Ao meu modo de ver, acho
que a principal dificuldade justamente a concordncia entre os diagramas,
ou seja fazer com que cada diagrama represente de maneira clara o sistema a
ser desenvolvido, embora acredite que se o individuo dominar a tcnica UML,
acho que isto no ser problema. Muitas empresas no seguem nenhum
documentao devido a falta de treinamento de seus funcionrios e a falta de
boas prticas. O mximo que muitas fazem um diagrama dizendo quais so
as telas do sistema. O desenvolvimento da documentao um processo
demorado, onde muitos acabam deixando de lado para iniciar a programao
do sistema.
Outra viso das empresas quanto a fazer a documentao usando UML, por
exemplo, que muitas coisas no so implementadas no sistema, devido a
problemas que foram detectados na teoria e na prtica no foi possvel realizar.
Muitos podem dizer que houve uma falha na documentao, mas na verdade o
prprio analista pode no conhece o cenrio que est trabalhando ou at
mesmo os programadores no tem conhecimento suficiente. Essa situao
piora ainda mais em empresas jovens. Muitos dizem que gastar tempo com
documentao consome muitas horas, sendo assim podemos acabar pagando
para trabalhar.
Muitos sistemas so desenvolvidos com o mnimo de documentao, no
mximo uma conversa com o cliente, alguns rabiscos de tela, algumas
referencias, combinado um prazo e logo comea o desenvolvimento.
Quando o projeto est na mo da empresa que desenvolve, tudo est perfeito
e quando o cliente comea a testar ele percebe que algumas telas precisam
ser mudadas e que o sistema est cheio de problemas.
O que mais prevalece nesses casos que o cliente est pagando e o medo de
perder o cliente leva a empresa que desenvolveu o software fazer um monte de
ajustes.
O que dizer disto? O cliente que passou errado ou a empresa que desenvolveu
o software que fez errado? Isso pode gerar uma discusso muito grande devido
que ambos podem alegar que fizeram o combinado.
De acordo com o que tenho visto na prtica, as empresas costumam usar
metodologias de desenvolvimento de software, mas, nunca completamente,
acabam utilizando somente as indispensveis, por ter sempre prazos curtos,
ento acabam pulando algumas etapas e se focalizam nas tcnicas bsicas.
Sem a documentao mais rpido. Eficcia nem se discute, pois acredito que
fazendo rpido a qualidade cai l embaixo. Manutenes no sistema ficam
complicadas a medida que o tempo passa