Engenharia de Software: Definição, Características e Desafios

Prévia do material em texto

1
Engenharia de Software
Ulf Bergmann
ulf@ime.eb.br
Página: 
http://www.des.ime.eb.br/~ulf/engsw
? ? ?
??
?
Instruções 
(programas de 
computador) que 
quando executadas 
fornecem 
determinadas 
funcionalidades 
desejadas
Estruturas de dados 
que habilitam os 
programas a 
manipular 
corretamente as 
informações
Documentos que 
descrevem a operação 
e uso dos programas
O que é Software ?
Características do Software
¾Falhas 
tempo
T
ax
a 
de
 fa
lh
as
Hardware
tempo
T
ax
a 
de
 fa
lh
as
Software
mudança
Características do Software
¾Custo das mudanças
0
10
20
30
40
50
60
custo
Definição
Desenvolvimento
Manutenção
„ Foco no Cliente
„ Rentabilidade
„ Segmentação de Mercado
„ Competição global
„ Menor tempo para o Mercado
„ Organização Achatada
Razões de 
Negócios „ Requisitos Voláteis
„ Complexidade crescente
„ Reduções drásticas de custo
„ Entrega rápida de Sistemas
„ Atraso em atender a 
demanda de aplicações
Desafios
„ Mudança rápida de tecnologia
„ Demandas de Usuários
„ Interface Gráfica com Usuário
„ Multimídia
„ Sistemas Abertos
„ Computação Cliente/Servidor
„ Computação distribuída
Condicionantes 
Tecnológicas
Mudança de 
Paradigma
Procurando Soluções
„ Melhores Linguagens de 
programação
„ Melhores programadores
„ Ferramentas CASE
„ Reuso de Software
„ Tecnologia OO
„ . . .
Usuários IT
A Crise de Software Situação na entrega do software
‹Excesso de custos + 50 %
‹Atraso no cronograma + 60 %
‹Não funcionavam + 45 %
‹Não foram entregues + 29 %
‹Precisaram ser modificados +22 %
‹Funcionaram 2 %
2
Engenharia de Software
É a área interdisciplinar que engloba as 
vertentes tecnológica e gerencial visando 
abordar, de modo sistemático, os 
processos de construção, implantação e 
manutenção de produtos de software com 
qualidade assegurada por construção, 
segundo cronograma e custos previamente 
definidos
Evolução da Engenharia de Software
1960 1970 1980 1990
• Desenvolvimento de 
SW fora de Controle
• Nenhuma Gerência
Surgimento da 
Engenharia de 
Software
Primeiros Princípios 
de “boas práticas”
Surge a 
Programação 
Estruturada
Incorporação de 
Conceitos de 
Qualidade
Concentração em 
requisitos, especificação 
e projeto
Ferramentas 
Automatizadas, 
Cursos de ES
Estações de 
Trabalho, CASE
Ferramentas integradas, 
IA, Trabalho 
Cooperativo, Fábricas 
de SW, Reutilização
Programação
Técnicas 
Básicas
Qualidade
Confiabilidade
Produtividade
Ênfase da Engenharia de Software
1960 1970 1980 1990
Modelagem
Processo de Desenvolvimento de Software
ciclo de vida
Métodos
Ferramentas
Procedimentos
Produtos
Controle de Qualidade
Documentação
Métodos , Ferramentas e Procedimentos
¾Elementos chave para:
‹ gerente controlar o processo de desenvolvimento
‹ desenvolvedores criarem software de alta qualidade e produtividade 
¾Métodos
‹ fornecem o “how to” para o desenvolvimento
‹ normalmente utilizam uma linguagem própria (textual ou gráfica)
¾Ferramentas
‹ fornecem suporte (semi)automático para os métodos
¾Procedimentos
‹ unem métodos e ferramentas e permitem o desenvolvimento 
racional e eficiente de software
3
Requisitos
Objetos do 
Mundo real
Objetos do 
Mundo real
Modelo Semântico
Domínio do Problema
Fases do Desenvolvimento
Modelo Implementacional
Domínio da Solução
Aplicação Interface Serviços
Fases Clássicas no Desenvolvimento
Análise de Requisitos
Análise
Design (Projeto)
Codificação
Testes
Manutenção
Análise de Requisitos
¾ O que o usuário deseja do 
sistema a ser desenvolvido
Levantamento de Requisitos
¾ Visão do usuário (visão 
externa)
¾ Sistema como uma “caixa 
preta”
SistemaSistema
Análise
¾ O que o sistema deve ser 
utilizando-se a visão do 
desenvolvedor
Sistema
Design (Projeto)
¾ Como o sistema executará as 
funções necessárias a cumprir 
os requisitos levantados
Sistema
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
4
Codificação
¾ Tradução do projeto em 
linguagens que possam ser 
compreendidas pelo 
computador
Sistema
Testes / Manutenção
¾ Verificação do sistema 
¾ Resolver problemas
Ciclos de Vida
¾A ordenação das fases e das atividades desenvolvidas é 
especificada nos ciclos de vida
¾Principais ciclos de vida:
‹ Cascata
‹ Incremental
‹ Espiral
Requisitos
Análise
Projeto
Codificação
Teste
Manutenção
z Requisitos para manutenção 
podem levar muitos anos
z Risco máximo com custo 
máximo
Tempo
Risco
O Modelo de Processo em Cascata
Início
Versão1
Versão 2
Versão 3
Nova Função
Planejamento
Análise e Projeto
Determina objetivos
Avalia alternativas
Identifica e analisa 
riscos
Produz Protótipos
Desenvolve, verifica
produto próximo-nível
Validação de Requisitos
Planejar próxima iteração
Modelo de Processo Espiral
z Necessita ser cuidadosamente 
gerenciado
z Pode ser iniciado e 
incrementado antes do 
desenvolvimento completo dos 
requisitos
Viabilidade 
do Sistema
Planos de SW
Requisitos
Projeto 
Preliminar
Projeto
Implementação
Manut/Retroalim
Teste Unidade
Integração
Incremento 1
Incremento 2
Incremento N. . .
Modelo de Processo Incremental
Projeto
Implementação
Manut/Retroalim
Teste Unidade
Integração
5
Lev
Requisitos
Design
Rápido
Construção 
Protótipo
Avaliação 
pelo usuário
Refinar 
protótipo
Engenharia 
produto
início
fim
Prototipação RUP - Rational Unified Process
RUP - Rational Unified Process
¾Framework genérico para processos de 
desenvolvimento de software podendo ser instanciado 
para diferentes tipos de sistemas
¾Características
‹ Baseado em componentes
‹ Utiliza a UML
‹ Dirigido por use cases
‹ Centrado na arquitetura
‹ Interativo e incremental
RUP - Definições
Pessoas envolvidas no processo
(desenvolvedor)
¾ Artefatos: qualquer tipo de 
informação criada, produzida, 
modificada, ou utilizada pelas 
pessoas envolvidas no 
desenvolvimento
¾ Atividade: unidade de trabalho 
realizada por um desenvolvedor. 
¾ Workflow: conjunto de 
atividades realizadas seguindo 
determinada seqüência
RUP - Exemplo de Workflow RUP - Visão Geral 
tempo
Conteúdo
6
Fases e Interações
Ciclo Produto 
Versão 2.0
Inception Elaboration Construction TransitionPhases
Ciclo Produto 
Versão 1.0
#1Inter. #2 #3 #4 ... ... ... ... ... ... ... ... ... #N
Milestones
Milestones
•Objetivos devem 
ser atingidos
•Decisões críticas 
são tomadas
Inception Phase
¾Objetivo: estabelecer o caso do negócio a ser tratado 
pelo sistema e delimitar o escopo do projeto
‹ Caso do negócio:
» critérios de sucesso
» avaliação dos riscos
» estimativa de recursos necessários
» planejamento das fases mostrando as datas dos milestones
¾Como: 
‹ Identificar todas as entidades externas que irão interagir com o
sistema (actors)
‹ Definir a natureza das interações em alto nível (use case)
» Identificar todos os use cases e descrever apenas alguns
Inception Phase
¾Resultados: 
‹ Documento de Visão Geral: requisitos básicos, características 
chaves e principais restrições do sistema
‹ Use Case Model (inicial, 10 a 20% completo)
‹ Project Grossary (inicial)
‹ Business case
‹ Avaliação inicial de riscos
‹ Planejamento do Projeto
‹ Business Model (opcional)
‹ Protótipos
Inception Phase
¾Milestone: Lifecycle Objectives Milestone
‹ Critérios de Avaliação
» Concordância da direção e dos usuários sobre o escopo do projeto, custos e 
planejamento
» Entendimento dos requisitos como evidenciado pela fidelidade dos use 
cases primários
» Credibilidade das estimativas de custo e planejamento, das prioridades e 
dos riscos
» Profundidade e abrangência dos protótipos
» Comparação das despesas realizadas X planejadas
Projeto pode ser cancelado ou repensado se 
não passar pelo milestone
Inception Elaboration Construction Transition
Lifecycle Objectives Milestone
Elaboration Phase
¾Objetivo: analisar o domínio do problema, estabelecer 
uma arquitetura base, desenvolver o planejamento do 
projeto e eliminar os principais elementos de risco do 
projeto
¾Fase mais crítica: passagem de uma etapa simples, 
pequena e de baixo risco para uma etapaque possui 
alto custo e uma alta taxa de riscos 
¾Como: 
‹ Desenvolvimento de protótipos
» que usem a arquitetura definida
» que tratem os use cases críticos encontrados na fase de inception
Elaboration Phase
¾Resultados: 
‹ Use Case Model (mínimo de 80% completo): todos os use cases 
identificados e a maior parte deles já descritos
‹ Requisitos suplementares, capturando os requisitos não 
funcionais e aqueles que não podem ser associados a um 
determinado use case
‹ Descrição da Arquitetura de Software
‹ Protótipo executável da arquitetura
‹ Lista revisada dos riscos e do caso do negócio
‹ Planejamento de todo o projeto
‹ Manual do Usuário (inicial, opcional)
7
Projeto pode ser cancelado ou repensado se 
não passar pelo milestone
Elaboration Phase
¾Milestone: Lifecycle Architecture Milestone
‹ Critérios de Avaliação
» Documento de Visão Geral é estável?
» A arquitetura é estável?
» A execução do protótipo mostrou que os maiores elementos de riscos 
foram tratados e contornados?
» O Planejamento do Projeto é correto e detalhado o suficiente?
» Todos os usuários e diretores concordam que o sistema possa ser 
desenvolvido se o planejamento atual for seguido e sendo utilizada a 
arquitetura especificada?
» A comparação das despesas realizadas X planejadas é aceitável?
Inception Elaboration Construction Transition
Lifecycle Architecture Milestone
Construction Phase
¾Objetivo: desenvolver todos os componentes 
necessários, integrá-los ao produto e testar 
completamente as características desejadas do sistema.
¾Resultados: 
‹ Produto “pronto” para ser colocado em produção
» Software integrado para a plataforma de destino
» Manuais do Usuário
» Descrição da versão atual
Se não passar por este milestone a fase de Transition
pode ser cancelada e em consequência uma versão do 
sistema não será distribuída.
Construction Phase
¾Milestone: Initial Operational Capability Milestone
‹ Critérios de Avaliação
» Esta versão do produto é estável e madura o suficiente para ser distribuída 
aos usuários?
» Os usuários do sistema estão em condições de começar a utilizar o sistema?
» A comparação das despesas realizadas X planejadas continua aceitável?
Inception Elaboration Construction Transition
Initial Operational Capability Milestone
Transition Phase
¾Objetivo: colocar o sistema em produção
¾Como: 
‹ “beta” testes
‹ operação paralela de sistemas legados
‹ conversão de bases de dados
‹ treinamentos
¾Resultado: 
‹ Sistema em produção
Se não passar por este milestone pode ser decidido pela 
realização de um novo ciclo de desenvolvimento
Transition Phase
¾Milestone: Product Release Milestone
‹ Critérios de Avaliação
» Os usuários estão satisfeitos?
» A comparação das despesas realizadas X planejadas continua aceitável?
Inception Elaboration Construction Transition
Product Release Milestone
Artigos para 03 Março
¾Software’s Future: Managing Evolution
‹ M.M.Lehman
¾Heuristics for Iterative Software Development
‹ Drasko Sotirovski