Modelos de Processo de Software
Um modelo de processo para
engenharia de software é
escolhido com base na natureza
do projeto e da aplicação, nos
métodos e ferramentas a serem
usados, e nos controles e nos
produtos intermediários e finais
que são requeridos.
Caracterizado por um ciclo de solução
de problemas
4 estágios distintos:
Situação atual
Definição do problema
Desenvolvimento técnico e
integração da solução
Situação Atual
Representa o estado atual das
coisas
Definição do problema
Identifica o problema específico a
ser resolvido
Desenvolvimento técnico
Resolve o problema por intermédio da
aplicação de alguma tecnologia.
Integração da solução
• Aqueles que solicitaram a solução
inicialmente (p. ex. documentos,
programas, dados, nova função de
negócios, novo produto)
Ciclo solução de problemas
Aplica-se ao trabalho de
engenharia de software em
muitos diferentes níveis de
resolução. Pode ser usado em
nível macro, quando toda
aplicação é considerada.
Em nível intermediário, quando os
componentes de programa estão
passando por engenharia e
mesmo no nível de linha de
código.
Cada estágio do ciclo de solução
do problema contém, um ciclo
idêntico de solução de problema,
que contêm um outro ciclo de
solução do problema (isso
continua até algum limite
racional; para software, uma linha
de código)
Realisticamente, é difícil...
Porque interferências ocorrem
dentro e entre os estágios. Essa
visão simplificada leva ainda a
uma idéia muito importante:
independentemente do modelo de
processo que é escolhido um
projeto, todos os estágios.
Situação atual, definição do
problema, desenvolvimento
técnico e integração da solução –
coexistem simultaneamente em
algum nível de detalhe.
Uma completa aplicação para a
geração de um pequeno trecho de
código.
Ciclo de Vida
Ciclode vida Clássico
(cascata)
Abordagem sistemática e
seqüencial;
O mais antigo ciclo e o mais
amplamente utilizado pela
engenharia de software;
Ciclo de vida
Engenharia
de Sistemas
Análise de
Requisitos
Projeto do
Software
Codificação
Teste
Manutenção
Modelagem – Eng. de Sistemas
Trabalho começa pelo
estabelecimento de requisitos
para todos os elementos do
sistema e depois pela
alocação de algum
subconjunto desses requisitos
para o software
Precisa interagir com outros
elementos tais como
hardware, pessoas e bases de
dados.
Incluem um conjunto de
necessidade a nível de
sistema com um pouco de
projeto de alto nível.
Inclui um conjunto de
necessidades a nível
estratégico e a nível da área
de negócios.
Análise de requisitos de software
É intensificado e focalizado
especificamente no software.
O ES (“analista”) deve
conhecer o domínio da
informação do software, tanto
quanto a função necessária, o
comportamento, o
desempenho e a interface.
Os requisitos do sistema e do
software são documentado e
revistos com o cliente.
Projeto
Um processo de múltiplos
passos que enfoca quatro
atributos distintos do
programa: estrutura de
dados, arquitetura do
software, representações da
interface e detalhes
procedimentais (algoritmicos)
O processo de projeto traduz os
requisitos para uma
representação do software, que
pode ser avaliada quanto à
qualidade, antes que a codificação
tenha início. À semelhança dos
requisitos, o projeto é
documentado e torna-se parte da
configuração do software.
Geração de código
O projeto deve ser traduzido
para linguagem de máquina.
O passo de geração de código
executa essa tarefa. Se o
projeto é realizado de
maneira detalhada, a geração
de código pode ser realizada
mecanicamente.
Testes
O processo de teste focaliza
os aspectos lógicos internos
do software, garantindo que
todos os comandos sejam
testados, e os aspectos
externos funcionais;
isto é, conduz testes para
descobrir erros e garantir que
entradas produzirão
resultados reais, que
concordam com os resultados
exigidos.
Manutenção
Uma modificação acomodar
mudanças no seu ambiente
externo (modificação necessária
por causa de um novo sistema
Operacional ou dispositivo
periférico), ou quando o cliente
deseja melhoramentos
funcionais ou de desempenho
O suporte/manutenção do
software reaplica cada uma
das fases precedentes a um
programa existente ao invés
de um novo programa
Ciclo de Vida
Atualmente críticas estão sendo feitas
sobre sua aplicabilidade:
Os projetos raramente seguem o
fluxo seqüencial;
Raramente o cliente declara
totalmente suas exigências;
Uma versão do sistema é entregue
no fim do cronograma, o que deixa o
cliente sem paciência
Prototipação
Adequado em casos de incertezas do cliente;
Recomendado quando há dúvidas da
eficiência da versão final;
A prototipação pode assumir:
Modelo em papel ou baseado em PC com
algumas interfaces que retratariam a versão
final;
Implementação de um subconjunto da
versão final
Uma versão que executa parte ou toda
função desejada, mas que será melhorado
em nova versão.
Prototipação
Começa com a definição de
requisitos. O desenvolvedor e o
cliente encontra-se e definem os
objetivos gerais do software,
identificam as necessidades
conhecidas e delineiam áreas que
necessitam de mais definições.
Um projeto rápido é então
realizado. Esse projeto concentra-
se na representação daqueles
aspectos do software que vão
ficar visíveis ao cliente/usuário
(ex. abordagem de entrada e
formato de saída).
O projeto rápido parte de um
protótipo. O protótipo é avaliado
pelo cliente/usuário e usado para
refinar os requisitos do software
que será desenvolvido.
Interaçõesocorrem à medida que
o protótipo é ajustado para
satisfazer às necessidades do
cliente, enquanto, ao mesmo
tempo, permitem ao
desenvolvedor entender melhor o
que precisa ser feito.
Idealmente, o protótipo serve
como um mecanismo para a
identificação dos requisitos do
software. Se um protótipo
executável é elaborado, o
desenvolvedor tenta usar partes
do programas existentes ou aplica
ferramentas (ex. geradores de
relatórios) que possibilitam que
programas executáveis sejam
gerados rapidamente.
Mas o que fazer com o protótipo quando
tiver cumprido a finalidade descrita
Na maioria dos projetos, o
primeiro sistema construído
consegue ser apenas
utilizável. Pode ser muito
lento, grande, complicado de
usar ou tudo isso ao mesmo
tempo.
Na há alternativa senão começar
de novo e construir uma versão
reprojetada, na qual esses
problemas são resolvidos...
Quando um novo conceito de
sistema ou uma nova tecnologia é
usada deve-se construir um
sistema para ser descartado,
porque nem mesmo o melhor
planejamento é tão onisciente
para fazer certo na primeira vez.
A questão de gerência,
entretanto, não é se o sistema
piloto elaborado deve ser
descartado. Ele será. A única
questão é planejar
antecipadamente a construção de
um descartável, ou prometer
entregá-lo aos clientes...
O protótipo pode servir como o
“primeiro sistema”. Aquele que
Brooks recomenda que se
descarte. Mas essa pode ser uma
visão idealizada. É verdade que
tanto clientes quanto
desenvolvedores gostam de
paradigma de prototipagem.
Osusuários tem o sabor de
um sistema real e os
desenvolvedores conseguem
construir algo imediatamente.
Apesar dos problemas poderem
ocorrer, a prototipagem pode ser
utilizado. O importante é definir
as regras do jogo no início, isto é,
o cliente e desenvolvedor devem
estar de acordo que o protótipo
seja construído para servir como
um mecanismo para definição dos
requisitos. Depois é descartado
(ou pelo menos em parte).
Prototipação
– possíveis problemas
O cliente vê aquilo que “parece”
ser uma versão definitiva do
trabalho do software.
O desenvolvedor muitas vezes faz
concessões de implementação a
fim de colocar um protótipo em
funcionamento rapidamente.
Espiral
Atividades em espiral que é composta por
ciclos (Planejamento, Análise de Riscos,
Engenharia e Avaliação pelo Cliente);
A cada ciclo, novas versões são
apresentadas ao cliente;
Caso a análise dos riscos indicar que há
incertezas nos requisitos, a prototipação
pode ser adotada no quadrante da
engenharia para ajudar a desenvolvedor e
cliente.
Espiral
É um modelo de processo de
software evolucionário que
combina a natureza iterativa da
prototipagem com os aspectos
controlados e sistemáticos de
modelo sequencial linear
Fornece potencial para o
desenvolvimento rápido de
versões incrementais do software.
Usando o modelo Espiral, o
software é desenvolvido numa
séie de versões incrementais.
A versão incremental, durante as
primeiras iterações, pode ser um
modelo de papel ou protótipo.
Durante as últimas iterações, são
produzidas versões cada vez mais
completas do sistema submetido
à engenharia.
Regiões de tarefas
Comunicação com o cliente –
tarefas necessárias para
estabelecer efetiva
comunicação entre o
desenvolvedor e o cliente
Planejamento – tarefa
necessárias para definir
recursos, prazos e outras
informações relacionadas ao
projeto.
Análise de Risco – tarefas
necessárias para avaliar os
riscos, tanto técnico quanto
gerenciais.
Engenharia – tarefa
necessária para construir uma
ou mais representações da
aplicação.
Construção e liberação – para
construir, testar, instalar e
fornecer apoio ao usuário (Ex.
documentação e treinamento)
Avaliação pelo cliente – tarefa
necessária para obter
realimentação do cliente, com
base na avaliação das
representações do software
criadas durante o estágio de
engenharia e implementadas
durante o estágio de instalação.
Cada uma das regiões é
preenchida por um conjunto de
tarefas de trabalho, que são
adaptadas às características do
projeto a ser desenvolvidos.
Para projetos pequenos, a
quantidade de tarefas de trabalho
e suas formalidades é pequena.
Para projetos maiores, mais
críticos, cada região de tarefas
contém mais tarefas de trabalho,
que são definidas para alcançar
um alto nível de formalidade.
A medida que esse processo
evolucionário tem início, a equipe
de engenharia de software move-
se em volta da espiral, no sentido
horário, a partir do centro. O
primeiro circuito em torno da
espiral pode resultar no
desenvolvimento da especificação
do produto;
Passagens subsequentes em
torno da espiral podem ser
usadas para desenvolver um
protótipo e depois,
progressivamente, versões mais
sofisticadas do software. Cada
passagem pela região de
planejamento resulta em ajustes
ao plano do projeto.
O custo e o cronograma sã
ajustados com base na
realimentação derivada da
avaliação do cliente. Além disso, o
gerente do projeto ajusta a
quantidade de iterações
necessárias planejadas para
completar o software.
Um “projeto de desenvolvimento
conceitual” começa no centro da
espiral e continua (ocorrem
múltiplas iterações ao longo do
caminho em espiral que limita a
região central escura) até que o
desenvolvimento conceitual se
complete.
Se o conceito deve ser
desenvolvido até virar um produto
real, o processo prossegue
através do próximo cubo (ponto
de entrada para um projeto de
desenvolvimento de novo
produto) e um “novo projeto de
desenvolvimento” é iniciado.
O novo produto vai evoluir
através de um certo número de
iterações, em torno da espiral,
seguindo o caminho que limita a
região, que tem uma tonalidade
um pouco mais clara do que o
núcleo.
Em resumo, o espiral, quando
caracterizada desse modo,
permanece operacional até que o
software seja retirado de serviço.
Há momentos em que eu o
processo fica adormecido, mas
sempre que uma modificação é
iniciada, o processo começa no
ponto de entrada adequado (ex.:
melhoria)
O modelo é utilizado para
desenvolvimento de sistemas de
grande porte. Como o software
evolui a medida que o processo
avança o desenvolvedor e o
cliente entendem melhor e
reagem aos riscos em cada nível
evolucionário.
O modelo espiral usa
prototipagem como mecanismo
de redução de risco, porém, o
mais importante, é que permite
ao desenvolvedor aplicar a
abordagem de prototipagem em
qualquer estágio de evolução do
produto.
Espiral
possíveis problemas
Pode ser difícil convencer os
clientes de que a abordagem
evolutiva é controlável;
Exige considerável experiência na
avaliação dos riscos;
É um modelo relativamente novo,
portanto a atenção e cuidados
devem ser maiores.
Modelo Espiral Ganha-Ganha
O objetivo dessa atividade é
formular os requisitos de projeto
do cliente. Em contexto ideal, o
desenvolvedor simplesmente
pergunta ao cliente o que é
necessário e o cliente fornece os
detalhes suficiente para
prosseguir.
Infelizmente, isso raramente
acontece. Na realidade, o cliente
e o desenvolvedor iniciam uma
negociação, em que o cliente
pode ser levado a ponderar a
funcionalidade, o desempenho e
outras características do produto,
ou do sistema, em relação ao
custo e ao prazo para chegar ao
mercado.
As melhores negociações buscam
um resultado “ganha-ganha”. Isto
é, o cliente ganha obtendo um
produto ou sistema que satisfaz à
maior parte das necessidades do
cliente, e o desenvolvedor ganha
trabalhando com orçamento e
prazos de entrega realísticos e
possíveis de serem cumpridos.
Omodelo espiral ganha-ganha de
Boehm [BO98] define um
conjunto de atividades de
negociação no começo de cada
passagem, em torno da espiral.
Ao invés de uma única atividade
de comunicação com o cliente, as
seguintes atividades são
definidas:
Identificação dos principais
“interessados” do sistema ou do
subsistema.
Determinação das condições de
lucro do interessado.
Negociação das condições de
ganho do interessado para
reconciliá-las no âmbito das
condições ganha-ganha para
todos os envolvidos.
A conclusão bem-sucedida desses
passos iniciais leva a um
resultado ganha-ganha que vem a
ser o principal critério para
prosseguir em direção à definição
do software e do sistema.
Além da ênfase na negociação
inicial, o modelo espiral ganha-
ganha introduz três marcos de
processo, chamados pontos de
ancoragem que ajudam a
estabelecer quando um ciclo é
completado em torno da espiral e
fornecem marcos de decisão
antes do projeto de software
prosseguir.
Os pontos de ancoragem
representam três diferentes
visões de progresso a medida que
o projeto percorre a espiral. O
primeiro ponto...
Primeiro ponto de ancoragem
Objetivos de ciclo de vida –
define um conjunto de
objetivos para cada atividade
principal de engenharia de
software. (ex. alto nível dos
requisitos do
sistema/produto)
Segundo ponto de ancoragem
Arquiteturado ciclo de vida –
estabelece objetivos que
precisam ser satisfeitos, à
medida que a arquitetura do
sistema, e do software, é
definida. (ex. avaliação de
componentes reusável)
Terceiro ponto de ancoragem
Capacidade operacional – um
conjunto de objetivos associado
com a preparação do software
para instalação/distribuição,
preparação do local antes da
instalação e assistência
requerida por todas as partes
que irão usar ao dar suporte.
Visão Geral da ES
Ao observarmos os modelos
apresentados de ciclo de vida de um
software, deparamos com fases em
comum em todos eles;
Basicamente a Engenharia de
Software dispões de 3 grandes fases:
Definição;
Desenvolvimento;
Manutenção.
Fase de Definição:
Análise ou Definição do Sistema;
Permite determinar o papel de cada elemento
(software, hardware, equipamentos, pessoas)
Planejamento do Projeto de Software;
Análise de riscos, definição de recursos, custos e
cronograma.
Análise de Requisitos
Determina o conjunto de funções a serem
realizadas e principais estruturas de informação a
serem processadas.
Fase de Desenvolvimento:
Projeto de Software
Definição de estrutura de dados, arquitetura de
software, detalhes procedimentais e
caracterização de interface.
Codificação:
É o mapa ou definição em forma de código em
uma ou mais linguagens de programação
baseado nas definições de Projeto de Software
Teste de Software:
Submissão a um conjunto de testes para validar
sua funcionalidade e corrigir possíveis erros.
Fase de Manutenção:
Correção
Atividade de correção dos erros observados
durante a operação do sistema
Adaptação
Alterações no software para que ele possa
ser executado por exemplo em plataforma
diferente
Melhoramento funcional ou Perfectivo
Alterações que permitam melhorar aspectos
do software como desempenho, interface,
robustez.