ENGENHARIA DE SOFTWARE - retondaro.pro.br · Estabelece um plano para o trabalho de engenharia de...

2016-1

ENGENHARIA DE SOFTWARE

Kele Teixeira Belloze

kelebelloze@gmail.com

Processos de Software

Etapas do processo de software

Modelos de ciclo de vida de software

2016-1

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE

ELEMENTOS DA ENGENHARIA DE SOFTWARE

A Engenharia de Software (ES) compreende um conjunto de etapas que envolve processos, métodos e ferramentas.

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

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

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.

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

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.

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

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

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

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

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

ETAPAS GENÉRICAS DO PROCESSO DE SOFTWARE

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.

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.

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.

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

MODELOS DE CICLO DE VIDA DO SOFTWARE

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”

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

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

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.

É mais fácil modificar o processo para refletir alterações nos requisitos do cliente.

Leonardo Murta

Para continuar o entendimento

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.

MODELO EM CASCATA OU CICLO DE VIDA CLÁSSICO

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

Engenharia de Sistemas

Análise de Requisitos

Projeto

Implementação/Codificação

Teste

Manutenção

CICLO DE VIDA CLÁSSICO (2/11)

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

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

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

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

CICLO DE VIDA CLÁSSICO (7/11)

Implementação/Codificação

O projeto deve ser traduzido em uma linguagem de programação

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

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

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.

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

RAPID APPLICATION DEVELOPMENT (RAD)

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

RAD (2/4)

Comunicação Planejamento

Leonardo Murta Introdução à ES

Integração e Implantação

...

Modelagem Construção

Modelagem Construção

Modelagem Construção

Modelagem: Modelagem de negócio Modelagem de dados Modelagem de processo

Construção: Reuso de componentes Geração automática de código Teste

60-90 dias

RAD (3/4)

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

MODELOS EVOLUTIVOS (ITERATIVOS) - Incremental

- Prototipação

- Espiral

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

CASCATA X EVOLUTIVO

Ciclo de vida cascata

Ciclo de vida evolutivo

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

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

...

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

Revisão de ES I 47 Leonardo Murta

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

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

Revisão de ES I 49 Leonardo Murta

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

Revisão de ES I 50 Leonardo Murta

MODELO INCREMENTAL

MODELO INCREMENTAL (1/5)

Comunicação

Planejamento

Modelagem

Construção

Implantação

Incremento 1

Entrega 1 – núcleo do produto

Comunicação

Planejamento

Modelagem

Construção

Implantação

Incremento 2

Entrega 2

Comunicação

Planejamento

Modelagem

Construção

Implantação

Incremento 3

Entrega 3

Fun

cio

nal

idad

es

e C

arac

terí

stic

as d

o P

roje

to

Tempo do Projeto

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

MODELO INCREMENTAL (3/5)

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.

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)

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.

ENTREGA INCREMENTAL (2/2)

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.

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.

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.

PROTOTIPAÇÃO

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)

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 homem-máquina deve assumir

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

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

PROTOTIPAÇÃO (5/10)

Usualmente utilizado como auxílio a outro modelo de ciclo de vida

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)

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

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.

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

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

MODELO ESPIRAL

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.

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

Protótipo no nível seguinte

Análise de riscos

Engenharia

Planejamento

Avaliação do Cliente

Coleta inicial dos requisitos

Protótipo de sw inicial

Sistema construído pela engenharia

Avaliação do Cliente

Análise dos riscos baseada nos requisitos iniciais

Análise dos riscos baseada na reação do cliente

Planejamento baseado nos comentários do projeto

(3/7)

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

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

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

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

DESENVOLVIMENTO ORIENTADO A REUSO - Desenvolvimento Baseado em Componentes

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

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

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

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

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

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

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

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

DESENVOLVIMENTO BASEADO EM COMPONENTES (DBC)

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

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.

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.

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.

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.

FCC - 2014 - 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

FUNRIO - 2013 - 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.

CESPE - 2013 - 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 - 2012 - 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

CESGRANRIO - 2011 - 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.

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

REFERÊNCIAS

PRESSMAN, Roger S., Engenharia de Software – Uma Abordagem Profissional, 7a edição, São Paulo: Mc Graw Hill, 2011.

SOMMERVILLE, Ian, Engenharia de Software, 9a edição, São Paulo: Pearson Education – Addison-Wesley, 2011.

MURTA, Leonardo G.P., Introdução à Engenharia de Software. Instituto de Computação, UFF.