ENGENHARIA DE SOFTWARE/

SISTEMAS DE SOFTWARE

CMP1280/CMP1250

Prof. Me. Fábio Assunção

Introdução à Engenharia de Software

SOFTWARE

Programa de computador acompanhado dos

dados de documentação e configuração

associados.

Documentação do sistema (modelos e projetos).

Documentação do usuário (manuais de ajuda).

Via de atualização (ex.: site).

Código fonte.

Arquivos de configuração.

Regras de negócio.

PRODUTO DE SOFTWARE

Software vendido ao a um cliente.

Produtos genéricos: desenvolvido por uma

organização e vendido a qualquer cliente que

queira/possa adquiri-lo.

Produtos sob encomenda: desenvolvido sob

demanda de encomenda para um cliente específico.

ENGENHARIA DE SOFTWARE - ES

Disciplina de engenharia relacionada com todos

os aspectos da produção de um software,

desde os estágios iniciais de especificação do

sistema até a sua manutenção, depois que o

mesmo entra em operação.

CIÊNCIA DA COMPUTAÇÃO X ENGENHARIA

DE SOFTWARE

Ciência da Computação: teorias e métodos que

constituem a base de computadores e sistemas de

software (modelos matemáticos, algoritmos,

formalização lógica, etc.).

Engenharia de Software: problemas práticos

da produção de software (produção de software

com maior desempenho e produtividade).

Engenharia da Computação: desenvolvimento

de equipamentos e dispositivos computacionais,

mais focada em hardware (aplicações industriais,

redes, sistemas embarcados, etc).

SISTEMAS DE SOFTWARE

Um sistema é o conjunto intencional de

componentes inter-relacionados que funcionam

juntos para atingir certo objetivo.

Sistema de software: sistema computacional

(envolve hardware e software).

SISTEMAS DE SOFTWARE

Técnicos

Incluem componentes de hardware e software, mas

não incluem operadores e processos operacionais. São

usados para algum propósito, mas o conhecimento

deste propósito não é parte do sistema.

Ex.: MS Word.

Sociotécnicos

Incluem um (ou mais) sistemas técnicos, mas,

decisivamente, incluem operadores (pessoas) e

processos operacionais definidos. São instalados

dentro de uma organização, projetados para ajudá-la

a atingir um objetivo maior.

SISTEMAS SOCIOTÉCNICOS

Fatores humanos e políticas organizacionais têm

um efeito significativo sobre a operação de

sistemas sociotécnicos.

Caracterizado por:

Propriedades emergentes.

Não é determinístico.

Objetivos organizacionais.

SISTEMAS LEGADOS

Sistemas sociotécnicos desenvolvidos no passado,

frequentemente utilizando tecnologia obsoleta,

porém, ainda fornecem serviços essenciais.

Processos operacionais “legados”: mudanças

envolvem alterações em diversos componentes;

criticidade e custo de modernização.

São sistemas críticos de negócios. Mantidos por

que é arriscado substituí-los.

Ex.: Sistemas bancários, sistemas de controle

aéreo, etc.

DIFICULDADES ESSENCIAIS E ACIDENTAIS

DA ENGENHARIA DE SOFTWARE

No Silver Bullet – Essense and Accidents of

Software Engineering (Frederick P. Brooks,

1987).

Analogia de softwares com a lobisomens.

Ente querido = lobisomem.

Projeto de software = “monstro” criado pela tortura

de prazos perdidos, orçamentos estourados, produto

final imperfeito.

Para os lobisomens há uma bala de prata de

capaz de matar todos. Para os softwares não há

uma solução para todos os problemas.

DIFICULDADES ESSENCIAIS E ACIDENTAIS

DA ENGENHARIA DE SOFTWARE

Dificuldades em se construir um software:

Essenciais: pertinentes à natureza do software,

ao modelo conceitual para o sistema (conjunto de

dados, relação entre esses itens de dados e a

chamadas de funções).

Acidentais: dificuldades que se tem na produção

do software, mas que não são inerentes às regras de

negócio implementadas pelo software (linguagem,

tecnologias, etc).

Conquistas passadas resolveram as dificuldades

acidentais, não essenciais.

DIFICULDADES ESSENCIAIS E ACIDENTAIS DA

ENGENHARIA DE SOFTWARE – PRINCIPAIS

PROBLEMAS

Complexidade: entidades de software são mais

complexas pelo seu tamanho que qualquer outra

construção humana, pois suas partes são

desiguais. Software tem um grande número de

estados, tornando sua descrição, concepção e

teste muito difíceis.

DIFICULDADES ESSENCIAIS E ACIDENTAIS DA

ENGENHARIA DE SOFTWARE – PRINCIPAIS

PROBLEMAS

Conformidade: dificuldade em se manter

padrões desenvolvidos por pessoas diferentes,

em tempos diferentes. Em versões prévias, por

exemplo, esta complexidade não pode ser

simplificada redesenhando o software sozinho.

DIFICULDADES ESSENCIAIS E ACIDENTAIS DA

ENGENHARIA DE SOFTWARE – PRINCIPAIS

PROBLEMAS

Alterabilidade: mudanças constantes são

promovidas no software, inclusive após ser

desenvolvido (o que é mais complexo). Sistemas

incorporam funcionalidades e estas são, na

maioria das vezes, os pivôs das mudanças.

DIFICULDADES ESSENCIAIS E ACIDENTAIS DA

ENGENHARIA DE SOFTWARE – PRINCIPAIS

PROBLEMAS

Invisibilidade: software possui um aspecto

abstrato, imaterial, não pode ser representado

por uma baseado em combinações geométricas.

Para se construir um software é necessário um

conjunto de diagramas (que devem representar

fluxo de dados, padrões de dependência,

sequência temporal, etc.)

DIFICULDADES ESSENCIAIS E ACIDENTAIS DA

ENGENHARIA DE SOFTWARE – SOLUÇÕES

PROMISSORAS

Compra x Construir: concepção do software

não construindo-o completamente.

Refinamento de requisitos e prototipagem

rápida: precisão no levantamento de dados é

essencial. É necessária uma interação exaustiva

entre cliente e desenvolvedor.

Grandes projetistas: gerenciamento de pessoal.

Qualificação de grandes projetistas.

PROCESSO

Conjunto de

manipulações para

obter um resultado.

Diretrizes

utilizadas para se

fazer alguma coisa.

PROCESSO DE SOFTWARE

Conjunto de atividades relacionadas que levam à

produção de um produto de software. Essas

atividades podem envolver o desenvolvimento do

software a partir do zero em uma linguagem

padrão, como C ou Java.

PROCESSO DE SOFTWARE – ATIVIDADES

FUNDAMENTAIS

Especificação de software: funcionalidade do

software e as restrições a seu funcionamento

devem ser definidas.

Projeto e implementação do software:

produção do software atendendo às

especificações.

Validação do software: o software deve ser

validado para garantir que atenda as solicitações

do cliente.

Evolução do software: o software deve evoluir

para atender às necessidades de mudança dos

clientes.

ATIVIDADES DO PROCESSO DE SOFTWARE:

ESPECIFICAÇÃO DE SOFTWARE

Processo de compreensão e definição dos serviços

requisitados (requisitos) e identificação das

restrições relativas à operação e

desenvolvimento.

Estudo de viabilidade: rentabilidade.

Elicitação e análise de requisitos: entendimento.

Especificação de requisitos: documento.

Validação de requisitos: consistência e

completude.

ATIVIDADES DO PROCESSO DE SOFTWARE:

PROJETO E IMPLMENTAÇÃO DE SOFTWARE

Conversão de uma especificação do sistema em

um sistema executável.

Projeto de arquitetura: estrutura geral do

sistema (componentes e suas relações).

Projeto de interface: interfaces entre

componentes.

Projeto de componente: funcionamento.

Projeto de banco de dados: estruturas de dados.

ATIVIDADES DO PROCESSO DE SOFTWARE:

VALIDAÇÃO DE SOFTWARE

Verificação e Validação (V&V).

Verificação: “Estou construindo o produto certo?”.

Validação: “Estou construindo o produto da forma

correta?”.

Sistemas devem ser testados como uma unidade

única.

Teste de desenvolvimento: desenvolvedores.

Teste de sistemas: integração de componentes.

Teste de aceitação: dados do cliente.

ATIVIDADES DO PROCESSO DE SOFTWARE:

EVOLUÇÃO DE SOFTWARE

Desenvolvimento e manutenção devem ser

encarados como processos contínuos. O software é

constantemente modificado em função do das

mudanças de requisitos.

Mudanças no software são mais baratas que em

projetos de hardware.

PARADIGMA

Exemplo típico ou modelo de algo. É a

representação de um padrão a ser seguido.

PARADIGMAS DA ENGENHARIA DE

SOFTWARE

Escolha de um modelo de processo para

Engenharia de Software.

Um modelo de processo de software é uma

representação simplificada de um processo de

software. Cada modelo representa uma

perspectiva particular de um projeto e, portanto,

fornece informações parciais sobre ele.

MODELO EM CASCATA

MODELO EM CASCATA

Análise e definição de requisitos:

estabelecimento de serviços, restrições e metas.

Projeto de sistema e software: aloca

requisitos tanto de hardware tanto de software.

Implementação e teste unitário: conjunto de

unidades de programas são testados.

Integração e teste de sistema: integração das

unidades para um teste do sistema completo.

Operação e manutenção: correção de erros não

descobertos e inserção de funcionalidades.

MODELO EM CASCATA

Também chamado de “Ciclo de Vida”.

O resultado de cada estágio é a aprovação de um

ou mais documentos “assinados”.

O estágio seguinte não deve ser iniciado antes da

conclusão da fase anterior.

Na prática, os estágios se sobrepõem e se

alimentam, um ao outro, de informações.

Uma versão executável só fica disponível quando

o projeto é finalizado.

Erros iniciais x Evolução.

MODELO (DE DESENVOLVIMENTO)

INCREMENTAL

MODELO (DE DESENVOLVIMENTO)

INCREMENTAL

Desenvolvimento de uma implementação inicial

(núcleo de produto), apresentá-la ao cliente e

aplicar as correções solicitadas, resultando em

uma nova versão/incremento (até que o sistema

adequado seja apresentado).

Sequencia linear x incrementos.

Promoção de mudanças mais barata e fácil.

Invisível ao gerente: rapidez de incrementação x

documentação.

MODELO RAD – RAPID APPLICATION

DEVELOPMENT

MODELO RAD

Processo incremental que enfatiza um ciclo de

desenvolvimento extremamente curto.

Modularidade x ciclo de desenvolvimento.

Projetos grandes envolvem grandes equipes.

Exige compromisso de desenvolvedores e clientes

com atividades continuamente rápidas.

Orientação à reuso diminui necessidades de

testes.

MODELO DE PROTOTIPAGEM

MODELO DE PROTOTIPAGEM

Protótipo é uma implementação concreta mas parcial do desenho do sistema.

Componente de uma UI – User Interface.

Físico.

Funcional.

Auxilia na compreensão do que deve ser construído quando os requisitos estão confusos, possibilitando que seja criado um modelo executável ao invés de descrito.

Geralmente o cliente deseja que o protótipo torne-se o produto final.

Escolhas aquém da necessidade, podem tornar-se parte integrante do sistema.

MODELO EM ESPIRAL

MODELO EM ESPIRAL

Ciclo de vida clássico com prototipagem, porém, com a análise de riscos à medida que, gradativamente, o software vai sendo construído.

Este modelo assume que o desenvolvimento ocorre em ciclos.

Variações consideram entre 3 e 6 tarefas (setores) de avaliação na espiral:

Comunicação com o cliente.

Planejamento.

Análise de risco.

Engenharia.

Construção e entrega.

Avaliação do cliente.

MODELO EM ESPIRAL

MODELO EM ESPIRAL

Direção radial: custo acumulado.

Direção angular: progresso através da espiral.

Modelo mais indicado para softwares de grande

escala.

Permite ao engenheiro de software e ao cliente

reagir aos riscos após cada etapa evolutiva.