V Simpósio Internacional de
Melhoria de Processo de Software
Recife, PE - Brasil 3-5/11/2003
www.simpros.com.br
Avaliação e Melhoria do Processo de
Gestão de Requisitos para Projetos de
Software de Controle de Tráfego: Um
Estudo de Caso
Denise Lazzeri Gastaldo
Edson Toshimi Midorikawa
"!$#"!"!%&'
()
Introdução:
• Os problemas de requisitos são muito
freqüentes;
• Atribui-se às falhas de especificação uma
das maiores causas de retrabalho;
• Existem falhas nos processos para gerenciar
e registrar os requisitos desde o início do
projeto;
• Neste contexto a engenharia de requisitos é
uma solução muito interessante.
*+-,/.1032546.0798;:,=<7>,/2@?2BA<7DCEFG+H7 ?2?EI?6EIJK.L4M2N0>.
V Simpósio Internacional de
Melhoria de Processo de Software
Recife, PE - Brasil 3-5/11/2003
www.simpros.com.br
Requisitos:
• Devem definir:
–
–
–
–
Como o sistema deve se comportar;
Funcionalidades;
Restrições de operação;
Atributos de qualidade.
• São classificados como:
– Funcionais, ou seja, “o que o sistema deve
fazer”;
– Não-Funcionais: atributos de qualidade, ou seja,
“como a sistema deve fazer”.
OP-Q/R1S3T5U6RSV9W;XQ=YV>Q/T@ZTB[YVD\]^GPHV ZTZ]IZ6]I_`RLUMTaS>R
Requisitos:
• Requisitos Não-Funcionais, precisam:
– Ser medidos quantitativamente b requisitos que
não podem ser medidos dificilmente serão
atendidos;
– Ser acompanhados desde o início do projeto b
requisitos não-funcionais não elicitados podem
colocar toda a solução do projeto a perder;
– Ser incluídos no processo de
desenvolvimento b abordagens orientadas a
processo facilitam as mudanças e a tomada de
decisões.
cd-e/f1g3h5i6fgj9k;le=mj>e/h@nhBomjDpqrGdHj nhnqIn6qIstfLiMhug>f
V Simpósio Internacional de
Melhoria de Processo de Software
Recife, PE - Brasil 3-5/11/2003
www.simpros.com.br
Engenharia de Requisitos:
• É um processo variável, por alguns motivos:
–
–
–
–
Maturidade técnica;
Envolvimento e comprometimento;
Cultura organizacional;
Domínio da aplicação.
Por isso, não existem processos de engenharia de
requisitos perfeitos...
vw-x/y1z3{5|6yz}9~;x=€}>x/{@{B‚€}Dƒ„…GwH} {„I6„I†‡yL|M{ˆz>y
Engenharia de Requisitos:
• Atividades do Processo:
– Elicitação: os requisitos são discutidos com
stakeholders;
– Análise e Negociação: os requisitos são
analisados em detalhes e diferentes
stakeholders negociam para decidir quais
requisitos serão aceitos;
– Documentação: os requisitos acordados são
documentados nos níveis apropriados de
detalhes;
– Validação: os requisitos são checados a fim de
obter consistência e completeza .
vw-x/y1z3{5|6yz}9~;x=€}>x/{@{B‚€}Dƒ„…GwH} {„I6„I†‡yL|M{ˆz>y
V Simpósio Internacional de
Melhoria de Processo de Software
Recife, PE - Brasil 3-5/11/2003
www.simpros.com.br
Estudo de Caso:
• Subsistema de software para controle de
equipamentos:
– Controla entrada e saída de dados;
– Gerencia e processa os dados;
– Gera relatórios de demanda de utilização de
acordo com os picos de utilização;
– Possui controle local e central.
• Foi feita uma análise do subsistema com
base nos itens descritos a seguir.
‰Š-‹/Œ13Ž56Œ9‘;’‹=“>‹/Ž@”ŽB•“D–—˜GŠH ”Ž”—I”6—I™šŒLMŽ›>Œ
Avaliação do Processo:
• Documentação de Especificação:
–
–
–
–
Falta de método de levantamento de requisitos;
Requisitos documentados não estão claros;
Falta de detalhamento;
Confusão entre requisitos funcionais e nãofuncionais;
– Falta de padronização;
– Apresentação deficiente.
‰Š-‹/Œ13Ž56Œ9‘;’‹=“>‹/Ž@”ŽB•“D–—˜GŠH ”Ž”—I”6—I™šŒLMŽ›>Œ
V Simpósio Internacional de
Melhoria de Processo de Software
Recife, PE - Brasil 3-5/11/2003
www.simpros.com.br
Avaliação do Processo:
• Controle de Alteração de Documentos:
– Atualizações tardias;
– Dificuldade em manter os documentos.
• Requisitos Funcionais:
– Informação dispersa;
– Falta de participação de todos os stakeholders
na definição dos requisitos;
– Falta de clareza e formato.
œ-ž/Ÿ1 3¡5¢6Ÿ £9¤;¥ž=¦£>ž/¡@§¡B¨¦£D©ª«GH£ §¡§ªI§6ªI¬­ŸL¢M¡® >Ÿ
Avaliação do Processo:
• Requisitos Não-Funcionais:
– Informação dispersa;
– Deficiência conceitual sobre requisitos nãofuncionais;
– Deficiência na elicitação e análise;
– Exigências contraditórias;
– Falta de participação de todos os stakeholders
na definição dos requisitos;
– Falta de clareza e formato.
œ-ž/Ÿ1 3¡5¢6Ÿ £9¤;¥ž=¦£>ž/¡@§¡B¨¦£D©ª«GH£ §¡§ªI§6ªI¬­ŸL¢M¡® >Ÿ
V Simpósio Internacional de
Melhoria de Processo de Software
Recife, PE - Brasil 3-5/11/2003
www.simpros.com.br
Avaliação do Processo:
• Documento de Arquitetura de Software:
– Inexistência de definição de interfaces externas;
– Inexistência de definição de restrições de
projeto;
– Inexistência de associação entre requisitos nãofuncionais e funcionais e arquitetura;
– Falta de cobertura do conjunto de requisitos
especificados;
– Falta de rastreabilidade entre especificação e
arquitetura.
¯°-±/²1³3´5µ6²³¶9·;¸±=¹¶>±/´@º´B»¹¶D¼½¾G°H¶ º´º½Iº6½I¿À²LµM´Á³>²
Avaliação do Processo:
• Integração e Validação de Software:
– Impossibilidade de integração de subsistemas;
– Necessidade de proposta de novas soluções ao
cliente;
– Falta de análise de dimensionamento de
hardware;
– Falta de análise de dimensionamento de
software;
– Problemas de comunicação entre módulos;
– Problemas no atendimento aos requisitos nãofuncionais.
¯°-±/²1³3´5µ6²³¶9·;¸±=¹¶>±/´@º´B»¹¶D¼½¾G°H¶ º´º½Iº6½I¿À²LµM´Á³>²
V Simpósio Internacional de
Melhoria de Processo de Software
Recife, PE - Brasil 3-5/11/2003
www.simpros.com.br
Avaliação do Processo:
• Aspecto Humano:
– Falta de sincronização entre equipe de sistemas
e equipe de software.
• Metodologia de Desenvolvimento:
– Dificuldade em seguir metodologia definida na
organização.
ÂÃ-Ä/Å1Æ3Ç5È6ÅÆÉ9Ê;ËÄ=ÌÉ>Ä/Ç@ÍÇBÎÌÉDÏÐÑGÃHÉ ÍÇÍÐIÍ6ÐIÒÓÅLÈMÇÔÆ>Å
Avaliação do Processo:
• Aplicação de um checklist de avaliação do
processo de gestão de requisitos, para
medir:
– O custo das atividades;
– A qualidade dos produtos gerados;
– Os serviços prestados.
ÂÃ-Ä/Å1Æ3Ç5È6ÅÆÉ9Ê;ËÄ=ÌÉ>Ä/Ç@ÍÇBÎÌÉDÏÐÑGÃHÉ ÍÇÍÐIÍ6ÐIÒÓÅLÈMÇÔÆ>Å
V Simpósio Internacional de
Melhoria de Processo de Software
Recife, PE - Brasil 3-5/11/2003
www.simpros.com.br
Resultados:
Categoria
CERE
QREP
QRES
Resultado por Categoria
Ótimo
Regular
Insatisfatório
0
0
5
0
0
14
6
3
4
Nota
1
Critério
Ótimo
2
3
Regular
Insatisfatório
Resultado Geral
Qtd
%
Ação
6
18% Pontos isolados de
melhoria
5
15% Melhoria do processo
23
67% Implantação de processo
CERE – Cost Effective of Requirements Engineering
QREP – Quality of Requirements Engineering Products
QRES – Quality of Requirements Engieenring Services
ÕÖ-×/Ø1Ù3Ú5Û6ØÙÜ9Ý;Þ×=ßÜ>×/Ú@àÚBáßÜDâãäGÖHÜ àÚàãIà6ãIåæØLÛMÚçÙ>Ø
Resultados:
• Necessidade de implantação de um processo
de engenharia de requisitos;
• Os custos são muito elevados quando não
são aplicadas metodologias e técnicas
adequadas;
• Apesar da qualidade dos produtos
apresentarem valores positivos, falta
documentação de requisitos eficiente;
• O projeto fica dependente das pessoas e do
“heroísmo”.
ÕÖ-×/Ø1Ù3Ú5Û6ØÙÜ9Ý;Þ×=ßÜ>×/Ú@àÚBáßÜDâãäGÖHÜ àÚàãIà6ãIåæØLÛMÚçÙ>Ø
V Simpósio Internacional de
Melhoria de Processo de Software
Recife, PE - Brasil 3-5/11/2003
www.simpros.com.br
Soluções (1): Especificações
• Vantagens da utilização da PLanguage:
– Medida e teste dos requisitos funcionais e nãofuncionais (plano de testes);
– Facilidade no aprendizado;
– Flexibilidade;
– Objetividade;
– Previne omissões;
– Estabelece um padrão de especificação;
– Estabelece um canal de comunicação comum;
– Controla alterações de requisitos;
– Auxilia no desenvolvimento da arquitetura de
software.
èé-ê/ë1ì3í5î6ëìï9ð;ñê=òï>ê/í@óíBôòïDõö÷GéHï óíóöIó6öIøùëLîMíúì>ë
• PLanguage: Palavras chave
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
Tipo: Etiqueta, rótulo, identificador persistente e único do requisito.
Descrição:Descrição simples do conceito ou significado geral do requisito.
Stakeholders: Envolvidos/Afetados pelo requisito
Escala: Escala usada para quantificar o requisito.
Métrica: Definição de medidas da escala.
Método: Método para medir a escala.
Freqüência: Freqüência para medição.
Responsável: Pessoas/Departamento responsável por fazer as medições.
Registro: Onde/Quando as medidas devem ser reportadas.
Nível Mínimo: O nível mínimo requerido para evitar falhas.
Plano: Nível para obter sucesso exigido.
Nível de Sucesso: Como prolongar o sucesso.
Nível Desejado: Nível desejável de sucesso a ser atingido no futuro.
Histórico: Resultados anteriores para comparação.
Tendência: Tendência histórica.
Histórico de Sucesso: O melhor resultado obtido.
Definição: Definição de termos relevantes.
Autoridade: Pessoa, grupo ou nível de autorização.
èé-ê/ë1ì3í5î6ëìï9ð;ñê=òï>ê/í@óíBôòïDõö÷GéHï óíóöIó6öIøùëLîMíúì>ë
V Simpósio Internacional de
Melhoria de Processo de Software
Recife, PE - Brasil 3-5/11/2003
www.simpros.com.br
Requisito: A transferência de arquivos de programas executáveis do centro de controle para as unidades
remotas e desta para os equipamentos será feita de modo a não causar impactos ao processamento dos
dados do processo (tempo real).
– Tipo: Tempo (tempo de resposta)
– Descrição:Transferência de arquivos executáveis do centro de controle para as unidades
remotas e desta para os equipamentos.
– Stakeholders: Não definido.
– Escala: Não definido.
– Métrica: Não definido.
– Método: Não definido.
– Freqüência: Não definido.
– Responsável: Não definido.
– Registro: Não definido.
– Nível Mínimo: Não causar impacto ao processamento de dados do processo em tempo
real.
– Plano: Não definido.
– Nível de Sucesso: Não definido.
– Nível Desejado: Não definido.
– Histórico: Não definido.
– Tendência: Não definido.
– Histórico de Sucesso: Não definido.
– Definição: Não definido.
– Autoridade: Não definido.
Requisito: A transferência de arquivos de programas executáveis do centro de controle para as unidades
remotas e desta para os equipamentos será feita de modo a não causar impactos ao processamento dos
dados do processo (tempo real).
– Tipo: Tempo (tempo de resposta)
– Descrição:Transferência de arquivos executáveis do centro de controle para as unidades
remotas e desta para os equipamentos.
– Stakeholders: Cliente, Responsável Técnico, Coordenador de Software, Desenvolvedor,
Garantia da Qualidade.
– Escala: Ms.
– Métrica: Medidas de tempo de envio e recebimento de arquivos executáveis.
– Método: Inclusão de marcadores de tempo no código.
– Freqüência: Para qualquer envio de arquivo.
– Responsável: Desenvolvedor
– Registro: Banco de Dados de arquivos de log com o seguinte padrão de nome:
BD_001_089 (BD_código da métrica_código do requisito).
– Nível Mínimo: Cada transferência não pode demorar mais que 100 ms (Dada uma rede
Ethernet com tráfego de 10 Mbps).
– Plano: Monitoração através do software de controle, sendo que a qualquer índice de
tempo maior que o esperado deve ser emitido um alarme e o arquivo de log deve ser
analisado.
– Nível de Sucesso: Processo constante de monitoramento
– Nível Desejado: Melhorar a capacidade da rede para que os arquivos possam trafegar em
até 50 ms.
– Histórico: Medidas anteriores chegaram a uma transferência em até 200 ms.
V Simpósio Internacional de
Melhoria de Processo de Software
Recife, PE - Brasil 3-5/11/2003
www.simpros.com.br
Soluções (1): Especificações
–
–
–
–
Tendência: Melhoria de desempenho de acordo com as ações planejadas.
Histórico de Sucesso: Transferências em 180 ms.
Definição: Tempo Real deve ser o tempo máximo permitido para a execução da tarefa.
Autoridade: Responsável Técnico e Garantia da Qualidade.
ûü-ý/þ1ÿ6þÿý
>ý
Güþ
ÿ>þ
!"
Soluções (2): Níveis de Maturidade
• Níveis de Maturidade baseados no CMM:
Nível 3: Definido
Boas Práticas e
Programa de
Melhoria
Processo,
Melhoria,
Participação
Padrões,
Controle,
Prazos
Retrabalho,
Insatisfação,
Heroísmo
Nível 2: Repetível
Padrões e poucos
problemas
Nível 1: Inicial
Processo Ad hoc e
problemas
freqüentes
ûü-ý/þ1ÿ6þÿý
>ý
Güþ
ÿ>þ
!"
V Simpósio Internacional de
Melhoria de Processo de Software
Recife, PE - Brasil 3-5/11/2003
www.simpros.com.br
Conclusão:
• Detecção dos principais problemas (comuns
a todas as organizações);
• Utilização de uma linguagem de
especificação que agrega qualidade ao
produto que será desenvolvido;
• Utilização de um chekclist para verificar
qual ação de melhoria deve ser tomada nos
processos de gerenciamento de requisitos;
• Aplicação de um processo de engenharia de
requisitos baseado no modelo CMM.
#$&%')(*+'(,-.%/,0%*1*2/,3456$,1*141478'
+!*9(0'
Dúvidas
Comentários
S uges tões
Contato:
denise.gastaldo @ poli.usp.br
#$&%')(*+'(,-.%/,0%*1*2/,3456$,1*141478'
+!*9(0'