ES1-Cap3-Modelos de Processos de SW,r2 (10p) (1)

Prévia do material em texto

Prof. Ms. Eng. Edson Quedas Moreno. Engenharia de Software REPRODUÇÃO PROIBIDA 1 
 
 ENGENHARIA DE SOFTWARE I 
 
CAPÍTULO 3 – MODELOS DE PROCESSOS DE SOFTWARE, r2 
 
Sumário 
3.1 Modelo genérico de estrutura organizacional 
3.2 Modelo Cascata (Waterfall ou Sequencial Linear) 
3.3 Modelo Balburdia (Implementação/Implantação; Codifica/Remenda) 
3.4 Prototipagem 
3.4.1 Atividades da prototipação 
3.5 Modelo Incremental 
3.6 Modelo Espiral 
3.7 RAD (Rapid Application Development) 
 
 
3.1 MODELO DE ESTRUTURA ORGANIZACIONAL 
O processo é um diálogo no qual o conhecimento, que deve se transformar em 
software, é reunido e embutido no software (PRESSMAN, 2002). 
 
Quando se elabora um produto ou sistema é importante percorrer uma série de 
passos previsíveis, o Ciclo de Vida do Desenvolvimento de Sistema (System 
Development Life Cycle – SDLC) visto na figura abaixo. Um roteiro que ajuda a criar a 
tempo um resultado de alta qualidade. Os Modelos de Processos de Software englobam 
um conjunto de atividades, métodos, práticas e transformações empregadas no 
desenvolvimento e manutenção de software. Fornecem estabilidade, controle e 
organização para as atividades. Se deixadas sem controle, tornam-se bastante caótica. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
PLANEJAMENTO 
 
ANÁLISE 
 
IMPLEMENTAÇÃO 
 
Nesta fase são levantados os Requisitos do Software com base nas 
arguições sobre os negócios, necessidades dos clientes e usuários e 
restrições do sistema. 
Partindo do levantamento dos requisitos do software, à análise consiste em 
coletar dados, especificar os requisitos, determinar as atividades do 
desenvolvimento do software, medir o escopo do sistema e avaliar a relação 
custo/benefício. 
No projeto usa-se a Engenharia de Software para escolher metodologias, 
procedimentos e técnicas apropriadas para o controle e operacionalização 
do sistema e que atendam os requisitos do software. Criam-se diagramas 
de entidades e relacionamento dos dados com base em protótipos, 
normalmente desenvolvidos em UML. O desenvolvimento do software 
ocorre na sequência, onde são definidas técnicas de programação, 
linguagens associadas e formas de testar e diagnosticar os programas. 
 
A implementação aborda a entrega, manutenção, treinamento e suporte 
técnico aos usuários. A fase de desenvolvimento normalmente realiza 90% 
do software e os outros 10% são desenvolvidos durante a implementação. 
Mas o fato é que os 90% previsíveis ocupam a metade do tempo total para a 
finalização do software, ou seja, a outra metade é ocupada na 
implementação. Novos problemas não previstos surgem: correções, mudança 
de requisitos e melhorias no software. 
 
 
PROJETO 
 
 
 
 
Prof. Ms. Eng. Edson Quedas Moreno. Engenharia de Software REPRODUÇÃO PROIBIDA 2 
 
 
3.2 MODELO CASCATA (WATERFALL OU SEQUENCIAL LINEAR) 
O Modelo Cascata foi o primeiro modelo publicado do processo de desenvolvimento 
do software, originário de outros processos da engenharia de sistemas, é considerado o 
modelo clássico do ciclo de vida de desenvolvimento do software, se dá de forma 
sequencial encadeada e reflete as atividades fundamentais do desenvolvimento 
(PRESSMAN, 2011). 
 
O Modelo Cascata apresentado na Figura abaixo, mostra que as principais atividades 
são organizadas no formato de uma cascata. 
Só após a última atividade, que é a de Operação e Manutenção é feita a entrega do 
sistema ao cliente. O cliente e desenvolvedor revisam o software ou sistema. 
Figura: Modelo Cascata para o desenvolvimento do software. 
 
Fonte: SOMERVILLE (2003); PRESSMAN (2002) (2007) (2011). 
 
Abaixo são descritos os conceitos sobre as atividades do Modelo Cascata: 
1. Definição dos requisitos – são determinadas as funcionalidades, restrições e 
objetivos do sistema. Estabelecidas com base na comunicação com o cliente e 
usuários do sistema. E em seguida são definidos em detalhes e servem como 
especificação do sistema. 
2. Projeto de sistemas e de software – Este processo agrupa os requisitos em 
sistemas de software e/ou hardware. Define a arquitetura do sistema. 
3. Implementação e teste de unidades – Verifica se cada unidade atende as 
especificações. 
4. Integração e testes de sistemas – As unidades são integradas e testadas como 
um sistema completo. Depois dos testes, o software é entregue ao cliente. 
5. Operação e manutenção – Esta é a fase mais longa do ciclo de vida do software. 
O sistema é instalado e colocado em operação e novos problemas surgem. A 
manutenção procura corrigir erros que não foram identificados anteriormente, 
melhora a interface, aumenta as funções do sistema e novos requisitos são 
descobertos. 
 
 
 
 
Prof. Ms. Eng. Edson Quedas Moreno. Engenharia de Software REPRODUÇÃO PROIBIDA 3 
 
Apesar do Modelo Cascata servir de base para outros modelos, a vantagem do 
Modelo Cascata está nas aplicações com sistemas estruturados, que são sistemas 
únicos e que operam em um ambiente operacional restrito, porém de alta capacidade. 
Outra vantagem é ser aplicado em problemas complexos, ou ainda difíceis de resolver por 
incluir vários componentes. 
 
A desvantagem do Modelo Cascata é ser inflexível na divisão do projeto em estágios 
distintos. Na prática, é impossível se conseguir a totalidade dos requisitos em um 
momento inicial do projeto, e qualquer problema que ocorra em uma das fases só poderá 
ser detectado após a entrega do software para o cliente, gerando retrabalhos ou até 
mesmo a extinção do projeto. 
A visão do Modelo Cascata é de alto nível e não reflete o modo de como o software é 
desenvolvido. Mudanças no software durante o desenvolvimento não são apreciáveis e 
consequentemente não são sugeridas para projetos orientados a objeto. 
 
 
3.3 Modelo Balbúrdia (Codifica/Corrige ou Codifica/Remenda) 
No modelo Balbúrdia que também é conhecido como Codifica/Corrige ou 
Codifica/Remenda, apresentado na Figura abaixo, mostra que o software é construído 
sem nenhum tipo de projeto ou documentação. Normalmente é encontrado em 
organizações que são administradas por crises, em que não há planejamento, nem 
controle com relação aos possíveis riscos. Neste modelo só existem duas fases: 
Codificação e Correção (ou remenda). 
 
Neste modelo ocorrem várias mudanças que levam sempre a novas implementações, 
fazendo com que o software fique cada vez mais longe da maturidade. Este modelo é 
caracterizado pela administração do caos, pela informalidade, pelo loop de gestão 
Codifica/Corrige, em que o planejamento, requisitos do software, modelagem e 
documentação são caóticos ou até mesmo inexistentes. 
Figura: Modelo de processo de software Bálburdia. 
 
Fonte: MORENO (2020). 
 
3.4 PROTOTIPAGEM 
A Figura abaixo mostra uma maquete em escala reduzida da arquitetura de uma obra. 
A Prototipagem tem o mesmo objetivo da maquete. Antes da entrega final do sistema 
são desenvolvidos protótipos apresentados em um esboço, para melhorar o entendimento 
de desenvolvedores e clientes, sobre as possíveis problemáticas que possam surgir. 
 
 
 
Prof. Ms. Eng. Edson Quedas Moreno. Engenharia de Software REPRODUÇÃO PROIBIDA 4 
 
Figura: Maquete produzida para uma obra construída pela arquitetura em escala menor. 
 
 
 
 
A prototipagem pode ser classificada de acordo com uma variedade de dimensões. A 
abordagem de prototipação tem um número de vantagens importantes a oferecer, das 
quais são: 
 Primeira abordagem – todos os requisitos do sistema não necessitam de 
determinação completa e antecipada, podendo estes serem alvo de trocas ainda 
durante o curso do projeto. 
 Segunda abordagem – a entrega da prototipação concisa deve conter definições 
do sistema e especificações para o usuário final. Como consequência,o 
envolvimento e a satisfação do usuário final são fortemente aumentados. 
 Última abordagem – a prototipação possibilita testar rapidamente o ambiente de 
desenvolvimento voltado para a funcionalidade, desempenho e interface de dados. 
 
Dentro dessa visão, o projeto passa por várias investigações para garantir que o 
desenvolvedor, usuário e cliente cheguem a um consenso sobre o que é necessário e o 
que deve ser proposto. Como muitos usuários não possuem uma visão ampla sobre a 
tecnologia, esse método de desenvolvimento é bastante interessante, permitindo que o 
usuário interaja significativamente no sistema. 
 
 
 
3.4.1 Atividades da Prototipagem: 
As atividades da prototipagem são determinadas a partir do paradigma de 
prototipagem, apresentado por Pressman (2002), como é mostrado na Figura abaixo, que 
por sua vez, é um procedimento a ser seguido pelo engenheiro de software. 
 
 
 
 
 
Prof. Ms. Eng. Edson Quedas Moreno. Engenharia de Software REPRODUÇÃO PROIBIDA 5 
 
Figura: O paradigma de prototipagem. 
 
Fonte: PRESSMAN (2002). 
 
Ciclo de atividades da prototipagem se baseia em três etapas: 
1. Começar com um conjunto bem simples de requisitos fornecidos pelos clientes e 
usuários. 
2. Clientes e usuários fazem testes e experimentações, e assim que eles decidem o 
que querem, os requisitos são revisados, alterados, detalhados, documentados e o 
sistema passa a ser codificado. 
3. Novamente as alternativas são apresentadas e discutidas com os usuários, e volta 
para a etapa 2, até a entrega definitiva do sistema. 
 
Vantagens da prototipagem: 
 A prototipagem é um ciclo de vida eficiente, que possibilita ao desenvolvedor criar o 
modelo do software que será construído. 
 Apropriado para quando o cliente definiu os objetivos do software, mas não 
identificou detalhes dos requisitos de entrada, processamento e saídas. 
 A prototipagem é útil para identificar os requisitos do software. É um processo que 
possibilita ao desenvolvedor, cliente e usuário a examinarem antecipadamente os 
requisitos, reduzindo os riscos e incertezas do desenvolvimento. A chave é definir 
as regras do jogo logo no começo. 
 Velocidade de desenvolvimento no sentido de propiciar ao usuário uma visão mais 
real do software que se está projetando (o usuário pode “enxergar” telas e 
relatórios resultantes do software). 
 Envolvimento direto do usuário à medida que o software é desenvolvido. O usuário 
passa a ser um coautor do desenvolvimento. 
 
Desvantagens da prototipagem: 
 O caso em que cliente não sabe que o software que está testando ainda não foi 
concluído e não o considera no desenvolvimento, a qualidade global e a 
manutenibilidade ao longo da operacionalização do software. 
 
 
 
Prof. Ms. Eng. Edson Quedas Moreno. Engenharia de Software REPRODUÇÃO PROIBIDA 6 
 
 A prototipação pode dar ao usuário a impressão que praticamente qualquer 
sugestão pode ser implementada, de modo a não importar qual estágio do 
processo de desenvolvimento está em andamento. Além disso, para os usuários 
não fica claro o porquê da demora em entregar a aplicação final, depois que uma 
versão demo do sistema foi exibida. A cliente então não aceita bem a ideia de que 
a versão final do software ainda será construída e, por conseguinte, “força” a 
utilização do protótipo como produto final. 
 
 
3.5 MODELO INCREMENTAL 
 
O modelo de processo Incremental (Figura abaixo) aplica sequências lineares dos 
elementos do Modelo Cascata e aplica de forma evolucionária incrementos com base no 
prazo de entrega, aprovação e validação. O modelo de processo Incremental é iterativo e 
tem como objetivo apresentar um produto operacional a cada incremento realizado, ou 
seja, é desenvolvido com o conceito de versões. 
 
Iteração é uma estratégia de planejamento para retrabalhar o processo, revisar 
tempos, comentar falhas, erros e tecnologia, melhorar o sistema e distribuir tarefas. A 
cada iteração são geradas novas versões, que são os registros de acompanhamento das 
mudanças no software até o release que é o registro da versão que é liberada para o 
usuário. As iterações do processo são necessárias para a melhoria contínua do processo 
de desenvolvimento do software. 
Figura: Modelo de processo incremental. 
 
Fonte: PRESSMAN, 2007 (adaptado). 
Na prática o usuário quer sempre o sistema para ontem, e com qualidade. O Modelo 
Incremental parte do princípio que é preferível o usuário receber o sistema em partes, 
permitindo assim que esses recursos já possam ser utilizados, enquanto que os demais 
estão em desenvolvimento. 
 
 
 
 
Prof. Ms. Eng. Edson Quedas Moreno. Engenharia de Software REPRODUÇÃO PROIBIDA 7 
 
O modelo de processo Incremental é desenvolvido com o conceito de versões. Nesse 
modelo o sistema será especificado na documentação dos requisitos, e “quebrado” em 
subsistemas por funcionalidades. As versões são definidas, começando com um pequeno 
subsistema funcional e então adicionadas mais funcionalidades a cada versão. Pode-se 
então dizer que o Modelo Incremental chega lentamente à funcionalidade total, por meio 
dessas novas versões. 
 
 
3.6 MODELO ESPIRAL 
 
O Modelo Espiral é um modelo evolucionário que combina a natureza iterativa da 
prototipagem com o estilo clássico do modelo cascata. 
 
A Figura abaixo mostra o modelo Espiral, em que o software é desenvolvido em uma 
série de versões evolucionárias e em cada ciclo da espiral é definido um conjunto de 
atividades de arcabouço que depois de completada a espiral, um release é definido e 
após várias iterações o software atinge sua totalidade. 
 
Figura: Modelo de processo Espiral. 
 
Fonte: PFLEEGER (2004) 
 
 
O modelo espiral é mais adequado para sistemas complexos, software de grande 
porte e que exigem um alto nível de iterações com os usuários, o que possibilita uma 
melhor abordagem de todos os problemas do sistema. 
 
 
 
 
 
Prof. Ms. Eng. Edson Quedas Moreno. Engenharia de Software REPRODUÇÃO PROIBIDA 8 
 
O Modelo Espiral basicamente é dividido em quatro etapas: 
 Ativação: Definem-se os objetivos específicos, identificam-se as restrições para o 
processo e é preparado um plano de gerenciamento detalhado. Identificam-se 
também os riscos sem os analisar profundamente (foco da próxima fase). 
 Análise de riscos e prototipagem: Com base nos riscos identificados na fase 
anterior são realizadas análises detalhadas, e tomadas providências para amenizar 
esses riscos. Criam-se várias versões de protótipos para apoiar essa fase. 
 Desenvolvimento: Fundamentado pelas fases anteriores escolhe-se o modelo 
mais adequado para o desenvolvimento do Sistema. A bagagem profissional e a 
vivência do desenvolvedor em outros sistemas, são estratégicas para essa fase. 
Dependendo da complexidade do Sistema, as vezes, é necessária a presença de 
um consultor especialista. 
 Planejamento: O projeto é revisto nessa fase e é tomada uma decisão de realizar 
um novo ciclo, na espiral ou não. Se continuar com o aperfeiçoamento do Sistema, 
é traçado um plano para a próxima fase do projeto. Um diferencial nesse modelo 
comparado com outros, é a explícita consideração de riscos dentro do projeto como 
um todo. Para tanto, criou-se uma fase específica de Análise de Riscos nesse 
modelo. 
 
 
3.7 RAD (Rapid Application Development) 
Outros modelos se apresentam com grande utilidade. Alguns não deixam de ser a 
combinação de outros modelos, integrando dois ou mais conceitos de outros modelos. 
Um deles é o modelo RAD - Rapid Application Development (Desenvolvimento 
Rápido de Aplicações), considerado um modelo misto e de características genéricas, é 
um modelo amplamente utilizado. 
 
O modelo de processoRAD permite que uma equipe crie um sistema plenamente 
funcional, dentro de um curto período. “O modelo RAD é um processo de software 
incremental que enfatiza um ciclo de desenvolvimento curto (PRESSMAN, 2002)”. 
RAD é uma abordagem para desenvolvimento de software com objetivo de entregar 
software rapidamente. Comumente envolve o uso de ferramentas de programação de 
banco de dados e de apoio ao desenvolvimento, como geradores de telas e relatórios 
(SOMMERVILLE, 2011). 
 
A estratégia para isso é o uso da abordagem de construção baseada em 
componentes. Com isso o desenvolvimento completo de um sistema, de relativa 
complexidade (observe a Figura abaixo), chega a atingir 60 a 90 dias. 
 
 
 
 
 
 
Prof. Ms. Eng. Edson Quedas Moreno. Engenharia de Software REPRODUÇÃO PROIBIDA 9 
 
Figura: Modelo RAD. 
 
Fonte: PRESSMAN, 2007 (adaptado). 
 
Vantagens do modelo RAD: 
 RAD é um modelo sequencial linear que enfatiza um ciclo de desenvolvimento 
extremamente curto. Entregas pequenas, entre 60 e 90 dias. 
 O desenvolvimento rápido é obtido usando uma abordagem modularizada e de 
construção baseada em componentes. Este processo traz facilidades: de 
gerenciamento e de encontrar desvios no escopo. 
 Os requisitos devem ser suficientes para alcançar o projeto restrito. 
 O modelo RAD é usado principalmente para aplicações de sistema de informação 
grandes e modularizados. 
 Cada módulo ou função principal pode ser direcionada para uma equipe RAD 
separada e então integrada para formar o todo. Observe a Figura 29. 
 Visibilidade ao projeto – o cliente percebe pequenas entregas 
 
Desvantagens do modelo RAD: 
 Ressalta-se nesse modelo que se o sistema não for adequadamente modularizado, 
a construção de componentes necessários ao RAD será problemática. 
 O RAD pode não ser adequado quando os riscos técnicos são altos, por exemplo, 
se existir a necessidade de uma aplicação usufruir tecnologias novas não 
dominadas pela equipe. 
 Exige recursos humanos suficientes para todas as equipes 
 Exige que desenvolvedores e clientes estejam comprometidos com as atividades 
de “fogo-rápido” a fim de terminar o projeto num prazo curto 
 
 
 
Prof. Ms. Eng. Edson Quedas Moreno. Engenharia de Software REPRODUÇÃO PROIBIDA 10 
 
 Nem todos os tipos de aplicação são apropriados para o RAD. 
 Deve ser possível a modularização efetiva da aplicação. Se alto desempenho é 
uma característica do RAD e o desempenho do sistema estiver ligado ao 
sincronismo das interfaces dos componentes, a abordagem RAD pode não 
funcionar. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
BIBLIOGRAFIA 
PRESSMAN, Ph.D. Roger S. Engenharia de Software. – 5a ed. Rio de Janeiro: McGraw-Hill, 2002. 
PRESSMAN, Ph.D. Roger S. Engenharia de Software. – 6a ed. Rio de Janeiro: McGraw-Hill, 2007. 
PFLEEGER, Shari Lawrence. Engenharia de Software. – 2a ed. São Paulo: Prentice Hall, 2004. 
ROCHA, Roberto dos Santos. Modelagem do processo de desenvolvimento e manutenção de 
software para a UINFOR/UESB. Bahia: UINFOR/UESB, 2006. Artigo. 
SOMMERVILLE, Ian. Engenharia de software. São Paulo: Pearson Addison Wesley, 2003.