5 processo unificado e uml
DESCRIPTION
TRANSCRIPT
Engenharia de Software
Processo Unificado
Prof. Marcelo de Barros
Modelo com estrutura genérica de processo◦ Pode ser customizado: adicionando-se ou removendo-se atividades
Exemplo: Processo Unificado da Rational (RUP)
Faz uso extensivo da Unified Modeling Language (UML)
Introdução
Unified Modeling Language ou Linguagem de modelagem unificada◦ Linguagem visual utilizada para modelar software baseados no
paradigma de orientação a objetos◦ Linguagem padrão de modelagem internacionalmente
A UML foi criada para auxiliar aqueles que participam da atividade de desenvolvimento do sistema permitindo:◦ Visualizar o sistema◦ Especificar a estrutura◦ Especificar o comportamento◦ Construir o sistema◦ Documentar as decisões
Introdução à UML
História da UML “A UML é a linguagem padrão para visualizar, especificar,
construir e documentar os artefatos de software de um sistema.”
Unificação de diversas notações anteriores.
Mentores: Booch, Rumbaugh e Jacobson “Três Amigos” IBM Rational
UML não é:◦ Linguagem de programação◦ Processo de desenvolvimento
Introdução à UML
A vida de um sistema de software pode ser representada como uma série de ciclos
Cada ciclo termina com a liberação de uma versão do sistema para os clientes
No Processo Unificado, cada ciclo contém 4 fases
Fases do Processo Unificado
Fases do Processo Unificado
Concepção◦ Estabelecer a viabilidade do sistema
Elaboração◦ Estabelecer a capacidade para a construção do novo sistema◦ Visão refinada, implementação iterativa da arquitetura central
Construção◦ Construir um sistema capaz de operar bem em ambientes beta de
clientes◦ Construir o sistema de modo iterativo e incremental
Transição◦ Entregar o sistema completamente funcional aos clientes◦ Se concentra em corrigir defeitos e modificar o sistema para corrigir
problemas não identificados anteriormente
Fases do Processo Unificado
Representação
Conceitos do Processo Unificado
Requisitos em RUP Realizado em duas etapas
◦ Fase de Concepção
◦ Fase de Elaboração
Requisitos em RUP Fase de Concepção
◦ Passo inicial curto, onde se busca as primeiras informações sobre o sistema a ser desenvolvido
O que é visto na fase de concepção◦ Qual é a visão e o caso de negócio para este projeto?◦ Ele é viável?◦ Devemos construir ou comprar?◦ Estimativa aproximada de custo◦ Devemos continuar ou parar?
Atividades da Concepção:◦ Levantamento de Requisitos◦ Organização dos Requisitos◦ Planejamento do Desenvolvimento
Requisitos em RUP Levantamento de Requisitos
◦ Buscar todas as informações sobre o sistema (funções que deve executar e as restrições)
◦ Produto: Documento de Requisitos
Organização dos Requisitos◦ Estruturar os requisitos para que possam ser abordados nos ciclos de
desenvolvimento◦ Produto: Documento de Casos de Uso
Planejamento do Desenvolvimento◦ Acomodar os diferentes casos de uso, cadastros e consultas nos ciclos,
prever a duração dos ciclos, determinar tamanho da equipe◦ Produto: Cronograma de atividades para o desenvolvimento
Levantamento de Requisitos A fase da concepção deve fornecer a visão do todo para
poder ver o que é mais importante e dividir o todo em partes
Análise de requisitos é rápida e genérica
Deve entender o que o sistema deve fazer, mas sem detalhes de como vai fazer
Artefatos Importantes gerados nesta fase:◦ Visão Geral do sistema◦ Requisitos Funcionais e Não Funcionais
Levantamento de Requisitos
Visão Geral do Sistema Documento em formato livre
Deve escrever informações relevantes sobre o sistema após as conversas com os clientes e usuários
É bom que não seja longo demais◦ Uma a duas páginas é suficiente
Visão Geral do Sistema
Visão Geral do Sistema Apenas uma descrição desestruturada
◦ Descreve as principais preocupações do cliente
◦ Algumas vezes, é descrito detalhes sobre tecnologias
Categorias de Requisitos Categorias dos requisitos:
◦ Funcionais Listagem de tudo o que o sistema deve fazer
◦ Não Funcionais Restrições colocadas sobre como o sistema deve realizar seus
requisitos funcionais
Requisitos Funcionais Classificação quanto a Categoria Funcional
Evidentes◦ Efetuados com conhecimento do usuário◦ Geralmente relacionados com trocas de informações que
ocorram pela interface do sistema com o meio exterior
Ocultos◦ São efetuados pelo sistema sem o conhecimento explícito do
usuário
Requisitos Não Funcionais Classificação quanto a Obrigatoriedade
Obrigatórios◦ Podem ser obtidos de qualquer maneira
Desejados◦ Podem ser obtidos caso isso não cause maiores transtornos no
processo de desenvolvimento
Requisitos Não Funcionais Classificação quanto a Permanência
Permanentes◦ Nunca mudará com o tempo;◦ Ex.: Interface gráfica feita por janelas
Transitórios◦ Poderá sofrer alterações no futuro◦ Ex.: Forma de calcular impostos
Requisitos Não Funcionais Classificação quanto ao Atributo
Usabilidade◦ Fatores humanos, recursos de ajuda, documentação
Confiabilidade◦ Frequência de falhas, capacidade de recuperação,
previsibilidade
Desempenho/Performance◦ Tempos de resposta, fluxo de vazão, precisão, disponibilidade,
uso de recursos◦ Tipo de eficiência e precisão que o sistema será capaz de
apresentar
Requisitos Não Funcionais Classificação quanto ao Atributo
Configurabilidade◦ Partes do sistema que podem ser configuradas
Segurança◦ Funções que somente alguns tipos de usuários podem executar
Implementação◦ Linguagem que deve ser usada
Interface◦ Definição de como vai ser a interface
Requisitos Não Funcionais Classificação quanto ao Atributo
Curiosidade (Sommerville)
Criação da Tabela de Requisitos
Para os requisitos funcionais
◦ Código do Requisito (“F” seguido de número)◦ Nome do requisito Funcional◦ Descrição◦ Categoria Funcional (Evidente ou oculto)
Criação da Tabela de Requisitos
Para os requisitos não funcionais
◦ Código do Requisito não Funcional (“NF” seguido do número)
◦ Nome do requisito não-funcional◦ Restrição◦ Categoria◦ Obrigatoriedade (Desejável ou Obrigatório)◦ Permanência (Permanente ou Transitório)
Criação da Tabela de Requisitos
Exercício Criar um documento com a visão geral e os
requisitos para o seguinte sistema
◦ Venda de Ingressos para Cinema
Utilizar o modelo que se encontra disponível no Edmodo
Grupos de no máximo 4 componentes
São todo tipo de restrição tecnológica ou lógica que se aplica ao sistema como um todo e não apenas a funções individuais
◦ Ex.: estabelecer que o sistema deve ser compatível com um banco de dados legado ou ser implementado em uma determinada linguagem de programação
Requisitos Suplementares
Cuidados no Enunciado
“O sistema deve ser fácil de usar”
O sistema terá ajuda on-line em todas as telas e para todas as funções
Requisitos Suplementares
Ex:1. O sistema deve operar via interface Web.2. Todos os controles de interface devem ter um campo de ajuda associado.3. O sistema deve ser implementado utilizando linguagem php.
Requisitos Suplementares