Levantamento, Análise e GestãoRequisitos

Aula 11

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

Agenda

Problema de Projetos Cancelados

Managing Software Requirements:

A Use Case Approach, Second Edition, 2003

31% dos projetos são cancelados antes de serem completados

52,7% dos projetos custam 189% de sua estimativa inicial

Causas ?

Situação Desenvolvimento de Software

Causas mais importantesFalta de comunicação do usuário - 13%

Requisitos /Especificações incompletas - 12%

Requisitos /Especificações que mudam - 12%

Projetos que Falham

● Realizados no prazo e no custo estimados• Grandes empresas: 9%• Pequenas empresas: 16%

Três fatores de sucesso mais importantesEnvolvimento do usuário - 16%

Suporte Gerencial do alto executivo - 14%

Requisitos definidos de forma clara - 12%

Projetos de Sucesso

1980 – Codificação

Code – Centric

• Linguagens: Pascal, C, Basic, Cobol...• Monolítico

1985 – Dados

Database – Centric

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

1990 – Produtividade

GUI – Centric

• Cliente - Servidor• Rapid Aplication Developer• Visual Basic e Delphi

1995 – Performance

Object – Centric (volta a 1966)

• Computação Distribuída• Escalabilidade

2000 – Controle

Process – Centric

• Processo Unificado• UML – Unified Model Language

2005 – Distribuição

Multi – Centric

• Processo Distribuído na WEB• Processo Colaborativo• Redes Sociais: Facebok, Twitter, Linkedin,...• Linguagens WEB: ASP, JSP, PHP,...

2010 – Mobilidade

Mobile – Centric

• Aplicativos móveis• Nascimento do e-Readers• Nascimento do iPhone• Nascimento do Tablets• Nascimento do Android

2015 – Interatividade

Interactive – Centric

• Aplicativos na Nuvem• Pesquisas Inteligentes• Escritório em qualquer lugar• Programação Interativa: TV

Conjunto de problemas encontrados no desenvolvimento de software:

(1) As estimativas de prazo e de custo frequentemente As estimativas de prazo e de custo frequentemente são imprecisassã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”

Crise de Software

(2) A produtividade das pessoas da área de software A produtividade das pessoas da área de software não tem acompanhado a demanda por seus não tem acompanhado a demanda por seus serviçosserviços“Os projetos de desenvolvimento de software

normalmente são efetuados apenas com um vago indício das exigências do cliente”

Crise de Software

(3) A qualidade de software às vezes é menos que A qualidade de software às vezes é menos que adequadaadequada

Só recentemente começam a surgir conceitos quantitativos sólidos de garantia de qualidade de software

(4) O software existente é muito difícil de manterO software existente é muito difícil de manterA tarefa de manutenção devora o orçamento destinado ao softwareA facilidade de manutenção não foi enfatizada como um critério importante

Crise de Software

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

Testes

Manutenção

Visão essencial quando o software deve fazer

interface com outros elementos (hardware,

pessoas e banco de dados)

Atividades do Ciclo de Vida Clássico

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

Os requisitos (para o sistema e para o software) são

documentados e revistos com o cliente

Engenharia de Sistemas Análise de

Requisitos Projeto

Codificação

Testes

Manutenção

Atividades do Ciclo de Vida Clássico

Tradução dos requisitos do software para um conjunto de representações que podem ser avaliadas quanto à

qualidade, antes que a codificação se inicieSe concentra em 4 atributos do programa:

Estrutura de DadosArquitetura de Software

Detalhes Procedimentais Caracterização de

Interfaces

Engenharia de Sistemas Análise de

Requisitos Projeto

Codificação

Testes

Manutenção

Atividades do Ciclo de Vida Clássico

Tradução das representações do projeto para uma linguagem

“artificial” resultando em instruções executáveis pelo

computadorEngenharia de Sistemas Análise de

Requisitos Projeto

Codificação

Testes

Manutenção

Atividades do Ciclo de Vida Clássico

Concentram-se:Nos aspectos lógicos internos do software, garante que

todas as instruções tenham sido verificadasNos aspectos funcionais externos, para descobrir erros e garantir que

a entrada definida produza resultados que concordem

com os esperados

Engenharia de Sistemas Análise de

Requisitos Projeto

Codificação

Testes

Manutenção

Atividades do Ciclo de Vida Clássico

O software pode sofrer mudanças depois que for entregue ao cliente

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

Engenharia de Sistemas Análise de

Requisitos Projeto

Codificação

Testes

Manutenção

Atividades do Ciclo de Vida Clássico

Documentação em Projetos

● Dado nosso conhecimento técnico, os prazos dos projetos são razoáveis?● 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

Viabilidade do Cronograma

Viabilidade do Cronograma

● Talvez a mais crítica● Julgar se os possíveis benefícios de solucionar o problema são ou não vantajosos

● 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

Viabilidade Econômica

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

Pessoal

Tipos de Custos

Estudo de Caso – Definição dos Requisitos

* Quero algo para atravessar a cidade no menor tempo possível

* Mas não quero me molhar! Como vou carregar minha pasta?

Estudo de Caso – Mudança nos Requisitos

Estudo de Caso – Retrabalho

Estudo de Caso – Entrega do Sistema

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íciosEsta avaliação é denominada de Análise de Impacto da Mudança

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

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

RequisitosRevisados

ProblemaIdentificado

Análise do problema e

Especificação da alteração

(1)

Análise e Avaliação de

Custo da Solução

(2)

Implementaçãoda alteração

(3)

Gerenciamento de Alterações de Requisitos

Análise e Avaliação do Custo da Soluçã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

Análise e Avaliação da Alteração

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

Gerenciamento de Alterações de Requisitos

● Técnicas principais:● 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)

Análise de Custo Benefício

● É 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

Análise do Retorno Financeiro

● 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:

● 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

Taxa Interna de Retorno

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

● 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

Análise de Retorno do Investimento

● 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

Documento de Viabilidade

Plano de AçãoVisão Habilidades Incentivos Recursos Mudança

Plano de AçãoHabilidades Incentivos Recursos Confusão

Plano de AçãoVisão Incentivos Recursos Ansiedade

Plano de AçãoVisão Habilidades Recursos MudançaGradual

Plano de AçãoVisão Habilidades Incentivos Frustração

Visão Habilidades Incentivos Recursos FalsosInícios

5 Elementos da Mudança

● 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

Mudanças em Software

● 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 cliente-servidor

● 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

● 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

Manutenção de Software

● 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

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

Tipos de Manutenção

● Quanto maior o esforço empregado para tornar o software “manutenível”, menor o custo de manutenção

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

Fatores do Custo de 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

Problemas Relacionados à Manutenção

● Processo Ideal:

Pedido de Alteração

Análise do Impacto

Planejamentoda Alteração

Implementação da Alteração

Entrega doSistema

Teste do Sistema

Alteração na Documentação

Processo de Manutenção

● Processo real:

Pedido deAlteração

Implementaçãoda Alteração Entrega

Processo de Manutençã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”

Gerenciamento de Configuração

Dúvidas? AgradecimentosDúvidas? Agradecimentos

Home PageHome Pagehttp://fernandoans.site50.nethttp://fernandoans.site50.net

BlogBloghttp://fernandoanselmo.blogspot.comhttp://fernandoanselmo.blogspot.com

X25 Home PageX25 Home Pagehttp://www.x25.com.brhttp://www.x25.com.br

Fernando AnselmoFernando Anselmofernando.anselmo@x25.com.brfernando.anselmo@x25.com.br