Aula 2 - Modelos de processos de software

Prévia do material em texto

Modelo de processos de software
(Modelo de ciclo de vida de software)
Codifica-remenda: trata-se do ciclo de vida mais caótico existente. Nele, com apenas a
especificação (ou às vezes nem isso), os desenvolvedores começam imediatamente a codificar,
remendando à medida que os erros vão aparecendo. Nenhum processo de desenvolvimento é
seguido. É um dos ciclos de vida mais utilizado. Para muitos esse modelo é atraente porque não
exige nenhuma sofisticação técnica ou gerencial. Possui alto risco, impossível de gerir ou prever
qualquer passo confiável.
Cascata: Os processos são executados em uma estrita sequência, o que permite demarcá-los com
pontos de controle bem-definidos. Desta forma, com esses pontos de controle a gestão fica
facilitada, o que faz do modelo, um modelo confiável e utilizado em projetos de qualquer escala.
Agora, se interpretado de forme literal, é um processo rígido e burocrático onde o modelo em
cascata é de baixa visibilidade para o cliente, que só recebe o resultado final do projeto. As suas
principais características são:
- Sequência rígida de processos
- Especificação de pontos de controle
- Rígido e burocrático
- Não são permitidos erros nas fases que o compõem
- Baixa visibilidade para o cliente
- O cliente deve ter paciência, pois a implementação se iniciará mais tarde.
O Modelo RAD
O Rapid Application Development (RAD) é um modelo de processo de software
incremental que enfatiza um ciclo de desenvolvimento curto. O Modelo RAD é uma adaptação, de
alta velocidade, do modelo em cascata, no qual a agilidade é conseguida com o uso de uma
abordagem de construção baseada em componentes.
Porém o processo RAD necessita que os requisitos sejam bem compreendidos e o objetivo
do projeto seja restrito, para garantir o sucesso do projeto.
A figura abaixo ilustra o Modelo RAD. As etapas do Modelo RAD apresentam as seguintes
definições:
• comunicação: trabalha para entender os problemas do negócio e as características de
informação que o software precisa acomodar;
• planejamento: o planejamento é essencial, porque várias equipes de software trabalham em
paralelo em diferentes funções do sistema;
• modelagem: abrange três das principais fases: modelagem do negócio, modelagem dos
dados e modelagem dos processo. Também estabelece representações de projeto que servem
como base para a atividade de construção do RAD;
• construção: enfatiza o uso de componentes de software preexistentes e a aplicação da
geração automática de código;
• implantação: estabelece a base para iterações subsequentes, se necessárias.
Entre as desvantagens do Modelo RAD, considera-se:
• para projetos grandes, mas passíveis de sofrer aumento, o RAD exige recursos humanos
suficientes para criar um número adequado de equipes;
• se desenvolvedores e clientes não estiverem comprometidos com as atividades os projetos
RAD falharão;
• se o sistema não puder ser adequadamente modularizado, a construção dos componentes
será problemática;
• se for necessário ajustes nas interfaces dos componentes do sistema, a abordagem RAD
pode não funcionar;
• o RAD pode não ser adequado quando os riscos técnicos são altos.
Entre as vantagens, temos:
• Permite o desenvolvimento rápido e/ou a prototipagem de aplicações;
• Enfatiza um ciclo de desenvolvimento extremamente curto (entre 60 e 90 dias);
• Cada função principal pode ser direcionada para a uma equipe RAD separada e então
integrada a formar um todo;
• Criação e reutilização de componentes;
• Usado principalmente para aplicações de sistemas de informações;
• Desenvolvimento é conduzido em um nível mais alto de abstração;
• Visibilidade mais cedo (protótipos);
• Envolvimento maior do usuário
 
Modelo de Prototipação
• O objetivo é entender os requisitos do usuário e, assim, obter uma melhor definição dos
requisitos do sistema;
• Possibilita que o desenvolvedor crie um modelo (protótipo) do software que deve ser
construído;
• É apropriado para quando o cliente não definiu detalhadamente os requisitos
Fases do modelo de Prototipação
1 Obtenção dos requisitos: Desenvolvedor e cliente definem os objetivos gerais do
software, identificam quais requisitos são conhecidos e as áreas que necessitam de definições
adicionais;
2- Projeto rápido: Representação dos aspectos do software que são visíveis ao usuário
(abordagens de entrada e formatos de saída)
3- Construção do protótipo: Implementação rápida do projeto
4- Avaliação do protótipo: cliente e desenvolvedor avaliem o protótipo.
5- Refinamento do protótipo: cliente e desenvolvedor refinam os requisitos do software a
ser desenvolvido.
6- Construção do Produto: identificados os requisitos, o protótipo deve ser descartado e a
versão de produção deve ser construída considerando os critérios de qualidade.
Modelo Espiral
O produto é desenvolvido em uma série de iterações. Cada nova iteração corresponde a uma
volta na espiral. Isso permite construir produtos em prazos curtos, com novas características e
recursos que são agregados à medida que a experiência descobre sua necessidade. As atividades de
manutenção são usadas para identificar problemas; seus registros fornecem dados para definir os
requisitos das próximas liberações. O principal problema do ciclo de vida em espiral é que ele
requer gestão muito sofisticada para ser previsível e confiável. 
O modelo espiral acopla a natureza iterativa da prototipação com os aspectos controlados e
sistemáticos do modelo cascata.
O modelo espiral é dividido em uma série de atividades de trabalho ou regiões de tarefa.
Cada loop no espiral representa uma fase do processo de software. O loop mais interno está
concentrado nas possibilidades do sistema; o próximo loop está concentrado na definição dos
requisitos do sistema; o loop um pouco mais externo está concentrado no projeto do sistema e; o
loop ainda mais externo está concentrado na construção do sistema.
Colocação de objetivos: são definidos objetivos específicos para a fase do projeto; são
identificadas restrições sobre o processo e o produto; é projetado um plano de gerenciamento
detalhado; são identificados riscos do projeto; dependendo dos riscos, estratégias alternativas
podem ser planejadas.
Avaliação e redução de riscos: para cada um dos riscos identificados, uma análise
detalhada é executada. Passos são tomados para reduzir o risco.
Desenvolvimento e validação: após a avaliação do risco, um modelo de desenvolvimento é
escolhido para o sistema.
Planejamento: o projeto é revisto e é tomada uma decisão de continuidade. Se for decidido
continuar, são projetados planos para a próxima fase do projeto (próximo loop).
Processo Unificado
É um processo de software: conjunto de atividades executadas para transforma um conjunto
de requisitos do cliente em um sistema de software.
É um framework que pode ser personalizado de acordo com as necessidades específicas e
recursos disponíveis para cada projeto.
Elementos do Processo Unificado:
Papel (quem) – um trabalhador é alguém que desempenha um papel e é repsonsável pela
realização de atividades para produzir ou modificar um artefato
O que (artefato) – Porção significativa de informação internet ou a ser fornecida a
interessados externos que desempenhe um papel no desenvolvimento do sistema. Um artefato é
algum documento, relatório, modelo ou código que é produzido, manipulado ou consumido.
como (atividade) – É uma tarefa que um trabalhador executa a fim de produzir ou modificar
um artefato.
quando (disciplina) – Descreve as sequências das atividades queproduzem algum resultado
significativo e mostra as interações entre os participantes. São realizadas a qualquer momento
durante o ciclo de desenvolvimento.
Princípios Básicos do Processo Unificado
Desenvolvimento iterativo – O desenvolvimento de um software é dividido em vários
ciclos de iteração, cada qual produzindo um sistema testado, integrado e executável. Em cada ciclo
ocorrem as atividades de análise de requisitos, projeto, implementação e teste, bem como a
integração dos artefatos produzidos com os artefatos já existentes.
Baseado em casos de uso – Um caso de uso é uma sequência de ações, executadas por um
ou mais atores e pelo próprio sistema, que produz um ou mais resultados de valor para um ou mais
atores. O Processo Unificado é dirigido por casos de uso, pois os utiliza para dirigir todo o trabalho
de desenvolvimento, desde a captação inicial e negociação dos requisitos até a aceitação do código.
Centrado na arquitetura – Arquitetura é a organização fundamental do sistema com oum
todo. Inclui elementos estáticos, dinâmicos, o modo como trabalham juntos e o estilo arquitetônico
total que guia a organização do sistema. No Processo Unificado, a arquitetura do sistema em
construção é o alicerce fundamental sobre o qual ele se erguerá. A arquitetura, juntamente com os
casos de uso, deve orientar a exploração de todos os aspectos do sistema.
Fases do Processo Unificado
Concepção: Estabelece-se a viabilidade de implantação do sistema; Define o escopo do
sistema, Estimativas de custos e cronograma; Identificação dos potenciais riscos que devem ser
gerenciados ao longo do projeto; Esboço da arquitetura do sistema, que servirá como alicerce para a
sua construção.
Elaboração: Visão refinada do sistema, com a definição dos requisitos funcionais,
detalhamento da arquitetura criada na fase anterior e gerenciamento contínuo dos riscos envolvidos.
Estimativas realistas feitas nesta fase permitem preparar um plano para orientar a construção do
sistema.
Construção: O sistema é efetivamente desenvolvido e, em geral, tem condições de ser
operado, mesmo que em ambiente de teste, pelos clientes.
Transição: O sistema é entregue ao cliente para uso em produção. Testes são realizados em
um ou mais incrementos do sistema são implantados. Defeitos são corrigidos, se necessário.
REFERÊNCIAS
https://engenhariasoftware.wordpress.com/2013/01/24/rapid-application-development-rad/
http://jkolb.com.br/o-modelo-rad/
https://www.inf.pucrs.br/~lleite/seII/material/ciclodevida.pdf
http://www.vqv.com.br/uneb/AnaliseSistemasII.pdf
https://edisciplinas.usp.br/pluginfile.php/839466/mod_resource/content/1/Aula02_ModelosProcesso
s.pdf