Modelo sequencial linear, prototipacao, rad - Leandro A Zardo

Prévia do material em texto

‘ 
CÂMPUS VERANÓPOLIS 
ANÁLISE E DESENVOLVIMENTO DE SISTEMAS 
ENGENHARIA DE SOFTWARE I 
IV SEMESTRE 
 
 
 
 
LEANDRO ANTONIO ZARDO 
 
 
 
 
 
 
 
 
MODELO SEQUENCIAL LINEAR (MODELO CASCATA) 
MODELO DE PROTOTIPAÇÃO 
MODELO RAD (RAPID APPLICATION DEVELOPMENT) 
 
 
 
 
 
 
 
 
VERANÓPOLIS 
2021 
2 
 
Sumário 
 
1 INTRODUÇÃO ........................................................................................................ 3 
2 MODELO SEQUENCIAL LINEAR (MODELO CASCATA) ................................... 4 
2.1 Vantagens ........................................................................................................ 4 
2.2 Desvantagens ............................................................................................... 5 
3 MODELO DE PROTOTIPAÇÃO ............................................................................ 6 
3.1 Vantagens ........................................................................................................ 7 
3.2 Desvantagens ................................................................................................ 7 
4 MODELO RAID ........................................................................................................ 8 
4.1 Vantagens ......................................................................................................... 8 
4.2 Desvantagens .............................................................................................. .8 
5 COMPARATIVO ....................................................................................................... 9 
6 CONCLUSÂO ..........................................................................................................10 
7 REFERÊNCIA BIBLIOGRÁFICAS ........................................................................11 
 
 
3 
 
1 INTRODUÇÃO 
 
 Um Modelo de Processo de Software ou Paradigmas de Processo é a 
representação genérica dos processos de desenvolvimento. Para desenvolver 
softwares em equipe de forma organizada é preciso seguir uma série de práticas e 
passos bem definidos, conhecidos como processos de software. 
4 
 
2 MODELO SEQUENCIAL LINEAR (MODELO CASCATA) 
 
 Considerado o modelo clássico de desenvolvimento, o Modelo em Cascata é 
sugerido para projetos pequenos e sua ideia defende que para uma fase iniciar, a 
anterior deve estar totalmente finalizada e que o resultado de cada etapa é a 
aprovação de um ou mais documentos assinados. 
 O desenvolvimento de software é dividido em cinco etapas, que começam 
assim que a anterior termina: 
Especificação: é feita a análise e captação das necessidades do cliente e definidos 
os requisitos do sistema com suas funcionalidades; 
Projeto do software: é elaborado o desenho da arquitetura geral do sistema, 
seguindo as informações coletadas na etapa anterior. Tudo é separado em partes 
chamadas de unidades de programa para poder agilizar o desenvolvimento. Cada 
unidade terá seu próprio requisito de unidade; 
Implementação: nesta etapa, com o projeto definido, cada unidade de programa é 
implementada, podendo alocar vários programadores simultaneamente. 
Teste unitário: no final da implementação, são feitos os testes de unidade para 
certificar (validação) que as implementações atendem aos requisitos de unidade; 
Integração: com as unidades testadas, a próxima tarefa é integrar todas elas para 
compor um sistema completo. 
Teste de Sistema: no final da integração, é feito um teste geral para certificar 
(validação) que os requisitos do sistema foram completamente atendidos. Por fim, o 
software é entregue ao cliente; 
Operação e manutenção: Ao operar, ou seja, utilizar o sistema, o cliente poderá 
encontrar erros ou necessidades que não foram identificadas anteriormente. Esta fase 
se responsabiliza pela correção dos erros ou melhorias do sistema (evolução). 
 
2.1 Vantagens 
 
• Por causa de sua natureza separada em unidades, o modelo em 
cascata possibilita a implementação concorrente entre vários programadores, 
agilizando a entrega; 
• É útil quando o pessoal envolvido no projeto é fraco tecnicamente. 
5 
 
• O modelo apresenta uma grande vantagem quando o escopo do trabalho é 
claramente definido. Se as especificações estiverem corretas (o que é muito difícil 
em projetos de médio e grande porte), um software pode ser desenvolvido de forma 
muito rápida. 
 
2.2 Desvantagens 
 
• Se a especificação não for bem definida, ele pode ser tornar um risco e um convite 
para falhas, o modelo se tratava era um conceito inicial e ainda defeituoso; 
• Como o modelo não possui flexibilidade, seguindo um sequencia engessada, é 
considerado um modelo frágil, principalmente nos dias de hoje que os projetos 
mudam muito no decorrer do desenvolvimento; 
• Também é difícil estabelecer explicitamente todos os requisitos logo o início do 
projeto, pois no começo, sempre existe uma incerteza natural; 
• O cliente deve ter muita paciência, pois uma versão executável do software só fica 
disponível numa etapa avançada do desenvolvimento; 
• Projetos grandes raramente seguem a sequência proposta pelo modelo. A 
produção e aprovação de documentos durante as etapas costumam se caras e 
geradoras de muito retrabalho; 
• Durante o processo, é comum o cliente solicitar o congelamento de partes do 
desenvolvimento para dar continuidade aos estágios posteriores, tornando a solução 
dos problemas mais difícil, pois acaba sendo programada para mais tarde e, 
dependendo da situação, acaba sendo parcial ou totalmente ignorada; 
• O congelamento prematuro de partes da implementação pode resultar em um 
sistema que não faça o que o usuário quer. Também pode levar a sistemas mal 
estruturados, quando os problemas de projeto são contornados por artifícios de 
implementação; 
• Nesse modelo os especialistas de um negócio conversam com os analistas, que 
passam o resultado para os programadores. No entanto, essa abordagem falha 
porque lhe falta feedback. Em outras palavras, o software resultante pode atender às 
necessidades do cliente, mas o código não reflete as regras de negócio, uma vez que 
os programadores só programam, não sendo possível identificar os termos de 
negócio olhando no código; 
6 
 
• A natureza linear do modelo leva a estados de bloqueio, nos quais alguns membros 
da equipe de projeto precisam esperar que outros membros completem as tarefas 
dependentes; 
 
 
3 MODELO DE PROTOTIPAÇÃO 
 
 Nesse modelo o desenvolvimento é feito obedecendo à realização das 
diferentes etapas de análise de requisitos, o projeto, a codificação e os testes. A 
definição de todos os requisitos necessários ao sistema pelo cliente ou usuário 
geralmente é uma tarefa muito difícil, sendo quase impossível prever como o sistema 
irá afetar o funcionamento das práticas de trabalho, como será a interação com outros 
sistemas e que operações dos usuários devem ser automatizadas. Mas para poder 
testar os requisitos de uma forma mais eficiente, seria necessária a utilização de um 
protótipo do sistema. 
 Um protótipo é uma versão inicial de um sistema de software, que é utilizada 
para mostrar conceitos, experimentar opções de projeto e, em geral, para conhecer 
mais sobre os problemas e suas possíveis soluções. O processo de desenvolvimento 
de um protótipo deve ser rápido para que seja essencial para que os custos sejam 
controlados e os usuários possam fazer experiências com o protótipo no início do 
processo de software. 
 Um modelo de prototipação de software apoia duas atividades do processo de 
engenharia de requisitos: 
• Levantamento de requisitos - Os protótipos de sistema permitem que os usuários 
realizem experiências para ver como o sistema apoia seu trabalho. Eles obtêm novas 
ideias para os requisitos e podem identificar pontos positivos e negativos do software. 
Eles podem, então, propor novos requisitos de sistema. 
• Validação de requisitos -O protótipo pode revelar erros e omissões nos requisitos 
propostos. Uma função descrita em uma especificação pode parecer útil e bem-
definida. Contudo, quando essa função é utilizada com outras, os usuários muitas 
vezes acham que sua visão inicial era incorreta e incompleta. A especificação de 
sistema pode então ser modificada para refletir sua compreensão alterada dos 
requisitos. 
7 
 
 Na maioria dos projetos, o primeiro sistema construído dificilmente será usável. 
Podendo ser muito lento, muito grande, desajeitado em uso, ou todos os três. A 
questão administrativa, não é se deve construir um sistema-piloto e jogá-lo fora. Isso 
será feito. A única questão é se deve planejar antecipadamente a construção de algo 
que se vai jogar fora ou prometer entregar isso aos clientes. O protótipo pode ser 
oferecido ao cliente em diferentes formas: protótipo em papel, modelo executável em 
computador retratando a interface homem-máquina capacitando o cliente a 
compreender a forma de interação com o software; protótipo de trabalho que 
implemente um subconjunto dos requisitos indicados; programa existente que permita 
representar toda ou parte das funções desejadas para o software a construir 
 
3.1 Vantagens: 
 
• Modelo de desenvolvimento interessante para alguns sistemas de grande porte 
que representem um certo grau de dificuldade para exprimir rigorosamente os 
requisitos 
• É possível demonstrar a irrealizabilidades através da construção de um protótipo 
do sistema; 
• É possível obter uma versão, mesmo simplificada do que será o sistema, com um 
pequeno investimento inicial; 
• A experiência adquirida no desenvolvimento do protótipo vai ser de extrema 
utilidade nas etapas posteriores do desenvolvimento do sistema real, permitindo 
reduzir o seu custo e resultando num sistema melhor concebido. 
 
3.2 Desvantagens: 
 
• Quando informamos que o produto precisa ser reconstruído, o cliente exige que 
alguns acertos sejam aplicados para tornar o protótipo um produto; muito 
frequentemente, a gerência de desenvolvimento de software cede. 
• O desenvolvedor muitas vezes faz concessões de implementação a fim de colocar 
um protótipo em funcionamento rapidamente. Depois de algum tempo, o 
desenvolvedor pode familiarizar-se com essas opções e esquecer-se de todas as 
8 
 
razões pelas quais elas são inadequadas - a opção menos ideal se tornou então parte 
integrante do sistema. 
 
4 MODELO RAID 
 
 É 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. 
 No desenvolvimento incremental, uma das características de RAD, o sistema 
é dividido em módulos, tomando por base a funcionalidade. Tendo os incrementos 
definidos, a cada ciclo é acrescido de novas funcionalidades ou até mesmo 
modificações, caso seja necessário. Outra característica é justamente essa 
maleabilidade de adaptação dos processos e a capacidade de se manter em 
constante evolução. 
 As fases de modelagem e geração da aplicação são executadas por diversas 
equipes. Essa divisão otimiza tempo, além do reaproveitamento de módulos prontos 
que faz com que o desenvolvimento cumpra prazos curtos. Por fim, ocorre a 
integração desses componentes. 
 
4.1 Vantagens: 
 
• Desenvolvimento rápido, com prazos curtos (entre 30 e 90 dias); 
• Divisão de tarefas entre equipes; 
• Mais rápida visão geral do sistema (protótipos); 
• Maior envolvimento do usuário/cliente; 
• Menor custo (menos tempo; tempo é igual dinheiro); 
• Exceto em projetos grandes, onde as equipes são maiores; 
 
4. 2 Desvantagens: 
 
• Para grandes projetos, exige-se equipe grande, para cumprir o prazo; 
• Grande envolvimento do usuário (disponibilidade pode ser um problema); 
• Perda de precisão cientifica (falta de métodos formais). 
 
9 
 
5 COMPARATIVO 
 
 O modelo sequencial linear ou o modelo em cascata descreve que, cada fase 
de desenvolvimento prossegue em uma ordem estrita, sem qualquer sobre posição 
ou passos iterativos, ou seja, cada vez que uma fase é completada, o 
desenvolvimento prossegue para a próxima fase e não há retorno. 
 O modelo de prototipação serve com um mecanismo para identificar os 
requisitos de 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. 
 O modelo RAD, é um tipo de modelo incremental que prima por um ciclo de 
desenvolvimento extremamente curto. Assim, como no modelo incremental, o sistema 
é subdividido em subsistemas e incrementos são realizados. A diferença marcante é 
que os incrementos são desenvolvidos em paralelo por equipes distintas e apenas 
uma única entrega é feita. 
 
10 
 
6 CONCLUSÃO 
 
 O modelo sequencial linear não é o mais recomendado para a produção de 
softwares, e a tendência é que as empresas o utilizem cada vez menos. Para 
substituí-lo, surgiram as metodologias ágeis, que permitem desenvolver softwares de 
maneira mais rápida e eficiente. 
 Por ser uma metodologia de poucas fases e de caráter simples, o modelo de 
prototipação é possível que, o modelo seja adaptado possibilitando a opção de ser 
englobado em qualquer outro modelo. Tem como foco a Interação e o Software em 
funcionamento ao invés de Processos e Documentação excessiva. Sua fase de 
desenvolvimento tem como objetivo a Prototipação Evolutiva, porém faz-se uso de 
protótipos de testes e interface, a fim de melhorar o levantamento de requisitos e 
comunicação com o cliente. 
 Apesar do modelo RAD serem de rápido desenvolvimento, a falta de literatura 
e instruções para utilização de algumas delas prejudica o tempo de desenvolvimento 
trabalho. Sobre as desvantagens citadas, elas são bastante importantes na aplicação 
de diversos tipos de sistemas atuais. O que deve ser levado em consideração no 
momento da escolha de uma ferramenta RAD é a identificação da robustez 
necessária para o programa solicitado e em qual âmbito será aplicado. 
 
https://blog.betrybe.com/carreira/metodologias-ageis/
11 
 
7 REFERÊNCIAS BIBLIOGRÁFICAS 
 
ENGHOLM, Hélio. Engenharia de Software na Prática. Novatec Editora. São Paulo, 
Brasil, 2010. 
PRESSMAN, Roger S. Engenharia de Software, 7ª Edição. Editora MCGrawHill: Porto 
Alegre, 2011. 
SOMMERVILLE, Ian. Engenharia de Software. 9ª Edição. Pearson Education, 2011. 
Modelos Incremental, Espiral e de Prototipação. 06/12/12. Disponível em: 
<http://engenhariadesoftwareuesb.blogspot.com/2012/12/blog-post.html>. Acessado 
em>. 10/02/2021. 
O Modelo em Cascata. DIAS, Riacardo Pereira. 21/08/2019. Disponível em: 
<https://mediu m.com/contexto-delimitado/o-modelo-em-cascata-f2418addaf36>. 
Acesso em: 10/02/2021 
Desenvolvendo Sistemas de Informação com Ferramentas RAD. Disponível em: 
<http://www.inicepg.univap.br/cd/INIC_2007/trabalhos/exatas/inic/INICG00513_09C.
pdf>. Acessado em 11/02/2021. 
Prototyping Model, LEWIS, Sarah. September 2019. Disponível em: <encurtador.com.br 
/hiqxW>. Acessado em 11/02/2021. 
Rapid Application Development (RAD). FABRI, José Augusto. Disponível em: 
<https://engenhariasoftware.wordpress.com/2013/01/24/rapid-application-evelopmen 
t-rad/>. Acesso em 13/02/2021. 
 
 
 
 
http://www.inicepg.univap.br/cd/INIC_2007/trabalhos/exatas/inic/INICG00513_09C.pdf
http://www.inicepg.univap.br/cd/INIC_2007/trabalhos/exatas/inic/INICG00513_09C.pdf
https://engenhariasoftware.wordpress.com/2013/01/24/rapid-application-evelopmen%20t-rad/
https://engenhariasoftware.wordpress.com/2013/01/24/rapid-application-evelopmen%20t-rad/
https://engenhariasoftware.files.wordpress.com/2013/01/rad.png
https://engenhariasoftware.files.wordpress.com/2013/01/rad.png