Software Development and Design

Existem muitas metodologias de desenvolvimento de software para escolher e você deve aprender com as práticas recomendadas de engenharia de software. Em sua carreira, você desenvolverá software de forma colaborativa e independente. Isso significa que o controle de origem (source control) será uma grande parte do seu trabalho como desenvolvedor.

Software Development Life Cycle (SDLC)

O processo de desenvolvimento de software também é conhecido como ciclo de vida de desenvolvimento de software (SDLC). Este processo é mais do que apenas codificação. Também inclui a coleta de requisitos, a criação de uma prova de conceito, o teste e a correção de bugs.

Ciclo de vida de desenvolvimento de software (SDLC)
A figura mostra um círculo com palavras e números:
1 requisitos e análise, 2 design, 3 implementação, 4 testes, 5 implantação e 6 manutenção.

O ciclo de vida de desenvolvimento de software (SDLC) é o processo de desenvolvimento de software, começando com uma ideia e terminando com a entrega. Este processo consiste em seis fases. Cada fase recebe informações dos resultados da fase anterior. Não existe um SDLC padrão, portanto as fases exatas podem variar, mas as mais comuns são:

• Fase 1. Requisitos e Análise
• Fase 2. Projeto
• Fase 3. Implementação
• Fase 4. Teste
• Fase 5. Implantação
• Fase 6. Manutenção

Historicamente, as equipes de desenvolvimento geralmente seguiam essas fases em ordem no método em cascata. O objetivo do cascata era completar cada fase do SDLC até o último detalhe antes de prosseguir para a próxima, nunca retornando à fase anterior e anotando tudo ao longo do caminho.

Embora os métodos em cascata ainda sejam amplamente utilizados hoje, eles estão sendo gradualmente substituídos por métodos mais adaptáveis e flexíveis que produzem software melhor, mais rápido e com menos problemas. Esses métodos são conhecidos coletivamente como “desenvolvimento ágil”.

É importante compreender que o SDLC pode ser aplicado de muitas maneiras diferentes. Suas fases podem ser repetidas e a ordem invertida. As fases individuais podem ser executadas em vários níveis em paralelo (por exemplo, os requisitos podem ser reunidos separadamente para detalhes da interface do usuário, integrações de back-end, parâmetros operacionais e de desempenho, etc.).

Veremos as fases do SDLC com mais detalhes e em sua ordem clássica (lembre-se: esta é uma descrição, não uma prescrição)

1.Fase de Requisitos e Análise

 O objetivo da fase de requisitos e análise é responder a vários níveis de perguntas. Eles começam explorando a situação atual, as necessidades e restrições das partes interessadas, a infraestrutura atual, etc. Eles determinam quais problemas este novo software precisa resolver.

Depois que o problema for melhor definido, questões mais concretas poderão ser exploradas para determinar onde e em que contexto o novo software precisará estar instalado.

Quando as respostas a essas perguntas são compiladas, é hora de começar a explorar requisitos mais precisos, concentrando-se nos recursos desejados e na experiência do usuário (UX).

Finalmente, a equipe começa a avaliar as opções arquitetônicas para a construção do próprio software. Para a maioria dos aplicativos empresariais, isso significa muitas iterações na definição de requisitos para o front-end e back-end do software. Você também precisará fornecer pontos de integração para outros aplicativos, bem como serviços para gerenciamento do ciclo de vida.

Após reunir os requisitos, a equipe analisa os resultados para determinar o seguinte:

• É possível desenvolver o software de acordo com estes requisitos e isso pode ser feito dentro do orçamento?
• Existem riscos para o cronograma de desenvolvimento e, em caso afirmativo, quais são?
• Como o software será testado?
• Quando e como o software será entregue?

Na conclusão desta fase, o método clássico em cascata sugere a criação de um documento de Especificação de Requisitos de Software (SRS) que declara os requisitos e o escopo do software e confirma isso meticulosamente com as partes interessadas.

Fases de design e implementação

2. Design 

A fase de design classicamente utiliza o documento SRS da fase de Requisitos e Análise como entrada. Durante a fase de design, os arquitetos e desenvolvedores de software projetam o software com base no SRS fornecido.

Na conclusão da fase de design, a equipe cria documentos de Design de Alto Nível (HLD) e Design de Baixo Nível (LLD). O HLD oferece uma “visão de 10.000 pés” do software proposto. Descreve a arquitetura geral, os componentes e seus relacionamentos, podendo fornecer detalhes adicionais. O LLD, baseado no documento HLD, descreve com muito mais detalhes a arquitetura dos componentes individuais, os protocolos usados para comunicação entre eles e enumera as classes necessárias e outros aspectos do projeto.

3. Implementação

A fase de implementação classicamente toma como entrada o HLD e o LLD da fase de design.

A fase de implementação costuma ser chamada de fase de codificação ou desenvolvimento. Durante esta fase, os desenvolvedores pegam a documentação do design e desenvolvem o código de acordo com esse design. Todos os componentes e módulos são construídos durante esta fase, o que torna a implementação a fase mais longa do ciclo de vida. Durante esta fase, os engenheiros de teste também escrevem o plano de teste.

Na conclusão da fase de implementação, o código funcional que implementa todos os requisitos do cliente está pronto para ser testado.

Fases de teste, implantação e manutenção

4. Teste

A fase de teste utiliza classicamente o código do software da fase de implementação como entrada. Durante esta fase, os engenheiros de teste pegam o código e instalam no ambiente de teste para que possam seguir o plano de teste. O plano de teste é um documento que inclui uma lista de todos os testes a serem realizados para cobrir todos os recursos e funcionalidades do software, conforme especificado pelos requisitos do cliente. Além dos testes funcionais, os engenheiros de teste também realizam:

• Teste de integração
• Teste de desempenho
• Teste de segurança

Quando o código não passa no teste, o engenheiro de teste identifica o bug, que é repassado aos desenvolvedores. Depois que o bug foi corrigido, os engenheiros de teste testarão novamente o software. Esse vaivém entre os engenheiros de teste e desenvolvimento continua até que todo o código passe em todos os testes.

Na conclusão da fase de testes, um software funcional de alta qualidade e livre de erros está pronto para produção, em teoria. Na prática, isso raramente acontece. Os desenvolvedores aprenderam a testar com mais eficiência, como incorporar testes em fluxos de trabalho automatizados e como testar software em muitos níveis diferentes de detalhe e abstração: desde a definição mais ínfima de função de baixo nível até agregações de componentes em grande escala. Eles também aprenderam que o software nunca está livre de bugs e, em vez disso, deve ser observável, testado em produção e resiliente para que possa permanecer disponível e funcionar adequadamente, apesar dos problemas.

5. Implantação (Deployment)

A fase de implantação utiliza o software da fase de teste como entrada. Durante a fase de implantação, o software é instalado no ambiente de produção. Se não houver problemas de implantação, o gerente do produto de trabalho estará com os arquitetos e engenheiros projetados para decidir se o software está pronto para ser lançado.

No final da fase de implantação, o software final é lançado para clientes e outros usuários finais.

6. Manutenção

Durante a fase de manutenção, a equipe:

• Fornece suporte aos clientes
• Corrige bugs encontrados em produção
• Trabalha em melhorias de software
• Recebe novas requisições do cliente

Ao final da fase de manutenção, a equipe está pronta para trabalhar na próxima iteração e versão do software, o que traz o processo de volta ao início do SDLC e à fase de requisitos e análise.

Desenvolvimento Ágil de Software

O método Agile é flexível e focado no cliente. Embora metodologias semelhantes ao Agile já estivessem sendo praticadas, o modelo Agile não foi oficializado até 2001, quando dezessete desenvolvedores de software se uniram para encontrar uma solução para suas frustrações com as opções atuais e criaram o Manifesto para Desenvolvimento Ágil de Software, também conhecido como Manifesto Agile.

Agile Manifesto

De acordo com o Manifesto Ágil, os valores do Ágil são:

• Indivíduos e interações acima de processos e ferramentas
• Software que trabalha sobre uma documentação completa
• Colaboração do cliente sobre negociação de contrato
• Responder à mudança em vez de seguir um plano

O manifesto lista doze princípios diferentes:

1. Foco no cliente - Nossa maior prioridade é satisfazer o cliente por meio da entrega antecipada e contínua de software valioso.
2. Aceite a mudança e adapte-se - Aceite as mudanças nos requisitos, mesmo no final do desenvolvimento. Os processos ágeis aproveitam as mudanças para obter vantagem competitiva do cliente.
3. Entrega frequente de software funcional - Entregar software funcional com frequência, de algumas semanas a alguns meses, com preferência ao prazo mais curto.
4. Colaboração – Empresários e desenvolvedores devem trabalhar juntos diariamente durante todo o projeto.
5. Equipes motivadas - Construa projetos em torno de indivíduos motivados. Dê-lhes o ambiente e o apoio de que precisam e confie neles para realizar o trabalho.
6. Conversas cara a cara – O método mais eficiente e eficaz de transmitir informações para e dentro de uma equipe de desenvolvimento é a conversa cara a cara.
7. Software funcionando - Software funcionando é a principal medida de progresso.
8. Trabalhe em um ritmo sustentável – Os processos ágeis promovem o desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente.
9. Ambiente ágil – A atenção contínua à excelência técnica e ao bom design aumenta a agilidade.
10. Simplicidade – A arte de maximizar a quantidade de trabalho não realizado – é essencial.
11. Equipes auto-organizadas – As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizadas.
12. Melhoria Contínua – Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e, em seguida, refina e ajusta seu comportamento de acordo.

Métodos Ágeis

O Manifesto Ágil por design não era preciso sobre como o Agile deveria funcionar. Depois de forjar o Manifesto, os seus criadores (e muitos outros) continuaram a desenvolver estas ideias, absorvendo novas ideias de muitas fontes e testando-as na prática. Como resultado, nas últimas décadas, surgiram muitas abordagens sobre Agile e algumas tornaram-se amplamente populares. Esses incluem:

• Agile Scrum - No rugby, o termo scrum descreve um ponto do jogo onde os jogadores se aglomeram e tentam obter a posse da bola. O Scrum concentra-se em equipes pequenas e auto-organizadas que se reúnem diariamente por curtos períodos e trabalham em sprints iterativos, adaptando constantemente as entregas para atender aos requisitos em constante mudança.
• Lean - Baseado no Lean Manufacturing (Manufatura, Produção Enxuta), o método Lean enfatiza a eliminação do desperdício de esforço no planejamento e execução e a redução da carga cognitiva do programador.
• Extreme Programming (XP) - Comparado ao Scrum, o XP é mais prescritivo sobre as melhores práticas de engenharia de software e aborda de forma mais deliberada os tipos específicos de problemas de qualidade de vida enfrentados pelas equipes de desenvolvimento de software.
• Desenvolvimento Orientado a Recursos (FDD) - O FDD prescreve que o desenvolvimento de software deve prosseguir em termos de um modelo geral, dividido, planejado, projetado e construído recurso por recurso. Ele especifica um processo de modelagem usado para estimar e planejar a entrega de recursos e um conjunto detalhado de funções tanto para a equipe principal de desenvolvimento quanto para o pessoal de suporte.

Das metodologias descritas acima, Agile Scrum é provavelmente a mais popular. Discutiremos abaixo alguns termos e conceitos do Scrum que foram adotados mais ou menos universalmente pela comunidade Agile em todas as metodologias.

Sprints

Um sprint é um período específico de tempo (time-boxed) que geralmente varia entre duas e quatro semanas, mas de preferência o mais curto possível. A duração do sprint deve ser determinada antes do início do processo e raramente deve ser alterada.

Durante um sprint, cada equipe assume tarefas, também conhecidas como histórias de usuário, quantas acharem que podem realizar dentro do prazo definido para o sprint. Quando o sprint terminar, o software deverá estar funcionando e entregável, mas isso não significa necessariamente que será entregue; um sprint nem sempre leva a um lançamento, mas o Agile exige que o software continue entregável.

Lista de Pendências (Backlog)

É função do proprietário do produto criar o backlog. Esse backlog é composto por todas as funcionalidades do software, em uma lista priorizada. Os recursos do backlog são resultado da fase de Requisitos e Análise e incluem recursos que não estarão necessariamente no lançamento imediato. Novos recursos podem ser adicionados ao backlog a qualquer momento, e o proprietário do produto pode redefinir a prioridade do backlog com base no feedback do cliente.

Histórias de usuários

Quando um recurso chega perto do topo da lista de prioridades, ele é dividido em tarefas menores chamadas histórias de usuários. Cada história de usuário deve ser pequena o suficiente para que uma única equipe possa concluí-la em um único sprint. Se for muito grande para ser concluído em um único sprint, a equipe deverá dividi-lo ainda mais. Como o software deve ser entregue ao final de cada sprint, uma história de usuário também deve obedecer a essas regras.

Uma história de usuário é uma declaração simples do que um usuário (ou função) precisa e por quê. O modelo sugerido para uma história de usuário é:

Como <usuário|função>, eu gostaria de <ação>, para que <valor|benefício>

A conclusão de uma história de usuário requer a conclusão de todas as fases do SDLC. A história do usuário em si já deve ter os requisitos definidos pelo proprietário do produto, e a equipe que a assume precisa criar um design para a tarefa, implementá-la e testá-la.

Scrum Teams

As equipes Scrum são multifuncionais, colaborativas, autogerenciadas e autocapacitadas. Idealmente, essas equipes scrum não devem ter mais de 10 indivíduos, mas devem ser grandes o suficiente para finalizar uma história de usuário em um sprint.

Todos os dias, cada equipe scrum deve ter uma reunião diária (standup). Um "standup" deve ser uma reunião que não pode durar mais de 15 minutos e deve acontecer no mesmo horário todos os dias. Na verdade, é chamado de “standup” porque, idealmente, deve ser curto o suficiente para que a equipe possa realizá-lo sem precisar se sentar.

O objetivo do 'standup' diário é manter todos os membros da equipe sincronizados com o que cada pessoa realizou desde a última reunião, o que eles vão trabalhar até o próximo standup e quais obstáculos eles têm que podem estar impedindo-os de terminar sua tarefa. O scrum master facilita essas reuniões e seu trabalho é relatar e/ou ajudar a remover obstáculos.

Lean Software Development (Desenvolvimento de software enxuto)

 O desenvolvimento de software Lean é baseado nos princípios do Lean Manufacturing, que se concentram em minimizar o desperdício e maximizar o valor para o cliente.

Na sua forma mais simples, o Lean Software Development entrega apenas o que os clientes desejam. No livro Lean Software Development: An Agile Toolkit, existem sete princípios para o Lean:

1. Eliminar desperdício
2. Amplifique o aprendizado
3. Decida o mais tarde possível
4. Entregue o mais rápido possível
5. Capacite a equipe
6. Construa integridade em
7. Otimize o todo
   

Eliminar desperdício

Desperdício é tudo aquilo que não agrega valor aos clientes. A definição de valor é subjetiva, porém, porque é determinada pelo cliente. Eliminar o desperdício é o princípio Lean mais fundamental, aquele do qual decorrem todos os outros princípios.

Para eliminar o desperdício, você deve ser capaz de entender o que é desperdício. Desperdício é tudo aquilo que não agrega valor direto ao cliente. Existem sete desperdícios no desenvolvimento de software:

• Trabalho parcialmente concluído
• Processos Extras
• Recursos extras
• Troca de tarefas
• Esperando
• Movimento
• Defeitos

Trabalho parcialmente concluído

O trabalho parcialmente realizado é um desperdício porque:

• Não agrega nenhum valor ao cliente
• O tempo e os recursos gastos neste trabalho poderiam ter sido usados em algo que fosse de valor para o cliente
• O trabalho geralmente não é mantido, então eventualmente se torna obsoleto

Processos extras

Processos extras são como um monte de papelada. Como resultado, eles são um desperdício praticamente pelas mesmas razões que o trabalho parcialmente executado.

Recursos extras

Se o cliente não pediu, isso não agrega valor. Pode ser bom ter, mas é melhor usar os recursos para construir exatamente o que os clientes desejam.

Troca de tarefas

Os humanos precisam de tempo para mudar de ideia e se concentrar em outra tarefa, e esse tempo gasto mudando de contexto é um desperdício. A alternância de tarefas desperdiça o tempo de um recurso (pessoa), por isso é um desperdício atribuir um recurso a vários projetos.

Esperar

Muitas pessoas concordariam que, por definição, esperar é uma grande perda de tempo. Portanto, qualquer tipo de atraso é um desperdício. Exemplos de atraso no desenvolvimento de software são atrasos em:

• iniciar o projeto
• obter os recursos certos (equipe)
• obter os requisitos do cliente
• aprovações de documentação
• obter respostas
• tomar decisões
• implementação
• testes

Movimento

O desenvolvimento enxuto de software define movimento para duas coisas: pessoas e artefatos. O movimento para as pessoas ocorre quando elas precisam caminhar fisicamente de sua mesa até outro membro da equipe para fazer uma pergunta, colaborar e assim por diante. Quando eles saem da mesa, não é apenas o tempo que levam para chegar ao destino que é um desperdício, mas também o tempo de troca de tarefas.

O movimento de artefatos ocorre quando documentos ou códigos são movidos de uma pessoa para outra. Na maioria das vezes, o documento não contém todas as informações da próxima pessoa, então ou essa pessoa precisa reunir as informações novamente ou a transferência exige tempo, o que é um desperdício.

Defeitos

Defeitos despercebidos (também conhecidos como bugs) são um desperdício devido ao impacto do defeito. O defeito pode causar um efeito bola de neve com outros recursos, portanto, o tempo necessário para depurá-lo é um desperdício. Além disso, para um cliente, o valor do software é reduzido quando ele enfrenta problemas, então o recurso acaba sendo um desperdício.

Amplifique o aprendizado com sprints curtos

Para poder ajustar o software, deve haver iterações curtas e frequentes do software em funcionamento. Tendo mais iterações:

• Os desenvolvedores aprendem mais rápido
• Os clientes podem dar feedback mais cedo
• Os recursos podem ser ajustados para que agreguem mais valor aos clientes

Decida o mais tarde possível

Quando há incerteza, é melhor adiar a tomada de decisão até o mais tarde possível no processo, porque é melhor basear as decisões em fatos e não em opiniões ou especulações.

Além disso, quando uma decisão ainda não foi tomada, o software é construído para ser flexível, a fim de acomodar a incerteza. Essa flexibilidade permite que os desenvolvedores façam alterações quando uma decisão for tomada – ou no futuro, se os requisitos mudarem.

Entregue o mais rápido possível

Entregando o software mais rápido:

• Permite que os clientes forneçam feedback
• Permite que os desenvolvedores amplifiquem o aprendizado
• Oferece aos clientes os recursos de que eles precisam agora
• Não permite que os clientes mudem de ideia
• Faz com que todos tomem decisões mais rapidamente
• Produz menos resíduos

Você notará que cada uma dessas razões pratica pelo menos um dos princípios lean discutidos anteriormente.

Capacite a equipe

Cada pessoa tem sua própria experiência, portanto deixe-a tomar decisões em sua área de especialização. Quando combinado com outros princípios como eliminação de desperdícios, tomada de decisões tardias e entregas rápidas, não há tempo para que outros tomem decisões pela equipe.

Construa integridade em

Integridade para software é quando o software atende exatamente ao que o cliente precisa. Outro nível de integridade é que o software mantém sua utilidade para o cliente.

Otimize o todo

Embora um dos princípios seja capacitar a equipe, cada especialista deve dar um passo atrás e ver o panorama geral. O software deve ser construído de forma coesa. O valor do software será prejudicado se cada especialista se concentrar apenas em sua experiência e não considerar as ramificações de suas decisões sobre o restante do software.