Baixe o app para aproveitar ainda mais
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
Compartilhar