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 [email protected]@x25.com.br
Top Related