Upload
internet
View
109
Download
0
Embed Size (px)
Citation preview
Gerência de Requisitos de Software
Problemas comuns em desenvolvimento de Software
Melhorando o trabalho com requisitos:
Alguns Números
Fatores de Sucesso de um Projeto % de Respostas
1. Envolvimento do Usuário 15.9%
2. Suporte do Gerente Executivo 13.9%
3. Requerimentos Bem Elicitados 13.0%
4. Planejamento Apropriado 9.6%
5. Expectativas Realistas 8.2%
6. Pequenos Marcos de Projeto 7.7%
7. Equipe Competente 7.2%
8. Domínio 5.3%
9. Visão Clara e Objetivos Definidos 2.9%
10. Trabalho Duro e Pessoal Focado 2.4%
11. Outros 13.9%
THE STANDISH GROUP REPORT 1995
Fatores que Mais Prejudicam um Projeto % de Respostas
1. Requerimentos Incompletos 13.1%
2. Quebra do envolvimento do Usuário 12.4%
3. Corte de recursos 10.6%
4. Expectativas irrealistas 9.9%
5. Falta de apoio do Gerente Executivo 9.3%
6. Mudança de Requerimentos e Especificações 8.7%
7. Falta de Planejamento 8.1%
8. Dimensionamento Maior que o Necessário 7.5%
9. Falta de gerenciamento de TI 6.2%
10. Falta de Conhecimento Tecnológico 4.3%
11. Outras 9.9%
Antes de Qualquer Coisa....
“Nem sempre as Pessoas compram o que precisam, mas sempre desejam o que compram, mesmo que esse desejo seja transitório.”
Donald Gause e Gerald Weinberg
“Não faz sentido ser exato em relação a algo se você nem mesmo sabe o contexto do que está falando.”
John Von Neumann
“Ninguém possui uma verdade absoluta. A verdade é tão vasta que todas as verdades acabam sendo relativas.”
Osho
Elicitação de Requisitos
Elicitação de Requisitos
Elicitar: descobrir, tornar explicito, obter o máximo de informações para o conhecimento do objeto em questão.
Objetivos do Negócio
Descrição do
Problema
Restrições do Negócio
Estrutura da
Organização
Contexto da
Aplicação
Sistemas Existentes
Identificação dos
Stakeholder
Priorização dos Objetivos
Contexto do Conheciment
o
Requisitos dos
Stakeholder
Requisitos do Produto
Requisitos da Organização
Estabelecimento dos Objetivos
Entendimento do Contexto
Conhecimento da Organização
Coleta dos Requisitos
Elicitação de Requisitos
• Entrevista• JAD - Joint Application Design • Leitura de Documentos• Questionários• Cenários• Etnografia (Observação)• Prototipagem
Focinho, Olhos, Ouvidos. Nesta ordem… (Cesar Millan)
Comunicação Não Verbal
• 7% verbal• 38% vocal (Incluindo o tom de voz,
inflexões e outros sons);• 55% não-verbal (gestos e movimentos)
Pesquisas mostram que o impacto total de uma mensagem é:
Desenvolvimento de um Sistema
Como foi Pedido Como foi Levantado
Como foi Projetado
Desenvolvimento de um Sistema
Como foi Aprovado Como foi Implementado
Desenvolvimento de um Sistema
Como foi Documentado
Como está em produção
Como está sendo vendido
Domínios das Informações dos Projetos
Universo de Informações
Domínio doProblema
Domínio daSolução
NecessidadeRequisito
s de Negócio
Requisito de Produto
Definições
Requisito
Requisitos de Negócio Requisito de Produto
Necessidade
Req
uis
ito
Fu
nci
on
al
Req
uis
ito
Não
Fu
nc i
on
al
Req
uis
ito
sIn
v er s
os
Req
uis
ito
Fu
nci
on
al
Req
uis
ito
Não
Fu
nc i
on
al
Req
uis
ito
sIn
v er s
os
Papeis Dentro do Processo
Responsável Técnico
Lider de Projeto
GerenteDe Configuração
Responsável pelo projeto. Faz a abertura do projeto e seu acompanhamento junto ao cliente. É ele que conduz as reuniões de aceitação do produto pelo cliente.
Responsável pelo desenvolvimento do software e pela interface entre o Líder de Projeto e a equipe do DS. Faz o acompanhamento das tarefas ligadas ao desenvolvimento do Software.
Responsável pelo versionamento dos artefatos gerados durante o desenvolvimento do software e pela guarda dos fontes ao final do projeto.
Papéis
Analista deRequisito
Analista deNegócio
Responsável pela elicitação dos requisitos de negócio. Ë ele que cria o documento de visão, documento de regras de negócio e caso necessário desenvolve casos de uso a partir de cenários de negócio.
Responsável por elicitar os requisitos de produto, ligados a arquitetura da solução proposta. Os registros destes requisitos é feito através de casos de uso desenvolvidos a partir de cenários que levam em conta o software que será desenvolvido.
Administrador de Requisite Pro
Responsável pela criação de projetos e concessão de permissões dentro do ReqPro. Também faz o Transport das bases temporárias Access para o Oracle e mantém os templates dos documentos atualizados.
Papéis
Equipe de Desenvolvimento
Equipe de Qualidade
Responsável por inspecionar os artefatos gerados em cada uma das fases do ciclo de desenvolvimento do software e realizar os testes no software construído. Considerei que o analista de teste faz parte desta equipe, ele é responsável por desenvolver os casos de teste.
Responsável por desenvolver os produtos relativos as fases de Análise, Projeto e Construção do software. Pode ser uma equipe interna ou uma fabrica de software externa.
Infra-estrutura
Responsável por criar os ambientes de desenvolvimento, teste, homologação e produção e colocar o software em produção. Em alguns casos realiza testes de liberação.
Nec
essi
dade
Doc
umen
to d
e S
oluç
ão
Req
uisi
to d
e P
rodu
to
Aná
lise
Pro
jeto
Impl
emen
taçã
o
I nsp
eção
eT
e ste
s
Hom
olog
ação
Itens de Homologação
Casos de Teste
GC GC GC GC GC
Sempre que houver renegociação por mudança de escopo será necessário versionar os requisitos.
GC
Req
uisi
tos
de
Neg
ócio
Desenvolvimento de um novo projeto:
Necessidade
Documentode Visão
DemandaDocumentode Solução
NTI NTI
RequisitePro(Access)
NTI
Aprovaçãodo Cliente
Aprovaçãodo Cliente
ResponsávelPela Solução
Analista deNegócio
Líder de Projeto
Casos de UsoP/ Homologação
RequisitePro(Access)
Uso do SODA para formatação
do Relatório
Documentode Visão
VOB/ViewDocumentode Solução(Aprovada)
NTI RequisitePro(Access)
Clear Case
Documentode Visão
RequisitePro(Oracle)
Documentode VisãoVersionado
Clear Case
RequisitePro(Oracle)
ResponsávelPela Solução
Administradorde ReqPro
Gerência deConfiguração
Casos de UsoProduto
RequisitePro(Oracle)
Documentode VisãoVersionado
Clear Case
RequisitePro(Oracle)
Casos de UsoProdutoInspecionados
RequisitePro(Oracle)
Casos de UsoProdutoVersionados
Clear Case
RequisitePro(Oracle)
Aprovaçãodo Cliente
Analista deRequisitos
Equipe deQualidade
Gerência deConfiguração
Casos deTeste
CQTM
Artefatos deAnálise
RSA
Casos de UsoProduto Versionados
Clear Case
RequisitePro(Oracle)
Artefatos deAnáliseInspecionados
RSA
Artefatos de AnáliseVersionados
Clear Case
RSA
Equipe deDesenvolvimento
Equipe deQualidade
Gerência deConfiguração
Artefatos deProjeto
RSA
Artefatos deAnáliseVersionados
Clear Case
RSA
Artefatos deProjetoInspecionados
RSA
Artefatos deProjetoVersionados
Clear Case
RSA
Aprovaçãodo Cliente
Equipe deDesenvolvimento
Equipe deQualidade
Gerência deConfiguração
SoftwareCodificado
Eclipse
Artefatos deProjetoVersionados
Clear Case
RSA
Software Testado
Eclipse
SoftwareVersionado
Clear Case
Eclipse
Criação doAmbiente de
Desenvolvimento
Criação doAmbiente de
Teste
Equipe deDesenvolvimento
Equipe deQualidade
Gerência deConfiguração
Casos deTeste
SoftwareCodificadoHomologado
SoftwareVersionado
Clear Case
Eclipse
Software emProdução
Relatório deFechamento
NTI
Criação doAmbiente deHomologação
Criação doAmbiente de
Produção
ResponsávelPela Solução
Infra-estrutura Líder de Projeto
Casos de UsoP/ Homologação
Tratando uma mudança de requisito:
Alteraçãode Requisitode Negócio
Documentode VisãoAlterado
Checkout do Documento de
Visão
Casos de Usode ProdutoAlterados
Casos de UsoP/ Homologação
RequisitePro(Oracle)
Clear CaseRequisite Pro(Oracle)
Aprovaçãodo Cliente
Casos de UsoProdutoInspecionados
RequisitePro(Oracle)
Casos deTesteAlterados
CQTM
ResponsávelPela Solução
Analista deNegócio
Equipe deQualidade
TratarMudança
Casos de UsoProdutoInspecionados
RequisitePro(Oracle)
Casos deTesteAlterados
CQTM
Aprovaçãodo Cliente
NTI
Documentos de RequisitoVersionados
Clear CaseRequisit Pro
ResponsávelPela Solução
Administradorde ReqPro
Gerência deConfiguração Líder de Projeto
Rastreabilidade
Requisitode Negócio
Requisitode Produto
Análise, Projeto e
Construção
TestesExecutados
Necessidade
Pro
cess
ode
Neg
ócio Visão da
Demanda
Gerencia daMudança
Estrutura Física
ReqProClear Case
ReqProClear Case
ReqProClear Case
ReqProClear Case
ReqProClear Case
ReqProClear Case
ReqProClear Case
TI-BAN
TI-SPS
ADS
TI-BC
TIDT-SEALRequisitos
TI-ES
TI-NE
Fabrica de Software
Fabrica deSoftware
Escritório Da Fabrica
Escritório daPetrobras
Escritório Da Fabrica
Escritório daPetrobras
. . .
Fabrica de Software
Ambiente de Desenvolvimento
Ambiente de Teste
Servidor de Aplicação
Site Seguro Clear CaseCQTMRequisit ProRSA/RSM
Situação Atual
• Requisite Pro Disponível– Templates– Instrução de Instalação
• Procedimentos Definidos– Padrões no SINPEP– Descrição de Casos de Uso
• Capacitação– Treinamento Realizado (Administradores e Usuários)– Mentoring
O que falta fazer?
• (Re) Apresentar o processo para todos os participantes;
• Criar projetos pilotos com todas as Agilidades;
• Definir a atuação dos mentores em cada local;
• Definir uma solução de arquitetura que permita a consulta de todas as bases de requisitos;
Gerência de Requisito de Software
TI-SPS/DS -- Patricia Nishimura Guerra – CWBJ TI-SPS/DS -- Edmilson Galinari Miranda -- TSN0TI-BAN/DS -- Carlos Henrique Magalhães Oest -- CN7UTI-BAN/DS -- Tersia Pacheco de Almeida -- CWD9TI-BC/DS -- Afonso Carlos Tavares Pinheiro -- RMUUTI-RIO/DS -- Bruno Peixoto Alvarenga -- CYB2SERV-TI/SSE -- Cassiano Ebert -- CWG1TI-NE/DS -- Paulo Ivan Benigno Pereira -- PIB1SERV-TI/SES -- Silezia Gomes dos Anjos -- CWI1
Grupo de Trabalho de Gerência de Requisitos:
Patrocinadora: Janice – TI-SPS/DS
Referências
• http://gts.petrobras.com.br/main.asp• SINPEP
– PR-1T1-00132 - Gerenciamento de Requisitos– TI - NF-1T1-00059 – Glossário– TI - NF-1T1-00105 – Regras de Negócio– TI - NF-1T1-00060 – Documento de Visão– TI - NF-1T1-00058 – Especificação Suplementar– TI -NF-1T1-00057 – Especificação de Casos de Uso– Casos de Uso de Novo desenvolvimento e
manutenção
Considerações Especiais
Sete Pecados Capitais• Confiança Cega (no parceiro)
• Cinismo e Desconfiança (com o parceiro)
• O Contrato é “a Bíblia” (falta de flexibilidade)
• Falta de Comunicação (com o seu pessoal)
• “Ir Dormir Aborrecido” (fazer bola de neve)
• Má Prática de Métricas (ambas as partes devem entender os critérios)
• Cobiça e Oportunidade (explorar falhas do contrato)
Dekkers, C., Management of Outsourcing: How to Avoid Common Mistakes, Software Management Conference, San Jose, February 2000
Qualidade
““Você pode obrigarVocê pode obrigarum louco a aceitarum louco a aceitarum prazo,um prazo,mas não pode mas não pode obriga-lo a cumpri-lo”obriga-lo a cumpri-lo”
VantagemGlobal doSistema
Vantagem Global de Um Sistema
Din
heiro
Data de Entrega
Custo do Desenvolvimento
Valor do Sistema
Fonte: Meillir Page-Jones
Inicio doProjeto
Primeiraprevisãode entrega
O projeto passaa custar mais doque vale
l
Evitando a Região Impossível
To : é a capacidade para a qual o custo unitário médio esteja no mínimo;. Td : é o melhor prazo para um custo aceitável em função do beneficio
esperado.
Cu
sto
do
Esf
orç
o
Tem po de D esenvolvim ento
Td To
Região Im possível(75% de Td)
Boa Sorte!!!
Necessidade
Manter a ANP informada da produção de gás e óleo da Petrobras.
Requisito de Negócio – Requisito Funcional
O sistema deve fornecer informação da vazão de óleo e gás até o quinto dia útil de cada mês.
Requisito de Negócio – Requisito Não Funcional
O sistema deve proteger as informações enviadas para a ANP de acessos não autorizados.
Requisito de Produto – Requisito Não Funcional
O sistema deve armazenar os arquivos de vazão de óleo e gás em uma pasta dentro do Firewall da Petrobras.
O sistema deve usar um algoritmo de chave publica para encriptografar os arquivos de vazão de óleo e gás.
Requisito de Produto – Requisito Funcional
Gerar um arquivo compactado com a vazão de óleo e gás conforme o formato e descrição de campos determinados pela ANP.
Definição de RequisitoRequisitos expressam as características e restrições do produto se software do ponto de vista da satisfação das necessidades do usuário.
Manter o registro de todos os livros e periódicos da biblioteca;
Permitir ao usuário pesquisar os livros e periódicos por: título, autor, editora e palavra-chave;
Ter o tempo máximo de espera para apresentação de uma página menor ou igual a 4 segundos;
Suportar no mínimo 50 usuários concomitantes sem comprometer a performance do sistema;
Exem
plo
s
Funcional Não Funcional Inverso
Requisitos de Negócio
Descrevem as atividades que os usuários deverão ser capazes de executar com a utilização do sistema, delimitando o domínio do problema.
Requisitos do Produto
Descrevem características associadas a implementação da solução. Estão associados ao domínio da solução.
Requisito Funcional
• Descrevem a funcionalidade e os serviços do sistema;
• Dependem do tipo de software dos prováveis usuários e do tipo de sistema onde o software é usado;
• Podem ser do usuário (descrição de alto nível), ou do produto (comportamento do software).
Requisitos Não Funcionais
• Definem as propriedades e restrições do sistema.
• São características desejadas pelos clientes;
• Como se fossem adjetivos ou advérbios;• Dois produtos podem ter exatamente as
mesmas funções, mas seus atributos podem torná-los produtos inteiramente diferentes.
Requisitos Inversos
Os requisitos inversos são situações que não podem ocorrer. São de certa forma restrições de alcance geral. Descrevem o espaço fora da fronteira do sistema.
Requisito de Negócio – Requisito Inverso
O sistema não altera os dados que foram obtidos das bases de dados do E&P.