desenvolvimento iterativo de software/up-universidade_de... · iterativa do núcleo da arquitectura...

Antónia Lopes Desenvolvimento C. Objectos 09/10

18

Desenvolvimento Iterativo

Esta abordagem ao desenvolvimento

• assegura que o sistema cresce de forma incremental

• assegura que a complexidade se mantém controlada

• permite ainda obter rápido feedback de várias fontes: utilizadores, equipa de desenvolvimento e de teste

o como resultado, o risco do projecto falhar é menor, a produtividade é melhor e a taxa de erros menor

o há desde início progresso visível

• é uma forma efectiva de lidar com a mudança, a diferentes níveis

o planear a aprendizagem

o planear o feedback

o planear a revisão de requisitos e desenho


19

Unified Process (UP)

• É um processo para desenvolvimento de software que cobre todo o ciclo de vida

• Guia a equipa de desenvolvimento

o nas diversas actividades técnicas

o nas diversas actividades de gestão

que têm de ser levadas a cabo até à entrega do produto final.

• É um processo para projectos que usam Análise e Desenho OO

• Tem na sua base o Desenvolvimento Iterativo


20

Unified Process

Tem 6 workflows de engenharia:

! business modelling

! requirements

! analysis and design

! implementation

! test

! deployment

• Os vários workflows são seguidos linearmente em cada iteração de cada fase.

• O esforço dispendido em cada workflow depende da fase.

Tem 4 fases:

! inception

! elaboration

! construction

! transition


21

Unified Process


22

Unified Process

• Inception: Obtenção de uma visão aproximada do sistema. Estabelece o business case, definindo o âmbito e tamanho, avaliando a viabilidade e as estimativas de custo e tempo.

• Elaboration: Obtenção de uma visão refinada. Construção e implementação iterativa do núcleo da arquitectura do sistema, cobrindo a maioria dos requisitos identificados, nomeadamente os com mais risco.

• Construction: Construção iterativa do resto do sistema cobrindo os restantes requisitos — elementos identificados como sendo de menor risco ou mais simples.

• Transition: Preparar o produto para o cliente. Testes beta, treino dos utilizadores, instalação.


23

Unified Process

• O número de iterações em cada fase e artefactos a serem produzidos em cada workflow não é fixo

• Deve ser escolhido de acordo com a dimensão e tipo do projecto e documentado no Development Case

Workflow Artefacto

Iteração

Inception

I1

Elaboration

E1..En

...

Business Modelling

modelo do domínio

glossário

start

start

ref

Requirements modelo de casos de uso

visão

especificação suplementar

start

start

start

ref

ref

ref

Design modelo de desenho

modelo de dados

doc da arquitectura

start

start

start


24

Inception

Nesta fase deve-se:

• Compreender o que é preciso construir. Determinar a visão e limitar o âmbito do sistema (construir vs comprar). Identificar quem são os interessados no sistema e o que esperam dele.

• Identificar as funcionalidades chave do sistema. Decidir quais as formas de utilizar o sistema (casos de uso) que são críticas ou mais importantes.

• Identificar os requisitos não funcionais críticos e determinar uma possível arquitectura e solução (pode envolver realização de protótipos).

• Compreender os custos, o escalonamento e os riscos associados ao projecto.


25

Inception

Algumas das actividades que são tipicamente desenvolvidas nesta fase e artefactos produzidos (se trouxerem valor acrescentado) são:

Actividade Documentos Descrição de alto nível dos objectivos, restrições e

dos aspectos negociais e empresariais. Business Case e Visão do Projecto

Descrição dos requisitos funcionais. Modelo de Casos de Uso Descrição de outros requisitos. Especificação Suplementar Descrição da terminologia chave do domínio. Glossário Descrição dos vários tipos de riscos e plano estabelecendo a forma como podem ser atenuados.

Lista de Riscos e Gestão de Riscos

Descrição do plano para a primeira iteração da fase elaboration.

Plano de Iteração


26

Visão do Projecto e Business Case

Documento que apresenta uma descrição de alto nível dos objectivos, restrições e dos aspectos negociais e empresariais do projecto.

Entre outras coisas, apresenta:

• Descrição do produto do ponto de vista do contexto de negócio

• Descrição dos envolvidos (stakeholders), dos seus objectivos e problemas

• Descrição do produto, benefícios e diagrama de contexto

• Descrição das funcionalidades principais


27

Visão do Projecto e Business Case: Exemplo

Histórico de Revisões Data Versão Descrição Autor

<dd/mmm/yy> <x.x> <detalhes> <nome>

Introdução <Descrição do propósito do documento> Descrição do Produto <Breve descrição do que deve ser o produto resultante do projecto. Benefícios e oportunidades de negócio; explica qual o problema a ser resolvido e porque vale a pena desenvolver um software para isso.> Contexto de Negócio <O domínio no qual o sistema será utilizado e qual o mercado. O sistema será desenvolvido para um cliente específico, é um produto a ser comercializado, ou é uma continuação de um projecto existente?> Descrição dos StakeHolders <Descrição das várias pessoas ou organizações que, de alguma forma, estão relacionadas com o sistema ou o podem influenciar (e.g., utilizadores, clientes, investidores, gestores de produto, analistas e designers, programadores, etc). Principais objectivos e problemas dos vários grupos.> Características do Produto <Descrição de alto nível do que o sistema deve fazer, em termos de características/serviços que os utilizadores podem observar/usar.> Outros Requisitos e Restrições <Requisitos de alto nível (usabilidade, fiabilidade, eficiência,etc) e interfaces externas, tecnologia, etc., que tenham impacto nos riscos e no custo do software>


28

Glossário

Documento que apresenta a terminologia chave do domínio.

Exemplo



Definições Termo Definição e Informação Aliases

<nome/sigla do termo>

<detalhes>


29

Requisitos

Os requisitos são as capacidades e condições a que o sistema, e o projecto em geral, tem de satisfazer

o Enquanto que os requisitos funcionais estão relacionados com o que o sistema tem de fazer (comportamento)

modelo de casos de uso

o a maior parte dos requisitos não funcionais estão relacionados com atributos de qualidade (-ities), por exemplo: o usabilidade o fiabilidade o desempenho o segurança o disponibilidade o manutenção o adaptabilidade o ...

especificação suplementar


30

Atributos de Qualidade


31

Especificação Suplementar: Exemplo



Introdução <Descrição do propósito do documento> Funcionalidade

Factores Humanos <detalhes> Tratamento e Registo de Erros <detalhes> Segurança <detalhes> …

Usabilidade Help <detalhes> Documentação <detalhes> ...

Desempenho <detalhes> Tempos de resposta <detalhes> Número de Pedidos <detalhes> Disponibilidade <detalhes> Uso de recursos (cpu/rede/...) <detalhes>


32

Especificação Suplementar: Exemplo

Fiabilidade Recuperação de Erros<detalhes>

… Suportabilidade

Adaptabilidade<detalhes> Manutenção<detalhes> Configurabilidade<detalhes>

Restrições de Implementação <detalhes> Interfaces <detalhes> Regras de Negócio Id Descrição da regra Grau de Estabilidade Fonte

<detalhes> <grau de estabilidade e factores de mudança>


33

Modelo de Casos de Uso


34

Caso de Estudo: Sistema POS para Posto de Venda

Um sistema POS é usado, parcialmente, para registar vendas e pagamentos (típicas em lojas de revenda como os supermercados).

• O POS tem componentes de hardware tais como um computador e um leitor de código de barras e tem componentes de software, que controlam o seu comportamento.

• O POS estabelece o interface com outros sistemas computacionais como um sistema de controlo de stock e um sistema de cálculo de impostos.

• O POS deve suportar, de uma forma incremental, múltiplos clientes de variados tipos: cliente com poucos recursos com interface web, desktop pc com interface em JavaSwing, …

Pretende-se um sistema que possa ser facilmente adaptado para diferentes clientes com diferentes regras de negócio.


35

Caso de Estudo: Sistema POS para Posto de Venda

Fronteira do Sistema • Entidades Externas

o Caixa o Sistema de gestão de stocks o Sistema de cálculo de impostos o Serviço de autorização de pagamentos

• Entidades Internas

o Sistema POS


36

Análise OO

desenvolvimento iterativo de software/up-universidade_de... · iterativa do núcleo da arquitectura...

Documents