©Jaelson Castro 2000Engenharia de Sofware, Capítulo 1 Slide 1 Engenharia de Software u Projetando, construindo e mantendo grande sistemas de software

©Jaelson Castro 2000 Engenharia de Sofware, Capítulo 1 Slide 1

Engenharia de Software

Projetando, construindo e mantendo grande sistemas de software


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.


Tópicos Produtos de software Processo de software Modelo espiral de Boehm Visibilidade do processo Responsabilidade profissional


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


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


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.


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


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


Custos da EficiênciaCost

Efficiency


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


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?


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


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


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


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


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.


Modelo Cascata


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


Desenvolvimento Evolucionário

Versão Final

Versão Inicial

Descrição dos Esquemas

Atividades Concorrentes

Versões Intermediárias

Especificação

Validação

Desenvolvimento


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.


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


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.


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


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


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


Formulário Padrão para uma volta da espiral

Objetivos Limitações Alternativas Riscos Resolução do risco Resultados Planos Compromisso


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.


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.


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)


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)


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.


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)


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)


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.


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


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


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


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


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


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


Ética Confidencialidade Competência Direito de propriedade intelectual Mal uso do computador


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


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;

Documents

©Jaelson Castro 2000Engenharia de Sofware, Capítulo 1 Slide 1 Engenharia de Software u Projetando, construindo e mantendo grande sistemas de software