DI-UFPE1 Sistemas CASE Seleção, Avaliação e Adoção de Ferramentas CASE.

Slides:



Advertisements
Apresentações semelhantes
Gerenciamento de Projetos
Advertisements

BENCHMARKING.
A estrutura do gerenciamento de projetos Introdução
Sistema de Informação Gerencial
Gerenciamento de Projetos
ISO Processos do Ciclo de Vida do Software
Processos de Software Introdução
Gerenciamento de Pessoal
Mitos e Problemas Relacionados ao Software
Qualidade de Software Aula 2
PLANOS DE NEGÓCIOS ESTRUTURA E ESTRATÉGIA DE ELABORAÇÃO
Planejamento do gerenciamento de riscos
Implementação de Sistemas
Prof. Everton Lopes Bonifácio
Sistemas de Informação Capítulo 6
TSDD Teste de segurança durante o desenvolvimento.
Engenharia de Software
Estratégias do agronegócio
Sistema de Informação Gerencial (SIG)
Modelos de Maturidade de Processos de Software
Cap 2 – Processo de Software
Análise e Projeto de Sistemas
Qualidade de Produto de Software
Metolodogia de Desenvolvimento de Data Warehouse
Capability Maturity Model (CMM)
Gerenciamento da Integração
PMBOK 5ª Edição Capítulo 9
Análise de problemas Capacidade de pensamento crítico
Qualidade de Software Aula 2 / 2014/1
DISCIPLINA Pesquisa de Tecnologias Emergentes - PTE Profa. Eliane
Profª. Selma Maria da Silva
Implantação e Melhoria de Processos de SOFTWARE
Modelos de Maturidade de Processos de Software
Otimizando sua TI, maximizando seus negócios
Processo de Aquisição Adilson de Almeida Cezar Meriguetti
O Processo de desenvolvimento de software
Estratégia Organizacional
Gerência de Projetos.
Aula 2 Gerência de Projeto no Contexto do Modelo de Maturidade e Capacidade de Software - CMM.
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.
Sistemas de Informação
EPR16 – Planejamento e Gestão da Qualidade Professora Michelle Luz
METODOLOGIA, MÉTODOS E FERRAMENTAS
Gabriel Bastos Machado
Modelagem de Processos de Negócio
FUNDAMENTOS DE MARKETING ELEMENTOS DO MARKETING
Modelos de Qualidade para indivíduos e grupos: PSP & TSP
Engenharia de Software
Integração de Ferramentas CASE
Equipe Prof. Henrique Freitas
FERRAMENTAS DE MARKETING
Gerenciamento dos Recursos Humanos
POLITICAS DE SEGURANÇA
Conceitos de Monitoramento
Prof. Fábio Botelho Metodologia de Desenvolvimento de Software - MDS Padrões de Processo de Software: CMMI.
PROF. Ms. DELANO GURGEL DO AMARAL. A Estruturação das Soluções dos Treinamentos ou cursos de curta duração, são Customizadas, combina diferentes eixos.
Visão Geral da Gestão de Projetos
Sobre a Prime Control A Prime Control é um Centro de Excelência em Qualidade de Software. Nossa missão é desenvolver, aperfeiçoar e realizar serviços.
Gestão de Projetos - aula 5: organização - Profª. Vilma Tupinambá, MsC
Análise e Projeto de Sistemas Análise e Projeto de Sistemas Aula 2 Professor: Italo Rodrigues Castro.
ISO9001:2000 para Software Professor: Alexandre Vasconcelos Equipe: Amanda Pimentel Börje Karlsson Danielly Karine Erika Pessoa Jorge Cavalcanti Jose Edson.
Apresentação Leonardo Brussolo de Paula
Programa criado em Apoio ao programa: Ministério da Ciência e Tecnologia da Finep Banco Interamericano de Desenvolvimento Universidades e Governo.
Introdução – ISO Conceitos relacionados a Norma NBR ISO/IEC 12207; Procedimentos de ciclo de vida e desenvolvimento de software; Objetivos e a estrutura.
PROJETO SPICE ISO Integrantes: Erickson Balzaneli
Processos de Software Ludimila Monjardim Casagrande 1º Semestre Desenvolvimento e Qualidade.
Planejamento Estratégico Planejamento Estratégico de de Tecnologia de Informação Prof. Antonio Márcio M. Carmo Prof. Antonio Márcio M. Carmo.
GUGP - GRUPO DE USUÁRIOS DE GERENCIAMENTO DE PROJETOS OS DESAFIOS DO GERENCIAMENTO DE PROJETOS DE IMPLANTAÇÃO DE ERP.
Sistemas de Informação Capítulo 6 O uso consciente da tecnologia para o gerenciamento.
CMMI Capability Maturity Model Integration
Transcrição da apresentação:

DI-UFPE1 Sistemas CASE Seleção, Avaliação e Adoção de Ferramentas CASE

DI-UFPE2DI-UFPEDI-UFPE Enfoques n Empírico; n Baseado na Engenharia de Software.

DI-UFPE3DI-UFPEDI-UFPE Enfoque Empírico n Na maioria das organizações, o processo de aquisição de ferramentas CASE (quando são adotadas) tem sido o seguinte:  Experimenta-se uma falha no software;  Houve-se “falar” que o uso de ferramentas CASE pode evitar tais problemas;  Compra-se uma ferramenta anunciada;  Tenta-se descobrir que processos se encaixam no escopo da ferramenta;

DI-UFPE4DI-UFPEDI-UFPE Enfoque Empírico  Assume-se que todos os problemas foram resolvidos;  Se os problemas persistem, culpa-se os membros do staff por não saberem usar a ferramenta propriamente;  Contrata-se um consultor que não consegue os resultados esperados;  Desilude-se com a ferramenta adquirida;  “Engaveta-se” a ferramenta.

DI-UFPE5 Um Enfoque da Engenharia de Software n O SEI (Software Engineering Institute) propôs um enfoque para seleção e adoção de ferramentas baseado nas seguintes etapas: Conhecimento e Tomada de Decisão Seleção Julgamento Estratégia de implantação Institucionalização

DI-UFPE6 Um Enfoque da Engenharia de Software: conhecimento e tomada de decisão n Nesta fase procura-se conhecer melhor o perfil da organização, para avaliar a aplicabilidade ou não de ferramentas CASE como parte da solução para os problemas organizacionais; n Tal fase pode ser dividida nas seguintes sub-fases:  Avaliação de pessoal;  Avaliação da tecnologia usada na organização;  Avaliação do processo organizacional;  Avaliação dos projetos da organização;  Avaliação da política organizacional;  Avaliação de necessidades adicionais.

DI-UFPE7 Um Enfoque da Engenharia de Software: conhecimento e tomada de decisão n Avaliação de pessoal:  Como os empregados irão reagir à introdução de uma nova tecnologia?  Existe algum registro de mudanças que foram tentadas (sucessos e falhas)?  Existem lideranças capazes de influenciar o pessoal técnico no que concerne à adoção ou não de novas tecnologias?  Qual a habilidade do pessoal para aprender novas técnicas?  Qual a habilidade técnica do pessoal de suporte?

DI-UFPE8 Um Enfoque da Engenharia de Software: conhecimento e tomada de decisão n Avaliação de pessoal (cont.):  Quais as tarefas assinaladas ao pessoal técnico?  Qual a habilidade do pessoal de staff para gerenciar as inovações e mudanças?  Quão estável é o pessoal de staff? Existem constantes mudanças de decisão e/ou de chefia?

DI-UFPE9 Um Enfoque da Engenharia de Software: conhecimento e tomada de decisão n Avaliação da tecnologia usada na organização:  Quais as plataformas de hardware/software existentes atualmente na organização?  Os recursos existentes são satisfatórios?  Qual o grau de integração do software utilizado?  Quais as linguagens de programação utilizadas?  A organização utiliza recursos de rede?  Em média, qual a percentagem de desenvolvimento, reuso e manutenção de sistemas?  A plataforma de desenvolvimento difere da plataforma de uso?

DI-UFPE10 Um Enfoque da Engenharia de Software: conhecimento e tomada de decisão n Avaliação do processo organizacional:  Quão bem definido é o processo de desenvolvimento de software na organização?  O processo de desenvolvimento ou parte dele é passível de automação?  Qual o modelo de ciclo de vida adotado pela organização?  Quais os métodos de desenvolvimento adotados pela organização (SADT, SA/SD, JSD, OMT, etc.)?  Quão experiente é o pessoal com os métodos adotados?  Algum destes métodos foi adaptado para ser aplicado à organização?  Os métodos utilizados são satisfatórios?

DI-UFPE11 Um Enfoque da Engenharia de Software: conhecimento e tomada de decisão n Avaliação do processo organizacional (cont.):  A adoção de um novo processo e/ou método de desenvolvimento seria adequado à organização?  Existe algum padrão de documentação adotado (ou a ser adotado) pela organização?  Existe algum programa (padrão) de qualidade de software adotado (ou a ser adotado) pela organização?  A organização coleta alguma métrica de produtividade? Como e para quê ela é utilizada?

DI-UFPE12 Um Enfoque da Engenharia de Software: conhecimento e tomada de decisão n Avaliação dos projetos da organização:  Quais os domínios de atuação atendidos negócios da organização?  Quais os tamanhos dos projetos e durações normais?  Qual o grau em que produtos similares são produzidos?  Por quais fases da produção a organização é responsável?  Qual a complexidade do processo de produção em cada fase?  Quão experiente e decisivo deve ser o gerenciamento de dos projetos?

DI-UFPE13 Um Enfoque da Engenharia de Software: conhecimento e tomada de decisão n Avaliação da política organizacional:  Como a produtividade e a qualidade dos produtos da organização se comparam com a de seus concorrentes?  Quais as metas de produtividade e qualidade a serem atingidas?  A gerência está satisfeita com a situação atual?  Qual o compromisso da gerência em termos de investimento em dinheiro, pessoal e projetos?  Existe algum suporte organizacional para encorajar a adoção de novas ferramentas e tecnologias? Vontade de arriscar, invovar e mudar?  Como as falhas têm sido gerenciadas?

DI-UFPE14 Um Enfoque da Engenharia de Software: conhecimento e tomada de decisão n Avaliação da política organizacional (cont.):  Existem pressões da gerência para a adoção de ferramentas CASE?  Em que grau a gerência considera que o uso de ferramentas CASE será estratégico como fator diferencial de competitividade?  Como o uso de uma ferramenta CASE poderá afetar os custos, cronograma e a qualidade dos projetos?  Qual o período esperado para se obter retorno em termos de custo-benefício?  Qual é o balanço do retorno dos investimentos passados?  As expectativas da gerência são factíveis?

DI-UFPE15 Um Enfoque da Engenharia de Software: conhecimento e tomada de decisão n Avaliação de necessidades adicionais:  Quais as partes do ciclo de vida que estão funcionando melhor/pior?  Quais as partes do ciclo de vida do software que podem ser melhoradas com o uso de ferramentas CASE?  Quais as necessidades adicionais de documentação?  Os mecanismos de comunicação inter-pessoal estão funcionando adequadamente?  Que facilidades adicionais melhorariam a comunicação?

DI-UFPE16 Um Enfoque da Engenharia de Software: seleção n Nesta fase faz-se uma análise rigorosa sobre qual ferramenta será adotada. Caso contrário corre-se o risco de adquirir uma ferramenta que não será usada; n A seleção pode ser dividida nas seguintes sub-fases:  Avaliação da tecnologia disponível para adoção: èAnálise das ferramentas disponíveis; èAnálise do fornecedor da ferramenta; èAnálise das experiências de outros usuários.  Avaliação da aplicabilidade da tecnologia.

DI-UFPE17 Um Enfoque da Engenharia de Software: seleção n Avaliação da tecnologia disponível para adoção:  Análise das ferramentas disponíveis: èÉ viável desenvolver uma ferramenta CASE própria? èQue ferramentas existem no mercado que podem servir a organização? èAlguma das ferramentas existentes é customizável ou suporta diretamente o processo de desenvolvimento adotado pela organização? èQual o hardware/software necessário para a implantação da ferramenta? èQuão difícil será a inserção da ferramenta no ambiente organizacional?

DI-UFPE18 Um Enfoque da Engenharia de Software: seleção n Avaliação da tecnologia disponível para adoção:  Análise das ferramentas disponíveis (cont.): èQuão compatível é a ferramenta em relação a outras ferramentas e métodos? A ferramenta é passível de integração com outras ferramentas usadas na organização? èVersões de teste estão disponíveis? Se sim, devem ser solicitadas; èA ferramenta funciona bem em um ambiente multi-usuário? èQual a performance da ferramenta em relação a uma grande carga de uso e acessos simultâneos? èA ferramenta funciona bem tanto para projetos de pequeno como de grande porte? A ferramenta proporciona meios para decomposição de projetos em sub-projetos?

DI-UFPE19 Um Enfoque da Engenharia de Software: seleção n Avaliação da tecnologia disponível para adoção:  Análise das ferramentas disponíveis (cont.): èQual o grau de maturidade da ferramenta a ser utilizada? èA ferramenta tem capacidade de funcionar em condições adversas (robustez)? èOs mecanismos de disponibilização de atualizações da ferramenta são satisfatórios para a organização? èA interface da ferramenta é de fácil uso? èO pessoal técnico é conhecedor das metodologias suportadas pela ferramenta? Será preciso oferecer treinamento especializado para eles? èQual o tempo necessário para o pessoal técnico se adaptar à ferramenta?

DI-UFPE20 Um Enfoque da Engenharia de Software: seleção n Avaliação da tecnologia disponível para adoção:  Análise das ferramentas disponíveis (cont.): èA ferramenta a ser adotada está de acordo com algum programa de qualidade adotado (ou a ser adotado) pela organização? èA ferramenta a ser adotada tem que oferecer todas as facilidades desejadas? èQual o custo (financeiro e de tempo) para aquisição, implantação, treinamento e manutenção da ferramenta, incluindo também os custos de hardware, software e pessoal? èEstes custos ameaçam a aquisição da ferramenta?

DI-UFPE21 Um Enfoque da Engenharia de Software: seleção n Avaliação da tecnologia disponível para adoção:  Análise do fornecedor da ferramenta: èA quanto tempo o fornecedor está no mercado de ferramentas CASE? èA produção de ferramentas CASE é a linha principal de negócios do fornecedor? èQual o balanço quantitativo de vendas do fornecedor no período de um ano? èExiste algum sentimento sobre a estabilidade do fornecedor no mercado, por pelo menos um período de 5 anos (prazo estimado para uma ferramenta cair em desuso)?

DI-UFPE22 Um Enfoque da Engenharia de Software: seleção n Avaliação da tecnologia disponível para adoção:  Análise do fornecedor da ferramenta (cont.): èA qualidade do suporte oferecido pelo fornecedor é boa? Meio de comunicação; Tempo para atendimento; Localização geográfica. èO fornecedor oferece treinamento? èO fornecedor irá customizar a ferramenta e/ou treinamento às necessidades da organização? èQual a reputação do fornecedor no mercado de ferramentas CASE?

DI-UFPE23 Um Enfoque da Engenharia de Software: seleção n Avaliação da tecnologia disponível para adoção:  Análise das experiências de outros usuários: èExiste algum grupo de discussão sobre a ferramenta na Internet? Se sim, qual tem sido a avaliação dos usuários? èExiste algum comentário crítico sobre a ferramenta na mídia (publicações especializadas, anais de congresso, etc.)? èA organização tem conhecimento da experiência de outros usuários? Qualidade e nível de suporte; Problemas com a ferramenta; Dicas e exemplos de uso, etc.

DI-UFPE24 Um Enfoque da Engenharia de Software: seleção n Avaliação da aplicabilidade da tecnologia:  Nesta sub-fase é tomada a decisão, com base nas questões levantadas anteriormente, se a ferramenta selecionada adequa-se às necessidades da organização;  Os pontos fortes e fracos da ferramenta são “pesados” e comparados;

DI-UFPE25 Um Enfoque da Engenharia de Software: seleção n Avaliação da aplicabilidade da tecnologia (cont.)  Esta avaliação baseia-se principalmente em: èCompatibilidade da ferramenta com as capacidades do pessoal técnico; èA tecnologia de software e hardware usada pela ferramenta; èO grau de suporte aos processo e métodos adotados pela organização; èA capacidade de integração oferecida pela ferramenta; èA performance da ferramenta e o suporte oferecido ao trabalho cooperativo; èA qualidade da documentação e do suporte oferecido; èCompatibilidade entre a ferramenta e as necessidades adicionais da organização.

DI-UFPE26 Um Enfoque da Engenharia de Software: julgamento n Nesta fase a ferramenta escolhida deve ser experimentada em um projeto-piloto; n Critérios de avaliação (sucessos e insucessos) devem ser definidos antes de se começar a usar a ferramenta; n O projeto-piloto deve ser representativo em relação aos projetos que efetivamente vão usar a ferramenta; n Idealmente o experimento deveria ser feito antes da aquisição da ferramenta, em uma versão de teste, mas nem sempre isto é possível (tal facilidade pode não ser oferecida pelo fornecedor);

DI-UFPE27 Um Enfoque da Engenharia de Software: julgamento n Os principais objetivos a serem alcançados nesta fase são:  Desenvolvimento de especialistas que podem disseminar o uso da ferramenta na organização;  Documentação sobre as experiências de uso da ferramenta;  Direcionamento da ferramenta, dos métodos e dos processos organizacionais, para um uso mais efetivo da ferramenta;  Desenvolvimento de padrões e guias sobre o uso da ferramenta;  Identificação de necessidades de treinamento.

DI-UFPE28 Um Enfoque da Engenharia de Software: julgamento n Os principais objetivos a serem alcançados nesta fase são (cont.):  Estabelecimento de um ambiente “seguro onde os indivíduos podem aprender mais sobre a ferramenta sem pressões excessivas;  Desenvolvimento de expectativas realísticas para a implantação da ferramenta em toda a organização (ex: cronograma de implantação);  Desenvolvimento de uma estratégia organizacional para a implantação da ferramenta (ex: definição de prioridades, política de migração, etc.).

DI-UFPE29 Um Enfoque da Engenharia de Software: estratégia de implantação n Nesta fase define-se a estratégia de implantação da ferramenta na organização de modo que o impacto organizacional seja o menor possível; n Em adição ao cronograma de implantação, a estratégia de implantação deve levar em conta os seguintes pontos:  Mudança de cultura na organização;  Treinamento;  Estabelecimento de padrões;  Avaliação da efetividade da ferramenta.

DI-UFPE30 Um Enfoque da Engenharia de Software: estratégia de implantação n Mudança de cultura na organização:  Identificar as pessoas-chave e seus papéis na implantação;  Assegurar que as pessoas-chave tenham uma visão comum do porque, o que e como será implantado;  Identificar as pessoas mais sucetíveis às mudanças e incentivá-las;  Identificar as maiores barreiras para a implantação da ferramenta, baseando-se em experiências anteriores;  Tentar minimizar as barreiras para a implantação;  Planejar a estratégia da gerência para convencer e comunicar o pessoal sobre a adoção da ferramenta;  Monitorar e se preciso corrigir a estratégia de implantação.

DI-UFPE31 Um Enfoque da Engenharia de Software: estratégia de implantação n Treinamento - a definição da estratégia de treinamento depende de:  Complexidade dos produtos desenvolvidos pela organização;  Qualidade dos cursos disponíveis;  O orçamento disponível para o treinamento;  O tempo que a gerência disponibilizará para o treinamento;  A formação e o interesse do pessoal que utilizará a ferramenta;  A existência e disponibilização de pessoal habilitado a servir como multiplicador de conhecimento. Este pessoal poderá ser treinado e então treinar o restante da equipe (solução satisfatória e mais econômica).

DI-UFPE32 Um Enfoque da Engenharia de Software: estratégia de implantação n Estabelecimento de padrões - para o sucesso da ferramenta é essencial que certos padrões sejam estabelecidos:  Padrões para usar a ferramenta;  Convenções de nomes para as entidades manipuladas pela ferramenta;  Padrões para backup e compartilhamento da base de dados da ferramenta;  Padrões de segurança;

DI-UFPE33 Um Enfoque da Engenharia de Software: estratégia de implantação n Estabelecimento de padrões (cont.):  Padrões de relatórios para cada etapa do ciclo de vida do software;  Padrões para documentação do software;  Padrões para a análise de produtividade e qualidade do trabalho;  Padrões e técnicas para a interface com outras ferramentas;

DI-UFPE34 Um Enfoque da Engenharia de Software: estratégia de implantação n Avaliação da efetividade da ferramenta:  Nesta etapa define-se a estratégia para medir os ganhos de produtividade e/ou qualidade obtidos com a implantação da ferramenta em relação à sistemática anterior.

DI-UFPE35 Um Enfoque da Engenharia de Software: institucionalização n Nesta fase o uso da ferramenta é adotado como norma institucional; n Os seguintes mecanismos podem auxiliar à institucionalização da ferramenta:  Suporte para treinamento continuado quando do lançamento de novos releases e da incorporação de novo pessoal técnico;

DI-UFPE36 Um Enfoque da Engenharia de Software: institucionalização n Mecanismos para a institucionalização da ferramenta (cont.):  Desenvolvimento e implementação de políticas para update da ferramenta (ex: definição de procedimentos e responsabilidades de instalação);  Desenvolvimento de mecanismos para compartilhamento de experiências (ex: grupos de discussão, relatórios internos, bibliotecas de reuso, publicações em congressos, etc.);  Bom relacionamento com o fornecedor;  Desenvolvimento de mecanismos para incentivar o uso da ferramenta (reconhecimento público dos bons funcionários, recompensas por produtividade, etc.);  Avaliação continua da qualidade e da produtividade.

DI-UFPE37DI-UFPEDI-UFPE Conclusões n A crise de software está longe de ser resolvida por completo; n O uso de ferramentas e ambientes no processo de desenvolvimento de software contribui para amenizar esta crise; n O CASE está para a Engenharia de Software assim como o CAD/CAM (Computer Aided Design/ Computer Aided Manufacture) está para as outras engenharias;

DI-UFPE38 Conclusões n No entanto o CAD/CAM implementa práticas de engenharia que foram experimentadas e provadas ao longo dos últimos 100 anos; n O CASE, por sua vez, apresenta um conjunto de ferramentas semi-automatizadas e automatizadas que implementam uma cultura de engenharia que é novidade para muitas organizações; n Existe uma grande quantidade de ambientes especializados, os quais são geralmente fechados; n A maioria dos ambientes existentes está longe de ser de propósito geral;

DI-UFPE39 Conclusões n Os ambientes CASE emergentes apresentam as seguintes características, entre outras:  Uso de interfaces gráficas padrão;  Repositório compartilhado (se tornando comum);  Estão caminhando rumo a modelos comuns;  Arquitetura cliente-servidor;  Pequeno suporte à integração por processo;  Interação dinâmica entre as ferramentas;  Troca de mensagens entre as ferramentas.

DI-UFPE40DI-UFPEDI-UFPE Conclusões n Ambientes genéricos baseados em PTIs permitem que todo o ciclo de vida seja suportado. Porém não existe um conjunto completo de ferramentas que suporte isto na prática; n Um dos grandes problemas no uso de CASE é a integração de ferramentas; n Apesar de ser mais disciplinado, o processo de seleção de ferramentas CASE adotado pela Engenharia de software ainda não é preciso. Depende das necessidades da organização;

DI-UFPE41DI-UFPEDI-UFPE Conclusões n Estima-se que mais da metade de todas as ferramentas CASE adquiridas caem no desuso muito rapidamente. Isto implica em prejuízos econômicos (hardware, software, treinamento e da própria ferramenta) e decréscimo de produtividade; n O sucesso de uma ferramenta CASE depende não só da ferramenta, mas também do processo de adoção da mesma na organização;

DI-UFPE42 Conclusões n As estratégias de seleção e adoção de ferramentas apresentadas não garantem o sucesso da ferramenta a ser adotada, porém diminuem consideravelmente a probabilidade de insucesso; n De forma análoga aos custos de correção de erros de software, quanto mais tarde se descobre que a ferramenta é inadequada para a organização, maior será a perda econômica e de tempo;

DI-UFPE43 Conclusão n Um pré-requisito para a implantação de uma ferramenta/ambiente CASE em uma organização é que o processo de desenvolvimento de software tem que estar bem definido. Uma ferramenta/ambiente CASE suporta o processo, mas não é um substituto para os procedimentos de desenvolvimento.

DI-UFPE44DI-UFPE Perspectivas Futuras n No futuro, espera-se que exista um padrão ao qual todos os ambientes deverão obedecer, o que permitirá uma melhor integração de ferramentas; n Os ambientes e ferramentas deverão ser mais customizáveis, de modo a que possam se adaptar às necessidades dos usuários; n Do ponto de vista do usuário final, as ferramentas deverão oferecer a possibilidade de produzir aplicações de maneira rápida (ex: geração automática de código, facilidades para localização de componentes reutilizáveis);

DI-UFPE45 Perspectivas Futuras n As arquiteturas deverão ser do tipo cliente-servidor; n As ferramentas poderão estar distribuídas; n Os ambientes deverão ser extensíveis e baseados em componentes; n A integração por processo deverá ser mais comum; n Os sistemas incentivarão cada vez mais o desenvolvimento cooperativo de software, possivelmente desenvolvimento distribuído.