Metodo eXtreme Requirements XR
-
Upload
robson-silva-espig -
Category
Documents
-
view
508 -
download
8
Transcript of Metodo eXtreme Requirements XR
Processo
eXtreme
Requiriments
XR
Eduardo José Ribeiro de Castro, MSc
Fernando de Albuquerque Guimarães, MSc
Direitos reservados
XR
2
Elementos Conceituais
Elementos Conceituais
Business Process Management (BPM)
• Processo é “um conjunto fim-a-fim completo deatividades que juntas criam valor para o cliente”(Beyond Reengineering, Michael Hammer, HarperBusiness, 1996)
3
Business, 1996)• Processo é a unidade básica de valor do negócio em
uma empresa
Motivação
• No final do século passado, o redesenho de funçõesde negócio como processos tornou-se a estratégiaestabelecida para reduzir custos, tempos de ciclo emelhorar a qualidade e satisfação de clientes
Conceito de Qualidade de Software
• “Conformidade a requisitos funcionais e dedesempenho, explicitamente declarados, apadrões de desenvolvimento claramentedocumentados e a características implícitas que são
Elementos Conceituais
4
padrões de desenvolvimento claramentedocumentados e a características implícitas que sãoesperadas de todo o software profissionalmentedesenvolvido.”
Pressman, Roger
Conceito de Qualidade de Software
• “Conformidade a requisitos funcionais e dedesempenho, explicitamente declarados, apadrões de desenvolvimento claramentedocumentados e a características implícitas que são
Elementos Conceituais
5
padrões de desenvolvimento claramentedocumentados e a características implícitas que sãoesperadas de todo o software profissionalmentedesenvolvido.”
Pressman, Roger
Processo de Desenvolvimento
• O desenvolvimento do produto deve seguir um modelo baseado em umprocesso de software. Este processo consiste numa seqüência deetapas que envolvem atividades, restrições e recursos para alcançar umresultado desejado.
• O primeiro modelo proposto pela engenharia de software, modelo em
Elementos Conceituais
6
• O primeiro modelo proposto pela engenharia de software, modelo emcascata, define as etapas em seqüência. Neste modelo, uma etapadever ser finalizada antes de a próxima começar.
• Em 1988, Boehm sugeriu um modelo de processo em espiral,combinando as atividades de desenvolvimento com o gerenciamento derisco, de modo a minimizar e controlar os riscos do projeto.
Processo de Desenvolvimento
• A metodologia a ser empregada no desenvolvimento da ferramentautilizará a abordagem iterativa proposta por Philippe Kkruchten em1995. Este novo modelo combina o modelo em cascata e o modelo emespiral, incorporando novos conceitos da Engenharia de Software.
• Nesta abordagem, as atividades que ocorrem em cada fase do modelo
Elementos Conceituais
7
• Nesta abordagem, as atividades que ocorrem em cada fase do modeloem cascata podem ser “refinadas” durante várias iterações do projeto.E, como no modelo em espiral, cada iteração é planejada paraminimizar os riscos inerentes a cada estágio do desenvolvimento.
• Uma iteração incorpora uma seqüência livre de atividades (modelagemde negócio, proposta de solução, definição de requisitos, etc., emproporções variáveis de acordo com a fase do ciclo de desenvolvimentoque a iteração está localizada). O foco da iteração depende em quefase esta se encontra.
Engenharia de Requisitos
Produção deRequisitos
1. Elicitação2. Análise e Negociação3. Documentação
Elementos Conceituais
8
Engenharia deRequisitos
Requisitos
Gerênciade Requisitos
3. Documentação4. Validação
1.Rastreabilidade2.Gerenciamento de Mudanças3.Gerenciamento de Configuração4.Gerenciamento da Qualidade dos
Requisitos
Engenharia de Requisitos
• Os 4 subprocessos da Produção de Requisitos:
– Elicitação• Identificação da fonte de informação. Obtenção dos dados e
fatos
Elementos Conceituais
9
fatos– Análise
• Obter entendimento sobre as funcionalidades do sistema. Avaliar e revisar o escopo do software.
– Documentação• Definição e conversão dos requisitos em alguma forma-padrão;
Documento de Definição de Requisitos– Validação
• Verificação se os requisitos realmente definem o sistema que o cliente deseja; Protótipo.
Engenharia de Requisitos
• Os 4 subprocessos da Gerência de Requisitos:
– Gerência de Mudanças• Controla as solicitações de mudança do cliente
Elementos Conceituais
10
• Controla as solicitações de mudança do cliente
– Gerência de Configuração• Controla as versões dos artefatos
– Gerência de Qualidade dos Requisitos• Define o padrão de produção e verificação da qualidade dos
requisitos
– Rastreabilidade• Relação entre as fontes dos requisitos, os requisitos
propriamente ditos e outros artefato
Processo XR
11
Processo XR
eXtreme Requirements
(Eduardo Castro, Direitos Reservados)
• Com base nos conceitos de Engenharia de Software(IEEE), de Qualidade de Software (ISO 9126),Gestão de Processo de Negócio (BPM) e dosprocesso de Engenharia de Requisitos (IEEE) foiconstruído um processo para definição de requisitoscomposto de fases, disciplinas, atividades e
Processo eXtreme Requirements
12
composto de fases, disciplinas, atividades eartefatos necessários a construção de requisitospara definição das funcionalidades de um software.
Modelagem de
Negócio
Disciplinas
Fases
Análise ValidaçãoElicitação Documentação
Proposta de
Solução
Processo eXtreme Requirements®Eduardo José Ribeiro de Castro®
13
Definição dos
Requisitos
Prototipação
Teste
Gerência de
Requisitos
Disciplinas de ApoioGerência de
Projeto
Métrica de
Software
Administração
de Dados
Fases:
1. Elicitação• O objetivo principal da fase de elicitação de requisitos é organizar e
analisar os documentos, normas, leis, estrutura, responsáveis quecompõem o processo de negócio em estudo, buscando obterconhecimento do domínio do problema.
2. Análise
Processo eXtreme Requirements
14
2. Análise• O objetivo da fase de análise de requisitos é avaliar e revisar o escopo
do software por meio de um processo de descoberta, refinamento,revisão e validação, obtendo um entendimento sobre asfuncionalidades do sistema.
• O processo de avaliação e síntese continua até que o analista e o clienteconcordem que o software pode ser adequadamente definido gerandoassim uma proposta de solução.
Fases:
3. Documentação• O documento de requisitos de um software contém os requisitos
identificados e desejados pelo cliente a partir da proposta de soluçãodescrita na fase de análise.
• São definidos todos os requisitos funcionais, complementares e nãofuncionais do software
• São identificadas as regras de negócio que indicam a condição para que
Processo eXtreme Requirements
15
• São identificadas as regras de negócio que indicam a condição para queaquele requisito possa ser implementado e executado.
• Este documento serve como um meio de comunicação entre oprojetista do software e o usuário, a fim de estabelecer um “acordo”acerca do software pretendido.
4. Validação• A validação representa a atividade em que obtemos o aceite do cliente
sob determinado artefato• No cenário de engenharia de requisitos, esta atividade significa aprovar
junto ao cliente os requisitos que foram definidos
Etapas:
1. Modelagem de Negócio• Atividade: Análise do negócio, organograma, responsáveis, área(s)
de automação, fluxo de atividades e identificação de problemas.• Artefato: Documento de Análise
2. Proposta de SoluçãoAtividade: Para cada problema identificado na etapa anterior é
Processo eXtreme Requirements
16
2. Proposta de Solução• Atividade: Para cada problema identificado na etapa anterior é
proposta solução contendo os objetivo geral, objetivos específicos,suas principais funcionalidades e fluxo de atividades do processoatualizado.
• Artefato: Proposta de Solução
3. Definição dos requisitos• Atividade: A partir dos objetivos específicos e suas principais
funcionalidades são identificados os requisitos do software(funcionais, complementares e não funcionais), as regras denegócio, matriz de rastreabilidade e priorização dos requisitos.
• Artefato: Documento de Definição de Requisitos - DDR
Etapas:
4. Prototipação• Atividade: A partir da definição dos requisitos do software é
construído um protótipo de Baixa Fidelidade de forma a facilitar acomunicação entre o usuário e os analistas de requisitos e validaras funcionalidades e requisitos identificados.
• Artefato: Protótipo de Baixa Fidelidade (não funcional)
Processo eXtreme Requirements
17
Artefato Protótipo de Baixa Fidelidade (não funcional)
5. Teste• Atividade: A partir da análise do negócio podem ser executados
testes de verificação e validação entre os objetivos específicos,suas principais funcionalidades, requisitos do softwareidentificados, regras de negocio e prioridades definidas.
• Artefato: Documento de Teste de Requisitos
6. Gerência de Requisitos• Atividade: Durante todo o processo XR a Gerência de requisitos é
responsável pela rastreabilidade de requisitos, gerência demudança, gerencia de configuração e gerencia da qualidade dosrequisitos.
• Artefato: Plano de Gerência de Requisitos
• Estas fases e disciplinas têm como objetivoconstruir, de forma organizada e estruturada, deuma visão mais geral para a mais específica, oentendimento do sistema de informação que sepretende automatizar, qual(is) o(s) processo(s) queo compõem e seus problemas.
Processo eXtreme Requirements
18
o compõem e seus problemas.• Esta prática facilita a aplicação de técnicas de
contagem (métrica de software) logo no inicio doprojeto.
• A partir da Modelagem de Negócio e do mapeamentodo seu processo (fluxo de atividades) é possívelidentificar e compreender a seqüência lógica dasatividades que visam a transformação dos dados eminformação.
• Esta compreensão auxilia na descrição dos problemas
Processo eXtreme Requirements
19
• Esta compreensão auxilia na descrição dos problemasque são passíveis de automação.
• Com essa modelagem e descrição dos problemas, épossível gerar uma proposta de solução quecontenham os objetivos geral e específicos para suaautomação.
• Os objetivos específicos devem ser descritos e suasfuncionalidades identificadas.
• Um novo fluxo de atividades é gerado, corrigindo e/ouotimizando o processo atual.
• A partir dos objetivos específicos e suas principaisfuncionalidades, são identificados os requisitos dosoftware (funcionais, complementares, nãofuncionais), as regras de negócio e elaborado odocumento de definição de requisitos.
• Este documento tem de ser validado pelo usuário de
Processo eXtreme Requirements
20
• Este documento tem de ser validado pelo usuário deforma a orientar a construção do software.
• Tendo por base o documento de definição derequisitos é construído um protótipo de baixafidelidade com o intuito de validar, junto ao usuário,os requisitos e regras de negócio identificados.
• O protótipo auxilia na validação e verificação dosrequisitos.
• A disciplina de teste verifica se os requisitos estãoatendendo aos objetivos específicos e suasfuncionalidades e se o protótipo contem todos osrequisitos definidos.
Processo eXtreme Requirements
21
funcionalidades e se o protótipo contem todos osrequisitos definidos.
• A gerencia de requisitos acompanha todo oprocesso, mantendo a rastreabildiade dosrequisitos, o controle de mudança e configuração e aqualidade dos requisitos produzidos e dadocumentação construída.
Análisedo Negócio
Modelagemdo Processo
Análise doProblema
Proposta de
Solução
Documentaçãoe
Validação
Processo de NegócioDefinição
dos Requisitos
Processo eXtreme Requirements
22
do Negócio do Processo ProblemaSolução Validação
Projeto deDefinição de
Software
Definiçãode
Requisitos
• Os requisitos do software construídos a partir deuma visão sistêmica de todo o processo facilitam aidentificação de pontos ou de oportunidades deautomação, possibilitando a integração entrediversos sistemas.
Processo eXtreme Requirements
23
• Esta prática leva a uma melhora considerável daaplicação dos recursos financeiros, pessoal, dehardware e software, gerando expectativas demenores custos, prazos mais realísticos e melhorana qualidade do software.
VISÃO SISTÊMICA
Pontos de Automação
Processo de NegócioInicio Fim
Processo eXtreme Requirements
24
XR
Melhoria do SistemaeXtremeRequirementsPreocupação com a
solução
ESTRATÉGICA
Para Refletir
“ Para fazer as coisas de maneira diferente, vocêprecisa ver as coisas de maneira diferente.”
Paul Allaire, CEO da
Xerox CorporationXerox Corporation
“ Se não mudarmos o rumo, chegaremos exatamenteaonde estamos indo.”
Provérbio antigo
25
Referências Bibliográficas
• BALDAM, Roquemar de Lima, ET AL. Gerenciamento de Processos de negócios: BPM – Business Process Management – 1ª. edição São Paulo: Érica, 2007
• COCKBURN, A. Escrevendo Casos de Uso Eficazes: Um Guia Pratico para Desenvolvedores de Software. Bookman, 2005
• DINSMORE, Paul - Como se tornar um Profissional em Gerenciamento de Projetos - 2ª Edição;
26
Projetos - 2ª Edição;
• LEFFINGWELL, Dean Managing Software Requirements, Second Edition: A Use Case Approach, ed. Pearson , 2003
• PFLEEGER, Shari Lawrence. Engenharia de Software: Teoria e Prática. 2ª edição – 2004
• PRESSMAN, Roger. S. Engenharia de software: um enfoque prático. 3. ed. São Paulo: Makron Books, 1995.
• SOMMERVILLE, Ian.Engenharia de Software. 6ª ed. São Paulo: Addison Wesley, 2003
• SWEBOK - Guide to the Software Engineering Body of Knowledge (www.swebok.org)
Perguntas ?