Engenharia de Software Vítor Vargas Robaina

Apresentação em tema: "Engenharia de Software Vítor Vargas Robaina"— Transcrição da apresentação:

1 Engenharia de Software Vítor Vargas Robaina

2 Ambiente de Desenvolvimento de Software
um processo, métodos e a automação necessária para produzir um sistema de software (Charette) um sistema que fornece suporte a qualquer tipo de atividade executada por engenheiros de software (Saito) um ciclo de vida, que define as etapas do processo de desenvolvimento um conjunto de métodos usados para organizar o pensamento e o trabalho do usuário um conjunto de ferramentas que automatizam os instrumentos.

3 Ciclo de Vida diferentes modelos não existe o melhor modelo
escolha depende: do domínio da aplicação das características do grupo desenvolvedor do grau de conhecimento sobre o problema

4 Modelo Clássico (Cascata)
fases realizadas sequencialmente variações: número das fases nomes das fases

5 Prototipagem Evolutiva
Objetivo ter uma versão inicial através da qual se aumente o conhecimento sobre o produto Procedimento desenvolve-se uma versão parcial que atinge os requisitos conhecidos a partir do conhecimento sobre os requisitos, obtido com o uso do protótipo, continua-se o desenvolvimento (evolue-se) o produto

6 Ciclo de Vida em Espiral
Objetivo permitir definir processos de desenvolvimento, guiado pelos riscos dos projetos É um meta-modelo pode acomodar qualquer processo de desenvolvimento (por exemplo: espiral + cascata)

7 Métodos “prescrições explícitas para a realização de uma atividade ou conjunto de atividades do modelo de ciclo de vida” (Charette) Devem estabelecer: que passos seguir como tomar as decisões envolvidas nestes passos

8 Seleção de Métodos Nenhum método é adequado sempre
A seleção de métodos deve levar em consideração: a adequação à tecnologia de desenvolvimento a cultura da organização os conhecimentos prévios e as preferências da equipe de desenvolvimento a facilidade de aprendizado a facilidade de integração com outros métodos a existência de ferramentas que automatizem o método

9 Métodos de Desenvolvimento de Software são efetivos apenas na medida em que auxiliam a comunicação entre pessoas. Se a utilização de um método de Engenharia de Software produz um monumento de papel, então, alguma coisa está errada no método, na aplicação ou em ambos. Se perdermos em visão das pessoas e comerçarmos a produzir gráficos, diagramas e pilhas de papel como um fim em si mesmo, então falhamos numa comunicação efetiva. Engenharia de Software é uma questão relacionada a pessoas. Pessoas tem problemas e pessoas resolvem problemas. E nós só podemos resolver problemas de desenvolvimento de sistemas, interagindo uns com os outros. Logo, métodos de desenvolvimento de software viáveis devem facilitar a comunicação. (Coad-Yourdon)

10 Proposta de Desenvolvimento
OBJETIVOS reunir dados iniciais sobre o produto a ser construído permitir estabelecer o contrato para desenvolvimento do produto A Proposta de Desenvolvimento deve conter: uma descrição do sistema atual e suas deficiências uma descrição do sistema a ser desenvolvido dados que permitam avaliar a viabilidade de construção e operação do sistema proposto

11 A Proposta de Desenvolvimento deve ser:
macroscópica fidedigna imparcial realista viável

12 Conteúdo da Proposta de Desenvolvimento
Descrição do Sistema Atual Objetivos servir de base para o entendimento do funcionamento do sistema atual proporcionar uma primeira justificativa da necessidade do novo sistema indicar os problemas organizacionais existentes indicar a urgência com que o novo sistema deverá ser posto em operação

13 Conteúdo da Proposta de Desenvolvimento
Descrição do Sistema Proposto Objetivos permitir o entendimento do sistema proposto avaliar o impacto do sistema sobre a organização do usuário, os benefícios esperados e a expectativa de vida do sistema proposto Objetivos permitir avaliar o esboço do Plano do Projeto avaliar se é possível constituir uma equipe capaz de desenvolver o sistema proposto Viabilidade de Implementação

14 o risco de fracasso é grande
Sem o esboço do Plano do Projeto não se pode discutir a viabilidade de implementação do sistema Se a equipe de desenvolvimento não domina o ambiente de desenvolvimento utilizado o domínio da aplicação o risco de fracasso é grande

15 Conteúdo da Proposta de Desenvolvimento
Relação do Sistema com o Ambiente Objetivos permitir avaliar a conveniência de desenvolver o sistema proposto ou adaptar um sistema existente permitir avaliar a interação do sistema proposto com outros sistemas da organização permitir estimar os benefícios do sistema proposto

16 Avaliação da Proposta de Desenvolvimento
deve ser realizada em conjunto por usuários e desenvolvedores o documento final deve conter: o texto da Proposta de Desenvolvimento o laudo da avaliação

17 Análise de Requisitos

18 ESPECIFICAÇÃO DE REQUISITOS produto da fase ANÁLISE DE REQUISITOS DE SOFTWARE
A fase de Análise de Requisitos começa quando: se reconhece que existe um problema que necessita de uma solução surge uma idéia nova e termina quando se tem uma descrição completa do comportamento do software a ser construído

19 O que são especificações?
representações que descrevem o software desde uma visão macroscópica (Especificação de Requisitos) até uma visão detalhada (Programas) passando por representações intermediárias (Especificações de Projeto)

20 O que são requisitos? alguma coisa necessária, desejada
Webster’s Ninth New Collegiate Dictionary condição ou capacidade necessária por um usuário para resolver um problema ou atingir um objetivo condição ou capacidade que precisa ser atingida por um sistema para satisfazer um contrato, norma, especificação ou algum outro documento IEEE Standard

21 Funções da Especificação de Requisitos
ser a base para o desenvolvimento permitir o controle da qualidade do produto estabelecer a comunicação entre o pessoal envolvido no projeto auxiliar no entendimento do problema

22 Durante a fase de Análise de Requisitos são realizadas três atividades:
Identificação do Problema Especificação do Produto Avaliação da Especificação

23 Identificação do Problema
Realizada através de: Brainstorm Entrevistas JAD Problemas: comunicação com o usuário entendimento completo do problema organização das informações

24 Especificação do Produto
Momento de: organizar idéias resolver visões conflitantes eliminar inconsistências eliminar ambiguidades Problemas: seleção do método adequado seleção de ferramentas

25 Avaliação da Especificação
Momento de: comparar a Especificação com os padrões de qualidade previamente estabelecidos Problemas: inexistência de padrões como realizar as avaliações

26 Importância da Especificação de Requisitos
São cometidos muitos erros na fase de Análise de Requisitos Erros permanecem latentes e tardam a ser detectados Quanto mais tarde um erro é detectado maior é o custo de sua correção 75% dos erros detectados, o são depois das fases de codificação e teste de unidades 45% destes erros são erros de especificação e projeto 9% são erros de codificação 56% de todos os erros detectados são devido a erros na fase de Análise de Requisitos

27 Erros Típicos 49% fatos incorretos 31% omissões 13% inconsistências
5% ambiguidades 2% localização errada do requisito

28 Impacto dos erros o software não satisfaz as necessidades dos usuários
desentendimento entre usuários e desenvolvedores perda de tempo e dinheiro problemas judiciários

29 Roteiro para a Especificação de Requisitos
varia com: o projeto a tecnologia adotada no desenvolvimento

30 Gerência de Projetos

31 GERÊNCIA Planejamento Acompanhamento

32 ? OU

33 Planejamento de Projetos

34 Por que planejar? evitar o fracasso
prever custos, recursos, prazos e riscos analisar alternativas organizar preparar-se para alterações poder acompanhar o andamento do projeto planejar melhor da próxima vez

35 Quando planejar o planejamento começa de forma macroscópica no início do projeto o planejamento é revisto e detalhado ao longo do projeto

36 O que planejar CRONOGRAMA DOCUMENTAÇÃO PROCESSO CUSTO PESSOAS
Click to add sub-title CRONOGRAMA DOCUMENTAÇÃO PROCESSO CUSTO PESSOAS CONTROLE DA QUALIDADE HARDWARE E SOFTWARE RISCOS

37 Plano do Projeto

38 Plano do Projeto Conteúdo 1. Sumário 2. Resumo do Projeto 3. Visão Geral do Plano do Projeto 4. Plano do Processo de Desenvolvimento 5. Plano de Organização 6. Plano de Documentação 7. Plano de Controle da Qualidade 8. Plano de Recursos e Produtos 9. Plano de Treinamento 10. Plano de Implantação e Operação 11. Glossário

39 Plano do Processo de Desenvolvimento
Plano do Projeto Plano do Processo de Desenvolvimento Ciclo de Vida do Projeto Métodos de Desenvolvimento Ambiente de Programação Ambiente de Hardware para Desenvolvimento

40 A qualidade do produto depende da qualidade e adequação do processo de desenvolvimento

41 Plano de Organização Equipe de Gerência Equipe de Desenvolvimento
Plano do Projeto Plano de Organização Equipe de Gerência Equipe de Desenvolvimento Equipe de Controle da Qualidade Assessorias

42 Plano de Documentação Especificação de Requisitos
Plano do Projeto Plano de Documentação Especificação de Requisitos Especificação de Projeto Relatório Histórico do Projeto Formulários para Reunião de Inspeção Documentação de Programas Manual do Usuário ...

43 Importância da Documentação
o software existe primeiro sob a forma de documentos a qualidade do produto final vai depender da qualidade destes documentos documentos são a forma de comunicação entre os diferentes grupos envolvidos com o produto

44 Planejamento da Documentação
definição da documentação adequada a um determinado projeto depende: do porte do projeto de sua expectativa de vida dos métodos e ferramentas utilizados durante o desenvolvimento

45 Plano de Documentação Deve definir que documentos devem ser gerados
em que momento devem ser gerados o roteiro para elaboração do documento responsabilidades destinatários ferramentas de apoio

46 Plano de Controle da Qualidade
Plano do Projeto Plano de Controle da Qualidade Controle da Qualidade ao longo do Desenvolvimento Avaliação do Produto Final Plano de Testes

47 Deve-se planejar as ações necessárias para atingir os requisitos de qualidade definidos:
que critérios devem controlar as características de qualidade de interesse como e quando os dados necessários devem ser coletados que métodos, técnicas e ferramentas serão utilizados

48 Plano de Recursos e Produtos
Plano do Projeto Plano de Recursos e Produtos Recursos Humanos Recursos de Hardware Recursos de Software Recursos Financeiros Análise de Riscos Cronograma Produtos

49 Estimativas TEMPO RECURSOS PESSOAS DINHEIRO

50 Recursos Humanos No desenvolvimento de software o principal custo é com pessoal estimar custo = estimar pessoas inicialmente define-se as características desejáveis para o pessoal após estimar-se o esforço de desenvolvimento, estima-se o número de pessoas

51 Gerência de Riscos

52 Analisar e Gerenciar riscos com relação a: pessoal
Blá,Blá,Blá... Analisar e Gerenciar riscos com relação a: pessoal recursos

53 AVALIAÇÃO DA VIABILIDADE DO PROJETO
ESPECIFICAÇÃO DE REQUISITOS PLANO DO PROJETO AVALIAÇÃO DA VIABILIDADE DO PROJETO SOCIAL TECNOLÓGICA PESSOAL FINANCEIRA TEMPO ECONÔMICA.