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)

OBRIGADO.OBRIGADO.

ejrcastro@gmail.comejrcastro@gmail.com

eduardo@quaddract.com.breduardo@quaddract.com.br

Perguntas ?