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