Os mitos de software so falsas verdades que existem no mundo da indstria de software.

Tanto jovens engenheiros quanto pessoas mais experientes tendem a acreditar neles, distorcendo
a verdadeira face do processo de engenharia.

Os mais comuns so:

Um bom manual, repleto de padres e regras, fornecer a equipe tudo que ela
precisa saber
Desenvolvimento no uma receita de bolo! Os clientes so diferentes, os projetos so diferentes,
os programadores so diferentes, as prioridades dependem do projeto. Basicamente, TUDO diferente. No
pense que um site de ecommerce que voc desenvolveu para a empresa X valer para a empresa Y, e viceversa. O planejamento fundamental e s ento voc poder levantar os requisitos necessrios e trabalhar em
cima de um novo projeto.

Caso ocorra atraso no cronograma este poder ser contornado alocando-se mais
programadores ao projeto.
Por mais que exista o conceito de Fbrica de Software no podemos pensar no processo de desenvolvimento
como uma linha de produo. Ao se inserir um programador em um projeto, ele levar algum tempo para se
familiarizar com o cdigo e com o que est sendo feito, para ento, comear de fato a produzir. Outro grande
pecado que muitos gestores comentem tratar o programador como pedreiro, como um peo. Se o o
desenvolvedor no entende nada do processo da empresa para o qual est desenvolvendo, tenha certeza que
no poder contribuir da melhor maneira possvel. Mais um vez, quero frisar: Desenvolvimento no linha
de produo. Alocar programadores para resolver um problema de cronograma poder surgir efeito contrrio,
causando mais problemas!

Terceirizar um projeto garantia de tranquilidade e nenhum trabalho.

Quando um projeto muito trabalhoso, requer know-how maior do que a sua equipe possui ou o cronograma
est apertado, muitos optam pela terceirizao achando que esta uma garantia de tranquilidade e nenhum
trabalho. Contudo, tome cuidado: Se a empresa X contratou voc, voc o responsvel pelo trabalho que est
entregando. Ou seja, qualquer problema ser um problema seu tambm! A maioria das empresas terceiriza o
servio, mas ao comprar o cdigo, fica responsvel por suas manutenes. A fica a pergunta: A terceirizao
fez o servio direito? Comentou o cdigo? Documentou o que foi feito? Sua equipe tem pessoal para trabalhar

nesse cdigo? Pense bem antes de terceirizar algo que no poder trabalhar bem no futuro. melhor recusar
um projeto do que faze-lo mal feito.

Um software pode ser construdo observando-se o seu propsito geral os

detalhes podem ser levados em conta posteriormente.
Se voc desenvolvedor j deve ter se deparado com um usurio que s queria um ajustizinho no sistema: s
adicione um boto que faa isso e busque aquilo e faa isso ficar cor de rosa e brilhar girando. Sim, essas
coisas acontecem! Ao se pensar em um software deve-se mapear o mximo possvel de suas funcionalidades a
serem desempenhadas. claro que em um primeiro momento difcil pensar em tudo, alguma coisa ou outra
vai entrar como correo. Mas pensar em algo bsico demais e querer enfeita-lo demais depois, envolve mais
tempo e o pior: retrabalho! Desenvolvedores geralmente no gostam de destruir algo para faze-lo de outra
forma, pois o cliente mudou de ideia. Alis, ningum gosta. Como eu disse, existem excees, mas se voc no
entende de desenvolvimento e s gerencia o processo, no pense que os seus detalhes so realmente detalhes
quando viram linhas de cdigo!

Mesmo que os requisitos de um software mudem, as alteraes so realizadas

facilmente pois temos uma boa equipe que sabe como fazer o servio muito bem.
Mais uma vez, se voc no desenvolver e no entende do processo, no julgue uma atualizao como
simples. Somente um programador poder avaliar o quo simples uma alterao e muitas vezes, ela s vai
realmente ter a ideia depois que estiver trabalhando com o cdigo. Mesmo que voc tenha uma boa equipe,
modificaes devem ser analisadas, discutidas com relao a sua viabilidade e testadas. Lembre-se sempre:
alocar um programador requer algum tempo para que esse se familiarize com o que vem sendo feito. As coisas
no so to simples.

Se
o
programa
funciona,
nosso
trabalho
est
completo.
Se o programa ainda no est finalizado e rodando, no posso avaliar sua
qualidade.
Esses dois tpicos so assutadoramente passados adiante e voc j deve ter ouvido isso de algum. Se um
programa roda isso no garante que o seu trabalho est feito. Todo o processo de desenvolvimento deve buscar
a qualidade e apenas funcionar no lhe garante isso ou seja, o processo da avaliao de qualidade no se
limita a essa etapa. O seu cdigo bem comentado? Est bem feito? Otimizado? A tecnologia utilizada
adequada? Os banco de dados esto otimizados? Sua relaes foram criadas corretamente? A infraestrutura do
cliente suporta o que est sendo desenvolvido? Se o seu sistema foi feito para suportar vrios acessos, ele
realmente suporta isso? Um programa mais do que o executvel. Voc vende todo o processo.

O nico produto que entregarei ao cliente o cdigo executvel.

Em alguns casos, o produto palpvel que o cliente recebe somente o executvel. Em outros, trabalha-se
com o cdigo fonte e com a documentao. Contudo, independente do caso, lembre que, como foi dito no item
anterior: Um programa mais do que o executvel. Voc vende todo o processo de desenvolvimento. Por isso,
deve-se pensar e faze-lo com perfeio.

O processo de planejamento far com que criemos documentao volumosa que

atrasar a execuo do projeto, atrasando o cronograma.
Planejamento fundamental! Muitas pessoas aindam confundem planejamento com papelada e estas esto
terrivelmente enganadas! Mesmo trabalhando-se em um time Agile, planejar fundamental! A documentao
do projeto ser trabalhada na melhor metodologia adotada mas um plano do que ser feito dever ser estudado
antes de colocar a mo na massa. Somente com o estudo dos processos e necessidades do cliente voc
conseguir criar um software que trabalhe com excelncia!

http://www.profissionaisti.com.br/2011/08/os-principais-mitos-do-desenvolvimento-de-software/

O que um processo de software?