software orientado ao negócio a solução proposta pelo ... · analista de sistemas . projetista...

A solução proposta pelo método iRON integração de Requisitos Orientados a Negócio

Construção de Software Orientado ao Negócio

Eduardo José Ribeiro de Castro, MSc

1) Contextualização ● Causas de fracasso em projetos de software

● Importância dos requisitos

● Processo de construção de software

● Qualidade de software

2) Método iRON ● Análise do negócio

● Engenharia de requisitos

● Princípios norteadores

● Estrutura do método

3) Estudo de caso ● Visão geral do emprego do iRon

4) Debates e análise de casos

Agenda

1) Contextualização

● Causas de fracasso em projetos de software








3) Estudo de caso

● Visão geral do emprego do iRon


Agenda

Porque os projetos falham ?

Porque os projetos falham ?

● Ausência dos elementos básicos

● Pouco entendimento das necessidades dos clientes ○ Problema de comunicação ○ Ausência de especialista na função

Ausência dos componentes básicos

O que dá e o que não dá certo

Referência: ATALLA, FABIANO. Por que os Projetos de TI Fracassam? http://www.techoje.com.br/site/techoje/categoria/detalhe_artigo/1532

Por que os projetos falham ?

http://www.techoje.com.br/site/techoje/categoria/detalhe_artigo/1532




Produtividade


● Ausência dos elementos básicos ● Pouco entendimento das necessidades

dos clientes ○ Problema de comunicação ○ Ausência de especialista na função

Ausência dos componentes básicos

O que dá e o que não dá certo

Elementos da Comunicação

A importância da Comunicação

O problema da Comunicação

Mundos diferentes

CLIENTES TÉCNICOS

Dominam o problema (sua necessidade)

Dominam a solução técnica

Conhecem as regras do negócio Sabem como colocar em programas as regras de negócio

Tem necessidades que evoluem constantemente

Preferem congelar as expectativas e celebrar atas ou documentar requisições

Usam o linguajar de negócio Usam o linguajar da tecnologia

Não entendem de modelos técnicos

Não dominam modelos de negócio (preferem se especializar em modelos e ferramentas da informática)

Vai ficar melhor do que eu esperava!

GASPARETTO, Wagner. Toda relação humana é uma negociação – saiba negociar!


● Ausência dos elementos básicos ● Pouco entendimento das necessidades

dos clientes ○ Problema de comunicação ○ Ausência de especialista na função

Por que continuam falhando ?

Fonte: Standish Group. http://www.projectsmart.co.uk/the-curious-case-of-the-chaos-report-2009.html

http://www.projectsmart.co.uk/the-curious-case-of-the-chaos-report-2009.html
















Projetos persistentes em projeto

Fonte: PMI - Chapter São Paulo - eNews - http://www.pmisp.org.br/enews/edicao1106/artigo_01.asp

http://www.pmisp.org.br/enews/edicao1106/artigo_01.asp

http://www.pmisp.org.br/enews/edicao1106/artigo_01.asp

Por que? Falta de processo de Engenharia de Requisitos? Falta de especialistas na comunicação? Falta de um método focado no negócio?


• A tendência natural das organizações que trabalham sem um processo de ER tem sido identificar os requisitos rapidamente de maneira informal e iniciar a codificação.

• Este é o processo “codifica-remenda” até a produção de uma versão com qualidade adequada ou o cancelamento do projeto.

• Estes projetos freqüentemente estouram o prazo e o orçamento.

• É importante lembrar que o esforço e o custo do retrabalho são maiores do que os investimentos em ER, buscando desenvolver o projeto certo da primeira vez.


A especialização em Engenharia de Requisitos


Adaptado de: RUP- Por que iterar? http://www.funpar.ufpr.br:8080/rup/process/workflow/manageme/co_phase.htm

Analista de Sistemas

Projetista de

Sistemas

Progra madores

Engenheiro de

Requisitos

http://www.funpar.ufpr.br:8080/rup/process/workflow/manageme/co_phase.htm

http://www.funpar.ufpr.br:8080/rup/process/workflow/manageme/co_phase.htm

Resposta: solução sistêmica











Agenda

2) Método iRON

●Análise do negócio ● Engenharia de requisitos



Agenda

2) O método iRON – Análise do Negócio

"A primeira regra de qualquer tecnologia utilizada nos negócios é que a automação aplicada a um processo eficiente aumentará a eficiencia.

A segunda é que a automação aplicada a um processo ineficiente aumentará a ineficiência.”

(Bill Gates)


Segundo o BABOK 2.0, a Análise de Negócio é definida como: • Conjunto de tarefas e técnicas utilizadas

para o trabalho como um elo de ligação entre as partes interessadas (stakeholders) para entender a estrutura, as políticas e as operações de uma organização bem como os problemas envolvidos, e recomendar soluções que permitam que esta possa alcançar seus objetivos.


Sistemas de Informação

É um conjunto de componentes interrelacionados que coletam, manipulam e disseminam dados e informação, proporcionando um mecanismos de feedback para atender a um objetivo.

Stairs e Reynolds(2002)


• A analise do negócio de um Sistema de Informação deve ser realizada buscando identificar os elementos que a compõem e as tarefas e as regras dos processos utilizados para transformação dos dados em informação

• Essa análise do processo nos permite compreender o negócio, identificar os problemas e propor soluções.


DADOS

PROCESSO

INFORMAÇÃO

SISTEMA DE INFORMAÇÃO – S.I.


Automação

SISTEMA DE INFORMAÇÃO – S.I.

DADOS

PROCESSO

INFORMAÇÃO Descrição do

Processo

Mapeamento do Processo

Análise do Problema

Proposta de Solução


Automação


●Engenharia de requisitos ● Princípios norteadores


Agenda

• A ER é uma sub-área da Engenharia de Software que estuda o processo de produção e gerência dos requisitos que o software deverá atender.

• O objetivo da ER é fornecer métodos, procedimentos e ferramentas que forneçam suporte adequado às tarefas de produção e gerência dos requisitos do sistema.

• Foi estabelecida como disciplina independente em 1993

2) O método iRON – Engenharia de Requisitos


• Uma compreensão completa do problema e a definição dos requisitos do software e sua especificação minuciosa é fundamental para o processo de desenvolvimento obter um software com alta qualidade.

• Não importa quão bem projetado ou codificado está um programa, se ele for mal analisado e especificado desapontará o usuário e trará aborrecimentos ao desenvolvedor.

Importância dos Requisitos



• Requisitos mal definidos, ou que não atendam as expectativas dos clientes, exigem reparos durante o desenvolvimento do software.

• A manutenção do projeto de software eleva drasticamente seus custos, podendo levá-lo ao fracasso.


O que é um REQUISITO ?

“Podemos conceituar requisitos como sendo uma ação a ser executada por um sistema, possuindo características e condições próprias e que devem ser atendidas conforme as necessidades de negócio do usuário.”

Carlos Vazquez - FATTO

Dois tipos de DOCUMENTO de REQUISITOS

Clientes Técnicos

Especificação dos Requisitos

Definição dos Requisitos

•Lista do que o Cliente espera que o sistema faça;

•Compreensível ao Cliente; •Consenso entre Cliente e Analista;

•Redefine os requisitos em termos técnicos;

•Compreensível para o Projetista •Consenso entre Analista e Desenvolvedor

•Envolve Modelagem




●Princípios norteadores ● Estrutura do método

Agenda

2) O método iRON – Princípios Norteadores

Princípios:

Apoio a:

• organização de dados • métrica de software • teste de software

Negócio orienta o Software Software automatiza Processo Requisitos a partir de Tarefas Protótipo define e valida Requisitos Rastreabilidade para controle de Mudança


Software automatiza as tarefas de um processos de negócio

Software

Processo de Negócio (BPM)

Conjunto de Tarefas

Conjunto de Requisitos

Automação

LP BD

Define


Mapeamento do

Processo

Identificação do

Problema

Análise do Problema

Análise do

Negócio

Viabilidade

Produção e Gerência

de Requisitos

Definição dos

Objetivos

Proposta

de Solução

Funcionalidades e

Recursos

Definição e Controle

dos Requisitos

Engenharia de

Requisitos

Descrição do

Processo


O RUP – Rational Unified Process é um processo iterativo e adaptativo de desenvolvimento, organizado e consistente.

iRON


Anex

Com relação as Metodologias ágeis, o iRON também pode participar das etapas iniciais de levantamento de requisitos.

iRON





●Estrutura do método

Agenda

2) O método iRON – Estrutura do Método

• Com base nos conceitos de • Engenharia de Software (IEEE), de • Qualidade de Software (ISO 9126), • Gestão de Processo de Negócio (BPM), • Análise de Negócio (BABOK) • Engenharia de Requisitos (IEEE)

• foi construído o método. • com disciplina e seu conjunto de atividades e

artefatos • necessários a documentação das

funcionalidades de um software solicitado pelo usuário.

Fonte: PFLEEGER, Engenharia de Software

Resolvendo problemas: processo de análise (1)


Fonte: PFLEEGER, Engenharia de Software

Resolvendo problemas: processo de síntese (2)



Método iRON

integração de

Requisitos Orientado ao

Negócio

Construção de software orientado ao negócio.

Análise do Negócio


Disciplinas

Fases

Análise Validação Elicitação Documentação


Prototipação

Teste

Gerência de Requisitos

Disciplinas de Apoio

Gerência de Projeto

Métrica de Software

Administração de Dados


iRON

VISÃO

SISTÊMICA

Pontos de Automação

Qualidade de Software

Integração de Requisitos Orientado ao Negócio

Preocupação com a solução ESTRATÉGICA

Processo de Negócio

Inicio Fim



Artefatos: • Documento de Análise de Negócio – DAN

• Descrição e mapeamento do processo • Definição do problema e proposta de solução

• Documento de Definição de Requisitos – DDR • Requisitos de software • Rastreabilidade • Prototipação

• Documento de Modelagem de Requisitos – DMR • Documento de Modelagem de Dados - DMD • Documento de Especificação de Requisitos – DER • Documento de Teste de Software – DTS • Documento de Métrica de Software - DMS • Plano de Gerencia de Requisitos – PGR

Requisitos do Software: • Funcionais (ações)

• Ex.: O sistema deve gerar extrato bancário

• Dados (atributos) • Ex.: O sistema deve gerar extrato bancário contendo

nome, hora, data, saldo e movimentação

• Regras de Negócio (condição) • Ex.: Quando o sistema gerar o extrato bancário o sistema

deve apresentar a movimentação dos 5 último dias

• Não Funcionais (Norma ISO 9126 - Qualidade) • Ex.: Quando o sistema gerar o extrato bancário o sistema

deve imprimir o extrato em até 5 segundos












Agenda

3) Estudo de Caso

Análise do Negócio


Disciplinas

Fases

Análise Validação Elicitação Documentação


Prototipação

Teste

Gerência de Requisitos

Disciplinas de Apoio

Gerência de Projeto

Métrica de Software

Administração de Dados

iRO

N

VISÃO

SISTÊMICA

Pontos de Automação

Melhoria do Sistema

Integração de Requisitos Orientado ao Negócio Preocupação com a solução

ESTRATÉGICA

Processo de Negócio

Inicio

Fim

Mapeamento do

Processo

Identificação do

Problema Análise do Problema

Análise do

Negócio

Viabilidade

Produção e Gerência

de Requisitos

Definição dos

Objetivos

Proposta

de Solução

Funcionalidades e

Recursos

Definição e Controle

dos Requisitos

Engenharia de

Requisitos

Descrição do

Processo

Identificador Requisito Funcional Requisito de

dados Regra de

Negócio

RF01 O sistema deve permitir incluir usuário RD01 RNG01 RF02 O sistema deve incluir autor RD02 RF03 O deve incluir RD03 RNG02 RF04 O sistema deve permitir alterar usuário RD01 RNG01 RF05 O sistema deve permitir excluir usuário RD04 RNG03 RF06 O sistema deve permitir incluir premio RD05 RNG08

3) Estudo de Caso – Análise do Negócio

• Visão Geral do uso do método 1. Analise de Negócio

2. Mapeamento do processo

3. Analise de Requisitos

4. Rastreabilidade

5. Prototipação

6. Modelagem de Requisitos

7. Modelagem de Dados

8. Métrica de Software

3) Estudo de Caso – Análise do Negócio

“A Editora ABC trabalha com diversos autores que escrevem livros para ela publicar. Alguns autores escrevem apenas um livro, enquanto outros escrevem muitos. Além disso, alguns livros são escritos por diversos autores. Mensalmente é enviado às livrarias um catálogo com o nome dos livros lançados e seus respectivos autores. Esse catálogo é organizado por assunto para facilitar a divulgação.

Informações sobre a cota de compra de cada livraria são modificadas a cada três meses, de acordo com a média de compra no trimestre solicitada pela livraria. Uma carta é enviada à livraria anunciando a nova cota em cada assunto e os descontos especiais que lhe serão concedidos para comprar em quantidades maiores.

Aos autores dos dez livros mais vendidos no ano, a Editora ABC oferece prêmios. A festa de premiação é anunciada com dez dias de antecedência, por meio de publicação em jornal dos dez livros mais vendidos, com seus respectivos autores.”

3) Estudo de Caso – Mapeamento do Processo

Subprocesso Gerar Catálogo

3) Estudo de Caso – Definição dos Requisitos Sub-Processo Gerar Catálogo (Requisitos Funcionais) RF01 – O Sistema deve cadastrar autor (RD01) RF02 – O sistema deve cadastrar livro (RD02) (RNG01) RF03 – O sistema deve cadastrar as livrarias (RD03) RF15 - O sistema deve registrar publicação (RD14) RF04 – O sistema deve gerar catalogo de lançamento de livros (RD04) (RNG02) (RNG03)

Sub-Processo Gerar Catálogo (Requisitos de Dados) RD01 – O sistema deve cadastrar autor contendo nome, endereço, telefone (RF01) RD02 – O sistema deve cadastrar livro contendo o nome do livro, assunto e seu(s) respectivo(s) autor(es) (RF02) RD03 – O sistema deve cadastrar livraria contendo nome da livraria, endereço, telefone e cota (RF03) RD04 – O sistema deve gerar catalogo contendo nome do livro, assunto, data publicação, e autor (RF04) RD15 - O sistema deve registrar publicação contendo nome do livro, data de publicação, assunto e seu(s) respectivo(s) autor(es) (RF15)

Sub-Processo Gerar Catálogo (Regra de Negócio) RNG01 – Quando o livro for cadastrado o sistema deve permitir cadastrar um ou mais autores (RF02) RNG02 – Quando o catalogo de lançamento do livro for gerado o sistema deve organizar por assunto (RF03) RNG03 – Quando o catalogo de lançamento do livro for gerado o sistema deve verificar se o período é de 30 dias (RF03)

3) Estudo de Caso - Rastreabilidade

Req. Complementares

Req. Funcional

RD01 RD02 RD03 RD04 RD14

RF01 X

RF02 X

RF03 X

RF04 X

RF15 X

Req. Complementares

Req. Funcional

RNG01 RNG 02 RNG 03

RF02 X

RF04 X X

3) Estudo de Caso - Rastreabilidade

DAN DDR Prototipo Modelagem Lógica Teste

Problema Solucao Requisito Funcional

Requisitos de Dados

Regra de Negocio Formulario Caso de Uso Tabelas

Especificação de Requisitos Código

Caso de Teste

Rastreabilidade Bidirecional

3) Estudo de Caso - Prototipação

3) Estudo de Caso – Modelagem de Requisitos

3) Estudo de Caso – Modelagem de Dados

Identificador Requisito Funcional Requisito

Complementar

Regra de

Negócio

RF01 O sistema deve permitir cadastrar usuário RD01 RNG01

RF02 O sistema deve cadastrar autor RD02

RF03 O sistema deve cadastrar livro RD03 RNG02

RF04 O sistema deve cadastrar Livraria RD04

DER criado após a análise de alguns requisitos funcionais

Identificador: Requisitos Funcional RD01 – O sistema deve cadastrar o usuário pelos seguintes atributos. RF01 / RFXX Nome O S E Descrição Exemplo Tipo Nome usuário x x Atributo que representa o nome completo do usuário Pedro Silva Motta. A

Login x x Atributo que representa o login do usuário. Este atributo é utilizado para efetuar o login no sistema. PedroSM A

Senha x x Atributo que representa a senha do usuário. Este atributo é utilizado para efetuar o login no sistema. 12345678 A

Data de cadastramento x Atributo que representa a data do cadastramento do usuário a ser identificado pelo sistema 17/11/2002 D

Status x x Atributo que representa o status do usuário. I ou A --

CPF x x Atributo que representa o número do cadastro da pessoa física do usuário. 021.058.194-08 N

RG x Atributo que representa o número do registro geral do usuário. 1.487.599 N

UF do RG x Atributo que representa a unidade da federação de expedição do RG do usuário. DF, BA, RR. C

Órgão expedidor do RG x Atributo que representa o órgão que expediu o RG do usuário. SSP/DF C

e-mail x Atributo que representa um e-mail do usuário. [email protected] A

RD02 – O sistema deve cadastrar o autor pelos seguintes atributos. RF02 / RFXX Nome O S E Descrição Exemplo Nome Autor x Atributo que representa o nome completo do autor Pedro Silva Motta.

Unidade Federação - UF x x Atributo que representa a unidade da federação do endereço do autor DF, BA, RJ, SP

Cidade x x Atributo que representa a cidade do endereço do autor São Paulo

Endereço x x Endereço do autor SQN 216 BL V APT 326 Bairro x x Bairro do endereço do autor Asa Norte

Município x x Município do endereço do autor

CEP x x CEP do endereço do autor 70000-000

Telefone residencial x Número do telefone residencial do autor (61) 3034-8457

Telefone Celular x Número do telefone celular do autor. (61) 9999-8877

e-mail x e-mail do autor [email protected]


mailto:[email protected]






RD03 – O sistema deve cadastrar o livro pelos os seguintes atributos RF03 / RFXX

Nome O S E Descrição Exemplo Título livro x x Atributo que representa o título do livro do autor. Qualidade de Software

Autor

x x Atributo que representa o(s) autor(es) de um mesmo livro Ivan Mecenas e Viviane Oliveira

Edição x x Atributo que representa a edição do livro 3ª.

Editora x x Atributo que representa a editora do livro Atlas

Ano x x Atributo que representa o ano da edição do livro 2010

ISBN x x Atributo que representa o código ISBN (International Standard Book Number) 978-85-7194-312-4


DER atualizado após a análise dos Requisitos de dados


Identificação da regra de

negócio Descrição da regra de negócio

RNG01 Quando o livro for cadastrado o sistema deve permitir cadastrar um ou mais

autores RNG08 Quando cadastrar o premio o sistema deve permitir relacionar prêmio ao autor

Regras de negócio consideradas


DER atualizado após a análise das regras de execução


3) Estudo de Caso – Métrica de Software

O iRON sugere a utilização da APF e da NESMA para mensuração do tamanho do software no processo de produção de requisitos.

Outras métricas de tamanho podem ser utilizadas, pois o método iRON possibilita a identificação de todos os dados necessários para a mensuração inicial e final.

Após a elaboração do DAN pode-se realizar a contagem estimada (Nesma), e após a elaboração da DDR realizar-se-ia a contagem detalhada (IFPUG).

Para realizar a contagem estimada do estudo de caso da Editora ABC, analisa-se o modelo de dados e os requisitos funcionais que facilitam a identificação dos ALIS e AIES.

Identificação dos ALI, Dados de código e Dados de referência do modelo de dados da Editora ABC


Pela Contagem Estimada tem-se o valor de 7 PF x 5 ALIS computando o total de 35 PF e 7 PF para o dado de referência.

Ao todo são 42 PF correspondentes as funções de dados.

Não existem AIES nesse estudo de caso.


Com relação as funções transacionais, o quadro apresenta parte dos requisitos funcionais.

Essa tabela permite identificar inicialmente as EE, SE e CE.

Seriam inicialmente 6 EE. Na contagem estimativa cada EE recebe 4 PF. Assim teríamos 6 EE x 4 PF = 24 PF.

A contagem estimada até o momento é de 42 PF + 24 PF = 66 PF.


Identificador Requisito Funcional Requisito de

Dado Regra de

Execução

RF01 O sistema deve incluir usuário RD01 RE01

RF02 O sistema deve incluir autor RD02

RF03 O sistema deve incluir livro RD03 RE02

RF04 O sistema deve permitir alterar usuário RD01 RE01

RF05 O sistema deve permitir excluir usuário RD04 RE03

RF06 O sistema deve permitir incluir premio RD05 RE08

Parte dos requisitos funcionais da Editora ABC

O Quadro apresenta a contagem detalhada de parte dos requisitos da Editora ABC.

A contagem detalhada até o momento é de 42 PF (7 x 6) + 18 PF (3 x 6) = 60 PF.

Funcão Identificação Complexidade QTD PF

ALI Autor Baixa 7

ALI Usuário Baixa 7

ALI Prêmio Baixa 7

ALI Livro Baixa 7

ALI Editora ‘Baixa 7

Dados de referencia Municipio Baixa 7

EE O sistema deve incluir usuário Baixa 3

EE O sistema deve incluir autor Baixa 3

EE O sistema deve incluir livro Baixa 3

EE O sistema deve permitir alterar usuário Baixa 3

EE O sistema deve permitir excluir usuário Baixa 3

EE O sistema deve permitir incluir premio Baixa 3


Eduardo Castro, Msc [email protected] http://lattes.cnpq.br/2217593248315675 br.linkedin.com/pub/eduardo-castro/6/64b/4b2/

Perguntas??


http://lattes.cnpq.br/2217593248315675

http://br.linkedin.com/pub/eduardo-castro/6/64b/4b2/



software orientado ao negócio a solução proposta pelo ... · analista de sistemas . projetista...

Documents