Upload
ngonhi
View
214
Download
0
Embed Size (px)
Citation preview
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 ?
● Ausência dos elementos básicos
● Pouco entendimento das necessidades dos clientes ○ Problema de comunicação ○ Ausência de especialista na função
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 ?
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
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 ?
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
"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 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
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
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
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
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
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 – 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 – 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]
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
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
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 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.
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 [email protected] http://lattes.cnpq.br/2217593248315675 br.linkedin.com/pub/eduardo-castro/6/64b/4b2/
Perguntas??