Anda di halaman 1dari 45

Visão Geral sobre Ciclo de Vida de Software, Processos e RUP

Alexandre Monteiro

1/45

Ciclo de Vida e Processo de Desenvolvimento de Software
2/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

3/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
4/45

existe uma interação entre as etapas e cada etapa pode levar a modificações nas etapas anteriores 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.

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 6/45 .

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 7/45 .

Modelo de Desenvolvimento Evolucionário   Programação Exploratória Prototipagem Descartável Atividades Concorrentes Versão Inicial Especificação Esboço de Descrição Desenvolvimento Versões Intermediárias Validação Versão Final 8/45 .

Programação Exploratória  Idéia geral:      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 9/45 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 .

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 10/45 .Programação Exploratória   Tem sido mais usada no desenvolvimento de sistemas especialistas .

Prototipagem Descartável  Como na programação exploratória. o objetivo aqui é estabelecer os requisitos do sistema O software deve ser reimplementado na fase seguinte Para sistemas grandes e complicados Quando não existe um sistema anterior ou um sistema manual que ajude a especificar os requisitos 11/45 . a primeira fase prevê o desenvolvimento de um programa para o usuário experimentar    A construção de protótipos com os quais os usuários possam brincar é uma idéia bastante atrativa:   No entanto.

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 12/45 .Prototipagem Descartável   Os objetivos do protótipo devem estar bem claros antes do início da codificação.

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. 13/45 esp. 1 . 2 implement.Transformação Formal  Idéia geral:  Uma especificação formal (definição matemática.

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   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) 14/45 O próprio processo de desenvolvimento deve grantir que o programa faz exatamente o que foi especificado .

Modelo de Desenvolvimento Baseado em Reuso   Baseado no reuso sistemático de componentes existentes ou sistemas COTS (Commercial-offthe-shelf) Etapas do processo        Esta abordagem está se tornando mais importante. mas há ainda pouca experiência com ela 15/45 Especificação dos requisitos Análise de componentes Modificação dos requisitos Projeto de sistema com reuso Desenvolvimento e integração Validação .

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 16/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 17/45 .

        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 18/45 longo do processo análise de riscos em intervalos regulares do processo de desenvolvimento de software planejamento controle tomada de decisão .Desenvolvimento Espiral  Acrescenta aspectos gerenciais ao processo de desenvolvimento de software.

Desenvolvimento Espiral Determinação dos objetivos. modelos e benchmarks Planejamento Desenvolvimento e validação da versão corrente do produto 19/45 . alternativas e restrições Análise das alternativas e identificação e/ou resolução de riscos Análise de Riscos Simulações.

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. o desenvolvimento e a entrega são divididos em incrementos. Embora os requisitos possam continuar a evoluir para incrementos posteriores Em certos aspectos é similar à programação exploratória. No entanto.Desenvolvimento Incremental     Em vez de entregar o sistema como um todo. o escopo do sistema deve ser claramente entendido antes de se iniciar o desenvolvimento 20/45 . os requisitos são "congelados".

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 21/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 22/45 .

Processo    é uma ação regular e contínua (ou sucessão de ações) realizada de forma bem definida. quando e como para atingir um certo objetivo 23/45 . levando a um resultado é um conjunto parcialmente ordenado de atividades (ou passos) para se atingir um objetivo define quem está fazendo o que.

Processo versus Metodologia  Alguns autores consideram que processos incluem     Outros consideram que uma metodologia é a especialização de um processo com um conjunto de métodos 24/45 uma metodologia pessoas tecnologia (suporte de ferramentas) .

Método    Descrição sistemática de como devese 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. 25/45 .

usualmente envolvendo     atividades a serem realizadas agentes que realizam as atividades artefatos (produtos) gerados recursos necessários (consumidos) 26/45 .Modelo de Processo  é uma representação de um processo.

Modelo de Processo    Um modelo é usado para entendimento e comunicação do processo. e como base para análise. por exemplo. gerência e melhoria do processo Idealmente a descrição deve ser formal e completa para permitir. execução. automação A descrição deve ser apresentada em diferentes níveis de abstração 27/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  Mas há esforço de padronização (SPEM – OMG) 28/45 .

Catalysis  Processos ágeis (leves)  XP. pragmatic programming. Internet Speed. Scrum.. OPEN. 29/45 . Agile modeling.. Crystal. .Exemplos de processos  Processos tradicionais (pesados)  RUP.

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 30/45 .

Exemplos de processos  Divergências   Detalhamento de atividades a serem seguidas Critério de conclusão da execução das atividades    Rigor na atribuição de tarefas a responsáveis  Arquitetura robusta (RUP) Arquitetura para o contexto da iteração atual (agile modeling) workers (RUP) alocação sob demanda e interesse (XP)     Artefatos (documentação) gerados Nível de Automação Nível de (im)pessoalidade 31/45 .

???   E todo o esforço de consolidação da Engenharia de Software como uma ciência exata??? 32/45 ... afinal o desenvolvimento de software é Arte+Sociologia+Psicologia+. ou  Lógica+Modelos+Engenharia+...Polêmica  Se a tendência é processos leves.

Visão Geral do RUP 33/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 34/45 .

templates utilizando diagramas de UML 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).

Características Principais do RUP  O desenvolvimento de sistemas seguindo o RUP é    Iterativo e incremental Guiado por casos de uso (use cases) Baseado na arquitetura do sistema 36/45 .

O RUP é iterativo e incremental  O ciclo de vida de um sistema consiste de quatro fases: elaboração construção transição concepção tempo     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) 37/45 .

iteration Devel.. iteration Transition iteration Transition iteration Minor Milestones: Releases 38/45 .O RUP é iterativo e incremental  Cada fase é dividida em iterações: Elaboration Construction Inception Transition Preliminary iteration Architect. iteration iteration iteration Devel. Architect. Devel...

O RUP é iterativo e incremental  Cada iteração     é planejada realiza uma seqüência de atividades (de elicitação de requisitos.) distintas geralmente resulta em uma versão executável do sistema é avaliada segundo critérios de sucesso previamente definidos 39/45 . análise e projeto. implementação. etc.

O RUP é iterativo e incremental 40/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 41/45 .

O RUP é baseado na arquitetura do sistema  Arquitetura     A arquitetura é prototipada e definida logo nas primeiras iterações O desenvolvimento consiste em complementar a arquitetura A arquitetura serve para definir a organização da equipe de desenvolvimento e identificar oportunidades de reuso 42/45 visão geral do sistema em termos dos seus subsistemas e como estes se relacionam .

templates 43/45 .Organização do RUP   Fluxos de atividades Atividades      Responsáveis (papel e perfil. não pessoa) Artefatos passos entradas e saídas guias (de ferramentas ou não).

Exemplo de Fluxo: Planejamento e Gerenciamento Iniciar Projeto Contratante Aprovar Projeto Atestar Conclusão do Projeto Identificar Riscos Estudar Viabilidade Executar Plano de Iteração Desenvolver Plano de Projeto Gerente de projeto Desenvolver Plano de Iteração Reavaliar Riscos Avaliar Iteração Finalizar Projeto Arquiteto Priorizar Casos de Uso 44/45 .

Referências   Ivar Jacobson. The Unified Software Development Process. 45/45 . The Rational Unified Process – an Introduction. Philippe Kruchten. Grady Booch e James Rumbaugh. Capítulos 1 a 5.