Qual Processo de Software usar?Online version
Estudos de caso para avaliação de qual o melhor método de desenvolvimento de software a ser empregado.
1
O governo contratou uma empresa para atualizar o sistema de cálculo de imposto de renda. As regras de negócio são estritamente definidas por leis já aprovadas, os requisitos são 100% conhecidos, estáveis e não podem sofrer qualquer alteração durante o desenvolvimento.
2
Uma startup quer criar um aplicativo de fitness, mas os fundadores têm apenas objetivos gerais. Eles não sabem ao certo como deverá ser a interface do usuário, nem quais funções específicas manterão os usuários engajados. Eles precisam visualizar o produto rapidamente para validar a ideia com os clientes.
3
Uma grande empresa aeroespacial vai desenvolver o software de controle de uma nova aeronave comercial. Trata-se de um projeto gigantesco, de altíssimo custo e com riscos técnicos e financeiros severos. A gerência exige um modelo que faça avaliações rigorosas de risco antes de investir pesado em cada nova fase de desenvolvimento.
4
Uma universidade precisa de um novo sistema acadêmico. O projeto inteiro levará 1 ano, mas o período de matrículas começa em 2 meses. A universidade exige que o módulo de matrículas seja entregue e colocado em funcionamento primeiro, enquanto as funções de biblioteca e financeiro podem ser adicionadas nos meses seguintes.
5
Uma rede de lojas precisa de um sistema interno de Recursos Humanos. Em vez de programar tudo do zero, o arquiteto de software percebe que pode comprar um pacote de banco de dados comercial, usar uma API de pagamento pronta e um framework web de prateleira, unindo essas partes para montar o sistema rapidamente. O cliente topou adaptar alguns de seus requisitos para caber no que os sistemas prontos oferecem.
6
Uma empresa médica está desenvolvendo o software embarcado para uma bomba de insulina que ficará acoplada ao corpo de pacientes. Devido à inflexibilidade do hardware que já foi fabricado e pelo fato de que uma falha de software pode matar o paciente, a empresa exige documentação pesada e análise exaustiva de segurança de toda a especificação antes de autorizar a escrita do código.
7
Uma equipe de desenvolvedores teve uma ideia para um novo algoritmo de busca e criptografia de dados. Eles sabem os requisitos, mas não têm certeza se a tecnologia atual e o servidor que possuem suportarão processar isso com velocidade suficiente. Eles decidem criar um sistema simplificado e focado apenas no algoritmo, que será testado e depois jogado fora.
8
Um estúdio de games está criando um novo jogo online (MMORPG). Eles sabem que o jogo sofrerá mudanças contínuas de acordo com a reação da comunidade. Eles lançam uma versão "Alfa" apenas com o mapa, meses depois uma versão "Beta" contendo as lutas e, após o lançamento, continuarão adicionando novas missões de tempos em tempos.
9
Um banco nacional com 30 anos de mercado vai abandonar seus sistemas Mainframe antigos para um sistema moderno em nuvem. É um projeto de 5 anos. Por ser um ambiente extremamente mutável e com chances de falhas milionárias, a gerência exige que o planejamento seja reavaliado e o cronograma seja ajustado a cada ciclo concluído, passando por constantes análises de viabilidade e risco técnico.
10
Um pequeno comerciante quer vender seus produtos online. Ele tem pouquíssimo dinheiro e tempo. A equipe de software propõe usar a plataforma WordPress, instalar o plugin WooCommerce (para a loja) e integrar com o serviço de correios. A equipe de engenharia quase não escreverá código novo, apenas configurará as soluções.
Explicação
O modelo Cascata é ideal (e aplicável) quando os requisitos do problema são perfeitamente compreendidos e razoavelmente estáveis desde o primeiro dia. Como as regras são baseadas em uma lei já aprovada, o trabalho pode fluir linearmente da comunicação até a entrega sem necessidade de revisões iterativas.
A Prototipação é o melhor caminho quando os requisitos são obscuros, especialmente em relação à interação humano-máquina (telas e usabilidade). Criar um "projeto rápido" ajudará os stakeholders a compreenderem melhor o que deve ser construído antes de programar o sistema definitivo.
O modelo Espiral, proposto por Boehm, é essencialmente dirigido a riscos. Ele é altamente recomendado para sistemas de larga escala onde falhas não descobertas (riscos não mitigados) podem ser catastróficas. Cada "volta" na espiral exige uma análise explícita de riscos antes de continuar.
A grande vantagem do modelo Incremental é fornecer as funcionalidades mais críticas (ou urgentes) logo nos primeiros incrementos. Isso permite que o cliente obtenha valor e comece a usar partes operacionais do software sem ter que esperar o sistema inteiro ficar pronto.
Este modelo foca no reúso. Ao integrar aplicações de prateleira (COTS) ou componentes existentes, a equipe reduz o tempo e os custos de desenvolvimento. O sacrifício é que os requisitos precisam ser adaptados para se encaixarem nos componentes disponíveis.
Sistemas críticos em segurança (safety-critical) e sistemas embarcados de hardware inflexível costumam exigir o modelo em Cascata formal. A necessidade de compromisso inicial e a documentação completa de requisitos e projeto são vitais antes da implementação, pois corrigir um defeito de arquitetura depois pode ser caríssimo ou fatal.
Protótipos não servem apenas para telas. Como vimos nas fontes, a prototipação é excelente quando o desenvolvedor está inseguro quanto à eficiência de um algoritmo ou à adaptabilidade de uma tecnologia. Um protótipo estrutural descartável mitiga esse risco antes do desenvolvimento real.
Softwares de entretenimento modernos reagem fortemente ao feedback do usuário. Desenvolver iterativamente e incrementalmente permite liberar o software em versões operacionais (Alfa, Beta, v1.0, v2.0), refinando o produto e absorvendo as inevitáveis mudanças de escopo ao longo do tempo.
A longa duração, a complexidade e a exigência de planejamento adaptativo baseado em revisões de risco tornam o Espiral perfeito aqui. Diferente da cascata, o modelo espiral assume que o plano não é fixo; custo e cronograma são ajustados em cada volta (circuito) baseado no aprendizado e nos riscos encontrados.
A construção do sistema é feita ligando serviços de terceiros e frameworks que já resolvem o problema. Quando o tempo e o orçamento são os fatores restritivos e não há necessidade de um sistema feito totalmente "sob medida", integrar componentes de prateleira é a melhor decisão de engenharia de software.
|
Test your knowledge about the 5 seeing habits discussed in the text 'UPS 5 seeing habits'.