ENGENHARIA DE SOFTWARE

Transcrição

1 ENGENHARIA DE SOFTWARE Processos de Software Etapas do processo de software Modelos de ciclo de vida de software Kele Teixeira Belloze

2 PROCESSO DE DESENVOLVIMENTO DE SOFTWARE

3 ELEMENTOS DA ENGENHARIA DE SOFTWARE A Engenharia de Software (ES) compreende um conjunto de etapas que envolve processos, métodos e ferramentas.

4 ELEMENTOS DA ES Processo Define os passos gerais para o desenvolvimento e manutenção do software Serve como uma estrutura de encadeamento de métodos e ferramentas Métodos São os how to s, como fazer um passo específico do processo Ferramentas Automatizam o processo e os métodos Leonardo Murta Revisão de ES I

5 CARACTERÍSTICAS DE UM PROCESSO Tecnologicamente competitivos, adaptáveis e adequados com relação ao tempo Capazes de produzir produtos que atingem as necessidades do cliente e do negócio Adequados à cultura organizacional

6 DESCRIÇÃO DE UM PROCESSO Pode ser descrito em termos de: Propósito/Resultado Tipo de definição útil quando não se quer definir as atividades de forma detalhada, mas sabe-se o objetivo do processo (propósito) e os resultados que este deve produzir Atividades É a abordagem mais comum, onde são descritas as atividades e suas inter-relações, bem como a sequência de execução de cada atividade Cada atividade deve conter: procedimentos e métodos, ferramentas de apoio, artefatos de entrada e de saída, responsáveis etc.

7 EXEMPLO: PROCESSO COZINHAR (1/4) Defina o processo em termos de Propósito/Resultado Propósito: Fornecer o prato de comida ao cliente de acordo com o pedido Resultados: Um pedido que indica o prato de comida a ser produzido é comunicado ao cozinheiro Um prato de comida é preparado O garçom é avisado que o prato de comida está preparado Leonardo Murta Revisão de ES I

8 EXEMPLO: PROCESSO COZINHAR (2/4) Defina o processo em termos de Atividades Artefato de Entrada: Pedido solicitado Atividades: O pedido é impresso na cozinha na ordem em que foi solicitado; É verificado qual a comida a ser produzida; Os ingredientes que serão utilizados para preparar a comida são separados; A comida é preparada de acordo com a receita pré-definida; A comida é colocada no prato em que será servida; O prato de comida é decorado; O prato de comida é colocado no passa-prato para o garçom pegar; O garçom é avisado que o prato de comida referente ao pedido X está pronto.

9 EXEMPLO: PROCESSO COZINHAR (3/4) Defina o processo em termos de Atividades Responsável: cozinheiro Artefato de Saída: Prato de comida pronto Ferramentas: Sistema automatizado de pedidos sistema luminoso de aviso ao garçom indicando que o pedido está pronto

10 EXEMPLO: PROCESSO COZINHAR (4/4) Defina o processo em termos de Atividades Métodos: receita detalhada Treinamento: cozinheiro ter feito curso de culinária e ter feito estágio como ajudante de cozinha do chef do restaurante por no mínimo 3 meses Métrica do processo: Número de pratos devolvidos por não ser o solicitado Quantidade de comida deixada no prato pelo cliente

11 POR QUE DEFINIR PROCESSOS? Alguns benefícios: Facilitar o entendimento e a comunicação entre pessoas Apoiar a melhoria dos processos Apoiar a gerência dos processos Fornecer apoio automatizado guiando no processo Fornecer apoio na execução automatizada do processo

12 PROCESSO DE SOFTWARE (1/2) Definições (Sommerville) Processo de Software Conjuntos de atividades para especificação, projeto, implementação e teste de sistemas de software Modelo de Processo Software Um modelo de processo de software é uma representação abstrata de um processo Apresenta a descrição de um processo a partir de uma perspectiva particular

13 PROCESSO DE SOFTWARE (2/2) Um processo de desenvolvimento de software define: Um ciclo de vida para o software e um paradigma Os métodos que serão utilizados durante o desenvolvimento As ferramentas que apoiarão estes métodos Os papéis das pessoas envolvidas no desenvolvimento

14 ETAPAS GENÉRICAS DO PROCESSO DE SOFTWARE

15 ETAPAS GENÉRICAS DO PROCESSO DE SOFTWARE (1/4) Comunicação Envolve a alta comunicação e colaboração com o cliente e abrange o levantamento de requisitos e outras atividades relacionadas. Planejamento Estabelece um plano para o trabalho de engenharia de software que se segue. Descreve as tarefas técnicas a ser conduzidas, os riscos prováveis, os recursos que serão necessários, os produtos de trabalho a ser produzidos e um cronograma do trabalho. Modelagem Inclui a criação de modelos que permitam ao desenvolvedor e ao cliente, entender melhor os requisitos do software e o projeto que vai satisfazer a esses requisitos.

16 ETAPAS GENÉRICAS DO PROCESSO DE SOFTWARE (2/4) Construção Combina geração de código e os testes necessários para revelar erros no código. Implantação O software é entregue ao cliente, que avalia o produto entregue e fornece feedback com base na avaliação.

17 ETAPAS GENÉRICAS DO PROCESSO DE SOFTWARE (3/4) Essas cinco etapas genéricas são aplicáveis à grande maioria dos projetos de software. Os detalhes do processo de software podem ser diferentes em cada caso, mas as etapas genéricas permanecem as mesmas.

18 ETAPAS GENÉRICAS DO PROCESSO DE SOFTWARE (4/4) Atividades Guarda Chuva: transversais às demais etapas Gestão de projeto de software (acompanhamento e controle) Gestão de riscos Gestão de mudanças Garantia de qualidade de software Revisões técnicas formais Medição Gestão de configuração de software Gestão de reutilização Preparação e produção de documentos

19 MODELOS DE CICLO DE VIDA DO SOFTWARE

20 CICLO DE VIDA DO DESENVOLVIMENTO DE SOFTWARE É um processo utilizado por um analista de sistemas para desenvolver um sistema de informação É um roteiro, um conjunto de passos bem definidos, que permite o uso de uma ou várias técnicas para o desenvolvimento de um sistema de informação

21 MODELOS DE CICLO DE VIDA (1/3) Existem alguns processos pré-fabricados Esses processos são conhecidos como modelos de ciclo de vida Eles apresentam características predefinidas Um modelo de processo de desenvolvimento de software é uma representação abstrata de um processo. Ele representa uma descrição do processo de uma perspectiva particular. Leonardo Murta

22 MODELOS DE CICLO DE VIDA (2/3) Estes modelos são escolhidos considerando: Domínio da aplicação Os métodos e as ferramentas a serem usadas Os produtos que precisam ser entregues As características do grupo desenvolvedor O grau de conhecimento sobre o problema Características do cliente

23 Para continuar o entendimento PROCESSOS DIRIGIDOS A: PLANOS X ÁGEIS Processos dirigidos a planos são processos em que todas as atividades do processo são planejadas com antecedência e o progresso é medido em relação a esse plano. Não é necessariamente um modelo em cascata, isto é, desenvolvimento dirigido a planos e incremental é possível. Iterações ocorrem em conjunto com as atividades. Nos processos ágeis, especificação, modelagem, implementação e teste são intercalados e as saídas do processo de desenvolvimento são decididas por um processo de negociação durante o processo de desenvolvimento de software. Leonardo Murta É mais fácil modificar o processo para refletir alterações nos requisitos do cliente.

24 MODELOS DE CICLO DE VIDA (3/3) Em síntese, existem três estilos de modelos de ciclo de vida: Modelo Cascata: modelo dirigido a planos. Fases de especificação e desenvolvimento separadas e distintas. Desenvolvimento Incremental: especificação, desenvolvimento e validação são intercaladas. Pode ser dirigido a planos ou ágil. Engenharia de software orientada a reuso: o sistema é montado a partir de componentes já existentes. Pode ser dirigido a planos ou ágil. Na realidade a maioria dos grandes sistemas são desenvolvidos usando um processo que incorpora elementos de todos esses modelos.

25 MODELO EM CASCATA OU CICLO DE VIDA CLÁSSICO

26 CICLO DE VIDA CLÁSSICO (CVC) (1/11) Às vezes chamado modelo cascata ou sequencial O modelo do ciclo de vida clássico requer uma abordagem sistemática, sequencial ao desenvolvimento de software que se inicia no nível do sistema e avança ao longo da análise, projeto, codificação, teste e manutenção

27 CICLO DE VIDA CLÁSSICO (2/11) Engenharia de Sistemas Análise de Requisitos Projeto Implementação /Codificação Teste Manutenção

28 CICLO DE VIDA CLÁSSICO (3/11) Composto por uma determinada sequência de atividades Uma atividade começa a ser executada quando a anterior termina Resultado de uma etapa é utilizado na etapa seguinte Guiado por documentos Ciclo de vida mais antigo e ainda muito utilizado

29 CICLO DE VIDA CLÁSSICO (4/11) Engenharia de Sistemas Requisitos amplos, a nível de sistema, que podem envolver hardware, banco de dados,... Como o software sempre faz parte de um sistema mais amplo, o trabalho inicia-se com o estabelecimento dos requisitos para todos os elementos do sistema e prossegue com a atribuição de certo subconjunto desses requisitos ao software Esta visão do sistema é essencial quando o software deve fazer interface com outros elementos, tais como hardware, pessoas e banco de dados

30 CICLO DE VIDA CLÁSSICO (5/11) Análise de Requisitos de Software Domínio da informação, função, desempenho, interfaces Processo da coleta dos requisitos é intensificado e concentrado especificamente no software Para entender o sistema a ser construído, o analista deve compreender o domínio da informação para o software, bem como a função, desempenho e interface exigidos Os requisitos tanto para o sistema como para o software, são documentados e revistos com o cliente

31 CICLO DE VIDA CLÁSSICO (6/11) Projeto Estruturas de dados, arquitetura de software, especificação de programas, detalhamento de interfaces O projeto é de fato, um processo de múltiplos passos que se concentra nos quatro atributos distintos do programa citados O processo de construção do projeto traduz as exigências numa representação do software que pode ser avaliada quanto à qualidade antes que a codificação se inicie Como os requisitos, o projeto é documentado e torna-se parte da configuração do software

32 CICLO DE VIDA CLÁSSICO (7/11) Implementação/Codificação O projeto deve ser traduzido em uma linguagem de programação

33 CICLO DE VIDA CLÁSSICO (8/11) Teste Assim que que a codificação termina iniciam-se os testes de programa Aspectos lógicos: garantir que todas as instruções foram testadas Aspectos funcionais: realizam-se testes para descobrir erros e garantir que todas as entradas definidas produzam resultados reais e esperados

34 CICLO DE VIDA CLÁSSICO (9/11) Manutenção Mudanças no software após ser entregue ao cliente. Estas mudanças podem ocorrer devido: Erros Alterações no ambiente externo (troca de sistema operacional; novo periférico; etc...) Cliente solicita acréscimos/alterações funcionais ou de desempenho A manutenção reaplica cada uma das etapas precedentes do ciclo de vida a um programa existente, e não a um novo

35 CONSIDERAÇÕES (10/11) Problemas: Não lida bem com incertezas Fornece pouca visibilidade do estado do projeto Versão do trabalho disponível em um ponto tardio do cronograma Tempo longo para a primeira entrega Dificuldade na obtenção de feedback do cliente Erros detectados em fases tardias causam problemas maiores Projetos reais raramente seguem o fluxo sequencial que o modelo propõe Muitas vezes é difícil para o cliente declarar todas as exigências explicitamente Dificuldade de acomodação de mudanças depois que o processo foi iniciado. Em princípio, uma fase precisa ser completada antes de se mover para a próxima fase.

36 CONSIDERAÇÕES (11/11) Pontos Positivos: Tem lugar definido e importante na ES É significativamente melhor do que uma abordagem casual ao desenvolvimento de software Útil quando se tem requisitos estáveis e bem definidos Apropriado quando os requisitos são bem entendidos e as mudanças durante o processo de projeto serão limitadas. Etapas do modelo de ciclo de vida clássico são muito semelhantes às etapas genéricas aplicadas a todos os paradigmas

37 RAPID APPLICATION DEVELOPMENT (RAD)

38 RAD (1/4) Enfatiza um ciclo de desenvolvimento curto Funcionamento equivalente ao cascata Adaptação de alta velocidade Abordagem de construção baseada em componentes Leonardo Murta Introdução à ES

39 RAD (2/4) Modelagem Construção Comunicação Planejamento Modelagem Construção Integração e Implantação... Modelagem Construção dias Modelagem: Modelagem de negócio Modelagem de dados Modelagem de processo Leonardo Murta Construção: Reuso de componentes Geração automática de código Teste Introdução à ES

40 RAD (3/4)

41 RAD (4/4) Principais diferenças em relação ao Cascata Visa entregar um sistema funcional dentro de um período curto (ex.: de 60 a 90 dias) Múltiplas equipes trabalham em paralelo na modelagem e construção Assume a existência de componentes reutilizáveis e geração automática de código Difícil de ser utilizado em domínios novos ou instáveis Leonardo Murta

42 MODELOS EVOLUTIVOS (ITERATIVOS) - Incremental - Prototipação - Espiral

43 DESENVOLVIMENTO EVOLUTIVO O software evolui durante um período de tempo Requisitos do negócio e do produto mudam à medida que o desenvolvimento prossegue Prazos reduzidos de mercado exigem versão reduzida Os modelos evolucionários são iterativos e permitem o desenvolvimento de versões cada vez mais completas do software Para a maioria dos grandes sistemas, existe a necessidade de utilizar diferentes abordagens para diferentes partes do sistema Abordagem híbrida

44 CASCATA X EVOLUTIVO Ciclo de vida cascata Ciclo de vida evolutivo

45 MAS O QUE É ITERATIVO? Iteração Repetir partes do processo à medida que os requisitos do sistema evoluem Por exemplo, deve-se refazer (ou complementar) o projeto do sistema e sua implementação para incluir novos requisitos Cada ciclo desenvolve uma versão mais completa

46 DESENVOLVIMENTO ITERATIVO O desenvolvimento é organizado em mini-projetos Cada mini-projeto é uma iteração Cada iteração tem duração curta e fixa (de 2 a 6 semanas) Cada iteração tem atividades de análise, projeto, programação e testes O produto de uma iteração é um software parcial X semanas X semanas X semanas... Software Software Software

47 DESENVOLVIMENTO ITERATIVO A iteração deve ser fixa A iteração nunca deve passar da duração estipulada Tarefas podem ser removidas ou incluídas O resultado de cada iteração é um software... Incompleto Em desenvolvimento Mas não é um protótipo! Esse software pode ser verificado e validado parcialmente Testes Usuários Podem ser necessárias várias iterações (10 a 15) para ter uma versão do sistema pronta para entrar em produção Leonardo Murta Revisão de ES I 47

48 DESENVOLVIMENTO ITERATIVO Iterações curtas privilegiam a propagação de conhecimento Aumento do conhecimento sobre o software Diminuição das incertezas, que levam às mudanças Revisão de ES I 48

49 DESENVOLVIMENTO EVOLUTIVO As especificações evoluem a cada iteração A cada iteração, uma parte do software fica pronta O conhecimento sobre o software aumenta As especificações são evoluídas para retratar esse aumento de conhecimento sobre o que é o software Leonardo Murta Revisão de ES I 49

50 DESENVOLVIMENTO EVOLUTIVO Mudanças sempre acontecem em projetos de software Requisitos mudam O ambiente em que o software está inserido muda As pessoas que operam o software mudam Estratégias para lidar com mudanças Evitar as mudanças (corretivas) fazendo uso de boas técnicas de engenharia de software Acolher mudanças por meio de um processo evolutivo Leonardo Murta Revisão de ES I 50

51 MODELO INCREMENTAL

52 Funcionalidades e Características do Projeto MODELO INCREMENTAL (1/5) Incremento 3 Comunicação Incremento 1 Comunicação Planejamento Modelagem Construção Implantação Incremento 2 Comunicação Planejamento Modelagem Construção Implantação Entrega 2 Planejamento Modelagem Construção Implantação Entrega 3 Entrega 1 núcleo do produto Tempo do Projeto

53 MODELO INCREMENTAL (2/5) Faz entregas incrementais do software Cada incremento é construído via um mini-cascata Cada incremento é um software operacional Versões anteriores ajudam a refinar o plano Feedback constante do cliente Diminuição da ansiedade do cliente O cliente rapidamente recebe uma versão funcional do software

54 MODELO INCREMENTAL (3/5)

55 MODELO INCREMENTAL (4/5) Benefícios O custo para acomodar mudanças nos requisitos do cliente é reduzido. A quantidade de análise e documentação que precisa ser feita é bem menor do que o necessária no modelo cascata. É mais fácil obter feedback do cliente sobre o trabalho de desenvolvimento que tem sido feito. Os clientes podem comentar demonstrações do software e ver quanto foi implementado. Possibilidade de mais rapidez na entrega e implantação de software útil para o cliente. Os clientes podem usar e obter ganhos do software mais cedo do que é possível no processo cascata.

56 MODELO INCREMENTAL (5/5) Problemas Devido à rapidez, o processo não é visível para a gerência. (E para o cliente/usuário?) Gerentes precisam de entregas regulares para medir o progresso. Se os sistemas são desenvolvidos de forma rápida, não é viável do ponto de vista do custo produzir documentação para refletir todas as versões do sistema. A estrutura do sistema tende a degradar conforme novos incrementos são adicionados. (depende da experiência dos projetistas e desenvolvedores com o tipo de sistema) A menos que tempo e dinheiro sejam gastos na reconstrução para melhorar o software, as mudanças regulares tendem a corromper a estrutura do sistema. A incorporação posterior de mudanças no software se torna progressivamente mais difícil e cara. (REFATORAÇÃO e REÚSO)

57 ENTREGA INCREMENTAL (1/2) Ao invés de entregar o sistema em uma única entrega, o desenvolvimento e a entrega são distribuídos em incrementos, nos quais cada incremento entrega parte da funcionalidade necessária. Os requisitos do usuário são priorizados e os requisitos de mais alta prioridade são incluídos nos primeiros incrementos. Assim que o desenvolvimento de um incremento é iniciado os requisitos são congelados, mas os requisitos dos incrementos posteriores podem continuar a evoluir.

58 ENTREGA INCREMENTAL (2/2)

59 DESENVOLVIMENTO E ENTREGA INCREMENTAL Desenvolvimento incremental Desenvolve o sistema em incrementos e avalia cada incremento antes de proceder com o desenvolvimento do próximo incremento; Abordagem normalmente usada em métodos ágeis; Avaliação feita por representantes do usuário/cliente. Entrega incremental Implanta um incremento para uso do usuário-final; Avaliação mais realística sobre o uso prático do software; Difícil de implementar para sistemas substitutos devido aos incrementos possuírem menos funções do que o sistema que está sendo substituído.

60 VANTAGENS DA ENTREGA INCREMENTAL Funções do sistema ficam disponíveis mais rapidamente. Primeiros incrementos agem como protótipos para ajudar a deduzir requisitos para incrementos posteriores. Menor risco de falha geral do projeto. Os serviços mais prioritários do sistema tendem a ser mais testados.

61 PROBLEMAS DA ENTREGA INCREMENTAL A maioria dos sistemas requer um conjunto de funções básicas que são usadas por diferentes partes do sistema. Como os requisitos não são definidos em detalhes até que um incremento seja implementado, pode ser difícil identificar funções comuns que são necessárias a todos os incrementos. A essência dos processos iterativos é que a especificação seja desenvolvida em conjunto com o software. No entanto, essa pode entrar em conflito com o modelo de aquisição de muitas organizações, nos quais a especificação completa do sistema é parte do contrato de desenvolvimento do sistema.

62 PROTOTIPAÇÃO

63 PROTOTIPAÇÃO (1/10) É um processo que capacita o desenvolvedor a criar um modelo do software que será implementado (similar a uma maquete em arquitetura)

64 PROTOTIPAÇÃO (2/10) Motivações: 1. O cliente definiu um conjunto de objetivos gerais para o software, mas não identificou requisitos de entrada, processamento e saída detalhados 2. O desenvolvedor pode não ter certeza da eficiência de um algoritmo, da adaptabilidade a um sistema operacional ou da forma que a interação homemmáquina deve assumir

65 PROTOTIPAÇÃO (3/10) Ou seja Em situações em que a incerteza está presente na definição de requisitos, objetivos e procedimentos, a prototipagem pode representar uma abordagem interessante

66 PROTOTIPAÇÃO (4/10) O modelo da prototipação pode assumir uma das três seguintes formas: 1. Um protótipo em papel ou modelo baseado em computador que retrata a interação homem-máquina de maneira a capacitar o cliente (usuário) a entender quanta interação ocorrerá 2. Um protótipo de trabalho que implementa algum subconjunto da função exigida do software 3. Um programa que executa parte ou toda a função desejada, mas que tem outras características que serão melhoradas em um novo esforço de desenvolvimento

67 PROTOTIPAÇÃO (5/10) Usualmente utilizado como auxílio a outro modelo de ciclo de vida

68 PROTOTIPAÇÃO (6/10) O desenvolvedor e o cliente se reúnem e definem os objetivos globais para o software, identificam as exigências conhecidas e esboçam as áreas em que uma definição adicional é obrigatória Ocorre a elaboração de um projeto rápido que se concentra na representação daqueles aspectos do software que serão visíveis ao usuário (abordagens de entrada e formatos de saída)

69 PROTOTIPAÇÃO (7/10) O projeto rápido leva à construção de um protótipo que é avaliado pelo cliente/usuário e é usado para refinar os requisitos para o software a ser desenvolvido Um processo de iteração ocorre quando é feita uma sintonia fina do protótipo para satisfazer as necessidades do cliente, capacitando, ao mesmo tempo, o desenvolvedor a compreender melhor aquilo que precisa ser feito

70 PROTOTIPAÇÃO (8/10) Os protótipos devem ser descartados depois do desenvolvimento, pois não são uma boa base para um sistema em produção: Pode ser impossível ajustar o sistema para alcançar requisitos não funcionais; Geralmente os protótipos não possuem documentação; Geralmente a estrutura do protótipo é degradada por mudanças rápidas; Provavelmente o protótipo não irá alcançar os padrões normais de qualidade organizacional.

71 PROTOTIPAÇÃO (9/10) Benefícios: É um modelo eficiente da ES Cliente e desenvolvedor devem concordar que o protótipo seja construído para servir como um mecanismo a fim de definir os requisitos Depois será descartado (pelo menos em parte) e o software real será projetado Útil para: Validar um requisito obscuro com o cliente Verificar o desempenho de um algoritmo específico

72 PROTOTIPAÇÃO (10/10) Problemas: Protótipos não são produtos Cliente vê o protótipo como uma versão do software e exige a sua adequação para o produto, pensando no prazo e não considerando as questões de qualidade e manutenibilidade Apesar disto, alguns cliente tendem a desejar colocar protótipos em ambiente de produção Desenvolvedor faz concessões de implementação a fim de colocar um protótipo em funcionamento

73 MODELO ESPIRAL

74 MODELO ESPIRAL (1/7) Modelo também conhecido como Modelo Espiral de Boehm Foi desenvolvido para abranger as melhores características tanto do modelo de ciclo de vida clássico como da prototipação, acrescentando, ao mesmo tempo, um novo elemento a análise dos riscos Risco: é a possibilidade de ocorrência de algum evento que cause prejuízo ao processo de desenvolvimento juntamente com as consequências desse prejuízo. Influências: custos do projeto, cronograma, qualidade do produto, satisfação do cliente, etc.

75 MODELO ESPIRAL (2/7) Define quatro importantes atividades: Planejamento: determinação dos objetivos, alternativas e restrições Análise dos riscos: análise de alternativas e identificação/resolução dos riscos Engenharia: desenvolvimento do produto no nível seguinte Avaliação feita pelo cliente: avaliação dos resultados da engenharia

76 (3/7) Planejamento Análise de riscos Coleta inicial dos requisitos Análise dos riscos baseada nos requisitos iniciais Planejamento baseado nos comentários do projeto Análise dos riscos baseada na reação do cliente Avaliação do Cliente Protótipo de sw inicial Protótipo no nível seguinte Sistema construído pela engenharia Avaliação do Cliente Engenharia

77 MODELO ESPIRAL (4/7) A cada iteração ao redor da espiral, versões mais completas do software são construídas Durante o primeiro giro ao redor da espiral, os objetivos, alternativas e restrições são definidos e os riscos são identificados e analisados Se a análise dos riscos indicar que há incertezas nos requisitos, a prototipação pode ser usada no parte da engenharia para ajudar o desenvolvedor e o cliente Simulações e outros modelos podem ser usados para definir ainda mais o problema e refinar os requisitos

78 MODELO ESPIRAL (5/7) Mantém a abordagem de passos sistemáticos sugerida pelo modelo de ciclo de vida clássico, mas incorpora-a numa estrutura iterativa que reflete melhor o mundo real Exige uma consideração direta dos riscos técnicos em todas as etapas do projeto e se adequadamente aplicado, deve reduzir os riscos antes que eles se tornem problemáticos

79 MODELO ESPIRAL (6/7) Benefícios: O modelo espiral para a ES é uma abordagem realística para o desenvolvimento de sistemas e de software em grande escala Usa uma abordagem evolucionária à ES, capacitando o desenvolvedor e o cliente a entender e reagir aos riscos em cada etapa Usa a prototipação como um mecanismo de redução de risco, mas, o que é mais importante, possibilita que o desenvolvedor aplique a abordagem de prototipação em qualquer etapa da evolução do produto

80 MODELO ESPIRAL (7/7) Problemas: Pode ser difícil de convencer grandes clientes de que a abordagem evolutiva é controlável Exige considerável experiência na avaliação dos riscos Se um grande risco não for descoberto, ocorrerão problemas

81 DESENVOLVIMENTO ORIENTADO A REUSO - Desenvolvimento Baseado em Componentes

82 DESENVOLVIMENTO ORIENTADO A REUSO (1/8) Motivação O desenvolvimento de aplicações hoje em dia sofre grandes pressões: 1. Escalabilidade e complexidade estão em constante crescimento 2. A tecnologia da informação se tornou estratégica no contexto das empresas 3. Necessidade de garantia de qualidade das aplicações 4. Mudanças tecnológicas crescentes 5. Necessidade de interoperação com aplicativos de terceiros

83 DESENVOLVIMENTO ORIENTADO A REUSO (2/8) Motivação Os sistemas atuais devem estar aptos: Adaptar-se facilmente a mudanças: tecnológicas, organizacionais e de domínio Necessidade de melhoria no processo de desenvolvimento de software: maior produtividade e menor custo

84 DESENVOLVIMENTO ORIENTADO A REUSO (3/8) Motivação Requisitos das novas aplicações: Distribuição entre vários sites, acesso a dados de múltiplas fontes, interface para Web Solução: Uso de técnicas de reutilização de software para criação e reuso de componentes interoperáveis

85 DESENVOLVIMENTO ORIENTADO A REUSO (4/8) Incorpora as características do modelo espiral e compõe aplicações a partir de componentes de software previamente desenvolvidos ou desenvolvidos durante o processo Enfatiza a reutilização, isto é desenvolve para e com reuso

86 DESENVOLVIMENTO ORIENTADO A REUSO (5/8) Reuso de sistemas de aplicações Todo o sistema pode ser reutilizado pela sua incorporação, sem mudança, em outros sistemas Reuso de componentes Componentes de uma aplicação que variam desde subsistemas até objetos isolados podem ser reutilizados Reuso de funções Componentes de software que implementam uma única função podem ser reutilizados

87 DESENVOLVIMENTO ORIENTADO A REUSO (6/8) Benefícios Maior confiabilidade Os componentes já foram experimentados e testados em sistemas que já estão funcionando Redução dos riscos de processo Menos incertezas sobre as estimativas de custo de desenvolvimento Diminuição de custos e tempo na construção de aplicações Uso efetivo de especialistas Reuso de componentes ao invés de pessoas

88 DESENVOLVIMENTO ORIENTADO A REUSO (7/8) Benefícios Conformidade com padrões Os padrões são embutidos ao reutilizar componentes. Ex: padrões de interfaces com o usuário Desenvolvimento acelerado Evita o desenvolvimento e validação, acelerando a produção Maior flexibilidade na manutenção Maior qualidade dos produtos

89 DESENVOLVIMENTO ORIENTADO A REUSO (8/8) Problemas Identificação e recuperação de componentes Compreensão dos componentes Qualidade de componentes Paradigmas legais e econômicos Aumento nos custos de manutenção Código fonte não disponível

90 DESENVOLVIMENTO BASEADO EM COMPONENTES (DBC)

91 DBC (1/5) Baseada no reuso sistemático em que os sistemas são integrados com componentes existentes ou sistemas COTS (Commercial-off-the-shelf). Demanda abordagem iterativa para a construção do software, como o modelo espiral O DBC pode ser utilizado em um processo de software padrão, incorporando atividades de reuso no processo É muito aplicado em desenvolvimento OO

92 DBC (2/5) Embora o estágio de especificação de requisitos iniciais e o estágio de validação do sistema sejam comparáveis a outros processos de software, os estágios intermediários em um processo orientado a reuso são diferentes.

93 DBC (3/5) Esses estágios são: Análise de componentes: após a especificação de requisitos, inicia-se uma busca por componentes que implementem essa especificação. Modificação de requisitos: analisa-se os requisitos de acordo com os componentes encontrados. Em seguida, modifica-se, se possível, o requisito para se adequar ao componente encontrado. Projeto do sistema com reuso: o framework do sistema é projetado ou um existente é reutilizado. Os especialistas tem em mente os componentes que serão reutilizados para esse projeto. Desenvolvimento e integração: softwares que não podem ser adquiridos externamente são desenvolvidos e, os componentes e sistemas COTS são integrados para criar o novo sistema.

94 DBC (4/5) Tipos de Componentes de Software Web services desenvolvidos de acordo com padrões de serviço e que estão disponíveis para chamada remota. Coleções de objetos desenvolvidas como um pacote para ser integrado com um framework como.net ou J2EE. Sistemas de software stand-alone (COTS) configurados para uso em ambientes específicos.

95 DBC (5/5) Desenvolvimento Baseado em Componentes tem a vantagem óbvia de reduzir a quantidade de software a ser desenvolvido e, assim, reduzir os custos e riscos. Geralmente, também proporciona a entrega mais rápida do software. No entanto, compromissos com os requisitos são inevitáveis, e isso pode levar a um sistema que não atende as reais necessidades dos usuários. E também, o componente pode possuir algum código malicioso ou funcionalidade que não é necessária.

96 FCC TRT - ANALISTA JUDICIÁRIO - TECNOLOGIA DA INFORMAÇÃO Os modelos de processo são uma representação abstrata de um processo de software, que podem ser usados para explicar diferentes abordagens para o desenvolvimento de sistemas. Analise as seguintes abordagens: Desenvolvimento (I) intercala as atividades de especificação, desenvolvimento e validação. Um sistema inicial é desenvolvido rapidamente baseado em especificações abstratas e depois é refinado com as entradas do cliente para produzir um produto que o satisfaça. Modelo (II) considera as atividades fundamentais do processo, compreendendo especificação, desenvolvimento, validação e evolução e as representa como fases de processo separadas, tais como especificação de requisitos, projeto de software, implementação, teste etc. (III) baseia-se na existência de um número significativo de partes reusáveis. O processo de desenvolvimento do sistema enfoca a integração destas partes, ao invés de desenvolvê-las a partir do zero. Os modelos de processo genéricos descritos em I, II e III são, correta e respectivamente, associados a: a) em Espiral - Baseado em Componentes - RAD b) Evolucionário - em Cascata - Baseado em Componentes c) Baseado em Componentes - Sequencial - Refactoring d) Ágil - Sequencial - Unified Process e) em Cascata - Ágil - Refactoring

97 FUNRIO MPOG - ANALISTA DE TECNOLOGIA DA INFORMAÇÃO Considere o seguinte problema encontrado em projetos de desenvolvimento de software: Projetos reais raramente seguem um fluxo sequencial. Apesar de um modelo linear poder acomodar a iteração, ele o faz indiretamente. Como resultado, as modificações podem causar confusão à medida que a equipe de projeto prossegue. Esse é um dos problemas que são algumas vezes encontrados quando é aplicado o modelo de desenvolvimento a) em cascata. b) ágil. c) espiral. d) incremental. e) unificado.

98 CESPE CNJ - ANALISTA JUDICIÁRIO - ANÁLISE DE SISTEMAS Para a utilização de metodologias modernas, com abordagem da engenharia de software, recomenda-se a elaboração dos manuais do sistema ao final do projeto, quando todos os seus detalhes já estão definidos. Certo Errado CESGRANRIO CHESF - PROFISSIONAL DE NÍVEL SUPERIOR - ANALISTA DE SISTEMAS Um analista desenvolve um software e identifica que os seus requisitos iniciais estão razoavelmente bem definidos, mas o escopo geral do desenvolvimento não permite um processo puramente linear. Ele sabe que precisa, em curtíssimo prazo, prover um conjunto limitado de funcionalidades do software para os usuários, que serão refinadas e expandidas em versões futuras. Qual o modelo de ciclo de vida de desenvolvimento de software mais adequado a esse caso? a) Cascata b) RAD c) Formal d) Incremental e) Prototipação

99 CESGRANRIO PETROBRÁS - ANALISTA DE SISTEMAS JÚNIOR Ainda existem muitos projetos de software que atrasam, ultrapassam o orçamento e não produzem software que atenda às necessidades do cliente. PORQUE Não existem métricas de software padronizadas e universalmente aceitas, e, colocar mais homem/hora em um projeto atrasado, pode atrasar ainda mais a construção desse software. Analisando-se as afirmações acima, conclui-se que a) as duas afirmações são verdadeiras, e a segunda justifica a primeira. b) as duas afirmações são verdadeiras, e a segunda não justifica a primeira. c) a primeira afirmação é verdadeira, e a segunda é falsa. d) a primeira afirmação é falsa, e a segunda é verdadeira. e) as duas afirmações são falsas.

100 EXERCÍCIO Cenário Você deseja abrir uma empresa e lançar no mercado um produto inovador Detalhe um pouco mais este cenário. Qual ciclo de vida utilizar como base? Quais outras atividades de ES você incorporaria nesse processo? Quais são os maiores riscos que você está se expondo? Leonardo Murta Introdução à ES 100

101 REFERÊNCIAS PRESSMAN, Roger S., Engenharia de Software Uma Abordagem Profissional, 7 a edição, São Paulo: Mc Graw Hill, SOMMERVILLE, Ian, Engenharia de Software, 9 a edição, São Paulo: Pearson Education Addison-Wesley, MURTA, Leonardo G.P., Introdução à Engenharia de Software. Instituto de Computação, UFF.