1/45
Visão Geral sobre Ciclo de Vida de Software, Processos e RUP
Alexandre Vasconcelos([email protected])
2/45
Ciclo de Vida e Processo de Desenvolvimento de
Software
3/45
O que é um modelo de ciclo de vida de processo de software? 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
4/45
Principais Modelos do Ciclo de Vida de Software Cascata Modelo de Desenvolvimento
Evolucionário Programação Exploratória Prototipagem descartável
Modelo de Transformação Formal Modelos Iterativos
Espiral Incremental
5/45
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
6/45
Modelo CascataDefiniçã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
7/45
Modelo Cascata na PráticaDefiniçã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
8/45
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
9/45
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
10/45
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 profissionais altamente qualificados e motivados
11/45
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
12/45
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! Os objetivos do protótipo são o ponto de partida
13/45
Transformação Formal Idéia geral:
Uma especificação formal (definição matemática, não ambígua) do software é desenvolvida e posteriormente “transformada” em um programa através de regras que preservam a corretude da especificação
esp. 2esp. 1 implement.
14/45
Transformação Formal A grande motivação por trás da idéia de
refinamento formal é a possibilidade de gerar automaticamente programas que são corretos por construção O próprio processo de desenvolvimento deve
grantir que o programa faz exatamente o que foi especificado
Este modelo tem sido aplicado ao desenvolvimento de sistemas críticos, especialmente naqueles onde a segurança é um fator crítico (ex: sistema de controle de tráfego aéreo)
15/45
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
16/45
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
17/45
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 Desenvolvimento incremental
18/45
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
19/45
Desenvolvimento Espiral
Determinação dos objetivos, alternativas e restrições
Análise de Riscos
Análise das alternativas e identificação e/ou resolução de riscos
Desenvolvimento e validação da versão corrente do produto
Simulações,modelos e benchmarks
Planejamento
20/45
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
21/45
Definiresboço dosrequisitos
Associarrequisitos aincrementos
Projetar aarquitetura dosistema
Desenvolverumincremento
Validar oincremento
Integrar oincremento
Validar osistema
SistemaFinal
Desenvolvimento Incremental
22/45
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 com modelo de ciclo de vida
23/45
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
24/45
Processo versus Metodologia Alguns autores consideram que
processos incluem uma metodologia pessoas tecnologia (suporte de ferramentas)
Outros consideram que uma metodologia é a especialização de um processo com um conjunto de métodos
25/45
Método Descrição sistemática de como
deve-se realizar uma determinada atividade ou tarefa
A descrição é normalmente feita através de padrões e guias
Exemplos: Método para descoberta de atores e casos de uso no RUP.
26/45
Modelo de Processo é uma representação de um
processo, usualmente envolvendo atividades a serem realizadas agentes que realizam as atividades artefatos (produtos) gerados recursos necessários (consumidos)
27/45
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
28/45
Modelo de Processo O formalismo utilizado para representar o
processo é o ingrediente mais importante da modelagem
Não parece haver consenso sobre um formalismo ideal Terminologias distintas
Fase, workflow, domínio, disciplina, Atividade Mas há esforço de padronização (SPEM e
BPMN – OMG)
29/45
Exemplos de processos Processos tradicionais (pesados)
RUP, OPEN, Catalysis Processos ágeis (leves)
XP, Agile modeling, Crystal, pragmatic programming, Internet Speed, Scrum, ...
30/45
Exemplos de processos Consenso em torno de
Iteratividade Participação de usuários Flexibilidade de configuração para
projetos específicos Comunicação entre membros da
equipe
31/45
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 Nível de (im)pessoalidade
32/45
Polêmica Se a tendência é processos leves, afinal o
desenvolvimento de software é Arte+Sociologia+Psicologia+...
ou Lógica+Modelos+Engenharia+...???
E todo o esforço de consolidação da Engenharia de Software como uma ciência exata???
Compromisso Balancing agility and discipline
33/45
Visão Geral do RUP
34/45
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 é
Framework para gerar processos
35/45
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 utilizando diagramas de UML
36/45
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
37/45
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
concepção elaboração construção transição
38/45
O RUP é iterativo e incremental Cada fase é dividida em iterações:
Minor Milestones: Releases
Inception Elaboration Construction Transition
Transitioniteration
Preliminaryiteration
Architect.iteration
Architect.iteration
Devel..iteration
Devel..iteration
Devel..iteration
Transitioniteration
39/45
O RUP é iterativo e incremental Cada iteração
é planejada realiza uma seqüência 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
40/45
O RUP é iterativo e incremental
41/45
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
42/45
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
43/45
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
44/45
Exemplo de Fluxo: Planejamento e Gerenciamento
Gerente de projeto
Arquiteto
Contratante
Iniciar Projeto
Aprovar Projeto
Estudar Viabilidade
Atestar Conclusão do Projeto
Identificar Riscos
Desenvolver Plano de Projeto
Desenvolver Plano de Iteração
Executar Plano de Iteração
Avaliar Iteração
Finalizar Projeto
Reavaliar Riscos
Priorizar Casos de
Uso
45/45
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 Introduction.