Jpf@fe.up.pt www.fe.up.pt/~jpf Captura e Especificação de Requisitos usando UML (Unified Modeling Language) e RUP (Rational Unified Process) LIA, 2000/2001.

Apresentação em tema: "Jpf@fe.up.pt www.fe.up.pt/~jpf Captura e Especificação de Requisitos usando UML (Unified Modeling Language) e RUP (Rational Unified Process) LIA, 2000/2001."— Transcrição da apresentação:

1 jpf@fe.up.pt www.fe.up.pt/~jpf
Captura e Especificação de Requisitos usando UML (Unified Modeling Language) e RUP (Rational Unified Process) LIA, 2000/2001 João Pascoal Faria Março de 2001

2 Porquê usar o RUP? Porque, tendo sido desenvolvido pela mesma empresa que promoveu o UML (a Rational Software), está bem integrado com UML Explica que diagramas UML devem ser usados em que fases do ciclo de vida No entanto, está vocacionada para grandes projectos de software, sendo necessário alguma cautela na sua utilização em pequenos projectos de software (como são os projectos da disciplina de LIA)

3 Introdução ao RUP Um processo define quem faz o quê, quando e como para atingir um certo objectivo (aqui trata-se de produzir um sistema de software obedecendo a um conjunto de requisitos) O RUP é iterativo e incremental Uma iteração é uma sequência de actividades com um plano e um critério de avaliação estabelecidos, resultando numa release executável (um incremento ao produto) O RUP é dirigido por casos de uso Os casos de uso conduzem diversas actividades de desenvolvimento: Criação e validação da arquitectura do sistema Definição de casos de teste e procedimentos de teste Planeamento das iterações Criação de documentação para o utilizador Distribuição (deployment) do sistema Sincronizam o conteúdo de diferentes modelos O RUP é centrado na arquitectura Modelos são veículos para visualizar, especificar, construir e documentar a arquitectura O RUP prescreve o refinamento sucessivo de uma arquitectura executável

4 Fases, iterações e workflows numa geração do produto
h a s e C o r e W k f l w s I n c e p t i o E l a b o r t i n C o n s t r u c i T r a n s i t o Requirements Analysis Design Implementation Test P r e l i m n a y I t o ( s ) i t e r . # 1 i t e r . # 2 i t e r . # n i t e r . # n + 1 i t e r . # n + 2 i t e r . # m i t e r . # m + 1 I t e r a i o n s

5 Fases numa geração do produto
Inception Elaboration Construction Transition time Inception (análise preliminar) Define the scope of the project and develop business case Elaboration Plan project, specify features, and baseline the architecture Construction Build the product Transition Transition the product to its users

6 Enquadramento em LIA Elaboração Construção
tempo Captura e especificação de requisitos Requisitos Revisão de requisitos Projecto de alto nível Revisão do projecto de alto nível Análise e Projecto (Design) Projecto detalhado Implementação e Teste Implementação e teste Rel.Esp.Req. Rel.Proj.Alto Nível Rel.Des.+Produto

7 Estrutura do Relatório de Especificação de Requisitos
Introdução Objectivo do projecto Enquadramento do sistema a desenvolver no negócio/organização Riscos Lista de requisitos do sistema Descrever os requisitos do sistema a desenvolver, não se limitando ao software, em linguagem corrente facilmente compreendida pelos utilizadores e clientes finais Esta listagem é opcional (ver utilidade caso a caso), porque os requisitos se podem distribuir pelos casos de uso Modelo de casos de uso Formalizar e aprofundar os requisitos anteriores Começar com uma visão geral, com diagrama(s) de casos de uso e uma descrição Tem fronteira do sistema, actores, casos de uso, pacotes de casos de uso

8 Estrutura do Relatório de Especificação de Requisitos (cont.)
Modelo de casos de uso (cont.) Os casos de uso descrevem os requisitos funcionais e podem ter associados alguns requisitos não funcionais Casos de uso podem ser detalhados com esboços ou protótipos de interfaces para o utilizador e com diagramas dinâmicos (particularmente diagramas de sequência) Diagramas de actividade podem ser usados para descrever fluxos de trabalho que atravessam vários casos de uso Requisitos suplementares com restantes requisitos não funcionais Modelo de objectos do domínio (vocabulário do domínio) Descrição de sistemas existentes com os quais o software a desenvolver tem de comunicar (BD's) Tudo aquilo que interessa validar junto do cliente (sobre o que deve ser feito e porquê, e restrições a considerar no como) Glossário (dicionário de termos do vocabulário do domínio)

9 Propriedades dos Requisitos
Tipo de requisito: do produto (propriedade pretendida para o produto) funcional não funcional do processo (relativo ao processo de desenvolvimento) Grau de dificuldade na sua satisfação Fonte Em geral é alguém interessado no produto, podendo ser: O utilizador final O cliente (quem encomenda o produto) O implementador Prioridade

10 Prioritização dos Requisitos
Cada requisito deve ser classificado com uma prioridade Na solução mais simples, podem-se classificar os requisitos como mínimos ou não mínimos Os requisitos com maior prioridade devem ser especificados com maior detalhe Os requisitos com maior prioridade devem ser implementados mais cedo O produto a entregar no fim do trabalho de LIA deve contemplar pelo menos todos os requisitos mínimos!!

11 Requisitos não funcionais
Têm normalmente a ver com aspectos de qualidade: Usabilidade factores humanos - estéticos, facilidade de aprendizagem, facilidade de utilização consistência no interface para o utilizador documentação para o utilizador material de treino Fiabilidade frequência e severidade de falhas recuperação de falhas previsibilidade

12 Requisitos não funcionais (cont.)
Desempenho (performance) os requisitos de desempenho impõem condições nos requisições funcionais por exemplo, um requisito que especifica a taxa de transacções, velocidade, disponibilidade, precisão, tempo de resposta, tempo de recuperação, ou utilização de memória com que uma determinada acção deve ser executada Supportability requisitos nesta categoria cobrem: facilidade/possibilidade de teste facilidade/possibilidade de manutenção outras qualidades requeridas para manter o sistema actualizado depois da sua entrega requisitos nesta categoria não são necessariamente impostos no próprio sistema (produto final), mas possivelmente nos processos usados para criar o sistema ou nos artefactos (relatórios, código fonte, etc.) produzidos no decurso desses processos

13 Bibliografia The Rational Unified Process: An Introduction Philie Kruchten Addison-Wesley, 1999