Aula 03 - Processos de Software

(1)

Engenharia de Software

Processos de Software

Marcelo Marinho

(2)

Um Conjunto estruturado de atividades, procedimentos, artefatos e ferramentas necessários para o

(3)

O Processo de Software

 Embora exista muitos processos de software diferentes, algumas atividades fundamentais são comuns a todos eles, como:

 Especificação;  Projeto;

 Validação;  Evolução;

(4)

Processo

• Conjunto de atividades

– Bem definidas;

– com responsáveis;

– Com artefatos de entrada e saída;

– Com dependências entre as mesmas e ordem de execução;

(5)

Processo

• É uma ação regular e contínua (ou sucessão de ações) realizada de forma bem definida, levando a um resultado;

• É um conjunto parcialmente ordenado de atividades

(ou passos) para se atingir um objetivo;

• Define quem está fazendo o que, quando e como para atingir um certo objetivo;

(6)

Modelos de Processo de Software

• (Def:) Uma

representação abstrata

e

simplificada do processo de desenvolvimento

software, tipicamente mostrando as principais

atividades e dados usados na produção e

manutenção de software;

• Cada modelo de processo representa um

(7)

Modelo de Processo

• É uma representação de um processo, usualmente envolvendo

– Atividades a serem realizadas

– Agentes que realizam as atividades – Artefatos (produtos) gerados

(8)

Modelo de Processo

• Um modelo é usado para entendimento e comunicação do processo, e como base para análise, execução, gerência e melhoria do processo;

• Idealmente a descrição deve ser formal e completa

para permitir, por exemplo, automação;

• A descrição deve ser apresentada em diferentes níveis de abstração.

(9)

Principais Modelos do Processo de

Software

• Cascata

• Modelo de Desenvolvimento Evolucionário

– Programação Exploratória – Prototipagem descartável

• Modelo de Transformação Formal

• Modelos Iterativos

– Espiral

(10)

Principais Modelos do Processo de

Software

• Cascata

• Modelo de Desenvolvimento Evolucionário

– Programação Exploratória

– Prototipagem descartável

• Modelo de Transformação Formal

• Modelos Iterativos

– Espiral

(11)

Modelo Cascata

(ou clássico)

• Derivado de modelos existentes em outras engenharias.

• Sua estrutura é composta por várias etapas que são executadas de forma sistemática e seqüencial.

• Na prática, existe uma interação entre as etapas e

cada etapa pode levar a modificações nas etapas anteriores.

(12)

Modelo Cascata

Definição de Requisitos Projeto do Sistema e do Software Implementação e Testes Unitários Integração e Teste do Sistema Operação e Manutenção

(13)

Modelo Cascata na Prática

Definição de Requisitos Projeto do Sistema e do Software Implementação e Testes Unitários Integração e Teste do Sistema Operação e Manutenção

(14)

Problemas do Modelo em Cascata

• Particionamento inflexível do projeto em estágios distintos,

dificulta a resposta aos requisitos de mudança do cliente;

• Documentos “completamente elaborados” são necessários para fazer as transições entre os estágios;

• Poucos sistemas de negócios têm requisitos estáveis;

• O modelo cascata é o mais usado em projetos de engenharia de sistemas de grande porte, onde um sistema é desenvolvido em várias localidades.

(15)

Principais Modelos do Processo de

Software

• Cascata

• Modelo de Desenvolvimento Evolucionário

• Modelo de Transformação Formal

• Modelos Iterativos

– Espiral

(16)

Modelo de Desenvolvimento

Evolucionário

• Programação Exploratória

• Prototipagem Descartável

Atividades Concorrentes Especificação Desenvolvimento Validação Esboço de Descrição Versão Inicial Versões Intermediárias Versão Final

(17)

Modelo de Desenvolvimento

Evolucionário -

Programação Exploratória

• Idéia geral:

– Desenvolvimento da primeira versão do sistema o mais rápido possível;

– Modificações sucessivas até que o sistema seja considerado adequado;

– Após o desenvolvimento de cada uma das versões do sistema ele é mostrado aos usuários para comentários;

• Adequado para o desenvolvimento de sistemas onde é difícil ou impossível se fazer uma especificação detalhada do sistema.

• Principal diferença para os outros modelos é a ausência da noção de programa correto.

(18)

Modelo de Desenvolvimento

Evolucionário -

Programação Exploratória

• Tem sido mais usada no desenvolvimento de

sistemas especialistas - geralmente sistemas que tentam emular capacidades humanas.

• A maioria dos sistemas desenvolvidos com sucesso

usando a programação exploratória foi

implementada usando pequenos grupos de

(19)

Modelo de Desenvolvimento

Evolucionário -

Prototipagem Descartável

• Como na programação exploratória, a primeira fase prevê o desenvolvimento de um programa para o usuário experimentar

– No entanto, o objetivo aqui é estabelecer os requisitos do sistema.

– O software deve ser reimplementado na fase seguinte.

• A construção de protótipos com os quais os usuários possam brincar é uma idéia bastante atrativa:

– Para sistemas grandes e complicados.

– Quando não existe um sistema anterior ou um sistema manual que ajude a especificar os requisitos.

(20)

Modelo de Desenvolvimento

Evolucionário -

Prototipagem Descartável

• Os objetivos do protótipo devem estar bem claros antes do início da codificação. Possíveis objetivos:

– Entender os requisitos dos usuários – Definir a interface com os usuários

– Demonstrar a viabilidade do sistemas para os gerentes.

• Uma decisão importante a ser tomada é escolher o que será e o que não será parte do protótipo

– Não é economicamente viável implementar todo o sistema!

(21)

Problemas da Abordagem

Evolucionária

• O processo não é visível:

– Os gerentes precisam de produtos regulares para medir o progresso;

– Se os sistemas são desenvolvidos rapidamente, não é viável produzir documentos que reflitam cada versão do sistema;

• Os sistemas são frequentemente mal Estruturados:

– A mudança continua tende a corromper a estrutura do software;

– A incorporação de mudanças torna-se cada vez mais difícil e onerosa;

(22)

Principais Modelos do Processo de

Software

• Cascata

• Modelo de Desenvolvimento Evolucionário

• Modelo de Transformação Formal

• Modelos Iterativos

– Espiral

(23)

Modelo de Desenvolvimento

Baseado em Reuso

• Baseado no reuso sistemático de componentes existentes ou sistemas COTS (Commercial-off-the-shelf)

• Etapas do processo

– Especificação dos requisitos – Análise de componentes – Modificação dos requisitos – Projeto de sistema com reuso – Desenvolvimento e integração – Validação

• Esta abordagem está se tornando mais importante, mas há ainda pouca experiência com ela.

(24)

Modelo de Desenvolvimento

Baseado em 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

(25)

Principais Modelos do Processo de

Software

• Cascata

• Modelo de Desenvolvimento Evolucionário

• Modelo de Transformação Formal

• Modelos Iterativos

– Espiral

(26)

Modelos Iterativos

• Requisitos de sistema SEMPRE evoluem durante curso de um projeto. Assim a iteração do processo sempre faz parte do desenvolvimento de grandes sistemas

• Iterações podem ser aplicadas a quaisquer dos modelos de ciclo de vida

• Duas abordagens (relacionadas)

– Desenvolvimento espiral

(27)

Desenvolvimento Espiral

• Acrescenta aspectos gerenciais ao processo de desenvolvimento de software.

– Análise de riscos em intervalos regulares do processo de desenvolvimento de software

– Planejamento – Controle

– Tomada de decisão

• O processo é representado como uma espiral em vez de uma seqüência de atividades

• Cada volta na espiral representa uma fase no processo

• Não há fases fixas como especificação ou projeto - voltas na espiral são escolhidas dependendo do que é requerido

• Riscos são avaliados explicitamente e resolvidos ao longo do processo

(28)

Desenvolvimento Espiral

(29)

Desenvolvimento Incremental

• Em vez de entregar o sistema como um todo, o desenvolvimento e a entrega são divididos em incrementos, com cada incremento entregando parte da funcionalidade requerida.

• Requisitos dos usuários são priorizados e os requisitos de mais alta

prioridade são incluídos nas iterações iniciais

• Uma vez que o desenvolvimento de um incremento é iniciado, os requisitos são "congelados". Embora os requisitos possam continuar a evoluir para incrementos posteriores

• Em certos aspectos é similar à programação exploratória. No entanto, o escopo do sistema deve ser claramente entendido antes de se iniciar o desenvolvimento

(30)

Desenvolvimento Incremental

Definir esboço dos requisitos Associar requisitos a incrementos Projetar a arquitetura do sistema Desenvolver um incremento Validar o incremento Integrar o incremento Validar o sistema Sistema Final

(31)

Vantagens do Desenvolvimento

Incremental

• Incrementos

podem ser

entregues

regularmente

ao cliente e, desse modo, a funcionalidade do

sistema é disponibilizada mais cedo;

• O incremento inicial age como um protótipo para

auxiliar a elicitar os requisitos para incrementos

posteriores do sistema

• Riscos menores de falhas gerais do projeto;

• Os serviços de sistemas de mais alta prioridade

tendem a receber mais testes;

(32)

Exemplos de processos

• Processos tradicionais (pesados)

– RUP, OPEN, Catalysis • Processos ágeis (leves)

– XP, Agile modeling, Crystal, pragmatic programming, Internet Speed, ...

(33)

Exemplos de processos

• Consenso em torno de – Iteratividade;

– Participação de usuários;

– Flexibilidade de configuração para projetos específicos;

(34)

Exemplos de processos

• Divergências em torno de

Detalhamento de atividades a serem seguidas Critério de conclusão da execução das atividades

Arquitetura robusta (RUP)

Arquitetura para o contexto da iteração atual (agile modeling)

Rigor na atribuição de tarefas a responsáveis

workers (RUP)

alocação sob demanda e interesse (XP)

Artefatos (documentação) gerados Nível de Automação

(35)

(36)

Contexto

• Necessidade de software cada vez mais complexo, melhor e mais rápido;

• Os métodos de desenvolvimento não evoluíram a contento

– É necessário um processo que integre as muitas facetas do desenvolvimento.

• Não é suficiente apenas a presença de desenvolvedores altamente treinados

(37)

Precisamos de um processo que

• Defina um guia que controle as atividades do time de

desenvolvimento;

• Direcione as tarefas para desenvolvedores específicos;

• Especifique que artefatos precisam ser desenvolvidos nas etapas do desenvolvimento;

• Ofereça critérios para monitorar as atividades e os produtos de um projeto

(38)

O que é o RUP?

• O nome é uma abreviação de Rational Unified

Process

– mas na verdade é

• Processo + Métodos + Linguagem (UML)

– e os autores argumentam que é

(39)

O que é o RUP?

• Conjunto de atividades

– bem definidas – com responsáveis

– com artefatos de entrada e saída

– com dependências entre as mesmas e ordem de execução – com modelo de ciclo de vida

– descrição sistemática de como devem ser realizadas – guias (de ferramentas ou não), templates

(40)

Características Principais do RUP

• O desenvolvimento de sistemas seguindo o RUP é

– Iterativo e incremental

– Guiado por casos de uso (use cases) – Centrado na arquitetura do sistema

(41)

(42)

 papel (responsável)  atividade

 produto de trabalho (artefato)  fluxo de trabalho (workflow)

(43)

papel

define as responsabilidades e o papel desempenhado por um indivíduo ou uma equipe

ex: analista de sistema, programador

atividade

unidade de trabalho, desempenhada por um responsável, e que produz um resultado expresso em termos de criação ou atualização de produtos de trabalho

(44)

produto de trabalho

peça de informação que é produzida, modificada ou usada pelo processo de desenvolvimento

pode ser um modelo ou um documento

ex: Modelo de Análise, Documento de Especificação de Requisitos

fluxo de trabalho

seqüência de atividades que produz um resultado de valor observável

(45)

(46)

O RUP é iterativo e incremental

• O ciclo de vida de um sistema consiste de quatro fases:

 Concepção (define o escopo do projeto)

 Elaboração (detalha os requisitos e a arquitetura)  Construção (desenvolve o sistema)

 Transição (implanta o sistema)

tempo

(47)

Concepção

• Estabelecer o escopo da versão a ser produzida • Capturar os requisitos e as restrições, bem como

elaborar os critérios de aceitação

• Avaliar alternativas para gerenciamento de riscos, planejar o projeto, e identificar restrições de custo e prazo

• Principais artefatos: Modelo de Casos de Uso e Documento de Especificação de Requisitos

(48)

Elaboração

• Estabelecer uma arquitetura e demonstrar que esta arquitetura suporta os requisitos do sistema

• Estabelecer um entendimento sólido dos casos de uso mais críticos que dirigem as decisões de planejamento e de arquitetura

• Criar os subsídios necessários para a realização da fase de Construção

• Os Modelos de Análise e de Projeto são os principais artefatos produzidos nesta fase

(49)

Construção

• Minimizar custos de desenvolvimento, otimizando recursos e evitando re-trabalho

• Finalizar a análise, projeto, implementação, e testes de todas as funcionalidade requeridas da versão

• Criar versões (alfa, beta) usáveis para teste

• O Modelo de Implementação é o principal produto de trabalho produzido nesta fase

(50)

Transição

• Realizar beta testes para validar a versão do sistema com relação às expectativas dos usuários

• Treinar os usuários

• Obter concordância de que o produto está consistente com os critérios de aceitação

• Disponibilizar a versão em produção

• O Modelo de Implementação e a Unidade de Implantação são os principais produtos de trabalho atualizado/produzido nesta fase

(51)

O RUP é iterativo e incremental

• Cada iteração – é planejada

– realiza uma sequencia de atividades (de elicitação de requisitos, análise e projeto, implementação, etc.) distintas

– geralmente resulta em uma versão executável do sistema

– é avaliada segundo critérios de sucesso previamente definidos

(52)

(53)

O RUP é guiado por casos de uso

• Os casos de uso não servem apenas para definir os requisitos do sistema

• Várias atividades do RUP são guiadas pelos casos de uso:

– planejamento das iterações

– criação e validação do modelo de projeto – planejamento da integração do sistema – definição dos casos de teste

(54)

O RUP é centrado na arquitetura do

sistema

• Arquitetura

– visão geral do sistema em termos dos seus subsistemas e como estes se relacionam

• A arquitetura é prototipada, definida e validada nas primeiras iterações da fase de elaboração

• O desenvolvimento consiste em complementar a arquitetura

• A arquitetura serve para definir a organização da equipe de desenvolvimento e identificar oportunidades de reuso

(55)

Organização do RUP

• Fluxos de atividades • Atividades

– passos

– entradas e saídas

– guias (de ferramentas ou não), templates • Responsáveis (papel e perfil, não pessoa) • Artefatos

(56)

RUP...

• http://www.wthreex.com/rup/portugues/inde

x.htm

(57)

Referências

• Ivar Jacobson, Grady Booch e James Rumbaugh. The

Unified Software Development Process. Capítulos 1 a

5.

• Philippe Kruchten. The Rational Unified Process – an

(58)