Upload
portaldoestudanteads
View
2.483
Download
8
Embed Size (px)
Citation preview
ENGENHARIA DE ENGENHARIA DE SOFTWARESOFTWARE
RESUMO DA AULA ANTERIORRESUMO DA AULA ANTERIOR
DefinicaoDefinicao de de Engenharia de Engenharia de softwaresoftware
estabelecimento e uso de sestabelecimento e uso de sóólidos lidos princprincíípios de engenharia para:pios de engenharia para:
Minimizar custos de desenvolvimento Minimizar custos de desenvolvimento de software;de software;Software Software conficonfiáávelvel;;Software eficientemente;Software eficientemente;OrganizacaoOrganizacao;;Produtividade; eProdutividade; eSoftware de qualidadeSoftware de qualidade
Etapas da Eng. SoftwareEtapas da Eng. Software
Métodos
Como fazer
Ferramentas
Apoio automatizado –CASE Tools
Procedimentos
Definem a sequência em que os métodos são aplicados.
Ciclo de Vida clCiclo de Vida cláássico da ESssico da ES
Definição deRequisitos
Análise
Desenho
Implementação
Teste
Manutenção
Processo de Desenvolvimento
Definição (O quê?)- Analise e Planeamento:
o que será desenvolvido
Desenvolvimento (Como?)- Desenho, Codificacao e Teste:
como será desenvolvido
Manutenção (Mudanças?)- Correcao, adaptacao e perfeicao:
que mudanças ocorrerão depois
PARADIGMAS DA PARADIGMAS DA ENG. DE SOFTWAREENG. DE SOFTWARE
DefiniDefiniçção, Caracterizaão, Caracterizaçção, ão, Vantagens e Desvantagens.Vantagens e Desvantagens.
Paradigmas de Eng. de SoftwareParadigmas de Eng. de Software
IncrementalIncrementalRADRADIterativoIterativoFormalFormalEstruturadoEstruturadoLLóógicogicoEspiralEspiralEvolutivoEvolutivoOOOOCombinaCombinaççãoão de de ParadigmasParadigmasTTéécnicascnicas de de QuartaQuarta GeraGeraççãoão
Modelos de Ciclo deVida de Software
Paradigmas de Eng. de Software: Paradigmas de Eng. de Software: Escolha da Estrategia de deve Escolha da Estrategia de deve considerar:considerar:
Natureza do projecto;Tipo da aplicação;Métodos e ferramentas que serão usados;Métodos de controle;Prazo de entrega;Produtos que serão entregues.
IncrementalIncremental
Desenvolv.incremento
Validaçãoincremento
Integraçãoincremento
Requisitossuperficiais
Requisitosem
incrementos
Projecto da
arquitetura
Sistema incompleto
Sistemacompleto
Validação do
sistema
IncrementalIncremental
Desenvolvimento atravDesenvolvimento atravéés de incrementos s de incrementos sucessivas do âmbito do sistema;sucessivas do âmbito do sistema;O sistema O sistema éé alargado progressivamente;alargado progressivamente;Ao invés de entregar o sistema completo, divide-se o sistema em partes de tal forma a cada entrega corresponder a alguma funcionalidade do sistema;Requisitos do usuário são priorizados e quanto maior a prioridade, mais cedo tal funcionalidade deve ser entregue;Uma vez que o desenvolvimento de um incremento seja iniciado, esses requisitos são fixados enquanto que os posteriores são deixados serem modificados;
IncrementalIncremental -- VantagensVantagens
Esta abordagem Esta abordagem éé úútil paratil paraProblemas complexos;Problemas complexos;Recursos humanos insuficientes;Recursos humanos insuficientes;Datas de entrega inflexDatas de entrega inflexííveis.veis.
IncrementalIncremental -- VantagensVantagens
Solicitações dos clientes são entregues a cada incremento. Assim, as funcionalidades são entregues o mais cedo possívelIncrementos iniciais servem de protótipo para obter requisitos para incrementos posterioresDiminuição do risco de falha de todo o projetoServiços de maior prioridade tendem a receber maior ênfase em testes
RapidRapid ApplicationApplicationDevelopmentDevelopment (RAD)(RAD)
ÉÉ um modelo de processo de um modelo de processo de desenvolvimento de software desenvolvimento de software iterativo e iterativo e incrementalincremental;;O ciclo de desenvolvimento O ciclo de desenvolvimento éécurto (entre 60 e 90 dias).curto (entre 60 e 90 dias).
RapidRapid ApplicationApplicationDevelopmentDevelopment (RAD)(RAD)
ModeladoDa gestãoModeladoDa gestão
Modelado Dos dadosModelado Dos dados
Modelado Dos
processos
Modelado Dos
processos
Geração deAplicaçõesGeração deAplicações
Testes eentrega
Testes eentrega
ModeladoDa gestãoModeladoDa gestão
Modelado Dos dadosModelado Dos dados
Modelado Dos
processos
Modelado Dos
processos
Geração deAplicaçõesGeração deAplicações
Testes eentrega
Testes eentrega
ModeladoDa gestãoModeladoDa gestão
Modelado Dos dadosModelado Dos dados
Modelado Dos
processos
Modelado Dos
processos
Geração deAplicações
Geração deAplicações
Testes eentrega
Testes eentrega
Equipa 1 Equipa 2 Equipa 3
RAD RAD -- VantagensVantagensPermite o desenvolvimento rPermite o desenvolvimento ráápido e/ou a pido e/ou a prototipagemprototipagem de aplicade aplicaçções;ões;Enfatiza um ciclo de desenvolvimento Enfatiza um ciclo de desenvolvimento extremamente curto (entre 60 e 90 dias);extremamente curto (entre 60 e 90 dias);Cada funCada funçção principal pode ser ão principal pode ser direcionadadirecionadapara uma equipe RAD separada e então para uma equipe RAD separada e então integrada a formar um todo;integrada a formar um todo;CriaCriaçção e reutilizaão e reutilizaçção de componentes;ão de componentes;Visibilidade mais cedo (protVisibilidade mais cedo (protóótipos)tipos)Maior flexibilidade (desenvolvedores podem Maior flexibilidade (desenvolvedores podem experimentar praticamente a vontade)experimentar praticamente a vontade)Grande reduGrande reduçção de codificaão de codificaçção manual ão manual ((wizardswizards...);...);Envolvimento maior do usuEnvolvimento maior do usuáário;rio;ProvProváável custo reduzido (tempo vel custo reduzido (tempo éé dinheiro e dinheiro e tambtambéém devido ao m devido ao reusoreuso););
RAD RAD -- DesvantagensDesvantagens
Se uma aplicaSe uma aplicaçção não puder ser ão não puder ser modularizada de modo que cada funmodularizada de modo que cada funçção ão principal seja completada em menos de 3 principal seja completada em menos de 3 meses, não meses, não éé aconselhaconselháável o uso do RAD;vel o uso do RAD;Para projectos grandes (mas escalPara projectos grandes (mas escalááveis) o veis) o RAD exige recursos humanos suficientes RAD exige recursos humanos suficientes para criar o npara criar o núúmero correcto de equipes, mero correcto de equipes, isso implica em um alto custo com a isso implica em um alto custo com a equipe;equipe;O envolvimento com o usuO envolvimento com o usuáário tem que ser rio tem que ser activo;activo;Comprometimento da equipe do projecto;Comprometimento da equipe do projecto;
RAD RAD -- DesvantagensDesvantagens
O RAD O RAD não não éé aconselhaconselháávelvel quando os quando os riscos triscos téécnicos são altos e não cnicos são altos e não éé indicada indicada quando se estquando se estáá testando testando novas novas tecnologias;tecnologias;Menos eficientes;Menos eficientes;Perda de precisão cientPerda de precisão cientíífica (falta de fica (falta de mméétodos formais);todos formais);FunFunçções reduzidas (ões reduzidas (reusoreuso, ", "timeboxingtimeboxing");");Problemas legais;Problemas legais;Requisitos podem não se encaixar Requisitos podem não se encaixar (conflitos entre desenvolvedores e clientes)(conflitos entre desenvolvedores e clientes)Sucessos anteriores são difSucessos anteriores são difííceis de se ceis de se reproduzirreproduzir..
O RAD O RAD éé apropriado quandoapropriado quando
A aplicaA aplicaçção ão éé do tipo "do tipo "standalonestandalone";";A performance não A performance não éé o mais o mais importante;importante;A distribuiA distribuiçção do produto ão do produto éé pequena;pequena;O escopo do projecto O escopo do projecto éé restrito;restrito;O sistema pode ser dividido em O sistema pode ser dividido em vváários mrios móódulos independentes;dulos independentes;A tecnologia necessA tecnologia necessáária tem mais de ria tem mais de um ano de existência.um ano de existência.
O RAD deve ser evitado O RAD deve ser evitado quandoquando
A aplicaA aplicaçção precisa interagir com outros programas;ão precisa interagir com outros programas;Performance Performance éé essencial;essencial;O desenvolvimento não pode tirar vantagem de O desenvolvimento não pode tirar vantagem de ferramentas de alto nferramentas de alto níível;vel;A distribuiA distribuiçção do produto serão do produto seráá em grande escala;em grande escala;Para se construir sistemas operacionais Para se construir sistemas operacionais ((confiabilidadeconfiabilidade exigida alta demais)exigida alta demais)Jogos de computador (performance exigida muito Jogos de computador (performance exigida muito alta)alta)Riscos tecnolRiscos tecnolóógicos muito altos devido a tecnologia gicos muito altos devido a tecnologia ter sido recter sido recéém lanm lanççada;ada;O sistema não pode ser modularizado.O sistema não pode ser modularizado.
IterativoAplicação do modelo cascata
iterativamente;As iterações iniciais atacam os
maiores riscos;
IterativoIterativoOs requisitos do sistema SEMPRE mudam durante o desenvolvimentoIteração pode ser aplicado a qualquer um dos processos de desenvolvimentoDuas abordagens são destacadas:
Desenvolvimento incrementalDesenvolvimento em espiral.
IterativoDesenvolvimento iterativo antecipa a redução de riscos;Testes e integração são realizados desde o início, de forma contínua;Riscos críticos são resolvidos antes que grandes investimentos sejam realizados;Permite feedback dos usuários desde cedo;Pequenos objectivos, foco em curto-prazo;Progresso é medido de forma mais concreta;Implementações parciais podem ser implantadas;
FormalFormal
Definição derequisitos
Especificaçãoformal
Transformaçãoformal
Integração etestes
FormalFormal
MMéétodos formaistodos formaisEspecificaEspecificaçção matemão matemááticaticaExacta e rigorosaExacta e rigorosaDetecta e corrige requisitos Detecta e corrige requisitos incompletos, ambincompletos, ambííguos e guos e inconsistentesinconsistentes
FormalFormal
DesvantagensDesvantagensNecessita de profissionais altamente Necessita de profissionais altamente qualificados para aplicar a tqualificados para aplicar a téécnicacnicaAlguns aspectos ainda são difAlguns aspectos ainda são difííceis de ceis de especificar (GUI)especificar (GUI)
VantagensVantagensGarantia de seguranGarantia de segurançça e a e confiabilidadeconfiabilidade
AplicaAplicaççõesõesSistemas crSistemas crííticos e complexosticos e complexos
CascataCascataVVáárias actividades executadas de forma rias actividades executadas de forma sistemsistemáática e sequencialtica e sequencial
CascataCascataUm dos mais antigos, e ainda um dos mais Um dos mais antigos, e ainda um dos mais usados!usados!VVáárias actividades executadas deforma rias actividades executadas deforma sistemsistemáática e sequencial;tica e sequencial;Fixa pontos especFixa pontos especííficos para a entrega de ficos para a entrega de artefactos;artefactos;ÉÉ simples e fsimples e fáácil de aplicar, facilitando o cil de aplicar, facilitando o planeamento;planeamento;Na prNa práática, existe uma interactica, existe uma interacçção entre as ão entre as atividades e cada atividade pode levar a atividades e cada atividade pode levar a modificamodificaçções nas anteriores;ões nas anteriores;Pressupõe que os requisitos ficarão Pressupõe que os requisitos ficarão estestááveis;veis;Atrasa a reduAtrasa a reduçção de riscos.ão de riscos.
Cascata Cascata -- VantagensVantagens
Padroniza os métodos para análise, projecto, codificação, testes e manutenção.Etapas semelhantes às etapas genéricas aplicáveis a todos os paradigmas;OrientadoOrientado a a documentadocumentaççãoão;;ManutenManutenççãoão éé maismais simples.simples.
Cascata Cascata -- DesvantagensProjectos reais raramente seguem o fluxo sequencial que esse modelo propõe. Sempre ocorre alguma interacção e/ou superposição;Dificilmente os clientes são capazes de relacionar todos os requisitos de uma sóvez no início do projecto;Maioria dos programas só estarádisponível quando o cronograma já estábastante adiantado;Dificuldades para se introduzir alterações quando o processo está avançado;Dificuldade para lidar com as mudanDificuldade para lidar com as mudançças as nos requisitos do sistemanos requisitos do sistemaNão gere riscosNão gere riscos
EspiralEspiral
EspiralEspiral
AnAnáálise de riscos como ferramenta;lise de riscos como ferramenta;Essencial para o planeamento e Essencial para o planeamento e gestão do projecto;gestão do projecto;Dificuldades para fechar o contrato;Dificuldades para fechar o contrato;Complexo e requer experiência na Complexo e requer experiência na avaliaavaliaçção de riscos!ão de riscos!
Espiral Espiral -- VantagensVantagens
Modelo evolutivo possibilita uma maior integração entre as fases e facilita a depuração e a manutenção do sistema.Permite que o projectista e cliente possa entender e reagir aos riscos em cada etapa evolutiva.FFáácilcil de de decidirdecidir o o quandoquando testartestar
Espiral Espiral -- DesvantagensDesvantagens
Avaliação dos riscos exige muita experiência;O modelo é relativamente novo e não tem sido amplamente utilizado;BemBem aplicadoaplicado somentesomente a a sistemassistemasde de largalarga escalaescala;;SistemasSistemas devemdevem ser ser produtosprodutosinternosinternos dada empresaempresa..
44ªª GeraGeraççãoão
Ferramentas de 4Ferramentas de 4ªª GeraGeraççãoãoSuporte automatizado Suporte automatizado ààespecificaespecificaçção de requisitosão de requisitos..
A ferramenta gera A ferramenta gera codigocodigo--fontefonte, , na base da especna base da especificaificaççãoão do do desenvolvedor;desenvolvedor;
CombinaCombinaçção de Paradigmasão de Paradigmas
Os paradigmas para a Os paradigmas para a Engenharia de Software Engenharia de Software alcancamalcancam melhores resultados melhores resultados quando combinadas. quando combinadas. ExemExemploplo::
Espiral resulta da Espiral resulta da combinacaocombinacaoentre a Prototipacao e cascata entre a Prototipacao e cascata numa abordagem revolucionaria.numa abordagem revolucionaria.
EvolutivoEvolutivo
Atividadesconcorrentes
Especificação
Desenvolvimento
Validação
Versãoinicial
Versãofinal
Versõesintermediárias
Descriçãosuperficial
EvolutivoEvolutivo
Desenvolvimento exploratDesenvolvimento exploratóório rio (Prot(Protóótipo evoluciontipo evolucionáário)rio)
Construa, avalie e evolua para produtoConstrua, avalie e evolua para produtoTrabalhar com os clientes atTrabalhar com os clientes atéé se obter o se obter o produto final a partir de uma especificaproduto final a partir de uma especificaçção ão bembem--definidadefinida e completa do sistema.e completa do sistema.
ProtProtóótipo descarttipo descartáávelvelConstrua, use e descarteConstrua, use e descarte
Obter requisitos do cliente. IniciaObter requisitos do cliente. Inicia--se com se com uma especificauma especificaçção incompleta e simples do ão incompleta e simples do sistemasistema
EstruturadoEstruturado
Orientado a ObjectosOrientado a Objectos
Métodos OO são voltados principalmente para sistemas complexos, que devem ser divididos para a distribuição dos trabalhos pela equipe;A abordagem OO se baseia em um desenvolvimento onde fases teoricamente já completadas são revistas continuamente, e alteradas se preciso;Iterativo e Iterativo e incrementalincremental..
Orientado a ObjectosOrientado a Objectos
recursivo(modelo evolutivo)
paralelo(reutilização de componentes)
desenvolver novas classes,se não existem
adicionar novas classes à biblioteca
construir n-ésimaiteração do sistema
Análise de Riscos
Engenhariae Construção
Baseado em componentes Baseado em componentes UnifiedUnified DevelopmentDevelopment ProcessProcessUtiliza UML Utiliza UML
Identificar classes candidatas
buscar classes na biblioteca
extrair classes, se existem
SelecSelecçção do Modeloão do Modelo
Projectos pequenos: ciclo Projectos pequenos: ciclo clcláássicossicoLimites severos de tempo: RADLimites severos de tempo: RADData entrega muito prData entrega muito próóxima: xima: modelo modelo incrementalincremental..Sistemas Complexos com Sistemas Complexos com muitas mudanmuitas mudançças de Requisitos: as de Requisitos: Orientadas a Objectos;Orientadas a Objectos;
BIBLIOGRAFIABIBLIOGRAFIA
Gerry Coleman and Gerry Coleman and RenaatRenaat VerbruggenVerbruggen. A. A quality quality software process for rapid application developmentsoftware process for rapid application development, , Software Quality Journal 7, pp. 107Software Quality Journal 7, pp. 107--122, 1998.122, 1998.
Software Software EngineeringEngineering. I.Somme. I.Sommervillerville;;
Engenharia de Software, Engenharia de Software, RogerRoger S. S. PressmanPressman, 3., 3.ªªEdiEdiççãoão..
A Discipline for Software A Discipline for Software EngineeringEngineering. . W.S.HumphreyW.S.Humphrey;;
httphttp://://pt.wikipedia.orgpt.wikipedia.org/wi/wikiki/En/Engenharia_de_softwaregenharia_de_software, , de 9/de 9/FevFev/2007/2007
TPCTPC1.1. FacaFaca um um estudoestudo comparativocomparativo dos dos seguintesseguintes
paradigmasparadigmas::a.a. Evolutivo e Espiral;Evolutivo e Espiral;b.b. IncrementalIncremental e Iterativo;e Iterativo;c.c. Estruturada e OO;Estruturada e OO;
2.2. Para cada uma das Para cada uma das situacoessituacoes que modelo usaria que modelo usaria para desenvolvimento de Software:para desenvolvimento de Software:
a.a. Tempo reduzido (60 dias);Tempo reduzido (60 dias);b.b. Sistema complexo, com muitos riscos;Sistema complexo, com muitos riscos;c.c. Sistema com uma dimensão muito reduzida;Sistema com uma dimensão muito reduzida;d.d. Sistema critico com alta precisão de Sistema critico com alta precisão de
processamento (logico ou matemprocessamento (logico ou matemáático);tico);e.e. ImplementaImplementaçção de um jogo de entretenimento;ão de um jogo de entretenimento;
3.3. Para o desenvolvimento de um software para Para o desenvolvimento de um software para gestaogestao de registos academicos da UST, que com de registos academicos da UST, que com binbinacaoacao de modelos usaria? Justifique a sua de modelos usaria? Justifique a sua escolha.escolha.