O Impacto Dos COTS No Processo de Engenharia de Requisitos

Fazer download em pdf ou txt
Fazer download em pdf ou txt
Você está na página 1de 12

O Impacto dos COTS no Processo de Engenharia de Requisitos

Fabrzia M. de Sousa1, Fernanda M. R. de Alencar2, Jaelson F. B. Castro1


UFPE - Universidade Federal de Pernambuco CCEN - Departamento de Informtica Av. Prof. Luiz Freire, s/n - Cidade Universitria Recife - PE - CEP: 50.740-540 E-mail: {fms, jbc}@di.ufpe.br UFPE - Universidade Federal de Pernambuco CT - Departamento de Eletrnica e Sistemas Rua Acadmico Hlio Ramos, s/n - Cidade Universitria Recife - PE - CEP: 50.740-530 E-mail: [email protected]
2 1

Resumo Surge uma nova forma de desenvolvimento de software baseada no uso de software prontos, j existentes no mercado, chamados componentes COTS (Commercial Off-The-Shelf). O sucesso dessa nova metodologia de desenvolvimento tem sido demonstrado pelo uso crescente em importantes organizaes, incluindo governo, indstria e comrcio. Reduo de custos e de prazos so os principais benefcios prometidos por esta nova tecnologia de desenvolvimento de software. Por outro lado, existem riscos associados ao novo processo. Nesse trabalho apresentado o processo de desenvolvimento de software baseado em COTS e suas implicaes na engenharia de requisitos. feita uma anlise das fases tradicionais do processo de engenharia de requisitos para adaptar as novas caractersticas de desenvolvimento introduzidas pelos componentes COTS.

Palavras chaves: Metodologia de Desenvolvimento, Requisitos, COTS


Abstract A new way for software development has been proposed. It is based on the use of existing software products, already available in the market, COTS (Commercial Off-The-Shelf) components. The success of this new development methodology has been demonstrated by the growing use of it in important organizations including government, industry and businesses. Reduction of costs and of time are the main benefits promised by this new software development technology. On the other hand, there are risks associated to this new process. In this work we present the software process based on COTS and its implication in the Requirement Engineering. Its done an analysis of the requirements engineering traditional phase for fit new features development insert by COTS components Key Words: Development Methodology, Requirements, COTS

1. Introduo

Na literatura disponvel, selecionamos as seguintes definies de COTS (Commercial Off-The-Shelf): Software de terceiros [Voas 1998b], Software comercial, desenvolvido sem nenhuma aplicao especfica em mente [McDermid 1998], Software comercial, com cdigo fonte no disponvel e com verses peridicas [Deifel 1999a] e Software que existe, est disponvel para o pblico e pode ser comprado ou licenciado [Oberndorf 1997]. O desenvolvimento usando componentes COTS considera que a maior parte da funcionalidade necessria de um sistema deva ser adquirida de terceiros enquanto o paradigma tradicional assume que praticamente toda a funcionalidade deve ser desenvolvida. A filosofia COTS se concentra na produo de componentes competitivos e fceis de integrar, muitas vezes usando componentes de outros fornecedores. A abordagem de produzir software baseado em componentes j usada com maturidade em setores industriais como telefonia, automotores e hardware. As principais motivaes para o incentivo a utilizao de COTS tem sido a proposta de reduo de custos de desenvolvimento dos produtos desejados e a proposta de reduo e cumprimento dos prazos de elaborao. Outras caractersticas que tambm colaboram para o aceite dessa nova tendncia de desenvolvimento de software so: (i) Dificuldade de desenvolvimento de software complexo e extenso, isto com mais de 300.000 linhas de cdigo; (ii) A disponibilidade de COTS alternativos de domnio especfico ou genrico; (iii) A maturidade dos componentes COTS; (iv) A interoperabilidade de componentes COTS para padres de mercado; e (v) O interesse conjunto da indstria, comrcio e governo. O aumento considervel no nmero de organizaes que adotam uso de componentes COTS no desenvolvimento de software fortalece a credibilidade na obteno de benefcios com essa nova forma de desenvolvimento. Governo, indstria, comrcio e instituies de pesquisa tm demonstrado interesse pelo tema. Na dcada de 90 importantes organizaes, como NASA e DoD (Departament of Defence dos Estados Unidos), declaram ter obtido sucesso com reduo de custos e prazos de desenvolvimento de software devido ao uso de componentes COTS [Oberndorf 1997]. Tanto que em 1994 foi estabelecido uma poltica de incentivo ao uso de COTS no DoD. Em 1998, McDermid chegou a declarar que dependendo da aplicao, COTS pode suportar 80% da funcionalidade com custo de apenas 2% do desenvolvimento tradicional [McDermid 1998]. A comunidade de pesquisa mostra seu envolvimento com componentes COTS atravs de eventos internacionais que destacam COTS como rea de interesse. Como exemplos de eventos com contribuies para a rea de COTS destacamos : Annual Reliability and Maintainability Symposium (1996), Fifth International Symposium on Assessment of Software Tools and Technologies (SAST97), International Conference on Software Engineering (ICSE97), COTS and Safety Critical Systems (1997), NRC-CNRC Software Engineer Seminar (1998), International Workshop on Requirements Engineering: Foundation for Software Quality (REFSQ98), REFSQ99 e ICSE99. Alm desse eventos, existem projetos relativos a COTS em universidades e centros de pesquisas conceituados. Existem dois tipos de sistemas baseados em COTS [Wallnau 1998]: (i) solues COTS que esto prontas para uso; e (ii) COTS integrados que so componentes que precisam ser adaptados e integrados em uma sistema maior. Os

desafios se encontram exatamente nesse segundo tipo de sistemas, ou seja em COTS integrados. O processo de desenvolvimento de software, considerando COTS integrados, possui dois enfoques com caractersticas e objetivos distintos : (i) desenvolvimento de sistemas baseados em componentes COTS, que produz um sistema maior a partir de componentes de mercado; e (ii) desenvolvimento de componentes COTS que gera para o mercado componentes confiveis e fceis de integrar. O processo de desenvolvimento nos dois casos so distintos e mudam tambm, com relao ao processo de desenvolvimento de software tradicional. Para o desenvolvimento baseado em COTS foi proposto um novo ciclo de vida definido pelas fases de avaliao, seleo, adaptao, juno e atualizao. Para o desenvolvimento de componentes COTS no existe um novo modelo proposto, o processo feito baseado no ciclo de vida tradicional e no novo ciclo de vida proposto para desenvolvimento de sistemas baseado em COTS. Nesse trabalho iremos investigar quais as implicaes do advento da tecnologia COTS nas etapas do processo da engenharia de requisitos, ressaltando as principais diferenas entre o processo de engenharia de requisitos tradicional e o novo processo utilizando COTS. Investigaremos requisitos tanto para o caso de desenvolvimento de software baseado em COTS, como requisitos para desenvolvimento de componentes a serem disponibilizados no mercado como COTS. Requisitos para sistemas que se baseiam no uso de componentes COTS necessitam se integrar com as fases propostas pelo novo ciclo de desenvolvimento (avaliao, seleo, adaptao, juno e atualizao). Requisitos para a construo de componentes COTS devem ser identificados a partir de diferentes contextos, como mercado, sistema e desenvolvedor. Na seo 2 apresentamos o processo tradicional de engenharia de software. Na seo 3 descrito o desenvolvimento baseado em COTS, incluindo caractersticas, vantagens, desvantagens e modelos propostos. Na seo 4 feita uma avaliao quanto s possveis alteraes no processo da engenharia de requisitos devido tecnologia COTS, sendo apresentadas na seo 5 algumas concluses.

2. Processo Tradicional da Engenharia de Requisitos


No processo tradicional de desenvolvimento de sistemas e, principalmente, de software, a engenharia de requisitos ocupa destacada posio. Representa a base para o desenvolvimento de qualquer tipo de produto, dela dependendo fundamentalmente a satisfao do produto s necessidades e desejos dos clientes contratantes, bem como sua qualidade. Sabe-se no haver um processo ideal para requisitos, contribuindo para tanto, a maturidade tcnica, a cultura organizacional e o domnio da aplicao, mas algumas atividades bsicas, bem definidas, do processo da engenharia de requisitos sempre existiro. Desta forma que a fase de definio dos requisitos e, como conseqncia, o documento de requisitos, representam o primeiro estgio do desenvolvimento, enquanto, que o sistema de software produto, propriamente, resultante dos estgios posteriores do desenvolvimento. No desenvolvimento tradicional [Castro 1995], como pode ser visto na figura 1, so distinguidas quatro atividades bsicas para o processo da engenharia de requisitos:

Especificao Aquisio Elicitao Anlise e Negociao

Validao

Documentao

Fig. 1 - Atividades do Processo Tradicional da Engenharia de Requisitos.

(i) Elicitao, onde procura-se levantar os requisitos existentes e pretendidos pela organizao, seja eles funcionais e no-funcionais; (ii) Anlise e Negociao de Requisitos, onde faz-se anlise sobre os requisitos levantados na fase anterior, descobrindo-se possveis conflitos e necessidades de elicitar outros requisitos, fatos estes negociados com todas as partes envolvidas; (iii) Documentao dos Requisitos, atravs de um documento que sirva como base para o desenvolvimento do sistema requerido; e (iv) Validao dos Requisitos, onde sero levantadas as possveis inconsistncias e determinada a completude ou no dos requisitos levantados. Nessas atividades, durante todo o ciclo de desenvolvimento a interao entre as partes, contratante e contratados, dever ser sempre ativa. Um bom processo de comunicao pr-requisito para que o desenvolvimento do produto desejado seja adequado s reais necessidades e anseios do contratante. Sabe-se que a depender do tamanho, da complexidade e da criticalidade do sistema a ser desenvolvido, os desafios a serem vencidos sero muitos. Todavia, da qualidade e da maturidade do processo da engenharia de requisitos depender o sucesso ou insucesso do sistema sob desenvolvimento.

3. Desenvolvimento de Software com uso de COTS


Um princpio bsico do desenvolvimento de software com uso de componentes COTS adquirir componentes para a maior parte da funcionalidade desejada, ao invs de desenvolver. O processo de desenvolvimento, de uma forma geral, corresponde seleo e integrao de componentes e est ilustrado na figura 2. O mercado produz componentes independentes, alguns deles so selecionados pela organizao e integrados para formar um sistema maior.

Fig. 2 : Desenvolvimento baseado em COTS. Softwares desenvolvidos com o uso de componentes COTS so ricos em funcionalidades, utilizam tecnologia moderna, esto disponveis para uso e por custos de aquisio previsveis. Entretanto, existem desvantagens como taxa de licena de uso, dependncia do desenvolvedor, falta de controle sobre novas verses (upgrades), integrao no trivial e consumo de recursos computacionais (como memria e disco) por funcionalidades disponveis, mas desnecessrias para alguns usurios. Software desenvolvido de forma tradicional, com o desenvolvimento de toda a funcionalidade desejada, apesar de no ter dependncia de terceiros, permitindo controle de desenvolvimento e controle de segurana, so historicamente caros, de desenvolvimento imprevisvel e de difcil portabilidade. 3.1. Modelos Propostos Alguns modelos de ciclo de vida de sistemas desenvolvidos com uso de componentes COTS foram propostos. Entre eles, apresentados em 1997, temos o modelo COTS Intensive System (CIS) e o COTS Integreted System Development (CISD). O modelo CIS, apresentado na figura 3, descreve cinco fases no ciclo de vida de desenvolvimento [Wallnau 1998]: (i) Mercado de COTS que corresponde construo de componentes independentes por diversos fabricantes do mercado; (ii) Qualificao que representa a seleo de componentes com funcionalidade e capacidade de integrao apropriadas para as necessidades da organizao; (iii) Adaptao que corresponde ao ajuste de componentes baseados em parmetros da organizao; (iv) Integrao que representa a juno de componentes formando o sistema desejado pela organizao; e (v) Atualizao que trata da substituio de um componentes do sistema integrado ou mesmo substituio de verso.

Mercado de COTS

Qualificao

Adaptao

Integrao

Atualizao

Fig. 3 : Modelo CIS (COTS Intensive System).

O modelo CISD, apresenta na figura 4.a sua interface externa constituda por COTS disponveis no mercado e definio de requisitos. Na figura 4.b so apresentadas as fases do ciclo de vida de desenvolvimento [Tran 1997b]: (i) Identificao que enumera componentes disponveis no mercado como candidatos a serem selecionados; (ii) Avaliao que faz um estudo relativo da funcionalidade e capacidade de integrao dos componentes, identificando e selecionando aqueles que sejam apropriados para as necessidades da organizao; e (iii) Integrao que faz a integrao de vrios componentes, incluindo ajustes necessrios.

Requisitos

Produtos COTS

Modelo CISD

Produtos Integrados

Fig. 4.a) Interfaces externas do modelo CISD

Requisitos

Produto COTS

Identificao Avaliao Integrao Sistema Integrado

Fig. 4.b) Fases do modelo CISD.

3.2. Aspectos Relevantes ao Desenvolvimento COTS Dentre os principais aspectos associados ao desenvolvimento baseado em COTS, destacam-se: (i) os riscos do processo de avaliao e integrao; (ii) a garantia de confiabilidade de todo o sistema; e (iii) o custo final do sistema. A avaliao e seleo de componentes verifica a funcionalidade e a capacidade de integrao desejada. Precisa ser feita de forma rpida, usando as informaes disponveis, que podem ser insatisfatrias, e com grau de rigor apropriado para a aplicao em questo. um processo de escolha subjetivo e sujeito a falhas porque difcil examinar, em um prazo curto, componentes concorrentes e aparentemente semelhantes. Para eliminar os risco do processo de avaliao e seleo, pode ser usado o mtodo de certificao [Voas 1997a][Voas 1998c], que guia o processo de avaliao atravs de testes de caixa-preta, injeo de falhas e testes feitos em ambientes operacionais. Os riscos relativos ao processo de integrao so devido a falhas que podem ocorrer com as entradas ou sadas dos componentes, muitas vezes devido a defeitos (bugs) dos prprios componentes, comprometendo a ligao entre dois componentes e quebrando, consequentemente, a integrao geral do sistema. Para eliminar risco do processo de integrao foram propostas estratgias como, capas de proteo (wraper) [Tran 1997a][Tran 1997b][Voas 1998c], anlise atenuao de riscos [Voas 1997b][Zhong 1998][Kropp 1998] e localizao de falhas [Hissam 1997][Voas 1998a]. O problema com a confiabilidade de todo o sistema conseqncia direta de defeitos (bugs) e limitaes dos componentes. Um sistema que usa componentes COTS herda seus defeitos e limitaes, diminuindo sua confiabilidade. Pode-se dizer tambm que a confiabilidade e segurana de um sistema depende da confiabilidade e segurana de cada componente que use. Uma falsa idia que se tem do desenvolvimento com COTS que o custo do processo apenas o custo de aquisio do componente. Uma avaliao de custos realstica para esse tipo de desenvolvimento descrita no modelo de custos COCOTS (Constructive COTS) [COCOTS] uma variao do modelo de custos COCOMO [Boehm 1981]. O COCOTS classifica a utilizao de componentes pela organizao em ferramenta, infra-estrutura e componentes. Para cada categoria de uso apresenta frmulas de clculo e tabelas de referncia para serem calculados os seguintes custos: avaliao, ajuste, integrao e incorporao de novas verses.

4. Alteraes no Processo de Requisitos


Podemos dizer que no desenvolvimento tradicional a fase de definio dos requisitos crtica e essencial a construo de qualquer produto. Pelo que analisamos com a tecnologia COTS de desenvolvimento, esta fase tambm necessria e importante. O que acontece que muitos pontos que antes precisavam ser bem definidos numa fase inicial, no so necessrios nos primeiros estgios do desenvolvimento, uma vez que j dispomos de componentes acabados. Alm da no existncia de um relacionamento mais aprofundado entre as organizaes

desenvolvedoras, nem to pouco de uma nica autoridade para o projeto. Essa a viso que se tem quando se est trabalhando com desenvolvimento de sistemas baseado em COTS. Os requisitos e a arquitetura so definidas de forma concorrente [Vigder 1998]. Quando estamos desenvolvendo os componentes COTS diferente. Tomando-se por base a nova tecnologia COTS, apresentamos a seguir uma anlise a respeito de como ficam as atividades do processo da engenharia de requisitos, considerando o desenvolvimento de sistemas baseados em COTS e o desenvolvimento de componentes COTS. 4.1. Requisitos para Desenvolvimento de Softwares Baseados em COTS Com base no modelo CIS, apresentado anteriormente na figura 3, podemos inicialmente dizer que a determinao dos requisitos feita de maneira exgena ao processo de desenvolvimento. Para o incio do desenvolvimento, parte-se de uma descrio abstrata dos requisitos a fim que se tenha a almejada funcionalidade. Explicitamente, no existe no modelo CIS, qualquer fase do desenvolvimento voltada diretamente definio dos requisitos do sistema requerido. Entretanto, constatamos neste modelo, atividades do processo da engenharia de requisitos tradicional: (i) na fase qualificao ocorre a atividade de anlise dos requisitos, pois preciso garantir que a funcionalidade dos componentes COTS selecionados no mercado, satisfaam aos requisitos mnimos elicitados antes do incio do processo CIS; (ii) na fase de adaptao temos a atividade de elicitao, porque necessrio levantar requisitos que no foram enquadrados nos componentes qualificados; e por fim, (iii) na fase integrao, existe a atividade de validao, considerando que os ajustes feitos na fase adaptao, precisam ser consolidadas. O modelo CISD, entretanto, mais detalhado no tocante a requisitos, mesmo considerando requisitos como processo externo. Esse modelo apresentado anteriormente nas figuras 4.a e 4.b mostra que a definio de requisitos participa de forma diferente nas fases do ciclo de vida do modelo. Identificao, avaliao e integrao so as fases que compem esse modelo e para cada uma dela a definio de requisitos vista de forma diferente. A fase de identificao seleciona componentes COTS para serem posteriormente avaliados. Nessa fase necessrio se fazer uma anlise do documento de requisitos visando particionar os requisitos funcionais em domnios de servios, facilitando assim a identificao de componentes, que passa a ser feita por domnio. A fase de avaliao compara, em ambiente operacional (por prototipao), a funcionalidade e capacidade de integrao dos componentes previamente selecionados. Nessa fase feito um particionamento dos requisitos, gerando-se a partir dessa diviso estgios de avaliao, como : (i) avaliao da funcionalidade que verifica, por testes, se o componente satisfaz funcionalidade exigida; (ii) avaliao da interoperabilidade para se certificar da capacidade de integrao dos componentes; e (iii) avaliao de desempenho para avaliar se os requisitos no funcionais de desempenho foram atendidos depois da integrao (por prottipo) de diferentes componentes. A fase de integrao corresponde ao desenvolvimento e teste de adaptadores para formar o sistema integrado final. Nessa fase a participao dos requisitos diz respeito certificao de atendimento dos requisitos no funcionais.

Comparando esse processo de desenvolvimento com o processo tradicional de requisitos podemos dizer que tarefas tpicas de requisitos esto distribudas no novo ciclo de desenvolvimento. Na fase de identificao do modelo CISD, a classificao dos requisitos por domnio um meio de atribuir prioridades, tarefa tpica da fase de negociao de requisitos. A fase de avaliao do CISD faz uma validao parcial de requisitos ao testar requisitos funcionais e no funcionais do sistema. A fase de integrao do CISD uma validao final de requisitos, com destaque para os requisitos no funcionais. Outro aspecto relevante de requisitos para sistemas baseados em COTS o nvel de detalhamento das fases de elicitao, especificao e validao de requisitos. No h necessidade de elicitar e especificar com muitos detalhes, j que os componentes fornecem funcionalidades prontas, entretanto validao de requisitos mais detalhada, devido importncia dos testes de integrao. 4.2 Requisitos para Desenvolvimento de Componentes COTS Uma importante caracterstica dos componentes COTS que eles so desenvolvidos para um mercado inteiro, ao invs de um nico cliente. Isso afeta de forma significativa o processo de desenvolvimento, em todas as fases onde ocorra interao entre desenvolvedor e cliente. Outros fatores importantes relativos a componentes COTS que eles so distribudos em verses e, normalmente, fazem parte de um sistema produto maior. Diante dessas novas caractersticas, foi apresentado no REFSQ98 uma viso diferente para as fases tradicionais do processo de Engenharia de Requisitos [Deifel 1998]. Considerando a Engenharia de Requisitos composta pelas fases elicitao, negociao, documentao e validao, temos as seguintes mudanas relativa a requisitos para desenvolvimento de componentes COTS : No processo tradicional de requisitos, a fase de elicitao feita por tcnicas que se baseiam na premissa de existncia de comunicao entre desenvolvedor e cliente, tais como, entrevistas, questionrios, anlise de protocolos, participao ativa dos usurios, etc. Entretanto, para componentes COTS, como no existe comunicao entre desenvolvedor e Cliente, a elicitao passa a ser feita dividida por contexto e buscando informaes em canais de comunicao. Contextos so divises de requisitos, como por exemplo, requisitos do mercado, do sistema e do desenvolvedor ou ainda requisitos do domnio da aplicao, do contexto de utilizao e do sistema bsico [Deifel 1999b]. Canais de comunicao so locais possveis de conter informaes relativas ao componente que ser construdo, tais como, workshops, vendedores, hotlines, suporte, manuteno, outros softwares e verses anteriores [Deifel 1998]. A fase de negociao, que consolida os requisitos, diferencia-se pela inexistncia de um usurio que colabore no processo de checagem da consistncia dos requisitos e pelo diferente papel da priorizao. As fontes de informaes para essa fase passam a ser os canais de comunicao. A priorizao, antes feita sob todo o conjunto de requisitos, passa a ser feita pela distribuio de requisitos sobre verses, liberando-se para as primeiras verses os requisitos mais importantes. A distribuio dos requisitos por verso adiciona ao processo um fator de dificuldade relativo

compatibilidade de verses, que precisa ser cuidadosamente elaborada. Em [Deifel 1999a] apresentado um modelo de requisitos para planejamento de verses. A fase de documentao, que traduz requisitos do cliente em especificaes tcnicas, antes feita para todos os requisitos do sistema, passa a ser feita apenas para os requisitos de uma verso. A distribuio de requisitos por verso feita na fase de negociao e coloca os requisitos mais importantes nas primeiras verses. A documentao por verso, apesar de ser menor que a documentao para todo o sistema, precisa garantir compatibilidade com verses passadas e futuras, constituindo-se assim, em uma nova obrigao dessa fase. A fase de validao tm como propsito garantir que o software desenvolvido esteja correto, verificando se a funcionalidade solicitada foi fornecida e se est implementada corretamente. No processo tradicional de requisitos a checagem entre a funcionalidade desejada e a funcionalidade fornecida feita pela apresentao do produto final ao cliente, entretanto para COTS, como no existem clientes, essa confirmao s obtida pelo sucesso de vendas do componente. A validao referente implementao correta das funcionalidades feita por testes, tanto no processo tradicional de requisitos como nos requisitos para COTS.

5. Concluso
A tecnologia COTS fornece novos direcionamentos ao processo de desenvolvimento de software. Desenvolver software baseado no uso e integrao de COTS e desenvolver componentes COTS confiveis e fceis de integrar so enfoques diferentes de desenvolvimento de software utilizando a tecnologia COTS. Para representar o ciclo de vida do desenvolvimento baseado em COTS forma propostos os modelos CIS e CISD. O CIS definido pelas fases produo de mercado COTS, qualificao, adaptao, integrao e atualizao e CISD definido pelas fases de identificao, avaliao e integrao. Apesar de dividir e nomear o ciclo de vida em fases diferentes, ambos os modelos so comuns ao definir as tarefas de seleo e integrao de componentes no processo de desenvolvimento. Para o desenvolvimento de componentes COTS entretanto, no temos um modelo de ciclo de vida especfico. O impacto dos componentes COTS no engenharia de requisitos relevante. Nesse novo tipo de desenvolvimento o processo de requisitos deve ser feito considerando os novos objetivo do desenvolvimento, tendo assim um nova viso das fases tradicionais de requisitos. Quando se elabora requisitos para integrar COTS, diminui-se o nvel de detalhamento necessrio nas fases tradicionais de elicitao e especificao, entretanto aumenta-se o detalhamento da fase de validao, gerado devido necessidade de integrao de componentes. Quando se produz requisitos para desenvolver COTS, devido a inexistncia de interao com o cliente, as fases de requisitos so elaboradas a partir de contexto e canais de comunicao. Outra mudana na definio de requisitos para COTS a determinao de prioridades, que coloca os requisitos mais importantes nas primeiras verses e deve suportar compatibilidade de verses. A contribuio da Engenharia de Requisitos para o desenvolvimento de softwares que utilizam COTS ou para o desenvolvimento de componentes COTS poderia ser maior se o documento de requisitos fosse elaborado com o propsito de

facilitar os principais desafios desse tipo de desenvolvimento, que so a avaliao e a integrao. Isso representa a nossa sugesto de trabalhos futuros.

Referncias
Boehm, Barry W. Software Engineering Economics. Prentice Hall. 1981. Castro, J. F. Introduo a Engenharia de Requisitos. XV Congresso da Sociedade Brasileira de Computao, JAI 95 XIV Jornada de Atualizao em Informtica. Canela, RS Brasil. 1995. COCOTS Constructive COTS Model. Center for Software Engineering, University of Southers California, USA. (http://sunset.usc.edu/COCOTS/cocots.html) Deifel, Bernhard. Requirements Engineering for Complex COTS. Positional Paper. REFSQ98. Deifel, Bernhard. A Model for version Planning of COTS. Extended Abstract. SCE99. Deifel, Bernhard. Supporting Reuse and Flexibility in COTS Variation Development. REFSQ99. Hissam, Scott. Case Study: Correcting System Failure in a COTS Information Systems. Software Engineering Institute, Carnegie Mellon University, USA. September, 1997. Kropp, Nathan P.; Koopman, Philip J. and Seiwiorek, Daniel P. Automated Robustness Testing of Off-the-Shelf Software Components. In Proceeding of the Fault Tolerant Computing Symposium. Germany. 1998. McDermid, John (Interview). The Cost of COTS. IEEE Computer Society. June, 1998. Vol 31. Number 6. Pages 4652. Oberndorf, Tricia. COTS and Open Systems an Overview. Software Engineering Institute, Carnegie Mellon University, USA. January, 1997.

Tran, Vu and Liu, Dar-Biau. A Procurement-centric Model for Engineering Component-based Software Systems. Proceedings of the Fifth International Symposium on Assessment of Software Tools - SAST97. Jun, 1997. Tran, Vu and Liu, Dar-Biau. A Risk-Mitigating Model for The Development of Reliable and Maintainable Large-Scale COTS Integrated Software Systems . Proceedings of the 1997 Annual Reliability and Maintainability Symposium The International Symposium on Product Quality and Integrity. Jan, 1997. Vigder, Mark. An Architecture for COTS Based Software Systems, National Research Council Canada, Institute for Information Technology, Ottawa, Ontario, Canada, Prepared for Defense Research Development Branch. Nov., 1998. Voas, Jeffrey M. Certifying Off-the-Shelfs Software Componentes. IEEE Computer Society. June, 1998. Vol 31. Number 6. Pages 5359. Voas, Jeffrey M. The Challenges of Using COTS Software in Component-Based Development. IEEE Computer Society. June, 1998. Vol 31. Number 6. Pages 44-45. Voas, Jeffrey. A Defensive Approach to Certifying COTS Software. Technical Report.

Reliable Software Technologies Corporation, Sterling VA USA. August, 1997. Voas, Jeffrey. Defensive Approaches to Testing Systems that Contain COTS and Third-Party Functionality. Reliable Software Technologies Corporation, Sterling VA USA. June, 1998. Voas, Jeffrey. Mitigating the Potential for Damage Caused by COTS and Third-party Software Failures. Reliable Software Technologies Corporation, Sterling VA USA. August, 1997. Wallnau, Kurt C.; Carney, David and Pollak, Bill. How COTS Software Affects the Design of COTS-Intensive Systems. Software Engineering Institute, Carnegie Mellon University, USA. June, 1998. Zhong, Qun and Nigel, Edward. Security Control for COTS Components. IEEE Computer Society. June, 1998. Vol 31. Number 6. Pages 44 73.

Você também pode gostar