Engenharia de Software
Cláudio Larieira
[email protected]
Plano de Aula – 3o. período
• Requisitos
• Conceitos
• Tipos de requisitos
• Atividades de gestão e engenharia
• Técnicas de elicitação
• Fontes de requisitos
• Workshop sobre Requisitos
• Estimativas
• Conceitos
• Estimativas de Tamanho e Esforço : FPA, UCP, LOC e WBS
• Métricas de Software
• Conceitos
• Possíveis Indicadores
2
3
Requisitos
Pondo em prática ...
Você aceitaria ou não o
documento de
requisitos do Sistema
de Segurança
apresentado ?
E o projeto ?
4
Dificuldades em se obter Requisitos
•Usuários nem sempre sabem o que efetivamente desejam
do sistema
•Diferença de linguagem entre os usuários e a equipe de
projeto, ocasionando problemas de entendimento
•Requisitos iguais, expressados de maneira diferente, por
diferentes usuários
•Fatores políticos na definição de requisitos
•Constante mudança de requisitos em função de mudanças
de cenário econômico e de negócio
•Ansiedade dos usuários em ter o software implementado
rapidamente, não permitindo que se executem
adequadamente as atividades de requisitos
•Resistência ao software a ser implementado
•Complexidade dos problemas de negócio
5
Requisitos
 Segundo IEEE (The Institute of Electrical and
Electronics Engineers), Requisito é :
“ Uma condição ou capacidade
requerida por um usuário para
resolver um problema ou atingir
um objetivo”
“Uma condição ou capacidade
que deve ser atingida ou
possuída por um sistema ou partes de
um sistema para satisfazer um
contrato, padrão, especificação
ou outros documentos”
6
Características de um Requisito
•Segundo Wiegers, todo requisito
deve ser :
•Completo – descrevendo plenamente a
necessidade a ser implementada
•Correto – atendendo de maneira inequívoca a
necessidade solicitada
•Exequível – podendo ser implementado dentro
das limitações e ambiente do sistema
•Necessário – correspondendo a algo que o
usuário realmente necessita
•Priorizado – podendo ser alocado nas iterações
ou release de um software conforme o momento
adequado
•Não ambíguo – sem margem de dúvidas ou de
interpretação
•Verificável – passível de verificação e validação
7
Tipos de Requisito
•Os requisitos se dividem em :
•Requisitos de Usuário – descrevendo as funções
que o sistema deverá ter e as limitações sob as quais
deverá operar
•Requisitos de Sistema – descrevendo a maneira
como o sistema deverá responder às necessidades
dos usuários
•Requisitos de Software – descrevendo
detalhadamente a maneira como o software deverá
ser construído
8
Requisitos de Sistema
•Os requisitos de sistema se
dividem em :
•Funcionais – descrevendo os
comportamentos esperados para o sistema
•Não funcionais – descrevendo as restrições
sobre os serviços ou as funções oferecidas pelo
sistema, tais como :
• De produto : facilidade de uso, desempenho, espaço,
confiabilidade e portabilidade
• Organizacionais : entrega, implementação e padrões
• Externos : interoperabilidade, éticos e legais
9
Requisitos Não-funcionais (segundo
Sommerville)
Requisitos
Não
Funcionais
Requisitos do
Produto
Requisitos de
Confiabilidade
Requisitos de
Eficiência
Requisitos de
Facilidade de
Uso
Requisitos
Organizacionais
Requisitos de
Portabilidade
Requisitos de
Entrega
Requisitos de
Desempenho
Requisitos de
Espaço
Requisitos
Externos
Requisitos de
Interoperabilidad
e
Requisitos de
Implementação
Requisitos
Éticos
Requisitos de
Padrões
Requisitos de
Privacidade
Requisitos
Legais
Requisitos de
Segurança
10
Fontes de Requisitos
•Requisitos podem ser obtidos através
de :
•Entrevistas e discussões com potenciais
usuários
•Documentos sobre produtos próprios ou de
concorrentes
•Especificações de sistemas atuais
•Relatórios de problemas ou de solicitação de
melhoria de sistemas atuais
•Pesquisas de marketing ou questionários de
usuários
•Observação de usuário trabalhando
•Análise de cenários
11
Atividades de Requisitos
•Os requisitos são tratados em
Engenharia de Software sob duas
perspectivas :
•Engenharia de Requisitos : atividades
relacionadas ao desenvolvimento do
requisito
•Gestão de Requisitos : atividades
relacionadas ao gerenciamento dos
requisitos documentados
12
Atividades de Requisitos
Mercado, Cliente, Gerenciamento
Requisitos
Analisa,
Documenta,
Revisa, Negocia
Desenvolvimento de
Requisitos
Requisitos em Baseline
Gestão de Requisitos
Baseline
Baseline
corrente
Mercado,
Cliente,
Gerenciamento
Mudanças de
Requisitos
revisada
Processo de
Mudança de
Requisitos
Ambiente de
Projeto
Mudanças de
Projeto
13
Atividades de Requisitos
•Engenharia de Requisitos envolve :
•Elicitação – identificar os usuários e coletar
os requisitos
•Análise – compreender o domínio do
problema, resolver conflitos e priorizar
requisitos
•Especificação – documentar os requisitos de
maneira compreensível, através de
modelagem
•Verificação - garantir que eles estejam
adequados
14
Atividades de Requisitos
•Gestão de Requisitos envolve :
•Identificação – garantir que cada requisito
tenha uma identidade única dentro do
projeto
•Controle de Mudanças – avaliar o impacto e
o custo as mudanças
•Rastreabilidade - permitir que haja uma
“amarração” entre os requisitos
documentados e a implementação do
software
•Manutenção da baseline – garantir a
integridade da base de requisitos do projeto
15
Documentos de Requisitos
•Todos os requisitos a serem implementados
devem ser consolidados em um artefato onde
possam ser identificados e claramente
especificados para que componham a baseline
do projeto de software
•Os documentos de requisitos devem ser
colocados sob gestão de configuração para que
se mantenha a integridade das informações e
visibilidade de progresso e mudanças ao longo
do tempo de projeto
16
Possíveis abstrações de Documentos de
Requisitos
•Documento de Definição do Sistema - requisitos em um
nível mais alto, com a visão de negócio ou de sistema, para
que se estabeleça um entendimento e comprometimento
dos requisitos juntos aos usuários
•System Requirements Specification - requisitos em um nível
de abstração intermdíario, com a visão de implementação
do sistema
•Software Requirements Specification - requisitos em um
nível de abstração mais baixo, com a visão de
implementação do software, para que se apresente à equipe
de projeto os requisitos e a solução a ser implementada
17
Outras possíveis abstrações
de Documentos de Requisitos
Requisitos
de Negócio
Documento de Visão e Escopo
Atributos de
Qualidade
Requisitos
de Usuário
Outros
Requisitos
Não
Funcionais
Documento de Caso de Uso
Requisitos do
Sistema
Requisitos
Funcionais
Limitações
Especificação de Requisitos de Software
18
Requisitos
•Algumas possibilidades de se fazer
engenharia de requisitos em projetos de
software combinadas com WBS :
•Usando técnica de Casos de Uso
•Usando técnicas de Análise Essencial :
•Diagrama de Contexto, DFD, DER, tabelas de
decisão, árvores de decisão e pseudo-código
•Usando técnicas de JAD
•Usando técnicas de entrevista e
questionário
•Usando técnicas de Prototipação
19
Pondo em prática ...
E agora que você conhece um
pouco mais sobre Requisitos,
você aceitaria ou não o
documento de requisitos do
Sistema de Segurança
apresentado ?
Liste argumentos para a sua
decisão.
20
Estimativas
21
Estimativas de tamanho de software
•Métricas mais conhecidas :
•LOC (line of code) :
•Através de contagem de linhas de programação obtémse o esforço necessário
•WBS (Work Breakdown Structure) :
•Através de “deliverables”, encontra-se o tamanho do
software
•FPA (Function Point Adjusted) :
•Através de contagem dos elementos de transação e de
dados, obtém-se o tamanho funcional do software
•UCP (Use Case Point) :
•Semelhante ao FPA, porém voltado a Casos de Uso
•COCOMO (Constructive Cost Model) :
•Modelo onde se obtém custo, esforço e prazo
22
FPA – Function Point Adjusted
•A métrica de ponto de função, primeiramente
proposta por Albrecht (IBM, em 1979), pode
ser usada efetivamente como um meio de
mensurar as funcionalidades entregues por um
sistema.
•Pontos de Função são derivados usando um
relacionamento empírico baseado em medidas
quantificáveis do domínio de informação do
software e suas respectivas complexidades
•Estes valores sobre o domínio da informação
são definidos da seguinte maneira :
• Número
• Número
• Número
• Número
• Número
de
de
de
de
de
external inputs (EIs)
external outputs (EOs)
external inquiries (EQs)
internal logical files (ILFs)
external interface files (EIFs)
23
Function Points
Inform ation
Domain Value
Weighting factor
sim ple average com plex
Count
=
External Inputs ( EIs)
3
3
4
6
External Outputs ( EOs)
3
4
5
7
External Inquiries ( EQs)
3
3
4
6
=
Internal Logical Files ( ILFs)
3
7
10
15
=
External Interf ace Files ( EIFs)
3
5
7
10
=
=
Count total
24
Métricas de Software
• Alguns sites de apoio :
• FPA :
• International Function Point Users Group
(http://www.ifpug.org)
• Brazilian Function Point Users Grupo (http://www.bfpug.org)
• ISBSG (http://www.isbsg.org)
• COCOMO :
• Site com a técnica
(http://sunset.usc.edu/research/COCOMOII/index.html)
25
Métricas de Software
26
Pondo em prática ...
Pergunta :
Como avaliar que a Fábrica de Software
do estudo de caso está desempenhando
bem?
Escolha ao menos 5 maneiras de medir.
27
Aprendendo com dados quantitativos e
qualitativos
•Organizações podem aprender e melhorrar
através de :
•Coleta e análise de dados quantitativos
sobre processos de desenvolvimento e
produtos
•Coleta e análise de dados qualitativos, por
exemplo, o que os desenvolvedores pensam
sobre os processos de desenvolvimento e
produtos
28
Triângulo da Qualidade de McCall’s
M a in ta in a b ility
P o rta b ility
F le xib ility
R e u sa bility
T e sta bility
In te ro p e ra b ility
PRODUCT REVISION
PRODUCT TRANSITION
PRODUCT OPERATION
C o rre ctn e ss
U sa b ility
R e lia b ility
E fficie n cy
In te g rity
29
Medidas, Métricas e Indicadores
•Uma medida provê uma indicação quantitativa
da extensão, quantidade, dimensão, capacidade
ou tamanho de algum atributo de um produto
ou processo
•O glossário IEEE define uma métrica como “uma
medida quantitativa do grau a qual um sistema,
um componente ou um processo possui de um
dado atributo.”
•Um indicador é uma métrica ou a combinação
de métricas que provêem uma visão sobre um
processo de software, um projeto ou o produto
propriamente dito
30
Descomplicando ...
•O quê é uma métrica ?
•É um processo que permite aos
desenvolvedores/gestores obter visão sobre
medidas quantitativas de um software e do
processo de software melhorando a eficácia de
planejamento e controle
•Por quê isto é importante ?
•Elimina a subjetividade das análises a serem
realizadas
•Antecipa tendências na implementação do
software
•Permite realizar comparações
31
Métricas de Software
•O quê é possível medir em um software ?
•Tamanho
•Esforço
•Custo
•Prazo
•Risco
•Recurso computacional crítico
•Retrabalho
•Erros em testes
•Falhas em produção
•Produtividade da equipe
•Etc.
32
Métricas de Software
•Quais os possíveis indicadores ?
•Tamanho – pontos de função, pontos por caso de uso,
linhas de código, etc.
•Esforço – horas de esforço por tipo de complexidade de
programa
•Custo – custo médio por programa
•Prazo – desvio médio de projeto
•Retrabalho – quantidade de retornos de teste
•Erros em testes – quantidade de defeitos em funcionalidade
•Falhas em produção – quantidade de páginas web não
encontradas
•Produtividade da equipe - número de linhas codificadas por
mês
•Etc.
33
Processo de Mensuração
•Formulação – A derivação das medidas de software
e das métricas apropriadas para a representação do
que se espera conhecer sobre o software, projeto
ou processo.
•Coleta – O mecanismo usado para acumular os
dados requeridos para derivar as métricas
formuladas.
•Análise – A consolidação das informações obtidas e
a aplicação de ferramentas matemáticas.
•Interpretação – A avaliação dos resultados da
métrica resulta em um esforço para obter uma
visão sobre a qualidade representada do software,
projeto ou processo.
•Feedback – Recomendações derivadas da
interpretação das métricas transmitidas ao time de
desenvolvimento.
34
Pondo em prática ...
Pergunta :
Quais indicadores você estabeleceria
para gerenciar sua Fábrica de
Software ?
Escolha ao menos 5.
35
Encerrando nossa aula
Nesta aula, tratamos sobre :
• Requisitos
• Conhecendo melhor o conceito sobre requisitos, os tipos
possíveis e as atividades propostas pela Engenharia de
Software para tratá-los
• Discutindo sobre técnicas de elicitação alternativas à
técnica de WBS proposta pelo PMBOK
• Aprendendo como avaliar de maneira mais objetiva a
qualidade dos requisitos recebidos
36