Sistemas CASE Introdução DI-UFPE @1997, Alexandre Vasconcelos.

Slides:



Advertisements
Apresentações semelhantes
Ferramentas CASE (Computer-Aided Software Engineering)
Advertisements

ISO Processos do Ciclo de Vida do Software
(Unified Modeling Language)
Tipos de sistemas de Lehman
Engenharia de Software
Processos de Software Introdução
> Fases de Engenharia de SW > Gestão de Projectos de SW
Engenharia de Software
Tópicos Motivação para teste Por que algumas empresas não testam
Rational Unified Process(RUP)
Engenharia de Software Professor Sandro de Paiva Carvalho.
FACULDADE DOS GUARARAPES
Mitos e Problemas Relacionados ao Software
Projeto de Sistemas de Software
Computer Aided Software Engineering
Processo Desenvolvimento de Software Tradicional
Engenharia Reversa É o processo de derivar as especificações lógicas dos componentes do sistema a partir de sua descrição física com auxílio de ferramentas.
Análise e Projeto de Sistemas
TIPOS DE TESTES APLICÁVEIS E NÃO APLICÁVEIS AO PROJETO
Como Desenvolver Sistemas de Informação
TSDD Teste de segurança durante o desenvolvimento.
Visão Geral do Desenvolvimento de Sistemas e Papéis no Desenvolvimento de Software Marcely Dias
Configuração de manutenção
Engenharia de Software e Sistemas de Informação e Gestão
RUP - Cap. 2 – Os 4 P’s (Pessoas, Projeto, Produto e Processo)
RUPinho Qualidade de Software
Cap 2 – Processo de Software
Projeto de Sistemas de Software
Processos de Desenvolvimento de Software – Parte 2
IFSul – Campus Venâncio Aires
Engenharia de Software
Modelos de Maturidade de Processos de Software
Engenharia de Software
Engenharia de Software
Projeto de Banco de Dados
Gerência de Configuração - GC
Análise e Projeto de Sistemas de Informação 2o. Semestre de 2014
Software engineering, the software process and their support M.M. Lehman Apresentadora: Tarciana Dias da Silva.
Documentação de Software
Análise e Projeto Orientados a Objetos
Bruno Silva Desenvolvido a partir de
O Processo Unificado (UP)
ANÁLISE ESTRUTURADA DE SISTEMAS
O que é? É o processo de investigação técnica com intuito de identificar a qualidade, a segurança e a exatidão do software desenvolvido. A validação do.
Introdução a Banco de Dados Aula 04
RUP - Cap. 4 – Processo Centrado na Arquitetura
METODOLOGIA, MÉTODOS E FERRAMENTAS
Laboratório de Programação
Processos de Software.
Processos de Software.
Requisitos de Software
Conceitos Básicos Introdução.
Integração de Ferramentas CASE
Desenvolvimento de Software Dirigido a Modelos
UML e a Ferramenta Astah
Orientação a Objetos e Java Graduação em Ciência da Computação  Centro de Informática, UFPE Alexandre Mota
© Nabor C. Mendonça Processo / Metodologia de Desenvolvimento de Software.
Os projetos.
Evitando os Problemas.
Engenharia de Software
UML (Unified Modeling Language) Linguagem Unificada de Modelagem
UML (Unified Modeling Language) Linguagem Unificada de Modelagem
RUP – Rational Unified Process Márcia Seabra Cabral Prof. Augusto Sampaio Centro de Informática - UFPE.
IF 718 Análise e Projeto de Sistemas Augusto Sampaio Vitor Braga (Estágio docência) Camila Sá (Monitora) Parte do material cedido pela Qualiti Software.
Apresentação Leonardo Brussolo de Paula
TÉCNICAS DE ESTIMATIVAS
Lenylda Albuquerque ISO Processos de Ciclo de Vida de Software Universidade Federal de Pernambuco.
1 Projeto Piloto Conclusão em Agenda Projeto Piloto –Descrição –Execução da aplicação –Implementação de requisitos funcionais e não- funcionais.
Processos de Software Ludimila Monjardim Casagrande 1º Semestre Desenvolvimento e Qualidade.
Síntese do Negócio ONTOWEB. Ontoweb – Nova Geração de Ferramenta de Busca Possui comportamento inteligente que auxilia o usuário a organizar e compartilhar.
Transcrição da apresentação:

Sistemas CASE Introdução DI-UFPE @1997, Alexandre Vasconcelos

Conteúdo Motivação O que é CASE? Uma Classificação para Sistemas CASE Histórico; Vantagens dos Sistemas CASE Problemas com os Sistemas CASE Ferramentas, Workbenches e Ambientes CASE O Ciclo de Vida de um Sistema CASE DI-UFPE @1997, Alexandre Vasconcelos

Motivação A Engenharia de Software envolve trabalho técnico, administrativo e de controle; Algumas tarefas são criativas e outras não; Tarefas não-criativas podem ser automatizadas com o uso de CASE (Computer Aided Software Engineering): editores de texto, compiladores, gerenciadores de versões, etc. DI-UFPE @1997, Alexandre Vasconcelos

O que é CASE? É o uso de suporte computacional no processo de desenvolvimento de software; DI-UFPE @1997, Alexandre Vasconcelos

Uma Classificação para Sistemas CASE Classificação permite que sistemas CASE possam ser comparados; Não existe uma classificação padrão; Sistemas CASE podem ser classificados de acordo com várias dimensões: grau de formalidade imposta; tipo de interface oferecida ao usuário; fase(s) do ciclo de vida coberta(s); profundidade do suporte oferecido, etc. DI-UFPE @1997, Alexandre Vasconcelos

Uma Classificação para Sistemas CASE - fases x profundidade Ferramenta - é um produto de software que auxilia em uma ou mais tarefas específicas de uma ou mais fases do processo (ciclo de vida) de desenvolvimento de software (ex: compilação, checagem de consistência de um projeto, edição de texto, etc.); Workbench - conjunto de ferramentas integradas que suporta uma ou mais fases do processo de desenvolvimento de software (ex: especificação, projeto, implementação, etc.). Ambiente - suporta todo ou uma grande parte do processo de desenvolvimento de software. Geralmente é um conjunto de workbenches integrados. Na prática estes limites não são bem definidos. DI-UFPE @1997, Alexandre Vasconcelos

Uma Classificação para Sistemas CASE - fases x profundidade DI-UFPE @1997, Alexandre Vasconcelos

Exemplos de Ferramentas CASE DI-UFPE @1997, Alexandre Vasconcelos

Um Ambiente CASE Típico Desenvolvedores e Gerentes Farermenta A Fearrmenta B Ferramenta X Integrador Plataforma de Hardware e Software Adm. Sist. DI-UFPE @1997, Alexandre Vasconcelos

Qualidade do Suporte CASE DI-UFPE @1997, Alexandre Vasconcelos

Histórico Surgimento de Ferramentas CASE específicas; Primeiras ferramentas voltadas ao desenvolvimento de programas (ex: compiladores); Desenvolvimento de ferramentas incompatíveis; Necessidade de desenvolver ferramentas que pudessem ser integradas; Surgimento de workbenches de programação; DI-UFPE @1997, Alexandre Vasconcelos

Histórico Surgimento de métodos de projeto de software (ex: Jackson, Yourdon, etc.); Adequação destes métodos a CASE (diagramas, anotações e documentos); Surgimento de ferramentas de suporte a estes métodos; Surgimento de workbenches de suporte a outras fases do ciclo de vida de software; DI-UFPE @1997, Alexandre Vasconcelos

Histórico Automação de fases isoladas não foi satisfatória; Surgimento do APSE (Ada Programming Support Environment) na década de 1980; Surgimento de ambientes CASE integrados (IPSEs, ICASE’s, SDE’s ou SEE’s), suportando todo o ciclo de vida de software. DI-UFPE @1997, Alexandre Vasconcelos

Vantagens dos Sistemas CASE Automatiza o trabalho manual (não-criativo); Torna o desenvolvimento menos tedioso; Impõe padrões de notações e métodos entre os usuários; Facilita a verificação de consistência e completude do projeto, documentação e código dos sistemas; Aumenta a produtividade e reduz os custos de desenvolvimento; Ajuda a melhorar a qualidade (ex: confiabilidade, reusabilidade, etc.) do software; DI-UFPE @1997, Alexandre Vasconcelos

Vantagens dos Sistemas CASE Ajuda a melhorar a documentação e manutenção; Possibilita que problemas no desenvolvimento sejam descobertos mais cedo, evitando a propagação entre as diversas fase; Enfim, ameniza a crise de software. DI-UFPE @1997, Alexandre Vasconcelos

Problemas com os Sistemas CASE O grau de melhoria da produtividade é menor do que o esperado, devido a: Alguns problemas de desenvolvimento de software não são completamente automatizáveis (ex: problemas de gerenciamento); Problemas de integração; As pessoas que adotam estes sistemas não dão a devida atenção aos processos de treinamento e adaptação. DI-UFPE @1997, Alexandre Vasconcelos

CASE Workbenches São sistemas especializados, desenvolvidos a partir de ferramentas e tecnologias particulares e que tiveram sua aplicabilidade estendida para cobrir uma ou mais fases do ciclo de vida do desenvolvimento de software; Geralmente são fechados, ou seja, só podem ser estendidos a partir da modificação de sua arquitetura/código-fonte; Existem alguns poucos workbenches abertos, onde novas ferramentas podem ser adicionadas incrementalmente; Existe um grande número de workbenches especializados disponíveis e em uso, oferecendo excelente funcionalidade e ganhos em produtividade; DI-UFPE @1997, Alexandre Vasconcelos

Ferramentas e Workbenches: especificação de requisitos As principais características encontradas nestes sistemas são: Captura de requisitos; Alocação de requisitos a sub-sistemas (de forma gráfica ou textual); Estabelecimento de ligações entre requisitos dependentes/derivados; Rastreamento de requisitos (quem os forneceu?, por que?, evolução, etc.); Gerenciamento de versões dos requisitos; Gerenciamento do trabalho cooperativo (acessos concorrentes, níveis de acesso, etc.). DI-UFPE @1997, Alexandre Vasconcelos

Ferramentas e Workbenches: especificação de requisitos Exemplos: DOORS (Dynamic OO Requirements System) - Quality Systems & Software (QSS); RTM (Requirements and Traceability Management); ProductTrack (Ferramenta para Captura, rastreamento e avaliação de requisitos). DI-UFPE @1997, Alexandre Vasconcelos

Ferramentas e Workbenches: especificação formal As principais características encontradas nestes sistemas são: Ambiente para edição; Verificação léxica, sintática e de tipos; Geração de mensagens de erro com informações suficientes para o usuário localizar e reconhecer o erro; Auxílio à prova formal das especificações. Exemplos: CADiZ (Computer AIded Design in Z) - York Software Engineering; Z-eves - ORA Canada. DI-UFPE @1997, Alexandre Vasconcelos

Ferramentas e Workbenches: análise e projeto de sistemas As principais características encontradas nestes sistemas são: Facilidades para representação gráfica do fluxo de controle e dos dados correspondentes; Facilidades para criação de um modelo do sistema e análise da consistência do mesmo; Suporte a métodos de análise e projeto estruturados (ex: SA/SD, SADT, JSD) e/ou técnicas de modelagem orientadas a objetos (ex: OMT, Booch, UML, etc.); Pode incluir geradores de código a partir do modelo especificado. DI-UFPE @1997, Alexandre Vasconcelos

Ferramentas e Workbenches: análise e projeto de sistemas DI-UFPE @1997, Alexandre Vasconcelos

Ferramentas e Workbenches: análise e projeto de sistemas Exemplos: ObjectMaker - Catalyst Software Ltd. Teamwork - Cadre Technologies, Inc. Paradigm - Platinum Technology. DI-UFPE @1997, Alexandre Vasconcelos

Ferramentas e Workbenches: projeto e desenvolvimento de interfaces As principais características encontradas nestes sistemas são: Facilidades para edição gráfica da interface; Geração do código correspondente a partir do protótipo da interface construída por meio de manipulação direta. Exemplos: Interviews; X-Designer - Imperial Software Technology, UK. DI-UFPE @1997, Alexandre Vasconcelos

Ferramentas e Workbenches: apoio à programação As principais características encontradas nestes sistemas são: Edição, compilação, ligação e depuração de programas. Exemplos: Turbo C; Turbo Pascal; VisualC++; Delphi. DI-UFPE @1997, Alexandre Vasconcelos

Ferramentas e Workbenches: Dirigidos à Linguagem Ferramentas compartilham uma representação comum dos programas (ex: árvore sintática); O editor de texto tem conhecimento da sintaxe da linguagem e pode editar a representação abstrata ao invés do código fonte; Permite que múltiplas visões do programa sejam geradas. DI-UFPE @1997, Alexandre Vasconcelos

Ferramentas e Workbenches: Dirigidos à Linguagem DI-UFPE @1997, Alexandre Vasconcelos

Ferramentas e Workbenches: gerenciamento de projetos As principais características encontradas nestes sistemas são: Facilidades para representação de fluxo de documentos; Geração de métricas de produtividade; Estimativas de esforço e custos; Facilidades para gerenciamento de tarefas: Quais as tarefas a serem executadas e por quem? Qual o cronograma de execução das tarefas? Quais os pré-requisitos para execução das tarefas? Quais os recursos disponíveis para a execução das tarefas? Quais os custos para a execução das tarefas? DI-UFPE @1997, Alexandre Vasconcelos

Ferramentas e Workbenches: gerenciamento de projetos Exemplos: Project - Microsoft; Time Line - Symantec. DI-UFPE @1997, Alexandre Vasconcelos

Ferramentas e Workbenches: gerenciamento de configurações As principais características encontradas nestes sistemas são: Controle de acesso às bibliotecas de componentes (ex: duas pessoas não podem fazer modificações de um mesmo componente ao mesmo tempo); Controle de versões; Controle de dependências para a reconstrução do sistema. Exemplos: SCCS (Source Code Control System) e make no sistema Unix. DI-UFPE @1997, Alexandre Vasconcelos

Ferramentas e Workbenches: teste de software Tentam propiciar uma redução do tempo e do custo do esforço de teste; As principais características encontradas nestes sistemas são: Documentação de testes: Definição do teste, armazenamento e recuperação. Suporte à geração de casos de teste; Suporte à avaliação dinâmica da atividade de teste: Métricas (ex: número de comandos executados pelo teste); Percentagem de caminhos cobertos pelo teste, etc.; Suporte à avaliação estática (ex: análise da complexidade do software com respeito à facilidade de manutenção); Análise de abrangência (os testes foram exaustivos?). DI-UFPE @1997, Alexandre Vasconcelos

Ferramentas e Workbenches: teste de software Exemplos: +1Test - +1 Software Engineering; Ferramentas da Eastern Systems Inc.: TestPlan (gerenciamento de testes); TestBed (ferramenta de análise estática/dinâmica de testes); TestDesigner (ferramenta de testes). DI-UFPE @1997, Alexandre Vasconcelos

Ferramentas e Workbenches: documentação As principais características encontradas nestes sistemas são: Extração automática de informações de outras ferramentas usadas no desenvolvimento; Extração automática de informações do código fonte; Geração de documentos de acordo com determinados padrões. Exemplos: Interleaf; PageMaker - Aldus. DI-UFPE @1997, Alexandre Vasconcelos

Ferramentas e Workbenches: engenharia reversa As principais características encontradas nestes sistemas são: Extração de informações sobre a arquitetura do sistema, estrutura de controle, fluxo lógico, estrutura de dados e fluxo de dados, a partir da análise do código fonte; Construção do modelo comportamental do sistema a partir da análise dinâmica do sistema. Essa característica é bastante rara. Exemplos: PathMap - Cadre. DI-UFPE @1997, Alexandre Vasconcelos

Meta-CASE Workbenches Alguns workbenches são conceitualmente similares. Ex: em workbenches de projeto e análise, as diferenças podem ser o tipo de diagrama suportado e as regras utilizadas; em workbenches de programação, as ferramentas compartilham uma representação sintática dos programas, a qual pode ser definida separadamente; Meta-CASE Workbenches são sistemas que dão apoio ao processo de criação de outros workbenches. DI-UFPE @1997, Alexandre Vasconcelos

Meta-CASE Workbenches Os primeiros sistemas deste tipo foram criados na década de 1980 (Mentor, Synthesizer Generator, Gandalf); Nestes sistemas, a sintaxe e a semântica da linguagem alvo são definidas e usadas para adaptar ferramentas genéricas de processamento de linguagens. DI-UFPE @1997, Alexandre Vasconcelos

Meta-CASE Workbenches DI-UFPE @1997, Alexandre Vasconcelos

Vantagens dos Workbenches Geralmente estão disponíveis para uso em computadores pessoais de baixo custos; Facilitam a padronização da documentação de sistemas de software; Estima-se ganhos de produtividade em torno de 40% nos projetos, os quais são produzidos com menos defeitos. DI-UFPE @1997, Alexandre Vasconcelos

Desvantagens dos Workbenches São sistemas geralmente fechados. Dificilmente podem ser integrados com outros sistemas; Facilidades de importação e exportação de documentos são limitadas (geralmente ASCII e diagramas Postscript); É difícil e muitas vezes impossível adaptá-los às necessidades específicas das organizações; Deficiências no gerenciamento de configurações, principalmente devido à impossibilidade de relacionar documentos produzidos no workbench com documentos produzidos externamente. DI-UFPE @1997, Alexandre Vasconcelos

Ambientes de Propósito Geral São ambientes que já foram concebidos como plataformas capazes de incorporar uma vasta gama de ferramentas; Destinam-se ao suporte de sistemas de software de grande escala; São denominados IPSE’s; Existem poucos ambientes comerciais de propósito geral e mesmo os que existem oferecem funcionalidade limitada. DI-UFPE @1997, Alexandre Vasconcelos

Ambientes de Propósito Geral: requisitos Suportar o desenvolvimento de software de grande porte; Suportar todo o ciclo de vida de software; Suportar e integrar os diversos métodos usados nas diversas fases; Estabelecer um guia automático para elaboração de um projeto, passando por todas as fases do ciclo de vida de software, integrando as ferramentas e dados; Permitir acesso direto a qualquer ferramenta, obedecendo a certos pre-requisitos; Oferecer uma interface com o usuário consistente e uniforme em todas as ferramentas; DI-UFPE @1997, Alexandre Vasconcelos

Ambientes de Propósito Geral: requisitos Prover mecanismos para compartilhar informações entre as ferramentas; Permitir propagação de atualização por todas as ferramentas, se houver alteração da base de dados em uma delas; Prover controle de versão e gerenciamento de configuração sobre todas as informações; Permitir trabalho cooperativo; Ser configurável de acordo com as necessidades dos projetos e usuários; DI-UFPE @1997, Alexandre Vasconcelos

Ambientes de Propósito Geral: requisitos Permitir a reusabilidade de componentes de software; Ser extensível (aberto), isto é, permitir que novas ferramentas sejam incorporadas; Suportar a comunicação entre as equipes de desenvolvimento; Coletar dados para medição de produtividade do processo de desenvolvimento de software. DI-UFPE @1997, Alexandre Vasconcelos

Ambientes de Propósito Geral: problemas Pouca evidência prática das vantagens teóricas destes ambientes em termos do custo-benefício; Tamanho e complexidade dos ambientes, levando a: Custos elevados para aquisição, treinamento, manutenção e uso; Muitos sistemas não têm uma boa performance; Necessidade de pessoal de suporte para instalação, monitoração e ajustes; Decréscimo da produtividade no período de implantação, devido à falta de familiaridade e à mudança da sistemática de trabalho; DI-UFPE @1997, Alexandre Vasconcelos

Ambientes de Propósito Geral: problemas Inflexibilidade: Idealmente ambientes deveriam ser customizáveis para cada usuário; Na prática, a maioria dos ambientes disponibiliza um certo número de ferramentas e o melhor que pode ser feito é a incorporação de novas ferramentas; Poucos são os sistemas que permitem a flexibilização do processo de desenvolvimento. A tecnologia ainda é instável (falta ou excesso de padrões). DI-UFPE @1997, Alexandre Vasconcelos

O Ciclo de Vida um Sistema CASE O ciclo de vida de um sistema CASE é comparável ao ciclo de vida de um software desenvolvido usando tal sistema; Existem vários estágios que podem ser identificados no uso de um sistema CASE: Escolha; Adaptação; Introdução; Uso; Evolução; Obsolescência. DI-UFPE @1997, Alexandre Vasconcelos

O Ciclo de Vida de um Sistema CASE Escolha Adaptação Introdução Uso Evolução Obsolescência DI-UFPE @1997, Alexandre Vasconcelos

O Estágio da Escolha: definição Envolve a escolha de um sistema CASE apropriada(o) para o tipo de software a ser desenvolvido na empresa. DI-UFPE @1997, Alexandre Vasconcelos

O Estágio da Escolha: fatores Os fatores a serem levados em conta na escolha de um sistema CASE são: Padrões e métodos adotados na empresa devem ser suportados; O hardware existente e os futuros desenvolvimentos do hardware; As classes de aplicações a serem desenvolvidas; Segurança de acesso; Preço (aquisição, manutenção e evolução). DI-UFPE @1997, Alexandre Vasconcelos

O Estágio da Adaptação: definição Envolve a adaptação do sistema para as necessidades específicas da empresa. DI-UFPE @1997, Alexandre Vasconcelos

O Estágio da Adaptação: principais atividades Instalação e teste; Definição do modelo de processo de software - mesmo que não seja possível embutir este modelo (ex: cascata, espiral, etc.) no sistema, esta atividade é necessária para que o gerente visualize onde o sistema CASE pode ser usado e que interfaces com outras ferramentas precisam ser construídas; DI-UFPE @1997, Alexandre Vasconcelos

O Estágio da Adaptação: principais atividades Integração - envolve a integração do sistema CASE com outros sistemas CASE. Se o novo sistema baseia-se num Sistema de Gerenciamento de Objetos (OMS) compartilhado, o esquema deve ser definido e validado. Isto envolve identificar todas as entidades e relacionamentos que são importantes para o processo de desenvolvimento de software da organização; Se o novo sistema é baseado em arquivos, um formato comum de arquivos deve ser adotado, ou quando não, programas filtros devem ser construídos. Documentação - todo o processo de instalação e adaptação deve ser documentado. DI-UFPE @1997, Alexandre Vasconcelos

O Estágio da Introdução: definição Envolve a introdução do sistema CASE na empresa. Para isto, é necessário que o engenheiro de software seja adequadamente treinado para o seu uso. DI-UFPE @1997, Alexandre Vasconcelos

O Estágio da Introdução: problemas Resistência por parte dos usuários: crença de que os sistemas CASE são mais prescritivos e limitam a criatividade individual de cada pessoa. Deficiência de treinamento: usuários são relutantes em aprender novas tecnologias; dificuldades em entender características/facilidades dos novos sistemas. Resistência por parte da gerência: medo de que a introdução de tecnologia desconhecida dificulte o processo de gerenciamento. DI-UFPE @1997, Alexandre Vasconcelos

O Estágio da Introdução: respostas aos problemas Resistência por parte dos usuários: o sistema CASE dará assistência às tarefas maçantes do desenvolvimento de software (ex: redesenhar diagramas de projeto, encontrar o código associado à documentação e vice-versa, etc.); os engenheiros de software terão mais tempo para as tarefas criativas e gratificantes do seu trabalho; não é pretensão dos sistemas CASE desestimular a habilidade de criar dos engenheiros de software. DI-UFPE @1997, Alexandre Vasconcelos

O Estágio da Introdução: respostas aos problemas Deficiência de treinamento: o treinamento deve ser de boa qualidade; o orçamento dedicado ao treinamento deve ser adequado; a migração para a nova tecnologia deve ser gradativa. Resistência por parte da gerência: os custos de introdução da tecnologia em novos projetos devem ser cuidadosamente medidos e comparados com os custos anteriores; estas medidas podem ser usadas para convencer os gerentes das vantagens da introdução de novas ferramentas/ambientes. DI-UFPE @1997, Alexandre Vasconcelos

O Estágio do Uso: definição Envolve o uso da ferramenta/ambiente no desenvolvimento de software do dia-a-dia. Após a introdução da ferramenta/ambiente em projetos pilotos, tal tecnologia pode se tornar disponível para todos os projetos; Inicialmente o uso deve ser incentivado, mas com o ganho de experiência este uso pode se tornar obrigatório. DI-UFPE @1997, Alexandre Vasconcelos

O Estágio da Evolução: definição Na realidade não é um estágio isolado, pois é uma atividade contínua durante todo o ciclo de vida da ferramenta/ambiente; Envolve a modificação da ferramenta/ambiente para adaptá-la a novos requisitos ou a novas plataformas de hardware ou software. DI-UFPE @1997, Alexandre Vasconcelos

O Estágio da Evolução: problemas As versões nova e velha da ferramenta/ambiente podem não ser compatíveis devido a mudanças no hardware/software; Se esta incompatibilidade existir e forem necessárias ambas as versões da ferramenta/ambiente na empresa, então a infra-estrutura antiga de hardware/software terá que ser mantida na empresa, juntamente com a nova infra-estrutura. DI-UFPE @1997, Alexandre Vasconcelos

O Estágio da Obsolescência: definição Este é o estágio no qual a ferramenta/ambiente se torna fora de uso: devido a deficiência de suporte por parte do fabricante/vendedor; devido a mudanças na plataforma de hardware e/ou software da empresa; devido à substituição por outra ferramenta/ambiente mais adequado para a empresa. DI-UFPE @1997, Alexandre Vasconcelos

O Estágio da Obsolescência: problemas Garantir que o software desenvolvido usando a ferramenta/ambiente ainda pode ser suportado pela empresa; Um período de transição/migração para uma nova tecnologia deve ser cuidadosamente planejado; Este período é mais tranqüilo se o software desenvolvido usando a ferramenta/ambiente já se tornou obsoleto. DI-UFPE @1997, Alexandre Vasconcelos

Pontos-chave CASE envolve o suporte automatizado ao processo de desenvolvimento de software; A tecnologia CASE pode ser classificada de acordo com diversas características (ex: funcionalidade, fases do desenvolvimento suportadas, etc.); Ferramentas dão suporte a atividades individuais, workbenches dão suporte a conjuntos de atividades e ambientes dão suporte a todo o processo. DI-UFPE @1997, Alexandre Vasconcelos