São modelos que consideram a natureza evolutiva do software. Os modelos evolucionários são iterativos. São implementados de forma a permitir o desenvolvimento de versões cada vez mais completas do software. Suas características incluem:
- São usados quando o deadline (limite de tempo) não é adequado para o desenvolvimento do software, ou seja, a data de término não é realística (por exemplo, prazos reduzidos de mercado por causa da competitividade).
- Uma versão limitada pode ser introduzida para atender a essa competitividade e às pressões do negócio.
- São liberados produtos core (núcleo dos produtos) ao longo do desenvolvimento.
- Os detalhes e extensões do projeto são definidos ao longo do desenvolvimento.
Os modelos que são agrupados nesta categoria são: Prototipação, Modelo Espiral e Modelo Concorrente, que são apresentados a seguir.
Prototipação
É um modelo de processo que possibilita que o desenvolvedor crie um modelo do software que deve ser construído. Idealmente, o modelo (protótipo) serve como um mecanismo para identificar os requisitos do software. É apropriado para quando o cliente definiu um conjunto de objetivos gerais para o software, mas não identificou requisitos de entrada, processamento e saída com detalhes.
Envolve o desenvolvimento de uma versão inicial do sistema baseada no atendimento dos requisitos ainda pouco definidos. Este processo permite a descoberta de falhas difíceis de serem encontradas na comunicação verbal, servindo de apoio à fase de levantamento de requisitos prevenindo as possíveis falhas no sistema.
O objetivo principal de um protótipo é simular a aparência e funcionalidade do software, permitindo que os clientes, analistas, desenvolvedores e gerentes compreendam plenamente os requisitos do sistema interagindo, avaliando, alterando e aprovando as características mais relevantes que o produto deve ter. A figura ilustra este processo.
Certamente a redução de custos no desenvolvimento é um dos grandes ganhos da prototipação, pois envolve diretamente o usuário final permitindo um desenvolvimento mais próximo dos desejos do cliente e priorizando a facilidade de uso. Assim, pode-se obter um nível de satisfação maior em função do menor número de erros ou falhas de desenvolvimento comuns na passagem de informação entre o analista (que fez o levantamento de requisitos) e o desenvolvedor (equipe de desenvolvimento).
Um dos riscos envolvidos neste modelo é o descomprometimento com a análise do produto, visto que os envolvidos podem se apoiar totalmente no modelo prototipado gerando uma expectativa muitas vezes irrealista de desempenho, em função do protótipo ser muito mais enxuto do que o produto final e estar em um ambiente controlado.
Além disso, o cliente não sabe que o software que ele vê não considerou, durante o desenvolvimento, a qualidade global e a manutenibilidade em longo prazo. Ele pode, também, não aceitar facilmente a ideia de que a versão final do software está sendo construída e tentar forçar a utilização do protótipo como produto final.
Outro risco deste modelo é que o desenvolvedor frequentemente faz uma implementação comprometida (utilizando partes de programas existentes, geradores de relatórios, geradores de janelas) com o objetivo de produzir rapidamente um protótipo executável. Depois de um tempo ele se familiariza com essas escolhas, e pode se esquecer que elas não são apropriadas para o produto final.
Embora não seja livre de problemas, a prototipação é um modelo eficiente, pois cada protótipo é construído a partir de um acordo entre o cliente e o desenvolvedor. Deve estar claro para ambos que o protótipo é utilizado como um mecanismo que permite a definição dos requisitos do projeto. A figura traz outra visão deste processo.
Outra visão do Modelo de Prototipação.
Fonte: www.ebah.com.br
Modelo Espiral
O modelo espiral foi desenvolvido para abranger as melhores características do Modelo em Cascata e da Prototipação, acrescentando, ao mesmo tempo, um novo elemento: a análise de riscos. Foi desenvolvido por Barry Boehm (1988) em seu artigo intitulado “A Spiral Model of Software Development and Enhancement”. Este modelo foi o primeiro a explicar o porquê do modo iterativo e elencar suas vantagens.
As iterações têm uma duração típica de seis meses a dois anos. Cada fase inicia-se com um objetivo esperado e termina como uma revisão, pelo cliente, do progresso (que deve ser interna) e assim por diante. Esforços de análise e engenharia são aplicados em cada fase do projeto, tendo sempre o foco no objetivo do projeto. A figura ilustra este processo.
As principais características deste modelo são:
- Engloba a natureza iterativa da Prototipação com os aspectos sistemáticos e controlados do Modelo em Cascata;
- Fornece potencial para o desenvolvimento rápido de versões incrementais do software;
- O processo se inicia com a equipe de desenvolvimento movendo-se em volta da espiral, no sentido horário, a partir do centro;
- O primeiro circuito em torno da espiral pode resultar na especificação do produto;
- Nas primeiras iterações, a versão incremental pode ser um modelo em papel ou um protótipo;
- Nas iterações mais adiantadas são produzidas versões incrementais mais completas e melhoradas.
É uma abordagem realística para o desenvolvimento de software de grande porte. Como o software evolui na medida em que o processo avança, o cliente e o desenvolvedor entendem melhor e reagem aos riscos em cada nível evolucionário. Para pequenos projetos, os conceitos de desenvolvimento de software ágil tornam-se uma alternativa mais viável.
Como vantagens deste modelo, podemos citar: estimativas realísticas dadas à identificação de problemas importantes logo no início do processo; versatilidade para lidar com mudanças (quando inevitáveis); desenvolvimento antecipado por parte dos engenheiros de software, que têm visibilidade das necessidades por fases; e uso da prototipagem (em qualquer estágio de evolução do produto) como mecanismo de redução de risco.
No entanto, o uso do modelo Espiral exige considerável experiência na determinação de riscos e depende dessa experiência para ter sucesso. Além disso, pode ser difícil convencer os clientes que uma abordagem “evolutiva” é controlável.
Modelo de Processo Concorrente
De acordo com Pressman (2011, p. 67), o modelo de Desenvolvimento Concorrente, também chamado de Engenharia Concorrente, pode ser representado, esquematicamente, como uma série de atividades de arcabouço, ações e tarefas da Engenharia de Software e seus estados associados.
Um exemplo do uso deste modelo pode ver visto na figura. A figura traz a atividade “Modelagem” do modelo Espiral (mostrado na figura anterior), espelhada no modelo Concorrente.
No modelo Concorrente, uma atividade pode estar em qualquer um dos estados apresentados na figura 17 (em desenvolvimento, sob inspeção ou em exame, aguardando modificações etc.) a qualquer tempo. O modelo define uma série de eventos que vão disparar transições de um estado para outro, para cada uma das atividades, ações ou tarefas da Engenharia de Software. Por exemplo, suponha que durante os estágios da etapa de projeto, descobre-se uma inconsistência no modelo de análise. Isso geraria o evento “correção no modelo de análise”, que, por sua vez, implicaria na passagem da atividade de análise do estado “pronto” para o estado “aguardando modificações”.
De forma geral, as principais características deste modelo são:
- Todas as atividades ocorrem em paralelo, mas estão em diferentes estados;
- O modelo define uma série de eventos que vão disparar transições de estado para estado, para cada uma das atividades;
- Em vez de usar uma sequência como o modelo em cascata, ele define uma rede de atividades;
- Eventos gerados dentro de certa atividade ou em algum outro lugar da rede de atividades disparam transições entre estados de uma atividade;
- Pode ser aplicado a todo tipo de desenvolvimento de software e fornece uma visão exata de como está o estado do projeto;
- Em vários projetos pode existir uma simultaneidade (concorrência) entre as várias atividades de desenvolvimento e de gestão de projetos;
- É representado como uma série de grandes atividades técnicas, tarefas e seus estados associados (fornece um panorama preciso do estado atual do projeto).
Nenhum comentário:
Postar um comentário