SoftwareOrientadoNegocio_Metodo_iRON1

Prévia do material em texto

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 
● 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 
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 ? 
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 ? 
Produtividade 
Por que 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 
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! 
Por que 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 
Por que continuam falhando ? 
Fonte: Standish Group. 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 
Por que? 
 
Falta de processo de Engenharia de Requisitos? 
 
Falta de especialistas na comunicação? 
 
Falta de um método focado no negócio? 
Por que continuam falhando ? 
• 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. 
Por que continuam falhando ? 
Por que? 
 
Falta de processo de Engenharia de Requisitos? 
 
Falta de especialistas na comunicação? 
 
Falta de um método focado no negócio? 
Por que continuam falhando ? 
A especialização em Engenharia de Requisitos 
Por que continuam falhando ? 
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 
Por que? 
 
Falta de processo de Engenharia de Requisitos? 
 
Falta de especialistas na comunicação? 
 
Falta de um método focado no negócio? 
Por que continuam falhando ? 
Resposta: solução sistêmica 
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 
2) Método iRON 
●Análise do negócio 
● Engenharia de requisitos 
● Princípios norteadores 
● Estrutura do método 
 
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) 
 
 
2) O método iRON – Análise do Negócio 
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. 
2) O método iRON – Análise do Negócio 
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) 
 
2) O método iRON – Análise do Negócio 
• 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. 
2) O método iRON – Análise do Negócio 
DADOS 
PROCESSO 
INFORMAÇÃO 
SISTEMA DE INFORMAÇÃO – S.I. 
2) O método iRON – Análise do Negócio 
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 
2) O método iRON – Análise do Negócio 
Automação 
2) Método iRON 
● Análise do negócio 
●Engenharia de requisitos 
● Princípios norteadores 
● Estrutura do método 
 
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 
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 dedesenvolvimento 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 
2) O método iRON – Engenharia de Requisitos 
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. 
 
2) O método iRON – Engenharia de Requisitos 
Importância dos Requisitos 
2) O método iRON – Engenharia de Requisitos 
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 
 
 
2) O método iRON – Engenharia de Requisitos 
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 
2) O método iRON – Engenharia de Requisitos 
2) Método iRON 
● Análise do negócio 
● Engenharia de requisitos 
●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 
2) O método iRON – Princípios Norteadores 
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 
2) O método iRON – Princípios Norteadores 
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 
2) O método iRON – Princípios Norteadores 
O RUP – Rational Unified Process é um processo iterativo e adaptativo 
de desenvolvimento, organizado e consistente. 
iRON 
2) O método iRON – Princípios Norteadores 
Anex 
Com relação as Metodologias ágeis, o iRON também pode participar 
das etapas iniciais de levantamento de requisitos. 
iRON 
2) O método iRON – Princípios Norteadores 
2) Método iRON 
● Análise do negócio 
● Engenharia de requisitos 
● Princípios norteadores 
●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) 
2) O método iRON – Estrutura do Método 
Fonte: PFLEEGER, Engenharia de Software 
Resolvendo problemas: processo de síntese (2) 
2) O método iRON – Estrutura do Método 
2) O método iRON – Estrutura do Método 
Método iRON 
 
integração de 
Requisitos 
Orientado ao 
Negócio 
 
 
Construção de software orientado ao negócio. 
 
Análise do 
Negócio 
Definição 
dos 
Requisitos 
Disciplinas 
Fases 
Análise Validação Elicitação Documentação 
Proposta de 
Solução 
Prototipação 
Teste 
Gerência de 
Requisitos 
Disciplinas de Apoio 
Gerência de 
Projeto 
Métrica de 
Software 
Administração 
de Dados 
2) O método iRON – Estrutura do Método 
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 
2) O método iRON – Estrutura do Método 
2) O método iRON – Estrutura do Método 
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 
2) O método iRON – Estrutura do Método 
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 
3) Estudo de Caso 
Análise do 
Negócio 
Definição dos 
Requisitos 
Disciplinas 
Fases 
Análise Validação Elicitação Documentação 
Proposta de 
Soluçã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 
In
ici
o 
Fi
m 
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. Mapeamentodo 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 Requisitos 
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. teste@gmail.com 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 teste@gmail.com 
3) Estudo de Caso – Modelagem de Dados 
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 
3) Estudo de Caso – Modelagem de Dados 
DER atualizado após a análise dos Requisitos de dados 
3) Estudo de Caso – Modelagem 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 
3) Estudo de Caso – Modelagem de Dados 
DER atualizado após a análise das regras de execução 
3) Estudo de Caso – Modelagem de Dados 
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 
3) Estudo de Caso – Métrica de Software 
Pela Contagem Estimada tem-se o valor de 7PF 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. 
3) Estudo de Caso – Métrica de Software 
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. 
3) Estudo de Caso – Métrica de Software 
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 
3) Estudo de Caso – Métrica de Software 
Eduardo Castro, Msc 
 
ejrcastro@gmail.com 
 
http://lattes.cnpq.br/2217593248315675 
 
br.linkedin.com/pub/eduardo-castro/6/64b/4b2/ 
 
 
Perguntas??