Engenharia de Requisitos
2010
Autora :Professora Carmen Lucia Asp de Queiroz
Esta apostila foi desenvolvida para ajudar na aprendizagem e
desenvolvimento dos alunos na disciplina de Engenharia de
Requisitos da UniverCidade. Seu conteúdo é uma pesquisa de
vários autores, sendo em grande parte, transcrições dos mesmos. Ao
final de cada aula será apresentada a bibliografia utilizada.
Esta apostila tem como objetivo ser uma primeira leitura para os
alunos, propiciando subsídios para que possam se aprofundar nos
temas tratados.
Objetivos da disciplina:
• Apresentar ao aluno o desenvolvimento de software como uma
metodologia.
• Desenvolver a capacidade de o aluno realizar de forma correta e
satisfatória o levantamento de requisitos de um sistema
computacional.
No intuito de ser didática, esta apostila está estruturada da
seguinte forma:
Tópico 1 - Visão Geral da Engenharia de Software
Tópico 2 - Processos de Desenvolvimento de Software
Tópico 3 - Paradigmas de Desenvolvimento de Software
Tópico 4 - Análise e Especificação de Requisitos
Obs: Cada tópico acima será
ministrado em 1
encontro (4 tempos de aula), com exceção do tópico 4, cujo
conteúdo será diluído pelo restante do curso,
principalmente, através de exercícios de levantamento de
requisitos.
Tópico 1 - Visão Geral da Engenharia de Software
· Sistemas Computacionais
o Definição e conceitos básicos
o Evolução do desenvolvimento
· Natureza do produto “software”
· Definição de Engenharia de Software
VISÃO GERAL DA ENGENHARIA DE SOFTWARE
Uma empresa de software de sucesso é aquela que
consistentemente produz software de qualidade que vai ao
encontro das necessidades dos seus clientes. Uma empresa
que consegue desenvolver tal software, de forma previsível,
cumprindo os prazos, com uma gestão de recursos, quer
humanos quer materiais, eficiente e eficaz, é uma empresa
que tem um negócio sustentável.
Booch, Rumbaugh e Jacobson
VISÃO GERAL DA ENGENHARIA DE SOFTWARE
Sistema
Um sistema é um grupo de componentes inter-relacionados que
trabalham rumo a uma meta comum, recebendo insumos e produzindo
resultados em um processo organizado de transformação.
Componentes de um Sistema
Feedback e Controle
Entrada
Processamento
Saída
Propriedades e comportamento dos componentes estão intrinsecamente
interligados
Exemplo: o software só operará se o processador estiver operacional
O processador poderá realizar computações apenas se o sistema de
software, que define essas computações, tiver sido instalado com sucesso.
VISÃO GERAL DA ENGENHARIA DE SOFTWARE
Sistema de Informação Computadorizado, ou simplesmente,
Sistema de Informação
“...Pode ser definido como o
processo de transformação de
dados em informações que são
utilizadas na estrutura decisória da
empresa e que proporcionam a
sustentação administrativa visando
à otimização dos resultados
esperados” (Rezende, 2002) .
VISÃO GERAL DA ENGENHARIA DE SOFTWARE
Sistema de Informação Computadorizado, ou simplesmente, Sistema
de Informação (continuação)
Informação: é todo o dado trabalhado,
útil, tratado, com o valor significativo
atribuído ou agregado e com um sentido
natural e lógico para quem o usa.
Dado: é compreendido como um
elemento da informação, um conjunto de
letras, números ou dígitos, que tomado
isoladamente não transmite nenhum
conhecimento
VISÃO GERAL DA ENGENHARIA DE SOFTWARE
Sistema de Informação Computadorizado, ou simplesmente, Sistema
de Informação (continuação)
Características:
• Grande volume de dados e informações;
• Complexidade de processamento;
• Muitos clientes e / ou usuários envolvidos;
• Contexto abrangente, mutável e dinâmico;
• Interligação de diversas técnicas e tecnologias;
• Suporte a tomada de decisões empresariais;
• Auxílio na qualidade, produtividade e competitividade organizacional.
VISÃO GERAL DA ENGENHARIA DE SOFTWARE
O sistema de informação é um
sistema
sócio-técnico
cujos
componentes são indivíduos, tarefas
e equipamentos necessários ao seu
funcionamento
Implantar um sistema de informação em uma Organização equivale a
nela intervir visando a uma mudança.
VISÃO GERAL DA ENGENHARIA DE SOFTWARE
ENTRADAS
Componentes de um
Sistema de Informática
• Pessoas
Procedimentos
Hardware
Documentos
• Software
Sistema
Software
Base de Dados
• Hardware
Pessoas
• Banco de dados
SAÍDAS
• Documentos de diversas naturezas
• Procedimentos manuais que se integram aos automatizados
VISÃO GERAL DA ENGENHARIA DE SOFTWARE
Software
É a parte programável de um sistema de informação. Ele é um
elemento central: realiza estruturas complexas e flexíveis que
trazem funções, utilidade e valor ao sistema.
O software pode ser:
Genérico – desenvolvido para ser vendido para uma gama
de clientes diferentes.
Encomendado (personalizado) – desenvolvido para um
único cliente, de acordo com a sua especificação.
Natureza do software  é um produto intangível.
VISÃO GERAL DA ENGENHARIA DE SOFTWARE
Atributos de um bom Software
O software deve entregar a funcionalidade e desempenho exigidos
pelo usuário e deve ser manutenível, digno de confiança e
utilizável.
Manutenibilidade - O software deve evoluir para alcançar
necessidades de mudança;
Confiabilidade - O software deve ser confiável;
Eficiência - O software não deve desperdiçar recursos do sistema;
Usabilidade - O software deve ser usável pelos usuários para os
quais ele foi projetado.
VISÃO GERAL DA ENGENHARIA DE SOFTWARE
A importância dos softwares
• As economias de TODAS as nações desenvolvidas dependem de
software;
• Mais e mais sistemas são controlados por software;
• O gasto com engenharia de software representa uma parte
significativa do PIB em todos os países desenvolvidos;
• Os custos de software freqüentemente dominam os custos do
sistema;
• Os custos de software são maiores para mantê-lo do que para
desenvolvê-lo.
VISÃO GERAL DA ENGENHARIA DE SOFTWARE
Exemplos de problemas causados por erros de softwares:
• Aeroporto Internacional de Denver. Erro no sistema de transporte
automático de bagagens. Estima-se um prejuízo por volta dos 360 milhões
de dólares com o erro. Para o conserto foram investidos 86 milhões de
dólares.
• Ariane 5. É um Projeto da Agência Espacial Européia que levou 10 anos
para ser concluído e custou 8 Bilhões de dólares. O foguete tem capacidade
para 6 toneladas e prometia a supremacia européia no espaço. O primeiro vôo
marcado para 4 de junho de 1996. Quarenta segundos após a decolagem
houve a explosão (8 bilhões de investimentos foi junto). A carga do foguete
estava avaliada em 500 milhões de dólares.
• Therac-25. É um equipamento de Radioterapia. Entre 1985 e 1987 se
envolveu em 6 acidentes, causando mortes por overdoses de radiação. O
software deste equipamento foi adaptado de um antecessor, Therac-6, que
apresentou falhas por falta de testes integrados e falta de documentação.
VISÃO GERAL DA ENGENHARIA DE SOFTWARE
Problemas dos Sistemas de Informática:
• Não fazem o que deveriam fazer;
• São caros;
• São entregues tarde demais;
• São de baixa qualidade (cheios de defeitos, difíceis de usar e
lentos).
VISÃO GERAL DA ENGENHARIA DE SOFTWARE
Origem dos problemas dos Sistemas de Informação
• Falta de treinamento das pessoas que operam;
• Processos de negócios inadequados;
• Deficiências da tecnologia;
• Falta de empenho dos órgãos de topo das organizações;
• Falta de comprometimento e empenho dos usuários;
• Incompreensão do valor dos sistemas de informação;
• Falta de entendimento entre o pessoal da Informática e os usuários;
• Deficiências no processo de desenvolvimento;
• Falhas na coordenação do projeto;
• Mudanças freqüentes dos requisitos do negócio.
VISÃO GERAL DA ENGENHARIA DE SOFTWARE
VISÃO GERAL DA ENGENHARIA DE SOFTWARE
Arte
(o homem transforma
e domina a matéria)
Atendimento das
necessidades humanas
(geração de valor através do
tratamento da informação)
Processos
(baseia-se numa ação
sistemática e não na
improvisação)
Dispositivos e estruturas
(devem ser reunidos para atender
às necessidades humanas)
Engenharia de
Software
Formas
adequadas
(utilidade)
Conhecimentos
científicos e empíricos
(parte do métodos provém da ciência e
parte provém da experiência prática)
Habilitações
específicas
(as pessoas envolvidas
têm que ter habilitações
específicas)
Recursos naturais
(são as máquinas utilizadas
para materializar as
abstrações geradas pela ciência
da computação)
VISÃO GERAL DA ENGENHARIA DE SOFTWARE
Conceito de Engenharia:
“Arte de aplicar conhecimentos
científicos e empíricos e certas
habilitações específicas à
criação
de
estruturas,
dispositivos e processos que
são utilizados para converter
recursos naturais em formas
adequadas
ao
homem”,
Aurélio.
VISÃO GERAL DA ENGENHARIA DE SOFTWARE
Definição da Engenharia de Software
Uma das definições mais utilizada hoje em dia foi proposta pelo
Institute of Electrical and Electronics Engineering (IEEE) em 1993,
e defende que "a Engenharia de Software é a aplicação de um
processo sistemático, disciplinado, e quantificado ao
desenvolvimento, operação e manutenção de software; ou seja, a
Engenharia de Software é a aplicação de técnicas de engenharia
ao software".
A Engenharia de Software preocupa-se com as teorias, os métodos
e as ferramentas para o desenvolvimento profissional de software.
Seu objetivo é o desenvolvimento e operação de um produto
(software).
VISÃO GERAL DA ENGENHARIA DE SOFTWARE
Desafios enfrentados pela Engenharia de Software
Lidar com sistemas legados, lidar com diversidade crescente e
lidar com necessidades de tempos de entrega reduzidos.
Sistemas legados - Sistemas velhos e valiosos devem ser
mantidos e atualizados;
Heterogeneidade - Os sistemas são distribuídos e incluem uma
combinação de hardware e software;
Entrega - Há uma pressão crescente para entrega mais rápida do
software.
VISÃO GERAL DA ENGENHARIA DE SOFTWARE
Mitos e Realidades no Desenvolvimento de Software
Mito
Minha equipe tem as ferramentas mais atuais de Engenharia de
Software e os melhores computadores.
Realidade
• Não basta!!!
• Mesmo a melhor ferramenta não pode fazer um desenvolvedor
medíocre se tornar um bom desenvolvedor.
VISÃO GERAL DA ENGENHARIA DE SOFTWARE
Mitos e Realidades no Desenvolvimento de Software
(continuação)
Mito
O problema de atraso no cronograma pode ser resolvido
aumentando a equipe.
Realidade
• Não são todas as tarefas que podem ser divididas.
• Novas pessoas precisam ser treinadas pelas pessoas que já estão
no projeto.
• Acrescentar mais pessoas a um projeto atrasado pode fazer com
que ele se atrase ainda mais.
VISÃO GERAL DA ENGENHARIA DE SOFTWARE
Mitos e Realidades no Desenvolvimento de Software
(continuação)
Mito
Todos os programadores são iguais.
Todos os programadores experientes têm as mesmas habilidades.
Realidade
• Programadores com a mesma experiência podem ser bastante
diferentes.
VISÃO GERAL DA ENGENHARIA DE SOFTWARE
Mitos e Realidades no Desenvolvimento de Software
(continuação)
Mito
O programa está 95% pronto.
Realidade
• Programadores são extremamente otimistas.
• Programadores costumam acreditar na própria capacidade de
resolver problemas de forma imediata, mesmo na contínua
evidência do contrário.
VISÃO GERAL DA ENGENHARIA DE SOFTWARE
Mitos e Realidades no Desenvolvimento de Software
(continuação)
Mito
Para iniciar a programação basta uma identificação geral dos
objetivos. Os detalhes podem ser identificados depois.
Realidade
• A falta de identificação adequada dos objetivos é a principal causa
de fracasso de projetos.
• A descrição detalhada dos requisitos de informação, funções,
desempenho e interface, das restrições de projeto e dos critérios de
validação é essencial e deve ser feita com o usuário/cliente.
VISÃO GERAL DA ENGENHARIA DE SOFTWARE
Mitos e Realidades no Desenvolvimento de Software
(continuação)
Mito
Requisitos mudam continuamente, mas mudanças no software
podem ser feitas rapidamente porque o software é flexível.
Realidade
• Requistos mudam continuamente, mas o impacto das mudanças
varia de acordo com o momento em que estas ocorrem.
VISÃO GERAL DA ENGENHARIA DE SOFTWARE
Mitos e Realidades no Desenvolvimento de Software
(continuação)
Mito
Enquanto não se tem um programa “rodando”
avaliar a sua qualidade.
não é possível
Realidade
• O software pode ser avaliado desde a sua concepção através de
revisões que são mais efetivas do que testes.
VISÃO GERAL DA ENGENHARIA DE SOFTWARE
Mitos e Realidades no Desenvolvimento de Software
(continuação)
Mito
O único produto de um projeto de desenvolvimento de software é
um programa funcionando.
Realidade
• Um programa funcionando é apenas parte de uma configuração
do software que inclui programa, documentação e dados.
• A documentação é a base para um proheto bem sucedido e guia
para a manutenção de software.
VISÃO GERAL DA ENGENHARIA DE SOFTWARE
Ciência da Computação x Engenharia de Software
A Ciência da Computação preocupa-se com a teoria e os
fundamentos.
A Engenharia de Software preocupa-se com a prática do
desenvolvimento e entrega de software útil.
As teorias da ciência da computação são atualmente insuficientes
para servir como base única para a engenharia de software.
VISÃO GERAL DA ENGENHARIA DE SOFTWARE
Engenharia de Sistemas x Engenharia de Software
A engenharia de sistemas preocupa-se com todos os aspectos do
desenvolvimento de sistemas baseados em computador, incluindo
hardware, software e engenharia de processos. A engenharia de
software faz parte desse processo.
Engenheiros de sistemas estão envolvidos na especificação, projeto
arquitetural, integração e desenvolvimento de sistemas.
VISÃO GERAL DA ENGENHARIA DE SOFTWARE
Engenharia de Software x Engenharia de Requisitos
• A Engenharia de Requisitos faz parte da Engenharia de Software.
• A engenharia de requisitos é a disciplina que procura sistematizar o
processo de definição de requisitos. Aborda um ponto fundamental do
desenvolvimento de software: a definição do que se produzir.
• A engenharia de requisitos tem sido identificada como uma fase crucial
por tratar de conhecimentos não apenas técnicos, mas também gerenciais,
organizacionais, econômicos e sociais, e estar intimamente associada a
qualidade do software.
• As atividades da engenharia de requisitos vão desde a idéia de
desenvolver um sistema de software até a modelagem conceitual do que
se vai construir.
VISÃO GERAL DA ENGENHARIA DE SOFTWARE
Atividades associadas à Engenharia de Software
• Concepção
• Implementação
• Manutenção
Ao longo de cada fase existem tarefas, subprodutos a desenvolver,
pontos de verificação e intervenientes. Existe também um conjunto
de atividades de suporte contínuas: gestão de projeto, controle de
qualidade, gestão da configuração, elaboração de documentação,
elaboração de estimativas, gestão do risco, entre outras.
VISÃO GERAL DA ENGENHARIA DE SOFTWARE
Referências Bibliográficas
Booch, Grady; Rumbaugh, James; Jacobson, Ivar. UML – Guia do Usuário. Rio de Janeiro:
Campus, 2000.
O´Brien, A. James. Sistemas de Informação e as Decisões Gerenciais na Era da Internet. São
Paulo: Saraiva, 2004.
Paula Filho, Wilson de Pádua. Engenharia de Software – Fundamentos, Métodos e Padrões.
Rio de Janeiro: LTC, 2003.
Ribeiro, Carlos Augusto. Apostila de Engenharia de Requisitos.
Rocco, Giovanni Ely. Engenharia de Requisitos. Universidade de Caxias do Sul - Centro de
Ciências Exatas e Tecnologia - Departamento de Informática.
Rocha, Ana Regina. Apostila de Engenharia de Software – COPPE/UFRJ.
Silva, Alberto; Videira, Carlos. UML, Metodologias e Ferramentas CASE. Disponível em,
<http://www.centroatl.pt/titulos/tecnologias/uml.php3>. Acesso em 31/01/2005.
Souza, Isabel Fernandes de. Apostila de Engenharia de Sistemas de Informação – Parte I.
Sommerville, Ian. Engenharia de Software. São Paulo: Pearson Education, 2003.
Tópico 2 - Processos de Desenvolvimento de Software
· Definição de processos de desenvolvimento de software
· Ciclos de vida de softwares e suas fases
o Ciclo de vida clássico
o Prototipação
o Modelo espiral
o Técnicas de 4ª geração
PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
Processo - É um conjunto de passos parcialmente ordenados,
constituídos por atividades, métodos, práticas e transformações,
usado para atingir uma meta. Esta meta geralmente está associada
a um ou mais resultados concretos finais, que são os produtos da
execução do processo.
Processo definido tem documentação detalhada:
• o que é feito (produto)
• quando (passos)
• por quem (agentes)
• as coisas que usa (insumos)
• as coisas que produz (resultados)
PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
Requisitos do
Usuário
Processo de
Desenvolvimento
de Software
Sistema novo
ou modificado
Um processo de desenvolvimento de software é o conjunto de
atividades de engenharia necessárias para transformar os requisitos
do usuário em software.
PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
Modelo x Processo
Um modelo é algo teórico, um conjunto de possíveis ações.
O processo deve determinar ações práticas a serem realizadas pela
equipe como prazos definidos e métricas para se avaliar como elas
estão sendo realizadas.
Modelo + Planejamento = Processo
PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
Modelos de Processo (Ciclos de Vida)
• Um ciclo de vida define um conjunto de atividades específicas;
• É conceituado a partir da percepção de uma necessidade;
• É desenvolvido de forma a se transformar em um conjunto de
itens entregue a um cliente;
• Entra em operação, ou seja, é utilizado dentro de algum
processo de negócio;
• É retirado de operação ao final da vida útil.
PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
Etapas que compõem o desenvolvimento de sistemas:
• Determinação dos requisitos - Identificar as necessidades do cliente.
• Análise - Criar modelos conceituais associados ao negócio.
• Desenho - Criar uma visão detalhada do sistema considerando a
tecnologia que será utilizada.
• Implementação - Construir o sistema com base nos modelos das fases
anteriores.
• Testes – Avaliar a qualidade do sistema, verificando os requisitos e
corrigindo os problemas encontrados.
PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
Ciclo de vida do desenvolvimento de softwares:
• Codifica-remenda
• Cascata
• Espiral
• Prototipagem evolutiva
• Entrega evolutiva (Cascata e Prototipagem evolutiva)
•Dirigidos por prazo (time-boxed)
• Dirigidos por ferramentas
PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
Ciclo de vida do desenvolvimento de softwares – CodificaRemenda
• O ciclo de vida mais caótico é aquele que pode ser chamado de
“codifica-remenda”;
• Parte apenas de uma especificação (ou nem isso);
• Os desenvolvedores começam imediatamente a codificar,
remendando à medida que os erros vão sendo descobertos;
• Infelizmente, é provavelmente o ciclo de vida mais usado;
• É um modelo de alto risco, impossível de gerir e que não permite
assumir compromissos confiáveis.
PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
Ciclo de vida do desenvolvimento de softwares – Cascata
Os principais sub processos são executados em estrita seqüência, o que permite
demarcá-los com pontos de controle bem definidos. A fase seguinte só pode iniciar
quando a anterior tiver sido concluída e aprovada pelas partes envolvidas.
Desvantagem: O modelo em cascata puro é de baixa visibilidade para o cliente
porque ele só recebe o resultado no final. Além disso, ele dificulta a realização de
mudanças com o processo em andamento (requisitos sempre mudam). Portanto, é
um modelo de alto risco, tanto para o cliente quanto para os desenvolvedores.
Requisitos
Análise
Desenho
Implementação
Testes
PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
Ciclo de vida do desenvolvimento de softwares – Cascata (variante)
Para permitir que, em fases posteriores, haja revisão e alteração de resultados
das fase anteriores. É uma visão mais realista do desenvolvimento de software.
Desvantagem: É difícil de ser gerenciado e, como o modelo cascata “puro”, é
de baixa visibilidade para o cliente porque ele só recebe o resultado no final e é
um modelo de alto risco, tanto para o cliente quanto para os desenvolvedores.
Requisitos
Análise
Desenho
Implementação
Testes
PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
Prototipação
Protótipo de software é um sistema
que...
– não tem tempo de vida definido;
Definir objetivos
e requisitos de
informação
Construir/Revisar
protótipo
– pode servir a múltiplos propósitos;
– deve ser construído rapidamente e com
baixo custo;
– é parte integrante de um design centrado
no usuário, para avaliação e modificação.
Avaliar
protótipo
- Usuário -
PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
Prototipagem:
-
Protótipos descartáveis;
Protótipos evolutivos – evolui para o produto final.
Inconvenientes:
 O usuário passa a ver o protótipo como uma versão
final;
 Compromisso do desenvolvedor em gerar um protótipo em
um curto espaço de tempo.
PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
Ciclo de vida do desenvolvimento de softwares – Espiral
• o produto é desenvolvido em uma série de iterações;
• cada nova iteração corresponde a uma volta na espiral;
• permite construir produtos em prazos curtos, com novas
características e recursos que são agregados à medida que a
experiência descobre sua necessidade;
• as atividades de manutenção são usadas para identificar
problemas; seus registros fornecem dados para definir os requisitos
das próximas liberações;
Desvantagem: requer gestão sofisticada para ser previsível e
confiável.
PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
Ciclo de vida do desenvolvimento de softwares – Espiral (continuação)
Determinar objetivos,
alternativas e restrições
Atividades do Modelo Espiral
Determinar objetivos, alternativas e
restrições: são definidos os objetivos específicos
para essa fase do projeto.
Avaliação e redução de riscos: para cada um dos
risco do projeto identificado, é realizada uma
análise detalhada e são tomadas providências
para reduzir esses riscos.
Planejamento da
próxima iteração
Avaliar alternativas,
Identificar,
Desenvolvimento,
verificar produto do próximo nível Resolver riscos
Desenvolvimento e validação: depois da avaliação dos riscos, é escolhido o modelo de
desenvolvimento para o sistema.
Planejamento da próxima iteração: o projeto é revisto e é tomada uma decisão sobre
continuar com o próximo loop da espiral.:
PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
Ciclo de vida do desenvolvimento de softwares – Espiral
(continuação)
Modelo Espiral – Observações:
• é, atualmente, a abordagem mais realística para o desenvolvimento de
software em grande escala;
• usa uma abordagem que capacita o desenvolvedor
entender e reagir aos riscos em cada etapa evolutiva;
e o cliente a
• pode ser difícil convencer os clientes que uma abordagem "evolutiva" é
controlável;
• exige considerável experiência na determinação de riscos e depende
dessa experiência para ter sucesso;
Quando o modelo espiral é aplicado a um único projeto, tem-se o modelo
de prototipagem evolutiva.
PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
Ciclo de vida do desenvolvimento de softwares – Prototipagem evolutiva
A espiral é usada não para desenvolver o produto completo, mas para construir . Os
protótipos cobrem cada vez mais requisitos, até que se atinja o produto desejado.
Desvantagem: Requer gestão muito sofisticada e equipe disciplinada e experiente.
Planejamento
da iteração
Requisitos
Análise
Avaliação
da iteração
Testes
Desenho
Nova iteração
Projeto Terminado
Implementação
PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
Ciclo de vida do desenvolvimento de softwares – Entrega evolutiva
Permite que, em pontos bem definidos, os usuários possam avaliar partes do produto e
fornecer realimentação quanto às decisões tomadas.
Requisitos
Análise
Desenho
Arquitetônico
Desenho
Detalhado
Implementação
Nova iteração
Avaliação
da iteração
Projeto Terminado
Testes
PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
Ciclo de vida do desenvolvimento de softwares – Entrega evolutiva
• O sistema é particionado em partes independentes que podem ser entregues à
medida que forem ficando prontas e avaliadas;
• Permite que, em pontos bem definidos, os usuários possam avaliar partes do
produto e fornecer realimentação quanto às decisões tomadas;
• Os incrementos funcionam como protótipos do sistema;
• Novos requisitos podem ser incorporados aos outros incrementos do sistema;
• Deve-se identificar funcionalidade prioritárias que serão desenvolvidas primeiro;
• Os processos de cada incremento podem ser independentes. Pode-se utilizar
Cascata;
• Risco menor de fracasso completo do sistema;
• A funções entregues primeiro são testadas mais vezes, à medida que os
incrementos são entregues.
PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
Ciclo de vida do desenvolvimento de softwares – Dirigidos por
prazo
O produto é o que se consegue fazer dentro de um determinado
prazo, que normalmente, é estabelecido de forma política.
Desvantagem: O produto entregue é apenas parcial. O restante
será entregue disfarçado de manutenção.
PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
Ciclo de vida do desenvolvimento de softwares – Dirigidos por
ferramenta
Algumas ferramentas podem impor processos rígidos, que podem
ser adequados para tipos bem específicos de produtos. Essas
ferramentas são conhecidas por ferramentas CASE (Computer
Aided Software Engineering ).
Ferramentas CASE ajudam os desenvolvedores a aumentar sua
produtividade ao construírem aplicativos de negócios, sistemas de
software e dispositivos incorporados.
Exemplos: Posseidon (free), Rational Rose, System Architect,
PowerDesigner, etc.
PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
Recursos que podem ser encontrados numa ferramenta
CASE:
• Ferramentas para arquitetura e modelagem de design;
• Ferramentas para geração de código completamente
executável;
• Ferramentas para geração de scripts a partir de diagramas
destinados à banco de dados;
• Ferramentas para testes de componente e atividades de
análise de tempo de execução.
PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
Ferramentas CASE - Recomendações
• Uma ferramenta CASE não é a solução para todos os problemas
da organização;
• A organização deve ter certeza de estar pronta para a nova
ferramenta.
Dessa forma, uma ferramenta só deveria ser selecionada após a
definição do processo de desenvolvimento, dos métodos e de ter sido
utilizada num projeto piloto.
PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
Processos de desenvolvimento de software mais conhecidos:
• Personal Software Process (PSP)
• Team Software Process (TSP)
• Processo Unificado Racional (Rational Unified Process – RUP)
Processo de desenvolvimento para dar suporte a projetos
didáticos:
• PRocesso para Aplicativos eXtensíveis InterativoS (Praxis)
PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
Personal Software Process (PSP) ou Processo Pessoal de Software
Objetivos do PSP:
• Ajudar as pessoas a serem melhores engenheiros de software;
• Estabelecer um mecanismo para melhorar, no nível pessoal, a
capacidade de planejamento, acompanhamento e qualidade dos
resultados.
O PSP pode ser usado por pessoas em empresas que ainda estão no nível
1 do CMM (Capability Maturity Model). Alguns benefícios mútuos não
aparecerão mas certamente a pessoa perceberá as melhorias no nível
pessoal.
PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
Estágios do PSP
Classificação
Processos pessoais
básicos
Nome
Elementos novos de processo
PSP0
Registro de tempos, Registro de defeitos,
Padronização dos tipos de defeitos
PSP0.1
Processos pessoais com
planejamento
PSP1
PSP1.1
Processos pessoais com
gestão da qualidade
PSP2
PSP2.1
Processos pessoais
cíclicos
PSP3
Padronização da codificação, Medição do tamanho,
Proposição de melhorias de processos
Estimativas de tamanho, Relatórios de testes
Planejamento de tarefas, Planejamento de
cronogramas
Revisões de código, Revisões de desenho
Modelos de desenho
Desenvolvimento cíclico
PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
Team Software Process (TSP) ou Processo de Software para Times
O TSP é um modelo para gerenciar equipes de desenvolvedores de software
(compostas geralmente de mais de 20 pessoas) no desenvolvimento e na
manutenção de projetos. Nele, são utilizados métodos de disciplina,
oferecendo assim, condições para uma equipe definir e melhorar continuamente
o processo de desenvolvimento de software.
Introductory Team Software Process - (TSPi)
Devido à sua complexidade, é bastante difícil aplicar o TSP em equipes com
menos de 20 pessoas. Por esse motivo, Humphrey desenvolveu o TSPi que é
baseado em 7 princípios.
PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
Princípios do TSPi
1. Fornecer um framework simples, com base nos fundamentos do PSP
(Personal Software Process);
2. Desenvolver produtos em vários ciclos;
3. Estabelecer medidas-padrão para qualidade de software;
4. Fornecer medidas precisas para equipes;
5. Utilizar avaliações de papéis e de equipe;
6. Fornecer disciplina nos processos;
7. Fornecer direção para soluções de problemas do trabalho em equipe.
PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
O TSPi utiliza os seguintes conceitos do desenvolvimento de
software:
• Roteiros: podem ser considerados um guia de execução de atividades;
• Formulários: para coleta e totalização dos dados;
• Padrões: três tipos de documentos padrões que auxiliam as equipes no
desenvolvimento:
•
Padrão de tipos de defeitos;
•
Padrão para composição das anotações do projeto;
•
Padrão de critérios de qualidade.
PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
Rational Unified Process – RUP
• O RUP é um processo de desenvolvimento de software que utiliza a
Unified Modeling Language - UML – como notação de uma série de
modelos que compõem os principais resultados das atividades de uma
metodologia.
• O RUP utiliza pequenos ciclos do projeto (mini-projetos), que
correspondem a uma iteração e resultam em um incremento no software.
PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
Rational Unified Process – RUP
Embora o RUP sugira um processo, ele pode ser considerado como:
• uma abordagem de desenvolvimento de software que é iterativa, centrada na
arquitetura e dirigida por casos de uso, ou seja, levantamento de requisitos
baseados na visão do usuário;
• um processo de engenharia de software bem definido e bem estruturado. Ele
claramente define quem é o responsável pelo que, como as coisas são feitas e
quando fazê-las;
• um produto processo que fornece um framework de processo customizável
para a engenharia de software. Essas customizações podem ser feitas para
suportar pequenas equipes e abordagens disciplinadas ou menos formal para o
desenvolvimento.
PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
Rational Unified Process – RUP
Desenvolvimento iterativo controlado é superior à abordagem tradicional
em cascata por várias razões:
• Gerenciar a mudança de requisitos;
• Integração contínua;
• Redução dos riscos;
• Possibilidade de mudanças táticas;
• Facilita o reuso;
• Resulta numa arquitetura mais robusta;
• Aprendizado;
• Refinamento do processo.
PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
Rational Unified Process – RUP
Todos os componentes do processo, da captura dos requisitos aos testes, são
dirigidos por casos de uso.
PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
Rational Unified Process – RUP
Os Casos de Uso definidos para um sistema são a base de todo o
processo de desenvolvimento. Eles orientam o desenvolvimento:
• Na análise de requisitos os casos de uso são usados para capturar os
Requisitos;
• No design devem ser identificadas as classes a partir dos casos de uso;
• Na implementação os casos de uso são implementados;
• Nos testes os casos de uso devem ser verificados. Os casos de uso
tornam-se casos de teste.
PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
Rational Unified Process – RUP
PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
RUP – Estruturação do processo
PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
RUP - Fases do ciclo de vida do software
O processo tem quatro fases:
• Início (Inception): definição do escopo do projeto
• Elaboração (Elaboration): planejamento do projeto, especificação das
características e design da arquitetura
• Construção (Construction): construção do produto
• Transição (Transition): colocar em ação (deployment) para a comunidade de
usuários
PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
RUP – Iterações do ciclo de vida do software
Uma iteração é um ciclo completo de desenvolvimento finalizando com uma
versão (release) de um produto executável que é um pedaço incrementado no
produto final em desenvolvimento.
PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
RUP – Desenvolvimento iterativo
PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
Praxis
• É desenhado para suportar projetos realizados individualmente ou por
pequenas equipes, com duração de seis meses a um ano;
• Abrange tanto métodos técnicos (requisitos, análise, desenho, testes e
implementação, etc) quanto métodos gerenciais (gestão de requisitos, gestão de
projetos, garantia da qualidade, gestão de configurações, etc);
• Propõe um ciclo de vida composto por fases que produzem um conjunto
precisamente definido de artefatos (documentos e modelos);
• Sua linguagem de modelagem é a UML;
• Reflete muitos elementos do Processo Unificado;
• Assim como o RUP, é um processo concreto, ou seja, contém um conjunto de
padrões e gabaritos para serem aplicados.
PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
Os processos essenciais a qualquer projeto estão representados no
diagrama de rede (ou diagrama de precedência) abaixo:
Planejamento
do Escopo
do Produto
Definição das
Atividades
Seqüência das
Atividades
Programação
Definição
do WBS
Planejamento
dos Recursos
Estimativas e
Durações
Planejamento
Global
Estimativa
dos Custos
Planejamento
dos Riscos
Orçamento
dos Riscos
PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
Além dos processos da figura anterior, alguns projetos requerem
também os processos auxiliares abaixo:
Planejamento
da Qualidade
Planejamento
Organizacional
Contratação
de Pessoal
Planejamento
de Aquisições
Preparação da
Documentação
Planejamento
da
Comunicação
Identificação
dos Riscos
Análise
Qualitativa
Análise
Quantitativa
Planos de
Resposta ao
Risco
PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
Planejamento do Escopo do Projeto
A entrada para este processo é a descrição do produto que será
produzido, ou do serviço a ser executado pelo projeto.
O escopo do produto não deve ser confundido com o escopo do
projeto. O escopo do projeto define o conjunto de trabalhos que
serão executados para construir e entregar o produto.
Como o escopo do projeto descreve as principais atividades a serem
executadas, é a base para a elaboração do cronograma e do orçamento.
Algumas vezes é necessário especificar o que o produto não vai
produzir, principalmente quando existe algo que as pessoas possam
presumir como sendo parte implícita do produto.
PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
Processos podem ser definidos para:
• Desenvolvimento de software
• Manutenção de software
• Aquisição de software
• Contratação de software
Para cada um desses processos, pode-se definir sub processos.
PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
Embora existam várias ferramentas para
ajudar as organizações a desenvolver
software com qualidade, a maioria das
organizações
gasta
suas
energias
“apagando incêndios”
• O fogo está sob controle
• Reação (e não agindo pró-ativamente)
– Não há tempo para melhoria
• Os “ bombeiros” se queimam
• As cinzas podem voltar a se incendiar mais tarde
• Sua única forma de controle - prevenção de incêndio
PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
Referências Bibliográficas
Albuquerque, Antonio Roberto; Schiavo, Luciano. Uma visão de abordagem de desenvolvimento de software do Rational
Unified Process. Disponível em <http://www.simpep.feb.unesp.br/Artigos%20Apresentados.htm>. Acesso em 01/02/2005.
Hazan,
Claudia.
Implantação
de
um
processo
de
medições
de
software.
Disponível
http://www.bfpug.com.br/Artigos/Palestra%20_Medicoes%20Claudia%20Hazan.pdf . Acesso em 03/02/2005.
em
Leite, Jair C. Processo de Desenvolvimento de Software. Disponível em <www.dimap.ufrn.br/~jair/ES/slides/Processo.pdf>.
Acesso em 01/02/2005.
Martins, José Carlos Cordeiro. Gerenciando projetos de desenvolvimento de software com PMI, RUP e UML. Rio de
Janeiro: Brasport, 2004.
Paula Filho, Wilson de Pádua. Engenharia de Software – Fundamentos, Métodos e Padrões. Rio de Janeiro: LTC, 2003.
Ribeiro, Carlos Augusto. Apostila de Engenharia de Requisitos.
Souza, Isabel Fernandes de. Apostila de Engenharia de Sistemas de Informação – Qualidade – Parte VIII.
Sommerville, Ian. Engenharia de Software. São Paulo: Pearson Education, 2003.
<http://www.ibm.com/br/products/software/rational/des.phtml>. Acesso em 03/02/2005.
<http://www.esicenter.unisinos.br/index.php?pg=frm_rumocmmi25.php>. Acesso em 03/02/2005.
<www.dimap.ufrn.br/~jair/ES/slides/rup.pdf> . Acesso em 01/03/2005.
Tópico 3 - Paradigmas do Desenvolvimento de Software
· Conceitos da Modelagem Estruturada
· Conceitos da Modelagem Essencial
· O Paradigma Orientado a Objetos
o Objetos e classes
o Relacionamentos entre objetos
o Abstração
o Polimorfismo, Herança e Encapsulamento
PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE
Considerações sobre a Modelagem
• A modelagem é um técnica de engenharia aprovada e bem-aceita;
• Um modelo é uma simplificação da realidade;
• Construímos modelos para compreender melhor o sistema que
estamos desenvolvendo;
• Construímos modelos de sistemas complexos porque não é
possível compreendê-los em sua totalidade;
• Um modelo é expresso através de uma linguagem (linguagem de
modelagem).
PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE
A linguagem para a construção de modelos deve ter:
• Elementos do modelo - conceitos e semântica fundamentais ao
modelo;
• Notação dos elementos - representação visual dos elementos do
modelo;
• Guidelines - guias de como e onde usar a linguagem.
PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE
Objetivos alcançados com a Modelagem
• Os modelos ajudam a visualizar o sistema como ele é ou como
desejamos que seja;
• Os modelos permitem especificar
comportamento de um sistema;
a
estrutura
ou
o
• Os modelos permitem que as discussões sobre as modificações e
correções nos requisitos do usuário sejam feitas com baixo custo
e mínimo risco;
• Os modelos proporcionam um guia para a construção do sistema;
• Os modelos documentam as decisões tomadas.
PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE
Princípios da Modelagem
• A escolha dos modelos a serem criados tem profunda influência
sobre a maneira como um determinado problema é atacado e
como uma solução é definida;
• Cada modelo poderá ser expresso em diferentes níveis de
precisão;
• Os melhores modelos estão relacionados à realidade;
• Nenhum modelo único é suficiente. Qualquer sistema não-trivial
será melhor investigado por meio de um pequeno conjunto de
modelos quase independentes.
PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE
Antes da Modelagem Estruturada - 1950~meados da década de 60
• Programar é uma arte;
• Pouco método formal – maioria: tentativa e erro;
• Descrição em textos (linguagem natural) e fluxograma.
PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE
Modelagem Estruturada - Meados da década de 60~meados da
década de 70
Ambiente:
• Em 1969 – Criada a Disciplina de Engenharia de Software
Características da Análise Estruturada:
• Representação gráfica dos requerimentos dos sistemas;
• Preocupação com os fluxos de dados;
• Prega a separação entre modelo lógico e físico do sistema, mas
não diz como fazê-la.
PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE
Modelagem Estruturada
Ferramentas estruturadas para análise:
• Alguma coisa que nos ajude a segmentar nossos requisitos e o
documento em si, particionado antes da especificação – Diagrama
de Fluxo de Dados (DFD).
• Algum meio para armazenar dados sobre os dados – Dicionário
de Dados (DD).
• Novas ferramentas para a descrição da lógica e do programa de
ação, alguma coisa melhor que narrativa de texto – Português
estruturado, Tabelas de decisão e Árvores de decisão.
PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE
Modelagem Essencial - Meados da década 70~final da década de 80
Ambiente:
•
•
•
•
Sistemas distribuídos;
“Inteligência” embutida;
Hardware de baixo custo;
Impacto no consumidor.
Características da Análise Essencial:
•
•
•
•
Encontrar o Modelo Essencial do Sistema;
Abandono da modelagem do sistema atual;
Particionamento por Eventos;
Incorporação da Modelagem de Dados no processo de Especificação.
PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE
Princípios da Modelagem Essencial
FASES DO
PROJETO
OBJETIVO
ATIVIDADE
Projeto Lógico
Descrever o comportamento desejado
para o sistema
Elaborar o modelo
essencial
Projeto
Tecnológico
Descrever a organização da tecnologia
automatizada que incorporará o
comportamento desejado
Elaborar o modelo
de implementação
Implementação
Incorporar o modelo de implementação
ao hardware e software
Construir o sistema
PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE
O Modelo Essencial
SUBMODELO
OBJETIVO
Ambiental
Descrição do ambiente no
qual o sistema opera
Comportamental
Descrição do comportamento
em resposta a eventos em
seu ambiente
FERRAMENTAS
• Descrição do propósito
• Lista de eventos
• Diagrama de contexto
• MER
• DFD
• DTE
• Dicionário de Dados
• Miniespecificação de
processos
PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE
Tecnologia Perfeita
A tecnologia perfeita é útil pois facilita a identificação da essência do
sistema. Com ela, um sistema teria um processador perfeito e um container
perfeito.
Um processador perfeito seria capaz de fazer qualquer coisa
instantaneamente, não custaria nada, não consumiria energia, não ocuparia
espaço, não geraria calor, nunca cometeria um erro e nunca quebraria.
Um container perfeito teria muitas das mesmas virtudes e seria capaz de
conter uma quantidade infinita de dados. Qualquer processador poderia
alcançar adequadamente os seus dados.
PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE
O Paradigma da Orientação a Objetos - Final da década 80~até hoje
Ambiente:
• Sistemas desk-tops poderosos
• Software Free
• Inteligência Artificial
• Sistemas especialistas
• Redes neurais artificiais
• Data Mining
• Computação paralela
PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE
O Paradigma da Orientação a Objetos - Final da década 80~até hoje
Ambiente:
• Programação em pequenos devices
• Sistemas embarcados
• Processo de Desenvolvimento de Software
• Modelos de Qualidade de Software – CMM/ISO/SPICE
• Processo de Desenvolvimento de Software – RUP/EUP/PRAXIS
• Metodologia Orientada a Objetos
• Gerenciamento de Projetos
• Gerenciamento de Requisitos
• Gerenciamento de Versão e Configuração
PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE
• A orientação a objetos é um novo paradigma de
desenvolvimento de software que visa abordar o
mundo real como tal
• A filosofia básica é a visão do domínio do problema
como um conjunto de objetos, que possuem
características, comportamentos e comunicam-se
através de mensagens
PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE
Princípios da Orientação a Objetos:
1. Qualquer coisa é um objeto.
2. Os objetos realizam tarefas através da requisição de serviços a outros
objetos.
3. Cada objeto pertence a uma determinada classe. Uma classe agrupa
objetos similares.
4. A classe é um repositório para comportamento associado ao objeto.
5. Classes são organizadas em hierarquia.
O paradigma da orientação a objetos visualiza um sistema de software
como uma coleção de agentes interconectados chamados objetos. Cada
objeto é responsável por realizar tarefas específicas. É através da
interação entre objetos que uma tarefa computacional é realizada.
PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE
leão :
Animal
• Objeto
Objeto
Representação Gráfica
do Objeto
• Conjunto de objetos semelhantes: Classe
Conjunto de Objeto
Representação Gráfica
dos Objetos = Classe
Animal
PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE
Conjunto de Objetos
Representação Gráfica
dos Objetos = Classe
Animal
Características
Comportamento
peso
altura
cor
come()
locomove()
corre()
PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE
Mensagens
• Quando se diz na terminologia da orientação a objetos que objetos
estão trocando mensagens significa que esses objetos estão enviando
mensagens uns para os outros com o objetivo de realizar uma tarefa
dentro do sistema no qual eles estão inseridos.
Objeto
Objeto
Objeto
Objeto
Objeto
PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE
• A comunicação entre os objetos é feita através de
mensagens.
– Abstração de dados
– Informação de controle
Mensagem
Ande
Representação Gráfica Mensagem
1: ande( )
joão :
Homem
coelho :
Animal
PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE
Princípios da orientação a objetos como aplicações do Princípio da
Abstração
Orientação a Objetos
Encapsulamento
Polimorfismo
Abstração
Herança
PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE
Encapsulamento
• Objetos possuem comportamento (operações que o objeto pode
realizar);
• O mecanismo de encapsulamento é uma forma de restringir o acesso ao
comportamento interno de um objeto.
• O objeto requisitante precisa conhecer quais as tarefas que um outro
objeto sabe fazer ou que informação ele conhece.
• Interface de um objeto – é o que ele conhece e o que ele sabe fazer, sem
descrever como o objeto conhece ou faz. A interface de um objeto define
os serviços que ele pode realizar e consequentemente as mensagens que
ele recebe.
• Através do encapsulamento, a única coisa que um objeto precisa saber
para pedir a colaboração a outro objeto é conhecer a sua interface
PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE
Polimorfismo - etimologicamente, quer dizer “várias formas“.
• O polimorfismo indica a capacidade de abstrair várias implementações
diferentes de uma única interface. Ex: Controle remoto do DVD que serve
também para a TV;
• A abstração também é aplicada no polimorfismo: um objeto pode enviar a
mesma mensagem para objetos semelhantes, mas que implementam a sua
interface de forma diferente;
• Na Informática, e em particular no universo da POO, é definido como sendo
um código que possui "vários comportamentos" ou que produz “vários
comportamentos“;
• De maneira prática isto quer dizer que a operação em questão mantém seu
comportamento transparente para quaisquer tipos de argumentos; isto é, a
mesma mensagem é enviada a objetos de classes distintas e eles poderão
reagir de maneiras diferentes.
PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE
Herança
• As características e o comportamento comuns a um conjunto de objetos
podem ser abstraídos em uma classe;
• Na herança, classes semelhantes são agrupadas em hierarquia;
• Cada classe em um nível da hierarquia herda as características das
classes nos níveis acima.
Figura
Maior
abstração
Figura Geométrica
Menor
abstração
Quadrado
Círculo
Linha
PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE
Estereótipos
• são extensões de elementos do modelo;
• podem ser utilizados para denotar especializações significativas de
classes;
• podem ser indicados através de ícones próprios, ou incluindo-se o
nome do estereótipo em aspas francesas (<< >>).
Divisão das classes do Modelo de Análise
Jacobson propõe a divisão das classes do Modelo de Análise de acordo
com os seguintes estereótipos: entidades (entity), fronteiras (boundary)
e controles (control).
<< boundary >>
Tela de Venda
<< control >>
Controlador de Venda
<< entity >>
Venda
PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE
Classes de Entidades
• Modelam informação persistente, sendo tipicamente independente da
aplicação;
• São candidatas mais fortes a serem reutilizadas;
• Geralmente são necessárias para cumprir alguma responsabilidade do
produto;
• Frequentemente correspondem a entidades de banco de dados.
Classes de Fronteiras
• Tratam da comunicação com o ambiente do produto;
• Modelam as interfaces do produto com usuários e outros sistemas;
• Durante a análise de domínio considera-se que as classes de fronteira
surgem de cada par ator-caso de uso.
PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE
Classes de Controles
• Coordenam o fluxo de um caso de uso complexo, encapsulando
lógica que não se enquadra naturalmente nas responsabilidades das
entidades;
• São tipicamente dependentes da aplicação;
• Um caso de uso muito simples pode ser coordenado por uma
classe de fronteira;
• Por exemplo, pode-se definir classes de controle para coordenar
um subfluxo ou um fluxo alternativo mais complexo, um
algoritmo, a geração de um relatório ou uma regra de negócio
complexa.
PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE
Classes Abstratas x Classes Concretas
• Na hierarquia de classes, é comum especificar que certas classes são abstratas –
significando que não poderão apresentar instâncias diretas;
• Por contraste, uma classe concreta é aquela que pode ser instanciada;
• As classes abstratas são constituídas através da união de conceitos genéricos, que
serão adequados ao domínio da aplicação através apenas de suas subclasses;
• Classes abstratas são as candidatas em potencial para a reutilização, já que são
modeladas para este fim. Elas representam a melhor solução para reutilizar
comportamentos não associados diretamente ao domínio da aplicação;
• Como as classes abstratas são mais complexas, elas devem justificar a sua
existência. Devem ser definidas para servirem ao domínio público da organização,
deixando flexível a implementação específica.
PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE
Unified Modeling Process (UML)
• É uma linguagem de modelagem visual para
modelar sistemas orientados a objetos;
• Sua definição ainda está em desenvolvimento e
possui diversos colaboradores da área
comercial, como: Digital, HP, IBM, Oracle,
Microsoft, Unisys, IntelliCorp, i-Logix e
Rational;
• É independente tanto de
programação quanto de
desenvolvimento.
linguagem
processos
de
de
PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE
12/junho/2003
UML 2.0
1997-2002
UML 1.2 UML 1.3
UML 1.4 UML 1.5
Set 1997
OMT + BOOCH = UML 1.1
Jan 1997
OMT + BOOCH = UML 1.0
Microsoft, IBM, HP, outras
Jun 1996
OMT + BOOCH = UML 0.9
Iva Jacobson
Out 1995
OMT + BOOCH = UML 0.8
Grady Booch
James Rumbaugh
PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE
Visões de um Sistema de Software
Visão de Projeto
Visão de
Implementação
Visão de Casos de Uso
Visão de Processo
Visão de
Implantação
PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE
A UML sugere as seguintes visões para um sistema:
• Visão de Casos de Uso: descreve o sistema de um ponto de vista externo
como um conjunto de interações entre o sistema e os agentes externos ao
sistema. Esta visão é criada inicialmente e direciona o desenvolvimento das
outras visões.
• Visão de Projeto: enfatiza as características do sistema que dão suporte tanto
estrutural quanto comportamental, às funcionalidades externamente visíveis do
sistema.
• Visão de Implementação: abrange o gerenciamento de versões do sistema,
construídas através de agrupamento de módulos (componentes e subsistemas).
• Visão de Implantação: corresponde à distribuição física do sistema em seus
subsistemas e à conexão entre essas partes.
• Visão de Processo: esta visão enfatiza as características de concorrência
(paralelismo), sincronização e desenho do sistema.
PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE
Diagramas da UML
Diagramas
da UML
Diagramas
de Casos de Uso
Diagramas
de Classes
Diagramas
de Atividades
Diagramas
De Objetos
Diagramas
De Interação
Diagramas
de Sequência
Diagramas
de Implementação
Diagramas de
Transições de Estado
Diagramas
de Componentes
Diagramas
de Colaboração
Diagramas
de Implantação
PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE
Visões de um Sistema de Software
Visão de Projeto
Diagram. de Classes
Diagram. de Objetos
Diagram. de Interação
Diagram. Transição de Estado
Diagram. de Atividades
Visão de
Implementação
Diagram. de Componentes
Diagram. de Interação
Diagram. de Transição de Estado
Diagram. de Atividades
Visão de Caso de Uso
Visão de
Processo
Diagramas de Caso de Uso
Diagram. de Interação
Diagram. de Transição de Estado
Diagram. de Atividades
Diagram. de Classes
Diagram. de Objetos
Diagram. de Interação
Diagram. Transição de Estado
Diagram. de Atividades
Visão de
Implantação
Diagram. de Implantação
Diagram. de Interação
Diagram. de Transição de Estado
Diagram. de Atividades
PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
Work Breakdown Structure – WBS (Estrutura Analítica de Trabalho –
EAT)
• O WBS é um chek-list que identifica todas as partes do projeto e as tarefas
associadas.
• É peça central no planejamento de qualquer projeto.
• Contém dois tipos de elementos:
• Pacote Trabalho – Corresponde a uma atividade que será atribuída a uma
pessoa ou equipe.
• Tarefa Resumo – Corresponde a um agrupamento de pacotes de trabalho.
Quando uma equipe recebe um pacote de trabalho, ela poderá listar o
conjunto de atividades que precisam ser executadas e distribuir estas
atividades entre os membros da equipe. O pacote de trabalho representa,
então, o menor nível de gerenciamento para o gerente do projeto.
PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
Work Breakdown Structure – WBS (Estrutura Analítica de Trabalho – EAT)
Existem WBS padrão para determinados tipos de projetos, que podem servir como
ponto de partida para a criação do WBS específico para o projeto, Exemplo:
Engenharia Civil, Aeronáutica, Desenvolvimento de Software, etc.
O WBS para desenvolvimento de software pode ser baseado em diferentes
linguagens de modelagem (Análise Essencial, UML, etc) e diferentes
metodologias de desenvolvimento (Rational Unified Process - RUP, Praxis, etc).
O critério de finalização de uma tarefa pode ser definido através das respostas às
seguintes requisitos:
• O que significa terminar esta tarefa? Como saber se tudo foi feito corretamente?
• Descobrir critérios de aceitação do cliente para reproduzí-los “em casa”.
• Checar a verificação do trabalho através de uma lista de verificação ou teste
sistemático.
PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE
Exemplo de WBS para desenvolvimento de software baseado em RUP
Projeto de
Desenvolvimento
de Software
Requisitos do
Negócio
Modelo de
Negócio
Especificação
Implementação
Testes
Implantação
Modelo de
Caso de Uso
Camada de
Regras de Negócio
Modelo de
Testes
Banco de
Dados
Modelo de
Análise
Camada de
Persistência
Testes de
Integração
Aplicações
De Software
Modelo de
Designe
Camada de
Dados
Aplicações de
Usuários
Modelo de
Implementação
Camada de
Interface com o
Usuário (GUI)
Treinamento
Modelo de
Implantação
Manual do
Usuário
PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE
Referências Bibliográficas
Bezerra, Eduardo. Princípios da Análise e Projeto de Sistemas com UML. Rio de Janeiro:
Elsevier, 2002.
Booch, Grady; Rumbaugh, James; Jacobson, Ivar. UML – Guia do Usuário. Rio de Janeiro:
Campus, 2000.
DeMarco, Tom. Análise Estruturada e Especificação de Sistema. Rio de Janeiro: Campus, 1989.
Ito, Marcia. UML e a Modelagem de Sistemas – Um Enfoque Prático. Disponível em
<http://www.mind-tech.com.br/users/ito/marcia>. Acesso em 01/02/2005.
McMenamim, Sthephen M.; Palmer, John F. Análise Essencial de Sistemas. São Paulo:
MacGraw-Hill, 1991.Paula Filho, Wilson de Pádua. Engenharia de Software – Fundamentos,
Métodos e Padrões. Rio de Janeiro: LTC, 2003.
Paula Filho, Wilson de Pádua. Engenharia de Software – Fundamentos, Métodos e Padrões. Rio
de Janeiro: LTC, 2003.
Pompilho, S. Análise Essencial – Guia Prático de Análise de Sistemas. Rio de Janeiro:
Infobook, 1995.
Souza, Isabel Fernandes de. Apostila de Engenharia de Sistemas de Informação – Parte II.
Tópico 4 - Análise e Especificação de Requisitos
· O que são requisitos
o Definição
o Classificação
· Produção de requisitos
o Levantamento de requisitos
- Fontes
- Técnicas de comunicação com clientes e usuários
. Análise de documentos
. Entrevistas
. Reuniões
. Observação
. Etnografia
o Registro dos requisitos
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS
Requisitos
The IEEE Standard Glossary of Software Engineering Terminology
[IEEE97] define requisito como uma condição ou capacidade
necessária para um usuário resolver um problema ou alcançar um
objetivo (...).
Desta definição pode-se aferir que os requisitos de software são
derivados de necessidades que usuários têm em resolver algum
problema. Situa-se, então, o domínio do problema.
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS
Os domínios da Engenharia de Requisitos
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS
Definição de universo de informações
A especificação de requisitos deve incluir não somente as
especificações do domínio do problema, mas também qualquer
tipo de informação que descreva o contexto do sistema.
Esse contexto é conhecido como universo de informações, que é
a realidade circunstanciada pelo conjunto de objetivos definidos
pelos que demandam o software, e inclui todas as fontes de
informação e todos os stakeholders.
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS
Definição de domínio do problema
• O domínio do problema é o domínio de atuação do software e
inclui todos os elementos que interagem com ele.
• O domínio do problema é, portanto, o ambiente de atuação do
software. Neste ambiente principiam as atividades da engenharia
de software, a definição das necessidades do software.
• É tarefa dos engenheiros de requisitos entender o problema, na
cultura e linguagem dos usuários, e definir um sistema que
atenda às suas necessidades. Para tal, o engenheiro de requisitos
deve descobrir e estabelecer o universo de informações, de onde
obtém os recursos na tarefa de elucidação do problema.
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS
Definição do domínio da solução
• No domínio da solução é enfocada a definição da solução aos
problemas dos usuários.
• Os desenvolvedores do software aplicam seus conhecimentos em busca
da especificação do sistema a ser desenvolvido.
• Envolve as características da solução e os requisitos do sistema.
• Uma característica é definida como um serviço que o sistema provê
para cumprir uma ou mais necessidades dos stakeholders.
• Uma vez estabelecido o conjunto de características com a concordância
dos stakeholders, deve-se definir os requisitos mais específicos que serão
necessários impor a solução.
• Requisitos são propriedades que um sistema de software deve ter.
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS
Requisitos
• Funcionais – representam os comportamentos que um programa ou sistema
deve apresentar diante de certas ações de seus usuários.
• Não-funcionais – quantificam determinados aspectos do comportamento.
(Ex: tempo de resposta, tempo médio entre falhas, etc.).
Especificações dos requisitos:
• Explícitos – são aqueles descritos em um documento que arrola os requisitos
de um produto, ou seja, a especificação de requisitos.
• Normativos – são aqueles que decorrem de lei, regulamentos e outros tipos
de normas a que o produto deve obedecer.
• Implícitos – são expectativas dos clientes e usuários, que são cobradas por
esses, embora não documentadas.
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS
Processo de Aquisição e Especificação de Requisitos
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS
Elicitação (Levantamento) de Requisitos – Fontes
– Stakeholders
• Clientes
• Usuários
• Desenvolvedores
– Documentos
– Livros
– Sistemas de software (específico da organização ou software
comercial)
Levantamento de requisitos – Técnicas
– Levantamento orientado a pontos de vista
– Cenários
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS
Levantamento orientado a pontos de vista
• Normalmente, há diferentes tipos de usuário final e, em função disso,
diferentes pontos de vista.
• Os pontos de vista podem ser organizados de forma hierárquica, como por
exemplo:
Todos os pontos de vista
Serviços
Consultar saldo
Retirar dinheiro
Cliente
Pessoal
do banco
Serviços
Pedir cheques
Enviar mensagem
Executar transação
da lista
Pedir extrato
Transferir fundos
Titular
da conta
Não-titular
da conta
Caixa
Gerente
Engenheiro
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS
Levantamento orientado a pontos de vista (continuação)
Referência:
Cliente
Referência:
Retirada de dinheiro
Atributos:
Número da conta PIN
Início da transação
Razão:
Melhorar serviço do cliente e
reduzir trabalho com papel
Eventos:
Selecionar serviço
Cancelar transação
Encerrar transação
Especificações:
Usuários escolhem o serviço
pressionando o botão de retirada
de dinheiro. Em seguida,
informam a quantia solicitada. A
operação é confirmada e, se o
saldo permitir, o dinheiro é
entregue.
Pontos de vista:
Cliente
Requisitos não
funcionais:
Entregar o dinheiro um minuto
após ser confirmada e quantia.
Serviços:
Retirada de dinheiro
Consulta de saldo
Subpontos de vista:
Titular da conta
Não-titular da conta
Preenchido posteriormente
Provedor:
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS
Cenários
• Cada cenário aborda um ou um pequeno número de possíveis interações.
• O cenário geralmente começa com um esboço da interação e, durante o
levantamento de requisitos, são acrescentados detalhes para criar uma
distribuição completa dessa interação.
• O cenário pode incluir:
• uma descrição de estado do sistema no início do cenário;
• uma descrição do fluxo normal de eventos no cenário;
• uma distribuição do que pode sair errado e de como lidar com isso;
• informações sobre outras atividades que possam estar em andamento ao
mesmo tempo;
• uma descrição do estado do sistema no final do cenário.
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS
Métodos de Coleta de Requisitos
Algumas técnicas das ciências sociais, como psicologia e sociologia, têm
sido estudadas e utilizadas nesta atividade, que envolve fatores
comportamentais e de relacionamento humano.
Entre os métodos mais comuns estão:
• análise de documentos;
• entrevistas (tutoriais, estruturadas, não-estruturadas, semi-estruturadas);
• reuniões (Participatory Design, Joint Application Design e
Brainstorming);
• observações;
• etnografia.
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS
Análise de documentos
• A análise de documentos é uma técnica usualmente aplicada na
qual explora-se o conhecimento escrito encontrado no universo de
informações.
• A análise dos documentos permite um contato com o vocabulário
utilizado no domínio do problema e auxilia na construção do
glossário de termos especializados, que tem por objetivo definir os
objetos e equalizar o conhecimento dos stakeholders.
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS
Técnicas de entrevistas
• Entrevista é uma técnica de interação entre entrevistado (especialista do conhecimento) e
entrevistador (engenheiro de requisitos) buscando revelar conceitos, objetos e a organização do
domínio do problema, além de buscar soluções ou projeções de soluções que comporão o
domínio da solução.
• Entrevistas tutoriais - o entrevistado fica no comando, praticamente lecionando sobre um
determinado assunto.
• Entrevistas informais (não estruturadas) - o entrevistador age espontaneamente, perguntando
ao entrevistado sem obedecer a nenhuma organização. Esse tipo de entrevista oferece
flexibilidade ao entrevistador e, normalmente, é utilizado no início do processo de elicitação.
• Entrevistas estruturadas - são preparadas pelo entrevistador, que define previamente o
andamento do procedimento de aquisição de conhecimento.
• Entrevistas semi-estruturadas – são entrevistas que misturam as características das entrevistas
estruturadas e das entrevistas não estruturadas.
• Um fator importante a ser considerado nas entrevistas é o registro das informações coletadas,
que pode ser realizado através de anotações ou gravações de áudio ou vídeo. O material
produzido deve ser organizado e serve como base para a preparação da próxima entrevista.
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS
Técnicas de reuniões
Reunião - Permite uma interação mais natural entre os participantes e que
podem oferecer múltiplas visões sobre a questão abordada.
•Joint Application Design, Participatory Design e Brainstorming são
metodologias de reuniões que enfatizam a participação coletiva na elicitação
de requisitos.
• Joint Application Design (JAD) - Baseia-se em sessões estruturadas e
disciplinadas, onde os envolvidos reúnem-se para desenvolver juntos o
sistema de software. Em linhas gerais, essas sessões possuem uma agenda
detalhada, recursos visuais para auxiliar a exposição de idéias, um
moderador e um relator que registra as especificações de acordo comum
entre os membros do grupo. O produto final é um documento que contém
definições do software.
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS
Técnicas de reuniões (continuação)
•Participatory Design (PD) é uma abordagem que concentra-se mais fortemente
no envolvimento dos usuários, em relação ao Joint Application Design, por
facilitar o processo de aprendizado entre desenvolvedores e usuários através de
experiências conjuntas em situações de trabalho simuladas. Em linhas gerais,
os usuários são introduzidos no ambiente dos desenvolvedores, conhecendo
possibilidades técnicas e, da mesma maneira, os desenvolvedores colaboram com
os usuários em suas tarefas. Ocorre um aprendizado mútuo que vem a contribuir
no processo de definição dos requisitos.
•Braistorming - A filosofia básica do brainstorming é procurar deixar que venham
a tona todas as idéias possíveis, sem que estas sofram quaisquer críticas durante o
processo de criação. Isto diminui os bloqueios, e permite que as idéias fluam
melhor. Isto faz com que o inconsciente comece a desbloquear parte do raciocínio
não-lógico que estava bloqueado e, quando bem aplicado, seja um poderoso
instrumento de trabalho. Nesta reunião, a característica principal é a total ausência
de crítica e o julgamento adiado. As idéias que surgirem serão anotadas, por mais
loucas que possam parecer, e nunca sofrerão críticas na hora em que forem
formuladas.
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS
Técnica de observação
• Observação é uma técnica na qual o engenheiro de requisitos
procura ter uma posição sobre o domínio do problema, observando
seus elementos e comportamentos.
• Visa obter um entendimento inicial sobre o contexto em estudo.
• As observações consistem em observar alguém no momento da
realização de suas tarefas rotineiras no ambiente real.
• O observador procura familiarizar-se com o domínio do problema
e elicitar as informações necessárias para o seu entendimento.
• A aquisição desse conhecimento pode ocorrer com interrupção ou
não das atividades do observador.
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS
Etnografia
• Outra técnica que pode ser aplicada de forma complementar com o intento
de permitir uma visão mais completa e ajustada do domínio do problema é a
etnografia.
• Etnografia é a coleta direta, e o mais minuciosa possível, dos fenômenos
observados, por uma impregnação duradoura e contínua e um processo que
se realiza por aproximações sucessivas.
• É originária da antropologia, em observações de práticas das sociedades.
• No contexto da engenharia de requisitos, é uma técnica que busca revelar
informações sobre a estrutura, organização e práticas do domínio do
problema.
• A etnografia, segundo conclusão do projeto realizado, pode levar a
obtenção de requisitos fechados à prática corrente, o conhecimento tácito.
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS
Validação de Requisitos
A validação de requisitos se ocupa em mostrar que os requisitos realmente definem o
sistema que o cliente deseja.
Principais verificações de requisitos:
• Verificações de validade – O sistema deve conciliar as necessidades de todos os
seus usuários.
• Verificações de consistência – Os requisitos em um documento não devem ser
conflitantes, ou seja, não devem existir restrições contraditórias.
• Verificações de completeza – O documento de requisitos deve incluir requisitos que
definam todas as funções e restrições exigidas pelo usuário do sistema.
• Verificações de realismo – Um conjunto de verificações deve ser projetado para
mostrar que o sistema entregue cumpre com seus requisitos.
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS
Validação de Requisitos (continuação)
Técnicas de validação de requisitos:
• Revisões de requisitos – É um processo manual, que envolve muitos
leitores, tanto do pessoal do cliente como do fornecedor, que verifica o
documento de requisitos a fim de detectar anomalias ou omissões.
• Prototipação – É fornecido um modelo do sistema para que o usuário
possa verificar se o sistema atenderá às suas necessidades.
• Análise automatizada da consistência - Utilização de ferramenta CASE
para fazer a de consistência dos requisitos.
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS
Registro dos requisitos
1. Missão do Produto
2. Limites do Produto
3. Lista de requisitos funcionais
•
Nome e descrição do requisito
•
Identificação do ator
•
Necessidades e Benefícios
•
Estabilidade
•
Prioridade
4. Descrição dos atores
5. Regras de Negócio
6. Lista de requisitos não funcionais
7. Lista dos requisitos de persistência
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS
1. Missão do Produto
Descrever os objetivos do produto que deverá ser desenvolvido no projeto. De
preferência, usar um único parágrafo que sintetize a missão a ser desempenhada
pelo produto, ou seja, que valor o produto acrescenta para o cliente e os usuários.
A declaração de missão deve cumprir os seguintes objetivos:
• delimitar as responsabilidades do produto;
• delimitar o escopo do produto;
• sintetizar o comprometimento entre cliente e fornecedor.
Exemplo:
O produto Merci 1.0 visa a oferecer apoio informatizado ao controle de vendas,
de estoque, de compra e de fornecedores da mercearia Pereira & Pereira.
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS
2. Limites do Produto
Deve-se determinar o que o produto não fará. Isso evita falsas expectativas
por parte dos clientes e usuários e podem ressaltar funções e atributos que
serão implementados por outros componentes de um sistema maior, ou em
versões futuras desse produto.
Exemplo:
1. O sistema não fará vendas parceladas e só receberá pagamentos em
dinheiro ou cheque.
2. O backup e a recuperação das bases de dados do sistema ficam a cargo da
administração, não sendo providos pelo sistema.
3. O sistema não terá ajuda on-line.
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS
3. Lista de requisitos funcionais – Nome e descrição do requisito
Os requisitos funcionais definem as ações fundamentais através das quais o
produto aceita e processa as entradas especificadas, gerando as respectivas
saídas.
Exemplo:
Número
Requisito
Descrição
1
Manter mercadoria
Realizar o cadastro (inclusão, alteração, exclusão e consulta dos
dados de uma mercadoria.
2
Manter pedido de compra
Realizar o cadastro (inclusão, alteração, exclusão e consulta dos
dados de umpedido de compra.
3
Abrir caixa
Dar início às operações do caixa.
4
Fechar caixa
Encerrar as operações do caixa.
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS
3. Lista de requisitos funcionais – Identificação dos atores
Na terminologia da UML, qualquer elemento externo que interage com o sistema é
denominado ator. Note que um ator corresponde a um papel representado em relação ao
sistema.
Critérios para identificação dos atores:
• quem está interessado em certo requisito;
• quem se beneficiará diretamente do produto;
• quem usará informação do produto;
• quem fornecerá informação ao produto;
• quem dará suporte e manutenção ao produto;
• quais os recursos externos usados pelo produto;
• quais os papéis desempenhados por cada usuário;
• quais os grupos de usuários que desempenham o mesmo papel;
• quais os sistemas legados com os quais o produto deve interagir;
• o tempo, quando os casos de uso são disparados periodicamente, de forma automática.
Exemplo: Caixa, Atendente, Sistema Financeiro, Setor de Cadastro, etc.
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS
3. Lista de requisitos funcionais – Identificação dos atores (continuação)
Os atores podem ser classificados em:
Ator Primário
• É aquele que inicia uma seqüência de interações de um caso de uso;
• É um agente externo para o qual o caso de uso traz benefício direto;
• As funcionalidades principais do sistema são definidas tendo em mente os
objetivos dos atores primários.
Ator Secundário
• É aquele que supervisiona, opera, mantém ou auxilia na utilização do sistema;
• Existem apenas para que os atores primários possam utilizar o sistema.
Exemplo-1: Considere um programa para navegar na Internet (browser). Para que o
usuário (ator primário) requisite uma página ao programa, um outro ator
(secundário) está envolvido: o Servidor Web.
Exemplo-2: Quando um cliente precisa da ajuda do vendedor para registrar suas
compras no sistema, o cliente é o ator primário e o vendedor o ator secundário.
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS
3. Lista de requisitos funcionais – Nome e descrição do requisito
Os requisitos funcionais definem as ações fundamentais através das quais o
produto aceita e processa as entradas especificadas, gerando as respectivas
saídas.
Exemplo:
Número
Requisito
Descrição
Ator
1
Manter mercadoria
Realizar o cadastro (inclusão, alteração, exclusão
e consulta dos dados de mercadorias.
Gerente de Compras
2
Manter fornecedor
Realizar o cadastro (inclusão, alteração, exclusão
e consulta dos dados de fornecedores.
Gerente de Compras
3
Manter pedido de compra
Controlar os pedidos de compra feitos aos
fornecedores.
Gerente de Compras
4
Abrir caixa
Dar início às operações do caixa.
Caixa
5
Fechar caixa
Encerrar as operações do caixa.
Caixa
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS
3. Lista de requisitos funcionais – Necessidades e Benefícios
Deve-se identificar as necessidades que os requisitos atenderão e os benefícios que eles
podem proporcionar. O levantamento dos benefícios é necessário para determinar se o
valor dele compensará o investimento no projeto.
Exemplo:
Núm.
Requisito
Ator
Necessidades
Benefícios
1
Manter
mercadoria
Gerente de
Compras
Identificação das mercadorias.
Fornecer dados para outras funções
Agilidade na compra e venda de mercadorias.
Melhoria do conhecimento dos produtos
comercializados.
2
Manter
fornecedor
Gerente de
Compras
Atualizar os dados dos fornecedores.
Atualizr a lista de produtos comercializados
por cada fornecedor.
Fornecer dados para outras funções
Controle dos dados de fornecedores.
Conhecimento do mercado de fornecedores.
Avaliação da qualidade de fornecimento.
3
Manter
pedido de
compra
Gerente de
Compras
Registro dos pedidos de compra.
Controle de cancelamento de pedidos.
Acompanhamento do prazo de entrega.
Registro da recepção das mercadorias.
Fornecer dados para outras funções
Apoio na avaliação das melhores condições de preço e
menores prazos de entrega.
Eliminação da duplicidade de pedidos.
Identificação de mercadorias não entregues.
4
Abrir caixa
Caixa
Colocar o caixa no modo de venda,
informando o seu valor de abertura.
Ter controle dos valores de cada abertura do caixa.
Diminuição de erros na prestação de contas.
5
Fechar caixa
Caixa
Encerrar as operações do caixa, apurando o
total das transações realizadas.
Ter controle da movimentação do período.
Diminuição de erros na prestação de contas.
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS
3. Lista de requisitos funcionais – Prioridade
Representa o valor atribuído ao requisito, pelo cliente, em função do(s)
benefício(s) que ele lhe proporcionará.
A prioridade é classificada em:
• Essencial – O requisito é fundamental. Sua falta acarretará o não
atendimento das necessidades do cliente.
• Desejável – A existência do requisito contribuirá para o atendimento das
necessidades do cliente, mas a sua falta é aceitável.
• Opcional – A existência do requisito está condicionada a sobra de
recursos, prazo, etc. Sua falta não prejudica o atendimento das
necessidades do cliente.
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS
3. Lista de requisitos funcionais – Estabilidade
Representa a probabilidade do requisito ser alterado no decorrer do
projeto, com base na experiência de projetos correlatos.
A estabilidade é classificada em:
• Alta – O requisito tem pouca chance de mudar no decorrer do
projeto.
• Média – A probabilidade do requisito mudar no decorrer do projeto
estaria em torno de 50% de chance.
• Baixa – O requisito tem grande chance de mudar no decorrer do
projeto.
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS
Exemplo: Lista de requisitos funcionais – Prioridade e Estabilidade
Número
1
2
Requisito Funcional
Manter mercadoria
Manter fornecedor
Ator
Prioridade
Estabilidade
Gerente de Compras
Essencial
Média
Gerente de Compras
Essencial
Baixa
3
Manter pedido de compra
Gerente de Compras
Opcional
Baixa
4
Abrir caixa
Caixa
Essencial
Média
5
Fechar caixa
Caixa
Essencial
Média
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS
4. Descrição dos Atores
Para cada ator deve-se incluir uma descrição sucinta das responsabilidades do
respectivo papel.
Deve-se também identificar as características mais importantes do respectivo
grupo de usuários.
Exemplo de descrição dos atores:
Ator
Descrição
Caixa
Funcionário operador comercial do caixa.
Gerente de Compras
Funcionário responsável pela gestão dos cadastros de
mercadorias e fornecedores, e pela emissão e acompanhamento
de pedidos de compra.
Sistema Financeiro
Sistema de gestão financeira que recebe os detalhes financeiros
das transações diárias, para utilização posterior pela
administração financeira da mercearia.
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS
5. Regras de Negócio
Segundo o Business Rules Group (BRG) pode-se definir regra de negócio segundo
dois aspectos:
Sistemas de informação
Regra de negócio é “uma sentença
que define ou restringe algum aspecto
do negócio (...) sua intenção é manter
a estrutura do negócio, ou controlar ou
influenciar algum aspecto do
negócio”. Nesse contexto, as regras de
negócio dizem respeito aos “dados
que podem ser cadastrados em um
sistema de informação”.
Negócio
Regras de negócio são “diretivas que
visam influenciar ou guiar o
comportamento do negócio. Tais
diretivas existem como suporte a
políticas de negócio, formuladas em
resposta a riscos, ameaças ou
oportunidades”.
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS
5. Regras de Negócio (continuação)
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS
5. Regras de Negócio (continuação)
Classificação das Regras de Negócio:
Regras de Rejeição (Rejector): são regras que rejeitam um evento porque ele conduz o
sistema a um estado que não é permitido. As restrições de integridade em bancos de
dados são exemplos desse tipo de regra.
Ex1: “Uma conta não pode ter saldo negativo”.
Ex2: “Um time não pode ter mais que 11 jogadores em campo”.
Regras de Projeção (Projector): são regras que projetam o evento em outros eventos
alterando os fluxos de execução.
Ex1: “Ao criar um cliente, deve ser criada uma nova conta para ele”.
Ex2: “Se uma conta tiver saldo maior que 5.000, enviar folheto sobre investimentos”.
Regras de Produção (Productor): são regras que não respondem a eventos, elas
apenas definem informações do negócio.
Ex1: “Saldo é igual a crédito menos débito”
Ex2: “Uma conta é “Ouro Especial” se seu saldo atual é superior a 30.000 e seu
médio saldo médio é superior a 20.000.”
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS
5. Regras de Negócio (continuação)
Exemplo:
Nome
Condição para realização do pedido de compra
(RN01)
Descrição
Somente serão aceitos pedidos de compra para
fornecedores que tenham menos do que 3
ocorrências de entrega fora do prazo.
Obs: Esta regra de negócio deverá ser aplicada no requisito Incluir
pedido de compra.
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS
6. Lista de requisitos não funcionais
Os requisitos não funcionais
podem ser classificados segundo
a seguinte estrutura hierárquica
Requisitos
do produto
Requisitos
de facilidade
de uso
Requisitos
de
confiabilidade
Requisitos
de eficiência
Requisitos
de
desempenho
Requisitos
Não
Funcionais
Requisitos
organizacionais
Requisitos
de
portabilidade
Requisitos
de entrega
Requisitos
de espaço
Requisitos
externos
Requisitos de
interoperabilidade
Requisitos
de padrões
Requisitos
de
implementação
Requisitos
de
privacidade
Requisitos
éticos
Requisitos
legais
Requisitos
de segurança
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS
6. Lista de requisitos não funcionais (continuação)
Exemplos:
RNF01
O tempo de totalização da Operação de Venda (isto é, o
intervalo de tempo entre qualquer alteração nos itens de venda
e a exibição do total a pagar) não pode ser maior do que 2
segundos.
RNF02
O tempo para realização de qualquer operação de pesquisa de
usuários, mercadorias, fornecedores ou pedidos de compra não
pode ser maior do que 10 segundos.
RNF03
O leiaute do relatório Nota Fiscal deve ser previamente
aprovado pela Secretaria de Receita.
RNF04
O Merci deverá ser desenhado de forma que possa ser
expandido para mais de um terminal.
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS
7. Lista dos Requisitos de Persistência
Requisitos de persistência são representados através das classes de entidade,
com seus atributos e operações.
Possíveis Notações para uma Classe na UML
Nome da Classe
Nome da classe
Nome da classe
Nome da classe
Lista de atributos
Lista de operações
Lista de atributos
Lista de operações
Atributos – descrição dos dados armazenados pelos objetos de uma classe.
Cada atributo de uma classe está associado a um conjunto de valores que esse
atributo pode assumir.
Operações – correspondem à descrição das ações que os objetos de uma classe
sabem realizar. O nome de uma operação, normalmente, contém um verbo e
um complemento e termina com um par de parênteses.
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS
7. Lista dos Requisitos de Persistência (continuação)
Técnica para identificação das classes existentes nos fluxos dos casos de uso.
procurar substantivos
• eliminar aspectos de implementação e conceitos irrelevantes quanto à
missão do produto;
• resolver ambigüidades da linguagem;
• considerar também locuções verbais, desde que equivalentes a
substantivos;
• considerar que substantivos podem não resultar em classes, mas em
objetos, relacionamentos ou atributos de classes;
• permanecer no nível lógico, não incluindo detalhes da implementação;
• permanecer dentro do escopo do produto, evitando classes não conexas
com a missão.
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS
7. Lista dos Requisitos de Persistência (continuação)
Especificação das classes
• Deve-se escolher nomes significativos, isto é, substantivo no singular;
• Deve-se evitar nomes vagos, assim como nomes reservados da própria
metodologia (classe, tipo, etc.);
• Deve-se utilizar nomes que façam parte do domínio do negócio.
Ao longo da análise, a especificação das classes será completada com
outros aspectos relevantes, como:
• Operações necessárias para cumprir as responsabilidades;
• Atributos necessários para cumprir as responsabilidades.
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS
7. Lista dos Requisitos de Persistência (continuação)
Nomenclatura para o diagrama de classes na UML
• Para identificadores – quaisquer espaços em branco e preposições do
nome são removidos.
• Para nomes de classes e nomes de relacionamentos – começar
com letra maiúscula. Exemplo: Cliente, ItemPedido, Pedido, etc.
• Para nomes de atributos e nomes de operações – escrever a
primeira palavra do nome em minúsculas e as palavras
subseqüentes, sem espaço em entre elas, começando com a letra
em maiúsculo. No entanto, siglas são mantidas inalteradas.
Exemplo: quantidade, precoUnitario, CPF, dataNascimento, etc.
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS
7. Lista dos Requisitos de Persistência (continuação)
Exemplos de classes
Nome da classe
Descrição da classe
Atributos da classe
Fornecedor
representa os fornecedores da nome
empresa
CNPJ
contato
telefone
PedidoCompra
representa os pedidos feitos dataPedido
pelos aos fornecedores da status
empresa
Obs: A associação existente entre Fornecedor e PedidoCompra (um fornecedor
fornece muitos pedidos e um pedido é fornecido por somente um fornecedor)
só ficará evidente após a construção do diagrama de classes. Não pode existir
nenhum atributo na classe PedidoCompra, nem na classe Fornecedor, que
tente representar essa associação.
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS
7. Lista dos Requisitos de Persistência (continuação)
Diagrama de Objetos (ou Diagrama de Instâncias)
• Podem ser vistos como instâncias de diagramas de classes, da mesma
forma que objetos são instâncias de classes;
• Assim como diagramas de classes, diagramas de objetos são estruturas
estáticas. Um diagrama de objetos exibe uma “fotografia” do sistema em
um certo momento;
• Cada objeto é representado por um retângulo com dois compartimentos.
• No compartimento superior, a identificação do objeto é exibida
• No compartimento inferior, quando utilizado, exibe uma lista de
pares da forma nome do atributo: valor do atributo;
• A identificação do onjeto deve ser sempre sublinhada.
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS
7. Lista dos Requisitos de Persistência (continuação)
Exemplo de Diagrama de Objetos:
nome = “caderno M”
descrição = “caderno em espiral tamanho médio”
Fornecedor10:Fornecedor
nome = “Distribuidora XYZ”
CNPJ = 30502231000129
contato = “Maria”
telefone = 2126657588
Mercadoria20:Mercadoria
Item1:ItemPedido
quantidade = 6
Item2:ItemPedido
Mercadoria12:Mercadoria
nome = “caneta esf”
descrição = “caneta esferográfica 5 mm”
quantidade = 20
Pedido1:Pedido
data = 13/09/2002
status = “A”
Mercadoria07:Mercadoria
Item3:ItemPedido
quantidade = 1
nome = “esquadro”
descrição = “esquadro de acrílico 20 cm
ANÁLISE E ESPECIFICAÇÃO DE REQUISITOS
Referências Bibliográficas
Rocco, Giovanni Ely. Engenharia de Requisitos. Universidade de Caxias do Sul - Centro de
Ciências Exatas e Tecnologia - Departamento de Informática.
Alenquer , Pablo Lopes . Regras de Negócio para Análise em Ambientes OLAP. Disponível
em http://genesis.nce.ufrj.br/dataware/DataWarehouse/Teses/Pablo/TesePablo.pdf
Acesso em 02/11/2005.
Bezerra, Eduardo. Princípios da Análise e Projeto de Sistemas com UML. Rio de Janeiro:
Elsevier, 2002.
Paula Filho, Wilson de Pádua. Engenharia de Software – Fundamentos, Métodos e Padrões.
Rio de Janeiro: LTC, 2003.
Souza, Isabel Fernandes de. Apostila de Engenharia de Sistemas de Informação – Parte III.
Sommerville, Ian. Engenharia de Software. São Paulo: Pearson Education, 2003.
Descargar

xxx