Pós Graduação Engenharia de Softwarewebx.sefaz.al.gov.br/posEngSoft/documentos/qos1/Pos_Maceio_Parte… · e CMMI) Casos e relatos de ... Desvantagens: ... Uma versão executável

Pós Graduação Pós Graduação Engenharia de SoftwareEngenharia de Software

Ana Candida NataliAna Candida NataliCOPPE/UFRJCOPPE/UFRJ

Programa de Engenharia de Sistemas e ComputaçãoPrograma de Engenharia de Sistemas e Computação

FAPEC / FAT

Estrutura do Módulo Estrutura do Módulo –– Parte 1Parte 1QUALIDADE DE SOFTWARE QUALIDADE DE SOFTWARE –– PROCESSOPROCESSOIntrodução: desenvolvimento de software como uma Introdução: desenvolvimento de software como uma disciplina de engenhariadisciplina de engenhariaCiclo de vidaCiclo de vidaProcessos de softwareProcessos de software

Qualidade do processo e implicaçõesQualidade do processo e implicaçõesModelos de qualidade de processo (ênfase Modelos de qualidade de processo (ênfase ISO/IECISO/IEC 12207 12207 e CMMI) e CMMI) Casos e relatos de experiênciaCasos e relatos de experiência

AvaliaçãoAvaliação

Ciclo de vida de softwareCiclo de vida de software

Ciclo de Vida de SoftwareCiclo de Vida de Software

Definição de RequisitosDefinição de RequisitosAnáliseAnáliseProjetoProjetoCodificaçãoCodificaçãoTestesTestes


Antes do início da construção de um sistema, Antes do início da construção de um sistema, deve ser definido como ele será usado, como deve ser definido como ele será usado, como será sua interação com os usuários e a quais será sua interação com os usuários e a quais funções ele se destina. funções ele se destina. Esta visão externa de seu funcionamento pode Esta visão externa de seu funcionamento pode ser obtida através da Definição de Requisitos.ser obtida através da Definição de Requisitos.


A Análise visa os seguintes objetivos:verificar a qualidade dos requisitos obtidos;descrever estes requisitos o suficiente para que atinjam o nível de detalhe adequado aos desenvolvedores.

O Modelo de Análise é a base para o Projeto, mas deve-se evitar a inclusão de detalhes que pertençam ao domínio da solução e não do problema.


A Análise geralmente transcorre com a suposição de que há uma tecnologia “perfeita” disponível; já no Projeto, sabe-se que o sistema será implementado em uma plataforma de hardware, sob um sistema operacional, usando uma linguagem de programação. Em suma, a Análise interessa-se pelo o quê o sistema deve fazer, enquanto o Projeto diz respeito a como os requisitos serão implementados.


Na fase de Projeto há a incorporação de requisitos tecnológicos aos componentes modelados na fase de Análise, bem como a definição da plataforma e das ferramentas utilizadas.O Projeto é dependente de aspectos como as características da linguagem de programação utilizada, o modelo de persistência adotado, as características da plataforma de implementação e as características da interface com o usuário.


A Codificação deve ser vista como uma A Codificação deve ser vista como uma extensão ao processo de projetar. Deve ser extensão ao processo de projetar. Deve ser direta, quase mecânica, uma vez que as direta, quase mecânica, uma vez que as decisões difíceis devem ter sido tomadas decisões difíceis devem ter sido tomadas durante o projeto. durante o projeto. A Codificação deve ser uma tradução das A Codificação deve ser uma tradução das decisões de projeto em uma linguagem decisões de projeto em uma linguagem específica.específica.


Teste de software é uma atividade de garantia Teste de software é uma atividade de garantia da qualidade. O principal objetivo é analisar a da qualidade. O principal objetivo é analisar a qualidade do software em execução, qualidade do software em execução, verificando se este atende às necessidades do verificando se este atende às necessidades do cliente.cliente.Os principais tipos de teste são: teste de Os principais tipos de teste são: teste de unidade, teste de integração e teste de sistema.unidade, teste de integração e teste de sistema.


Teste de unidade é o nível mais baixo de teste e é Teste de unidade é o nível mais baixo de teste e é normalmente realizado pelo próprio desenvolvedor. normalmente realizado pelo próprio desenvolvedor. Em sistemas tradicionais, a unidade pode ser Em sistemas tradicionais, a unidade pode ser considerada uma função, procedimento ou subconsiderada uma função, procedimento ou sub--rotina. Fazendo uma analogia com o modelo de rotina. Fazendo uma analogia com o modelo de objetos, poderobjetos, poder--sese--ia considerar uma unidade como ia considerar uma unidade como sendo um método de uma classe. Muitas vezes, pode sendo um método de uma classe. Muitas vezes, pode ser difícil isolar um método de sua classe e passa a ser ser difícil isolar um método de sua classe e passa a ser necessário considerar a classe como sendo a menor necessário considerar a classe como sendo a menor unidade de teste.unidade de teste.


Quando as unidades tiverem sido certificadas nos Quando as unidades tiverem sido certificadas nos testes de unidade, elas devem ser integradas em testes de unidade, elas devem ser integradas em unidades maiores e finalmente no sistema. O unidades maiores e finalmente no sistema. O propósito dos testes de integração é testar se as propósito dos testes de integração é testar se as diferentes unidades trabalham corretamente em diferentes unidades trabalham corretamente em conjunto.conjunto.Mesmo que as unidades tenham sido extensivamente Mesmo que as unidades tenham sido extensivamente testadas, testes de integração são necessários. Quando testadas, testes de integração são necessários. Quando as unidades são combinadas, novas falhas podem ser as unidades são combinadas, novas falhas podem ser detectadas. A combinação de unidades aumenta detectadas. A combinação de unidades aumenta exponencialmente o número de caminhos possíveis. exponencialmente o número de caminhos possíveis.


O Teste de sistema objetiva assegurar que o O Teste de sistema objetiva assegurar que o sistema faz o que o cliente quer que ele faça.sistema faz o que o cliente quer que ele faça.O Teste de sistema é executado no ambiente O Teste de sistema é executado no ambiente real de funcionamento mas, freqüentemente, é real de funcionamento mas, freqüentemente, é realizado em um ambiente de teste diferente realizado em um ambiente de teste diferente do local em que será instalado.do local em que será instalado.

Modelos de ciclo de vida Modelos de ciclo de vida de softwarede software

Modelos de Ciclo de Modelos de Ciclo de Vida de SoftwareVida de Software

Define as diferentes fases na existência de um Define as diferentes fases na existência de um produto de software, além de definir também os produto de software, além de definir também os princípios e diretrizes que vão guiar a realização princípios e diretrizes que vão guiar a realização destas fasesdestas fasesUm modelo de ciclo de vida organiza as macroUm modelo de ciclo de vida organiza as macro--atividades básicas, estabelecendo precedência e atividades básicas, estabelecendo precedência e dependência entre as mesmas. dependência entre as mesmas. Define a estrutura e a filosofia segundo as quais o Define a estrutura e a filosofia segundo as quais o processo de software tem que ser executado processo de software tem que ser executado No desenvolvimento de software, o ponto de partida No desenvolvimento de software, o ponto de partida para a arquitetura de um processo é a escolha de um para a arquitetura de um processo é a escolha de um modelo de ciclo de vida.modelo de ciclo de vida.


A adoção de um ciclo de vida não é suficiente para A adoção de um ciclo de vida não é suficiente para guiar e controlar um projeto de software na prática. guiar e controlar um projeto de software na prática. Outras características devem ser levadas em Outras características devem ser levadas em consideração durante a vida de um produto de consideração durante a vida de um produto de software:software:

Organização das atividades do processoOrganização das atividades do processoRecursos humanos, hardware e softwareRecursos humanos, hardware e softwareProcedimentos de operaçãoProcedimentos de operaçãoPolíticas de desenvolvimento e restriçõesPolíticas de desenvolvimento e restriçõesTipos de softwareTipos de software


As características básicas comuns a todos os As características básicas comuns a todos os modelos são:modelos são:

Descrever as principais fases do desenvolvimentoDescrever as principais fases do desenvolvimentoDefinir as principais atividades a serem realizadas Definir as principais atividades a serem realizadas durante cada uma das fasesdurante cada uma das fasesEspecificar os produtos de cada uma das fases e Especificar os produtos de cada uma das fases e insumos para o início das fasesinsumos para o início das fasesFornecer um Fornecer um frameworkframework sobre o qual as atividades sobre o qual as atividades necessárias podem ser mapeadasnecessárias podem ser mapeadas


Principais modelos de ciclo de vida de Principais modelos de ciclo de vida de software:software:

Modelo CascataModelo CascataModelo IncrementalModelo IncrementalModelo EvolutivoModelo EvolutivoModelo RADModelo RADPrototipaçãoPrototipaçãoModelo EspiralModelo EspiralModelo de Ciclo de Vida Associado ao RUPModelo de Ciclo de Vida Associado ao RUP

Modelo CascataModelo Cascata

Modelo mais antigo e o mais amplamente usado na Modelo mais antigo e o mais amplamente usado na engenharia de software, modelado em função do ciclo engenharia de software, modelado em função do ciclo da engenharia convencional.da engenharia convencional.Requer uma abordagem sistemática e seqüencial ao Requer uma abordagem sistemática e seqüencial ao desenvolvimento de software desenvolvimento de software Adequado em situações nas quais os requisitos são Adequado em situações nas quais os requisitos são bem entendidos e o gerente do projeto confia na bem entendidos e o gerente do projeto confia na capacidade da equipe de desenvolver utilizando o capacidade da equipe de desenvolver utilizando o processoprocesso

Modelo CascataModelo CascataEspecificação de

Requisitos

Análise

Projeto

Implementação e Teste de Unidade

Integração

Manutenção

Figura 2 – Um típico modelo em cascata.

Modelo CascataModelo Cascata

Vantagens:Vantagens:A fase única de requisitos leva à especificação antes A fase única de requisitos leva à especificação antes do projeto e ao projeto antes da codificaçãodo projeto e ao projeto antes da codificaçãoO uso de revisões ao fim de cada fase permite o O uso de revisões ao fim de cada fase permite o envolvimento do usuárioenvolvimento do usuárioO modelo permite que se imponha um controle de O modelo permite que se imponha um controle de configuraçãoconfiguraçãoCada passo serve como uma base aprovada e Cada passo serve como uma base aprovada e documentada para o passo seguinte documentada para o passo seguinte

Modelo CascataModelo CascataDesvantagens:Desvantagens:

O fluxo seqüencial que o modelo propõe geralmente não é O fluxo seqüencial que o modelo propõe geralmente não é seguido em projeto reaisseguido em projeto reaisRequisitos devem ser estabelecidos de maneira completa Requisitos devem ser estabelecidos de maneira completa correta e clara no início de um projetocorreta e clara no início de um projetoAplicação deve ser entendida pelo desenvolvedor desde o Aplicação deve ser entendida pelo desenvolvedor desde o início do projetoinício do projetoDifícil avaliar o progresso verdadeiro do projeto durante as Difícil avaliar o progresso verdadeiro do projeto durante as primeiras fasesprimeiras fasesUma versão executável do software só fica disponível numa Uma versão executável do software só fica disponível numa etapa avançada do desenvolvimentoetapa avançada do desenvolvimentoAo final do projeto, é necessário um grande esforço de Ao final do projeto, é necessário um grande esforço de integração e testesintegração e testes

Modelo IncrementalModelo IncrementalRequisitos são segmentados em uma série Requisitos são segmentados em uma série incremental de produtos. O processo se repete até incremental de produtos. O processo se repete até que um produto completo seja produzido.que um produto completo seja produzido.A segmentação de requisitos é realizada antes do A segmentação de requisitos é realizada antes do desenvolvimento da primeira versão.desenvolvimento da primeira versão.Adotado quando os requisitos são conhecidos no Adotado quando os requisitos são conhecidos no início do desenvolvimentoinício do desenvolvimentoNecessidade de entrega de um produto funcional em Necessidade de entrega de um produto funcional em pouco tempopouco tempoA cada incremento é produzida uma versão A cada incremento é produzida uma versão operacional do software.operacional do software.

Modelo IncrementalModelo Incremental

Vantagens:Vantagens:Menor custo e menos tempo são necessários para Menor custo e menos tempo são necessários para se entregar a primeira versãose entregar a primeira versãoRiscos associados ao desenvolvimento de Riscos associados ao desenvolvimento de incrementos são menores, devido ao seu tamanho incrementos são menores, devido ao seu tamanho reduzidoreduzidoNúmero de mudanças nos requisitos pode Número de mudanças nos requisitos pode diminuir devido ao curto tempo de diminuir devido ao curto tempo de desenvolvimento da primeira versão desenvolvimento da primeira versão

Modelo IncrementalModelo Incremental

Desvantagens:Desvantagens:Se os requisitos não são tão estáveis ou completos Se os requisitos não são tão estáveis ou completos quanto se esperava, alguns incrementos podem quanto se esperava, alguns incrementos podem precisar ser retirados de uso e reprecisar ser retirados de uso e re--trabalhadostrabalhadosO gerenciamento de custo, cronograma e O gerenciamento de custo, cronograma e configuração é mais complexoconfiguração é mais complexo

Modelo EvolutivoModelo Evolutivo

Versões parciais são desenvolvidas que Versões parciais são desenvolvidas que atendem aos requisitos conhecidos atendem aos requisitos conhecidos inicialmenteinicialmenteA primeira versão é usada para refinar os A primeira versão é usada para refinar os requisitos para uma segunda versão.requisitos para uma segunda versão.A partir do conhecimento sobre os requisitos, A partir do conhecimento sobre os requisitos, obtido com o uso, continuaobtido com o uso, continua--se o se o desenvolvimento, evoluindo o produtodesenvolvimento, evoluindo o produto


Vantagens:Vantagens:Adequado quando os requisitos não podem ser Adequado quando os requisitos não podem ser completamente especificados de iníciocompletamente especificados de inícioO uso do sistema pode aumentar o conhecimento O uso do sistema pode aumentar o conhecimento sobre o produto e melhorar os requisitossobre o produto e melhorar os requisitos


Figura 3 – Um típico modelo evolutivo.


Desvantagens:Desvantagens:Necessária uma forte gerência de custo, Necessária uma forte gerência de custo, cronograma e configuraçãocronograma e configuraçãoUsuários podem não entender a natureza da Usuários podem não entender a natureza da abordagem e se decepcionar quando os resultados abordagem e se decepcionar quando os resultados são não satisfatóriossão não satisfatórios

Modelo RADModelo RADO Modelo RAD (O Modelo RAD (RapidRapid ApplicationApplication DevelopmentDevelopment) é ) é seqüencial linear enfatizando o desenvolvimento seqüencial linear enfatizando o desenvolvimento rápidorápidoA “alta velocidade” é conseguida através de uma A “alta velocidade” é conseguida através de uma abordagem de construção baseada em várias equipes abordagem de construção baseada em várias equipes trabalhando em paralelo quando o produto pode ser trabalhando em paralelo quando o produto pode ser dividido em módulosdividido em módulosAdequado quando os requisitos são bem definidos, o Adequado quando os requisitos são bem definidos, o escopo do sistema é restrito e a aplicação pode ser escopo do sistema é restrito e a aplicação pode ser modularizadamodularizada

Modelo RADModelo RAD

Vantagens:Vantagens:O ciclo de desenvolvimento é extremamente curtoO ciclo de desenvolvimento é extremamente curto

Desvantagens:Desvantagens:Requer recursos humanos suficientes para criar um número Requer recursos humanos suficientes para criar um número adequado de equipes em projetos grandes e escaláveisadequado de equipes em projetos grandes e escaláveisRequer um comprometimento entre desenvolvedores e Requer um comprometimento entre desenvolvedores e clientesclientesNão é apropriado quando os riscos são grandesNão é apropriado quando os riscos são grandesNão é apropriado quando o sistema precisar interagir com Não é apropriado quando o sistema precisar interagir com outros sistemasoutros sistemas

PrototipaçãoPrototipação

Protótipos podem ser utilizados para explorar Protótipos podem ser utilizados para explorar requisitos que serão implementados requisitos que serão implementados posteriormente em um incremento funcionalposteriormente em um incremento funcional

Protótipos podem ser utilizados para Protótipos podem ser utilizados para determinar a viabilidade técnica, de custo e de determinar a viabilidade técnica, de custo e de cronograma para o projetocronograma para o projeto


Vantagens:Vantagens:Um protótipo deve ser submetido a uma avaliação, Um protótipo deve ser submetido a uma avaliação, geralmente feita pelo clientegeralmente feita pelo clienteO fato de o cliente poder interagir com um O fato de o cliente poder interagir com um protótipo ajuda a cristalizar suas necessidades protótipo ajuda a cristalizar suas necessidades funcionais e de desempenhofuncionais e de desempenhoOs desenvolvedores podem implementar os Os desenvolvedores podem implementar os requisitos baseado no requisitos baseado no feedback feedback do usuáriodo usuário


Desvantagens:Desvantagens:Riscos envolvidos no uso da Riscos envolvidos no uso da prototipaçãoprototipação::

Clientes imaginam que a maior parte do trabalho já foi Clientes imaginam que a maior parte do trabalho já foi feitafeitaProtótipo pode crescer de maneira não planejada, se Protótipo pode crescer de maneira não planejada, se tornando um incremento funcionaltornando um incremento funcionalProtótipo pode ter um desempenho melhor do que um Protótipo pode ter um desempenho melhor do que um incremento funcional, pois não implementa toda a incremento funcional, pois não implementa toda a funcionalidade, causando frustração aos clientes quando funcionalidade, causando frustração aos clientes quando o sistema completo é entregueo sistema completo é entregue

Modelo EspiralModelo EspiralModelo de ciclo de vida evolutivo que combina a natureza Modelo de ciclo de vida evolutivo que combina a natureza evolutiva da evolutiva da prototipaçãoprototipação ao modelo seqüencial linear.ao modelo seqüencial linear.O software é desenvolvido em uma série de versões O software é desenvolvido em uma série de versões incrementais, cada vez mais completasincrementais, cada vez mais completasCada ciclo da espiral é composto das seguintes fases:Cada ciclo da espiral é composto das seguintes fases:

Identificar os objetivos da parte do produto que está sendo elabIdentificar os objetivos da parte do produto que está sendo elaborada, orada, as alternativas de implementação do produto e as restrições impoas alternativas de implementação do produto e as restrições impostas stas pela aplicação das alternativaspela aplicação das alternativasAvaliar as alternativas, identificando possíveis riscos para o pAvaliar as alternativas, identificando possíveis riscos para o projetorojetoPlanejar um protótipo para resolver os riscosPlanejar um protótipo para resolver os riscosDesenvolver o software segundo o modelo cascata ou o modelo Desenvolver o software segundo o modelo cascata ou o modelo iterativoiterativo

Modelo de Ciclo de Vida Modelo de Ciclo de Vida Associado ao RUPAssociado ao RUP

O RUP (O RUP (RationalRational UnifiedUnified ProcessProcess)) é um processo é um processo de engenharia de software desenvolvido pela de engenharia de software desenvolvido pela RationalRational Software e possui um Software e possui um frameworkframework de de processo que pode ser adaptado e estendidoprocesso que pode ser adaptado e estendidoO desenvolvimento de software é feito de O desenvolvimento de software é feito de forma iterativa e as interações são planejadas forma iterativa e as interações são planejadas em número, duração e objetivosem número, duração e objetivosOrientado a casos de usoOrientado a casos de uso


ConcepçãoConcepçãoEntender os requisitos gerais e determinar o escopo do esforço dEntender os requisitos gerais e determinar o escopo do esforço de e desenvolvimentodesenvolvimento

ElaboraçãoElaboraçãoPlanejar as atividades e recursos necessários; especificar as Planejar as atividades e recursos necessários; especificar as características e projeto da arquiteturacaracterísticas e projeto da arquitetura

ConstruçãoConstruçãoConstruir o produto e evoluir a visão, arquitetura e planos, atéConstruir o produto e evoluir a visão, arquitetura e planos, até que o que o produto esteja pronto para entregaproduto esteja pronto para entrega

TransiçãoTransiçãoGarantir que o sistema tem o nível correto de qualidade para atiGarantir que o sistema tem o nível correto de qualidade para atingir os ngir os objetivos; realizar correções, treinamento de usuários, ajustes objetivos; realizar correções, treinamento de usuários, ajustes e adição e adição de elementos que estavam faltando. O produto final é produzido ede elementos que estavam faltando. O produto final é produzido eentregue.entregue.


Vantagens:Vantagens:Permite e encoraja o feedback do usuário, Permite e encoraja o feedback do usuário, elicitandoelicitando os os requisitos reais do sistemarequisitos reais do sistemaInconsistências entre requisitos, projeto e implementação Inconsistências entre requisitos, projeto e implementação podem ser detectados rapidamentepodem ser detectados rapidamenteDivisão da carga de trabalho por todo o ciclo de vidaDivisão da carga de trabalho por todo o ciclo de vidaCompartilhamento de lições aprendidas, melhorando Compartilhamento de lições aprendidas, melhorando continuamente o processocontinuamente o processoEvidências concretas do andamento do projeto podem ser Evidências concretas do andamento do projeto podem ser oferecidas durante todo o ciclo de vidaoferecidas durante todo o ciclo de vida

ExercíciosExercícios

Modelos de Ciclo de VidaModelos de Ciclo de Vida

Cenário 1Cenário 1Objetivo: desenvolver um sistema para acompanhamento Objetivo: desenvolver um sistema para acompanhamento

de cirurgia cardíaca. A organização dispõe de uma de cirurgia cardíaca. A organização dispõe de uma quantidade adequada de desenvolvedores experientes quantidade adequada de desenvolvedores experientes no domínio da aplicação. O sistema pode ser no domínio da aplicação. O sistema pode ser modularizadomodularizado. Além disso, a organização possui um . Além disso, a organização possui um conjunto de bibliotecas de componentes reutilizáveis.conjunto de bibliotecas de componentes reutilizáveis.

Possibilidades: Cascata, Evolutivo, Espiral, Incremental, Possibilidades: Cascata, Evolutivo, Espiral, Incremental, PrototipaçãoPrototipação, RAD., RAD.


Cenário 1Cenário 1Objetivo: desenvolver um sistema para acompanhamento Objetivo: desenvolver um sistema para acompanhamento

de cirurgia cardíaca. A organização dispõe de uma de cirurgia cardíaca. A organização dispõe de uma quantidade adequada de desenvolvedores experientes quantidade adequada de desenvolvedores experientes no domínio da aplicação. O sistema pode ser no domínio da aplicação. O sistema pode ser modularizadomodularizado. Além disso, a organização possui um . Além disso, a organização possui um conjunto de bibliotecas de componentes reutilizáveis.conjunto de bibliotecas de componentes reutilizáveis.

Resposta: EspiralResposta: Espiral


Cenário 2Cenário 2Objetivo: desenvolver um sistema para uma aplicação de Objetivo: desenvolver um sistema para uma aplicação de

comércio eletrônico. Apesar do cliente ter uma certa comércio eletrônico. Apesar do cliente ter uma certa urgência em colocar o sistema em operação, os urgência em colocar o sistema em operação, os requisitos para o mesmo não se encontram bem requisitos para o mesmo não se encontram bem definidos. O cliente se comprometeu em acompanhar definidos. O cliente se comprometeu em acompanhar o desenvolvimento. Porém, este possui dificuldades o desenvolvimento. Porém, este possui dificuldades em expressar os requisitos do sistema.em expressar os requisitos do sistema.



Cenário 2Cenário 2Objetivo: desenvolver um sistema para uma aplicação de Objetivo: desenvolver um sistema para uma aplicação de

comércio eletrônico. Apesar do cliente ter uma certa comércio eletrônico. Apesar do cliente ter uma certa urgência em colocar o sistema em operação, os urgência em colocar o sistema em operação, os requisitos para o mesmo não se encontram bem requisitos para o mesmo não se encontram bem definidos. O cliente se comprometeu em acompanhar definidos. O cliente se comprometeu em acompanhar o desenvolvimento. Porém, este possui dificuldades o desenvolvimento. Porém, este possui dificuldades em expressar os requisitos do sistema.em expressar os requisitos do sistema.

Resposta: Resposta: PrototipaçãoPrototipação..


Cenário 3Cenário 3Objetivo:desenvolver um sistema de cadastro de usuários Objetivo:desenvolver um sistema de cadastro de usuários

de uma biblioteca virtual. Os requisitos para o sistema de uma biblioteca virtual. Os requisitos para o sistema foram fornecidos pelo usuário de antemão e estão foram fornecidos pelo usuário de antemão e estão relativamente bem definidos. A organização dispõe de relativamente bem definidos. A organização dispõe de uma quantidade adequada de desenvolvedores uma quantidade adequada de desenvolvedores experientes no domínio da aplicação. Porém, há uma experientes no domínio da aplicação. Porém, há uma alta disputa interna entre a equipe de alta disputa interna entre a equipe de desenvolvimento.desenvolvimento.



Cenário 3Cenário 3Objetivo:desenvolver um sistema de cadastro de usuários Objetivo:desenvolver um sistema de cadastro de usuários

de uma biblioteca virtual. Os requisitos para o sistema de uma biblioteca virtual. Os requisitos para o sistema foram fornecidos pelo usuário de antemão e estão foram fornecidos pelo usuário de antemão e estão relativamente bem definidos. A organização dispõe de relativamente bem definidos. A organização dispõe de uma quantidade adequada de desenvolvedores uma quantidade adequada de desenvolvedores experientes no domínio da aplicação. Porém, há uma experientes no domínio da aplicação. Porém, há uma alta disputa interna entre a equipe de alta disputa interna entre a equipe de desenvolvimento.desenvolvimento.

Resposta: Cascata.Resposta: Cascata.


Cenário 4Cenário 4Objetivo: desenvolver um sistema de controle de Objetivo: desenvolver um sistema de controle de

estacionamento. O cliente tem uma vaga idéia dos estacionamento. O cliente tem uma vaga idéia dos requisitos do sistema. Apesar disso, exige que uma requisitos do sistema. Apesar disso, exige que uma versão operacional esteja em execução num prazo versão operacional esteja em execução num prazo relativamente curto (2 meses). A organização de relativamente curto (2 meses). A organização de desenvolvimento dispõe de um conjunto de desenvolvimento dispõe de um conjunto de bibliotecas de componentes reutilizáveis. Entretanto, bibliotecas de componentes reutilizáveis. Entretanto, os desenvolvedores possuem baixa experiência no os desenvolvedores possuem baixa experiência no domínio da aplicação.domínio da aplicação.



Cenário 4Cenário 4Objetivo: desenvolver um sistema de controle de Objetivo: desenvolver um sistema de controle de

estacionamento. O cliente tem uma vaga idéia dos estacionamento. O cliente tem uma vaga idéia dos requisitos do sistema. Apesar disso, exige que uma requisitos do sistema. Apesar disso, exige que uma versão operacional esteja em execução num prazo versão operacional esteja em execução num prazo relativamente curto (2 meses). A organização de relativamente curto (2 meses). A organização de desenvolvimento dispõe de um conjunto de desenvolvimento dispõe de um conjunto de bibliotecas de componentes reutilizáveis. Entretanto, bibliotecas de componentes reutilizáveis. Entretanto, os desenvolvedores possuem baixa experiência no os desenvolvedores possuem baixa experiência no domínio da aplicação.domínio da aplicação.

Resposta: Evolutivo.Resposta: Evolutivo.

Modelos de Ciclo de VidaModelos de Ciclo de VidaNecessidade de execução imediata (Evolutivo, Incremental, RAD)Necessidade de execução imediata (Evolutivo, Incremental, RAD)Disponibilidade de recursos humanos (RAD)Disponibilidade de recursos humanos (RAD)Tecnologia inovadora (Espiral, Evolutiva)Tecnologia inovadora (Espiral, Evolutiva)Alta disputa interna na equipe de desenvolvimento (Alta disputa interna na equipe de desenvolvimento (--RAD)RAD)ModularidadeModularidade (RAD, Incremental)(RAD, Incremental)Disponibilidades de COTS (RAD, Cascata, Disponibilidades de COTS (RAD, Cascata, PrototipaçãoPrototipação))Disponibilidade do cliente (Todos, +Evolutivo, +Disponibilidade do cliente (Todos, +Evolutivo, +PrototipaçãoPrototipação))Desenvolvedores experientes (RAD, Cascata)Desenvolvedores experientes (RAD, Cascata)Baixa experiência no domínio de aplicação (Espiral, Evolutivo)Baixa experiência no domínio de aplicação (Espiral, Evolutivo)Software crítico (Espiral)Software crítico (Espiral)Requisitos BEM definidos (Cascata, Incremental)Requisitos BEM definidos (Cascata, Incremental)Necessidade de integração com outros sistemas (Espiral, Necessidade de integração com outros sistemas (Espiral, --RAD)RAD)Dificuldade do cliente em expressar requisitos (Dificuldade do cliente em expressar requisitos (PrototipaçãoPrototipação, , Evolutivo, Evolutivo,

-- Cascata, Cascata, --RAD, RAD, -- Incremental)Incremental)

ReferênciasReferênciasEngenharia de SoftwareEngenharia de Software, Roger S. Pressman, Tradução da 5a , Roger S. Pressman, Tradução da 5a edição, edição, McMc GrawGraw Hill, 2002.Hill, 2002.

http://www.http://www.mhhemhhe..com/engcs/compsci/pressmancom/engcs/compsci/pressman//

Engenharia de Software: Teoria e Prática, 2a edição, Engenharia de Software: Teoria e Prática, 2a edição, ShariShari L. L. PfleegerPfleeger, , PrenticePrentice Hall, 2004Hall, 2004..

www.www.prenhallprenhall..com/pfleeger_brcom/pfleeger_br

Qualidade de Software: Teoria e PráticaQualidade de Software: Teoria e Prática, Ana Regina da Rocha , Ana Regina da Rocha e outros autores, e outros autores, PrenticePrentice Hall, 2001. Hall, 2001.

ContatosContatos

Ana Candida NataliAna Candida [email protected]@cos.ufrj.br

Ana Regina da RochaAna Regina da [email protected]@centroin.com.br

Documents

Pós Graduação Engenharia de Softwarewebx.sefaz.al.gov.br/posEngSoft/documentos/qos1/Pos_Maceio_Parte… · e CMMI) Casos e relatos de ... Desvantagens: ... Uma versão executável