gerenciamento de projetos - Qual é a finalidade dos passos da sequência de desenvolvimento de software? - Stack Overflow em Português
Estava lendo as respostas da pergunta Quando usar Waterfall e quando usar Scrum? e me deparei com algo citado pelo usuário utluiz que me deixou com dúvida, que é a sequência de desenvolvimento de software:
Eu gostaria de uma explicação a respeito de cada passo desta sequência e qual é a finalidade de cada um dos passos?
Requisito: Nessa etapa a equipe de desenvolvimento tem o primeiro contato com o problema e o cenário. Resumidamente os stakeholders contam qual é o problema ou objetivo do projeto. Nesse momento é feita uma documentação (preliminar).
Análise: Após feito um estudo sobre o problema a equipe de desenvolvimento elabora uma solução isso vai desde a criação de um processo ou implantação de equipamentos. Uma documentação é escrita descrevendo como será resolvido o problema. O texto deve ser claro tanto para o desenvolvimento quanto pelo stackholders isso é uma conferência de que todos entenderam corretamente o problema e regras de negócios.
Design: Baseado nos documentos gerados na análise é possível definir quais tecnologias serão usadas, qual arquitetura, qual o tipo de software (web, desktop, mobile, embarcado etc). Essa escolha pode sofrer interferência do ambiente do cliente que restringe o leque de possibilidades.
Implementação: Aqui sim começa a codificação, as regras de negócio são adaptadas para a linguagem de máquina.
Testes: Existem vários tipos de testes (unidade, integração etc) aqui são feitos os de aceitação que basicamente verifica se o software se comporta conforme a documentação.
Integração: Depois terminado e empacotado o software ele é colocado no ambiente de produção do cliente, nessa etapa configurações, migrações de banco e outras tipos de tarefas são executadas. Também existe o problema de parte (ou todo) do software não funcionar no cliente devido aos teste feitos com recursos externos simulados e não os reais então uma adaptação é feita.
+1! Apenas um porém: testes de integração pode acontecer em um cenário que replica produção, sem entretanto interferir no ambiente real - geralmente chamado de staging area. – OnoSendai 8/02/17 às 16:55
@gato Participantes do projeto que definem ou validam os requisitos mas isso não significa que eles serão obrigatóriamente os usuários finais, são os mais 'interessados'. As vezes atuam ao longo do projeto ou em uma parte especifica. – rray♦ 8/02/17 às 17:43
complementando a resposta do @rray, stakeholders podem ser, por exemplo, clientes, proprietários da empresa, concorrentes, funcionários... qualquer um que tenha interesse - positivo ou negativo - no projeto. – Leila 6/10/18 às 5:06
Como o termo diz, é o que é requisitado, o que se deseja que seja feito. Por exemplo, um cliente precisa de um aplicativo de chat online e procura uma empresa de desenvolvimento para implementá-lo. Nessa etapa, é definido o que o aplicativo deve cumprir, quais as funcionalidades principais, quais serão os usuários finais, possíveis restrições (como por exemplo, nesse caso, de que não devem haver delays no envio das mensagens). Tudo isso é acordado entre o cliente e a empresa, podendo ser desde algo mais informal como uma conversa, até um Documento de Requisitos (exemplo).
Essa etapa é extremamente importante, uma vez que, se o cliente disser que quer uma coisa e a equipe de desenvolvimento entender outra, será como se o cliente solicitasse uma chave de fenda e acabasse recebendo um martelo. Pode parecer besta mas realmente acontece, até porque muitas vezes nem o cliente sabe exatamente o que quer, e aí quando o projeto estiver quase pronto pode ver e falar "opa, mas eu não queria nada disso, faz de novo". E ninguém quer isso, né?
De posse dos requisitos estabelecidos, a equipe analisa o que deve ser feito e o foco agora passa a ser como será feito:
Assim como os requisitos, é importante que todo mundo entenda o que deve ser feito e, agora, como deve ser feito, logo, também costuma-se ter um documento ou alguma outra forma de comunicação que deixe isso claro para toda a equipe. Isso evita, por exemplo, que dois desenvolvedores peguem a mesma coisa para implementar. Um conceito muito famoso e importante (e facilmente compreensível) em Engenharia de Software é comumente expresso pelo gráfico abaixo:
Que significa "quanto mais demorar para mudar algo, mais caro custará". Para entender isso basta pensar em quanto custa manter uma equipe trabalhando em algo, para depois de um tempo chegar e "opa, vamos ter que jogar isso fora e fazer de novo". Tendo que pagar novamente salário e outros custos envolvidos, que poderiam estar sendo empregados em outros projetos.
Definidas as questões mais relacionadas ao gerenciamento do projeto, é hora de pensar em quais tecnologias serão usadas, como linguagem de programação, qual a plataforma em que o programa será usado (Windows, Linux, Android, multiplataforma). Além disso, podem ser definidas as principais estruturas e rotinas do programa, como a criação de determinada tabela no banco de dados, uma função para realizar login com Facebook etc.
Finalmente chega a hora de botar a mão na massa, a hora em que as estruturas e rotinas mencionadas acima devem ser implementadas, que as funcionalidades descritas em alto nível devem ser traduzidas para o código realmente.
Após a implementação, não é garantido que o produto esteja 100% OK, funcionando corretamente, sem nenhum problema. Na verdade, é praticamente impossível não ter nenhum bug. Quanto mais complexo o sistema, mais difícil garantir isso e mais difícil identificar isso também.
É aí que entram os testes: são uma tentativa de procurar possíveis problemas, de forma exaustiva (tanto quanto possível), até que se possa garantir um mínimo de confiabilidade ao cliente (claro que essa confiabilidade depende muito do tipo de produto). Existem muitos tipos e técnicas de Testes, e isso virou uma importante sub-área da Engenharia de Software. Há pessoas dentro da equipe especializadas em testar software. Não entrarei em detalhes mas a imagem dá uma ideia (quem tiver interesse é só pesquisar pelos termos).
É o momento em que o produto produzido é entregue ao cliente e é colocado em produção, em execução realmente. No nosso exemplo, é como quando o aplicativo é publicado na Play Store e lançado. Nesse momento podem haver problemas, como o famoso "na minha máquina funciona" mas na do cliente não. E aí isso vai sendo ajustado.
Gostaria de adicionar a etapa de manutenção que não foi citada mas é uma constante em qualquer projeto. Como é difícil definir todos os possíveis problemas com os testes, é possível que o produto seja entregue e depois surjam problemas que devem ser corrigidos, ou até mesmo uma possível melhoria pode ser implementada. Vale olhar novamente ao gráfico de custo de mudança x tempo acima: consertar algo em uma manutenção é bem mais caro do que resolver o problema antes.