Resumo gerenciamento de requisitos e diagramas UML

Gerenciamento de requisitos O planejamento é o primeiro estágio, determina o nível de detalhamento requerido. Estágios do gerenciamento de requisitos 1. Identificação dos requisitos: comparação e avaliação de rastreabilidade entre os requisitos 2. Processo de gerenciamento de mudanças: avalia o impacto e custo das mudanças 3. Políticas de rastreabilidade: relacionamentos entre os requisitos e entre o projeto e os requisitos Ferramentas de apoio Podem ser \ue001 sistemas especializados \ue001 em gerenciamento de requisitos até \ue001 planilhas e banco de dados simples \u25cf Armazenamento de requisitos \u25cf Gerenciamento de mudanças \u25cf Gerenciamento de rastreabilidade Gerenciamento para mudanças de requisitos É essencial pois para decidir \ue001 se os benefícios da implementação de novos requisitos justificam os custos \ue001 de implementação. A vantagem de ser usado o gerenciamento formal de requisitos é que todas as \ue001 propostas \ue001 são tratadas de forma \ue001 consistente \ue001 , e as \ue001 alterações nos documentos \ue001 são feitas de forma controlada \ue001 . Existem 3 estágios 1. Análise de problema e especificação de mudanças Identifica o problema \ue001 de requisito ou já tem uma \ue001 proposta específica de mudanç \ue001 a. Busca validar a proposta ou problema \ue001 . A análise é enviada ao solicitante que pode detalhar mais a proposta de mudança de requisito ou retirar a solicitação. 2. Análise de mudanças e custo O seu efeito é analisado perante a informações de \ue001 rastreabilidade e conhecimentos gerais dos requisitos. \ue001 Após a análise é decidido se a mudança seguirá ou não. 3. Implementação de mudanças É feita a \ue001 documentação dos requisitos e o projeto e a implementação são modificados \ue001 . Deve-se organizar o documento de requisitos para poder \ue001 fazer alterações sem ampla reformulação. Se um novo requisito precisa ser urgentemente implementado, deve ser evitado a modificação do sistema e depois modificar o documento de requisitos, pois isso quase inevitavelmente faz com que a especificação dos requisitos e implementação do sistema fique defasado. Uma vez que o sistema foi modificado é fácil esquecer de atualizar a documentação ou colocar informações inconsistentes com a implementação. Programação Continuidade da análise e projeto e não somente a confecção do código. GAP semantico Se refere a \ue001 diferença de significado entre dois conceitos \ue001 que na verdade \ue001 deveriam representar a mesma coisa. Orientação a objetos Programas grandes são divididos em módulos, e este funções. Oferece uma \ue001 alternativa para particionar um problema \ue001 . Programas > módulos > funções Objetos São criados a partir de classes Classes Representam conjunto de objetos reconhecidos por \ue001 compartilhar as mesmas características de atributos, operações, relações e semântica \ue001 . Oferece a alternativa ao uso de módulos, o vantagem é a \ue001 ocultação de informação \ue001 . Ocultação da informação Utiliza-se objetos sem conhecer sua construção interna \ue001 , permitindo o trabalho em equipe, utilização de interfaces e integração de componentes. Orientação a aspectos Técnica de programação que trata problemas criados por requisitos \ue001 transversais \ue001 . Os requisitos transversais geram 2 problemas: \ue001 entrelaçamento \ue001 e \ue001 espelhamento \ue001 . O entrelaçamento ocorre quando a implementação do \ue001 requisito transversal se mescla aos código do requisito funcional \ue001 . O espelhamento é quando o aspecto a ser tratado \ue001 se encontra em variadas partes do código e não concentrado em um ponto \ue001 . Isso gera dificuldades em \ue001 rastrear e compreender o código, tornando obscura a correspondência entre requisitos e implementações \ue001 . Baixa produtividade dos desenvolvedores pois a \ue001 implementação simultânea \ue001 de vários requisitos em um módulo \ue001 desvia sua atenção \ue001 . Baixo reuso: pois um único módulo implementa vários requisitos. Baixa coesão e alto acoplamento: pois novos requisitos implementados podem gerar problemas adicionais não detectados. Diagramas Auxiliam na compreensão e documentação de requisitos, permitindo que diferentes profissionais entendam os mesmos conceitos e ideias, evitando ambiguidades. UML (unified modeling language) Linguagem gráfica para modelagem orientada a objetos, sendo um padrão mundial para modelagem. Diagramas estáticos Representam os \ue001 dados \ue001 , \ue001 arquitetura \ue001 do software ou \ue001 física \ue001 . Ex. Diagrama de classes e diagrama de componentes Diagramas dinâmicos Representam \ue001 funcionalidades \ue001 e \ue001 ações \ue001 do sistema Ex. Diagrama de casos de uso e diagrama de sequências Diagrama de casos de uso Descreve o sistema e suas interações com o mundo exterior de suas funcionalidades. Descreve os \ue001 requisitos funcionais do softwar \ue001 e Elementos: atores (gerente), casos de uso (aprovar pedido) e relacionamentos Diagrama de classes É uma forma de desenvolvedores expressarem a arquitetura da solução. Pode expressar herança das classes, composição e agregação. Elementos: nome, atributo e operações/métodos

Resumo gerenciamento de requisitos e diagramas UML

UNIVILLE

Qualidade de Software

Continue navegando

Materiais relacionados

Perguntas relacionadas

O que é feito durante a etapa de Negociação no processo de Engenharia de Requisitos? Estabelecimento de um contrato entre clientes e equipe de pr...

O que é feito durante a etapa de Negociação no processo de Engenharia de Requisitos? Construção de diagramas de classes da UML. Levantamento detal...

A UML foi criada para ser independente do processo de software. Os desenvolvedores podem adotar da UML algo que seja apropriado ao seu projeto e ao...

Com base na documentação de requisitos de um sistema, um arquiteto de sistemas utilizou a linguagem de modelagem unificada (UML) para elaborar um d...

Outros materiais