Upload
maria-luiza-antas-gusmao
View
213
Download
0
Embed Size (px)
Citation preview
©Jaelson Castro 2000 Engenharia de Sofware, Capítulo 1 Slide 1
Engenharia de Software
Projetando, construindo e mantendo grande sistemas de software
©Jaelson Castro 2000 Engenharia de Sofware, Capítulo 1 Slide 2
Objetivos Definir a engenharia de software e explicar sua
importância Discutir o conceito de produto de software e
processo de software Explicar a importância da visibilidade do
processo Introduzir a noção de responsabilidade
profissional.
©Jaelson Castro 2000 Engenharia de Sofware, Capítulo 1 Slide 3
Tópicos Produtos de software Processo de software Modelo espiral de Boehm Visibilidade do processo Responsabilidade profissional
©Jaelson Castro 2000 Engenharia de Sofware, Capítulo 1 Slide 4
A economia de todos os países depende de software Cada vez mais sistemas são controlados por software A engenharia de software inclui teorias, métodos e
ferramentas para o desenvolvimento profissional de software
O gasto em desenvolvimento de software representa uma fração significativa do PIB de muitos países.
Engenharia de Software
©Jaelson Castro 2000 Engenharia de Sofware, Capítulo 1 Slide 5
Custo do software geralmente domina o custo do desenvolvimento. Os custos do software de um PC são geralmente maiores do que do hardware;
Software custa mais para manter do que para desenvolver. Para sistemas com uma longa vida, os custos de manutenção são várias vezes maiores do que o de desenvolvimento;
Engenharia de Software trata do desenvolvimento de software de forma eficaz;
Custo do Software
©Jaelson Castro 2000 Engenharia de Sofware, Capítulo 1 Slide 6
Produto de Software Produtos genéricos
• Sistemas que são produzidos pelo desenvolvimento de uma organização e vendidos no mercado para qualquer cliente
Produtos customizados• Sistemas que são encomendados por um cliente e desenvolvidos
especialmente para ele
O maior gasto de software é em produtos genéricos, mas o maior esforço de desenvolvimento está nos produtos customizados.
©Jaelson Castro 2000 Engenharia de Sofware, Capítulo 1 Slide 7
Atributos dos Produtos de Software
Manutenabilidade• Deve ser possível para o software evoluir de forma a atender
requisitos que mudam
Dependenbilidade• Software não deve causar prejuízo físico ou econômico no caso de
uma falha.
Eficiência• Software não deve desperdiçar recursos do sistema
Usabilidade• O software deve ter uma interface com o usuário adequada e ser
documentado
©Jaelson Castro 2000 Engenharia de Sofware, Capítulo 1 Slide 8
Importância das Características do Produto
A importância relativa destas características depende do produto e do ambiente em que ele será usado
Em alguns casos, alguns dos atributos podem ser mais importantes• Em sistemas de segurança-críticos de tempo-real, os atributos-
chave podem ser dependenbilidade e eficiência
Os custos tendem a aumentar exponencialmente se altos níveis de um atributo são necessários
©Jaelson Castro 2000 Engenharia de Sofware, Capítulo 1 Slide 9
Custos da EficiênciaCost
Efficiency
©Jaelson Castro 2000 Engenharia de Sofware, Capítulo 1 Slide 10
O Processo de Software Um conjunto estruturado de atividades necessárias
para o desenvolvimento de um sistema de software • Especificação• Projeto• Validação• Evolução
As atividades variam de acordo com a organização e o tipo de sistema sendo desenvolvido
Deve ser modelado explicitamente se o processo precisa ser gerenciado
©Jaelson Castro 2000 Engenharia de Sofware, Capítulo 1 Slide 11
Características do Processo Entendível
• O processo está definido e bem entendido?
Visibilidade• O progresso do processo está externamente visível?
Suportabilidade• O processo pode ser apoiado por ferramentas CASE?
Aceitabilidade• O processo é aceito pelas pessoas envolvidas nele?
©Jaelson Castro 2000 Engenharia de Sofware, Capítulo 1 Slide 12
Características do Processo Confiabilidade
• Os erros no processo são descobertos antes deles resultarem em erros no produto
Robustez• O processo pode continuar mesmo com problemas não esperados
Manutenabilidade• O processo pode evoluir de forma a exigir necessidades
organizacionais que evoluem
Rapidez• Com que rapidez pode o sistema ser produzido
©Jaelson Castro 2000 Engenharia de Sofware, Capítulo 1 Slide 13
Modelo do Processo em Engenharia (Qualquer)
Especificação - define os requisitos e limitações do sistema
Projeto - Produz um modelo em papel do sistema Manufatura - construção do sistema Teste - verifica se o sistema satisfaz a especificação Instalação - entrega o sistema ao usuário e garante sua
operacionalidade Manutenção - repara falhas no sistema quando elas
são descobertas
©Jaelson Castro 2000 Engenharia de Sofware, Capítulo 1 Slide 14
Modelos do Processo de Software
Normalmente, especificações são incompletas/ anômalas
Distinção sutil entre especificação, projeto e manufatura
Software não se gasta - manutenção não significa troca de componente
©Jaelson Castro 2000 Engenharia de Sofware, Capítulo 1 Slide 15
Modelos de Processo de Software Genérico
O modelo cascata (waterfall model)• Fases distintas e separadas para especificação e desenvolvimento
Desenvolvimento evolucionário• Especificação e desenvolvimento são intercalados
Transformação formal• Um modelo matemático formal do sistemas é transformado
formalmente em uma implementação
Desenvolvimento baseado em reuso• O sistema é montado a partir de componentes existentes
©Jaelson Castro 2000 Engenharia de Sofware, Capítulo 1 Slide 16
Modelos de Processo de Software Genérico
Modelo Híbrido• O sistema é particionado em subsistemas menores, onde as
partes podem ser desenvolvidas com quaisquer dos modelos. Deve-se considerar o que seja mais apropriado a cada subsistema.
Modelo Espiral• Segue uma espiral. Apresenta quatro grandes fases bem
definidas, que vão sendo executadas a medida em que se caminha em um ciclo da espiral.
©Jaelson Castro 2000 Engenharia de Sofware, Capítulo 1 Slide 17
Modelo Cascata
©Jaelson Castro 2000 Engenharia de Sofware, Capítulo 1 Slide 18
Fases do modelo Cascata Análise e definição de requisitos Projeto de software e sistema Implementação e testes de unidades Integração e teste de sistema Operação e manutenção A desvantagem do modelo cascata é a dificuldade
de acomodar mudanças depois que o processo está em andamento
©Jaelson Castro 2000 Engenharia de Sofware, Capítulo 1 Slide 19
Desenvolvimento Evolucionário
Versão Final
Versão Inicial
Descrição dos Esquemas
Atividades Concorrentes
Versões Intermediárias
Especificação
Validação
Desenvolvimento
©Jaelson Castro 2000 Engenharia de Sofware, Capítulo 1 Slide 20
Desenvolvimento Evolucionário Programação exploratória
• O Objetivo é trabalhar com os clientes e evoluir para um sistemas final a partir de uma vaga especificação inicial. Deveria começar com requisitos bem entendidos.
Prototipagem descartável• O objetivo é entender os objetivos do sistema. Deveria
começar com requisitos vagamente entendidos.
©Jaelson Castro 2000 Engenharia de Sofware, Capítulo 1 Slide 21
Desenvolvimento Evolucionário Problemas
• Falta de visibilidade do processo• Sistemas ficam geralmente mal estruturados• Habilidades específicas (ex. linguagens para prototipagem
rápida) pode ser necessária
Aplicabilidade• Para sistemas interativos de pequeno ou médio porte • Para partes de um grande sistema (ex. a interface do usuário)• Para sistemas de vida curta
©Jaelson Castro 2000 Engenharia de Sofware, Capítulo 1 Slide 22
Modelo de Transformação Formal (Refinamento)
Idéia geral:• Uma especificação formal (definição
matemática, não ambígua) do software é desenvolvida e posteriormente transformada em um programa através de regras que preservam a corretude da especificação (passos de refinamento).
• Graficamente:
Esp. 2Esp. 1 Implement.
©Jaelson Castro 2000 Engenharia de Sofware, Capítulo 1 Slide 23
Modelo de Processo Híbrido Sistemas grandes são normalmente feitos com
vários sub-sistemas Não é necessário usar o mesmo modelo de
processo para todos os sub-sistemas Prototipagem para especificações de alto risco Modelo Cascata para desenvolvimento de partes
bem entendidas
©Jaelson Castro 2000 Engenharia de Sofware, Capítulo 1 Slide 24
Modelo Espiral para o Processo de Software
Avaliação de Alternativas, Identificação e Resolução de Riscos
Determinação de Objetivos, Alternativas e Limitações
Fase do Próximo Planejamento
Desenvolvimento e Validação do Produto do Próximo Nível
©Jaelson Castro 2000 Engenharia de Sofware, Capítulo 1 Slide 25
Fases do Modelo Espiral Definição dos objetivos
• Objetivos específicos para a fase do projeto são identificados
Avaliação e redução do risco• Os riscos principais são identificados, analisados e busca-se
informações para reduzir estes riscos
Desenvolvimento e validação• Escolha de um modelo apropriado para a fase do desenvolvimento
Planejamento• O projeto é revisto e planos são feitos para o próximo passo da
espiral
©Jaelson Castro 2000 Engenharia de Sofware, Capítulo 1 Slide 26
Formulário Padrão para uma volta da espiral
Objetivos Limitações Alternativas Riscos Resolução do risco Resultados Planos Compromisso
©Jaelson Castro 2000 Engenharia de Sofware, Capítulo 1 Slide 27
Gerenciamento de Riscos Talvez a tarefa principal de um gerente seja a
minimização de riscos O risco inerente de uma atividade é a medida da
incerteza do resultado desta atividade Atividades de alto risco causam atrasos e gastos
extras O risco está associado com a quantidade de
informação disponível. Quanto menor a informação, maior o risco.
©Jaelson Castro 2000 Engenharia de Sofware, Capítulo 1 Slide 28
Ex: Melhoria da Qualidade Objetivos
• Melhoria significativa da qualidade do software.
Limitações• No prazo de três anos;• Sem grande investimento de capital;• Sem mudanças radicais nos padrões da companhia .
Alternativas• Reuso de software existente certificado;• Introduzir especificação e verificação formal;• Investir em ferramentas de teste e validação.
©Jaelson Castro 2000 Engenharia de Sofware, Capítulo 1 Slide 29
Riscos• Não ser possível alcançar uma melhoria de qualidade com custo
apropriado; • Melhoria de qualidade poder aumentar o custo de forma excessiva;
• Novos métodos podem causar a saída de funcionários. Resolução de risco
• Pesquisa na literatura existente;• Projeto piloto;• Levantamento de componentes potencialmente reutilizáveis;• Avaliação das ferramentas de suporte disponíveis;• Treinamento de funcionários e seminários de motivação.
Ex: Melhoria da Qualidade (cont)
©Jaelson Castro 2000 Engenharia de Sofware, Capítulo 1 Slide 30
Resultados• Experiência com métodos formais é limitada - muito difícil de
quantificar melhorias;• Pouca disponibilidade de ferramentas de suporte para os padrões
de desenvolvimento da empresa;• Disponibilidade de componentes para reuso, porém poucas
ferramentas para suportar a reutilização. Planejamento
• Explorar em mais detalhes a opção de reuso;• Desenvolver protótipos de ferramentas de suporte de reuso;• Explorar o esquema de certificação de componentes.
Compromisso• Patrocinar uma fase de estudo com duração de 18 meses.
Ex: Melhoria da Qualidade (cont)
©Jaelson Castro 2000 Engenharia de Sofware, Capítulo 1 Slide 31
Ex.: Catálogo de Componentes Objetivo
• Obter um catálogo de componentes de software
Limitações• Dentro de uma ano;• Deve suportar os tipos de componentes existentes;• Custo total menor que R$ 100. 000,00.
Alternativas• Comprar um software existente para recuperação de informação;• Comprar um banco de dados e desenvolver um catálogo usando
o banco de dados;• Desenvolver um catálogo de propósito especial.
©Jaelson Castro 2000 Engenharia de Sofware, Capítulo 1 Slide 32
Riscos• Pode ser impossível obtê-lo de acordo com as limitações
impostas;• A funcionalidade do catálogo pode ser inapropriada.
Resolução do risco• Desenvolver um catálogo de um protótipo (usando L4G e
SGBD existente) para clarificar requisitos;• Contratar consultores para relatar as capacidades atuais dos
sistemas de recuperação de informação;• Relaxar as limitações de prazo.
Ex.: Catálogo de Componentes (cont)
©Jaelson Castro 2000 Engenharia de Sofware, Capítulo 1 Slide 33
Resultados• Sistemas de recuperação de informação são inflexíveis;• Requisitos identificados não podem ser alcançados;• Protótipo utilizando o SGBD pode ser estendido para completar
o sistema;• O desenvolvimento de uma catálogo de propósito especial
pode ser muito caro. Planos
• Desenvolver o catálogo utilizando SGBD existente , estendendo o protótipo e melhorando a interface com o usuário.
Compromisso• Patrocinar mais 12 meses de desenvolvimento.
Ex.: Catálogo de Componentes (cont)
©Jaelson Castro 2000 Engenharia de Sofware, Capítulo 1 Slide 34
Flexibilidade do Modelo Espiral Sistemas bem entendidos (baixo risco técnico) -
modelo cascata. A fase de análise de risco é relativamente barata.
Requisitos estáveis e especificação formal. Segurança crítica - Modelo de transformação formal
Risco alto de IU, especificação incompleta - modelo de prototipagem
Modelo híbrido acomodado para diferentes partes do projeto.
©Jaelson Castro 2000 Engenharia de Sofware, Capítulo 1 Slide 35
Vantagens do Modelo Espiral Foca atenção nas opções de reuso Foca atenção em eliminação cedo de erros Qualidade desde o início Integra desenvolvimento e manutenção
©Jaelson Castro 2000 Engenharia de Sofware, Capítulo 1 Slide 36
Problemas do Modelo Espiral Contrato de desenvolvimento geralmente já
especifica o modelo de processo e produtos (deliverables)
Requer experiência em avaliação de risco Precisa de refinamento para ser usado
©Jaelson Castro 2000 Engenharia de Sofware, Capítulo 1 Slide 37
Os Risco do Modelo de Processo Cascata
• Alto risco para novos sistemas devido a problemas de especificação e de projeto
• Baixo risco para desenvolvimento bem entendido que usa tecnologia conhecida
Prototipagem• Baixo risco para novas aplicações pois especificação e programa ficam
em compasso • Alto risco devido à falta de visibilidade do processo
Transformacional• Alto risco devido à necessidade de tecnologia avançada e habilidade da
equipe
©Jaelson Castro 2000 Engenharia de Sofware, Capítulo 1 Slide 38
Visibilidade do Processo Sistemas de software são intangíveis, assim gerentes
precisam de documentos para avaliar o progresso Contudo, isto pode causar problemas
• Prazo para os produtos de acompanhamento pode não ser adequado para o tempo necessário para completar a atividade
• A necessidade de produzir documentos limita a iteração do processo • O tempo que leva para revisão e aprovação de documentos é
significativo
Modelo cascata é ainda o mais usado para geração de documentos
©Jaelson Castro 2000 Engenharia de Sofware, Capítulo 1 Slide 39
Documentos do Modelo Cascata
Atividade Documentos de SaídaAnálise de Requisitos Estudo de viabilidade, Esboço dos RequisitosDefinição dos Requisitos Documento de Requisitos
Especificação do Sistema Especificação Funcional, Plano de Testes deAceitação, Esboço do Manual do Usuário
Projeto da Arquitetura Especificação da Arquitetura, Plano de Testes do SistemaProjeto da Interface Especificação da Interface, Plano de Teste de IntegraçãoProjeto Detalhado Especificação do Projeto, Plano de Teste da UnidadeCodificação Código do ProgramaTeste da Unidade Relatório de Teste da UnidadeTeste de Módulo Relatório de Teste de MóduloTeste de Integração Relatório de Teste de Integração, Manual Final do UsuárioTeste do Sistema Relatório de Teste do SistemaTeste de Aceitação Sistema Final e Documentação
©Jaelson Castro 2000 Engenharia de Sofware, Capítulo 1 Slide 40
Visibilidade do Modelo de Processo
Modelo de Processo Visibilidade do ProcessoModelo Cascata Visibilidade boa, cada atividade produz algum
Produto de saída
EvolucionárioVisibilidade pobre, não econômico para produzirdocumentos durante iteração rápida
FormalTransformação Visibilidade boa, documentos devem ser produzidos
a partir de cada fase para que o processo continueDesenvolvimento Orientado a Reuso
Visibilidade moderada, pode ser artificial para produzir documentos descrevendo reuso ecomponentes reusáveis.
Modelo Espiral Visibilidade boa, Cada segmento e cada anelda espiral pode produzir algum documento.
Desenvolvimento
©Jaelson Castro 2000 Engenharia de Sofware, Capítulo 1 Slide 41
Ética Confidencialidade Competência Direito de propriedade intelectual Mal uso do computador
©Jaelson Castro 2000 Engenharia de Sofware, Capítulo 1 Slide 42
Pontos principais A engenharia de software trata de teorias, métodos e
ferramentas para o desenvolvimento, gerenciamento e evolução de produtos de software
Produtos de software incluem programas e documentação. Atributos do produto: manutenabilidade, dependenbilidade, eficiência e usabilidade
O processo de software consiste naquelas atividades envolvidas no desenvolvimento de software
©Jaelson Castro 2000 Engenharia de Sofware, Capítulo 1 Slide 43
Pontos principais O modelo cascata considera cada atividade do
processo uma fase distinta; Desenvolvimento evolucionário considera as
atividades do processo de forma concorrente; O modelo de processo é baseado em riscos A visibilidade do processo envolve a criação de
produtos associados às atividades; Engenheiros de software têm responsabilidades
éticas e sociais;