1 anÁlise e projeto no processo de desenvolvimento de software processo: conceito modelos de...
Post on 16-Apr-2015
120 Views
Preview:
TRANSCRIPT
1
ANÁLISE E PROJETO NO PROCESSO DE DESENVOLVIMENTO DE SOFTWARE
PROCESSO: CONCEITO
MODELOS DE PROCESSO
PROCESSO UNIFICADO
HISTÓRIA
CARACTERÍSTICAS
AS QUATRO FASES
OS WORKFLOWS
MODELAGEM NO RUP
2
I . PROCESSO: CONCEITO
Quando elaboramos um produto ou sistema é importante percorrer uma série de passos previsíveis – um roteiro que ajuda a criar um resultado de alta qualidade no tempo que foi previsto.
O roteiro que seguimos é chamado processo de sof tware.
3
É importante termos um processo porque ele f ornece
estabilidade, controle e organização
No entanto, uma abordagem moderna de engenharia de sof tware precisa ser ágil, contendo atividades, controles e documentação adequados à equipe de projeto e ao produto que deve ser produzido.
4
I I . MODELOS DE PROCESSO CASCATA
Análise de requisitos de software: esta etapa tem como objetivo o entendimento da natureza do sof tware a ser desenvolvido. O engenheiro de sof tware deve obter detalhes sobre as informações, as f unções, o comportamento, o desempenho e a interface. Os requisitos devem ser documentados e revistos com o cliente.
Projeto: nesta etapa os requisitos são traduzidos para uma representação do sof tware que pode ser avaliada quanto à qualidade, antes que a codificação seja iniciada. Da mesma forma que na etapa anterior, o projeto deve ser documentado.
Codificação: nesta etapa é elaborado o código Teste: uma vez gerado o código, o teste é iniciado.
Análise Projeto
Codificação Teste
5
Características do modelo:
Linear: o desenvolvimento do sof tware procede linearmente do início ao fi m do processo.
Rígido: Os resultados de cada f ase são congelados antes de se passar para a próxima f ase.
Críticas:
Os projetos raramente seguem o fluxo seqüencial que o modelo propõe.
Tem dificuldade de acomodar a incerteza natural que existe no começo dos projetos.
O cliente deve ter paciência já que uma versão do trabalho só está disponível num ponto tardio do cronograma.
6
I NCREMENTAL
Podemos observar ao desenvolver determinados sistemas que os seus requisitos mudam f reqüentemente ao longo do desenvolvimento. Nesse caso é importante que tenhamos um modelo de processo que não seja rígido, como o modelo cascata
No modelo incremental a abordagem do modelo cascata, que é
seqüencial é combinada com uma abordagem iterativa. É enfatizado um desenvolvimento em fases através da realização de mini-projetos (chamados de incrementos).
Veremos a seguir exemplo de um processo incremental.
7
I I I . PROCESSO UNIFICADO
Processo Unificado – um conjunto de atividades executadas para transformar os requisitos do cliente em um sistema de sof tware.
Também é uma estrutura (f ramework) genérica de
processo que pode ser customizada. De acordo com as características do projeto podem ser adicionadas ou removidas atividades.
RUP (Rational Unifi ed Process) – é uma versão
especializada do Processo Unifi cado. É também um produto que é vendido e está integrado a um conjunto de ferramentas de desenvolvimento de sof tware que podem ser adquiridas separadamente.
8
HISTÓRIA
Final da década de 60 I var J acobson e sua equipe na Ericsson modelaram um sistema de telecomunicações muito grande utilizando vários dos diagramas que hoje f azem parte da UML.
1987 J acobson deixou a Ericsson criando uma
companhia chamada Objectory AB. Lá f oi desenvolvido o Objectory, um processo e um produto, assim como o RUP.
9
Pouco tempo depois a Rational comprou a ObjectoryAB.
Booch e Rumbaugh já estavam na Rational e os três juntos f oram os líderes do projeto do Processo Objectory da Rational em paralelo com o projeto da UML.
A Rational continuou a adquirir ou se fundir com várias empresas que fabricavam ferramentas de desenvolvimento de sof tware.
1998 A Rational mudou o nome de seu processo para
RUP.
Em fi ns de 2003 f oi anunciada a incorporação da Rational pela I BM
10
CARACTERÍSTICAS
É um processo iterativo As atividades enfatizam a criação de modelos É orientado por casos de uso O desenvolvimento é centrado em arquitetura É um processo confi gurável
11
AS QUATRO FASES
A vida de um sistema pode ser representada por uma
série de ciclos. E no Processo Unifi cado cada ciclo contém quatro f ases:
Concepção
Elaboração
Construção
Transição
12
CONCEPÇÃO
Atividades:
Defi nir o escopo do sistema I dentificar os requisitos funcionais e não-funcionais.
I niciar a modelagem de casos de uso. Esboçar uma arquitetura candidata I dentificar os riscos críticos (ameaçam a viabilidade do
sistema) e especificar como a equipe lidará com eles I niciar a análise econômica do projeto, de f orma a
determinar a viabilidade do projeto
13
ELABORAÇÃO
Atividades:
Especifi car os casos de uso que não f oram tratados na f ase de Concepção
Criar uma base arquitetônica sólida I dentificar os riscos signifi cativos, já que os críticos
f oram tratados na f ase anterior. Os riscos signifi cativos podem causar atrasos signifi cativos no cronograma e gastos maiores que os previstos no orçamento
Especifi car a qualidade desejada para o sistema considerando os requisitos não funcionais.
Atualizar a análise econômica e o plano de projeto com informações mais detalhadas obtidas durante esta f ase.
14
CONSTRUÇÃO
Atividades:Concluir o modelo de casos de usoConcluir os demais modelos.CodificaçãoModificar a arquitetura se for necessárioMonitorar os riscos críticos e os significativos e tomar as medidas necessárias para atenuá-los.
Nesta fase é construída uma versão operacional do sistema que possa ser entregue a clientes que realizarão testes.
15
TRANSI ÇÃO
Atividades:
Preparar a divulgação do sistema Divulgar o sistema Realizar ajustes quando for necessário para acertar
dif erenças em ambientes dos clientes Coletar informações sobre os defeitos e f azer as
correções
Nesta f ase é entregue uma versão operacional do sistema aos clientes que irão testar o sistema
16
I TERAÇÕES
Cada fase é dividida em uma ou mais iterações. I teração é um mini-projeto que resulta em uma versão
liberada interna ou externamente
Concepção
Elaboração
Construção
Transição
Iteração 1Iteração 2
Iteração x
Iteração x+1
Iteração y
Iteração y+1
Iteração z
. . . . . . . . .
17
OS WORKFLOWS
Cada iteração passa pelos workflows em maior ou menor grau.
Modelagem de negócio Requisitos Análise e Projeto I mplementação Teste I mplantação Gerência de confi guração Gerência de projeto Ambiente
18
19
Cada workflow tem os seguintes elementos:
Artef atos Trabalhadores Atividades
A seguir são descritos os workflows relacionados mais diretamente ao assunto deste curso: requisitos, análise e projeto e implementação
20
REQUISITOS
Objetivo: obter os requisitos dos vários interessados no sistema e negociar estes requisitos até que esteja claro que os clientes e a equipe de desenvolvedores concordam sobre as características do sistema que está sendo defi nido.
21
ANÁLISE e PROJ ETO
Objetivo: traduzir os requisitos numa especificação que descreva como implementar o sistema. O envolvimento do cliente é necessário quando precisa ocorrer uma negociação sobre os requisitos mas neste workflow o f oco está no trabalho dos desenvolvedores que precisam a partir dos requisitos construir o sistema.
22
Análise e Projeto:
Na análise o f oco maior está em assegurar que os requisitos f uncionais estão sendo atendidos.
J á o projeto é um refi namento da análise. Devem ser
considerados os requisitos não-funcionais.
23
Nível de detalhamento:
Há situações em que o projeto deve ser detalhado a ponto de se poder realizar uma tradução do projeto para o código.
Há outras situações em que não é necessário esse detalhamento.
O grau de detalhamento dependerá da experiência do desenvolvedor, da complexidade do projeto e dos riscos envolvidos.
24
Artef atos da Análise:
Modelo de Análise: é um pacote de pacotes de
análise.
Pacote de Análise: contém classes de análise e realizações de casos de uso e pode conter outros pacotes de análise.
25
Classes de Análise: É uma classe especifi cada no nível de detalhe próprio a este workflow. Contém por exemplo, atributos mas não operações.
Há três tipos de classes de análise:
Classes de interface Classes de entidade Classes de controle
26
Objeto de interface – um objeto com o qual um ator interage. Pode ser uma janela, página HTML, menu, etc. Um ator não-humano pode interagir com um objeto de interface como API s. Objeto entidade – geralmente é um objeto persistente, mas também pode ser um objeto que contenha dados transientes, resultado de uma pesquisa. Costuma vir do modelo de domínio. Objeto de controle – incorpora a lógica da aplicação. Atuam como coordenadores.
27
Realização de Análise: é uma colaboração que
descreve como o(s) ator(es) e o sistema realizarão um caso de uso em termos de classes de análise.
Colaboração: uma coleção de classes e outros
elementos que trabalham juntos para fornecer algum comportamento.
28
A equipe de desenvolvimento gera as realizações de análise ef etuando uma análise que envolve examinar cada sentença de um caso de uso, determinando os objetos de interface, entidade e controle necessários para se chegar a um determinado comportamento.
29
Artef atos de Projeto:
Modelo de projeto: é um detalhamento do modelo de análise
Modelo de instalação: especifi ca a distribuição
geográfica do hardware.
30
Uma abordagem a ser adotada é a de que o modelo de análise evolua para o modelo de projeto e não seja preservado. Caso haja necessidade é possível, no entanto, guardar o modelo de análise. A vantagem de se ter um modelo em um nível de abstração mais alto pode, no entanto, não compensar o trabalho de se manter a consistência entre os dois modelos.
31
IMPLEMENTAÇÃO
Objetivo: construir uma versão operacional do sistema. São realizados testes de unidade dos componentes criados. O modelo gerado neste workflow deve conter todos os componentes e subsistemas necessários para realizar a f uncionalidade especifi cada pelos casos de uso contidos no modelo de casos de uso e os requisitos complementares.
32
Componentes – O componente é f ísico e está
instalado em alguma parte do hardware. A classe é conceitual e é fi sicamente realizada por um componente.
Há componentes que são uma parte executável do sistema e outros que correspondem a partes não executáveis, como um tabela, um arquivo ou um documento.
Diagrama de Componentes – mostra uma coleção de componentes relacionados.
Neste diagrama é enf atizada a dependência entre os vários componentes.
33
O ESFORÇO DE CADA WORKFLOW AO LONGO DAS FASES
Dependendo da f ase em que o incremento é elaborado um workflow pode ser mais ou menos explorado.
Concepção Elaboração Construção
Transição
Iteração 1Iteração 2
Iteração x
Iteração x+1
Iteração y
Iteração y+1
Iteração z
. . . . . . . . .
34
A Fase de Concepção Requisitos – o maior esforço desta f ase ocorre neste workflow.
Análise e Projeto Análise – é construída uma versão inicial do modelo de análise baseada no conjunto inicial de casos de uso Projeto – são construídas as versões iniciais dos modelos de projeto e instalação I mplementação – só no caso de algum protótipo ser construído é que as atividades de implementação são realizadas.
Concepção
Elaboração
Construção
Transição
Iteração 1Iteração 2
Iteração x
Iteração x+1
Iteração y
Iteração y+1
Iteração z
. . . . . . . . .
35
A Fase de Elaboração Requisitos – busca-se capturar a maior parte dos requisitos funcionais Análise e Projeto Análise – a maior parte do trabalho de análise ocorre nesta f ase de elaboração. A descrição dos casos de uso é melhorada, o que aumenta o entendimento que os desenvolvedores têm sobre requisitos funcionais. Projeto – como a Análise, o Projeto também é muito importante nesta f ase. São construídos os modelos de projeto e instalação I mplementação – o objetivo é construir uma versão do sistema com as características chave do sistema
Concepção
Elaboração
Construção
Transição
Iteração 1Iteração 2
Iteração x
Iteração x+1
Iteração y
Iteração y+1
Iteração z
. . . . . . . . .
36
A Fase de Construção Requisitos – são descritos requisitos funcionais que possam ainda surgir. Análise e Projeto Análise – a partir do levantamento de novos casos de uso são acrescentados elementos ao modelo de análise. Projeto – a partir do levantamento de novos casos de uso são acrescentados elementos ao modelo de projeto. I mplementação – a maior parte do trabalho desta f ase encontra-se neste workflow. O objetivo é construir uma versão executável do sistema
Concepção
Elaboração
Construção
Transição
Iteração 1Iteração 2
Iteração x
Iteração x+1
Iteração y
Iteração y+1
Iteração z
. . . . . . . . .
37
A Fase de Transição O objetivo principal desta f ase é entregar uma versão operacional do sistema aos clientes. Pode, no entanto, ser observado algum problema, que deverá ser corrigido. E assim atividades dos workflows de Requisitos, Análise e Projeto e I mplementação podem ser realizadas.
Concepção
Elaboração
Construção
Transição
Iteração 1Iteração 2
Iteração x
Iteração x+1
Iteração y
Iteração y+1
Iteração z
. . . . . . . . .
38
MODELAGEM NO RUP No RUP são elaborados modelos com a perspectiva
conceitual no workflow de requisitos No RUP há um único workflow para análise e projeto. A
idéia é que seja construído um modelo de projeto não havendo a necessidade de se guardar um modelo intermediário entre o gerado no workflow de requisitos e o modelo de projeto. Mas se f or o caso pode ser guardado o modelo de análise que dá origem ao modelo de projeto.
A perspectiva de implementação é realizada no workflow de análise e projeto e é completada no workflow de implementação.
39
XP
-Planning Process / Planning Game-Short Releases-Stand Up Meetings-Pair Programming-Refactoring-Test Driven Development-Code Standard-Collective Code-Mataphor-Simple Design-Continuous Integration-Dedicated Consumer-Sustenaible Pace
40
Exercício: Listar as iterações, enquadradas conforme a fase e detalhando os
Artefatos, Trabalhadores e Atividades de cada workflow
top related