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 18 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 19
Unified Process Tem 6 workflows de engenharia:! business modelling! requirements! analysis and design! implementation! test! deployment Tem 4 fases:! inception! elaboration! construction! transition 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. 20 Unified Process 21
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. 22 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 ref Requirements modelo de casos de uso visão ref ref especificação suplementar ref Design modelo de desenho modelo de dados doc da arquitectura 23
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. 24 Inception Algumas das actividades que são tipicamente desenvolvidas nesta fase e artefactos produzidos (se trouxerem valor acrescentado) são: Actividade Descrição de alto nível dos objectivos, restrições e dos aspectos negociais e empresariais. Descrição dos requisitos funcionais. Descrição de outros requisitos. Descrição da terminologia chave do domínio. Descrição dos vários tipos de riscos e plano estabelecendo a forma como podem ser atenuados. Descrição do plano para a primeira iteração da fase elaboration. Documentos Business Case e Visão do Projecto Modelo de Casos de Uso Especificação Suplementar Glossário Lista de Riscos e Gestão de Riscos Plano de Iteração 25
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 26 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> 27
Glossário Documento que apresenta a terminologia chave do domínio. Exemplo Histórico de Revisões Data Versão Descrição Autor <dd/mmm/yy> <x.x> <detalhes> <nome> Definições Termo Definição e Informação Aliases <nome/sigla do termo> <detalhes> 28 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... 29 especificação suplementar
Atributos de Qualidade 30 Especificação Suplementar: 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> 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> 31
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. 34 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 35
Análise OO 36