Levantamento, Análise e Gestão Requisitos. Aula 11

Transcrição

1 Levantamento, Análise e Gestão Requisitos Aula 11

2 Agenda Miscelâneas (Parte 2): Refinamento da definição do sistema Análise da alteração e seu impacto

3 Problema de Projetos Cancelados

4 Managing Software Requirements: Situação Desenvolvimento de Software A Use Case Approach, Second Edition, % dos projetos são cancelados antes de serem completados 52,7% dos projetos custam 189% de sua estimativa inicial Causas?

5 Projetos que Falham Falta de Causas comunicação mais do importantes usuário - 13% Requisitos /Especificações incompletas - 12% Requisitos /Especificações que mudam - 12%

6 Projetos de Sucesso Realizados no prazo e no custo estimados Grandes empresas: 9% Pequenas empresas: 16% Envolvimento Três fatores do de usuário sucesso - mais 16% importantes Suporte Gerencial do alto executivo - 14% Requisitos definidos de forma clara - 12%

7 1980 Codificação Code Centric Linguagens: Pascal, C, Basic, Cobol... Monolítico

8 1985 Dados Database Centric Acesso a Banco de Dados SQL - Structure Query Language Ferramentas Case para geração automática

9 1990 Produtividade GUI Centric Cliente - Servidor Rapid Aplication Developer Visual Basic e Delphi

10 1995 Performance Object Centric (volta a 1966) Computação Distribuída Escalabilidade

11 2000 Controle Process Centric Processo Unificado UML Unified Model Language

12 2005 Distribuição Multi Centric Processo Distribuído na WEB Processo Colaborativo Redes Sociais: Facebok, Twitter, Linkedin,... Linguagens WEB: ASP, JSP, PHP,...

13 2010 Mobilidade Mobile Centric Aplicativos móveis Nascimento do e-readers Nascimento do iphone Nascimento do Tablets Nascimento do Android

14 2015 Interatividade Interactive Centric Aplicativos na Nuvem Pesquisas Inteligentes Escritório em qualquer lugar Programação Interativa: TV

15 Crise de Software Conjunto de problemas encontrados no desenvolvimento de software: (1) As estimativas de prazo e de custo frequentemente são imprecisas Não dedicamos tempo para coletar dados sobre o processo de desenvolvimento de software Sem nenhuma indicação sólida de produtividade, não podemos avaliar com precisão a eficácia de novas ferramentas, métodos ou padrões

16 Crise de Software (2) A produtividade das pessoas da área de software não tem acompanhado a demanda por seus serviços Os projetos de desenvolvimento de software normalmente são efetuados apenas com um vago indício das exigências do cliente

17 Crise de Software (3) A qualidade de software às vezes é menos que adequada Só recentemente começam a surgir conceitos quantitativos sólidos de garantia de qualidade de software (4) O software existente é muito difícil de manter A tarefa de manutenção devora o orçamento destinado ao software A facilidade de manutenção não foi enfatizada como um critério importante

18 Atividades do Ciclo de Vida Clássico Envolve a coleta de requisitos em nível do sistema, pequena quantidade de projeto e análise de alto nível Engenharia de Sistemas Análise de Requisitos Projeto Codificação Visão essencial quando o software deve fazer interface com outros elementos (hardware, pessoas e banco de dados) Testes Manutenção

19 Processo de coleta dos requisitos é intensificado e concentrado especificamente no software Deve-se compreender o domínio da informação, a função, desempenho e interfaces exigidos Engenharia de Sistemas Análise de Requisitos Projeto Atividades do Ciclo de Vida Clássico Codificação Testes Os requisitos (para o sistema e para o software) são documentados e revistos com o cliente Manutenção

20 Tradução dos requisitos do software para um conjunto de representações que podem ser avaliadas quanto à qualidade, antes que a codificação se inicie Engenharia de Sistemas Análise de Requisitos Projeto Atividades do Ciclo de Vida Clássico Se concentra em 4 atributos do programa: Codificação Testes Manutenção Estrutura de Dados Arquitetura de Software Detalhes Procedimentais Caracterização de Interfaces

21 Atividades do Ciclo de Vida Clássico Engenharia de Sistemas Análise de Requisitos Projeto Tradução das representações do projeto para uma linguagem artificial resultando em instruções executáveis pelo computador Codificação Testes Manutenção

22 Atividades do Ciclo de Vida Clássico Concentram-se: Nos aspectos lógicos internos do software, garante que todas as instruções tenham sido verificadas Engenharia de Sistemas Análise de Requisitos Projeto Codificação Nos aspectos funcionais externos, para descobrir erros e garantir que a entrada definida produza resultados que concordem com os esperados Testes Manutenção

23 Atividades do Ciclo de Vida Clássico O software pode sofrer mudanças depois que for entregue ao cliente Engenharia de Sistemas Análise de Requisitos Projeto Codificação Causas dessas mudanças: erros, adaptação do software para acomodar mudanças em seu ambiente externo e exigência do cliente para acréscimos funcionais e de desempenho Testes Manutenção

24 Documentação em Projetos

25 Dado nosso conhecimento técnico, os prazos dos projetos são razoáveis? Viabilidade do Cronograma Alguns projetos são iniciados com prazos específicos: Determinar se os prazos são obrigatórios ou desejáveis Se são mais desejáveis que obrigatórios, o analista pode propor outros cronogramas

26 Viabilidade do Cronograma

27 Talvez a mais crítica Julgar se os possíveis benefícios de solucionar o problema são ou não vantajosos Viabilidade Econômica Tão logo os requisitos específicos e soluções sejam identificados, o analista pode levar em consideração os custos e benefícios de cada alternativa Isso é chamado de análise de custo-benefício

28 Custos de desenvolvimento de sistemas: Custo para Aquisição de Equipamentos Custo de Instalação e Conversão de Dados Tipos de Custos Custo Operacionais (contínuos): Manutenção e Pessoal

29 Estudo de Caso Definição dos Requisitos * Quero algo para atravessar a cidade no menor tempo possível

30 Estudo de Caso Mudança nos Requisitos * Mas não quero me molhar! Como vou carregar minha pasta?

31 Estudo de Caso Retrabalho

32 Estudo de Caso Entrega do Sistema

33 Gerenciamento de Alterações de Requisitos O gerenciamento de alterações envolve métodos, procedimentos e padrões que são usados para gerenciar as alterações dos requisitos do sistema Este gerenciamento garante que sejam coletadas todas as informações relacionadas aos envolvidos na alteração, além de ser realizada, para cada alteração proposta, uma avaliação de custos e benefícios Esta avaliação é denominada de Análise de Impacto da Mudança

34 Gerenciamento de Alterações de Requisitos A Organização deve definir uma política de gestão de requisitos, considerando, dentre outros, os seguintes aspectos sobre o gerenciamento das alterações: Processo de solicitação de alteração e a informação requerida para processar cada solicitação de alteração Processo usado para analisar o impacto e custos da alteração e informações de rastreabilidade associadas Grupo da organização que considera formalmente as solicitações de alteração Ferramenta de suporte (caso exista) para o controle do processo de alterações

35 Gerenciamento de Alterações de Requisitos O processo de gerenciamento de alterações de requisitos consiste em um conjunto de atividades para documentação, relato, análise, avaliação de custo e implementação das alterações no conjunto de requisitos do sistema Problema Identificado Análise do problema e Especificação da alteração (1) Análise e Avaliação de Custo da Solução (2) Implementação da alteração (3) Requisitos Revisados

36 Análise e Avaliação do Custo da Solução

37 Análise e Avaliação da Alteração A solicitação de alteração pode ser rejeitada: Se a solicitação de alteração for inválida: Isto normalmente ocorre quando o cliente tem uma interpretação incorreta sobre alguns dos requisitos e propõe uma alteração que não é necessária Se a solicitação de alteração tem como consequência alterações que sejam inaceitáveis pelos stakeholders Se o custo de implementação da alteração for muito alto ou demorar muito

38 Gerenciamento de Alterações de Requisitos Uma parte crítica do gerenciamento de alterações é a avaliação do impacto da mudança no resto do sistema Se a mudança é proposta enquanto os requisitos estão sendo desenvolvidos, deve ser identificado como a alteração afeta outros requisitos Se a alteração é proposta enquanto o sistema está em implementação, o impacto de alteração envolve verificar como a alteração afeta os requisitos, o design e implementação Se a alteração é proposta depois que o sistema foi colocado em operação, deve haver também uma verificação adicional a fim de identificar como todos os stakeholders podem ser afetados pela alteração

39 Técnicas principais: Análise de Custo Benefício Análise do Retorno Financeiro (Payback Analysis) Taxa Interna de Retorno (Intern Return Rate) Valor Presente Líquido (Net Present Value) Retorno do Investimento (Return On Investments)

40 Análise do Retorno Financeiro É o tempo decorrido entre o investimento inicial e o momento no qual o lucro líquido acumulado se iguala ao valor desse investimento Tipos: Nominal, se calculado com base no fluxo de caixa com valores nominais Presente Líquido, se calculado com base no fluxo de caixa com valores trazidos ao valor presente líquido

41 Taxa necessária para igualar o valor de um investimento com os seus respectivos retornos futuros ou saldos de caixa Sendo usada em análise de investimentos significa a taxa de retorno de um projeto, que pode ser: Taxa Interna de Retorno Maior do que a Taxa Mínima de Atratividade: significa que o investimento é economicamente atrativo Igual à Taxa Mínima de Atratividade: o investimento está economicamente numa situação de indiferença Menor do que a Taxa Mínima de Atratividade: o investimento não é economicamente atrativo pois seu retorno é superado pelo retorno de um investimento com o mínimo de retorno

42 Valor Presente Líquido A soma algébrica dos valores descontados do fluxo de caixa a ele associado A diferença do valor presente das receitas menos o valor presente dos custos: O projeto que apresenta o VPL maior que zero é economicamente viável Sendo considerado o melhor aquele que apresentar maior VPL

43 Análise de Retorno do Investimento Comparar os benefícios das diferentes soluções ou projetos É a taxa percentual que mede a relação entre a quantia que a empresa obtém de retorno ao seu investimento e a quantia investida Solução que oferecer o ROI mais alto é a melhor alternativa: ROI = (Benefícios totais - Custos totais) / Custos totais

44 Documento de Viabilidade Após o esforço inicial, discutido anteriormente, deve-se elaborar um relatório de viabilidade: Para cada aspecto apresentado, deve haver seção de avaliação Deve haver uma seção conclusiva sobre a melhor alternativa ou que o sistema não é viável

45 5 Elementos da Mudança Visão Habilidades Incentivos Recursos Plano de Ação Mudança Habilidades Incentivos Recursos Plano de Ação Confusão Visão Incentivos Recursos Plano de Ação Ansiedade Visão Habilidades Recursos Plano de Ação Mudança Gradual Visão Habilidades Incentivos Plano de Ação Frustração Visão Habilidades Incentivos Recursos Falsos Inícios

46 Mudanças em Software Mudanças em software são inevitáveis: Novos requisitos surgem enquanto o software é usado O ambiente de negócios se altera Erros precisam ser consertados Novos equipamentos precisam ser acomodados O desempenho ou confiabilidade precisam ser melhorados

47 Manutenção do software Mudanças são feitas em resposta a mudanças nos requisitos mas a estrutura fundamental do software está estável Transformação de arquitetura A arquitetura do sistema é modificada, p.e., de uma arquitetura centralizada para uma arquitetura clienteservidor Reengenharia de software Nenhuma funcionalidade é adicionada mas o sistema é reestruturado e reorganizado para facilitar futuras mudanças Estas estratégias podem ser aplicadas juntas ou separadamente Estratégias de Mudanças

48 Manutenção de Software Manutenção é o processo de modificação de um software depois que ele foi colocado em operação Mudanças são implementadas pela alteração dos componentes existentes ou pela adição de novos componentes

49 Tipos de Manutenção Para reparar defeitos: o software não satisfaz os requisitos Para adaptar o software a um ambiente operacional diferente: hardware, SO diferentes em relação à implementação inicial Para fazer acréscimos de funcionalidades ou alterá-las: novos requisitos ou alteração nos existentes

50 Tipos de Manutenção Segundo Pressman, a manutenção pode ser: Corretiva: corrigir defeitos Adaptativa: acomodar mudanças no ambiente externo Perfectiva: aprimorar o software além dos requisitos funcionais originais Preventiva: alterações visando tornar o software mais manutenível Segundo Sommerville: Os rótulos não interessam

51 Custo de Manutenção Quanto maior o esforço empregado para tornar o software manutenível, menor o custo de manutenção

52 Fatores do Custo de Manutenção Instabilidade da Equipe: quem faz manutenção geralmente não é a mesma equipe que desenvolveu Responsabilidade Contratual: por que se preocupar com a manutenção se o software já foi vendido? (não há incentivo para tornar manutenível) Idade do Programa: quanto mais velho mais degradada sua estrutura e difícil de ser entendida

53 Problemas Relacionados à Manutenção Dificuldade de Entendimento: é difícil entender o que outro programou (47% do tempo gasto para entender) Ânimo da Equipe: é mais animador desenvolver do que consertar Riscos Associados as Alterações: uma mudança pode causar reflexos inesperados em outra parte do programa Dificuldade em Testar: nem sempre há tempo para testar, pois o software já está em operação

54 Processo de Manutenção Processo Ideal: Pedido de Alteração Análise do Impacto Planejamento da Alteração Alteração na Documentação Implementação da Alteração Teste do Sistema Entrega do Sistema

55 Processo de Manutenção Processo real: Pedido de Alteração Implementação da Alteração Entrega

56 Gerenciamento de Configuração Durante o processo de manutenção são criadas muitas versões do software Configuração: relação entre versões de um objeto composto, ou seja, configuração é uma instância do sistema composta da união de uma versão específica de cada objeto componente Gerenciamento das diversas versões de cada componente do software é chamada de Gerenciamento de Configuração

57 Dúvidas? Agradecimentos Home Page Blog X25 Home Page Fernando Anselmo