Modelo de Processos de Software – Eng.

de Software

No mundo da informática, temos diversos tipos de modelos de processo de softwares.

Eles têm a finalidade de fazer a criação do software, mas cada modelo tem a sua uma
abordagem diferente para a criar o software.

Vamos abordar alguns tipos de Modelos de Processos de Software, falar a finalidade e

os pontos positivos e os negativos dele.

Modelo Sequencial Linear (Modelo em Cascata)

O Modelo em cascata foi o primeiro modelo publicado para o processo de

desenvolvimento de software. Ele representa o desenvolvimento gradual com uma
sequência ordenada de passos que devem ser seguidos rigorosamente.
O Modelo cascata é um dos modelos mais importantes e utilizados como referência
para a criação de softwares, funcionando como base para os demais projetos
modernos. Ao longo do tempo, o modelo cascata foi melhorando e continua sendo
utilizado até os dias atuais.

Um dos motivos que fazem o modelo cascata ser bem-sucedido e famoso é o fato de
ser orientado para documentação. Porém, é importante ressaltar que a documentação
compreende mais do que o arquivo de texto, abrangendo representações gráficas ou
até mesmo simulação.

As fases do Modelo Sequencial Linear são exercitadas em sequência, ou seja, uma

fase só executa quando a anterior termina sua execução. Nesse momento os modelos
resultados não podem ser alterados após a fase terminar sua execução. Essa
característica faz com que esse modelo não seja tão utilizado pela falta de
flexibilidade.

Este modelo é utilizado principal quando os requisitos de um determinado problema

são bem compreendidos. Uma boa forma de utilizar o Modelo Cascata é quando
precisamos fazer adaptações ou aperfeiçoamentos em um sistema já existente. Um
exemplo disso é quando um software necessita de uma nova funcionalidade e os
requisitos estão bem definidos e são estáveis.

Primeiro, começamos fazendo o levantamento de requisitos ou as necessidades junto

ao cliente, após isso vamos para a fase de planejamento para definir estimativas,
cronograma e acompanhamento, depois disso partimos para a modelagem onde
fazemos a análise e projeto, seguindo a construção onde codificamos e testamos,
passamos para a implantação ou emprego onde efetuamos a entrega, suporte e
feedbacks do software concluído.

Etapas do Modelo Cascata

  Análise e Definição dos Requisitos

Nesta fase, são estabelecidos os requisitos do produto que o idealizador almeja

desenvolver, o que normalmente se baseia nos serviços que precisam ser fornecidos,
nas limitações aceitáveis do software.

Depois que isso é determinado, os requisitos precisam ser estabelecidos de forma

adequada para que também sejam úteis para a próxima etapa. Está fase compreende
a documentação e o estudo de viabilidade e a facilidade do projeto com a finalidade de
estipular o processo de início de desenvolvimento do projeto do sistema, podendo ser
entendida como o começo do ciclo de vida do produto.

 Projeto do Sistema

A etapa de implementação é quando os programas são criados. Caso o projeto tenha

um nível de detalhamento mais avançado, a etapa de codificação pode ser
implementada de maneira automática.

O processo de projeto mostra os requisitos de uma maneira que possibilita a

codificação do produto (sendo uma prévia fase de codificação). Da mesma forma que
a análise dos requisitos, o projeto passa a ser documentado e torna-se parte do
software.

 Implementação

A etapa de implementação é quando os programas são criados. Caso o projeto tenha

um nível de detalhamento mais avançado, a etapa de codificação pode ser
implementada de maneira automática.

A princípio, é recomendado adicionar um teste unitário de cada módulo que é

desenvolvido nesta fase. Nesta situação, as unidades de código criadas são
submetidas a testes individuais antes de progredir para a etapa de integração a teste
global.

 Teste do Sistema

Após o fim da etapa de codificação, inicia-se a fase da realização de teste do sistema.

Este processo de teste é focado em dois pontos principais, que são as lógicas internas
do software e as suas funcionalidades externas.

Está etapa é importante porque a evidência se os erros de comportamento do software

foram solucionados e assegura que as entradas definidas produzam resultados
eficientes e que estão de acordo com os requisitos determinados anteriormente.

 Manutenção

A fase da manutenção se baseia na correção de erros que não são detectados

durante os testes, em melhorias funcionais e de preferência com os demais tipos de
suporte. Está etapa faz parte do ciclo de vida do produto de software e não pertence
apenas ao seu desenvolvimento.
As melhorias e alterações para correções do software podem ser classificadas como
parte do processo de desenvolvimento.
As etapas de manutenção descritas até agora são as mais importantes e utilizadas,
mas também existe sub-etapas que devem ser executado dentro de cada etapa, que
podem se diferenciar do desenvolvimento de um projeto para o outro.

Pontos positivos do Modelo Cascata

 Documentação rígida (idealmente completa) em cada atividade;

 Reflete abordagens adotadas em outras engenharias;
 Aderência a outros modelos de processo.

Pontos negativos do Modelo Cascata

 Projetos reais raramente seguem um fluxo sequencial;

 Difícil se adequar a mudanças inevitáveis de requisitos;
 Uma versão executável só poderá ficar pronta na fase final do projeto.

Como podemos aplicar o Modelo Cascata?

 Em sistemas críticos;
 Quando os requisitos são bem compreendidos.

Modelo de Prototipação

Baseado no desenvolvimento de um protótipo com base no conhecimento dos

requisitos iniciais para o sistema.
O desenvolvimento é feito obedecendo à realização das diferentes etapas de análise
de requisitos, o projeto, a codificação e os testes. Não necessariamente estas etapas
devem ser realizadas de modo muito explícito ou formal.

A definição de todos os requisitos necessários ao sistema pelo cliente ou usuário

geralmente é uma tarefa muito difícil. É 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 desenvolvimento rápido de um
protótipo é 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 protótipo 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.

Na maioria dos projetos, o primeiro sistema construído dificilmente será usável. Ele
pode 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.

Pontos positivos da prototipação

 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 realizabilidade 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 mais bem concebido.

Pontos negativos da prototipação

 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
razões pelas quais elas são inadequadas - a opção menos ideal se tornou então
parte integrante do sistema;

 O cliente tende a confundir o protótipo com a versão final do produto;

 Alto custo de desenvolvimento.

Como podemos utilizar o Método de Prototipação?

 Utilizado para reduzir incertezas do projeto;

 São criadas interfaces para que o cliente possa compreender melhor os requisitos
do sistema;
 Para auxiliar na identificação de uma solução final mais acertida;
 Utilizada para “testar” todas as ideias criadas e avaliar somente as mais
promissoras;
 É utilizada para a criação rápida de softwares.

Modelo RAD

Rapid Application Development (RAD) ou Desenvolvimento Rápido de Aplicação é

um modelo de processo de desenvolvimento de software incremental, que foi
registrado por James Martin, em 1991.

É um processo de desenvolvimento de aplicações de forma rápida com objetivos bem

definidos e análise de requisitos extremamente bem alinhada. Esse modelo enfatiza
um ciclo de desenvolvimento curto, com o intuito de ter um desenvolvimento melhor e
mais rápido.

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.

O processo consiste basicamente em:

1. Modelagem do negócio

O fluxo de informações entre as funções de negócio são modeladas de maneira a

responder às questões:

 Que informação dirige o processo do negócio?

 Que informação é gerada?
 Quem gera a informação?
  Quem a processa?

2. Modelagem dos dados

O fluxo de informação definido na fase anterior é refinado em um conjunto de objetos

de dados que são necessários para dar suporte ao negócio. São identificadas as
características de cada objeto e são definidos seus relacionamentos.

3. Modelagem do processo

Os objetos de dados definidos são transformados para se obter o fluxo de informação

necessário para implementar uma função do negócio.

São criadas as descrições dos processamentos necessários para manipular esses

objetos de dados.

4. Geração da aplicação

O modelo RAD assume o uso de técnicas de 4a. Geração. Ao invés de criar software
de forma convencional, reusa componentes quando possível ou cria componentes
reutilizáveis. Ferramentas automatizadas são utilizadas para gerar software.

5. Teste e Modificação

Por reutilizar componentes, muitas vezes eles já foram testados, o que reduz o tempo
de teste. Os novos componentes devem ser testados e as interfaces devem ser
exercitadas.

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.

O RAD tem uma capacidade muito grande de potencializar o desempenho dos

profissionais da equipe. Algumas outras vantagens são:

 economia de tempo;
 progresso mensurável;
 trabalho com modelos;
 integração mais rápida de sistemas;
 feedback constante.

Pontos positivos do Modelo RAD

  Enfatiza um ciclo de desenvolvimento extremamente curto (entre 60 e 90 dias);
 Cada módulo pode ser direcionado a uma equipe de desenvolvimento e depois
de completados, juntos formarão um todo.

Pontos negativos do Modelo RAD

 Se o projeto for grande, por exemplo, o número de equipes crescerá demais e

a atividade de integração será muito complexa;
 A organização tem de ter recursos humanos suficientes para acomodar as
várias equipes;
 O sistema deve ser passível de modularização;
 Quando se pode ter uma grande quantidade de riscos técnicos (ex. nova
tecnologia).

Os Modelos evolutivos de Processo de Software

Na maioria das vezes a engenharia de software necessita de um processo que possa

acondicionar um produto que evolui ao longo do tempo. A evolução do produto ocorre
devido à constante atualização dos requisitos, fato este recorrente em projetos de
software. Dentro deste contexto encontram-se os Modelos Evolutivos.

Os Modelos Evolutivos são caracterizados por iterações, o que possibilita o

desenvolvimento de várias versões do produto. Estas versões são colocadas em
produção e os requisitos sofrem constantes refinamentos. É importante salientar
também que as versões, quando implantadas, podem gerar novos requisitos.

 Modelo Incremental:

O Modelo incremental é classificado como um modelo evolutivo dentro da engenharia

de software. Ele é baseado no modelo cascata e diversas iterações, ou seja, várias
“cascatinhas” são implementadas durante o desenvolvimento do produto – uma cada
versão.
O Modelo Incremental é uma combinação entre os modelos linear e de prototipação. O
desenvolvimento é feito em partes independentes denominadas incrementos. A cada
parte do desenvolvimento vai se incrementando partes até que o Software esteja
concluído. Este modelo foi sugerido por Barry Boehm.
A aplicabilidade do modelo incremental ocorre em projetos de software de qualquer
tamanho ou natureza.
Pontos positivos do Modelo Incremental

 Entregas parciais facilitam a identificação e correção de erros entre os

componentes do software;
 Necessidades não especificadas nas fases iniciais podem ser desenvolvidas
nos incrementos;
 Os incrementos podem ser desenvolvidos por menos pessoas;
 Entrega dos incrementos (partes do Software) permite o cumprimento do prazo
especificado;
 Facilita a manutenção dos “módulos”;
 O Modelo Incremental inclui o uso do software pelo usuário para que as
mudanças sejam feitas de acordo com o próprio usuário;
 É flexível e fácil de gerenciar para fazer um software melhor com uma melhor
estrutura;
 Os testes são simples

Pontos negativos do Modelo Incremental

 Podem surgir problemas relativos à arquitetura do sistema, porque nem todos

os requisitos estão reunidos na frente de todo o ciclo de vida do software;
 O modelo Incremental precisa ser relativamente pequeno;
 Número de iterações não pode ser definido no início do processo;
 O fim do processo não pode ser previamente definido;
 Gerenciamento e manutenção do sistema completo podem se tornar
complexos;
 Gerenciamento do custo é mais complexo devido ao número de iterações
(dinheiro pode acabar);

 Modelo Espiral
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.

Existem tipicamente de 3 a 6 regiões de tarefa:

Cada “loop” do espiral é dividido em 4 setores:

 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:
Depois da avaliação do risco, um modelo de desenvolvimento é escolhido para o
sistema.

 Planejamento:
O projeto é revisto e é tomada uma decisão de continuidade se é decidido continuar,
são projetados planos para a próxima fase do projeto (próximo “loop”).

Pontos positivos para o Modelo Espiral

 É atualmente, a abordagem mais realística para o desenvolvimento de software

em grande escala;
 Usa uma abordagem que capacita o desenvolvedor e o cliente a entender e
reagir aos riscos em cada etapa evolutiva.

Pontos negativos para o Modelo Espiral

 pode ser difícil convencer os clientes que uma abordagem "evolutiva" é

controlável;
 exige considerável experiência na determinação de riscos e depende dessa
experiência para ter sucesso;
 o modelo é relativamente novo e não tem sido amplamente usado. Demorará
muitos anos até que a eficácia desse modelo possa ser determinada com
absoluta certeza.

 O Modelo de Montagem de Componentes

É um modelo que incorpora características de tecnologias Orientadas a Objetos no
Modelo Espiral. Quando projetadas e implementadas apropriadamente as classes
orientadas a objeto são reutilizáveis em diferentes aplicações e arquiteturas de
sistema.

O Modelo de Montagem de Componentes conduz o reuso do software. A reusabilidade

fornece uma série de benefícios:

 Redução de 70% no tempo de desenvolvimento;

 Redução de 84% no custo do projeto;
 Índice de produtividade de 26.2 (normal da indústria é de 16.9).
Esses resultados dependem da robustez da biblioteca de componentes.

 Modelo de Desenvolvimento Concorrente

Este modelo é representado como uma série de grandes atividades técnicas, tarefas e
seus estados associados. Ele define uma série de eventos que podem disparar
transições de um estado para outro, para cada uma das atividades de engenharia de
software.

É frequentemente usado como um paradigma para o desenvolvimento de aplicações

Cliente/Servidor. Pode ser aplicado a todo tipo de desenvolvimento de software e
fornece uma visão exata de como está o estado do projeto.

Exemplo: Começo de projeto

 A atividade de comunicação completou sua primeira iteração e está no estado

aguardando modificações;
 A atividade de modelagem passa do estado nenhum para o estado em
desenvolvimento;
  Se o cliente requere mudança nos requisitos, a modelagem passa de em
desenvolvimento para aguardando modificações e a comunicação passa de
aguardando modificações para em revisão.

Compõe aplicações a partir de componentes de software previamente preparados.

Segue os seguintes passos implantados com uma abordagem evolucionária:

 Pesquisa e avaliação de componentes disponíveis para o domínio em

questão;
 Considerações sobre a integração de componentes;
 Projeto de arquitetura de software;
 Testes para garantir a funcionalidade adequada.

Pontos positivos do Desenvolvimento Baseados em Componentes:

 Leva ao reuso de software, que segundo estudos tem como consequências:

I. Redução significativa do prazo de desenvolvimento;
II. Redução significativa no custo do projeto;
III. Aumento do índice de produtividade.

 Modelo de Métodos Formais

Os Métodos Formais permitem ao engenheiro de software especificar, desenvolver e

verificar um sistema aplicando uma rigorosa notação matemática. São técnicas
baseadas em formalismos matemáticos para a especificação, desenvolvimento e
verificação dos sistemas de softwares e hardwares.

Na Ciência da Computação:

 O termo método formal foi restrito para o uso de notação formal para
representar modelos de sistemas durante o processo de desenvolvimento;
 É difícil formalizar domínios que possuem muitos casos especiais ou contém
muito conhecimento subentendido ou sujeito a mudanças.

Pontos positivos para o uso de Métodos Formais

 Usados para reduzir o número de erros do sistema;

 Reduz o tempo de desenvolvimento;
 Proporciona melhor documentação;
 Melhora a comunicação (entre equipe com o usuário);
 Facilita manutenção
 Ajuda a organizar as atividades durante o ciclo de vida.

Pontos negativos para o uso de Métodos Formais

 O desenvolvimento de Modelos Formais é atualmente muito lento e

dispendioso;
 Exige o treinamento extensivo para das aos desenvolvedores o preparo
necessário;
 É difícil usar os modelos como um mecanismo de comunicação com a maioria
dos clientes.
  Técnicas de 4 ª Geração

Concentra-se na capacidade de se especificar o software a uma máquina em um nível

que esteja próximo à linguagem natural.
Engloba um conjunto de ferramentas de software que possibilitam que:

 O sistema seja especificado em uma linguagem de alto nível;

 O código fonte seja gerado automaticamente a partir dessas especificações.

O ambiente de desenvolvimento de software que sustenta o ciclo de vida de 4ª

geração inclui as ferramentas:

 Linguagens não procedimentais para consulta de banco de dados;

 Geração de relatórios;
 Manipulação de dados;
 Interação e definição de telas;
 Geração de códigos;
 Capacidade gráfica de alto nível;
 Capacidade de planilhas eletrônicas.

1. Obtenção dos Requisitos:

 O cliente descreve os requisitos os quais são traduzidos para um protótipo

operacional;
 O Cliente pode ser incapaz de especificar as informações de um modo que
uma ferramenta 4GL possa consumir;
 As 4GLs atuais não são sofisticadas suficientemente para acomodar a
verdadeira “linguagem natural”.
 2. Estratégia de “Projeto”:

Para pequenas aplicações é possível mover-se do passo de Obtenção dos Requisitos

para o passo de Implementação usando uma Linguagem de 4G.

 Para grandes projetos é necessário desenvolver uma estratégia de projeto. De

outro modo ocorrerão os mesmos problemas encontrados quando se usa
abordagem convencional (baixa qualidade).

3. Implementação usando 4GL:

Os resultados desejados são representados de modo que haja geração automática de
código. Deve existir uma estrutura de dados com informações relevantes e que seja
acessível peça 4GL.

4. Teste:
O desenvolvedor deve efetuar testes e desenvolver uma documentação significativa.
O software desenvolvido deve ser construído de maneira que a manutenção possa ser
efetuada prontamente.

Pontos positivos:

 Redução dramática no tempo de desenvolvimento do software (aumento de

produtividade).

Pontos negativos:

 O código fonte produzido é ineficiente;

 A manutenibilidade de sistemas usando técnicas 4G ainda é questionável.