Seu guia completo para o desenvolvimento de software de todas as coisas

Quão semelhantes são um chão de fábrica e um escritório de desenvolvedores de software?

Imagine uma sala cheia de programadores digitando códigos em seus computadores. E se você tratar a produção deles como widgets montados em uma linha de montagem de fábrica? As coisas que maximizam a produção funcionarão aqui também? Ou o processo de desenvolvimento é mais parecido com outras disciplinas de engenharia?

Os gerentes de projeto têm tentado resolver isso desde o início do desenvolvimento de software. A partir dessas questões, surgiu a definição do ciclo de vida do desenvolvimento de software.

O que é desenvolvimento de software?

É o processo de criação de software do zero. Embora escrever código seja a atividade principal, é muito mais do que isso.

O processo de desenvolvimento inclui ideação e design antes de escrever qualquer código. O planejamento é fácil de ignorar. Não parece desenvolvimento como escrever código. No entanto, responder primeiro a perguntas cruciais fortalece o produto acabado. Vale a pena seguir o projeto? Se sim, qual é a melhor maneira de fazer isso? Quais recursos são necessários e quais recursos é bom ter? As respostas dão ao projeto uma chance melhor de sucesso.

Embora as etapas sejam constantes, sua aplicação varia. A razão pela qual o desenvolvimento de software é uma nova disciplina. As disciplinas de engenharia estão maduras com centenas de anos de história. O desenvolvimento de software só remonta ao final da década de 1940. Ainda é uma nova disciplina. O método ágil tem apenas 20 anos. No entanto, é uma das coisas mais influentes que acontecem na teoria da criação de software. Independentemente disso, as seis fases do ciclo de vida de desenvolvimento de software são comuns a todos os sistemas.

6 estágios do ciclo de vida de desenvolvimento de software (SDLC)

Uma equipe de desenvolvimento pode usar o ciclo de vida de desenvolvimento de software em um projeto inteiro ou em um recurso. A evolução do uso do SDLC tem sido sobre a redução do risco, encurtando a duração de cada etapa. Em breve, veremos mais as diferentes metodologias. Primeiro, vamos examinar as etapas em si.

Além disso, vale a pena notar que você verá variantes em termos de número de etapas ou seus nomes. Às vezes, as etapas são mescladas, como desenvolvimento e teste. Outras vezes, você verá uma etapa dividida em duas, como planejamento se tornando planejamento e análise. No nosso caso, ficaremos com esses seis, pois eles definem claramente as fases.

1. Planejamento

A fase de planejamento é o passo mais importante. As partes interessadas precisam considerar tudo, incluindo a viabilidade do próprio projeto. Não há problema em matar todo o projeto aqui. Uma organização saudável capacitará as partes interessadas a fazê-lo, se necessário. Os programadores terão menos envolvimento durante esta fase em um ambiente empresarial. Proprietários de produtos, analistas de negócios e outras partes interessadas expressam suas necessidades nesta etapa.

2. Projeto

A fase de planejamento é o passo mais importante. As partes interessadas precisam considerar tudo, incluindo a viabilidade do próprio projeto. Não há problema em matar todo o projeto aqui. Uma organização saudável capacitará as partes interessadas a fazê-lo, se necessário. Os programadores terão menos envolvimento durante esta fase em um ambiente corporativo. Proprietários de produtos, analistas de negócios e outras partes interessadas expressam suas necessidades nesta etapa.

3. Desenvolvimento

O estágio de design também inclui o design da experiência do usuário (UX). Se o aplicativo tiver algum componente voltado para o usuário, o design UX é obrigatório. Isso inclui pesquisa de usuários observando pessoas reais interagindo com modelos de produtos. A razão pela qual isso acontece na fase de design em vez da fase de desenvolvimento é o tempo. As sessões do usuário levam tempo. Muitas vezes, mais discussões com as partes interessadas nos negócios também acontecem a partir dos dados coletados.

4. Teste

Em seguida, a equipe de desenvolvimento testa o código. O escritor de código e o testador devem ser pessoas diferentes. Ainda melhor é um testador de garantia de qualidade não desenvolvedor. Os desenvolvedores tendem a pensar apenas em cenários de caminhos felizes. Profissionais de teste de controle de qualidade dedicados tendem a pensar melhor em como podem quebrar o software. Eles são mais propensos a encontrar bugs antes da implantação dessa maneira. O resultado é um software mais estável no lançamento.

Testes automatizados vs. manuais

Testes de unidade e testes de integração geralmente são automatizados. Muitas vezes, uma plataforma DevOps executa esses testes em um novo código antes de mesclá-lo no branch master.

O teste manual está longe de ser obsoleto. Testes automatizados fazem a mesma coisa repetidamente. No entanto, uma pessoa que faz testes manuais pode encontrar bugs acidentalmente durante os testes. É a variabilidade no teste manual que é sua força.

Teste de unidade

Um teste de unidade verifica apenas um método, nada mais. A função em teste é o limite. O desenvolvedor escreve os testes de unidade e alguns frameworks SDLC os obrigam. A Programação Extrema os exige. Também prescreve o desenvolvimento orientado a testes. Esta é a prática de escrever testes de unidade primeiro. Em seguida, escrever o código do programa real.

Teste de integração

Os testes de integração verificam seções ou recursos da base de código. Eles geralmente são automatizados e executados pela plataforma DevOps. O que eles verificam abrange mais do que um único método. Um exemplo é verificar se uma chamada de API persistiu em um novo registro em um banco de dados. Compare isso com um teste de unidade verificando também o método da API. O teste de unidade só seria capaz de verificar se uma chamada para o banco de dados deveria acontecer. O teste de integração pode provar que os dados fluíram pelo aplicativo conforme o esperado.

Teste do sistema

A forma final de teste é o teste completo do sistema. Para recapitular, o teste de unidade verifica apenas uma função. O teste de integração verifica um recurso. Mas o teste do sistema trata todo o aplicativo como uma única unidade. O teste de fumaça é uma forma leve de teste do sistema. Nele, o testador interage com o sistema como um usuário natural faria e garante que ele se comporte conforme o esperado. Em contraste com o teste completo do sistema de ponta a ponta, que é mais rigoroso. Um teste de sistema completo verifica todas as partes de um sistema como uma única entidade. Além disso, um conjunto de testes de integração pode servir como um teste completo do sistema.

5. Implantação

A fase de implantação está colocando o código testado em produção. Automatizar a implantação a torna mais confiável. Além disso, praticar implantações de produção também aumenta as chances de uma implantação tranquila. A equipe de desenvolvimento pratica com um ambiente de teste chamado ambiente de teste. Deve ser idêntico ao de produção. Quanto mais parecidos forem os dois ambientes, maior será o valor da implantação da prática.

6. Manutenção

Tudo até este ponto no SDLC será apenas cerca de um quarto do custo total de propriedade. O custo inicial de desenvolvimento de software é de 25% do que a empresa irá gastar. A fase de manutenção custará ao negócio cerca de 75% do custo total de propriedade. A defesa contra o aumento dos custos de manutenção é mais atenção às fases anteriores. Isso significa melhor design técnico, desenvolvimento e testes mais completos. A alternativa é a dívida técnica. Assim como a dívida real, ela fica mais cara com o tempo.

5 principais metodologias de desenvolvimento de software

Embora as etapas do SDLC sejam imutáveis, sua implementação e ordem de execução variam. Vejamos as formas mais populares pelas quais as organizações realizam o processo de desenvolvimento de software.

1. Ágil

O que torna o Agile único é o foco nas pessoas. As metodologias ágeis reorientaram a atenção da indústria. Antes, o foco era o produto, o software. O Agile desafiou isso e se concentrou nos indivíduos que faziam o processo. Além disso, antes do Agile Manifesto, Extreme Programming (XP) e Scrum não tinham conexão. No entanto, depois, seus praticantes se uniram sob a bandeira do Agile.

Agile não é um framework em si. É um framework para frameworks. Em sua essência, trata-se de focar nas pessoas e iterações rápidas. É exatamente o que o nome diz, ágil. Bem feito, há flexibilidade na obtenção do resultado. Os processos nunca são feitos às custas das pessoas, que, em vez disso, extraem valor deles.

Outro inquilino importante do Agile é uma abordagem iterativa. A ideia é fazer blocos de trabalho em períodos mais curtos de tempo. Dessa forma, a empresa pode se adaptar às mudanças no mercado mais rapidamente. A capacidade de mudar rapidamente a direção do desenvolvimento é o que o torna ágil. Ao mesmo tempo, a equipe de desenvolvimento pode aprender com o que fez em cada iteração e melhorar. As equipes ágeis fazem isso em reuniões retrospectivas após cada iteração.

2. Programação extrema

A programação extrema (muitas vezes abreviada como XP) começou no início dos anos 90. Martin Fowler foi um dos signatários originais do Manifesto Ágil. Ele acha que o Agile ganhou popularidade devido ao framework XP. Além disso, ele afirma que é a melhor maneira de começar a fazer desenvolvimento de software Agile.

XP recebe o nome de sua abordagem. São necessárias boas práticas comuns de software e as exige. É isso que o torna "extremo". O XP requer coisas como testes de unidade, programação em pares, lançamentos com mais frequência.

O que torna o XP um método único é:

• Ciclos de iteração curtos (1 a 2 semanas sendo comum)
• Abertura para substituir itens de trabalho na iteração atual (algo que o Scrum não permite)
• Ênfase em testes automatizados e programação em pares

3. Incline-se

Lean não era Agile tecnicamente, mas tem uma sensação semelhante na prática. Agora é aceito como parte do Agile pela maioria. Seu foco é diferente do Agile tradicional. De acordo com o manifesto Agile, "Indivíduos e interações sobre processos e ferramentas". O Lean se concentra mais no software do que nos fabricantes.

Suas raízes são os princípios de manufatura Lean da Toyota. Aqui estão as sete partes que o definem. Se você estiver familiarizado com a fabricação Lean, isso soará semelhante. Eles são:

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

4. Scrum

Scrum é o método ágil mais popular. De acordo com o 14º relatório State of Agile, 58% das empresas de software usam Scrum. Se você incluir híbridos Scum, a porcentagem salta para 84%. O que levanta a questão, por que é o mais popular?

A resposta é que Scrum tem tudo a ver com fazer mais trabalho em menos tempo. Isso atrai as empresas. Cada iteração no Scrum é um "sprint". O nome reforça a ideia de velocidade. Normalmente, um sprint dura de 2 a 3 semanas. Uma vez que uma equipe Scrum tenha planejado um sprint, ninguém deve alterá-lo. O novo trabalho deve esperar até o início do próximo sprint. Isso exige disciplina por parte das partes interessadas do negócio. Na prática, esta regra do Scrum é frequentemente violada. É por isso que as equipes relatam fazer um híbrido Scrum com frequência.

Outra característica do Scrum é o Scrum Master. Este é um membro da equipe nomeado para ser responsável por manter o sprint no alvo. Muitas vezes, o Scrum Master é um desenvolvedor da equipe de desenvolvimento.

A variante mais comum do Scrum é o ScrumBan, que é um mashup de Scrum e Kanban. Kanban tem suas raízes no processo de fabricação japonês da Toyota, como o Lean. É um sistema de trabalho just-in-time.

Cada item de trabalho é como uma iteração própria. Um desenvolvedor só trabalha em uma coisa de cada vez. A regra é um item "em andamento" por desenvolvedor. Este limite de trabalho em andamento estrito ilumina qualquer gargalo. Os desenvolvedores rastreiam os itens de trabalho em andamento por meio de um quadro Kanban. Como uma nota lateral, é daí que vem o nome. Em japonês, Kanban significa "placa".

5. Cachoeira

O método cascata é a primeira de todas as práticas de desenvolvimento de software. Ele antecede o Agile em várias décadas, pelo menos. Esse método também é mais antigo que seu nome.

É a forma natural como as empresas sempre trabalharam. É um processo linear, e você começa do início. Primeiro, as partes interessadas compilam os requisitos. Eles não estão fazendo isso por um recurso ou dois. Não, as partes interessadas do negócio abrangem todo o projeto de uma só vez. Depois disso, o trabalho começa. Os desenvolvedores fazem todo o trabalho sem nenhuma iteração até a conclusão.

O caminho em cascata é o mais fácil de entender conceitualmente. As pessoas fazem uma coisa de cada vez. Dito isto, é o mais arriscado para o sucesso do negócio. Se algo estiver fora do objetivo, as partes interessadas não poderão corrigi-lo até a conclusão do projeto. A razão é que não será notado até a conclusão do projeto.

3 subtipos principais de software

O software finalizado é um dos três tipos. Esses tipos são software de sistema, programação e aplicativo. Para ilustrar, aqui está uma analogia de fazer bolos. Um misturador ou espátula é o software de programação. Ele permite que você faça mais bolos ou mais aplicativos de software nesta analogia. Ao montar um bolo, a camada inferior é o software do sistema. É a fundação. Sem ele, você não pode ter um bolo em camadas. A camada superior seria então o software de aplicação. É o que é visível para a maioria dos observadores casuais.

Software de sistema

O sistema operacional de um computador é um software de sistema. É crucial para a utilidade dele. Imagine um computador sem sistema operacional. Você só seria capaz de interagir com ele via linguagem de máquina. Isso é binário puro - apenas uns e zeros. Você acharia impossível trabalhar com qualquer nível de escala. O software do sistema abre a utilidade de um computador.

Windows, macOS e Linux são os exemplos mais populares de software de sistema. Drivers de dispositivo também são software de sistema. Eles estendem a funcionalidade básica de um sistema operacional. Dispositivos inteligentes sem sistema operacional usam firmware para habilitar sua funcionalidade. Também é um software de sistema.

Software de programação

O software de programação é um subconjunto do software aplicativo. Qualquer programa que um desenvolvedor usa para criar novos programas seria classificado. Eles variam de editores de texto simples a ambientes de desenvolvimento integrados (IDEs) complexos. A maioria dos desenvolvedores prefere ferramentas de software de programação mais complexas. Programas como o Visual Studio da Microsoft ajudam a acelerar o desenvolvimento.

Software aplicativo

O software aplicativo é o tipo mais comum. É o software que permite fazer coisas com um computador. Torna os computadores úteis. Exemplos populares são programas como Microsoft Word e Excel.

O software em nuvem também se enquadra nessa categoria. Google Docs, Dropbox e até Instagram são softwares de aplicação. Se você se sentir confuso se algo é um software de aplicativo ou não, aqui está um teste simples. O programa precisa de algo mais para ser executado? Windows ou Android não. São softwares de sistema. PowerPoint, ou mesmo um jogo como Call of Duty, precisam de outras coisas em execução para funcionar, o que significa que são softwares aplicativos. Sem drivers de dispositivo e um sistema operacional, eles não podem ser executados.

Conclusão

Os métodos de desenvolvimento de software ainda estão amadurecendo. No entanto, independentemente do método utilizado, as etapas permanecem as mesmas. As equipes ágeis podem iterar sobre eles mais rapidamente, e os praticantes do Waterfall movem-se lentamente de um para o outro. No entanto, para construir um software melhor, você deve fortalecer o processo para cada etapa. Eles constroem um no outro. O ciclo de vida de desenvolvimento de software não existe sem uma de suas etapas. As partes fazem o todo.

Pense no que aconteceria se você deixasse qualquer passo de fora. Sem planejar o que você está fazendo? Sem design, o processo de desenvolvimento será aleatório. Deixar de fora a etapa de desenvolvimento é impossível. A falta de testes garante que o produto não funcionará conforme o esperado. Se não houver implantação, ninguém terá acesso para usar o produto. Um aplicativo não mantido cai em desuso. Cada etapa é crucial para o sucesso de um produto de software.