gerência de requisitos de software. problemas comuns em desenvolvimento de software

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


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


• 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


Como foi Aprovado Como foi Implementado


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


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



Administradorde ReqPro

Gerência deConfiguração

Casos de UsoProduto


Documentode VisãoVersionado

Clear Case


Casos de UsoProdutoInspecionados


Casos de UsoProdutoVersionados

Clear Case



Analista deRequisitos

Equipe deQualidade


Casos deTeste

CQTM

Artefatos deAnálise

RSA

Casos de UsoProduto Versionados

Clear Case


Artefatos deAnáliseInspecionados

RSA

Artefatos de AnáliseVersionados

Clear Case

RSA

Equipe deDesenvolvimento

Equipe deQualidade


Artefatos deProjeto

RSA

Artefatos deAnáliseVersionados

Clear Case

RSA

Artefatos deProjetoInspecionados

RSA

Artefatos deProjetoVersionados

Clear Case

RSA



Equipe deQualidade


SoftwareCodificado

Eclipse

Artefatos deProjetoVersionados

Clear Case

RSA

Software Testado

Eclipse

SoftwareVersionado

Clear Case

Eclipse

Criação doAmbiente de

Desenvolvimento


Teste


Equipe deQualidade


Casos deTeste

SoftwareCodificadoHomologado

SoftwareVersionado

Clear Case

Eclipse

Software emProdução

Relatório deFechamento

NTI

Criação doAmbiente deHomologação


Produção


Infra-estrutura Líder de Projeto


Tratando uma mudança de requisito:

Alteraçãode Requisitode Negócio

Documentode VisãoAlterado

Checkout do Documento de

Visão

Casos de Usode ProdutoAlterados



Clear CaseRequisite Pro(Oracle)




Casos deTesteAlterados

CQTM


Analista deNegócio

Equipe deQualidade

TratarMudança



Casos deTesteAlterados

CQTM


NTI

Documentos de RequisitoVersionados

Clear CaseRequisit Pro


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.

gerência de requisitos de software. problemas comuns em desenvolvimento de software

Documents