engenharia de software

Engenharia de Software

Revisão B1

2

Conceitos

O que é Hardware ?Parte tangível de um computador, equipamentos, periféricos. Está limitado a

espaços físicos com recursos finitos.No ser humano poderia ser comparado ao crânio.

O que é Software ?Não é material, intangível, não limitado a espaços físicos ou recursos naturais.

Seu potencial é infinito e conseqüente sua complexidade pode se tornar tão elevada, que pode passar a ser difícil de ser compreendido.

No ser humano poderia ser comparado com os pensamentos.

3

Hardware

Software

Falhas de hardware no início são inerentes à sua fabricação e no final relativas ao desgaste ambiental das peças (poeira, aquecimento, vibração). Na fase mediana a estabilidade se dá pela facilidade de substituição de uma peça ou outra que apresente falha. Conclusão: é fácil ter estabilidade quando é fácil atuar exatamente no ponto gerador do problema.

Durante a vida do software modificações introduzem novas falhas, se a manutenção desta falha for de difícil acesso¹, o índice de correção é baixo, trazendo novas falhas. . Conclusão: é difícil ter estabilidade quando é difícil atuar exatamente no ponto gerador do problema.

¹ Exemplo de difícil acesso = código macarrônico

Hardware x Software

4

Ciclo de Vida de Sistemas de Software.

Ciclo de Vida

5

Linha Tempo T.I.Evolução do Hardware

Evolução do Software

Registros ArgilaAbaco

Calculadora IBM (1924)Televisão

Máquina DiferençaTelégrafoRádioTelefone

IBM-CartãoPerfuradoIBM-Máq. Escrever Ele

Prim. Compu. PGM

RAM, CPUTransistor

Prim. Compu. Com.

Modem

Memória VirtualIBM 360

Chip 8 bitsMonitorTeclado Calculadora mão

MicroprocessadorImpres. LaserImpres. Jato Tinta

AppleMicrosoftt

Compu. < 11kh

IBM PCCD ROM

Super Compu.

1.2 milhõestransistores

Acesso ráp. www

4.000-1200 ac

www cel.

1935-37 1941

1947-49

1600-1800 dc

1800-1900

1951

1958-59

1960-61

1962

19671971

1976

1977

1981

1982-84

1985

1bi oper/seg

1989

1995 2000

Tear controla produçãoLógica x Símbolos

Base Algoritmos CompiladorModem

Transmissão dados7 bits

Data ddmmyyCOBOL Cria Bug Milênio

Processador

Windows 1.0

19371949-19511800-1937

1958-59

1959

1963

1968 19721977

1980

1981-83

1985 1986-89

1990-95

TextoDesenv. Sist.

1975

Desenv. Softw

Anál. EstruturadaPlanilha Eletr.

DOS

1 Ger.BD

COCOMOAutoCadTCP/IPC++OO

CASECMM“Verme”Modelo Espiral

WWWUMLhttp1 browserToyStory

1995-2000

Windows 95/NTJavaNapster57tri msg/anoOffice2000MP3Bug milênio

Serão estudados em Engenharia de Software

(~5.600 anos)

(~200 anos)

(~100 anos) (~84 anos)

(~84 anos)Fonte: IEEE Computer Society

Crise do Software

6

A Engenharia de Software é um ramo da Engenharia, que tem como foco o desenvolvimento de softwares dentro de determinados padrões de

custo e qualidade.


O que é Engenharia de Software?

7

Um produto de software novo, ou uma grande manutenção são produzidos por meio de um projeto. Este, por um determinado período de tempo, se

compromete a construir um produto.

Um projeto é uma função entre Escopo, Recurso e Tempo

P = F (E, R, T)


O tempo, que deveria ser variável, geralmente se mostra fixo segundo a necessidade do cliente. Com isto o projeto de construção ou manutenção

se reduz a uma função de Escopo e Recurso.

8

Com apenas essas duas variáveis o Engenheiro de Software precisa conseguir produzir produtos dentro dos padrões de custo e qualidade.

Com menos tempo, como conseguir entregar o mesmo produto com a mesma qualidade e pelo mesmo preço?

Procurar não errar. Utilizar processos e métodos já testados por outras pessoas.

Reutilizar o que já estiver pronto -

“ Os componentes reutilizáveis foram criados para que o Engenheiro possa se preocupar com os elementos realmente inovadores do projeto.”


9

Modelos

IncrementalCascata RAD Prototipação Espiral

Modelos usados na Engenharia de Software

Modelos: conjunto de atividades, ações, tarefas, marcos, roteiros e produtos necessários para fazer com que a Engenharia de Software produza com qualidade. Cada projeto de software pode usar um modelo específico, segundo uma determinada necessidade.

10

Modelos

Para situações em que os requisitos do software são razoavelmente estáveis e lineares. Sugere uma abordagem sistemática e seqüencial.


11

CascataPontos positivos e negativos

(+)- equipe com foco numa única fase traz qualidade;- fácil colocar preço; - fácil gerenciar projeto;- implementação mais barata.(-)- modificações podem causar confusão à medida que o

desenvolvimento prossegue;- todos os requisitos têm que ser definidos de uma única vez;- só se tem um executável no final do processo;- ociosidade de profissionais entre as fases.

12

Modelos

Não é um processo puramente linear. Quando há alguns requisitos definidos, mas ainda há necessidades a serem refinadas, porém há uma necessidade de entregar algum produto ao usuário, ou quando não há equipe suficiente para desenvolver o produto no tempo solicitado.


Combina a sequência linear do modelo em cascata de forma iterativa. Cada sequência linear produz uma entrega ao cliente chamada de iteração.

13

IncrementalPontos positivos e negativos

(+)- cliente recebe funcionalidades ao longo do projeto;- não é obrigatório (embora seja desejável) que todos os

requisitos estejam definidos no início do projeto;- modificações podem ser bem vindas e melhorar o software;- não há ociosidade de profissionais entre as fases.(-)- é complexo para colocar preço; - gerenciamento projeto trabalhoso;- implementação pode ficar cara;- novos requisitos podem ser incorporados e mudar planos...

14

ModelosIncrementalCascata RAD Prototipação Espiral

RAD (Rapid Application Development), Desenvolvimento Rápido de Aplicação.Também é um modelo de software incremental, porém enfatiza um ciclo de desenvolvimento curto. É uma aceleração do modelo em cascata, conseguida à base de utilização de componentes. Comunicação e Planejamento

para entender o que se deseja e coordenar equipes. Modelagem de Negocio, Dados e Processos. O desenvolvimento reaproveita componentes.

15

RADPontos positivos e negativos

(+)- rápida implementação;- baixa probabilidade de erros;- mão de obra barata, preço software mais barato;- pode ser trabalhado em equipes totalmente separadas (-)- é pouco customizável, ou seja, atende no padrão; - gerenciamento projeto trabalhoso, sem marcos tradicionais;- só vale ser tecnologia for conhecida;- requer profissionais comprometidos, pois equipe tem que

trabalhar num ritmo profundo de sintonia.

16

Utilizado quando os requisitos estão confusos. Auxilia cliente e desenvolvedor a entender o que se deseja do software. Pode ser aplicado a qualquer um dos modelos da Engenharia de Software.

Um protótipo executável é criado rapidamente, utilizando ferramentas de lay-out e componentes reutilizáveis, mas geralmente não tem a qualidade que o produto final reprojetado terá e quando cumpre sua função de clarear os requisitos, é descartado totalmente ou em partes.

ModelosIncrementalCascata RAD Prototipação Espiral

17

PrototipaçãoPontos positivos e negativos

(+)- um dos melhores aliados no entendimento do escopo;- materializa o escopo;- antecipa visualização de problemas;- auxilia nas fases de comunicação de todos os demais

modelos;(-)- o cliente exige que o protótipo evolua em software definitivo;- desenvolvedor pode se acostumar com baixa qualidade de

desenvolvimento;- requer investimento que não fará parte do software definitivo

18

Modelos

Combina os aspectos controlados e sistemáticos do modelo em cascata com a natureza iterativa da prototipagem. Possui uma abordagem cíclica para incrementar o nível de entendimento e implementação ao mesmo tempo que diminui o grau de risco. Além disso possui marcos para entregas. As primeiras versões entregues podem ser papel, mas as últimas são completas. São realizados vários circuitos em espiral ao longo da vida do software.

Veja na Web: www.sei.cmu.edu/cbs/spiral2000


19

EspiralPontos positivos e negativos

(+)- busca infinitamente a qualidade, busca erro tendendo a zero;- participação de profissionais altamente qualificados;- pode apoiar na produção de softwares altamente complexos;- pode entregar produtos relativos ao ciclo de desenvolvimento

(requisitos, protótipos, codificação...);- as versões entregues são sempre evoluções das anteriores. (-)- processo de desenvolvimento pode ser lento;- requer analistas de risco na equipe;- requer investimento de tempo e dinheiro;- requer marcos claros nas entregas;- se não for controlado, pode nunca ter fim.

20


Flexibilização – Capacidade de adaptar o produto ou o processo às várias mudanças que frequentemente acontecem em relação ao ambiente, ao escopo, à equipe envolvida, seja para eliminar erros ou para se adaptar a uma nova realidade.

Generalização – Capacidade de projetar um componente que possa ser reutilizado em mais de um ponto do sistema a ser desenvolvido, ao invés de ter várias soluções especializadas.

Decomposição – Decomposição é um principio que nos auxilia a lidar com a complexidade. Todas as vezes que nos deparamos com algo muito complexo, a melhor maneira de começar a entender tal complexidade é subdividir o processo complexo em atividades específicas. Tais atividades podem ser atribuídas a profissionais com perfis diferenciados para que cada um possa resolver a complexidade daquele quinhão que lhe foi atribuído.

Abstração – Habilidade de obter uma visão da realidade diferente da visão do todo, e naturalmente uma visão que em geral é reduzida em relação à visão do todo. Na abstração podem ser ignorados alguns detalhes presentes na visão do todo, mas que não são importantes na visão reduzida que se criou. A visão reduzida é construída segundo um objetivo específico que se queira alcançar num determinado momento do desenvolvimento de um produto.

Formalidade – O desenvolvimento de software é uma atividade criativa e como tal está muito relacionada à inspiração domomento e toda inspiração vem de uma maneira não estruturada. O princípio da formalidade deve estar presente todas asvezes que for necessário documentar, esquematizar, prototipar, registrar alguma idéia de maneira que ela saia do mundo abstrato e passe a vigorar no mundo concreto

Princípios

21


22

Sistema

Sistemas de Software

Sistemas sócio técnicos Sistemas baseados

em computadores

“Um conjunto de elementos concretos ou abstratos entre os quais se pode estabelecer uma relação”

Produtos entregues ao usuário, contendo vários artefatos envolvidos na sua produção,

tais como documentação, executáveis, estrutura de dados, manuais...

Sistemas críticos

ConfiáveisDisponíveis

Seguros

23

Comun

icaçã

oPl

aneja

men

toMod

elage

mCon

struç

ãoIm

plant

ação


Opera

ção

Desati

vaçã

o

24


Segundo Myers, o custo da correção de um defeito tende a ser cada vez maior tanto mais tarde ele for corrigido.

Ciclo V I D A

Cus

to

F A

L H

A

25

UP - Unified ProcessHistória

O Processo Unificado nasceu com um trabalho de Jacobson na Ericson, no final de 1960, quando modelaram um sistema muito grande de telecomunicações utilizando um modelo de camadas “em blocos”. Nesse modelo, as camadas inferiores serviam de subsídios para as camadas superiores. Esses blocos podem ser comparados ao que hoje chamamos de componentes. Os blocos de baixo foram construídos e chamados de “casos de tráfego”, hoje chamados de “casos de uso” na UML. Todo o trabalho subseqüente de análise, projeto, implementação, teste e implantação foi realizado com base nesses blocos chamados de “casos de tráfego”.

Em 1987 Jacobson deixou a Ericsson e fundou uma empresa chamada Objectory AB, ele e seus colegas despenderam vários anos desenvolvendo um processo e um produto chamado Objectory.

UP

Resolveu o dilema de ter que optar pelo melhor modelo para desenvolver. Ele reuniu o que há de bom em cada um dos modelos e criou um processo unificado!

26

UP - Unified Process“O processo de software deve ser, guiado por casos de uso, centrado em arquitetura, iterativo e incremental”

(Ivar Jacobson, Grady Booch e James Rumbaugh)

Por quê Casos de Uso? Por que a partir desse diagrama serão derivados todos os demais diagramas que irão guiar o desenvolvimento de software Orientado a Objeto.

Processo Unificado + UML (Unified Modeling Language) Unified Unifica em um único processo as melhores práticas de modelagem.Modeling Modelos = simplificação da realidade para entender aspectos complexos do desenvolvimento de um software. Alguns dos modelos da UML são: Casos de Uso, Classes, Atividades, Estado, Seqüência.Language Linguagem = por definição é algo que deve ser usado para descrever coisas.

A Língua Portuguesa é uma linguagem, mas saber falar português não significa ser poeta. Assim como saber construir um diagrama em UML não significa construir um software com uma arquitetura robusta.

Por quê Arquitetura? Porque quando se decide construir softwares orientados ao objeto é necessário que o plano arquitetônico seja bem construído e sempre revisado, permitindo que os componentes se harmonizem para produzir um software de qualidade.

Por quê Iterativo e Incremental? Porque são os melhores modelos que podem ser usados para entrega de um software em parte e garantir que a cada entrega o software está com mais qualidade.

Conceitos do Processo

27

UP - Unified Process - Processo Unificado

Conceito

Processo: conjunto de atividades executadas para transformar um conjunto de requisitos do cliente em um sistema de software.

Processo Unificado: Estrutura (framework) genérica de processo que pode ser customizado, adicionando-se ou removendo-se atividades com base nas necessidades e recursos de determinado projeto. Para se usar o Processo Unificado pode-se usar os elementos que agregam valor a um projeto específico e omitir os elementos que não agregam.

Comun

icaçã

o

Plan

ejam

ento

Modela

gem

Constr

ução

Impl

antaç

ão

Opera

ção

Desati

vaçã

o

28

Fonte: Adaptado de Pressman

Nas aulas anteriores foi dito que os modelos de desenvolvimento de software contém atividades comuns e que se repetem em todos os modelos são elas Comunicação, Planejamento, Modelagem, Construção, Implantação. Processo Unificado não é exceção a regra das atividades contidas naqueles modelos. Ele também contém todas aquelas atividades, que podemos chamar de atividade genéricas, porém as agrupa em 5 fases do Processo Unificado: CONCEPÇÃO, ELABORAÇÃO, CONSTRUÇÃO, TRANSIÇÃO e PRODUÇÃO.

UP - Unified ProcessFases

29

Fonte: Pressman

Fonte: RUP

RUP – Rational Unified Process

Fonte: Adaptado de Pressman

30

Fonte: RUP

RUP – Rational Unified Process

31

Dúvidas


Profa. Maria Lina Buscariolli [email protected]

Obrigada!

mailto:[email protected]

engenharia de software

Documents