ENGENHARIA DE SOFTWARE - retondaro.pro.br · Estabelece um plano para o trabalho de engenharia de...
Transcript of ENGENHARIA DE SOFTWARE - retondaro.pro.br · Estabelece um plano para o trabalho de engenharia de...
2016-1
ENGENHARIA DE SOFTWARE
Kele Teixeira Belloze
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.