02 - modelos de processo de sw.ppt

Monica de Souza Massa março / 2009 slide 1

Modelo de Processo de Software

MODELOS DE PROCESSO DE SOFTWARE



PROCESSO

Definição

Uma sequencia de etapas que envolvem atividades, restrições e recursos para alcançar o objetivo desejado.

Esta sequencia é, geralmente, realizada sempre na mesma ordem todas as vezes.

Um processo é mais do que um procedimento:

Procedimento = receita. Combinação de ferramentas e técnicas para produzir algo.

Processo = conjunto de procedimentos organizados de modo a permitir a construção de produtos que satisfaçam uma série de objetivos e padrões.



PROCESSO

O QUE É?

Exemplo:

Processo: fazer um bolo de chocolate

- procedimento: receita

- atividade: bater a massa

- restrições: temperatura do forno

- recursos: açucar

- ferramentas: batedeira



PROCESSO DE SOFTWARE

Definição

conjunto estruturado de atividades necessárias para o desenvolvimento ou a evolução do software.

conjunto coerente de atividades para especificar, projetar, implementar e testar um sistema de software.

Um processo define quem faz o quê, quando e como o objetivo será atingido

Jacobson, Booch e Rumbaugh




Um processo de software inclui…Todas as principais atividades

Recursos

Produtos intermediários e finais

Subprocessos, com hierarquia ou organizados de algum modo

Critérios de entrada e saída para cada atividade

Seqüência de atividades, de modo que a ordem de execução de uma para outra seja clara

Conjunto de diretrizes que explicam os objetivos de cada atividade

Restrições e controles para cada atividade, recurso ou produto




Diferentes processos de SW organizam as atividades de maneiras diversas.

Diferentes organizações podem utilizar processos diferentes para produzir o mesmo tipo de produto.

Alguns processos são mais adequados do que outros => depende do tipo de aplicação.




Framework genérico para um processo de SW

especificação +

desenvolvimento +

validação +

evoluçãoUtilizado como base para os modelos de processo de SW e ap[licado na grande maioria dos projetos de SW




Especificação

Estabelece quais as funções que são requeridas pelo sistema e as restrições sobre sua operação e desenvolvimento.

Engenharia de requisitos

Composto de quatro estágios principais:

Estudo de viabilidade

Levantamento e análise de requisitos

Especificação dos requisitos

Validação dos requisitos




Desenvolvimento (projeto e implementação do SW)

É o processo de conversão de uma especificação de sistema em um sistema executável.

Projeto de SW = descrição da estrutura do SW a ser implementado, dos dados, das interfaces e dos algoritmos.

Atividades principais:

Projeto de arquitetura

Especificação das funções do SW

Projeto de Interface

Projeto de Componentes

Projeto das Estruturas de Dados

Projetos de Algoritmos





Métodos de projeto – são notações padronizadas e incorporações das boas práticas.

Melhor método ???? – adequação ao domínio da aplicação

Aumento da probabilidade de resultar em um “bom” projeto

Criatividade ainda requerida pelo projetista





“Em muitos projetos de desenvolvimento, o projeto de SW ainda é um processo

utilizado à medida que for necessário. Partindo de um conjunto de requisitos,

geralmente em linguagem natural, é preparado um projeto informal. A codificação se

inicia, e o projeto é modificado à medida que o sistema é implementado. Existe pouco

ou nenhum controle dessas modificações ou do gerenciamento do projeto. Quando o

estágio de implementação se completa, o projeto normalmente foi tão modificado ,

depois da sua especificação inicial, que o documento original de projeto é uma

descrição incoerente e incompleta do sistema”.

Sommerville (2007)




Validação de SW

Tem por objetivo mostrar que um sistema está de acordo com suas especificações e que ele atende à expectativa do cliente.

Validação processual – desde requisitos até SW pronto

pós implementação

iterativo

Integração – planos de teste – teste “beta”




Validação de SW

UNIDADE

MÓDULO

SUBSISTEMA

SISTEMA

ACEITAÇÃO

Teste de componentes

Programadores Teste de integração

Equipe de teste Teste de usuário

Equipe de teste




Evolução do SW

Evolução ou manutenção (distinção entre os termos).

À medida que os requisitos mudam (em função das mudanças de negócio no domínio da aplicação), o SW que suporta esse negócio precisará ser modificado.

Embora exista uma marcação formal entre desenvolvimento e manutenção, o SW já evolui (sofre mudança) antes mesmo de concluir o seu desenvolvimento formal.

Desenvolvimento = melhor parte ????

Onde termina Desenvolvimento e começa Manutenção?



MODELO DE PROCESSO DE SOFTWARE

Um processo de desenvolvimento de software é, portanto, uma abordagem que descreve um conjunto de ações cuja meta é o desenvolvimento ou evolução de um sistema.

É composto de fases e atividades que descrevem a “receita do bolo”- o passo a passo do processo de desenvolvimento.

De forma a organizar o desenvolvimento de sistemas de software foram criadas ao longo do tempo vários critérios de divisão do processo em etapas – Modelos de Processo de Desenvolvimento ou Ciclos de Vida.

Contextualizando…




Todos os modelos de processo podem ser percebidos dentro da estrutura genérica (framework) descrita anteriormente, com algumas adaptações a depender da natureza do projeto de SW.

As diferenças entre os modelos de processo de SW residem: Na organziação do fluxo de atividades e tarefas dentro de

cada fase;

Na interdependência entre tarefas;

No nível de detalhamento de cada tarefa;

No nível de detalhamento de cada produto, resultado de uma tarefa;

Na forma como a qualidade é assegurada;

No grau de envolvimento entre os diversos atores do processo; etc.

Contextualizando…



Alguns modelos de processo de SW:

Code-and-Fix

Modelo em cascata

Prototipação

Modelos iterativos (incremental e espiral)

Desenvolvimento orientado a reuso

Processo Unificado




Modelo Code-and-fix.

Esse modelo começa com uma idéia geral informal do produto.

O SW é desenvolvido – CODIFICADO – até que o produto esteja “pronto”.

Não existe planejamento e a ordem de execução das atividades é randômica.





Vantagens:

Não existe um overhead administrativo (não se “perde” tempo planejando).

Os resultados – código – são rapidamente verificáveis.

Não precisa de conhecer técnicas de desenvolvimento de SW.

Útil para pequenos projetos de prova de conceito (modelo prático que possa provar um conceito teórico), para eliminação de riscos de projeto.





Desvantagens:

Perigoso!

Não existe controle.

Não existe planejamento de recursos.

Não existe estimativas de prazo ou custo.

Erros são difíceis apra descobrir e corrigir.

Modelo impossível de adequação a projetos de grande porte e alta complexidade.




Modelo Clássico - Cascata.

Surgiu na década de 50 e se popularizou em 70.

Cascata de etapas.

Ciclo de vida mais antigo e mais utilizado.

Resultado de uma etapa é usado na etapa seguinte.

Baseado no modelo clássico da engenharia.




Modelo Clássico - Cascata.


Requirementsdefinition

System andsoftware design

Implementationand unit testing

Integration andsystem testing

Operation andmaintenance

Ian Sommerville



Vantagens:

Fácil de entender e implementar.

Amplamente utilizado. (50’s)

Acompanha o modelo proposto pela Engenharia.

Reforça “bons hábitos”.

Orientado a documentos (mais um “bom hábito”!)

MODELO DE PROCESSO DE SOFTWARE Modelo Clássico - Cascata.



O grande obstáculo deste modelo é a dificuldade em acomodar mudanças ao longo do processo de desenvolvimento.

Desvantagens:

Projetos reais raramente seguem o fluxo sequencial que o modelo propõe

Difícil para o cliente estabelecer todos os requisitos inicialmente.




Mais desvantagens:

Dificuldade na adaptação à incerteza natural que existe no início dos projetos.

O cliente precisa ter paciência! Tempo necessário para disponibilizar o software.

Dificuldade em rasterar os requisitos do modelo para o código.

Particionamento inflexível do projeto em estágios, o que torna complicado atender äs mudanças de requisitos ao longo do projeto.




Prototipação. Processo onde o desenvolvedor cria um modelo do software que será implementado.

O protótipo serve como um mecanismo para a identificação dos requisitos do software.

Tipos de Prototipação:

EVOLUTIVA – o objetivo é trabalhar com o cliente e evoluir uma especificação inicial para o SW pronto.

DESCARTÁVEL – objeticvo é entender os requisitos do SW.




MODELO DE PROCESSO DE SOFTWARE Prototipação.




Concurrentactivities

ValidationFinal

version

DevelopmentIntermediate

versions

SpecificationInitial

version

Outlinedescription

Prototipação.



Fluxo de Trabalho

Reunião dos requisitos

Definição dos objetivos em conjunto (cliente e desenvolvedor) identificando áreas de risco.

Projeto rápido focando o que é visível ao usuário (entradas e saídas).

Refinamento dos requisitos e avaliação do protótipo.

Processo iterativo até cliente e desenvolvedor estarem satisfeitos.




Vantagens:

Redução de risco em função de requiistos de usuário incorretos.

Alternativa quando existe grande frequencia de mudança nos requisitos sem um comprometimento do cliente.

Progresso facilmente visto auxilia o gerenciamento.

Viabiliza o marketing antecipado do produto.




Desvantagens:

Falta de visibilidade do processo.

Idealização do protótipo como “resolvedor” dos problemas.

Conscientização do cliente, que ignora a função do protótipo.

SWs são frequentemente estruturados probremente (Concessões na escolha da arquitetura e infra-estrutura do SW para ateder äs expectativas do cliente).

Necessidade de conhecimento sobre ferramentas de prototipação.




Aplicação:

SWs de pequeno porte e alto grau de interação.

Parte de SWs de grande porte (p. ex. Interfaces gráficas)

SWs de curta duração.




Processos Iterativos

MODELO DE PROCESSO DE SOFTWARE Requisitos de sistema sempre evoluem durante o

desenvolvimento de um projeto de SW.

Desta forma, o retorno a estágios anteriores para alteração do projeto é sempre parte do processo de desenvolvimento, principalmente em SW de grande porte ou grande complexidade.

A inclusão da iteração como parte do processo de desenvolvimento de SW pode ser aplicada em qualquer modelo de processo..

Modelos iterativos: Modelo Incremental

Modelo Espiral



Modelo Incremental

O desenvolvimento e entrega do SW é dividido em incrementos.

Cada incremento é uma parte das funcionalidades requeridas eplo cliente.

Os requisitos do usuário são priorizados e aqueles com prioridade mais alta são incluídos nos primeiros incrementos.

Aplica sequencias lineares de forma racional à medida que o tempo passa.

Cada sequência produz um “incremento” factível do software.

Primeiro incremento – núcleo do produto




“Em um processo de desenvolvimento incremental, os clientes identificam, em um esboço, as funções a serem fornecidas pelo sistema, Eles identificam quais as funções são mais importantes e quais as menos importantes para eles. Em seguida é definida uma série de estágios de entrega, com cada estágio fornecendo um subconjunto das funcionalidades do sistema. A alocação de funções aos estágios depende da prioridade da função. As funções prioritárias são entregues primeiro ao cliente”. Sommerville (2007)

MODELO DE PROCESSO DE SOFTWAREModelo Incremental



Definir esboço dos requisitos

Atribuir requisitos aos incrementos

Projetar arquitetura do sistema

Desenvolver incremento do sistema Validar

incremento Integrar incremento

Validar sistema




Vantagens:

Os clientes não precisam esperar até o todo o sistema seja entregue.

Os clientes podem utilizar os primeiros incrementos como um protótipo para obter experiência sobre o sistema.

Existe um risco menor de fracasso completo do sistema.

Os serviços mais prioritários do SW tendem a receber a maior carga de teste..




Desvantagens:

Os incrementos devem ser relativamente pequenos.

Pode ser difícil mapear os requisistos dos clientes dentro de incrementos de tamanho “correto”.

A amioria dos sistemas exige um conjunto de funcionalidades básicas que são usadas por diferentes partes do sistema.




O processo de desenvolvimento do SW é representado com uma Espiral.

Considera o fato REAL de que a maioria dos SWs evoluem antes da entrega do produto.

Cada volta na Espiral representa uma nova fase no processo.

Em cada iteração, planos, custos, riscos e cronogramas sao atualizados e o gerente de projeto obtém maioroes informações sobre o SW e sobre a necessidade de mais iterações.

Meta modelo - qualquer ciclo pode ser usado na fase de desenvolvimento.

A análise de risco é explicitamente considerada.

MODELO DE PROCESSO DE SOFTWAREModelo Espiral



MODELO DE PROCESSO DE SOFTWAREModelo Espiral - fases

Comunicação com o cliente – tarefas específicas para estabelecer a comunicação efetiva entre desenvovledor e cliente

Planejamento – definição de recursos, prazos e outras informações para o gerenciamento do projeto.

Análise de risco – consideração dos riscos gerenciais e técnicos. Engenharia – construção dos modelos da aplicação (um ou mais

modelos). Construção e entrega - implementação, teste, instalação e suporte ao

usuário (documentação e treinamento). Avaliação – obtenção de feedback do cliente sobre o SW.




Vantagens:

Realismo – o modelo reflete a natureza iterativa do desenvolvimento do SW.

Flexibilidade – combina vantagens do modleo cascata com o modelo evolutivo.

Análise efetiva dos riscos.




Desvantagens:

Necessita de pessoas experientes em análise e gerenciamento de risco para que o modelo funcione bem.

O modelo não é facilemtne entendido pelos gerentes da área usuária.

O modelo é complexo e necessita de gerenciamento especializado, o que causa um overhead administrativo.



Baseado na reutilização sistemática de componeentes de SW.

Conta com um abase de componenetes de SW reutilizáveis , que podem ser acessados, e com uma infra-estrutura de integração para esses componentes.

Composto dos seguintes estágios:

Especificação de requisitos

Análise de Componentes

Modificação de requisitos

Projeto de sistema com reuso

Desenvolvimento e integração

Validação do software

MODELO DE PROCESSO DE SOFTWARE Desenvolvimento orientado ao reuso



Especificação de requisitos

Análise de Componentes

Modificação de requisitos

Projeto de sistema com reuso

Desenvolvimento e integração Validação do

sistema




Vantagens: Redução da quantidade de software produzida

Redução de custos e riscos

Entrega mais rápida do software

Desvantagens: Necessária adequações nos requisitos

Não atendimento às reais necessidades dos usuários

Alguma perda de controle sobre o sistema (componentes reutilizáveis fora do alcance).




UP – unified process


Um dos modelos de processo de desenvolvimento mais utilizado atualmente é o Processo Unificado (UP – unified process).

O UP foi construído pelos mesmos criadores da UML e, desta forma, é fortemente baseado na modelagem visual e utiliza largamente os artefatos produzidos por esta liguagem como documentos resultantes das etapas (fases) do processo de desenvolvimento.



Características: Processo iterativo e incremental

UP – unified process




O agrupamento de atividades em fases no Processo Unificado (UP) acontece sob duas dimensões:

A dimensão horizontal representa o tempo e mostra aspectos do ciclo de vida do processo. São os aspectos dinâmicos do processo expresso em termos de ciclos, fases, iterações e marcos.

A dimensão vertical representa a organização do processo em termos de atividades e fluxo de trabalho. Representa os aspectos estáticos do processo.

UP – unified process - DIMENSÕES




UP – unified process - DIMENSÕES




UP – unified process – FASES: dimensão tempo (horizontal)




Requisitos

Ambiente

Análise e Projeto

Implementação

Gerenciamento de projetos

Testes

Implantação

Gerenciamento de mudanças

Modelagem de negócio

workflow

UP – unified process – DISCIPLINAS: dimensão fluxo de trabalho (vertical)




UP – unified process – DISCIPLINAS: dimensão fluxo de trabalho (vertical)




Iteração e disciplinas do processo unificado

P r e lim in a ry

I te ra t io n (s )ite r.

# 1

ite r.

# 2

ite r.

# n

ite r.

# n + 1

ite r.

# n + 2

ite r.

# m

ite r.

# m + 1

Inception Elaboration Construction Transition

PhasesCore Workflows

An ite ration in theelaboration phase

Requirements

Design

Implementation

Test

Analysis



Combinação de Paradigmas.

Extrair peculiaridades de cada paradigma em um único projeto.

A natureza da aplicação e o ambiente organziacional são os fatores que devem indicar o modelo (ou modelos) de processo a ser aplicado no desenvolvimento do SW.

O todo É maior do que a soma das partes




Exemplos:

Combinação de paradigmas:

evolutivo com cascata – prototipação de interfaces.

Exemplos de análise de ambiente:

ambiente estável e software científico – modelo cascata

ambiente turbulento e software comercial – modelo evolutivo (prototipação).


02 - modelos de processo de sw.ppt

Documents