1

Software e Engenharia de

Software

O que é software?

• Programas de computador • Entidade abstrata. • Ferramentas (mecanismos) pelas quais:

– exploramos os recursos do hardware.– executamos determinadas tarefas– resolvemos problemas. – interagimos com a máquina. – tornamos o computador operacional.

O que é software?

Conceito mais amplo que inclui também:

• Instruções que executam uma funçãodesejada.

• Estrutura de dados para manipularinformação.

• Documentos para desenvolver, operar e manter os programas.

O que é software?

Software como um produto!

Sw pervasivo – incorporado em todas as atividades humanas cotidianas: cultura, comércio, lazer, etc.

Tipos de Sistemas de Software

• Software básico• Software stand-alone – aplicativos para PC que náo

precisam estar conectados à rede• Software para sistema em tempo real• Software baseado em transações: comércio

eletrônico• Software comercial e sistemas financeiros• Software para engenharia e aplicações científicas• Software embarcado (ex. microwave, celulares)• Software baseado em inteligência artificial• Software de entretenimento: jogos, cinema

A Evolução do Software

Os primeiros

anos

•sistemas batch

•distribuição limitada

•software personalizado

A segunda era

•sistemasmultiusuários

•sistemas em tempo real

•banco de dados

•software produto

A terceira

era

•sistemas distribuídos

•incorporação de inteligência

•hardware de baixo custo

•impacto do consumidor

A quarta era

•sistemasdesktoppoderosos

•tecnologia deorientação a objetos

•sistemas especialistas

•redes neurais

•computação paralela

19501960 1970 1980 1990 2000

A quinta

era

•Netbooks•Web 2.0•ServiçosWeb•Computa-ção em nuvens

2010

2

Dificuldades para desenvolver software

• Saber o que o software deve fazer : quais os requisitos (abstração);

• Ferramentas; linguagem; so – tecnologias diferentes

• Tempo e custos elevados de desenvolvimento.

• Prever falhas (antes de entregar).

• Tratar manutenção e versões.

• Produtividade não cresce com a demanda de serviços.

Características do Software

• software não é um elemento físico; é um elemento lógico (não tem propriedades físicas, como visualizar, medir ...)

• abstração maior; o produto final é diferente • o software não pode ser manufaturado; custos

estão concentrados no desenvolvimento e não na manufatura.

• o processo de gerenciamento é diferente; o relacionamento entre as pessoas é diferente;

Características do Software

• existem diferentes abordagens para se chegar no produto final

• o software não se desgasta com o uso; mas deteriora-se

• não há peças de reserva. => manutenção, correção, aperfeiçoamento.

• não é construído aproveitando-se componentes prontos pq muitas vezes é personalizado.

• Um erro durante um teste => mais difícil de testar.

Curvas de falhas no hw

tempo

“desgaste”“mortalidade

infantilӒndice

de

falhas

Curva de falhas no sw

índice de

falhas

mudança

curva real

curva idealizada

tempo

Falso ou verdadeiro?1. Já temos um manual repleto de padrões e

procedimentos para a construção de sw. Neles estátudo o que a equipe precisa saber para produzir com qualidade.

2. Meu pessoal tem ferramentas de última geração, isso é suficiente.

3. Se nós estamos atrasados nos prazos podemos adicionar mais programadores e isso irá resolver o problema com o cronograma

4. Podemos terceirizar o projeto de software. Assim a responsabilidade será da empresa contratada.

3

Falso ou verdadeiro?

• Assim que colocarmos o programa em funcionamento posso ficar tranquilo porque meu trabalho estará finalizado.

2. A engenharia de software irá nos fazer criar documentação volumosa e desnecessária e, invariavelmente nos retardar.

3. Só poderemos avaliar a qualidade do software quando tivermos o programa funcionando.

Falso ou verdadeiro?1. Uma definição geral dos objetivos é

suficiente para começar a escrever programs, podemos adicionar detalhes depois.

2. Os requisitos de software mudam constantemente mas mudanças podesm ser facilmente asimiladas pois o software éflexível.

3. Eu, cliente, sei o que preciso.

Mitos da ESMitos atuais

1. O teste de sw ou sua verificação formal pode remover todos os erros.

• Para garantir qualidade é só aumentar a confiabilidade do software.

• O reúso de componentes prontos me traz segurança com relação à qualidade.

Mitos: Propagaram desinformação e confusão

44administrativosadministrativos

44clientecliente

44profissionalprofissional

Crise de Software

Alguns autores associam a palavra “crise” aos problemas para desenvolver software

� estimativas de prazo e de custo ↑

� produtividade das pessoas ↓

� qualidade de software ↓

� software difícil de manter ↑

Crise de SoftwareProblemas: • Software inadequado. • Cronogramas e custos imprecisos - dificuldades em

prever o progresso durante o desenvolvimento. • Inexistência de dados históricos sobre o processo

de desenvolvimento. • Mitos da ES• Comunicação deficiente - insatisfação de usuários.• Carência de conceitos quantitativos sobre

confiabilidade, qualidade, reusabilidade. • Software existente é de difícil manutenção.

Crise de Software

Solução:

• Combinar métodos para as fases de desenvolvimento.

• Ferramentas para automatizar esses métodos.

• Técnicas para assegurar qualidade.

=> Disciplina: Engenharia de Software.

4

Engenharia de SoftwareEngenharia de Software

• Abordagem sistemática para o desenvolvimento, operação, manutenção e descarte de software.

• Aplicação prática de conhecimento científico ao projeto e construção de software.

• Disciplina que utiliza princípios de engenharia para produzir e manter softwares dentro de prazos e custos estimados.

• “.. construção por muitas pessoas de um software com múltiplas visões”. (Parnas 1987)

Engenharia de SoftwareEngenharia de Software

• Objetivos: Melhorar a qualidade do software e aumentar a produtividade e satisfação profissional de engenheiros de software.

• Definição: Disciplina que utiliza um conjunto de métodos, técnicas e ferramentas para analisar, projetar e gerenciar desenvolvimento e manutenção de software.

Engenharia de SoftwareEngenharia de Software Engenharia de SoftwareEngenharia de Software

• Métodos e Técnicas: detalhes de como fazer

• Metodologias: como aplicar• Ferramentas: automatizam os métodos,

dão apoio a utilização. CASE => (Computer-Aided Software Engineering): Ferramentas integradas para desenvolver software.

ES e outras áreasPrincPrincíípios da Engenharia de pios da Engenharia de

SoftwareSoftware• Formalidade: reduz inconsistências

• Abstração: aspectos importantes, ignorar detalhes

• Decomposição: lidar com complexidade

• Generalização: reutilização, custo

• Flexibilização: mudanças, processo incremental

5

Processo de Processo de SoftwareSoftware

À E. S. está associado um conjunto depassos

(que englobam métodos, ferramentas, etc)

denominado paradigma

Processo de Software

• Um conjunto estruturado de atividades requeridas para desenvolver um produto de software

• Envolve: fases, atividades, pessoas (responsáveis, participantes, papéis), entradas e saídas (artefatos), recursos, passos para execução, regras, procedimentos.

Processo de Software

• Fases – grandes divisões (marcos) dos processos, períodos de tempo no qual algumas ativides são executadas.

• Atividades- possui entradas e saídas bem definidas, pessoas (responsáveis, participantes, papéis), entradas e saídas.

• Artefatos: qq doucmentos quepossa ser produzido ao longo do desenvolvimento de sw.

• Recursos: hw, sw, material consumível ou não.• Passos para execução: o que precisa ser feito em

cada atividade

Processo de Software

• Modelos de processo de sw: representação abstrata de um proceso de sw. Podem ser instanciados

• Projeto: execução de um proceso, uma instância de um proceso.

• Padrão de processo: resolvem problemas recorrentes relacionados a processos de sw.

• Normas de avaliação de processos: NBR ISO/IEC 12207

Modelo de Processo de Software

• Apresenta uma descrição de um processo de alguma perspectiva particular.

• Modelos prescritivos: definem uma ordem para realizar as atividades e um fluxo de trabalho previsível.

• Modelos ágeis: planejamento é gradativo, mais fácil adaptação.

1. 1. Ciclo de Vida ClCiclo de Vida Cláássicossico(cascata)(cascata)

• modelo mais antigo e o mais amplamenteconhecido da engenharia de software

• modelado em função do ciclo da engenharia convencional

• requer uma abordagem sistemática, seqüencial ao desenvolvimento de software

• o resultado de uma fase é entrada para outra fase.

• existem variações/adaptações

6

Ciclo de Vida ClCiclo de Vida Cláássicossico (cascata)(cascata) Engenharia de sistemas

• envolve a coleta de requisitos em nível dosistema, com uma pequena quantidade deprojeto e análise de alto nível

• esta visão é essencial quando o software deve fazer interface com outros elementos(hardware, pessoas e banco de dados)

Análise de Requistos de Software

• o processo de coleta dos requisitos éintensificado e concentrado especificamente no software

• deve-se compreender o domínio da informação, a função, desempenho e interfaces exigidos

Projeto

• tradução dos requisitos do software para umconjunto de representações que podem seravaliadas quanto à qualidade, antes que acodificação se inicie

Codificação

• tradução das representações do projeto parauma linguagem “artificial” resultando eminstruções executáveis pelo computador

Teste

Concentra-se:• nos aspectos lógicos internos do

software,garantindo que todas as instruções tenham sido testadas

• nos aspectos funcionais externos,paradescobrir erros e garantir que a entrada definida produza resultados que concordem com os esperados.

7

Manutenção

• provavelmente o software deverá sofrermudanças depois que for entregue ao cliente

• causas das mudanças: erros, adaptação do

software para acomodar mudanças em seu

ambiente externo e exigência do cliente

para acréscimos funcionais e de

desempenho

Ciclo de Vida ClCiclo de Vida Cláássicossico

Problemas para aplicação:

• Na prática, projetos não seguem o fluxo seqüencial.

• Acomodações de incertezas no início do projeto é difícil.

• Versão funcional dos programas disponível após os últimos estágios do projeto

Ciclo de Vida ClCiclo de Vida Cláássicossico

• O modelo Cascata trouxe contribuiçõesimportantes para o processo dedesenvolvimento de software:– imposição de disciplina, planejamento e

gerenciamento;

– a implementação do produto deve serpostergada até que os objetivos tenham sidocompletamente entendidos

2. 2. EvoluEvolutivotivo

• Tudo merece uma nova chance – situações para acomodar um processo que evolui com o tempo

• Incorporação de diferente partes e criação de diferentes versões

• São iterativos – repetem atividades• Inclui prototipação• Permite o desenvolvimento exploratório

EvoluEvolutivotivo 3. Incremental

• Abordagem intermediária

• Combina vantagens dos paradigmas ciclo de vidaclássico e evolutivo

• Identificação das funções do sistema,estabelecimento de incrementos e prioridades

• Cada incremento pode utilizar um paradigma dedesenvolvimento diferente

• Dificuldade para dividir e gerenciar versões

8

Incremental

• O valor agregado ao Cliente está na entrega em cada incremento de modo que a funcionalidade do sistema estará disponível mais cedo

• Incrementos iniciais funcionam como protótipos para ajudar a evocar requisitos para incrementos posteriores

• Menores riscos de falha no projeto em geral• Os serviços do sistema de alta prioridade tendem a

receber a maioria dos testes

Incremental

Variações do modelo incremental

• Orientado a funcionalidades – a cada versão novas funcionalidades são entregues

• Orientado a cronograma – entrega em tempos determinados

4. Espiral

• Modelo que acopla a natureza iterativa da prototipação co os aspectos controlados e sitemáticos do modelo cascata

• Dividio em regiões ou atividades de trabalho.• Cada volta do espiral representa um

desenvolvimento completo. • O loop mais interno se concetra mais na definição

dos requisitos• A gerência pode adaptar o modelo e suas fases

EspiralEspiral EspiralEspiral

• Paradigma mais realístico - sistemas grandes

• É um metamodelo

• Incorpora análise de riscos.

• Permite prototipação em mais de um estágio

• Problemas: O modelo é relativamente novo. Requer esperteza. Pode nunca terminar, precisa ser evolutiva e controlável.

9

ConsideraConsideraçõções sobre processoses sobre processos

• Que processo usar ?

Depende da natureza da aplicação.

Métodos e ferramentas disponíveis, etc.

Outros processos - objetivos específicos, mais especializados

• RAD (Rapid Application Development)- enfatiza rapidez e um ciclo mais curto

• Prototipação• Processo formal• Modelo de componentes• Processo unificado – UP• Orientados a reúso• Linguagem de quarta geração• Engenhria de Linha de Produto de Sw (LPS)

1. Prototipação

• Possibilita que o desenvolvedor crie um modelo (protótipo) do software a ser construído para auxiliar a entender os requisitos do usuário

• Apropriado para quando os requisitos não estão claramente definidos

• Derivado da técnica de extração de requisitos

PrototipaPrototipaçãçãoo

PrototipaPrototipaçãçãoo

fim

início

construçãoproduto

refinamentoprotótipo

avaliaçãoprotótipo

construçãoprotótipo

projetorápido

obtenção dosrequisitos

Abordagem Prototipação

• Validar a precisão dos requisitos ou aceitabilidade das decisões– O usuário irá colaborar?

• Validar a viabilidade de uma estratégia proposta.– O software é particionável?

• Observações:– protótipos só são válidos se construídos rapidamente

10

Prototipação

• O protótipo pode ser descartado ou fazer parte do produto final.

• Conerstone (pedra fundamental): Prototipação evolutiva

• Throw away: descartável

Prototipação

• Localiza “aspectos visíveis” para o usuário (E/S).

• A iteração pode adequar o protótipo às necessidades do usuário.

• Problemas: – Cliente insiste que o protótipo seja com ligeiras

modificações, a versão final do produto.

– Decisões e soluções improvisados tornam-se parte do produto final.

2. 2. Linguagens de Quarta GeraLinguagens de Quarta Geraçãçãoo Linguagens de Quarta GeraLinguagens de Quarta Geraçãçãoo

• Ferramentas para especificação de alto nível(L4G):

Consulta a base de dados.

Geração de relatórios.

Manipulação de dados.

Definição e interação com Telas.

Geração de código.

Linguagens de Quarta GeraLinguagens de Quarta Geraçãçãoo

• Domínio predominante : Sistemas comerciais de informação.

• Boa produtividade para sistemas pequenos e médios e aplicação específicas.

• Problemas: Para sistemas grandes, demanda muito tempo; e ainda permanece a necessidade de projeto

3. Desenvolvimento de sistemas formais

• Baseado na transformação de uma especificação matemática através de diferentes representações para um programa executável

• Transformações são ‘preservadoras de exatidão’, portanto, são diretas para mostrar que o programa está de acordo com sua especificação

• Contido na abordagem ‘Cleanroom’ para desenvolvimento de software

11

Desenvolvimento de sistemas formais

Transformações Formais

Desenvolvimento de sistemas formais

• Problemas– Necessidade de habilidades especializadas e

treinamento para aplicar a técnica– Difícil de especificar formalmente alguns

aspectos do sistema como a interface de usuário

• Aplicabilidade– Sistemas críticos, especialmente aqueles no

qual um case de segurança deve ser feito antes do sistema ser posto em operação

4. Desenvolvimento Baseado em Componentes

• Baseado no reuso sistemático, onde os sistemas são integrados de componentes existentes ou sistemas padronizados

• Estágios do Processo– Análise do componente– Modificação dos requisitos – Projeto do sistema com reúso – Desenvolvimento e integração

• Esta abordagem está se tornando mais importante, mas a experiência ainda é limitada com ela

Desenvolvimento orientado acomponentes

Que processo usar?

• Sempre deve existir um processo de software definido - padrões de qualidade.

• Criar um processo baseado em fases específico para cada projeto.

• O profissional deve estar apto a avaliar a aplicação a ser desenvolvida e a situação do ambiente de desenvolvimento para decidir qual o melhor processo de software a ser definido.

12

CombinaCombinaçãção o Uma VisUma Visãão Geno Genéérica da E.S.rica da E.S.

Uma VisUma Visãão Geno Genéérica da E.S.rica da E.S.

Análise do SistemaDefinição

Análise de Requisitos

Planejamento do Projeto de

Software

Processo de

SoftwareDesenvolvi

mento

Manutenção

Projeto do

Software

Codificação Testes

Correção Adaptação Melhoramentos

O Que?

O Como?

A Obrigação ...

Uma VisUma Visãão Geno Genéérica da E.S.rica da E.S.

1) Definição

Função, desempenho, interface, restrições de projeto, critérios de validação.

Análise de sistemas

Planejamento de projeto de software.

Análise de requisitos.

Uma VisUma Visãão Geno Genéérica da E.S.rica da E.S.

2) Desenvolvimento:

Estrutura de dados, arquitetura de software, detalhes procedimentais, programas, testes.

Projeto de software.

Codificação.

Testes

Uma VisUma Visãão Geno Genéérica da E.S.rica da E.S.

3) Manutenção

Corretiva: para corrigir defeitos; Adaptativa: para acomodar mudanças no ambiente externo do software (S.O., periféricos, etc)Perfectiva: para inclusão de novas funcionalidades

13

Uma VisUma Visãão Geno Genéérica da E.S.rica da E.S. Uma VisUma Visãão Geno Genéérica da E.S.rica da E.S.

Uma VisUma Visãão Geno Genéérica da E.S.rica da E.S.O Ciclo de Vida Canônico

• Estudo de Viabilidade• Iniciação do projeto• Especificação de requisitos• Projeto da arquitetura• Projeto detalhado• Codificação• Teste de unidade• Teste de aceitação• Teste operacional• Encerramento do projeto• Operação• Desativação do produto

O modelo canônico deve ser tratado como uma referência que deve ser adaptada para cada situação.

Referências

• Pressman, R. Software Engineering: A Practitioner's Approach. McGraw-Hill, 6th edition, 2006.

• Sommerville, I. Software Engineering:) International Computer Science Series) 8th edition, 2006.

Programação Extrema – XP (eXtreme Programming)

• Nova abordagem para o desenvolvimento de software baseado no desenvolvimento e entrega de incrementos de funcionalidade bem pequenos

• Conta com melhoramento constante do código, envolvimento do usuário no time de desenvolvimento e programação em pares