Baixe o app para aproveitar ainda mais
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??
Compartilhar