engenharia de software revisão b1. 2 conceitos o que é hardware ? parte tangível de um...
TRANSCRIPT
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.
Engenharia de Software
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 que é Engenharia de Software?
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.”
O que é Engenharia de Software?
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.
IncrementalCascata RAD Prototipação Espiral
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.
IncrementalCascata RAD Prototipação Espiral
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
IncrementalCascata RAD Prototipação Espiral
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
O que é Engenharia de Software?
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
O que é Engenharia de Software?
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
Ciclo de Vida de Sistemas de Software.
Opera
ção
Desati
vaçã
o
24
Ciclo de Vida de Sistemas de Software.
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