UMA ABORDAGEM PARA INSPEO DE DOCUMENTOS ARQUITETURAIS BASEADA EM CHECKLIST Rafael Ferreira Barcelos

DISSERTAO SUBMETIDA AO CORPO DOCENTE DA COORDENAO DOS PROGRAMAS DE PS-GRADUAO DE ENGENHARIA DA UNIVERSIDADE FEDERAL DO RIO DE JANEIRO COMO PARTE DOS REQUISITOS NECESSRIOS PARA A OBTENO DO GRAU DE MESTRE EM CINCIAS EM ENGENHARIA DE SISTEMAS E COMPUTAO.

Aprovada por:

________________________________________________ Prof. Guilherme Horta Travassos, D.Sc. ________________________________________________ Profa. Claudia Maria Lima Werner, D.Sc. ________________________________________________ Prof. Julio Cesar Sampaio do Prado Leite, Ph.D.

RIO DE JANEIRO, RJ BRASIL ABRIL DE 2006

BARCELOS, RAFAEL FERREIRA Uma abordagem para inspeo de documentos arquiteturais baseada em checklist [Rio de Janeiro] 2006 VIII, 175 p., 29,7 cm (COPPE/UFRJ, M.Sc., Engenharia de Sistemas e Computao, 2006) Dissertao Universidade Federal do Rio de Janeiro, COPPE 1. Arquitetura de Software 2. Inspeo de Software I. COPPE/UFRJ II. Ttulo (srie)

ii

 minha famlia.

iii

Agradecimentos
Aos meus pais, por me apoiarem integralmente na realizao deste trabalho. Michelle, por compreender a minha ausncia de dois anos, pelo amor e carinho. Sua ateno e disponibilidade para as centenas de horas falando pelo telefone, me dando fora e escutando minhas inquietudes, foram fundamentais neste perodo. Ao professor Guilherme Travassos, por apostar em ns e dar oportunidade de mostrar do que somos capazes. Agradeo tambm pela orientao e pela pacincia. Aos professores Cludia Werner e Jlio Leite, por aceitarem participar de minha banca. Ao companheiro de quarto Arilo pelo apoio e por agentar dividir o grande apartamento por esses dois anos. Ao Beto e Jobson por terem auxiliado na realizao do estudo que foi realizado no contexto dessa pesquisa. Aos companheiros de COPPE Aline, Ana Cndida, Gladys, Gleison, Kali, Luiz Gustavo, Marco Antnio, Mariano, Murta, Natanael, Paula, Paulo Srgio, Rodrigo, Svio, Smulo, Tayana e Wladmir. A FAPEAM, pelo apoio financeiro. A BENQ/SIEMENS-AM pela confiana e pela participao nos estudos realizados nessa pesquisa. Um agradecimento especial para Andrey Patitucci e Rafael Kitauchi por possibilitarem a realizao desse acordo.

iv

Resumo da Dissertao apresentada COPPE/UFRJ como parte dos requisitos necessrios para a obteno do grau de Mestre em Cincias (M.Sc.)

UMA ABORDAGEM PARA INSPEO DE DOCUMENTOS ARQUITETURAIS BASEADA EM CHECKLIST Rafael Ferreira Barcelos Abril / 2006 Orientador: Guilherme Horta Travassos Programa: Engenharia de Sistemas e Computao A arquitetura de um software, representada atravs do documento arquitetural, de grande importncia para os stakeholders por ser utilizada em diversos momentos no processo de desenvolvimento do software. Portanto, a sua reviso se torna uma atividade relevante para o sucesso do projeto e para a melhoria da qualidade do software. Existem diversas abordagens de avaliao descritas na literatura que objetivam avaliar esse artefato, mas elas apresentam limitaes que dificultam a sua aplicao, principalmente em meio industrial. Com o objetivo principal de minimizar as limitaes presentes nas abordagens de avaliao, esta dissertao apresenta uma abordagem para inspeo de documentos arquiteturais baseada em checklist chamada ArqCheck. Devido procura cada vez maior por parte das empresas de software brasileiras por abordagens que permitam tanto a melhoria de seus processos quanto a de seus produtos, optamos por avaliar ArqCheck atravs de uma metodologia experimental que visa a transferncia de tecnologias de software para a indstria. Com isso, uma reviso sistemtica e dois estudos experimentais foram realizados e os resultados preliminares indicam a viabilidade, a eficcia e o custo / eficincia da abordagem na identificao de defeitos em documentos arquiteturais.

Abstract of Dissertation presented to COPPE/UFRJ as a partial fulfillment of the requirements for the degree of Master of Science (M.Sc.) AN APPROACH TO INSPECT ARCHITECTURAL DOCUMENTS BASED ON CHECKLIST Rafael Ferreira Barcelos April / 2006 Advisor: Guilherme Horta Travassos Department: Computer and Systems Engineering Software architecture, usually represented by an architectural document, is extremely important to stakeholders since it is used in several moments throughout the software development process. Therefore, due to its importance, the reviewing of architectural documents becomes a fundamental activity for the success of the software project and for the software quality improvement. There are several architectural evaluation approaches described in the literature, however they have some limitations related to their use that make difficult to apply them in industrial environments. Aiming at to reduce such limitations, this dissertation describes a checklist based approach to inspect architectural documents called ArqCheck. Due to the Brazilian software organizations needs for approaches concerned with process and product quality improvements, we decided to evaluate ArqCheck using an experimental methodology that supports technological transference of software technologies to software organizations. Based on this, a systematic review and two experimental studies were conducted and preliminary results indicated the feasibility, effectiveness and cost/efficiency of this approach to detect defects on software architectural documents.

vi

Sumrio
Captulo 1 Introduo ................................................................................................. 1 1.1 Motivao ............................................................................................................ 1 1.2 Objetivo do Trabalho........................................................................................... 3 1.3 Metodologia de Trabalho..................................................................................... 4 1.4 Organizao deste Trabalho ................................................................................ 5 Captulo 2 Arquitetura de Software .......................................................................... 8 2.1 Introduo............................................................................................................ 8 2.2 Definio dos conceitos relacionados arquitetura de software....................... 10 2.3 Papel da arquitetura em um processo de desenvolvimento de software e os benefcios de sua avaliao ........................................................................................ 11 2.4 Processo de especificao arquitetural .............................................................. 13 2.5 Concluso .......................................................................................................... 21 Captulo 3 Abordagens de avaliao arquitetural.................................................. 22 3.1 Introduo.......................................................................................................... 22 3.2 Reviso Sistemtica........................................................................................... 23 3.3 Conduzindo uma reviso sistemtica para identificar mtodos de avaliao arquitetural.................................................................................................................. 25 3.4 Abordagens de avaliao arquitetural identificadas .......................................... 28 3.5 Anlise das abordagens ..................................................................................... 56 3.6 Concluso .......................................................................................................... 60 Captulo 4 Inspeo de documentos arquiteturais ................................................. 63 4.1 Introduo.......................................................................................................... 63 4.2 Inspecionando documentos arquiteturais........................................................... 64 4.3 ArqCheck: uma abordagem para inspeo arquitetural..................................... 66 4.4 Concluso .......................................................................................................... 87 Captulo 5 Avaliando a abordagem proposta ......................................................... 89 5.1 Introduo.......................................................................................................... 89 5.2 Conceitos bsicos de Experimentao aplicada engenharia de software ....... 90 5.3 Metodologia experimental utilizada .................................................................. 92 5.4 Estudo de viabilidade ........................................................................................ 93 5.5 Estudo de observao ...................................................................................... 104 5.6 Concluso ........................................................................................................ 121 vii

Captulo 6 Concluses ............................................................................................. 123 6.1 Consideraes finais ........................................................................................ 123 6.2 Contribuies................................................................................................... 124 6.3 Limitaes ....................................................................................................... 125 6.4 Trabalhos Futuros ............................................................................................ 126 Referncias Bibliogrficas ......................................................................................... 128 Apndice A Protocolo de Reviso Sistemtica...................................................... 139 Apndice B Checklist para inspeo arquitetural................................................. 141 Apndice C Relatrio de discrepncias ................................................................. 151 Apndice D Plano do Experimento ........................................................................ 152 Apndice E Questionrio de Avaliao Ps-Experimento................................... 168 Anexo A Notao para Modelar Processo de Software........................................ 170 Anexo B Tticas Arquiteturais............................................................................... 172

viii

Captulo 1 Introduo
Neste captulo so apresentadas as motivaes para a realizao deste trabalho, alm de seus objetivos e a forma como esta dissertao est organizada.

1.1 Motivao
Desde a dcada de 90, com o aumento da complexidade e tamanho dos sistemas de software, a definio dos algoritmos e das estruturas de dados no so mais as maiores preocupaes do projetista durante os primeiros estgios do processo de desenvolvimento de um software (GARLAN e SHAW, 1993). Em conseqncia, vrias tarefas do processo de desenvolvimento deixaram de ser triviais como, por exemplo, a definio da estrutura da soluo computacional a ser construda. Uma forma encontrada para lidar com essa complexidade cada vez mais crescente foi o uso de abstraes durante a construo desses sistemas. Visto que a arquitetura de software auxilia na definio e visualizao da soluo computacional em um elevado nvel de abstrao (GARLAN e SHAW, 1993), ela passou a ser usada como ferramenta na definio da estrutura do software a ser construdo. A arquitetura de um software considerada o primeiro conjunto de decises de projeto e possui um grande papel como ponte entre os requisitos e a implementao. Essa estrutura utilizada principalmente como ferramenta para comunicar a soluo projetada aos diversos stakeholders1 que participam do processo de desenvolvimento (GARLAN, 2000). Para que essa comunicao seja possvel, essa estrutura deve ser descrita atravs de uma representao, conhecida como documento arquitetural. Um documento arquitetural portanto o documento que descreve a arquitetura de um software. Para isso, de acordo com as recomendaes da IEEE 1471 (IEEE, 2000), esse documento deve principalmente identificar os elementos arquiteturais e seus relacionamentos e tambm descrever o papel de cada um desses elementos dentro da soluo representada. Esse documento de grande importncia para os stakeholders visto que ele contm informaes que so utilizadas por diversos tipos de stakeholders e por ser utilizado em diversos momentos no processo de desenvolvimento do software.

Stakeholder: grupo ou indivduo envolvido, de forma direta ou indireta, em um projeto de software ou que possue algum interesse no resultado obtido por esse projeto.

Portanto, devido essa importncia, a sua reviso se torna uma atividade relevante para o sucesso do projeto e para a melhoria da qualidade do software. Esta afirmao fortalecida se for considerado que (1) a avaliao desse artefato dificulta a propagao de seus defeitos para os demais artefatos, como diagramas de projeto e cdigo fonte, e (2) o custo de correo desses defeitos bem menor se for realizada durante os primeiros estgios do projeto (BOEHM, 1981; BOEHM e BASILI, 2001). Contudo, como avaliar se o documento arquitetural descreve uma arquitetura que atenda aos requisitos especificados? O incio das pesquisas que resultou na abordagem para avaliao arquitetural proposta ocorreu no contexto do projeto eSEE. Esse projeto tem como objetivo criar um ambiente que auxilie no planejamento e conduo de estudos experimentais em Engenharia de Software (MIAN et al., 2005). A nossa participao nesse projeto ocorreu principalmente durante a especificao da arquitetura do ambiente (NETO et al., 2004). Os envolvidos nesse projeto identificaram a necessidade em definir a arquitetura desse ambiente devido sua complexidade e ao fato da equipe do projeto possuir uma alta rotatividade, por ser formada principalmente por alunos de ps-graduao. Com isso, o documento arquitetural do ambiente eSEE foi criado com o objetivo de documentar em um elevado nvel de abstrao a soluo a ser desenvolvida, facilitando o seu entendimento. Aps a definio da arquitetura desse ambiente, optou-se por avali-la em relao aos requisitos especificados devido aos ganhos que poderiam ser obtidos com os resultados dessa avaliao nesse estgio do processo de desenvolvimento. Com isso, iniciamos uma busca pelas abordagens de avaliao arquitetural descritas na literatura. Para essa busca, definimos algumas caractersticas que consideramos importantes e que deveriam estar presentes na abordagem selecionada a ser utilizada durante a avaliao da arquitetura do eSEE: Genrica e Adaptvel: para que ela possa ser aplicada na avaliao de diferentes tipos de documentos arquiteturais, ficando independente, portanto da abordagem utilizada para especific-los; Simples: para que no seja necessria a execuo de elaboradas atividades para sua aplicao, a necessidade de tipos de conhecimento especficos ou a alocao de grandes quantidades de recursos; Extensvel: para que seja facilmente modificvel e permita avaliar, alm dos conceitos inicialmente determinados, conceitos especficos ao contexto que esto sendo aplicados.

Essas caractersticas foram definidas com base em condies normalmente presentes em ambientes industriais e que podem influenciar na adoo de uma determinada tecnologia dentro desse contexto (SHULL et al., 2001). Sendo assim, aps a realizao dessa busca atravs de um estudo secundrio (reviso sistemtica), foram identificadas diversas abordagens de avaliao descritas na literatura que objetivam avaliar principalmente se a arquitetura projetada atende aos requisitos especificados para o produto (BARCELOS e TRAVASSOS, 2006b). Contudo, nenhuma abordagem atende s caractersticas que definimos e apresentam limitaes por terem sido criadas principalmente em contextos com grande disponibilidade de recursos que dificultam a sua aplicao, principalmente em meio industrial. Com a expectativa de minimizar as limitaes presentes nas abordagens de avaliao e levando em considerao os resultados que se tem obtido com a aplicao de tcnicas de inspeo na reviso de artefatos de software (SHULL et al., 2000; CONRADI et al., 2003), esta dissertao apresenta ArqCheck, uma abordagem para inspeo de documentos arquiteturais baseada em checklist. Ao longo deste trabalho, arquitetura de software ser chamada por diversas vezes simplesmente de arquitetura, para simplificar a escrita e o entendimento do trabalho. O mesmo ir ocorrer com o termo processo de desenvolvimento de software, que ser tratado somente como processo de desenvolvimento.

1.2 Objetivo do Trabalho

O objetivo desse trabalho elaborar uma abordagem de avaliao que permita a inspeo de um documento arquitetural, que foi chamada de ArqCheck. Com isso, a hiptese de pesquisa definida que atravs de uma abordagem para inspeo baseada em checklist que avalie um documento arquitetural seja possvel identificar defeitos arquiteturais relacionados ao atendimento dos requisitos do software. O checklist que compe ArqCheck foi criado com base em conhecimentos obtidos dos principais conceitos e tcnicas de projeto arquitetural (SHAW, 1995; BOSCH e MOLIN, 1999; BASS et al., 2003) e das principais abordagens de documentao arquitetural descritas na literatura (IEEE, 2000; CLEMENTS et al., 2004). Existe atualmente um aumento constante da procura por parte das empresas de software brasileiras por abordagens que permitam tanto a melhoria de seus processos quanto a de seus produtos (MCT/SEPIN, 2005). Devido essa procura, optamos por avaliar a abordagem para inspeo proposta atravs de uma metodologia experimental que objetiva analisar e evoluir novas tecnologias visando a sua transferncia para um contexto industrial.

Essa metodologia, definida em (SHULL et al., 2001), define uma srie de estudos experimentais que devem ser executados para que a tecnologia avaliada adquira maturidade e tenha seus riscos de implantao em um contexto industrial minimizados. Seguindo essa metodologia, dois dos estudos por ela definidos foram realizados. Esses estudos buscaram avaliar principalmente a viabilidade, a eficcia e o custo/eficincia da abordagem proposta. No contexto dessa dissertao, definimos eficcia como a quantidade de defeitos encontrados em relao ao nmero de discrepncias identificadas pelo inspetor. A caracterizao da eficcia de ArqCheck permite fornecer informaes em relao ao esforo gasto pelo inspetor que est realmente permitindo a melhoria da qualidade do documento arquitetural. Em relao ao conceito de custo/eficincia, ele consiste na caracterizao de quantos defeitos so encontrados por unidade de tempo de inspeo. Atravs dessa mtrica possvel caracterizar o auxlio fornecido pela abordagem na identificao de defeitos. Atravs desses estudos, ArqCheck foi avaliada em relao a sua aplicao para revisar tanto documentos arquiteturais gerados em um contexto acadmico quanto em documentos gerados em um contexto industrial. Os resultados desses estudos permitiram que evolues fossem feitas na abordagem, e que no futuro a transferncia dessa tecnologia para a indstria seja, de certa maneira, simplificada.

1.3 Metodologia de Trabalho

Para a realizao desse trabalho, optamos por nos basear em uma metodologia de pesquisa que utiliza estudos experimentais para (a) obter evidncias e conhecimento em relao rea de Arquitetura de Software e (b) avaliar a abordagem para inspeo (MAFRA e TRAVASSOS, 2006) Portanto, esse trabalho seguiu passos especficos que permitiram que os objetivos fossem atingidos (Figura 1.1): Passo 1: Anlise dos conceitos relacionados construo e documentao de arquiteturas. Para se entender como um artefato deve ser avaliado essencial que se entenda em um primeiro momento como ele construdo. Sendo assim, procuramos analisar nesse passo o processo de criao desse artefato, o papel dos requisitos nesse processo e que tipo de informao deve estar presente em um documento arquitetural. Para isso, foi realizada uma anlise das tcnicas de construo e documentao arquitetural com o objetivo de identificar os principais

conceitos por eles utilizados e que poderiam ser utilizados como base para a definio de uma abordagem de avaliao. Passo 2: Identificao das abordagens de avaliao arquitetural existentes. Aps identificar como a arquitetura de um software construda, esse segundo passo foi realizado com o objetivo de buscar indcios que permitam identificar e caracterizar as abordagens de avaliao arquitetural existentes. Para isso, uma reviso sistemtica (KITCHENHAM, 2004; BIOLCHINI et al., 2005) foi planejada e executada, e a partir dos resultados obtidos uma caracterizao dessas abordagens foi realizada. Passo 3: Definio e construo da abordagem para inspeo. A caracterizao das abordagens de avaliao identificadas permitiu a observao de caractersticas positivas e algumas limitaes. A compreenso desses mtodos e a anlise de suas caractersticas serviram como base para a definio e construo de uma abordagem para inspeo que foi chamada de ArqCheck. Passo 4: Realizao de estudos de avaliao. Aps a criao de ArqCheck, estudos primrios foram planejados e executados para avaliar a sua viabilidade, eficcia e custo/eficincia em relao reviso de documentos arquiteturais.

Figura 1.1- Metodologia de trabalho adotada

1.4 Organizao deste Trabalho

Alm desta introduo, este trabalho composto por outros cinco captulos, quatro apndices e quatro anexos. No Captulo 2, intitulado Arquitetura de Software, so descritos os conceitos bsicos relacionados ao projeto, documentao e avaliao arquitetural. Esse captulo possui como objetivo mostrar o papel e a importncia da arquitetura dentro do processo de desenvolvimento de software e tambm que tipo de conceito, informao e conhecimento so utilizados pelo arquiteto para transpor o gap entre os requisitos

especificados para o produto e a soluo computacional que ser implementada para atender a esses requisitos. No Captulo 3, intitulado Abordagens de Avaliao Arquitetural, so descritos a reviso sistemtica e os resultados obtidos. Nesse captulo, as abordagens de avaliao arquitetural identificadas pela reviso sistemtica so caracterizadas e analisadas. O resultado dessa reviso permite identificar o estado da arte em avaliao arquitetural, assim como identificar os pontos positivos e as limitaes das abordagens selecionadas. No Captulo 4, intitulado Inspeo de Documentos Arquiteturais, apresentada a abordagem ArqCheck que a abordagem proposta para inspeo de documentos arquiteturais baseada em checklist. Nesse captulo, so descritos os motivos que levaram criao dessa abordagem, como ela foi criada e os elementos que a compe. No Captulo 5, intitulado Avaliando a Abordagem Proposta, so descritos como os estudos foram planejados, executados e os resultados oriundos da anlise dos dados obtidos. Durante a descrio dos resultados, so identificadas a viabilidade, a eficcia e o custo/eficincia em se aplicar ArqCheck na identificao de defeitos em documentos arquiteturais. No Captulo 6, intitulado Consideraes Finais, so apresentadas as concluses, os resultados obtidos e contribuies, suas limitaes e prximos passos que podem ser executados para dar continuidade ao trabalho apresentado nessa dissertao. No Apndice A, intitulado Protocolo de Reviso Sistemtica, esto descritas as informaes que foram usadas como base para a realizao da reviso sistemtica das abordagens de avaliao arquitetural descritas na literatura, cujos resultados foram apresentados no Captulo 2 dessa dissertao. No Apndice B, intitulado Checklist para Inspeo Arquitetural, esto descritas as diferentes verses do checklist utilizadas durante os estudos de avaliao, assim como a sua verso final. No Apndice C, intitulado Relatrio de Discrepncias, est descrito o relatrio utilizado pelos inspetores na identificao de defeitos encontrados atravs do checklist de inspeo arquitetural que compem ArqCheck. No Apndice D, intitulado Plano do Experimento, est descrito o principal artefato gerado durante a fase de planejamento do estudo de observao, realizado para avaliar a viabilidade, a eficcia e o custo/eficincia da abordagem proposta. No Apndice E, intitulado Questionrio de avaliao ps-experimento, est descrito o questionrio que foi utilizado no estudo de observao para coletar

informaes que auxiliassem na anlise qualitativa do objeto de estudo, no caso a abordagem proposta. No Anexo A, intitulado Notao para a Modelagem de Processo de Software, est descrito de forma resumida a notao que utilizamos nessa dissertao para modelar os processos de software nela descritos. No Anexo B, intitulado Tticas Arquiteturais, esto descritas as principais tticas arquiteturais que utilizamos como base para criar os itens de avaliao que compem o checklist que compem ArqCheck.

Captulo 2 Arquitetura de Software

Neste captulo, so apresentadas algumas definies que permitem identificar o contexto de Arquitetura de Software em que a abordagem proposta nesta dissertao se aplica. Nele, procuramos responder, tambm, em que consiste uma arquitetura de software e qual benefcio que pode ser obtido ao avali-la. Para isso, descrevemos os conceitos relacionados arquitetura de software que utilizamos como base, identificamos a importncia desse artefato dentro do processo de desenvolvimento de software e como ele construdo.

2.1 Introduo
Quando tentamos solucionar um problema, possvel identificar diversas solues que poderiam ser utilizadas visando resolv-lo. Contudo, outros fatores como custo e eficincia influenciam na escolha da soluo a ser adotada. No contexto do desenvolvimento de software, o mesmo pode ser observado ao se analisar os requisitos visando construo de um software: vrias solues computacionais podem ser definidas para atender a esses requisitos, mas uma anlise deve ser feita para definir a mais adequada ao contexto de desenvolvimento da aplicao. Para se representar essas solues, a arquitetura de software uma das abordagens que podem ser usadas. Com isso, para se obter a arquitetura (soluo) mais adequada para atender aos requisitos do software (problema), uma avaliao dessa estrutura deve ser realizada. A arquitetura consiste em um modelo de alto nvel que possibilita um entendimento e uma anlise mais fcil do software a ser desenvolvido. O uso de arquitetura para representar solues de software foi incentivada principalmente por duas tendncias (GARLAN e PERRY, 1995; KAZMAN, 2001): (1) o reconhecimento por parte dos projetistas que o uso de abstraes facilita a visualizao e o entendimento de certas propriedades do software, e (2) a explorao cada vez maior de frameworks2 visando diminuir o esforo de construo de produtos atravs da integrao de partes previamente desenvolvidas.

De acordo com GAMMA et al. (1995), um framework consiste em uma arquitetura codificada para um domnio de problema que pode ser adaptada para resolver problemas especficos.

Uma outra propriedade da arquitetura a possibilidade de us-la como ferramenta para comunicar a soluo projetada aos diversos stakeholders que participam do processo de desenvolvimento do software (GARLAN, 2000). Contudo, para que essa comunicao seja possvel, a arquitetura deve ser representada atravs de um documento, conhecido como documento arquitetural. Para se construir a arquitetura de um software, e por conseqncia o documento arquitetural que a representa, os requisitos so as principais informaes usadas. Durante o processo de especificao arquitetural (Figura 2.1), alm dos requisitos, outras fontes de conhecimento podem ser utilizadas para definir os elementos arquiteturais e a forma como eles devem estar organizados. Entre essas fontes de conhecimento se destacam principalmente a experincia do arquiteto, o raciocnio sobre os requisitos, e os estilos e as tticas arquiteturais.

Figura 2.1 - Elementos usados na construo de uma arquitetura representados de acordo com a notao definida em (VILLELA, 2004)3.

Contudo, existe uma falta de consenso na comunidade em relao tanto aos conceitos e definies bsicas quanto forma de representar uma arquitetura de software (BUSCHMANN et al., 1996; CLEMENTS et al., 2004). Portanto, na prxima seo, com o intuito de buscar a uniformizao da terminologia utilizada nessa dissertao, so descritos os termos aqui adotados e seus respectivos conceitos associados. Alm disso, na seo 2.3 so descritos a importncia e o papel da arquitetura de software no processo de desenvolvimento, e na seo subseqente so identificadas as principais atividades realizadas durante o processo de especificao arquitetural.

A notao de modelagem de processo de software apresentada em (VILLELA, 2004) ser usada ao longo dessa dissertao para representar os diversos processos que descrevemos. Para maiores informaes sobre a notao vide Anexo A.

2.2 Definio dos conceitos relacionados arquitetura de software

Nessa seo, so definidos os termos utilizados neste trabalho, evitando ambigidades, visto que terminologias inconsistentes sobre estes termos podem ser encontradas na literatura. Arquitetura de software representa a estrutura, ou conjunto de estruturas, que compreende os elementos de software, suas propriedades externamente visveis e seus relacionamentos (BASS et al., 2003). Para criar essa estrutura, grande parte dos autores concorda que trs tipos de elementos bsicos podem ser usados (DIAS e VIEIRA, 2000): Elementos de software, podendo tambm ser chamados de mdulos ou componentes, so as abstraes responsveis por representar as entidades que implementam funcionalidades especificadas; Conectores, podendo ser chamados de relacionamentos ou interfaces, so as abstraes responsveis por representar as entidades que facilitam a comunicao entre os elementos de software; Organizao ou configurao que consiste na forma como os elementos de software e conectores esto organizados. Alm disso, essa estrutura e as entidades que a compem devem ser representados de uma forma que permita utilizar a arquitetura projetada para seus devidos fins, a essa representao dado o nome de documento arquitetural. Esse documento composto por um conjunto de modelos e informaes, que descrevem principalmente a estrutura do software especificado para atender aos requisitos. Para compor um documento arquitetural, podemos nos basear, por exemplo, nas recomendaes descritas no padro IEEE-1471 (IEEE, 2000). Contudo, mesmo existindo padres que indicam o tipo de informao que deve ser descrito em um documento arquitetural, no definido exatamente o nvel de abstrao que deve ser usado na descrio dessas informaes. A arquitetura de um software comea a ser construda nos estgios iniciais de um processo de desenvolvimento de software com o objetivo de definir e visualizar a soluo computacional que ser implementada. Neste momento, esse artefato conhecido como arquitetura inicial, pertence ao escopo do problema, tem como principal caracterstica descrever a soluo em um elevado nvel de abstrao e utilizado por vrios stakeholders como base para tomada de decises. Contudo, ao longo do desenvolvimento do software, a arquitetura sofre refinamentos que diminuem o nvel de abstrao e permitem, por exemplo, a

10

representao dos relacionamentos entre os elementos arquiteturais e os arquivos de cdigo fonte responsveis por implement-los (CLEMENTS et al., 2004). Neste momento, a arquitetura passa a pertencer ao escopo da soluo e incorpora tambm informaes relacionadas s decises de projeto, como elementos especficos tecnologia que ser usada para implementar a soluo. O fato da arquitetura representar informaes em diferentes nveis de abstrao ao longo do processo de desenvolvimento um dos motivos que leva falta de consenso na comunidade, pois ainda no se padronizou a granularidade que deve ser usada para descrever esse artefato. No contexto desse trabalho, iremos trabalhar somente com a arquitetura inicial, ou seja, a que representa a estrutura em um elevado nvel de abstrao. Escolhemos trabalhar com esse artefato, pois a abordagem de avaliao que propomos nessa dissertao foi definida para inspecionar o documento arquitetural antes que a fase de projeto do software seja iniciada, visando evitar a propagao de defeitos. Nesse momento, somente a arquitetura inicial ter sido construda. Alm do mais, acreditamos que o uso de arquitetura para representar a soluo em um baixo nvel de abstrao no adequado devido existncia de diversos tipos de representao de projeto de baixo nvel, como diagramas de classe e de seqncias, que permitem uma representao mais completa desse tipo de informao. Contudo, qual o benefcio em se avaliar esse artefato? Para responder a essa pergunta, preciso identificar os papis que a arquitetura possui no processo de desenvolvimento de software e os benefcios que podem ser obtidos ao avali-la, o que torna sua avaliao uma atividade extremamente desejvel pelos stakeholders.

2.3 Papel da arquitetura em um processo de desenvolvimento de software e os benefcios de sua avaliao

Ao revisar um artefato de software vrios benefcios para o projeto e para a melhoria da qualidade do software podem ser obtidos. Contudo, para que essa atividade seja realizada, recursos devem ser alocados, o que pode aumentar o custo final do projeto. Portanto, antes de realizar a reviso de um artefato, imprescindvel que a importncia desse artefato dentro do processo de desenvolvimento seja identificada, permitindo definir o custo/benefcio de sua reviso. A principal motivao para avaliar a arquitetura de um software est relacionada ao seu papel dentro do processo de desenvolvimento.

11

Possuindo o documento arquitetural do sistema, os stakeholders podem utiliz-lo como artefato de entrada na realizao de algumas atividades do processo ou ento como base para tomada de decises no contexto do projeto. Para cada stakeholder, a arquitetura do software utilizada com diferentes propsitos (GACEK, 1995; XAVIER, 2001; CLEMENTS et al., 2004): Cliente. O cliente a pessoa ou empresa que contrata uma equipe de desenvolvimento para a construo de um sistema de sua necessidade. Na fase inicial do projeto, esse stakeholder necessita de uma estimativa de certos fatores, normalmente econmicos, que podem ser obtidos aps a definio da estrutura principal do software. O cliente, por exemplo, tem interesse em estimativas de custo, confiabilidade e manutenibilidade do software que podem ser obtidos principalmente atravs de uma anlise da arquitetura. Portanto, de extrema importncia para o cliente que a arquitetura atenda os requisitos do software de forma a representar suas reais expectativas em relao ao que foi especificado. Gerentes. A arquitetura permite aos gerentes tomarem certas decises de projeto por possibilitar a sumarizao das diversas caractersticas do sistema. Um gerente pode, por exemplo, usar a arquitetura como base para definir as equipes de desenvolvimento de acordo com os elementos arquiteturais que esto identificados na arquitetura e que devem ser construdos. Desenvolvedor. Da arquitetura de um software, o desenvolvedor busca uma especificao que descreva a soluo com detalhes suficientes e que satisfaa os requisitos do cliente, mas que no seja to restritiva a ponto de limitar a escolha das abordagens para a sua implementao. Os desenvolvedores usam a arquitetura como uma referncia para a composio e o desenvolvimento dos elementos do sistema, e para a identificao e reutilizao de elementos arquiteturais j construdos. Testadores. A arquitetura fornece, numa viso de caixa preta, informaes aos testadores relacionadas ao correto comportamento dos elementos arquiteturais que se integram. Sendo assim, este artefato pode ser um dos artefatos bases utilizados durante o planejamento e execuo de testes de integrao e de sistema. Mantenedor. A descrio arquitetural do software fornece aos mantenedores uma estrutura central da aplicao que idealmente no deve ser violada. Qualquer mudana deve preserv-la, buscando, se possvel, uma modificao puramente dos elementos arquiteturais e no da forma como esto organizados.

12

Visto como os principais stakeholders podem utilizar a arquitetura de um software, percebemos que o principal papel desse artefato servir como instrumento para comunicar a soluo proposta (GARLAN, 2000). Sendo assim, o principal benefcio em se avaliar um documento arquitetural est na diminuio das chances de um stakeholder utilizar um documento defeituoso nas atividades subseqentes do processo de desenvolvimento de software. Contudo, para permitir uma melhor compreenso sobre como e o que deve ser avaliado em um documento arquitetural, devemos primeiro entender como esse artefato criado.

2.4 Processo de especificao arquitetural

Existem na literatura diversas abordagens que objetivam a especificao de arquiteturas de software. Aps avaliar algumas das principais abordagens (GACEK, 1995; SHAW e GARLAN, 1996; BOSCH e MOLIN, 1999; BACHMANN et al., 2000; BASS et al., 2003) identificamos um processo genrico de especificao arquitetural. Esse processo composto principalmente pelos seguintes elementos (Figura 2.2): duas macros atividades (projeto e avaliao arquitetural) e a tarefa de documentao da arquitetura. O que diferencia essas abordagens principalmente a forma como cada um desses elementos so realizados.

Figura 2.2 - Processo genrico de especificao arquitetural

Nesse processo, a caracterstica comum s duas macro-atividades identificadas a presena da tarefa de documentao responsvel por criar e atualizar o documento que representa a arquitetura de software. Esse documento arquitetural criado

13

durante a macro-atividade de projeto arquitetural e responsvel por registrar as decises e os elementos arquiteturais. Aps identificarem que a soluo descrita na arquitetura atende a todos os requisitos especificados, os arquitetos do incio atividade de avaliao arquitetural que utiliza como principal artefato de entrada o documento arquitetural. Aps a avaliao, dependendo da qualidade do documento arquitetural e por conseqncia da arquitetura projetada, o arquiteto decide se o artefato ser reavaliado visando atingir a qualidade desejada ou ento se o processo de especificao arquitetural ser finalizado. A seguir, mostrado para cada um dos elementos do processo de especificao arquitetural que tipo de informaes e abordagens podem ser utilizadas para realizlos.

2.4.1 Projeto Arquitetural

O projeto arquitetural consiste na atividade em que a soluo computacional e, por conseqncia, a arquitetura do software so definidas. Durante essa atividade, o raciocnio sobre os requisitos realizado e decises arquiteturais so tomadas, visando identificar e organizar os elementos arquiteturais para que os requisitos especificados possam ser atendidos. Ao se analisar como essa atividade realizada nas principais abordagens de especificao arquitetural, observamos a importncia dos requisitos de qualidade no projeto de uma arquitetura e a existncia de vrias abordagens que podem ser utilizadas para atend-los. 2.4.1.1 Requisitos de Qualidade Os requisitos de um software podem ser classificados como requisitos funcionais e os no-funcionais. Os requisitos funcionais so responsveis por descreverem as funcionalidades que o software deve apresentar. J os no-funcionais descrevem caractersticas que o software deve apresentar, muitas vezes podem ser enxergadas como restries ou especialidades do produto final. Os requisitos podem ter vrias sub-categorias, como por exemplo, requisitos de qualidade, requisitos legais e etc. Dentre os diferentes tipos de requisitos, tanto funcionais quanto no-funcionais, os requisitos de qualidade so os que mais influenciam na construo da arquitetura. Isso ocorre visto que, diferente dos requisitos funcionais onde na maioria dos casos uma modificao ocasiona alteraes em um conjunto especfico de elementos

14

arquiteturais, alteraes em um requisito de qualidade podem implicar na total reestruturao da arquitetura (BASS et al., 2003). Contudo, nem todos os requisitos de qualidade so relevantes a nvel arquitetural, pois determinados tipos de requisitos podem ser atendidos somente durante a etapa de codificao ou disponibilizao (XAVIER, 2001). Um requisito de inteligibilidade, por exemplo, s poder ser implementado no momento da definio da interface do sistema com o usurio. Existem diferentes taxonomias para se classificar requisitos de qualidade (ISO/IEC, 1998; BASS et al., 2003). No contexto desse trabalho, adotamos a taxonomia descrita por BASS et al. (2003) visto que ela identifica os tipos de requisitos de qualidade que so relevantes a nvel arquitetural, ou seja, quais os tipos de requisitos de qualidade que influenciam na construo da arquitetura de um software. Portanto, de acordo com BASS et al. (2003), esses tipos de requisitos so: Desempenho: Descrevem o comportamento do sistema em relao a restries de tempo e de recurso computacional; Disponibilidade: Descrevem o comportamento de determinada parte do sistema em caso de falha; Modificabilidade: Descrevem quais as provveis modificaes que podem acontecer no sistema e as flexibilidades que devem estar nele presentes para que essas modificaes sejam facilmente realizadas; Segurana: Descrevem o comportamento de determinada parte do sistema em relao ao acesso de seus dados ou funcionalidades; Testabilidade: Descrevem o comportamento de determinada parte do sistema em relao s facilidades que elas devem fornecer para a realizao de testes; Usabilidade: Requisitos desse tipo, em um contexto arquitetural, descrevem facilidades que o sistema deve possuir, mas que no so consideradas funcionalidades do sistema. Exemplo dessas facilidades so operaes de undo e redo. 2.4.1.2 Atendendo os requisitos de qualidade Durante o projeto de uma arquitetura, para atender aos requisitos de qualidade, as principais abordagens utilizam diversas fontes de conhecimento, tanto tcito quanto explcito para definir quais sero os elementos arquiteturais e com estaro organizados. Um exemplo de conhecimento tcito seria a experincia do arquiteto, e em relao ao conhecimento explcito teramos os estilos e as tticas arquiteturais. A experincia de um arquiteto uma caracterstica importante para o sucesso do projeto de uma arquitetura, pois a partir de suas lies aprendidas, o arquiteto

15

consegue facilmente identificar que elementos arquiteturais devem ser criados e como eles devem ser organizados. Mas, por ser um conhecimento tcito, difcil de ser externalizado e utilizado por terceiros. Por outro lado, estilos e tticas arquiteturais so conhecimentos explcitos amplamente difundidos na literatura e bastante utilizados por arquitetos de software (SHAW, 1995; BUSCHMANN et al., 1996; BASS et al., 2003). Um estilo arquitetural, ou padro arquitetural, consiste em um conhecimento que pode ser diretamente aplicado pelo arquiteto na identificao dos elementos arquiteturais. Isso possvel por ele ser composto por um conjunto de regras que permitem a identificao dos tipos de componentes e de conectores que sero usados na composio do software levando em conta as restries impostas (SHAW e GARLAN, 1996). Na literatura, existe um outro conceito, chamado de padres de projeto, que muito semelhante ao conceito de estilos arquiteturais. Em BUSCHMANN et al. (1996), feita a diferenciao entre padres arquiteturais e padres de projeto. Essa diferena encontra-se principalmente no nvel de abstrao onde cada um desses padres atua. Os padres de projeto so utilizados somente durante a fase de definio do projeto de baixo-nvel, onde refinamentos so feitos nos elementos arquiteturais que formam a arquitetura, e que foram definidos com base nos padres arquiteturais. Contudo, muitos dos conceitos presentes em padres arquiteturais e padres de projeto so semelhantes, mas o que os diferencia o fato de serem utilizados em nveis de abstrao diferentes. No contexto dessa dissertao, abordaremos somente padres arquiteturais pois so eles que possuem os principais conceitos relevantes a nvel arquitetural. Para evitar confuses, utilizaremos a denominao de estilos arquiteturais quando abordarmos esses conceitos. Com isso, uma caracterstica particular aos estilos arquiteturais que o uso de um nico estilo possibilita o atendimento a vrios tipos de requisitos de qualidade. XAVIER (2001), por exemplo, descreve uma abordagem que, a partir dos tipos de requisitos de qualidade que devem ser atendidos pelo software, permite identificar os estilos arquiteturais mais adequados que devem ser usados na construo desse software. Alm dos estilos, um outro tipo de conhecimento explcito que pode ser utilizado no projeto arquitetural so as tticas arquiteturais. Uma ttica arquitetural consiste em um conhecimento mais abstrato, utilizado principalmente para auxiliar o atendimento a um tipo de requisito de qualidade. Portanto, por serem mais abstratas, essas tticas descrevem principalmente possveis caractersticas que uma arquitetura deve apresentar para atender a um determinado tipo de requisito.

16

Em BASS et al. (2003), essas tticas so identificadas e categorizadas em grupos, de acordo com os atributos de qualidade que elas influenciam. Uma caracterstica particular a essas tticas que quando agrupadas e especializadas, podem ser usadas como base para a criao de estilos arquiteturais. ZHU (2004), por exemplo, realizou uma anlise dos principais estilos arquiteturais por eles utilizados e identificou as tticas arquiteturais que os compem. Sendo assim, a partir do uso desse tipo de conhecimento, o arquiteto consegue definir a estrutura principal da arquitetura. Essa estrutura em seguida povoada com elementos arquiteturais identificados principalmente a partir da anlise dos requisitos funcionais.

2.4.2 Documentao Arquitetural

Uma caracterstica nica em Engenharia de Software em relao s outras reas de engenharia que os produtos por ela construdos no so completamente materializveis. Diferente de um engenheiro civil que pode inspecionar, por exemplo, as partes de um prdio, um engenheiro de software no consegue inspecionar um pedao do software em si. Para isso ele deve utilizar representaes desse software (LAITENBERGER e ATKINSON, 1999). A arquitetura um exemplo da parte de um software que no materializvel. Durante uma inspeo, por exemplo, o documento arquitetural que deve ser revisado, por impossibilidade de se inspecionar diretamente a arquitetura projetada. Sendo assim, durante o seu projeto, a arquitetura tem que ser documentada para que ela possa ser usada para os seus devidos fins. A arquitetura uma entidade complexa que no pode ser descrita de uma forma unidimensional (CLEMENTS et al., 2004). Uma forma efetiva de lidar com essa complexidade descrevendo-a a partir de diferentes perspectivas, tambm conhecidas como vises arquiteturais. Em cada viso, a forma como os elementos arquiteturais e seus relacionamentos so documentados coloca em evidncia propriedades distintas do software que eles representam. De acordo com EGYED e MEDVIDOVIC (1999), ao criar uma viso arquitetural, os desenvolvedores conseguem reduzir a quantidade de informao que so obrigados a lidar em um determinado momento. Portanto, essas vises representam um aspecto parcial da arquitetura que mostram propriedades especficas do software.

17

Na Figura 2.3, podemos identificar trs vises arquiteturais usadas para descrever um conjunto de elementos arquiteturais. Independente da notao grfica utilizada, possvel notar as diferentes propriedades que cada viso permite identificar.

Figura 2.3 Exemplo de vises arquiteturais

Existe um grande nmero de vises arquiteturais propostas na literatura que propem solues similares para a representao de uma arquitetura (KRUCHTEN, 1995; HOFMEISTER et al., 2000; CLEMENTS et al., 2004). As principais vises so: Viso Modular: Esta perspectiva representa os elementos que compem a arquitetura, responsveis por realizar um conjunto de funcionalidades, e as dependncias entre eles. Para isso, um conjunto de diagramas pode ser criado para representar atravs de diferentes nveis de abstrao, os elementos, seus elementos internos (caso haja) e como eles se relacionam entre si. Viso Dinmica: Esta perspectiva procura descrever o comportamento dos elementos arquiteturais durante a realizao dos diferentes fluxos de execuo que pertencem ao sistema.

18

Viso de Alocao: Esta perspectiva busca representar o mapeamento das unidades de software para elementos fsicos do ambiente (hardware, arquivos do sistema, equipe de desenvolvimento).

Viso de contexto geral: Essa perspectiva tem como objetivo representar uma viso geral dos principais componentes que formam a arquitetura do software e de como ele se relaciona com os elementos externos ao seu contexto (atores e sistemas externos). A escolha das vises a serem documentadas deve ser feita com base nas

caractersticas de qualidade que se deseja por em evidncia, uma vez que diferentes vises expem caractersticas de qualidade distintas. Para CLEMENTS et al. (2004), documentar uma arquitetura consiste em documentar as vises arquiteturais relevantes, explicar como essas vises se relacionam e como um stakeholder deve utilizar esse material. No contexto dessa dissertao, utilizamos algumas das recomendaes definidas pelo padro IEEE-1471, que abordam a descrio arquitetural de sistemas de software, para definir as principais informaes que devem ser descritas em um documento arquitetural. Sendo assim, um documento arquitetural deve: Identificar os elementos arquiteturais que compem a soluo a ser construda, assim como a forma que esses elementos esto organizados; Descrever o papel de cada elemento dentro da arquitetura; Identificar como cada requisito relevante a nvel arquitetural est sendo atendido atravs da arquitetura documentada. Essa identificao pode ser feita principalmente atravs do rastreamento de que requisito est sendo atendido e quais requisitos justificam a criao de determinado elemento arquitetural; Representar o software atravs de diferentes perspectivas, como por exemplo, atravs do uso de vises arquiteturais.

2.4.3 Avaliao Arquitetural

A avaliao arquitetural consiste em caracterizar e avaliar os documentos arquiteturais atravs de mtodos ou procedimentos sistemticos (BAHSOON e EMMERICH, 2003). Essa avaliao verifica principalmente se as informaes descritas no documento esto consistentes e se a arquitetura nele representada atende aos requisitos especificados para o produto. Visto que so os requisitos de qualidade os que mais influenciam a construo de uma arquitetura, portanto, principalmente sob a perspectiva desse tipo de requisitos

19

que a avaliao deve ser realizada (DOBRICA e NIEMELA, 2002; BABAR et al., 2004). A realizao da atividade de avaliao de extrema importncia para a melhoria da qualidade do produto de software e para o sucesso do projeto. Esta afirmao fortalecida se for considerado que (1) a avaliao da arquitetura impede que seus defeitos se propaguem para os demais artefatos, como diagramas de projeto e cdigo fonte, e (2) o custo de correo desses defeitos bem menor se for realizada durante os primeiros estgios do projeto (BOEHM, 1981). Alm dos benefcios listados anteriormente, MARANZANO et al. (MARANZANO et al., 2005) identificaram os seguintes benefcios, aps aplicar a avaliao arquitetural em diversos projetos no contexto da empresa em que trabalha, que podem ser obtidos atravs dessa prtica: Permite um melhor aproveitamento do conhecimento de seus especialistas, pois so alocados em avaliaes arquiteturais que analisam arquiteturas de projetos em que no tiveram participao, utilizando assim suas experincias e conhecimentos para auxili-los; Permite um melhor gerenciamento dos fornecedores de componentes de software da empresa; Permite que a alta gerncia tenha uma maior compreenso de problemas, principalmente de ordem tcnica, que ocorrem durante a gerncia dos projetos da empresa; Possibilite a identificao de necessidades de treinamentos ao nvel de projeto ou organizacional com base em tipos de problema freqentemente identificados durante as avaliaes. Por exemplo, fornecer cursos em otimizao de sistemas quando as avaliaes identificarem principalmente problemas arquiteturais relacionados caracterstica de desempenho. A avaliao de documentos arquiteturais um tema que tem sido bastante discutido no contexto de vrios grupos de pesquisa, como no grupo do Software Engineering Institute (SEI) (KAZMAN et al., 1994; CLEMENTS et al., 2002), por exemplo. Portanto, existem diversas abordagens que realizam essa avaliao visando diferentes objetivos ou utilizando diferentes tcnicas. No captulo 3 dessa dissertao, os principais mtodos so identificados e caracterizados.

20

2.5 Concluso
Ao longo deste captulo, foram descritos os principais conceitos em relao arquitetura de software, dando nfase principalmente nas atividades que esto relacionadas ao seu processo de especificao. Atravs da anlise desses conceitos e processos, foi possvel identificar (1) a importncia da arquitetura dentro do processo de desenvolvimento de software, (2) como esse artefato construdo e principalmente (3) que informaes devem estar representadas nesse artefato e que devem ser analisadas durante o processo de avaliao para que se determine a corretude do documento arquitetural. Sendo assim, dando continuidade metodologia que foi definida para realizar esse trabalho, o segundo passo a ser realizado consiste em identificar as abordagens de avaliao existentes com o objetivo de observar suas caractersticas, pontos positivos e limitaes. No captulo seguinte, intitulado Abordagens de avaliao arquitetural, descrevemos os resultados obtidos neste contexto.

21

Captulo 3 Abordagens de avaliao arquitetural

Neste captulo, as principais abordagens de avaliao arquitetural descritas na literatura tcnica so identificadas e caracterizadas. Alm disso, descrevemos como essa identificao foi feita e os resultados obtidos aps a anlise dessas abordagens. So esses resultados que motivaram a criao da abordagem de avaliao proposta nessa dissertao.

3.1 Introduo
Sabemos que a avaliao de um documento arquitetural no permite medir com exatido as caractersticas de qualidade do produto de software final (BOSCH, 2000). Isso ocorre devido ao fato do documento arquitetural avaliado no representar todas as informaes que iro compor o projeto detalhado e a implementao, artefatos gerados em atividades posteriores, e tambm devido ao fato dessa avaliao ser realizada normalmente sobre a arquitetura inicial do sistema, artefato que no engloba diversas decises de projeto, como por exemplo, decises ligadas a questes tecnolgicas. O principal objetivo de uma avaliao arquitetural consiste em verificar se as informaes descritas no documento esto consistentes e se a arquitetura nele representada atende aos requisitos especificados para o software. Portanto, esse tipo de verificao possibilita principalmente a diminuio da propagao dos defeitos contidos nesse documento para as fases subseqentes que o utilizam como artefato de entrada. Contudo, o que se pode dizer sobre avaliao de documentos arquiteturais? possvel identificar abordagens que realizam esse tipo de avaliao? possvel caracterizar como tais abordagens realizam essa avaliao? A resposta a esses questionamentos extremamente importante pois permite entender como se caracteriza o estado da arte dessa rea. A partir desse entendimento, tambm possvel identificar benefcios e possveis limitaes das abordagens existentes. Visto que o nosso objetivo definir uma abordagem de avaliao de documentos arquiteturais, a identificao das abordagens de avaliao arquitetural existentes e a caracterizao de como eles avaliam um documento arquitetural uma das etapas que definimos para atingir o nosso objetivo.

Portanto, realizamos uma reviso sistemtica (KITCHENHAM, 2004; BIOLCHINI et al., 2005) para identificar as principais abordagens de avaliao arquitetural descritas na literatura tcnica e caracterizamos essas abordagens visando entend-las. Nas sees a seguir, descrito em que consiste uma reviso sistemtica, como foi a conduo desse tipo de reviso visando identificar abordagens de avaliao arquitetural e quais foram os resultados obtidos aps a anlise das abordagens identificadas.

3.2 Reviso Sistemtica

A avaliao de documentos arquiteturais um tema que tem sido bastante discutido no contexto de diversos grupos de pesquisa, como no grupo do Software Engineering Institute (SEI) (KAZMAN et al., 1994; CLEMENTS et al., 2002), por exemplo. Contudo, no foram encontrados registros na literatura tcnica de revises formais que tenham sido realizadas visando identificao das abordagens de avaliao arquitetural. As revises conduzidas anteriormente (CLEMENTS et al., 2002; DOBRICA e NIEMELA, 2002; BAHSOON e EMMERICH, 2003; BABAR et al., 2004) no descrevem o escopo em que as buscas foram executadas nem os critrios de seleo utilizados. Sendo assim, essas revises no podem ser auditadas, no so passveis de serem repetidas e a obteno dos resultados depende dos revisores que a executaram, aumentando assim a possibilidade de vis nos resultados (MAFRA e TRAVASSOS, 2005). Para evitar as limitaes observadas nas revises existentes, optamos por realizar uma reviso sistemtica que colete, em algumas das principais fontes da comunidade de Engenharia de Software, estudos que abordem o tema de avaliao arquitetural e permitam a identificao das abordagens de avaliao arquitetural existentes.

3.2.1 Definio
Normalmente, para se estudar uma nova rea de conhecimento, pesquisadores costumam utilizar a reviso bibliogrfica como abordagem de busca por publicaes. Contudo, essa abordagem no realizada de forma sistemtica e no fornece nenhum apoio que permita evitar vis na escolha das publicaes que sero selecionadas para serem analisadas, por exemplo. Uma forma de sistematizar a identificao e anlise de publicaes, e estudos primrios em geral, atravs de revises sistemticas. Uma reviso sistemtica um meio de identificar, avaliar e interpretar os resultados de pesquisas disponveis e relevantes a um conjunto de critrios, de acordo

23

com uma pergunta de pesquisa, uma rea especfica ou um fenmeno de interesse (KITCHENHAM, 2004). Essa abordagem segue uma seqncia precisa e bem definida de passos, de acordo com um protocolo de pesquisa previamente planejado. Os estudos identificados por uma reviso sistemtica so classificados como estudos primrios. No contexto deste trabalho, esses estudos so publicaes cientficas. A reviso sistemtica em si considerada um estudo secundrio (KITCHENHAM, 2004), uma vez que ela depende dos resultados dos estudos primrios para ser conduzida. KTCHENHAM (2004) descreve vrios motivos para a realizao de uma reviso sistemtica, entre os principais temos: Para sumarizar evidncias relacionadas a uma rea de conhecimento ou a uma tecnologia. Como por exemplo, sumarizar evidncias experimentais sobre os benefcios e limitaes de determinado mtodo; Identificar falhas em uma pesquisa existente visando sugerir que tpicos deveriam ser investigados com mais rigor; Caracterizar determinadas reas do conhecimento visando propor atividades de pesquisa que poderiam ser realizadas para evoluir essas reas. No contexto deste trabalho, realizamos esse tipo de reviso com o intuito de sumarizar conhecimento e identificar evidncias em relao s abordagens de avaliao arquitetural identificadas, permitindo a investigao de seus benefcios e limitaes. Uma reviso sistemtica se destaca por ser executada atravs de um processo de conduo. Alm disso, para que seja possvel uma posterior auditoria e repetio, as informaes relacionadas aos passos executados durante essa reviso devem ser avaliadas e registradas em um documento conhecido como protocolo de reviso sistemtica (KITCHENHAM, 2004; BIOLCHINI et al., 2005).

3.2.2 Processo de conduo de uma reviso sistemtica

O uso de um processo de conduo extremamente importante por permitir uma sistematizao dos passos que devem ser realizados. Um dos processos que pode ser utilizado na conduo de uma reviso sistemtica o descrito em (BIOLCHINI et al., 2005). Este processo composto pelos seguintes passos: Planejamento da reviso: Durante esse passo, os objetivos da pesquisa devem ser definidos atravs da especificao do que ser pesquisado, dos locais onde a pesquisa ser realizada e dos critrios utilizados para definir se um estudo identificado vlido ou no para a pesquisa. No final dele, uma verso refinada do

24

protocolo criada e a viabilidade em realizar o que foi descrito nesse protocolo tem que ser avaliada. Execuo da reviso: Durante esse passo, feita a identificao dos estudos que estejam relacionados ao objetivo da pesquisa e que satisfaam os critrios de seleo definidos. Essa identificao realizada atravs de buscas, usando palavras chave previamente definidas, que devem ser executadas nas fontes de pesquisa que foram previamente definidas. As publicaes identificadas so filtradas nesse momento, de acordo com os critrios de incluso e excluso. Anlise dos resultados: Durante esse passo, feita a anlise das publicaes selecionadas visando extrair informaes para responder s questes de pesquisa.

3.3 Conduzindo uma reviso sistemtica para identificar mtodos de avaliao arquitetural
A reviso sistemtica realizada no contexto dessa dissertao foi planejada e conduzida com base nos conceitos descritos em (BIOLCHINI et al., 2005). O objetivo desse estudo consiste em:
Tabela 3.1 - Objetivos do estudo seguindo o mtodo GQM (BASILI et al., 1994) Analisar abordagens que avaliam documentos arquiteturais Com o propsito de caracterizar Com respeito s caractersticas presentes em tcnicas de inspeo de software Do ponto de vista dos inspetores de artefatos de software No contexto dos estudos primrios que descrevem essas abordagens

A seguir, so mostradas as principais informaes relacionadas execuo dos passos dessa reviso sistemtica.

3.3.1 Planejamento da reviso sistemtica

Durante o planejamento dessa reviso, um protocolo foi criado visando registrar todas as decises tomadas em relao sua realizao. Esse protocolo seguiu o template descrito em (BIOLCHINI et al., 2005). Na Tabela 3.2, esto descritas as principais informaes que compem o protocolo, para uma verso completa desse artefato veja o Apndice A.
Tabela 3.2 - Principais informaes descritas no protocolo da reviso sistemtica. Foco da pergunta de pesquisa: Identificar e caracterizar abordagens utilizadas para avaliar a qualidade de documentos arquiteturais;

25

Pergunta: De que forma arquiteturas de software e documentos arquiteturais so avaliados? Quais as abordagens e em que contexto elas so utilizadas? Contexto: Essas abordagens de avaliao devem ter sido executadas em projetos de desenvolvimento de software que (1) possuam seus requisitos bem definidos, (2) possuam atividades que apiem a construo da arquitetura do software a ser implementado e (3) utilizam abordagens de avaliao para determinar se os atributos de qualidade desejados foram respeitados. Palavras-chave4: software architecture, software modularity, software component, architectural model, high level design, high level model, evaluate, assurance, review, inspection, verification, analysis; Critrios de seleo de fontes: Disponibilidade de consulta atravs da web; possurem um nvel de avaliao Qualis Capes superior a C; Listagem de fontes: Portal IEEE - IEEE Xplore (IEEE, 2004), Portal da ACM (ACM, 2004), Relatrios tcnicos do SEI (SEI, 2004), Livros da rea (Documenting Software Architecture (CLEMENTS et al., 2004), Evaluating Software Architecture (CLEMENTS et al., 2002) e Software Architecture in Practice, Second Edition (BASS et al., 2003)). Critrios de incluso e excluso dos estudos: Os artigos devem: estar disponveis no momento da pesquisa; descrever ou apresentar alguma abordagem que avalie a arquitetura de um software ou seus modelos;

3.3.2 Execuo da reviso sistemtica

A execuo de uma reviso sistemtica consiste na realizao de duas atividades. Em um primeiro momento, feita a identificao dos estudos cientficos. Essa identificao realizada atravs de buscas nas mquinas de buscas das fontes selecionadas, usando as palavras chave que foram definidas. Aps isso, para cada estudo identificado, feita uma anlise dos artigos visando avali-los e selecion-los de acordo com os critrios de excluso e incluso definidos no protocolo. Nas revises por ns realizadas, essa anlise foi feita atravs da leitura das sees de resumo e de introduo, e o critrio utilizado foi selecionar as publicaes que permitissem identificar alguma abordagem de avaliao arquitetural. No contexto desse trabalho, duas execues do protocolo da reviso sistemtica foram realizadas (Tabela 3.3). A primeira execuo foi realizada durante o ms de Dezembro de 2004 e 80 estudos cientficos foram por ela identificados. Contudo, somente 26 foram selecionados por atenderem aos critrios de incluso e excluso definidos no protocolo.

Conjunto de palavras que foram usadas como base para a criao das strings de busca nas diferentes mquinas de busca.

26

Durante a realizao da primeira atividade de execuo dessa reviso, tivemos problemas com a mquina de busca da ACM (ACM), relacionados principalmente a inconsistncias observadas nos resultados obtidos aps a execuo de uma busca, o que impossibilitaria a obteno dos mesmos resultados quando essa busca fosse repetida. Visto que uma das principais caractersticas da reviso sistemtica permitir que a obteno dos resultados seja repetvel de forma independente dos pesquisadores que a realiza, decidimos eliminar essa fonte de pesquisa, assim como as publicaes atravs dela identificadas.
Tabela 3.3 Quantidade de publicaes identificadas e selecionadas em cada reviso Revises Dezembro 2004 (IEEE Xplore) Dezembro 2005 (IEEE Xplore + ACM) Qtd. Identificados 80 119 Qtd. Selecionados 26 38

Todavia, em Dezembro de 2005, a reviso sistemtica foi re-executada. Optamos por re-execut-la por dois motivos: (1) identificar novas publicaes e abordagens arquiteturais que tenham surgido durante esse intervalo de tempo e (2) verificar a viabilidade de se identificar publicaes na mquina de busca da ACM, que sofreu evolues desde a ltima reviso que realizamos. Alm da incluso da biblioteca da ACM como fonte de pesquisa, o protocolo de reviso sofreu evolues aps a anlise dos resultados obtidos na primeira execuo. A principal modificao ocorreu nas palavras chave, que so usadas para criar as strings de busca utilizadas na identificao das publicaes nas fontes de pesquisa. Ao observar os estudos identificados na primeira execuo do protocolo, percebemos que algumas abordagens de avaliao arquitetural eram classificadas tambm como abordagens de anlise arquitetural. Sendo assim, a palavra analysis foi includa na lista de palavras chave, o que permitiu a identificao de publicaes que utilizam essa taxonomia durante a busca. Como resultado dessa segunda reviso, identificamos 119 publicaes relevantes e aps a aplicao dos critrios de incluso e excluso 38 foram selecionados. Ao fazer uma anlise dos artigos selecionados percebemos que esse novo conjunto contm todo o conjunto de artigos selecionados na primeira reviso e mais os publicados em 2005 e os que eram exclusivos biblioteca da ACM, eliminada na primeira reviso. Sendo assim, a partir de uma anlise mais completa dos estudos selecionados, 27 abordagens de avaliao arquitetural foram identificadas.

27

3.4 Abordagens de avaliao arquitetural identificadas

Para que seja possvel ter um melhor entendimento e permitir uma comparao entre essas 27 abordagens de avaliao identificadas, necessrio que cada uma seja caracterizada. O principal objetivo das abordagens de avaliao identificadas a melhoria da qualidade da arquitetura de software. Visto que resultados de estudos experimentais tm mostrado os benefcios que a utilizao de tcnicas de inspeo aportam melhoria da qualidade de artefatos de software (SHULL et al., 2000; CONRADI et al., 2003), optamos por usar um conjunto de caractersticas normalmente presentes nesse tipo de tcnicas para definir um framework que permita caracterizar as abordagens de avaliao arquitetural. Nas subsees abaixo, descrevemos os conceitos bsicos de inspeo de software, identificamos cada uma das caractersticas que compem essa abordagem de reviso e justificamos a importncia em utiliz-las para caracterizar as abordagens de avaliao arquitetural. Em seguida, descrevemos sucintamente cada abordagem identificada e os resultados de sua caracterizao.

3.4.1 Inspeo de Software

Inspeo de software (FAGAN, 1976) um mtodo rigoroso e formal executado com o objetivo de examinar artefatos de software. Esse tipo particular de reviso possui como caracterstica principal um processo de deteco de defeitos rigoroso e bem definido. Para caracterizar uma abordagem de inspeo, compreender o seu funcionamento e sua influncia no ambiente em que ela aplicada, necessrio avaliar as diferentes dimenses que formam essa abordagem. LAITENBERGER E DEBAUD (1998) identificaram, a partir de um survey realizado na literatura, cinco dimenses que podem ser utilizadas para caracterizar a natureza de uma abordagem de inspeo de software: Dimenso Tcnica: usada para caracterizar diferentes abordagens de inspeo atravs da identificao de similaridades e diferenas; Dimenso Gerencial: usada para prover informaes dos efeitos da abordagem de inspeo no projeto e vice versa; Dimenso Organizacional: usada para prover informaes sobre a influncia da abordagem no contexto de uma organizao e vice versa; Dimenso Avaliao: usada para comparar o custo / benefcio de uma abordagem em uma determinada situao;

28

Dimenso Apoio Ferramental: usada para prover informaes sobre como a abordagem pode ser apoiada por ferramentas.

3.4.2 Critrios usados para caracterizar as abordagens de avaliao arquitetural

No contexto dessa dissertao, visto que objetivamos caracterizar as abordagens identificadas pela reviso sistemtica e identificar similaridades e diferenas entre elas, utilizamos os conceitos pertencentes dimenso tcnica (LAITENBERGER e DEBAUD, 1998) como base para identificar alguns critrios para a nossa caracterizao (Tabela 3.4). Alm dos conceitos presentes na dimenso tcnica, decidimos adicionar ao framework de caracterizao alguns critrios presentes em outros frameworks descritos na literatura tcnica (DOBRICA e NIEMELA, 2002; BABAR et al., 2004) e que achamos relevantes para atingir o nosso propsito. Esses critrios adicionais so: o momento do processo de especificao arquitetural que a avaliao realizada, a existncia de alguma ferramenta que auxilie essa avaliao e a existncia de estudos que avaliem a abordagem.
Tabela 3.4 Questionamentos que buscamos responder a partir de cada critrio Critrios Tipo de arquitetura avaliada Tipo de tcnica usada na avaliao Processo seguido durante a avaliao Artefatos requeridos Artefatos produzidos Caractersticas de qualidade avaliadas Momento da avaliao Apoio ferramental Avaliao da abordagem Questionamentos Que tipo de informao usado para descrever a arquitetura a ser avaliada? Qual o nvel de abstrao utilizado? Como as discrepncias so encontradas? Quais os passos que so necessrios para realizar essa avaliao? Que artefatos devem ser disponibilizados para os envolvidos na avaliao? Que artefatos so gerados por essa avaliao? Que caractersticas cada abordagem busca avaliar? Em que momento do seu processo de especificao, a arquitetura avaliada? A abordagem possui algum apoio ferramental para a sua realizao? A abordagem teve sua viabilidade e utilidade avaliadas?

A seguir, justificamos a importncia em utilizar cada um desses critrios na caracterizao de abordagens de avaliao arquitetural. 3.4.2.1 Tipo de arquitetura avaliada Uma das caractersticas especficas a uma abordagem de avaliao o tipo de artefato que ela avalia. A princpio, no contexto de avaliao arquitetural, todas as abordagens identificadas avaliam arquiteturas de software. Porm, na rea de Arquitetura de

29

Software no existe um consenso em relao ao que uma arquitetura de software, mais especificamente ao contedo do documento que a descreve. Sendo assim, ao caracterizar uma abordagem atravs desse critrio, buscamos identificar o que exatamente avaliado pela abordagem. Com isso, definimos que o tipo de arquitetura avaliada deve ser caracterizado atravs dos tipos de informao usados para descrever a arquitetura (representaes grficas, descries textuais, rastreabilidade com os requisitos, decises arquiteturais, descrio usando diferentes perspectivas de representao) e o nvel de granularidade usado para descrever essas informaes (arquitetura inicial ou refinada). 3.4.2.2 Tipo de tcnica usada na avaliao Uma forma de caracterizar abordagens de avaliao arquitetural consiste em identificar as tcnicas ou tipos de mtodos que so utilizados para realizar essa avaliao (ABOWD et al., 1997). Identificar a tcnica utilizada por uma abordagem de extrema importncia, pois ela que define como o avaliador ir realizar a avaliao do artefato e, portanto, que procedimentos ele deve seguir para atingir o seu objetivo. No contexto de avaliao arquitetural, ABOWD et al. (1997) identificou trs tipos de tcnicas de avaliao que podem ser usadas: tcnicas de questionamento, de medio e hbridas. Tcnicas de questionamento Diferente das tcnicas de medio, que requer a existncia de algum tipo de artefato executvel para que elas possam ser utilizadas, as tcnicas de questionamento podem ser usadas para investigar qualquer parte da arquitetura, no importando o estado que ela se encontre (CLEMENTS et al., 2002). Esse tipo de tcnica utilizado principalmente quando se possui um conjunto de questionamentos e se deseja aplic-los visando observar como eles so respondidos a partir da arquitetura selecionada, ou seja, ela busca revisar a arquitetura de software a partir de critrios pr-definidos. Esse tipo de avaliao tambm conhecido como reviso de software e uma das possveis abordagens usadas para garantir a qualidade de artefatos de software. As principais tcnicas que se enquadram nessa categoria so principalmente as que fazem uso de cenrios, questionrios e checklists.

30

Tcnicas de medio Em vez de prover meios para gerar os questionamentos que sero feitos durante a avaliao, esse tipo de tcnica busca por respostas que os membros da equipe de avaliao j formularam em relao a uma determinada caracterstica da arquitetura. Contudo, esse tipo de tcnica necessita a presena de artefato implementacional sobre o qual as medies podem ser feitas. As principais abordagens que utilizam esse tipo de tcnica so aquelas que fazem uso de mtricas, simulao, prottipos ou experimentao sobre os sistemas derivados da arquitetura que est sendo avaliada. Tcnicas hbridas Muitas abordagens de avaliao fazem o uso simultneo de tcnicas de medio e de questionamento, ficando assim conhecidos como tcnicas hbridas. Essa abordagem utilizada quando alguma tcnica de medio utilizada para responder a questionamentos levantados por tcnicas de questionamento (CLEMENTS et al., 2002). 3.4.2.3 Processo seguido durante a avaliao Processos so importantes porque impem consistncia e estrutura a um conjunto de atividades, guiam aes e permitem examinar, entender, controlar e melhorar as atividades que o compem (PFLEEGER, 2004). A presena de um processo para uma abordagem de avaliao permite a sistematizao do mtodo e uma forma de identificar que atividades da abordagem de avaliao devem ser realizadas para que os resultados planejados sejam obtidos. Nessa caracterizao, pretendemos identificar principalmente quais so as atividades que devem ser realizadas para executar a abordagem. Com base nessa informao, possvel se ter uma idia dos custos envolvidos nessa avaliao. 3.4.2.4 Artefatos requeridos e artefatos produzidos pela avaliao Alm do documento arquitetural, outros artefatos so tambm necessrios para que uma avaliao seja realizada. Alm disso, devido aos diferentes objetivos que levam a realizao de uma avaliao arquitetural, os artefatos produzidos nem sempre consistem em uma lista de discrepncias, por exemplo. Procuramos ento identificar nas abordagens quais so os artefatos que eles necessitam e produzem. Isso feito pois a partir deles possvel identificar, entre outras coisas, o contexto em que essas abordagens de avaliao arquitetural podem ser aplicadas.

31

3.4.2.5 Caractersticas de qualidade avaliadas A arquitetura de um software criada com base nos seus requisitos, principalmente os requisitos de qualidade. Devido a importncia desse tipo de requisito para o projeto arquitetural, um dos principais objetivos de uma abordagem de avaliao arquitetural identificar defeitos relacionados ao no atendimento de requisitos de qualidade. Devido existncia de vrios tipos de requisitos de qualidade, procuramos identificar atravs desse critrio, que caractersticas de qualidade cada abordagem de avaliao procura avaliar e por conseqncia identificar defeitos nos tipos de requisitos relacionados. 3.4.2.6 Momento da avaliao A qualidade de um software no pode ser imposta depois que o produto estiver finalizado, portanto a sua qualidade deve ser um aspecto que deve ser tratado simultaneamente execuo do processo de desenvolvimento do software (CLEMENTS et al., 2002). Visto que a arquitetura auxilia no desenvolvimento do software, importante que ela tenha a sua qualidade avaliada antes do incio da implementao do software. Alm disso, principalmente para a reengenharia de sistemas legados, interessante tambm que uma avaliao arquitetural seja realizada visando caracterizar a arquitetura desse sistema. Portanto, visando entender melhor cada abordagem, procuramos caracterizar cada abordagem a partir do momento em que ela executada. Sendo assim, definimos que uma avaliao arquitetural pode ser realizada nos seguintes momentos: Durante construo Avaliaes podem ser realizadas durante a execuo do processo de especificao da arquitetura, quando nem todos os elementos arquiteturais tiverem sido gerados. Nesse caso, a avaliao auxilia na construo do restante dos elementos. Aps construo Aps a finalizao da construo da arquitetura, a arquitetura de um software pode ser avaliada com os seguintes propsitos: (1) avaliar o atendimento a todos os requisitos de qualidade, para que se possa decidir se o processo de especificao deve ser finalizado ou no; ou (2) entender a arquitetura de um sistema j desenvolvido durante a realizao de uma reengenharia ou manuteno do software.

32

3.4.2.7 Avaliao da abordagem De acordo com (BABAR et al., 2004), desenvolver uma abordagem de avaliao baseada em experincias pessoais, observaes gerais, heursticas de especialistas, ou boas prticas publicadas no uma boa forma de garantir a viabilidade e a utilidade da abordagem. O criador de uma abordagem pode avaliar o seu trabalho atravs de diversas tcnicas experimentais disponibilizadas no domnio de Engenharia de Software. Atravs desse critrio, procuramos ento identificar se cada abordagem foi realmente avaliada. Estamos interessados em identificar principalmente que tipo de estudos foi realizado. No contexto dessa caracterizao, classificamos a forma como uma abordagem foi avaliada atravs da seguinte taxonomia: Estudo experimental Um estudo experimental um possvel tipo de estudo que pode ser usado para avaliar uma abordagem de avaliao arquitetural. Esse tipo de estudo consiste em observar de forma sistemtica o efeito de uma tecnologia em aplicaes prticas (CIOLKOWSKI et al., 2002). Ele se caracteriza principalmente pela formalizao empregada na sua execuo e possui como principal objetivo obter respostas a questionamentos especficos que foram formalizados antes de sua realizao. O mais comum tipo de estudo experimental o estudo de caso. No nosso contexto, consideramos estudos de caso um estudo experimental que tem como objetivo aplicar a tecnologia avaliada em um contexto de desenvolvimento de software real (SHULL et al., 2001). Prova de conceito Estudo que foi realizado visando mostrar a viabilidade de se aplicar a abordagem de avaliao proposta. Geralmente, esse tipo de estudo realizado atravs da descrio do funcionamento da abordagem em um determinado exemplo, que pode ser real ou no. A principal caracterstica desse tipo de estudo que o autor no utilizou conceitos relacionados experimentao na sua conduo, o que inviabiliza tirar concluses sobre a real viabilidade e funcionalidade da abordagem avaliada. Vale lembrar que vrios autores classificam os estudos visando avaliar a abordagem que propem como estudos de caso. Contudo, na grande maioria das vezes nos os consideramos como simples provas de conceito devido falta de

33

formalizao durante a realizao do estudo e que necessria a um estudo experimental (KITCHENHAM et al., 2002). 3.4.2.8 Apoio ferramental Uma avaliao arquitetural se caracteriza por apresentar algumas dificuldades, devido ao intenso conhecimento envolvido e presena de atividades tediosas e repetitivas, que dificultam a sua adoo em ambientes industriais. Atravs de um apoio ferramental, o verdadeiro potencial de uma avaliao poderia ser mais explorado e o seu uso em um contexto industrial poderia se tornar vivel. Portanto, atravs desse critrio, pretendemos identificar qual abordagem possui esse apoio ferramental.

3.4.3 Caracterizao das abordagens

Visando facilitar a descrio e caracterizao dessas abordagens, as seguintes medidas foram tomadas: O nome dado s abordagens nem sempre corresponde a seus nomes oficiais. Em alguns casos, criamos a sigla com base no nome definido pelos criadores para denomin-las. A ordem de descrio de cada abordagem foi definida com base na data da publicao dos trabalhos que a originaram. Visando descrever e caracterizar cada abordagem, utilizamos principalmente as informaes contidas nas publicaes selecionadas pela reviso. O smbolo (-) ser utilizado visando indicar quando no foi possvel identificar como a abordagem caracterizada atende a determinado critrio. Para algumas abordagens de avaliao, a reviso sistemtica identificou publicaes que a descrevem mas no as publicaes que a originaram. Nesses casos, essas publicaes que originaram a abordagem no foram identificadas na tabela de caracterizao. A seguir as abordagens so identificadas e caracterizadas de acordo com o framework que definimos. 3.4.3.1 SAR SAR (Software Architecture Review) (ERICKSON et al., 1993) uma abordagem de avaliao que objetiva fornecer um melhor entendimento do software sobre a evoluo de novos servios, a robustez do sistema, e o gerenciamento de falhas. Portanto, essa abordagem avalia a arquitetura sobre a perspectiva dos atributos de evoluo e confiabilidade.

34

Essa avaliao feita atravs de checklists que so desenvolvidos a partir das caractersticas do sistema e dos critrios que se deseja avaliar. Contudo, visto que eles so orientados ao produto, novos checklist devem ser gerados a cada nova avaliao.
Tabela 3.5 Caracterizao da abordagem SAR Caractersticas da abordagem Tipo de informao: Descrio usando diferentes perspectivas de representao (vises arquiteturais) Tipo de arquitetura Nvel de abstrao: Arquitetura inicial Tipo de tcnica Questionamento (checklists) 1. Desenvolver checklists orientados ao produto a ser analisado com informaes sobre os critrios necessrios para realizar a reviso. 2. Averiguar junto aos projetistas da arquitetura as Processo seguido caractersticas atuais do sistema atravs da execuo dos checklists; 3. Caracterizar a informao obtida em (2); 4. Relatar os resultados da reviso aos envolvidos; Artefatos requeridos Artefatos produzidos Confiabilidade Caractersticas de qualidade Modificabilidade Momento da avaliao Aps construo Apoio ferramental Avaliao Artigos selecionados pela reviso que permitiram identificar essa abordagem (ERICKSON et al.)

3.4.3.2 SAAM SAAM (Software Architecture Analysis Method) (KAZMAN et al., 1994) uma abordagem que avalia a arquitetura de um software atravs da anlise de como os requisitos de modificabilidade, de variabilidade e funcionais foram atendidos. Essa abordagem pode ser utilizada para avaliar a qualidade de uma arquitetura ou ento para identificar, dentro de um conjunto de arquiteturas, a mais adequada para atender ao problema proposto. O desenvolvimento dessa abordagem foi motivado pela observao de que os arquitetos regularmente fazem afirmaes que no conseguem provar. SAAM tenta avaliar essas afirmaes atravs do uso de cenrios que colocam em evidncia os atributos de qualidade relacionados com a afirmativa que se deseja provar. Com isso, a principal funo do SAAM indicar os locais onde a arquitetura falha em se adequar aos requisitos de qualidade evidenciados. SAAM uma abordagem de avaliao arquitetural bastante utilizada. Alm disso, ela usada tambm como base para a criao de novas abordagens de avaliao.

35

Quando utilizada para criar outras abordagens, algumas caractersticas de SAAM so modificadas visando adapt-la s caractersticas do novo contexto em que ser utilizada. Essas modificaes podem ser mnimas (LASSING et al., 1999b; GRAAF et al., 2005) ou no. Algumas das abordagens que utilizam SAAM como base foram identificadas na reviso sistemtica e tambm esto descritas nesse captulo.
Tabela 3.6 Caracterizao da abordagem SAAM Caractersticas da abordagem Tipo de informao: Descrio usando diferentes perspectivas de representao (vises arquiteturais) Rastreabilidade com os requisitos funcionais Nvel de abstrao: Arquitetura inicial Questionamento (cenrio) 1. Especificao, por parte dos stakeholders, do conjunto de cenrios que representam as mudanas por eles desejadas; 2. Inspeo dos cenrios especificados previamente priorizados; 3. Mapeamento dos cenrios para a representao da arquitetura; 4. Identificao das discrepncias que foram evidenciadas atravs do mapeamento. Descrio do problema Documento de requisitos Representao da arquitetura Lista com os requisitos priorizados Lista de discrepncias Mapeamento da representao arquitetural aos atributos de qualidade, permitindo o rastreamento entre os elementos arquiteturais e os requisitos que eles implementam Modificabilidade

Tipo de arquitetura

Tipo de tcnica

Processo seguido

Artefatos requeridos

Artefatos produzidos Caractersticas de qualidade Momento da avaliao

Aps construo SAAMTool Apoio ferramental Intelligent Tool Based-Agent for Software Architecture Evaluation Avaliao Prova de conceito Artigos selecionados pela reviso que permitiram identificar essa abordagem (KAZMAN et al., 1994) (KAZMAN e BASS, 2002) (ABOWD, 1995) (LAND, 2002) (ABOWD et al., 1996) (BAHSOON e EMMERICH, 2003) (EICKELMANN e RICHARDSON, (SVAHNBERG, 2003) 1996) (BABAR e GORTON, 2004) (KAZMAN et al., 1996) (BABAR et al., 2004) (MCCRICKARD e ABOWD, 1996) (BENARIF et al., 2004) (LASSING et al., 1999b) (FOLMER e BOSCH, 2005) (GANNOD e LUTZ, 2000) (GRAAF et al., 2005) (CLEMENTS et al., 2002) (DOBRICA e NIEMELA, 2002)

3.4.3.3 SAA SAA (System Architecture Analysis) (GLOGER et al., 1996) uma abordagem de avaliao arquitetural desenvolvida pela Siemens e que busca otimizar a arquitetura

36

do software para atender tanto estratgias de mercado definidas pela organizao quanto aspectos tecnolgicos desejveis. Essa abordagem baseada em quatro princpios essenciais: (1) Anlise da arquitetura atravs de avaliaes das decises de projeto; (2) Avaliaes realizadas levando em considerao a aplicao a ser desenvolvida, assim como as expectativas do mercado; (3) Identificao de potenciais de otimizao atravs da comparao entre solues (arquiteturas) alternativas; (4) Avaliao objetiva realizada por diversas equipes de stakeholders. A SAA objetiva avaliar se a arquitetura uma boa arquitetura. Para SAA, uma boa arquitetura consiste em uma arquitetura criada a partir de decises de projeto que foram tomadas visando implementar os requisitos definidos para o sistema.
Tabela 3.7 Caracterizao da abordagem SAA Caractersticas da abordagem Tipo de informao: Tipo de arquitetura Nvel de abstrao: Arquitetura inicial Tipo de tcnica Questionamento (Questionrio) 1. Identificao dos critrios de avaliao: Consiste na priorizao dos principais requisitos que sero usados para avaliar a arquitetura; 2. Identificao das caractersticas do sistema e de solues alternativas: Consiste em usar uma equipe de experts para identificar as principais caractersticas do sistema e definir arquiteturas alternativas para essas caractersticas. Essas solues (arquiteturas alternativas) so utilizadas como comparativo com a arquitetura avaliada; Processo seguido 3. Avaliao sistemtica das diferentes arquiteturas: Consiste em avaliar as arquiteturas (proposta + alternativa) levando em considerao principalmente quo bem cada uma implementa os requisitos; 4. Avaliao dos resultados obtidos: Procura-se identificar os pontos fortes e fracos de cada arquitetura que sero usados como base para gerar recomendaes para otimizar a arquitetura final. Documento de requisitos Artefatos requeridos Representao arquitetural Recomendaes descrevendo o que deve ser feito para Artefatos produzidos otimizar a arquitetura final Desempenho Caractersticas de Usabilidade qualidade Escalabilidade Momento da avaliao Aps construo Apoio ferramental Avaliao Prova de conceito Artigos selecionados pela reviso que permitiram identificar essa abordagem (GLOGER et al., 1996)

3.4.3.4 SAAMER SAAMER (Software Architecture Analysis Method for Evolution and Reusability) (LUNG et al., 1997) uma abordagem que objetiva caracterizar a arquitetura de um

37

software com o objetivo de projetar a sua evoluo e reutilizao em projetos do mesmo domnio. Por ter sido construda com base na abordagem SAAM, SAAMER aplicou vrios conceitos de SAAM no contexto de reutilizao e evoluo de software. Uma das principais caractersticas dessa abordagem de ter sido baseada em um framework de obteno de informao e de anlise arquitetural para a sua concepo. Devido a essa caracterstica, essa abordagem possui um processo de avaliao organizado, cientfico e repetvel. Entre as alteraes feitas na abordagem base (SAAM), destaca-se a incluso de novos artefatos requeridos, como o modelo do domnio, que pode auxiliar na comparao entre arquiteturas candidatas, por exemplo.
Tabela 3.8 Caracterizao da abordagem SAAMER Caractersticas da abordagem Tipo de informao: Descrio usando diferentes perspectivas de representao (vises arquiteturais) Tipo de arquitetura Rastreabilidade com os requisitos funcionais Nvel de abstrao: Arquitetura inicial Tipo de tcnica Questionamento (cenrio) Processo seguido Descrio do problema Documento de requisitos Artefatos requeridos Modelo do domnio Representao da arquitetura Artefatos produzidos Reusabilidade Caractersticas de Modificabilidade qualidade Manutenibilidade Momento da avaliao Aps construo Apoio ferramental Avaliao Artigos selecionados pela reviso que permitiram identificar essa abordagem (DOBRICA e NIEMELA, 2002) (FOLMER e BOSCH, 2005) (BABAR et al., 2004)

3.4.3.5 PASA PASA (Performance Assesment of Software Architecture) (WILLIAMS e SMITH, 1998) uma abordagem que busca avaliar se os requisitos de desempenho especificados foram atendidos na arquitetura. Aps a sua realizao, com base nas discrepncias de desempenho identificadas, possvel ao arquiteto tomar os seguintes tipos de decises visando resolver essas discrepncias: aliviar os requisitos de desempenho, omitir a funcionalidade, aumentar o poder do hardware ou aplicar outros estilos arquiteturais para atender a esses requisitos.

38

Tabela 3.9 Caracterizao da abordagem PASA Caractersticas da abordagem Tipo de informao: Descrio usando diferentes perspectivas de representao (vises arquiteturais) Nvel de abstrao: Arquitetura inicial Questionamento (cenrio) 1. Identificar os casos de uso crticos que so importantes para o bom funcionamento do sistema 2. Definir os cenrios de desempenho para cada caso de uso crtico 3. Avaliar a arquitetura atravs dos cenrios Casos de uso do sistema Representao da arquitetura Lista de discrepncias Desempenho

Tipo de arquitetura Tipo de tcnica Processo seguido

Artefatos requeridos

Artefatos produzidos Caractersticas de qualidade Momento da avaliao Aps construo Apoio ferramental Avaliao Artigos selecionados pela reviso que permitiram identificar essa abordagem (BAHSOON e EMMERICH, 2003) (BABAR e GORTON, 2004)

3.4.3.6 SAEM SAEM (Software Architecture Evaluation Model) (DUENAS et al., 1998) uma abordagem que procura organizar e utilizar mtricas de qualidade, agrupadas a partir da aplicao do GQM (BASILI et al., 1994), para avaliar modelos arquiteturais.
Tabela 3.10 Caracterizao da abordagem SAEM Caractersticas da abordagem Tipo de informao: Descrio usando ADL (Architectural Description Language) Nvel de abstrao: Arquitetura inicial Medio (GQM) Mltiplos

Tipo de arquitetura

Tipo de tcnica Processo seguido Artefatos requeridos Artefatos produzidos Caractersticas de qualidade Momento da avaliao Durante e Aps construo Apoio ferramental Avaliao Artigos selecionados pela reviso que permitiram identificar essa abordagem (DOBRICA e NIEMELA, 2002)

3.4.3.7 SBAR SBAR (Scenario-Based Architecture Reengineering) (BENGTSSON e BOSCH, 1998) uma abordagem de reengenharia arquitetural que utiliza diversos tipos de tcnicas de avaliao como forma de identificar se o processo de reengenharia j

39

pode ser finalizado. Essa abordagem se divide principalmente em trs grandes etapas: (1) incorporao dos novos requisitos funcionais na arquitetura (se houver); (2) caracterizao arquitetural. A etapa (2) consiste no uso de tcnicas de avaliao para verificar se os atributos de qualidade do sistema se adequam aos requisitos. Caso isso no ocorra, transformaes arquiteturais so realizadas, seguido de uma nova caracterizao, at que os resultados esperados sejam obtidos. Para cada atributo de qualidade que ser avaliado, SBAR permite a escolha de uma tcnica de avaliao: cenrio, simulao, modelagem matemtica ou experincia baseada em raciocnio. Em relao s atividades para a avaliao arquitetural, a abordagem requer que cenrios sejam especificados para cada requisito de qualidade. Em seguida, esses cenrios so analisados de acordo com a tcnica de avaliao escolhida e os resultados so interpretados.
Tabela 3.11 Caracterizao da abordagem SBAR Caractersticas da abordagem Tipo de arquitetura Tipo de tcnica Processo seguido Artefatos requeridos Hbrido 1. Especificao de cenrios 2. Avaliao usando a tcnica escolhida 3. Interpretao dos resultados 4. Evoluo da arquitetura (se necessrio) Documento de requisitos Representao da arquitetura Mltiplos

dos

atributos

de

qualidade

especificados;

(3)

transformao

Artefatos produzidos Caractersticas de qualidade Momento da avaliao Aps construo Apoio ferramental Avaliao Prova de conceito Artigos selecionados pela reviso que permitiram identificar essa abordagem (DOBRICA e NIEMELA, 2002) (BABAR et al., 2004)

Uma caracterstica interessante da avaliao realizada por essa abordagem que ela pode ser executada de forma completa ou de forma estatstica. A principal diferena que a forma estatstica busca identificar um conjunto de cenrios representativos que no precisem cobrir todos os possveis casos. Isso foi uma soluo encontrada para o problema relacionada ao custo de se gerar o mximo de cenrios possveis.

40

3.4.3.8 ALPSM ALPSM (Architecture-Level Prediction of Software Maintenance) (BENGTSSON e BOSCH, 1999) uma abordagem que busca analisar a manutenibilidade de um sistema de software atravs da observao do impacto de cenrios nvel arquitetural. Para isso, essa abordagem utiliza um perfil de manuteno, ou seja, um conjunto de cenrios que representam as tarefas de manuteno referente principalmente s adaptaes ou melhorias que se deseja realizar na arquitetura avaliada. Com o uso desse perfil, a arquitetura avaliada atravs de uma anlise de impacto das mudanas necessrias para se adequar aos cenrios, assim como a grandeza dos esforos de manuteno necessria para cada cenrio avaliado. A principal diferena entre o ALPSM e o SAAM est na forma que os cenrios so definidos. Os cenrios do SAAM utilizam as perspectivas de todos os stakeholders disponveis, contudo os do ALPSM utiliza somente as do especialista do domnio.
Tabela 3.12 Caracterizao da abordagem ALPSM Caractersticas da abordagem Tipo de arquitetura Tipo de tcnica Questionamento (cenrio) 1. Identificar os diferentes tipos de tarefas de manuteno que sero realizadas na arquitetura. 2. Criar os cenrios que refletem essas manutenes; 3. Priorizar os cenrios. Feita com base na probabilidade do cenrio ocorrer durante o tempo de vida do sistema 4. Estimar o tamanho dos componentes envolvidos na alterao. Estimativa feita para determinar o esforo necessrio para realizar a modificao; 5. Simular a execuo dos cenrios visando identificar o impacto das mudanas na arquitetura; 6. Calcular o esforo de manuteno. Documento de requisitos Representao da arquitetura Histrico com dados de manuteno da arquitetura avaliada Perfil definido de manuteno Previso do esforo mdio das tarefas de manuteno Manutenibilidade

Processo seguido

Artefatos requeridos Artefatos produzidos

Caractersticas de qualidade Momento da avaliao Aps construo Apoio ferramental Avaliao Prova de conceito Artigos selecionados pela reviso que permitiram identificar essa abordagem (LASSING et al., 1999b) (BABAR et al., 2004) (DOBRICA e NIEMELA, 2002)

3.4.3.9 ESAAMI Quando aplicada ao contexto de reutilizao, engenharia de domnio ou linha de produtos, a importncia da arquitetura ainda maior que quando aplicada em

41

sistemas tradicionais. Isso ocorre por ela ser especificada com o principal objetivo de ser amplamente reutilizada e se tornar a base de diferentes produtos de software. Portanto, discrepncias arquiteturais no contexto de reutilizao devem ser evitadas e uma das ferramentas para diminuir a incidncia desse tipo de defeitos atravs da aplicao de mtodos de anlise. Com esse objetivo, foi definida em (MOLTER, 1999) a abordagem ESAMI (Extending SAAM by Integration in the Domain) com o objetivo de integrar o mtodo SAAM em processos de desenvolvimento de domnios especficos ou baseados em reutilizao. A principal modificao introduzida pelo ESAAMI metodologia utilizada pelo SAAM est na reutilizao do conhecimento de domnio, durante a avaliao, atravs de templates de anlise.
Tabela 3.13 Caracterizao da abordagem ESAAMI Caractersticas da abordagem Tipo de informao: Descrio usando diferentes perspectivas de representao (vises arquiteturais) Tipo de arquitetura Nvel de abstrao: Tipo de tcnica Questionamento (cenrio) Processo seguido Descrio do problema Documento de requisitos Artefatos requeridos Representao arquitetural Template de anlise focado nas caractersticas da arquitetura avaliada Artefatos produzidos Modificabilidade Caractersticas de Variabilidade qualidade Reusabilidade Momento da avaliao Aps construo Apoio ferramental Avaliao Artigos selecionados pela reviso que permitiram identificar essa abordagem (DOBRICA e NIEMELA, 2002) (BABAR et al., 2004)

3.4.3.10 SAAF A abordagem SAAF (Software Architecture Analysis of Flexibility) (LASSING et al., 1999a) similar abordagem SAAM, contudo ela disponibiliza suporte para a identificao e utilizao de cenrios que possuem uma alta complexidade. Essa abordagem parte do princpio que a complexidade dos cenrios o mais importante fator de risco durante a avaliao de uma arquitetura, e ento ela busca direcionar a forma de lidar com os cenrios mais complexos.

42

Tabela 3.14 Caracterizao da abordagem SAAF Caractersticas da abordagem Tipo de informao: Nvel de abstrao: Arquitetura Refinada Questionamento (cenrio) Representao arquitetural Categorias de cenrios complexos Instrumentos de medida Adaptabilidade

Tipo de arquitetura Tipo de tcnica Processo seguido Artefatos requeridos

Artefatos produzidos Caractersticas de qualidade Momento da avaliao Aps construo Apoio ferramental Avaliao Prova de conceito Artigos selecionados pela reviso que permitiram identificar essa abordagem (DOBRICA e NIEMELA, 2002) (BABAR et al., 2004)

3.4.3.11 ATAM O principal objetivo da abordagem ATAM (Architecture Trade-off Analysis Method) (KAZMAN et al., 2000) prover uma forma de entender a adequao de uma arquitetura com respeito a vrios atributos de qualidade, levando em considerao a existncia de trade-offs entre esses atributos. Trade-off entre duas caractersticas de qualidade ocorre quando se tenta maximizar uma das caractersticas e, por conseqncia, a segunda automaticamente minimizada. Como exemplo, existe o trade-off entre desempenho e reutilizao: se tentarmos obter o mximo de desempenho estaremos automaticamente diminuindo a capacidade em reutilizar a arquitetura visto que teremos que adapt-la a um contexto especfico; e vice-versa. ATAM foi idealizada com base em trs pontos: (a) os conceitos e o conhecimento obtido com estudos sobre estilos arquiteturais; (b) as comunidades que se dedicam ao estudo dos diferentes tipos de atributos de qualidade que podem ser utilizados em uma avaliao arquitetural; (c) os conceitos e lies aprendidas com o mtodo SAAM, o predecessor ao mtodo ATAM. Sendo assim, ATAM se concentra principalmente em identificar as abordagens e os estilos arquiteturais utilizados na especificao da arquitetura analisada, pois eles representam a forma que o arquiteto utilizou para adequar a arquitetura aos requisitos de qualidade especificados.

43

Tabela 3.15 Caracterizao da abordagem ATAM Caractersticas da abordagem Tipo de informao: Descrio usando diferentes perspectivas de representao (vises arquiteturais) Nvel de abstrao: Arquitetura refinada Hbrido Macro-atividades: 1. Apresentao: atividades responsveis por relatar os objetivos do negcio e a descrio da arquitetura; 2. Investigao e anlise: atividades responsveis por realizar um levantamento dos requisitos de qualidade que devem ser atendidos e das abordagens arquiteturais utilizadas para atend-los. 3. Teste: atividades responsveis por checar os resultados encontrados na anlise usando cenrios criados por outros participantes. 4. Exposio: atividades responsveis por apresentar os resultados obtidos Representao arquitetural Objetivos do negcio Perspectivas dos stakeholders descritas atravs dos cenrios Documento de requisitos Requisitos de qualidade priorizados Identificao das abordagens arquiteturais utilizadas Mapeamento requisitos com as abordagens Lista de riscos (discrepncias) Trade-off points Mltiplos

Tipo de arquitetura Tipo de tcnica

Processo seguido

Artefatos requeridos

Artefatos produzidos Caractersticas de qualidade Momento da avaliao

Durante ou aps construo Intelligent Tool Based-Agent for Software Architecture Evaluation Apoio ferramental ArchE Avaliao Prova de conceito Artigos selecionados pela reviso que permitiram identificar essa abordagem (CARRIERE et al., 1999) (SMITH e MERSON, 2003) (IVEZIC et al., 2000) (SVAHNBERG, 2003) (KAZMAN et al., 2000) (BABAR e GORTON, 2004) (LEE et al., 2001) (BABAR et al., 2004) (CLEMENTS et al., 2002) (BENARIF et al., 2004) (DOBRICA e NIEMELA, 2002) (FOLMER e BOSCH, 2005) (KAZMAN e BASS, 2002) (LEE e CHOI, 2005) (BAHSOON e EMMERICH, 2003)

3.4.3.12 FAV A abordagem FAV (Framewok for Software Architecture Verification) (LICHTNER et al., 2000) consiste em um framework utilizado para analisar representaes arquiteturais atravs do uso de prova formal. Para isso, a arquitetura, que deve estar descrita atravs de uma ADL, traduzida para uma representao matemtica alternativa. A partir dessa representao, feita uma converso para PVS (Prototype Verification System), lgica de alta ordem, que permite a verificao automtica da arquitetura.

44

Tabela 3.16 Caracterizao da abordagem FAV Caractersticas da abordagem Tipo de informao: Descrio usando ADL (Architectural Description Language) Descrio usando diferentes perspectivas de representao (vises arquiteturais) Nvel de abstrao: Medio Restries arquiteturais (Requisitos de qualidade) Representao arquitetural -

Tipo de arquitetura

Tipo de tcnica Processo seguido Artefatos requeridos

Artefatos produzidos Caractersticas de qualidade Momento da avaliao Aps construo Apoio ferramental Avaliao Prova de conceito Artigos selecionados pela reviso que permitiram identificar essa abordagem (LICHTNER et al., 2000)

3.4.3.13 SAASS A abordagem SAASS (Software Architecture Analysis based on Statechart Semantics) (DIAS e VIEIRA, 2000) busca desenvolver e avaliar sistemas baseados em arquitetura e componentes. Essa avaliao feita com base em informaes obtidas da representao arquitetural do sistema adicionada de informaes relacionadas ao comportamento de seus componentes.
Tabela 3.17 Caracterizao da abordagem SAASS Caractersticas da abordagem Tipo de informao: Descrio usando ADL (Architectural Description Language) Descrio usando diferentes perspectivas de representao (vises arquiteturais) Tipo de arquitetura Nvel de abstrao: Arquitetura inicial Arquitetura refinada Tipo de tcnica Medio (Simulao e Model Checking) Processo seguido Artefatos requeridos Representao arquitetural Artefatos produzidos Estrutural Caractersticas de qualidade Restries relacionadas ao estilo arquitetural C2 Momento da avaliao Durante e aps construo Apoio ferramental Argus-I Avaliao Prova de conceito Artigos selecionados pela reviso que permitiram identificar essa abordagem (DIAS e VIEIRA, 2000)

45

Para isso, a arquitetura deve implementar o estilo arquitetural C2 (MEDVIDOVIC et al., 1999) e estar descrita atravs de uma ADL associada. Aps isso, feito o uso do ambiente Argus-I que permite a avaliao dessa arquitetura atravs de diversas tcnicas, como Model checking e Simulao. 3.4.3.14 ARID A abordagem ARID (Active Reviews for Intermediate Designs) (CLEMENTS, 2000) avalia a consistncia de uma parte da arquitetura com respeito s demais partes j definidas. Para isso, ela combina a filosofia de revises ativas com abordagens de avaliaes baseados em cenrios, como o SAAM. Com essa combinao, ARID utiliza: (a) os revisores ativos das ADR, que asseguram principalmente resposta de alta qualidade sobre as questes realizadas durante a avaliao e (b) a abordagem de definir os cenrios a serem analisados pelos stakeholders. Essa abordagem, por revisar partes da arquitetura antes do final de sua inteira construo, permite obter indcios sobre a viabilidade de construo do artefato como um todo, alm de possibilitar a descoberta de erros, inconsistncias e elementos inadequados. Para a sua execuo, os revisores definem um conjunto de cenrios, cuja ordem de execuo definida por votao dos envolvidos.
Tabela 3.18 Caracterizao da abordagem ARID Caractersticas da abordagem Tipo de informao: Nvel de abstrao: Arquitetura refinado Questionamento (cenrio) Representao arquitetural incompleta Documento de requisitos Adequao da parte da arquitetura avaliada com os requisitos

Tipo de arquitetura Tipo de tcnica Processo seguido Artefatos requeridos

Artefatos produzidos Caractersticas de qualidade Momento da avaliao Durante construo Apoio ferramental Avaliao Artigos selecionados pela reviso que permitiram identificar essa abordagem (CLEMENTS et al., 2002) (BABAR et al., 2004) (BAHSOON e EMMERICH, 2003)

46

3.4.3.15 Qasar A abordagem Qasar (Quality Attribute-oriented Software ARchitecture) (BOSCH, 2000) consiste em uma abordagem de projeto arquitetural que durante a sua execuo realiza avaliaes arquiteturais. Essas avaliaes so realizadas quando os arquitetos acreditam que atenderam a todos os requisitos. Portanto, o seu resultado permite identificar o que falta a ser feito ou ento finalizar o processo de construo.
Tabela 3.19 Caracterizao da abordagem Qasar Caractersticas da abordagem Tipo de informao: Nvel de abstrao: Arquitetura inicial Hbrida 1. Elicitao dos requisitos com os stakeholders 2. Projeto inicial da arquitetura visando atender somente os requisitos funcionais 3. Avaliao preliminar visando identificar se os requisitos de qualidade esto atendidos. Essa avaliao pode utilizar tanto tcnicas qualitativas (cenrios) quanto quantitativas (simulao, modelagem matemtica) 4. Anlise dos resultados com relao aos resultados esperados. Se resultado for positivo o processo finalizado; 5. Caso contrrio feita uma reengenharia e novas avaliaes at que todos os requisitos estejam atendidos Documento de requisitos Representao arquitetural Mltiplos

Tipo de arquitetura Tipo de tcnica

Processo seguido

Artefatos requeridos

Artefatos produzidos Caractersticas de qualidade Momento da avaliao Aps construo Apoio ferramental Avaliao Prova de conceito Artigos selecionados pela reviso que permitiram identificar essa abordagem (FOLMER e BOSCH, 2005)

3.4.3.16 Avaliao baseada em Model Checking Mesmo com a exatido e os benefcios comprovados das tcnicas formais de avaliao, essas tcnicas so pouco usadas na avaliao de arquiteturas devido grande complexidade envolvida na sua aplicao. Tendo em vista essas dificuldades, a ferramenta ARCADE (BARBER et al., 2001) foi desenvolvida com o papel de automatizar a aplicao dessas tcnicas mais complexas em avaliaes arquiteturais. A ARCADE (Architecture Analysis Dynamic Environment) combina principalmente simulao e Model checking para auxiliar o arquiteto na caracterizao de um software a partir de sua arquitetura. Atravs dessa caracterizao, essa ferramenta avalia principalmente a confiabilidade da arquitetura do software.

47

Tabela 3.20 Caracterizao da abordagem Avaliao baseada em Model Checking Caractersticas da abordagem Tipo de informao: Descrio usando diferentes perspectivas de representao (vises arquiteturais) Nvel de abstrao: Arquitetura inicial Medio (Simulao e Model Checking) 1. Detectar as violaes das propriedades atravs da aplicao de model checking; 2. Corrigir a especificao; 3. Reaplicar a tcnica at que nenhuma outra violao seja identificada. Documento de Requisitos Representao arquitetural Log de violaes Adequao da arquitetura avaliada com os requisitos

Tipo de arquitetura Tipo de tcnica Processo seguido

Artefatos requeridos

Artefatos produzidos Caractersticas de qualidade Momento da avaliao Aps construo Apoio ferramental ARCADE Avaliao Artigos selecionados pela reviso que permitiram identificar essa abordagem (BARBER et al., 2001)

3.4.3.17 CBAM A abordagem CBAM (Cost Benefit Analysis Method) (KAZMAN et al., 2001) uma extenso da ATAM que visa realizar a modelagem econmica do software atravs da anlise de sua arquitetura. Conceitualmente, o CBAM continua a partir do ponto em que o ATAM acaba. Nessa abordagem, os custos e benefcios so analisados em relao aos atributos de qualidade do sistema, ou seja, objetiva-se saber como questes referentes ao custo e benefcio influenciam ou so influenciados pelos atributos de qualidade do sistema. Para isso, feita a adio de dimenses monetrias (custo e benefcio) ao resultado do ATAM como um atributo adicional de trade-off.
Tabela 3.21 Caracterizao da abordagem CBAM Caractersticas da abordagem Tipo de informao: Descrio usando diferentes perspectivas de representao (vises arquiteturais) Nvel de abstrao: Arquitetura refinada Hbrido 1. Escolher os cenrios e estratgias arquiteturais; 2. Caracterizar os benefcios obtidos pelos atributos de qualidade; 3. Quantificar os benefcios oferecidos pelas estratgias arquiteturais escolhidas; 4. Quantificar os custos e implicaes no cronograma; 5. Calcular o que for desejvel e possvel de ser feito; Realizar a tomada de deciso.

Tipo de arquitetura Tipo de tcnica

Processo seguido

48

Representao arquitetural Objetivos do negcio Artefatos requeridos Perspectivas dos stakeholders descritas atravs dos cenrios Documento de requisitos Requisitos de qualidade priorizados Identificao das abordagens arquiteturais utilizadas Mapeamento requisitos com as abordagens Artefatos produzidos Lista de riscos (discrepncias) Trade-off points Estimativas de custos e benefcios referente cada abordagem utilizada Mltiplos (qualidade) Caractersticas de qualidade Custo e benefcios (financeiro) Momento da avaliao Aps construo Apoio ferramental Avaliao Artigos selecionados pela reviso que permitiram identificar essa abordagem (BAHSOON e EMMERICH, 2003) (LEE e CHOI, 2005)

Os resultados obtidos pelo CBAM podem auxiliar os stakeholders em determinar o conjunto de estratgias arquiteturais que abordam os cenrios de qualidade com maior benefcio e menor custo. 3.4.3.18 ALMA O mtodo ALMA (Architecture-Level Modificability Analysis) (BENGTSSON, 2002) utiliza cenrios para avaliar a arquitetura sob a perspectiva das caractersticas de modificabilidade. Este mtodo foi criado a partir da unio do ALPSM e SAAF formando, de acordo com os seus criadores, o mtodo unificado de anlise de modificaes arquiteturais. Por assegurar a validao somente de um atributo de qualidade, seus criadores aconselham a utiliz-la em conjunto com um ou mais mtodos que suprem a necessidade de se avaliar os atributos de qualidade restantes (BENGTSSON et al., 2004).
Tabela 3.22 Caracterizao da abordagem ALMA Caractersticas da abordagem Tipo de informao: Descrio usando diferentes perspectivas de representao (vises arquiteturais) Nvel de abstrao: Arquitetura inicial Questionamento (cenrio) 1. Determinar o objetivo da anlise. 2. Descrever as partes relevantes da arquitetura que sero analisadas. 3. Elicitar os cenrios de evoluo ou alterao relevantes. 4. Avaliar os cenrios na arquitetura. 5. Interpretar os resultados. Documento de requisitos

Tipo de arquitetura Tipo de tcnica

Processo seguido

Artefatos requeridos

49

Representao da arquitetura Log de manuteno Artefatos produzidos Caractersticas de Modificabilidade qualidade Momento da avaliao Aps construo Apoio ferramental Avaliao Prova de conceito Artigos selecionados pela reviso que permitiram identificar essa abordagem (SVAHNBERG, 2003) (FOLMER e BOSCH, 2005) (BABAR e GORTON, 2004) (BABAR et al., 2004)

3.4.3.19 Metodologia de avaliao baseada no modelo 4+1 Essa abordagem (CHOI e YEOM, 2002) tem como objetivo avaliar arquiteturas de software que utilizam a abordagem 4+1 (KRUCHTEN, 1995) e a UML como formas de documentao e representao arquitetural. Atravs de questionamentos, busca avaliar a coerncia entre as vises e as decises tomadas para atender aos requisitos. O resultado final dessa avaliao no ajuda somente na identificao dos riscos em um projeto, mas tambm muito til na compreenso da adequao da arquitetura aos seus atributos de qualidade.
Tabela 3.23 Caracterizao da abordagem Metodologia de avaliao baseada no modelo 4+1 Caractersticas da abordagem Tipo de informao: Descrio usando diferentes perspectivas de representao (vises arquiteturais) Tipo de arquitetura Rastreabilidade com os requisitos Nvel de abstrao: Arquitetura inicial Tipo de tcnica Questionamento (cenrio) 1. Os passos referentes avaliao arquitetural so: 2. Identificar os sub-projetos arquiteturais atravs dos requisitos funcionais. 3. Determinar o conjunto de estilos arquiteturais utilizados para Processo seguido a especificao da arquitetura avaliada. 4. Determinar o raciocnio para cada estilo arquitetural. 5. Identificar as relaes entre os estilos arquiteturais identificados. Documento de requisitos Artefatos requeridos Representao arquitetural Lista com as decises arquiteturais que influenciaram o Artefatos produzidos atendimento aos requisitos de qualidade Caractersticas de Mltiplos qualidade Momento da avaliao Durante construo Apoio ferramental Avaliao Prova de conceito Artigos selecionados pela reviso que permitiram identificar essa abordagem (CHOI e YEOM, 2002)

50

3.4.3.20 Simulao usando RAPIDE Em (PEREZ et al., 2002), uma abordagem de avaliao foi definida atravs do uso de simulao para avaliar o desempenho de arquiteturas representadas atravs da ADL RAPIDE. Durante a execuo dessa abordagem, a simulao feita atravs do envio de mensagens para cada componente que faz parte da arquitetura visando analisar como eles reagem ao tipo e quantidade de mensagens enviadas (avaliando principalmente a funcionalidade e o desempenho do componente).
Tabela 3.24 Caracterizao da abordagem Simulao usando RAPIDE Caractersticas da abordagem Tipo de informao: Descrio usando diferentes perspectivas de representao (vises arquiteturais) Tipo de arquitetura Nvel de abstrao: Arquitetura refinada Tipo de tcnica Medio (simulao) Processo seguido Artefatos requeridos Artefatos produzidos Usabilidade Funcionalidade Caractersticas de qualidade Confiana Manutenibilidade Momento da avaliao Aps construo Apoio ferramental RAPTOR Avaliao Prova de conceito Artigos selecionados pela reviso que permitiram identificar essa abordagem (PEREZ et al., 2002)

3.4.3.21 OASE A abordagem OASE foi descrita em (JAZAYERI, 2002). Ela usada para avaliar a arquitetura sob a perspectiva de caractersticas de estabilidade. Para isso, essa abordagem utiliza mtricas simples (tamanho do mdulo, nmero de mdulos alterados e nmero de mdulos adicionados em diferentes releases) para sumarizar o padro de evoluo do software entre as diferentes releases.
Tabela 3.25 Caracterizao da abordagem OASE Caractersticas da abordagem Tipo de informao: Nvel de abstrao: Arquitetura refinada Medio -

Tipo de arquitetura Tipo de tcnica Processo seguido Artefatos requeridos Artefatos produzidos

51

Estabilidade Caractersticas de qualidade Evoluo Momento da avaliao Aps construo Apoio ferramental Avaliao Prova de conceito Artigos selecionados pela reviso que permitiram identificar essa abordagem (BAHSOON e EMMERICH, 2003)

3.4.3.22 (SVAHNBERG et al., 2002) A abordagem descrita em (SVAHNBERG et al., 2002) consiste em uma abordagem utilizada para entender as vantagens e desvantagens de diferentes estruturas arquiteturais em relao aos requisitos de qualidade especificados. Sendo assim, a avaliao realizada por essa abordagem permite identificar a arquitetura mais adequada a ser usada entre as alternativas disponveis. Durante essa avaliao, cada revisor realiza uma comparao das diferentes arquiteturas com relao aos atributos de qualidade e tambm uma comparao dos diferentes atributos de qualidade com relao s arquiteturas disponveis. Essas comparaes produzem uma lista de valores para cada arquitetura e aquela que possuir os maiores valores a mais adequada.
Tabela 3.26 Caracterizao da abordagem (SVAHNBERG et al., 2002) Caractersticas da abordagem Tipo de informao: Descrio usando diferentes perspectivas de representao (vises arquiteturais) Nvel de abstrao: Arquitetura inicial Arquitetura refinada Medio 1. Identificar principais requisitos de qualidade e potenciais arquiteturas 2. Criar o framework de comparao 3. Anlise dos frameworks obtidos 4. Identificao da arquitetura mais adequada Documento de requisitos Representao arquitetural Documento apontando as diferenas entre cada arquitetura candidata em relao aos requisitos priorizados Mltiplos

Tipo de arquitetura

Tipo de tcnica Processo seguido

Artefatos requeridos Artefatos produzidos

Caractersticas de qualidade Momento da avaliao Durante construo Apoio ferramental Avaliao Prova de conceito Artigos selecionados pela reviso que permitiram identificar essa abordagem (SVAHNBERG, 2003)

3.4.3.23 ArchOptions ArchOptions (BAHSOON, 2003) uma abordagem para avaliar arquiteturas sob a perspectiva de caractersticas de estabilidade utilizando insights sobre possveis

52

alteraes e sobre como a arquitetura ir se comportar em relao a essas modificaes. Assim como CBAM, essa abordagem tambm leva em considerao durante o processo de avaliao questes econmicas que influenciam o projeto da arquitetura.
Tabela 3.27 Caracterizao da abordagem ArchOptions Caractersticas da abordagem Tipo de informao: Tipo de arquitetura Nvel de abstrao: Arquitetura refinada Tipo de tcnica Medio Processo seguido Artefatos requeridos Artefatos produzidos Estabilidade Caractersticas de qualidade Evoluo Momento da avaliao Aps construo Apoio ferramental Avaliao Artigos selecionados pela reviso que permitiram identificar essa abordagem (BAHSOON e EMMERICH, 2003)

3.4.3.24 ASAAM Usualmente, a qualidade de uma arquitetura avaliada atravs da anlise do impacto de cenrios pr-definidos sobre os elementos da arquitetura. Uma possvel forma de adequar essa arquitetura aos cenrios especificados atravs do uso de refactoring.
Tabela 3.28 Caracterizao da abordagem ASAAM Caractersticas da abordagem Tipo de informao: Descrio usando diferentes perspectivas de representao (vises arquiteturais) Nvel de abstrao: Arquitetura refinada Questionamento (cenrio) 1. Desenvolvimento da arquitetura candidata; 2. Especificao dos cenrios a partir das perspectivas de vrios stakeholders; 3. Avaliao individual de cada cenrio e identificao dos aspectos arquiteturais. 4. Execuo desses cenrios para possibilitar a classificao dos componentes. 5. Refactoring da arquitetura baseado nos resultados obtidos pela execuo dos cenrios. Documento de requisitos Representao das arquiteturas candidatas Descrio do problema Modificabilidade

Tipo de arquitetura Tipo de tcnica

Processo seguido

Artefatos requeridos Artefatos produzidos Caractersticas de qualidade

53

Momento da avaliao Apoio ferramental Avaliao Prova de conceito Artigos selecionados pela reviso que permitiram identificar essa abordagem (TEKINERDOGAN, 2004)

Variabilidade Atendimento aos requisitos funcionais Aps construo

Contudo, observado que nem sempre os componentes podem ser coesos devido presena de propriedades similares executadas por vrios componentes. 3.4.3.25 Avaliao de desempenho proposto por (PURHONEN, 2004) Durante o desenvolvimento de software embarcado, deve ser levado em considerao vrios tipos de requisitos especficos a esse domnio, como restries de tempo, de recursos e alto desempenho. Alm do mais, a mesma arquitetura deve ser facilmente adaptada devido a constante evoluo do hardware onde o software embarcado.
Tabela 3.29 Caracterizao da abordagem Avaliao de desempenho proposto por (PURHONEN, 2004) Caractersticas da abordagem Tipo de informao: Descrio usando diferentes perspectivas de representao (vises arquiteturais) Tipo de arquitetura Nvel de abstrao: Arquitetura inicial Tipo de tcnica Hbrido 1. Determinar o escopo da avaliao. 2. Descrever a arquitetura atravs do uso de vises arquiteturais 3. Analisar o impacto. O impacto dos atributos de qualidade, nesse caso o de desempenho, analisado com o auxlio de Processo seguido tcnicas especficas desse domnio (RMA, abordagens baseadas em filas, etc.). 4. Analisar os resultados. Os resultados obtidos so comparados com os objetivos determinados durante a anlise de requisitos. Refinamentos so propostos ao final dessa anlise. Documento de requisitos Artefatos requeridos Representao arquitetural Refinamentos na arquitetura para atender os requisitos de Artefatos produzidos desempenho Caractersticas de Desempenho qualidade Momento da avaliao Durante construo Apoio ferramental Avaliao Prova de conceito Artigos selecionados pela reviso que permitiram identificar essa abordagem (PURHONEN, 2004)

Levando em considerao essas caractersticas, um abordagem de avaliao descrita em (PURHONEN, 2004) foi definida visando avaliar o desempenho de

54

arquiteturas de sistemas embarcados. Esse mtodo utiliza cenrios, simulaes e outras tcnicas especficas esse domnio durante a avaliao. 3.4.3.26 Saluta Saluta (Scenario based Architecture Level UsabiliTy Assessment) (FOLMER, 2005) consiste em uma abordagem que busca avaliar como as decises arquiteturais tomadas visando construir uma determinada arquitetura afetam os requisitos de usabilidade. Para isso, Saluta utiliza o framework SAU (FOLMER et al., 2003) para identificar o suporte da arquitetura para a usabilidade.
Tabela 3.30 Caracterizao da abordagem Saluta Caractersticas da abordagem Tipo de informao: Descrio usando diferentes perspectivas de representao (vises arquiteturais) Nvel de abstrao: Arquitetura inicial Questionamento (cenrio) 1. Criao de um perfil de utilizao que descreve a usabilidade requerida. Com a criao desse perfil, cenrios so definidos; 2. Anlise da arquitetura visando identificar a usabilidade provida pela arquitetura; 3. Avaliao da usabilidade provida em relao aos cenrios visando identificar se a implementao da usabilidade 4. Interpretao dos resultados Representao arquitetural Usabilidade

Tipo de arquitetura Tipo de tcnica

Processo seguido

Artefatos requeridos Artefatos produzidos Caractersticas de qualidade Momento da avaliao Durante construo Apoio ferramental Avaliao Prova de conceito Artigos selecionados pela reviso que permitiram identificar essa abordagem (FOLMER e BOSCH, 2005)

3.4.3.27 ASAV A ASAV (AT&Ts Software Architecture Validation) (MARANZANO et al., 2005) uma abordagem que avalia arquiteturas de software atravs de reunies presenciais. Atravs de um checklist, os revisores se preparam para essa reunio. Esse checklist composto por questes que os arquitetos devem considerar durante essa avaliao.
Tabela 3.31 Caracterizao da abordagem ASAV Caractersticas da abordagem Tipo de arquitetura Tipo de tcnica Processo seguido Questionamento (Checklist) 1. Definir se determinado projeto precisa ter usa arquitetura

55

Artefatos requeridos

Artefatos produzidos Caractersticas de qualidade Momento da avaliao Durante construo Apoio ferramental Avaliao Prova de conceito Artigos selecionados pela reviso que permitiram identificar essa abordagem (MARANZANO et al.)

avaliada. 2. Preparao da avaliao: escolha da equipe, definio da documentao necessria, definio do problema 3. Reunio de reviso: apresentao do problema por parte da equipe de arquitetos 4. Follow-up: os revisores informam os problema encontrados Descrio do problema Entrevista com arquitetos Documento de Requisitos Representao arquitetural Documento descrevendo os principais problemas encontrados Mltiplos

3.5 Anlise das abordagens

Aps identificar e caracterizar as abordagens de avaliao, dois tipos de anlise foram realizadas: uma anlise dos estudos que descrevem as abordagens e uma outra sobre as abordagens de avaliao em si. Essas anlises foram realizadas principalmente para fornecer informaes que permitam entender como as abordagens existentes avaliam os documentos arquiteturais.

3.5.1 Anlise das publicaes selecionadas

Devido ao fato de que, em alguns casos, as publicaes que descrevem determinadas abordagens no so as publicaes que a originaram, foi limitada a obteno de informaes suficientes para possibilitar uma caracterizao mais completa dessas abordagens. Mesmo assim, com a anlise das informaes contida nessas publicaes, conseguimos fazer constataes que permitem identificar algumas caractersticas do estado da arte em avaliao arquitetural. A primeira constatao foi a falta de estudos experimentais para avaliar as abordagens de avaliao arquitetural identificadas. Ns procuramos por esse tipo de informao nas publicaes devido aos possveis ganhos que podem ser obtidos ao utilizar experimentao. Entre esses ganhos podemos citar, por exemplo, uma compreenso mais rigorosa da abordagem de avaliao e de sua aplicao. Os estudos conduzidos com as abordagens identificadas consistem basicamente em provas de conceito que demonstram como elas so aplicadas e as melhorias que podem ser obtidas quando usadas para avaliar documentos arquiteturais (KAZMAN et al., 1994; LEE et al., 2003). Contudo, em nenhum artigo foi descrito algum estudo que,

56

por exemplo, realize uma comparao entre a abordagem descrita e uma abordagem ad-hoc ou qualquer outra que tambm objetive avaliar documentos arquiteturais. A segunda constatao foi a existncia de revises bibliogrficas cujo objetivo, assim como o nosso, de identificar abordagens de avaliao arquitetural (CLEMENTS et al., 2002; DOBRICA e NIEMELA, 2002; BAHSOON e EMMERICH, 2003; BABAR et al., 2004). Contudo, essas revises no descreveram os critrios de seleo que utilizaram para selecionar essas abordagens e nem como a busca por essas abordagens foi realizada, impedindo que sejam repetidas por outros pesquisadores. Entre essas revises, duas se destacaram (DOBRICA e NIEMELA, 2002; BABAR et al., 2004) por terem definido um framework para caracterizar as abordagens de avaliao que identificaram. Usamos alguns dados por elas identificados para auxiliar na caracterizao das abordagens que encontramos em comum. Um fato marcante em algumas dessas revises que seus autores as realizaram principalmente com o objetivo de identificar motivaes que justifiquem a abordagem de avaliao por eles criada. Todavia, quando uma reviso conduzida com esse propsito, como em (BAHSOON e EMMERICH, 2003), normalmente as abordagens identificadas so somente aquelas que apresentam as limitaes que o pesquisador pretende tratar atravs da sua nova abordagem. Isso ocorre pelo fato do pesquisador acabar utilizando, talvez de forma inconsciente, a limitao que ele pretende tratar como principal critrio de seleo durante a busca por trabalhos relacionados, inserindo assim vis nos resultados obtidos pela reviso, pois ele pode ter deixado de identificar abordagens que j propuseram uma soluo para a limitao que ele deseja solucionar. A terceira constatao observada foi o nmero de mtodos identificados pela reviso descrita nesse trabalho em relao s revises existentes. A reviso sistemtica identificou 27 abordagens enquanto as revises ad-hoc (CLEMENTS et al., 2002; DOBRICA e NIEMELA, 2002; BAHSOON e EMMERICH, 2003; BABAR et al., 2004) no identificaram mais que 8 mtodos cada.

3.5.2 Anlise das abordagens de avaliao identificadas

O principal objetivo das abordagens identificadas a melhoria da qualidade da arquitetura de software atravs da anlise dos documentos que a descreve. Visto que estudos experimentais tm demonstrado que a utilizao de tcnicas de inspeo beneficia a melhoria da qualidade de artefatos de software (SHULL et al., 2000; CONRADI et al., 2003), visando um melhor entendimento optamos por

57

caracterizar as abordagens identificadas a partir de um conjunto de critrios normalmente presentes em tcnicas de inspeo de software. Um dos motivos pela realizao dessa reviso sistemtica a necessidade que o nosso grupo de pesquisa e as empresas de software tm por uma abordagem de avaliao arquitetural que seja extensvel, simples de ser aplicada, genrica e adaptvel. Portanto, ao realizar essa caracterizao e analisar os conceitos relacionados a cada abordagem identificada, procuramos identificar as abordagens que possussem essas caractersticas. Contudo, no foi possvel encontrar nenhuma abordagem que atendesse a todas essas caractersticas simultaneamente. Observamos que isso ocorre devido ocorrncia de quatro problemas principais (Tabela 3.32)5 presentes nessas abordagens: grande subjetividade das abordagens, elevado custo de aplicao, dificuldades para avaliar simultaneamente o atendimento a vrias caractersticas de qualidade e contexto limitado para a aplicao de algumas abordagens. No contexto desse trabalho, se entende por subjetividade a falta de uma definio exata e completa de que caractersticas arquiteturais sero avaliadas durante a execuo de uma abordagem de avaliao arquitetural. Para identificar a existncia de subjetividade em alguma abordagem, avaliamos principalmente o tipo de tcnica usada durante a avaliao. Portanto, ao analisar as abordagens identificadas, uma elevada subjetividade foi observada principalmente nas abordagens que utilizam cenrios como tcnica de avaliao. Esse problema causado pela incapacidade dos stakeholders em identificar e gerar todos os possveis cenrios que deveriam ser usados na avaliao. Para conseguir gerar os cenrios, esses stakeholders se vem obrigados a utilizar subjetividade e criatividade como abordagens para definir o conjunto de cenrios de avaliao (DOBRICA e NIEMELA, 2002). Alm disso, durante a especificao dos cenrios, os stakeholders inconscientemente podem definir cenrios que no avaliam a arquitetura de forma completa, devido a sua familiarizao com a arquitetura, provocando distoro nos resultados da avaliao. O custo de aplicao de uma abordagem de avaliao est relacionado ao tipo de atividades que devem ser realizadas, quantidade de pessoas que devem participar do processo e ao uso de ferramentas complexas, como simulao e mtodos formais, que necessitam de especialistas em diversas reas de conhecimento. Devido a isso, uma abordagem pode requerer uma grande quantidade de tempo e investimento financeiro para que possa ser executada, o que pode inviabilizar a sua aplicao em
5

As informaes obtidas em relao ao mtodo SAEM no foram suficientes para caracteriz-lo, portanto no o inclumos na Tabela 3.32.

58

um contexto industrial. Para identificar esse custo de aplicao, analisamos principalmente os tipos de papis, o processo executado e o tipo de tcnica usada durante a avaliao.
Tabela 3.32- Mapeamento entre as abordagens de avaliao e problemas identificados durante a anlise Mtodo de Avaliao SAR SAAM SAA SAAMER PASA SBAR ALPSM ESAAMI SAAF ATAM FAV SAASS ARID QASAR Model Checking CBAM ALMA 4+1 Simulao usando RAPIDE OASE SVAHNBERG ArchOptions ASAAM AD SALUTA ASAV Grande subjetividade X X X X X X X X X Elevado custo de aplicao X X X X No avalia mltiplas caractersticas de qualidade X X X X X X X X X Contexto de aplicao limitado X

X X X X

X X X X X X X X X X X X X X X X X X X

X X

X X X X X X X X

X X X X

Sendo assim, aps a anlise, percebemos que o elevado custo de aplicao observado em determinadas abordagens est relacionado principalmente ao fato de terem sido desenvolvidas em um contexto acadmico ou ento para projetos de grande porte, que geralmente possuem alta disponibilidade de recursos. Com isso, somente um pequeno nmero de empresas consegue aplicar de forma correta essas avaliaes (LATTANZE, 2005). Outra caracterstica importante a uma abordagem de avaliao a quantidade de caractersticas de qualidade presentes na arquitetura que avalia. DOBRICA e NIEMELA (2002) sugerem que uma avaliao arquitetural deve ser feita sob a perspectiva de mltiplos requisitos, permitindo uma melhor compreenso dos pontos fracos e fortes dos produtos de software atuais.

59

Portanto, ao analisar as abordagens em relao a essa caracterstica, foi levado em considerao se as abordagens foram construdas especificamente para avaliar um conjunto restrito de caractersticas ou se elas podem ser configuradas para avaliar as caractersticas desejadas. Sendo assim, foi identificado que vrias abordagens avaliam a arquitetura e seus respectivos documentos sob a perspectiva de um nmero restrito de caractersticas de qualidade. Algum desses mtodos (GLOGER et al., 1996; BENGTSSON et al., 2004), conscientes dessa limitao, aconselham a execuo de outro mtodo de avaliao em paralelo. Mas tal abordagem poderia aumentar ainda mais o custo da avaliao. O quarto problema identificado est relacionado falta de consenso na comunidade em relao tanto s definies bsicas quanto forma de representar uma arquitetura (BUSCHMANN et al., 1996; CLEMENTS et al., 2004). Para identificar se determinada abordagem tem sua aplicao limitada a determinados contextos, procuramos determinar que peculiaridades relacionadas principalmente ao tipo de arquitetura avaliada, tcnica de avaliao realizada ou ento aos artefatos requeridos, que implicavam na necessidade de um tipo especfico de conhecimento, para que abordagem fosse executada, o que impossibilitaria a sua aplicao em determinados contextos Ao realizarmos esse tipo de anlise, identificamos que algumas abordagens de avaliao so baseadas em abordagens especficas de documentao ou utilizam tcnicas de avaliao dominadas somente pelo grupo que propem a abordagem de avaliao, o que dificulta a sua aplicao em diferentes projetos ou contextos.

3.6 Concluso
Ao longo deste captulo, foram identificadas e caracterizadas as principais abordagens de avaliao arquitetural descritas na literatura tcnica. Utilizamos como ferramenta para realizar essa reviso bibliogrfica o conceito de reviso sistemtica. O uso de reviso sistemtica, principalmente a sua etapa de planejamento, permitiu uma definio mais completa do que deveria ser procurado na literatura tcnica, facilitando a busca e aprimorando o foco para a leitura e anlise das publicaes coletadas. Aps a realizao dessa reviso, algumas evidncias em relao ao uso de reviso sistemtica na rea de Engenharia de Software puderam ser observadas. Uma dessas evidncias so os benefcios obtidos ao se utilizar reviso sistemtica como ferramenta para levantamento bibliogrfico, visto a grande quantidade de mtodos que foram identificados em comparao com as revises ad-hoc j realizadas.

60

Contudo, para a que a aplicao de revises sistemticas possa obter resultados mais completos preciso (1) que seja definida uma taxonomia padro para ser utilizada na classificao das publicaes escritas na rea, permitindo assim a obteno de resultados mais completos quando se usar a busca por palavras chaves, e (2) que as bibliotecas digitais disponibilizem ferramentas, como mquinas de busca, que permitam a recuperao de estudos de forma confivel, evitando assim problemas como os ocorridos com a mquina de busca da ACM. A principal contribuio dessa reviso consiste em uma identificao mais completa e uma caracterizao das abordagens de avaliao arquitetural existentes, em relao s revises ad-hoc encontradas na literatura. A partir da caracterizao que foi realizada foi possvel identificar os benefcios e limitaes desses mtodos. Uma das principais motivaes para a realizao dessa busca por abordagens de avaliao arquitetural foi a necessidade de identificar uma abordagem facilmente adaptvel, extensvel, genrica o suficiente para ser aplicada em diferentes contextos e simples de ser realizada, o que facilitaria a sua aplicao em um contexto industrial, por exemplo. Contudo, com base nas informaes e limitaes observadas nas abordagens identificadas pela reviso sistemtica constatamos que no existe ainda uma abordagem que atenda a todos esses requisitos (Tabela 3.33).
Tabela 3.33 - Mapeamento entre as caractersticas procuradas e as limitaes que as inviabilizam Caracterstica Requerida Adaptvel Extensvel Genrica Simples

Limitaes que a inviabiliza Contexto de aplicao limitado Contexto de aplicao limitado Elevado custo de aplicao No avalia mltiplas caractersticas de qualidade Contexto de aplicao limitado Grande subjetividade Elevado custo de aplicao

Com isso, devido ao conhecimento acumulado pela equipe aps a realizao dessa reviso, nos vimos motivados a desenvolver uma abordagem de avaliao arquitetural que possusse tais caractersticas. Esta abordagem para inspeo foi chamada de ArqCheck e consiste em um checklist configurvel que objetiva a avaliao principalmente das caractersticas de qualidade representadas nos documentos arquiteturais em relao aos requisitos especificados para o seu projeto (BARCELOS e TRAVASSOS, 2005). Este checklist foi criado com base na hiptese de que (1) o tipo de conhecimento utilizado pelo arquiteto de software na especificao de arquiteturas de software e que foi usado como base para especificar os itens de questionamento e (2) a configurao do checklist de acordo com as caractersticas que se deseja avaliar, permitem

61

identificar defeitos em documentos arquiteturais e minimizar as limitaes observadas nas abordagens de avaliao arquitetural existentes, o que nos fornece uma abordagem de avaliao arquitetural prxima as nossas expectativas. A proposta em questo descrita no captulo seguinte, intitulado Inspeo de documentos arquiteturais.

62

Captulo 4 Inspeo de documentos arquiteturais

Neste captulo, apresentamos ArqCheck, a abordagem proposta para inspecionar documentos arquiteturais atravs do uso de checklist. Justificamos tambm o uso dos conceitos que compem a abordagem e o papel de cada um deles na avaliao arquitetural.

4.1 Introduo
O custo de corrigir defeitos em artefatos de software aumenta exponencialmente com o decorrer do processo de desenvolvimento (BOEHM, 1981; BOEHM e BASILI, 2001). Portanto, iniciativas para avaliar a qualidade desses artefatos devem ser realizadas no sentido de identificar e corrigir os defeitos to logo sejam introduzidos. O documento arquitetural, responsvel por descrever a arquitetura de um software, um desses artefatos que deve ter a sua qualidade avaliada. Ao avali-lo, procura-se principalmente melhorar a qualidade da arquitetura nele descrita. A avaliao desse documento justificada pela sua importncia para os stakeholders, uma vez que ele utilizado em diversos momentos no processo de desenvolvimento do software. Contudo, como avaliar se a arquitetura descrita no documento arquitetural atende aos requisitos especificados? Como vimos no Captulo 3, existem diversas abordagens de avaliao descritas na literatura que possuem como foco principal avaliar a arquitetura, principalmente em relao forma como ela atende aos requisitos. Essas abordagens utilizam diferentes tcnicas de avaliao e j foram aplicadas em diferentes contextos. Todavia, algumas limitaes presentes nessas abordagens dificultam a sua aplicao, principalmente em ambiente industrial (LATTANZE, 2005). Estudos tm mostrado que abordagens baseadas em reviso de artefatos de software, quando utilizadas visando melhoria da sua qualidade, apresentam bons resultados e esto sendo cada vez mais usados no contexto industrial (SHULL et al., 2000; CONRADI et al., 2003). Isso ocorre devido sua eficincia e ao seu baixo custo para identificar defeitos, reduzindo assim o retrabalho, o custo total do projeto e melhorando a qualidade dos produtos (LAITENBERGER e ATKINSON, 1999; AURUM et al., 2002). Entre as abordagens de reviso, a inspeo de software uma das que se destaca devido aos resultados que se tem obtido com a sua aplicao (SHULL et al., 2000; CONRADI et al., 2003). Portanto, visto esses resultados obtidos, essa

dissertao prope uma abordagem para inspeo de documentos arquiteturais (BARCELOS e TRAVASSOS, 2006a) Nas sees a seguir, justificamos a deciso em utilizar inspeo como abordagem para revisar documentos arquiteturais, mostramos como pretendemos minimizar as limitaes presentes nas abordagens identificadas pela reviso sistemtica e descrevemos a abordagem proposta.

4.2 Inspecionando documentos arquiteturais

Qualidade de software consiste na conformidade do produto final e dos artefatos de software intermedirios (1) aos requisitos que tenham sido especificados, (2) aos padres de desenvolvimento que tenham sido claramente documentados e (3) s caractersticas implicitamente esperadas de todo software a ser desenvolvido (PRESSMAN, 2001). Entre as atividades que podem ser utilizadas para verificar a qualidade de um software se encontram (MELO et al., 2001): Revises de software; Testes; Padres e procedimentos formais; Controle de mudanas; Mtricas de software; Procedimentos para coleo e disseminao de informaes. Reviso de software, de acordo com o padro 1028 da IEEE (1988), visa avaliar produtos de software por uma equipe tecnicamente qualificada com o intuito de identificar discrepncias. Diversos mtodos tm sido propostos para a realizao de revises tcnicas e esses mtodos se diferenciam principalmente pelo seu grau de formalidade (WEINBERG e FREEDMAN, 1984). Inspeo de software, por exemplo, um mtodo de reviso de software que se destaca por ser rigoroso, formal e executado com o objetivo de examinar artefatos de software (FAGAN, 1976). Uma outra maneira de detectar defeitos em artefatos atravs de testes. No entanto, a aplicao de testes descobre apenas sintomas de problemas e, desta forma, pode necessitar da realizao de um trabalho refinado e custoso para detectar os defeitos que causaram o sintoma da falha (MELO et al., 2001). BASILI e SELBY (1987) afirmam que inspees descobrem defeitos que podem no ser descobertos nos testes. BOEHM e BASILI (2001) ressaltam ainda que inspees e testes capturam diferentes tipos de defeitos em diferentes momentos do

64

processo de desenvolvimento de software. Portanto, interessante aplicar tanto inspees quanto testes para detectar defeitos em artefatos de software. Contudo, o teste de um software consiste na anlise dinmica do produto, ou seja, na execuo do produto com o objetivo de verificar a presena de falhas (NETO e TRAVASSOS, 2005). Visto que no contexto dessa dissertao objetivamos avaliar documentos arquiteturais, abordagens de testes no podem ser aplicadas a esse tipo de artefato por ele no ser passvel de execuo. A aplicao de uma abordagem de reviso de software se mostra uma opo mais adequada para a avaliao da qualidade de documentos arquiteturais. Entre as abordagens de avaliao identificadas pela reviso sistemtica (Captulo 3), a maioria das abordagens que objetivam garantir a qualidade atravs da reviso da arquitetura (tcnicas de questionamento) utiliza a execuo de cenrios como tcnica de reviso. Cenrios so usados por permitirem uma fcil representao das caractersticas que se deseja avaliar (ABOWD et al., 1997). Contudo, as abordagens que utilizam essa tcnica como base apresentam problemas que dificultam a sua aplicao (BARCELOS e TRAVASSOS, 2006b). Sendo assim, optamos por definir uma abordagem usando conceitos relacionados a inspeo de software para avaliar os documentos arquiteturais.

4.2.1 Benefcios ao aplicar inspeo de software

Diferente de outras abordagens de reviso, inspeo de software se caracteriza por visar principalmente a deteco de defeitos nos artefatos avaliados (YOUNESSI, 2002) e por poder ser utilizada na reviso dos diferentes artefatos criados durante o processo de desenvolvimento (Figura 4.1).

Figura 4.1 - Inspees de software nos diferentes artefatos. Adaptado de (KALINOWSKI, 2004)

Quando inspeo aplicada em artefatos de software visando a melhoria da qualidade possvel capturar at 60% dos defeitos contidos nesses artefatos (BOEHM e BASILI, 2001). Alm disso, a aplicao de inspeo de software permite beneficiar o projeto sobre outras perspectivas, como por exemplo, diminuio de esforo de desenvolvimento.

65

De acordo com BOEHM e BASILI (2001), o esforo gasto por organizaes de software com retrabalho varia em mdia entre 40% e 50% do esforo total do desenvolvimento de um projeto. A aplicao de inspeo de software permite que esse esforo seja reduzido em mdia para 10% a 20% (JONES, 1991). Esta reduo no retrabalho maior se a inspeo for aplicada, entre outros, sobre o artefato que representa a arquitetura do software (BOEHM et al., 2000). Portanto, visto os benefcios que se obtm ao utilizar inspeo de software e o fato de que a reviso do documento arquitetural contribui para a melhoria da qualidade do software (BABAR et al., 2004), desenvolvemos como trabalho de mestrado uma abordagem para inspecionar documento arquiteturais que permita a identificao e correo de defeitos no incio da fase de projeto, momento esse onde os custos de correo so menores.

4.3 ArqCheck: Uma abordagem para inspeo de documento arquitetural

De acordo com LAITENBERGER e DEBAUD (1998), do ponto de vista tcnico, uma abordagem para inspeo de software formada pelo tipo do artefato de software a ser avaliado, pela forma como a equipe de profissionais ser definida para realizar a inspeo, pela tcnica de avaliao utilizada e pelo processo de execuo seguido. Portanto, uma possvel forma para se definir uma abordagem para inspeo seria atravs da realizao das seguintes tarefas: Determinar o artefato de software que deve ser avaliado e o tipo de informao que o compem; Identificar os perfis das pessoas que devem ser envolvidas nessa inspeo, assim como o papel que desempenham durante a avaliao; Definir os tipos de defeitos que a abordagem busca identificar; Definir a tcnica de avaliao utilizada para identificar os defeitos no artefato a ser avaliado, e; Especificar o processo composto pelas atividades a serem executadas para atingir o objetivo final da avaliao. A seguir, descrevemos essas tarefas com o objetivo de caracterizar os elementos que compem ArqCheck e descrever como pretendemos minimizar as limitaes encontradas nas demais abordagens de avaliao arquitetural.

66

4.3.1 Artefato de software avaliado

ArqCheck objetiva a melhoria da qualidade da arquitetura de um software atravs da identificao de defeitos no seu documento arquitetural. Segundo TRAVASSOS et al. (1999), artefatos criados durante o ciclo de desenvolvimento de um software devem possuir as seguintes caractersticas: (1) devem refletir de forma completa o sistema especificado atravs dos requisitos, (2) no devem conter restries desnecessrias oriundas de outros domnios que influenciam a soluo, e (3) no devem conter inconsistncias ou ambigidades para que seja possvel aos usurios do artefato utilizar a arquitetura de forma correta. Sendo assim, a abordagem proposta busca identificar defeitos arquiteturais. Esse tipo de defeito est relacionado falta dessas caractersticas em um documento arquitetural. Visto que no existe uma padronizao para se representar arquitetura de software, a abordagem proposta procura avaliar o documento independentemente da forma como as informaes so representadas. Contudo, para que ArqCheck possa ser aplicada necessrio que o documento arquitetural contenha algumas informaes, como as definidas pelas recomendaes da IEEE 1471 que abordam a descrio arquitetural de sistemas de software (IEEE, 2000). Sendo assim, definimos os seguintes requisitos para o documento arquitetural para que ArqCheck possa ser aplicada na sua avaliao: Identificar os elementos arquiteturais que compem a soluo a ser construda, assim como a forma que esses elementos esto organizados; Descrever o papel de cada elemento dentro da arquitetura; Identificar como cada requisito relevante a nvel arquitetural est sendo atendido atravs da arquitetura documentada. Essa identificao pode ser feita principalmente atravs do rastreamento de que requisito est sendo atendido e quais requisitos justificam a criao de determinado elemento arquitetural; Representar o software atravs de diferentes perspectivas, como por exemplo, atravs do uso de vises arquiteturais. Uma possvel abordagem que poderia ser usada para descrever essas informaes seria compor o documento com um conjunto de modelos, que representam as diferentes vises arquiteturais. Cada viso seria composta por diagramas grficos que representariam os elementos arquiteturais sob determinada perspectiva. Esse documento possuiria tambm um catlogo de elementos arquiteturais cujo objetivo descrever o papel de cada elemento representado nos diferentes modelos e identificar a rastreabilidade entre os elementos arquiteturais e os requisitos

67

especificados. Na Figura 4.2, est representado um exemplo de como seria um documento com essas caractersticas.

Figura 4.2 - Exemplo de documentao de uma viso arquitetural

4.3.2 Papis e perfis da equipe de inspeo

Em uma inspeo de software existem principalmente trs papis que so necessrios para que a reviso ocorra (KALINOWSKI, 2004): Moderador o responsvel por gerenciar a execuo do processo. Ele quem deve garantir que os procedimentos estipulados esto sendo seguidos e que cada membro da equipe assume as responsabilidades de seu papel. FAGAN (1976) afirma que o moderador o elemento chave para o sucesso de uma inspeo. Para preservar a objetividade e aumentar a integridade da inspeo, normalmente vantajoso utilizar um moderador de um outro projeto. O moderador deve gerenciar a equipe de inspeo e oferecer liderana. Para obteno de melhores resultados, este moderador deveria receber um treinamento especfico, ainda que este seja breve. Autor do documento uma pessoa ou grupo de pessoas que produziu o artefato em inspeo e responsvel por corrigir os defeitos na fase de correo.

68

Inspetor o responsvel por identificar os defeitos no artefato. Em relao ao nmero de moderadores e de autores de documento, a realizao

de uma inspeo de software geralmente necessita somente de uma pessoa alocada para cada um desses papis. Em relao aos inspetores, visto que so os responsveis por identificar os defeitos no artefato, em teoria quanto mais pessoas fossem alocadas para esse papel maior seria o nmero de defeitos identificados. Contudo, o custo da avaliao poderia se tornar muito alto e, alm disso, estudos experimentais mostram que no a quantidade de inspetores que importa mas sim a utilizao de profissionais com diferentes nveis de experincia (SVAHNBERG, 2003) e a realizao da reviso a partir de diferentes perspectivas que influenciam no tipo e na quantidade de defeitos encontrados (SHULL, 1998). No contexto de avaliao arquitetural, JOHANSSON et al. (2001) identificou que os stakeholders tendem a ter diferentes opinies em relao importncia dos requisitos de qualidade, o que influenciaria na identificao de defeitos durante uma avaliao arquitetural. Essa diferena de opinies um dos principais fatores que influencia na definio do nmero de stakeholders a serem utilizados em avaliaes arquiteturais. Abordagens baseadas em execuo de cenrios, por exemplo, aconselham o uso de diferentes stakeholders na construo de cenrios, o que pode tornar a abordagem muito custosa dependendo do tamanho do sistema a ser avaliado. Em relao otimizao de equipes para avaliaes arquiteturais, estudos experimentais j foram realizados visando identificar o perfil e a quantidade de pessoas que deveriam ser utilizadas na reviso desse tipo de artefato (SVAHNBERG, 2003). Os resultados obtidos pelo estudo descrito em (SVAHNBERG, 2003), por exemplo, indica que possvel otimizar o nmero de inspetores em uma avaliao arquitetural identificando as pessoas que concordam entre si como, por exemplo arquitetos com nveis de experincia similar, por tenderem a encontrar os mesmos defeitos. A substituio de um deles por pessoas com outros perfis poderia permitir a obteno de um maior nmero de defeitos. Uma possibilidade seria alocar para a reviso um gerente, visto que por possuir um conhecimento sobre a maioria dos projetos da empresa, ele consegue identificar defeitos relacionados a trade-offs a nvel organizacional. Em relao abordagem proposta nessa dissertao, nenhum estudo foi realizado visando analisar a quantidade de inspetores e de perfis a ser adotada para que a abordagem seja executada de forma eficiente. Contudo, com base nas observaes relatadas por (SVAHNBERG, 2003) e visto que a abordagem proposta avalia o

69

documento arquitetural sob duas perspectivas, consistncia de informaes e corretude em relao ao atendimento dos requisitos, a alocao dos inspetores para realizar a abordagem proposta feita atravs da diviso dos indivduos disponveis em grupos, que ficariam responsveis pela avaliao de uma dessas perspectivas. O grupo que avaliaria a consistncia das informaes poderia ser formado por indivduos com pouco conhecimento em projeto arquitetural mas que fazem uso de documentos arquiteturais em suas atividades. Um exemplo de tipos de profissionais que possuem essas caractersticas so os desenvolvedores, os projetistas ou at mesmo gerentes de projeto. O grupo responsvel por avaliar o atendimento aos requisitos poderia ser formado por pessoas com alguma experincia em projeto arquitetural, pois teriam mais facilidade em identificar se os requisitos foram corretamente atendidos. Um exemplo de um profissional com esse perfil seria o arquiteto de software da organizao. Contudo, para que ocorra uma avaliao objetiva do documento, seria interessante que esse arquiteto no tenha participado na construo da arquitetura avaliada. Alm disso, para cada grupo, o ideal seria alocar dois profissionais que possuam diferentes pontos de vista, o que aumentaria a eficincia da inspeo (TRAVASSOS et al., 2002). Contudo, visto que nem todas as organizaes dispem de profissionais suficientes para serem alocadas para esse tipo de tarefa, alocar um indivduo para cada perspectiva permite a identificao de grande parte dos defeitos.

4.3.3 Taxonomia de defeitos

A identificao de defeitos o principal objetivo de uma inspeo. Sendo assim, para se definir uma abordagem de inspeo, um dos passos determinar quais so os possveis tipos de defeitos que podem ocorrer no artefato avaliado. Tipo de defeito no foi um dos componentes identificados em (LAITENBERGER e DEBAUD, 1998) para caracterizar uma abordagem de inspeo. Contudo, a sua definio de extrema importncia durante a construo de uma abordagem dessa natureza, pois auxilia na definio dos questionamentos que auxiliaro os inspetores a identificar defeitos (TRAVASSOS et al., 2002). Defeitos em artefatos de software podem ser classificados atravs de diversas taxonomias. A taxonomia que utilizamos como base a definida por SHULL (1998), composta pelos seguintes tipos: omisso, ambigidade, inconsistncia, fato incorreto e informao estranha. Essa taxonomia conhecida como sendo uma taxonomia no ortogonal, ou seja, possvel que um determinado defeito pertena a mais de um tipo (SHULL, 1998).

70

Visto que a descrio de como cada tipo de defeito ocorre especfica ao tipo de artefato inspecionado (TRAVASSOS et al., 1999), alm de identificar os tipos de defeitos, necessrio identificar em que consistem. Por isso, a taxonomia de defeitos utilizada foi devidamente interpretada para o contexto de Arquitetura de Software. Portanto, no contexto de reviso de um documento arquitetural, defeitos arquiteturais podem ser identificados nos seguintes casos: (1) quando no houver uma consistncia na representao dos elementos arquiteturais entre os diferentes modelos que compem o documento, (2) quando os modelos no descreverem o mapeamento das funcionalidades em elementos arquiteturais e (3) quando os elementos arquiteturais que foram definidos, ou a forma como foram organizados, no permitirem atender aos requisitos de qualidade especificados. Sendo assim, visando auxiliar os inspetores na identificao e categorizao dos defeitos encontrados durante a atividade de identificao, a adaptao da taxonomia de defeitos proposta por (SHULL, 1998) gerou uma lista de tipos de defeitos (Tabela 4.1) que podem ser encontrados ao se revisar um documento arquitetural.
Tabela 4.1 - Taxonomia de defeitos Tipos de defeitos Omisso Ambigidade Descrio 1. Quando um elemento arquitetural necessrio para o atendimento a um requisito no foi definido; 2. Quando a forma como os elementos arquiteturais ou suas responsabilidades foram definidos dificulta ou impossibilita o atendimento a um requisito de qualidade. 3. Quando elementos descritos em vises distintas possuem o mesmo nome, mas responsabilidades diferentes (Homnimo); 4. Quando elementos descritos em vises distintas possuem mesma responsabilidade, mas nomes distintos (Sinnimo); 5. Quando um elemento arquitetural presente em diagramas das demais vises no foi definido no diagrama avaliado; 6. Quando a representao no condiz com a semntica estabelecida pela abordagem de documentao. 7. Quando um elemento arquitetural definido com responsabilidades distintas em duas ou mais vises. 8. Quando um elemento representado de maneira diferente em duas vises. 9. Quando um elemento no foi descrito ou representado de forma correta 10. Quando no possvel mapear um elemento arquitetural para algum elemento descrito em outra viso. 11. Quando no possvel determinar o papel de um elemento arquitetural ou de uma de suas responsabilidades no atendimento aos requisitos especificados.

Inconsistncia

Fato Incorreto

Informao Estranha

4.3.4 Tcnica de inspeo utilizada

O principal diferencial de uma abordagem de inspeo est na maneira como ela auxilia o inspetor a encontrar os defeitos. O que determina essa maneira a tcnica de deteco de defeitos utilizada. Para ArqCheck, a tcnica de deteco de defeitos utilizada foi o checklist. Checklist foi escolhido entre as tcnicas existentes por ser mais adequado s

71

caractersticas da rea de Arquitetura de Software e por permitir minimizar as limitaes identificadas nas abordagens de avaliao arquitetural identificadas na literatura (BARCELOS e TRAVASSOS, 2005). A seguir, mostramos porque a tcnica checklist foi escolhida em detrimento da tcnica ad-hoc ou da tcnica de leitura. Alm disso, mostramos que melhorias foram realizadas no checklist visando minimizar as limitaes identificadas nas demais abordagens de avaliao arquitetural. Descrevemos tambm quais os itens de avaliao que compem esse checklist e como eles foram criados. 4.3.4.1 Checklist versus demais tcnicas de inspeo Diversas tcnicas de inspeo de software j foram definidas visando auxiliar na identificao de defeitos. A principal caracterstica que diferencia essas tcnicas o nvel de formalidade usado durante a atividade de identificao. Esse nvel de formalidade permite as categorizar em trs tipos: Ad-hoc, Checklist e Tcnicas de leitura. Tcnicas ad-hoc so as tcnicas mais simples para identificar defeitos em artefatos de software. Elas no oferecem nenhum tipo de apoio ou procedimento de execuo formal e sistemtico de inspeo. Sendo assim, os defeitos identificados dependem exclusivamente da capacidade, competncia e experincia do inspetor (CHEN et al., 2002). Um dos pontos negativos em usar tcnicas ad-hoc o fato delas no oferecerem auxlio aos inspetores para identificar defeitos. Em um contexto arquitetural, por exemplo, os requisitos de qualidade exercem uma grande influncia na definio de uma arquitetura, porm o uso de uma tcnica ad-hoc para avali-la no forneceria nenhum auxlio visando garantir que os inspetores avaliem o atendimento a esses requisitos. Uma evoluo s tcnicas ad-hoc so as baseadas em checklist. Ao se utilizar checklist para revisar artefatos de software, fornecido ao inspetor um conjunto de questionamentos que o auxiliam a identificar em que parte do artefato avaliado ele deve procurar por defeitos (SHULL et al., 2000). Utilizar esse tipo de tcnica em inspees arquiteturais consiste em definir questionamentos que, por exemplo, indicariam ao inspetor como identificar os elementos arquiteturais que devem ser analisados, visando avaliar o atendimento a um determinado requisito. Um outro possvel tipo de tcnica que pode ser usado em inspeo so as tcnicas de leitura. Tcnicas de leitura so procedimentos que visam guiar individualmente os inspetores no entendimento de um artefato de software e, por conseqncia, na

72

identificao de discrepncias (SHULL et al., 2000). Abordagens de avaliao baseadas nessa tcnica (SHULL et al., 2000; CONRADI et al., 2003) so mais eficientes na deteco de defeitos quando comparadas a outras tcnicas de inspeo, como checklists, por exemplo. Porm, para que esse tipo de tcnica seja utilizado, o artefato deve ser representado em uma forma especfica e padronizada, caracterstica que ainda no pode ser atingida na rea de Arquitetura de Software por no existir uma padronizao para se representar documentos arquiteturais. Atualmente, se tem notcia de somente uma abordagem baseada em tcnicas de leitura para avaliar documentos arquiteturais, intitulada de Architecture Reading Techniques - ARTs (CARVER e LEMON, 2005)6. Uma caracterstica dessa abordagem a necessidade da arquitetura estar documentada seguindo a abordagem apresentada em (CLEMENTS et al., 2004), o que pode dificultar aplicar essa reviso em arquiteturas que no tenham sido documentadas desta forma. Em suma, a principal diferena entre os trs tipos de tcnicas de inspeo apresentados est no tipo de auxlio que eles oferecem aos inspetores para identificar defeitos. A tcnica ad-hoc no oferece nenhum auxlio ao inspetor durante a reviso do artefato visando a identificao de defeitos, a tcnica baseada em checklist auxilia o inspetor na identificao do que deve ser revisado e a tcnica de leitura, alm de auxiliar na identificao, auxilia tambm na forma como o artefato deve ser revisado para que os defeitos sejam identificados. Na Tabela 4.2, feita uma comparao entre as diferentes tcnicas de inspeo usando outros critrios (SHULL et al., 2000; SILVA, 2004) que permitem identificar o contexto em que cada tipo de tcnica pode ser usada.
Tabela 4.2 - Caractersticas das tcnicas de inspeo (SILVA, 2004) Caractersticas Linguagem: Em que linguagem ou notao os documentos devem estar escritos? Sistematizao: Os passos especficos do processo de reviso individual so definidos? Foco: Cada revisor deve focar em diferentes aspectos do documento? Aprimoramento Contnuo: A partir da realimentao dos revisores, aspectos da tcnica podem ser melhorados? Adaptao: A tcnica pode ser adaptada para projetos ou organizaes especficas? Treinamento: A tcnica permite e
6

Ad-hoc Qualquer No No No

Checklist Qualquer Parcialmente No Parcialmente

Tcnicas de leitura Especfica

(ex: Architecture Description Language - ADL especfica)

Sim Sim Sim

No No

Sim Parcialmente

Sim Sim

A abordagem ARTs no foi identificada pela reviso sistemtica visto que a abordagem foi publicada no ISESE05, cujos Anais ainda no tinham sido disponibilizados nas fontes de pesquisa que utilizamos no momento da realizao da reviso.

73

necessita de treinamento?

Portanto, devido s caractersticas da rea de Arquitetura de Software, a tcnica de checklist possui caractersticas que a tornam mais adequada para se aplicar em uma inspeo de documento arquitetural. Vrias abordagens baseadas em checklist j foram definidas visando a identificao de defeitos em documentos arquiteturais. Contudo, os questionamentos feitos por esses checklists ou so especficos ao domnio do software avaliado (HOLLOCKER, 1990; NASA, 1993), o que dificulta a sua aplicao em um contexto diferente do qual foi projetado, ou ento so muito especficos soluo (ERICKSON et al., 1993), o que requer que a cada avaliao um novo checklist seja criado. Com isso, algumas melhorias devem ser feitas para que uma tcnica de checklist possa ser utilizada de forma efetiva e escalvel, permitindo assim a sua aplicao em contexto industrial. 4.3.4.2 Melhorias realizadas no checklist para inspeo arquitetural ArqCheck objetiva identificar defeitos arquiteturais usando como guia os questionamentos definidos em um checklist de avaliao. A nossa hiptese que o uso de checklist como tcnica de inspeo e o tipo de conhecimento utilizado para definir esse checklist possibilitam identificar defeitos arquiteturais relacionados ao atendimento dos requisitos do software e permitem minimizar as limitaes identificadas nas abordagens de avaliao existentes (BARCELOS e TRAVASSOS, 2005). Para que essa abordagem pudesse utilizar um checklist para auxiliar na identificao de defeitos, identificamos alguns requisitos que devem ser atendidos pelo checklist para que limitaes identificadas nas abordagens de avaliao arquitetural sejam minimizadas. Essas caractersticas so: Os itens de avaliao que compem o checklist devem usar conceitos oriundos das atividades de especificao arquitetural, levando em considerao principalmente a forma como os requisitos de qualidade so atendidos. Com isso, pretende-se reduzir a subjetividade em relao ao que avaliado; Esses itens devem ser agrupados pelo tipo de requisito de qualidade que se busca avaliar o atendimento. Com isso, possvel definir exatamente que caractersticas de qualidade esto sendo avaliadas ao usar o checklist; Fcil execuo da avaliao, sem a necessidade de elaboradas atividades, como as necessrias para a especificao de cenrios, por exemplo, permitindo a realizao de avaliaes com baixos custos.

74

Os itens de avaliao devem avaliar as informaes contidas no documento arquitetural, ficando assim independente da forma como essas informaes foram representadas. Com isso, possvel aplicar a abordagem proposta em documentos que pertencem a diferentes contextos e que utilizam diferentes abordagens de documentao;

4.3.4.3 Descrio do checklist O checklist que compem ArqCheck, alm de atender aos requisitos descritos na seo anterior, foi criado com base em conceitos presentes na famlia de tcnica de leitura conhecida como Object Oriented Reading Techniques - OORTs (TRAVASSOS et al., 2002). Essa famlia de tcnica de leitura foi escolhida devido s similaridades existentes entre arquiteturas de software e documentos de projeto orientado a objetos, artefato avaliado por OORTs. Aps uma anlise de como OORTs avalia os documentos de projeto, percebemos que tambm seria possvel utilizar a abordagem de rastreabilidade de informaes utilizada por OORTs (TRAVASSOS et al., 1999), na avaliao de documentos arquiteturais. Ao adaptar essa abordagem de rastreabilidade para o contexto de Arquitetura de Software, definimos que a avaliao do documento arquitetural pode ser feita atravs (1) do rastreamento das informaes que so comuns s diferentes vises que o compe, visando garantir a consistncia do documento, e (2) da anlise das informaes descritas nesse documento com as que esto presentes na especificao dos requisitos, visando garantir a corretude e a completude da arquitetura avaliada. Alm disso, devido s caractersticas da rea de Arquitetura de Software, como a falta de padronizao entre abordagens de documentao arquitetural, criamos o checklist de forma que ele pudesse ser configurvel, para que se adapte arquitetura avaliada e possa ser utilizado para avaliar documentos arquiteturais oriundos de diversos contextos. Sendo assim, criamos itens de avaliao para compor o checklist com o objetivo de avaliar: Se as informaes descritas no documento arquitetural esto consistentes entre si. Essa avaliao feita devido ao uso de diferentes vises arquiteturais para representar um mesmo conjunto de elementos arquiteturais atravs de diferentes perspectivas. Sendo assim, necessrio avaliar a consistncia das informaes comuns a essas vises;

75

Se todas as funcionalidades especificadas foram atendidas pela arquitetura. Essa avaliao feita com o objetivo de identificar defeitos relacionados a rastreabilidade entre os requisitos e os elementos arquiteturais;

Se todos os elementos arquiteturais foram definidos com base nos requisitos especificados. Essa avaliao tambm feita com o objetivo de analisar a rastreabilidade requisitos-elementos arquiteturais;

Se a arquitetura atende aos requisitos de qualidade especificados para o produto. Essa avaliao feita devido importncia dos requisitos de qualidade na definio da arquitetura. Com isso, agrupamos os itens de avaliao que criamos em trs grupos (Figura

4.3): (1) itens que avaliam a consistncia do documento, (2) itens que avaliam o atendimento aos requisitos e (3) itens que avaliam a abordagem utilizada para atender aos requisitos de qualidade.

Figura 4.3 - Grupos de itens de avaliao que compem o checklist proposto

A seguir descrevemos como cada um desses grupos foi criada. No Apndice B.3, a verso final do checklist pode ser encontrada. Itens que avaliam a consistncia do documento Esse conjunto de itens busca avaliar se todas as vises que compem o documento arquitetural esto representando a mesma arquitetura. Visto que o papel das vises arquiteturais representar determinada arquitetura sob diferentes perspectivas, definimos itens para avaliar a consistncia das informaes de uma viso arquitetural e entre as diferentes vises.

76

A avaliao realizada por esses itens consiste principalmente em analisar os diagramas grficos que compem o documento arquitetural. Visto que esses diagramas so especficos abordagem de documentao utilizada, ou seja, dependem da semntica atribuda aos smbolos grficos que descrevem a arquitetura, houve necessidade em se criar itens de avaliao especficos abordagem de representao grfica utilizada, formando assim dois grupos de itens. O primeiro grupo formado por itens que buscam identificar a consistncia em relao a conceitos bsicos de especificao arquitetural, o que os deixa independente da representao grfica utilizada. Um exemplo de avaliao feita por itens que pertencem a esse grupo a identificao de mdulos arquiteturais que nunca se relacionam com outro elemento arquitetural (Tabela 4.3). A presena de um mdulo com essa caracterstica indica que possivelmente algum erro foi cometido no projeto arquitetural pois ele no exerce nenhuma funo na arquitetura projetada.
Tabela 4.3 - Exemplo de item que avalia consistncia do documento de forma independente representao grfica utilizada Descrio do item Resposta Esperada Tipo de Defeito Objetivo Item de avaliao de consistncia Ao analisar todos os diagramas, foi identificado algum elemento arquitetural que no possua relacionamentos, ficando isolado dos demais? No Informao Estranha ou Fato Incorreto Identificar elementos inseridos que foram inseridos na arquitetura sem necessidade ou ento identificar erros no projeto da arquitetura Exemplo

O segundo grupo formado por itens que so especficos abordagem de representao utilizada. Esses itens so utilizados para avaliar principalmente a consistncia das informaes dentro de cada uma das vises. Na Tabela 4.4, descrevemos um item que pertence a esse grupo. Para cada nova abordagem de documentao arquitetural, necessrio analisar os tipos de viso arquitetural que a abordagem define e tambm as regras de

77

consistncia pertencentes a cada viso. com base nessas informaes, que os itens de avaliao pertencentes a esse grupo so criados. O principal objetivo deles levar o inspetor a avaliar se, para cada viso, as regras de consistncia esto sendo respeitadas e se as informaes esto consistentes entre as diferentes vises.
Tabela 4.4 - Exemplo de item que avalia consistncia do documento e que especfico representao grfica utilizada Descrio do item Resposta Esperada Tipo de Defeito Objetivo Item de avaliao de consistncia Todo relacionamento definido entre dois clusters pode ser mapeado para seus respectivos mdulos? Sim Inconsistncia Identificar se todos os relacionamentos definidos entre elementos de alto nvel esto mapeados para os elementos de baixo nvel Exemplo

Os itens que compem esse grupo foram definidos principalmente com base em conceitos relacionados documentao de vises arquiteturais extrados de (CLEMENTS et al., 2004). Portanto, esses itens avaliam a consistncia entre quatro tipos de viso: modular, dinmica, de alocao e de contexto geral. A avaliao realizada por eles de extrema relevncia para a melhoria da qualidade do documento arquitetural pois buscam identificar defeitos que poderiam dificultar a implementao do software a partir da arquitetura. Alm disso, eles permitem uma avaliao direcionada, pois no fica a cargo do inspetor determinar o que deve ser avaliado. Devido presena de itens especficos abordagem de representao arquitetural utilizada, necessrio que, antes da avaliao, seja realizada uma anlise visando determinar os itens que so aplicveis ou no para a arquitetura a ser avaliada. Essa anlise feita durante a configurao do checklist 7. Alm de avaliar se as diferentes vises que formam um documento arquitetural esto representando a mesma arquitetura, preciso avaliar tambm se a arquitetura descrita no documento representa corretamente o sistema descrito pelos requisitos.
7

A configurao do checklist descrita com mais detalhes na seo 4.3.4 desse captulo.

78

Para isso criamos dois grupos de itens, um responsvel por avaliar o atendimento aos requisitos e um outro responsvel por avaliar abordagem utilizada para atender aos requisitos de qualidade. Itens que avaliam o atendimento aos requisitos A principal forma de avaliar o atendimento aos requisitos consiste em verificar se existe rastreabilidade entre os requisitos e os elementos arquiteturais. Por isso, definimos um conjunto de itens de avaliao que avaliam essa rastreabilidade. Nesses itens, foi dada nfase principalmente na avaliao do atendimento aos requisitos funcionais, visto que itens especficos tambm foram criados para avaliar o atendimento a requisitos de qualidade. Sendo assim, esses itens procuram avaliar se algum requisito relevante a nvel arquitetural no foi atendido pela arquitetura, devido falta de ateno por parte do arquiteto, por exemplo. Alm disso, eles procuram identificar tambm se elementos arquiteturais foram definidos sem haver necessidade de sua existncia. Isso ocorre, por exemplo, quando os arquitetos fazem uso de conceitos que no so diretamente relevantes ao domnio do problema e que acabariam introduzindo complexidade desnecessria ao projeto. Portanto, os itens de avaliao que pertencem a esse grupo permitem a realizao de dois tipos de anlise: (1) se todas as funcionalidades especificadas foram atendidas pela arquitetura e (2) se todos os elementos arquiteturais foram definidos com base nos requisitos especificados (Tabela 4.5). Itens que avaliam a abordagem utilizada para atender aos requisitos de qualidade A avaliao do atendimento a requisitos de qualidade de grande importncia para a garantia da qualidade do documento arquitetural (BASS et al., 2003), com isso, itens de avaliao foram criados especialmente para se a abordagem usada pelos arquitetos realmente atende aos requisitos de qualidade especificados. Visto que nem todos os requisitos de qualidade podem ser atendidos durante o projeto arquitetural, procuramos identificar, em um primeiro momento, quais so os tipos de requisito de qualidade que so relevantes a nvel arquitetural. Para isso, foi feita uma anlise das taxonomias existentes utilizadas para caracterizar esse tipo de requisito (ISO/IEC, 1998; BASS et al., 2003). Com essa anlise, identificamos que a taxonomia definida por BASS et al. (2003) identifica os tipos de requisitos de qualidade que so relevantes a esse nvel de abstrao. Visto isso, a utilizamos como base para o nosso trabalho.

79

Essa taxonomia nos orientou em relao ao tipo de avaliao que deveramos fazer. A partir dela, identificamos que para permitir a avaliao do atendimento a requisitos de qualidade, deveramos avaliar especificamente o atendimento a requisitos de Modificabilidade, Desempenho, Usabilidade, Testabilidade, Disponibilidade e Segurana. Alm de definir que tipo de requisitos de qualidade avaliar, precisvamos definir como avaliar a arquitetura em relao ao atendimento a esses requisitos. Para isso optamos por utilizar conhecimentos provenientes de prticas usadas durante o projeto arquitetural.
Tabela 4.5 - Exemplo de item que avalia o atendimento aos requisitos Item de avaliao do atendimento aos requisitos A infra-estrutura deve permitir a persistncia de todos os modelos e artefatos por ela manipulados Descrio do Item As responsabilidades dos elementos arquiteturais esto condizentes com os requisitos que eles atendem? Resposta Esperada Sim Tipo de Defeito Fato Incorreto Observao A simbologia utilizada representa que os dados no repositrio podem ser somente acessados e no alterados, o que vai de encontro com o requisito especificado. Exemplo Requisito Avaliado

Conforme descrito no Captulo 2, durante a etapa de projeto arquitetural, os arquitetos utilizam como abordagem para atender aos requisitos de qualidade a aplicao de estilos e tticas arquiteturais. Visto que as tticas arquiteturais so conhecimentos mais abstratos, simples e so utilizados na criao dos estilos arquiteturais, optamos por utiliz-las como principal fonte de conhecimento para a criao dos itens de avaliao do checklist que ficaram responsveis por avaliar essas caractersticas da arquitetura. As tticas arquiteturais consistem em um conjunto de diretrizes arquiteturais baseados em boas prticas, que auxiliam no atendimento a requisitos de qualidade que influenciam o projeto de uma arquitetura (TVEDT et al., 2002). Algumas pesquisas

80

mostram indcios que as informaes contidas nesse tipo de conhecimento so teis para apoiar o processo de avaliao arquitetural (ZHU et al., 2004). As tticas que utilizamos para a criao dos itens de avaliao esto descritas em (BASS et al., 2003). No Anexo B, descrevemos resumidamente as tticas que utilizamos para a criao do checklist. Com base nessas tticas e nos tipos de requisitos de qualidade que elas atendem foi possvel criar a Tabela 4.6, que identifica os tipos de requisitos de qualidade que so avaliados pelo checklist proposto e as tticas arquiteturais que foram usadas como base na criao dos itens que o compem.
Tabela 4.6 - Tticas arquiteturais utilizadas na definio do checklist Tipos de requisitos de qualidade atendidos pelos itens Desempenho Disponibilidade Modificabilidade Tticas arquiteturais usadas na definio dos itens Controle da gerao de eventos Controle da freqncia de eventos externos Reduo do overhead computacional Ping/echo Heartbeat Redundncia Ativa Manter a coerncia semntica Isolar servios comuns Isolar candidatos a alteraes Abstrair informaes Separar as interfaces da implementao do mdulo Usar intermedirios Autenticao de usurios Limitar o acesso Separar a interface da implementao Interfaces especficas de acesso Monitores -

Segurana Testabilidade Usabilidade

Para cada grupo de itens que avaliam o atendimento aos requisitos de qualidade foi criado uma Guia de identificao de contexto, que utiliza a descrio do requisito a ser avaliado para identificar os elementos arquiteturais relacionados ao atendimento de determinado requisito de qualidade. Ao identificar esses elementos, o inspetor consegue avaliar atravs dos itens de avaliao se os elementos arquiteturais foram definidos de forma a permitir o atendimento ao requisito. A principal contribuio desses itens est no fato do uso de agrupamentos permitir a avaliao de um ou mais requisitos de qualidade, identificados como prioritrios pelos stakeholders. Na Tabela 4.7 pode ser observado um exemplo de item de avaliao de qualidade. Nesse exemplo, um item de desempenho usado para avaliar um diagrama de acordo com o requisito de desempenho especificado.

81

4.3.5 Processo de inspeo utilizado

Um processo de software consiste em uma srie de passos envolvendo atividades, restries e recursos que produzem um resultado esperado (PFLEEGER, 2004). Abordagens de inspeo so normalmente executadas a partir de um processo que identifica as atividades utilizadas principalmente para detectar defeitos no artefato e que define os papis que os indivduos deveram exercer durante a realizao dessas atividades.
Tabela 4.7 - Exemplo de item que avalia a abordagem utilizada para atender a um requisito de qualidade Item de avaliao do atendimento aos requisitos Requisito de desempenho avaliado Cenrio de qualidade A infra-estrutura deve permitir a instanciao de um Ambiente para Execuo em menos de 10 segundos
Cenrio de Desempenho Usurio Engenheiro Instanciar Ambiente para Execuo Durante a execuo normal da infra-estrutura Sistema Ambiente para Execuo instanciado Menos de 10 segundos

Fonte do estmulo Estmulo Contexto do sistema Artefato Resposta Medida de resposta

Guia de Identificao de Contexto

Descrio do Item Resposta Esperada Tipo de Defeito Observao

De acordo com os requisitos de desempenho selecionados, identifique as seqncias de execuo do sistema (Seqncia), assim como os elementos arquiteturais (Elementos Participantes) que a compem. Essa identificao pode ser feita atravs da anlise do estmulo, do artefato e da resposta descritos nos cenrios de desempenho. Todos os Elementos Participantes foram alocados em um mesmo n computacional visando aumentar o desempenho da Seqncia? Sim Fato Incorreto Para a execuo da seqncia de instanciao, os elementos que participam dessa seqncia esto alocados em trs ns computacionais diferentes, o que pode atrapalhar o atendimento ao requisito de desempenho especificado. Exemplo

82

O processo utilizado por ArqCheck consiste em uma adaptao do processo tradicional de inspeo definido por FAGAN (1976). Devido s caractersticas do checklist proposto, algumas modificaes tiveram que ser feitas no processo de inspeo adotado. Essas modificaes consistem principalmente na introduo de atividades necessrias para realizar as devidas configuraes no checklist e de atividades que devem ser executadas pelo inspetor durante a identificao de discrepncias. A seguir, descrevemos as principais atividades que compem o processo a ser seguido para realizar a abordagem para inspeo proposta e detalhamos as modificaes que foram realizadas quando necessrio. 4.3.5.1 Descrio das atividades do processo de inspeo O processo de inspeo que utilizamos composto pelas seguintes atividades (Figura 4.4): Planejamento, Apresentao, Deteco, Reunio de inspeo, Retrabalho e Continuao.

Figura 4.4 - Processo de inspeo utilizado

Planejamento Nessa atividade, um profissional identificado como moderador da inspeo. Durante o Planejamento, esse moderador deve definir o contexto em que a inspeo vai ser realizada. Para isso, ele define os participantes, identifica o artefato a ser avaliado e distribui o material aos inspetores.

83

Alm dessas atividades que devem ser realizadas durante o planejamento de uma inspeo, realizamos algumas modificaes visando inserir atividades especficas s caractersticas da abordagem de inspeo proposta. A principal caracterstica que motivou essa modificao foi a necessidade de configurar o checklist antes de realizar a avaliao do documento arquitetural. Sendo assim, inclumos um conjunto de atividades para permitir a realizao dessa configurao (Figura 4.5).

Figura 4.5 Sub-atividades adicionadas na atividade de planejamento visando configurao do checklist

A configurao do checklist consiste em selecionar os itens que so aplicveis ao documento arquitetural a ser avaliado. Itens aplicveis so itens especficos que so utilizados na inspeo de acordo com a abordagem de representao arquitetural utilizada e de acordo com os tipos de requisitos de qualidade que se deseja avaliar. Os principais motivos que levaram a criao desses itens aplicveis so: A ausncia de padronizao na documentao da arquitetura, necessitando a criao de itens genricos e de itens que sejam especficos abordagem de documentao utilizada; O uso de tticas arquiteturais como base para a criao de itens de avaliao. Visto que existe um conjunto de tticas que auxilia o atendimento a cada um dos tipos de requisitos de qualidade relevantes a nvel arquitetural, os itens foram criados seguindo essa mesma poltica. Contudo, nem toda arquitetura necessita atender a todos esses tipos de requisitos, somente aos que foram especificados, com isso no precisam ser utilizados durante a avaliao. Sendo assim, durante o planejamento, o moderador dever tambm: Selecionar os itens de avaliao relacionados abordagem de documentao arquitetural utilizada;

84

Selecionar os itens de avaliao relacionados aos requisitos de qualidade priorizados. Para isso os stakeholders devem priorizar os requisitos de qualidade que sero utilizados para avaliar a arquitetura em relao ao seu atendimento;

Descrever os requisitos de qualidade selecionados como cenrios de qualidade. Isso feito visando complementar a Guia de identificao de contexto e auxiliar os inspetores na identificao dos elementos arquiteturais utilizados no atendimento a determinado requisito de qualidade. Para facilitar essa identificao, foi adotado o uso de cenrios de qualidade (BASS et al., 2003) que permite caracterizar um requisito de qualidade e facilitar o seu entendimento. Como principal resultado desse conjunto de atividades obtemos o checklist

configurado. Na Figura 4.6, apresentada uma parte de um checklist configurado. Nesse exemplo, os itens selecionados so itens que avaliam o atendimento ao requisito de modificabilidade especificado.

Figura 4.6 - Exemplo de itens pertencentes a um checklist configurado

Apresentao O profissional responsvel por realizar essa fase o autor. Neste momento, ele apresenta as caractersticas dos artefatos a serem inspecionados. Esta fase pode ser

85

omitida se os inspetores possuem conhecimento sobre o projeto e os artefatos que devem ser inspecionados. Alm disso, durante essa fase realizado pelo moderador o treinamento no checklist de inspeo arquitetural. Durante esse treinamento, passado para os inspetores (1) os conceitos presentes no checklist, (2) como deve ser feita a identificao e o registro de defeitos e (3) apresentada a taxonomia de classificao de defeitos que deve ser usada para classific-los. Deteco Nessa atividade, os inspetores individualmente revisam o artefato identificando os defeitos. Devido s caractersticas do checklist que compem ArqCheck, subatividades foram definidas visando auxiliar o inspetor na identificao de defeitos. Essas sub-atividades determinam a ordem de execuo dos itens de avaliao (Figura 4.7).

Figura 4.7 Atividades de deteco de defeitos

O motivo em estabelecer essa ordem est relacionado ocorrncia de inconsistncias nas representaes que podem influenciar na identificao de possveis inconsistncias relacionadas ao atendimento dos requisitos, por exemplo. Durante a execuo da atividade de Deteco, o inspetor deve registrar as discrepncias em um relatrio de discrepncias (vide Apndice C) e classific-las de acordo com o tipo de defeito que elas podem gerar, usando para isso a taxonomia de defeitos que fora definida. Reunio de inspeo Durante essa atividade, uma reunio de equipe ocorre envolvendo o moderador, os inspetores e os autores do documento. Discrepncias so discutidas e classificadas

86

como defeitos ou falso positivos. A deciso final sobre a classificao de uma discrepncia sendo discutida do moderador. A soluo dos defeitos no discutida durante a reunio, por no fazer parte do objetivo dessa reunio e para evitar que ela se estenda demais. Normalmente, uma reunio de inspeo no deve exceder duas horas, visto que aps esse tempo a concentrao e a capacidade de anlise dos inspetores costumam se reduzir drasticamente. No caso em que uma reunio precisa de mais de duas horas, sugerido que o trabalho de inspeo continue no prximo dia (KALINOWSKI, 2004). Retrabalho Nessa fase o autor corrige os defeitos detectados durante a inspeo. Continuao O material corrigido pelos autores repassado para o moderador, que faz uma anlise da inspeo como um todo e re-avalia a qualidade do artefato inspecionado. Ele tem a liberdade de decidir se uma nova inspeo deve ocorrer ou no.

4.4 Concluso
Ao longo desse captulo, foi apresentada Arqcheck, a abordagem proposta para inspeo de documentos arquiteturais baseada em checklist (Tabela 4.8).
Tabela 4.8 - Caracterizao da abordagem proposta seguindo o framework definido no Captulo 3 Checklist para inspeo arquitetural Caractersticas da abordagem Tipo de informao: Descrio usando diferentes perspectivas de representao (vises arquiteturais) Rastreabilidade com os requisitos Nvel de abstrao: Arquitetura inicial Questionamento (checklists) 1. Planejamento: realiza-se o planejamento da inspeo assim como a configurao do checklist para que ele avalie as caractersticas de qualidade definidas 2. Apresentao: apresenta-se o documento a ser avaliado e o checklist a ser utilizado 3. Deteco: identificao de discrepncias atravs do uso dos questionamentos que compem o checklist 4. Reunio de inspeo: consolidao dos defeitos atravs da anlise das discrepncias 5. Retrabalho 6. Continuao Representao arquitetural Documento de requisitos Requisitos de qualidade priorizados Lista de defeitos Recomendaes de como corrigir os defeitos atravs

Tipo de arquitetura

Tipo de tcnica

Processo seguido

Artefatos requeridos Artefatos produzidos

87

Caractersticas de qualidade Momento da avaliao Apoio ferramental Avaliao

da indicao de possveis tticas arquiteturais que poderiam ser aplicadas na arquitetura Mltiplos Aps construo Estudo experimental (estudos de viabilidade)

Essa abordagem foi criada com o objetivo de identificar defeitos em documentos arquiteturais. Alm disso, ela tem como principal requisito minimizar as limitaes identificadas nas abordagens de avaliao arquitetural existentes (Tabela 4.9), permitindo assim a atender as caractersticas por ns identificadas e que motivaram a realizao dessa pesquisa e que facilita a aplicao dessa prtica em um contexto industrial. Uma caracterstica de ArqCheck que o checklist que a compem foi criado com base no conhecimento normalmente utilizado durante as atividades de especificao arquitetural e tambm com base em conceitos observados em uma famlia de tcnicas de leitura conhecida como OORTs. Contudo, mesmo usando esses elementos como base para a criao da abordagem, no se pode garantir a sua viabilidade e a sua utilidade. Para isso, estudos experimentais devem ser realizados visando (1) avaliar a viabilidade de utilizar essa abordagem na identificao de defeitos e (2) confirmar a relevncia dos itens de avaliao do checklist na identificao de defeitos arquiteturais.
Tabela 4.9 - Solues adotadas para minimizar as limitaes identificadas Limitao das abordagens identificadas Subjetividade na avaliao Custo de aplicao Soluo para minimizar as limitaes Uso de um checklist composto por itens de avaliao que indicam ao inspetor o que deve ser avaliado, no deixando a cargo de sua experincia essa deciso. Uso de inspeo de software por no exigir a realizao de tarefas complexas, como a definio de cenrios. Alm disso, ArqCheck no exige uma grande quantidade de profissionais ou especialistas em arquitetura para que a avaliao seja realizada. Definio de itens no checklist para avaliar as caractersticas de qualidade de acordo com os requisitos de qualidade que foram especificados pelo cliente e que possuem relevncia em um contexto arquitetural Definio de um processo de configurao que permite adaptar o checklist s caractersticas do documento arquitetural a ser avaliado e aos objetivos da avaliao.

Avaliao de caractersticas qualidade Contexto limitado de

mltiplas de aplicao

No captulo seguinte, intitulado Estudos de avaliao da abordagem proposta, descrevemos como esses estudos experimentais foram realizados e os resultados que obtivemos.

88

Captulo 5 Avaliando a abordagem proposta

Neste captulo, detalhamos como foi feita a avaliao de ArqCheck. Para isso, apresentamos uma breve introduo aos conceitos relacionados Engenharia de Software Experimental e descrevemos os estudos experimentais executados com o intuito de avaliar a viabilidade da abordagem proposta.

5.1 Introduo
ArqCheck foi criada a partir de conhecimento e boas prticas utilizadas durante as etapas de especificao arquitetural. Uma das principais tarefas que realizamos para definir essa abordagem consistiu na identificao de como esse corpo de conhecimento utilizado na especificao arquitetural poderia ser utilizado na criao de um checklist que permitisse avaliar documentos arquiteturais. Contudo, quando uma tecnologia desenvolvida com base em experincias pessoais, observaes gerais ou boas prtica publicadas, no se pode assegurar que ela obtenha os resultados esperados (BABAR et al., 2004). Portanto, alm de desenvolver a tecnologia tambm importante avaliar se a tecnologia atende aos objetivos inicialmente definidos. O objetivo da abordagem proposta permitir a melhoria da qualidade de documentos arquiteturais atravs da identificao de defeitos. Para que isso seja possvel, diversas perguntas devem ser respondidas at que possamos afirmar que ArqCheck realmente atende aos seus objetivos. Entre os questionamentos possveis, procuramos responder inicialmente aos seguintes: vivel utilizar a abordagem proposta na identificao de defeitos em documentos arquiteturais? Ela identifica esses defeitos de forma eficiente e eficaz? Nesse sentido, realizamos uma srie de estudos experimentais visando caracterizao da abordagem e sua avaliao. Esses estudos objetivaram principalmente identificar se essa tecnologia realmente obtm os resultados esperados, alm de identificar problemas e dificuldades que as pessoas tiveram ao utiliz-la na prtica (CIOLKOWSKI et al., 2002). Os objetivos de cada estudo e a ordem em que foram executados foram definidos com base na metodologia experimental descrita por SHULL et al. (2001). Nas sees a seguir, identificamos alguns conceitos bsicos de experimentao aplicada engenharia de software, descrevemos a metodologia de transferncia

tecnolgica que utilizamos como base e detalhamos os estudos que foram realizados at o momento, assim como os resultados obtidos que permitiram uma evoluo da abordagem.

5.2 Conceitos

bsicos

de

Experimentao

aplicada

engenharia de software
Experimentao o centro do processo cientfico. Novos mtodos, tcnicas, linguagens e ferramentas no deveriam ser apenas sugeridos, publicados ou apresentados para venda sem experimentao e avaliao (AMARAL, 2003). Estudos experimentais podem ser usados nesses casos para avaliar essas tecnologias e auxiliar a direcionar pesquisas futuras atravs da identificao dos problemas e dificuldades que as pessoas possuem ao aplic-las na prtica. As pesquisas realizadas no contexto de Engenharia de Software geralmente buscam o desenvolvimento de novas tcnicas, mtodos ou ferramentas de desenvolvimento de software. Contudo, os benefcios e as limitaes dessas tecnologias so raramente examinados. TRAVASSOS et al. (1999) identificaram pesquisas que mostram que 50% de todos os artigos de engenharia de software realizaram pouca ou nenhuma avaliao das teorias por eles propostas. Ou seja, eles se baseiam principalmente em intuio ou utilizam estudos muito simples para demonstrar a validade de suas teorias. Para permitir um melhor entendimento e avaliao das tecnologias que esto sendo criadas, estudos experimentais tm se mostrado uma abordagem adequada (TRAVASSOS et al., 1999). Um estudo desse tipo consiste basicamente em uma observao sistemtica dos efeitos de uma tecnologia em aplicaes prticas (WOHLIN et al., 2000). Em suma, a utilizao de mtodos experimentais pode trazer os seguintes benefcios (TICHY, 1998; TRAVASSOS et al., 2001): Ajudar a construir uma base confivel de conhecimento e desta forma reduzir a incerteza sobre quais teorias, mtodos e ferramentas so adequados; Poder levar a novas compreenses sobre reas atualmente pesquisadas; Explorar reas desconhecidas, permitindo estender a fronteira do conhecimento; Acelerar o progresso atravs da rpida eliminao de abordagens no fundamentadas, suposies errneas e modismos, ajudando a orientar a engenharia e a teoria para direes promissoras;

90

Ajudar no processo de formao da Engenharia de Software como cincia, atravs do crescimento do nmero de trabalhos cientficos com uma avaliao experimental significativa.

Na demonstrao dos beneficio de uma nova tecnologia e no registro de experincias em relao a sua utilidade; Segundo WOHLIN (2000), os mtodos experimentais podem ser classificados

como: Survey: investigao executada em retrospecto quando, por exemplo, uma ferramenta ou tcnica tem sido utilizada em uma empresa e pretende-se avali-la sob algum aspecto (AMARAL, 2003). Algumas formas para coleta de dados como entrevistas e questionrios so bastante conhecidas e utilizadas. Estudos de caso: usados para monitorar projetos, atividades ou exerccios objetivando rastrear um atributo especfico, ou estabelecer relacionamentos entre diferentes atributos, sem um controle muito formal sobre as atividades relacionadas ao mtodo experimental. Experimentos: atividade com o propsito de descobrir algo desconhecido ou de testar uma hiptese envolvendo uma investigao de coleta de dados e de execuo de uma anlise para determinar o significado dos dados (BASILI et al., 1999). Experimentos so apropriados para confirmar teorias, o conhecimento convencional, explorar os relacionamentos, avaliar a predio dos modelos ou validar as medidas. A suas principais caractersticas so de (1) permitir o controle total sobre processo e variveis e (2) de ser possvel repeti-lo. A escolha de qual mtodo de pesquisa experimental utilizar depende dos prrequisitos da investigao, do propsito, da disponibilidade de recursos e de como se pretende analisar os dados coletados (WOHLIN et al., 2000). No contexto da nossa pesquisa, estudos experimentais foram realizados para avaliar a abordagem proposta para inspeo de documentos arquiteturais. Para isso, utilizamos principalmente estudos de casos devido (1) aos tipos de avaliao que se deseja realizar (avaliar a viabilidade, eficincia e eficaz da abordagem proposta), (2) s caractersticas desse tipo de estudo (fcil de planejar) e (3) ao fato de no termos o controle necessrio sobre diversas variveis que compem o contexto em que os estudos sero executados (variabilidade na escolha dos participantes, controle sobre os defeitos dos documentos arquiteturais) o que impossibilitaria a realizao de experimentos formais, por exemplo. Alm disso, uma das expectativas em relao a ArqCheck de introduzi-la em um contexto industrial, portanto, optamos por realizar os estudos experimentais de forma que alm de avaliar a abordagem proposta eles fornecessem um auxlio na realizao

91

dessa transferncia tecnolgica. Para isso, utilizamos uma metodologia que auxilia na definio de que estudos devem ser realizados visando minimizar os riscos ao introduzir essa tecnologia em um ambiente industrial. A metodologia utilizada foi definida em (SHULL et al., 2001).

5.3 Metodologia experimental utilizada

O MCT/SEPIN, rgo federal brasileiro responsvel pela poltica de informtica, vem realizando pesquisas anuais em relao qualidade e produtividade no setor de software no pas (MCT/SEPIN, 2005). Com base nos resultados obtidos com essa pesquisa, possvel observar um aumento, por parte das empresas brasileiras, pela procura por abordagens que permitam tanto a melhoria de seus processos quanto a de seus produtos. Essas abordagens consistem principalmente na implementao de modelos de maturidades de software, como CMMi (SEI, 2000) e MPS.Br (WEBER et al., 2004), ou ento no uso de conceitos como os relacionados a validao e verificao. Devido a essa procura, durante a construo e avaliao de ArqCheck, procuramos levar em considerao caractersticas que facilitem a transferncia dessa tecnologia e a sua utilizao em um contexto industrial, principalmente o das indstrias de software brasileiras. Para isso, a estratgia utilizada neste trabalho foi de realizar estudos inicialmente num ambiente acadmico para ento depois realiz-los na indstria. A realizao de estudos experimentais em ambientes acadmicos um passo necessrio por reduzirem o risco de transferncia de uma tecnologia imatura. importante lembrar que a transferncia tecnolgica no uma tarefa trivial. A insero de uma tecnologia em um ambiente industrial envolve diversos riscos e custos que devem ser minimizados para que ela possa ser aplicada com sucesso. A transferncia de uma tecnologia imatura diretamente em um ambiente industrial apresenta riscos que nem sempre so possveis de serem mitigados. Com isso, em caso de fracasso no seria possvel amadurecer a tecnologia devido impossibilidade de se identificar quais foram os fatores responsveis por esse resultado (SHULL et al., 2001), deixando assim de responder a vrias dvidas, como por exemplo: A idia bsica por traz da tecnologia est correta? A tecnologia no compatvel com as caractersticas do ambiente industrial? A tecnologia foi aplicada de forma correta? Alm do mais, os custos relacionados ao fracasso de um estudo quando realizado em um contexto industrial so altos, o que justifica a realizao de uma srie de estudos em um ambiente acadmico, menos custoso. O principal objetivo dos estudos realizados no contexto o de identificar e solucionar problemas observados para que

92

a tecnologia em estudo se torne mais madura e seus resultados no sejam oriundos de variaes humanas ou erros experimentais (PORTER et al., 1995). Com base nesse contexto, adotamos uma metodologia experimental que objetiva desenvolver novas tecnologias e auxiliar a sua transferncia para um contexto industrial. Essa metodologia de transferncia tecnolgica foi definida por SHULL et al. (2001) e busca lidar com os principais problemas de uma tecnologia ou processo antes que eles sejam inseridos em um contexto industrial. As principais motivaes que nos influenciaram a utilizar essa metodologia esto no fato (1) dela j ter sido utilizada com sucesso para avaliar outras abordagens de inspeo (TRAVASSOS et al., 1999) e (2) dela permitir mostrar aos profissionais da rea de software os possveis benefcios das tecnologias desenvolvidas na academia. A aplicao dessa metodologia consiste na avaliao da tecnologia a ser introduzida atravs de uma srie de estudos: de viabilidade, de observao, de caso aplicado em um ciclo de vida real e de caso aplicado em um ambiente industrial (Figura 5.1). Os estudos sugeridos para cada uma das fases esto diretamente relacionados s variveis que se desejam controlar e os riscos possveis de serem assumidos na fase em questo. A seguir, descrevemos o que foi realizado no contexto dessa pesquisa para cada um desses estudos.

5.4 Estudo de viabilidade

Estudos de viabilidade costumam ser os primeiros a serem conduzidos quando se deseja avaliar uma tecnologia recm criada. Atravs de um estudo com esse objetivo, procura-se identificar se a tecnologia realmente faz o que ela se prope a fazer e se vivel continuar a despender recursos para desenvolv-la. SHULL et al. (2001) destacam que revises nestas questes provocam as maiores alteraes na tecnologia, por isso elas devem ser tratadas no incio do processo de avaliao.

5.4.1 Definio do estudo

No contexto da avaliao da abordagem proposta, foi realizado um estudo de viabilidade visando identificar a sua capacidade em produzir resultados prticos no que se refere deteco de defeitos em um documento arquitetural. Portanto, procurou-se avaliar principalmente se o checklist que compem ArqCheck permite que um inspetor realmente identifique defeitos em um documento arquitetural.

93

Figura 5.1 - Viso geral da metodologia experimental utilizada. Adaptado de (SHULL et al., 2001)

Uma descrio mais detalhada do objetivo desse estudo est descrito na Tabela 5.1.
Tabela 5.1 - Objetivo do estudo de viabilidade seguindo o mtodo GQM (BASILI et al., 1994) Analisar o checklist para avaliar documentos arquiteturais Com o propsito de caracterizar Com respeito clareza e aplicabilidade em identificar defeitos Do ponto de vista de inspetores de artefatos de software No contexto de uma inspeo de um documento arquitetural cujos defeitos so conhecidos

Visando avaliar esse objetivo, buscou-se responder s seguintes perguntas: Q1: Os itens de avaliao que compem o checklist foram totalmente compreendidos? Mtricas: o Para cada item, quantidade de participantes que no o respondeu da forma planejada;

94

Q2: Os itens de avaliao que compem o checklist auxiliaram os inspetores na identificao de defeitos? Mtricas: o Para cada item, quantidade de participantes que o utilizou para identificar defeitos; As respostas obtidas por esses questionamentos foram ento utilizadas visando

obter algum tipo de concluso em relao seguinte hiptese nula: H0: No possvel identificar, em um documento arquitetural, defeitos arquiteturais relacionados ao atendimento dos requisitos de software utilizando uma abordagem para inspeo arquitetural baseada em checklist.

5.4.2 Planejamento e Execuo do estudo

Para a realizao desse estudo, foi utilizado o documento que representa a arquitetura do Ambiente de Experimentao eSEE (NETO et al., 2004), que est sendo construdo pelos membros do grupo de pesquisa ESE/COPPE/UFRJ. Esse documento foi criado de acordo com as recomendaes da IEEE 1471 e, portanto atende aos requisitos, descritos no Captulo 4, que definimos como essenciais para que a abordagem para inspeo proposta possa ser aplicada. Em relao corretude desse documento, foi utilizada nessa avaliao uma verso que possui 18 defeitos conhecidos, que foram identificados anteriormente no processo de desenvolvimento atravs de inspeo ad-hoc, pelo grupo que est desenvolvendo o projeto eSEE. Alm disso, visto que o objetivo do estudo avaliar se os itens que compem o checklist realmente detectam defeitos, foram inseridos defeitos adicionais no documento arquitetural. Essa insero ocorreu de forma que os defeitos possam ser encontrados pelos itens de questionamento, o que permite avaliar se os itens do checklist esto claros e que realmente, ao menos do ponto de vista do pesquisador, auxiliam na identificao de defeitos. A verso do checklist utilizada composta por 42 itens de avaliao. Entre esses itens, existem os que so aplicveis e os que no so aplicveis. Os itens aplicveis que se destacam nessa avaliao so os responsveis por avaliar as caractersticas de qualidade designadas pelos stakeholders. No contexto desse estudo, o ambiente eSEE possui requisitos de Modificabilidade, Segurana e Usabilidade que devem ter o seu atendimento avaliado. Por isso, necessrio que itens relacionados a esses tipos de requisitos sejam aplicados ao avaliar o documento arquitetural.

95

Em relao aos itens no aplicveis, eles so formados principalmente por itens que avaliam caractersticas do documento arquitetural que no esto sendo abordadas nesse estudo, como testabilidade, por exemplo, e, portanto no deveriam fazer parte do checklist. Contudo, como outra forma de avaliar a clareza dos itens, optamos por deixar esses itens no checklist a ser entregue para os participantes. Com isso, alm das opes Sim e No, o checklist utilizado nesse estudo disponibiliza uma terceira opo, NA - No Aplicvel (Figura 5.2), que deve ser marcada caso o participante identifique que o item no pode ser usado para avaliar o documento arquitetural que lhe fora passado.

Figura 5.2 - Exemplo de itens do checklist utilizado no estudo de viabilidade

Ao fornecer ao participante a possibilidade de marcar um item como no aplicvel, no desejamos avaliar se determinado grupo de itens realmente aplicvel ou no. O pesquisador j conhece quais so esses itens pois eles dependem das caractersticas de qualidade que se deseja avaliar. Com essa atitude, o que buscamos identificar se os inspetores conseguem entender o propsito do item e identificar se o item aplicvel ou no aplicvel. Partimos do princpio que se o participante marcar um item aplicvel como no aplicvel ou vice-versa, isso poderia ser um indcio de que ele no entendeu o propsito do item, o que categoriza o item como no claro.

96

Aps as alteraes no checklist, o pesquisador aplicou ArqCheck no documento arquitetural a ser distribudo aos participantes. Essa tarefa foi realizada com o objetivo de caracterizar o checklist em relao aos defeitos do documento arquitetural avaliado. Essa caracterizao permitiu, a partir do ponto de vista do pesquisador, (1) definir que itens do checklist levariam a identificar os defeitos, conhecidos como identificadores de defeitos, (2) definir se todos os defeitos conhecidos at o momento seriam identificados pelos itens, (4) avaliar se haveria novos defeitos que a inspeo ad-hoc no teria identificado e (5) identificar os itens que no seriam aplicveis. Com base nos resultados obtidos atravs dessa caracterizao (Tabela 5.2), foi possvel identificar, durante a anlise dos dados obtidos atravs do estudo, se os itens identificados pelo pesquisador realmente auxiliam os participantes a detectar defeitos. Sabemos da limitao dessa anlise, principalmente devido ao vis que pode ocorrer devido ao fato de ser o pesquisador quem realizou essa caracterizao do checklist. Contudo, o objetivo dessa comparao obter algum indcio sobre a clareza dos itens, para que sejam melhorados, e os resultados obtidos por essa caracterizao permitem a identificao desses indcios. Para isso, partimos do princpio de que se um participante no identificar um defeito a partir de um item marcado como tal, isso pode significar que o item no est claro o suficiente e que deve sofrer melhorias.
Tabela 5.2 - Caracterizao dos itens do checklist Item 1 2 3 4 5 6 7 8 9 10 11 12 13 14 Identifica defeitos? No Sim Sim Sim No No Sim Sim No No No Sim No Sim Item 15 16 17 18 19 20 21 22 23 24 25 26 27 28 Identifica defeitos? No Sim No No Sim No NA NA NA NA NA NA NA NA Item 29 30 31 32 33 34 35 36 37 38 39 40 41 42 Identifica defeitos? No Sim No No No No No No Sim Sim NA NA No No

Aps esse planejamento, o estudo foi executado em outubro de 2005 com 4 participantes, escolhidos por convenincia. Estes participantes so alunos de psgraduao e possuem conhecimento no domnio do problema e na aplicao de tcnicas de inspeo.

97

O fato dos participantes possurem esse perfil de conhecimento no oferece risco em relao validade dos resultados que podem ser obtidos com a conduo desse estudo. Na verdade, soba perspectiva destes participantes que se pretende avaliar ArqCheck de acordo com a descrio GQM realizada. Isso se justifica visto que o objeto de estudo a abordagem ArqCheck, alm do mais, pelos participantes possurem conhecimento em tcnicas de inspeo, por exemplo, possvel que o retorno fornecido por eles seja de extrema relevncia para a melhoria da abordagem avaliada. Devido falta de uma abordagem padro para representao arquitetural, foi realizado, antes da execuo do estudo, um treinamento com os participantes sobre a abordagem de representao que foi utilizada para descrever o documento arquitetural a ser avaliado. O principal objetivo na realizao desse treinamento de evitar problemas de entendimento dos participantes em relao simbologia utilizada, o que poderia influenciar na tarefa de identificao de defeitos. Aps isso, os participantes assinaram um formulrio de consentimento de participao do experimento e preencheram um questionrio de caracterizao. Para esse estudo, os dados relacionados experincia dos participantes no foram utilizados para agrupamento por termos poucos participantes, o que no possibilitava a diviso em diferentes grupos, por exemplo. Feito isso, os artefatos necessrios para que a inspeo fosse realizada foram distribudos. Por no estar no objetivo do estudo observar os participantes durante a execuo da inspeo, a inspeo foi conduzida em apenas uma sesso de forma remota, ou seja, os participantes no realizaram a inspeo ao mesmo tempo e nem no mesmo lugar. Contudo, eles foram informados que comentrios entre eles deveriam ser evitados para no prejudicar a validade do estudo. Para cada participante, foi distribudo o checklist de avaliao, o documento arquitetural, o documento de requisitos, o relatrio de discrepncias e o questionrio de ps-experimento, utilizado para obter informaes de ordem qualitativa. Como retorno, eles deveriam retornar ao pesquisador o relatrio de discrepncias preenchido, indicando o tempo que levaram para realizar a inspeo, o checklist com os itens selecionados e o questionrio de ps-experimento preenchido. Nesse estudo no foi necessrio realizar a etapa de Reunio de Inspeo, onde as discrepncias identificadas pelos inspetores so discutidas com o autor do documento visando identificar quais dela so defeitos ou falso-positivos. A principal razo por no ter sido necessria a realizao dessa reunio foi o fato dos pesquisadores conhecerem de antemo os defeitos contidos no documento.

98

5.4.3 Anlise dos dados e resultados obtidos

Durante o planejamento desse estudo foi definido como objetivo principal avaliar a viabilidade de ArqCheck. Essa viabilidade, conforme os questionamentos identificados, seria avaliada atravs da anlise da compreenso dos itens de avaliao do checklist pelos participantes e atravs do auxlio que cada item ofereceu a identificao dos defeitos. A seguir, descrevemos que resultados preliminares foram obtidos para cada um desses questionamentos. Os itens de avaliao que compem o checklist foram totalmente

compreendidos? A avaliao da compreenso dos itens que compem o checklist consistiu em comparar o valor atribudo pelos participantes a cada item de avaliao (S, N, NA) em relao aos valores identificados durante a caracterizao do checklist (Tabela 5.2), que fora realizada pelo pesquisador. Nesse momento, no foi levado em considerao o fato do item ter auxiliado os participantes na identificao de defeitos. Para definir se um item foi compreendido ou no, partimos do princpio que se o participante no atribusse o valor esperado ao item de avaliao, isso seria um possvel indcio de que o item pode no ter sido compreendido. Sendo assim, se um participante tiver identificado um item aplicvel como no aplicvel ou vice-versa, ou ento se o item identificar um defeito, mas ele no tiver marcado de tal forma, considerado que o participante no entendeu corretamente o propsito do item.

Grfico 5.1 - Compreenso dos itens de avaliao

99

Portanto, com base nos dados coletados, foi identificado para cada item a quantidade de participantes que atriburam erroneamente valores para ele. Com isso, foi observado que 8 itens de avaliao no foram compreendidos por pelo menos 3 participantes e por conseqncia precisam ser analisados e possivelmente sofrer melhorias (Grfico 5.1). Esses itens foram: 2, 14, 16, 19, 30, 33, 37, 38 (vide Apndice B.1). Com base nesses dados, foi possvel observar tambm uma outra caracterstica da abordagem proposta: a necessidade das atividades de configurao. Ao analisar os dados em relao compreenso, foi identificado que 80% dos itens no-aplicveis foram marcados como tal (Grfico 5.2), justificando assim a realizao das atividades de configurao. Alm disso, pode ser observado que alguns participantes indicaram alguns itens aplicveis como no-aplicveis. Esses itens, dependendo da quantidade de participantes que o marcaram, sero analisados, pois podem apresentar problemas como, por exemplo, falta de clareza ou no so realmente aplicveis a uma avaliao arquitetural.

Grfico 5.2 - Itens no-aplicveis

Os itens de avaliao que compem o checklist auxiliaram os inspetores na identificao de defeitos? Para avaliar se os itens realmente auxiliaram o inspetor na identificao de defeitos, alm das perguntas realizadas atravs do questionrio de ps-experimento, foi realizada uma anlise dos relatrios de discrepncia de cada participante. Essa anlise identificou que itens levaram cada participante a detectar defeitos e permitiu a

100

comparao desses dados com os obtidos pela caracterizao realizada pelo pesquisador. Sabe-se das limitaes em obter concluses a partir desse tipo de comparao, uma vez que no se pode afirmar que determinado defeito s pode ser detectado pelo item indicado pelo pesquisador. Contudo, essa anlise fornece indcios de itens de avaliao que deveriam ser revistos, principalmente em relao a sua clareza. Alm do mais, visto que no foi possvel realizar agrupamentos dos participantes em relao aos seus nveis de experincia, devido pequena quantidade de participantes, a anlise dos dados em relao a essa perspectiva apresenta fatores de confuso8. Esses fatores ocorrem visto que no possvel determinar se os defeitos so identificados graas ao conhecimento contido no item de avaliao ou ao conhecimento do inspetor obtido atravs de sua experincia. Contudo, mesmo com a presena desse fator, os indcios fornecidos em relao aos itens que auxiliaram na identificao de defeitos so relevantes para a evoluo do checklist. Portanto, aps essa anlise (Grfico 5.3), foi possvel observar que alguns dos itens que o pesquisador caracterizou como identificador de defeitos no auxiliaram os participantes. Os principais itens onde isso ocorreu foram nos identificados com o nmero 2, 12, 14, 19, 30, 37 e 38. Acreditamos que o principal motivo seja a falta de clareza desses itens.

Grfico 5.3 - Itens que auxiliaram na identificao de defeitos

Confounding factors

101

Um outro fato que foi observado ao analisar os resultados obtidos em relao deteco de defeitos foi o elevado tempo de execuo, em mdia 3 horas para a realizao da inspeo. Mesmo sendo um documento arquitetural que representava uma arquitetura com certa complexidade, os participantes j possuam conhecimento em relao ao domnio do problema. Sendo assim, acreditamos que o elevado tempo de inspeo foi ocasionado por itens redundantes, que faziam com que os participantes re-avaliassem o documento buscando defeitos que j haviam sido identificados, e tambm pela presena de itens no-aplicveis, que faziam com que os participantes gastassem uma determinada quantidade de tempo para identificar se o item era realmente no-aplicvel. Os itens redundantes foram classificados como tal por terem sido originalmente definidos com o propsito de detectar determinado tipo de defeito, mas que na prtica identificaram os mesmos tipos de defeitos que outros itens. Os principais grupos de itens redundantes identificado foram: os itens 2, 13 e 14 e os itens 3, 4, e 9. Esses itens foram analisados, e com base nisso foram reescritos ou excludos do checklist.

5.4.4 Consideraes em relao hiptese nula

Ao analisar os relatrios de discrepncias devolvidos pelos participantes do estudo, observou-se que, em mdia, cada participante identificou 30% dos defeitos (Grfico 5.4).

Grfico 5.4 - Defeitos encontrados

Ao analisar as porcentagens individuais dos defeitos inseridos e defeitos reais, percebemos que a porcentagem de defeitos inseridos encontrados por participante

102

bem maior que a de reais. Uma das razes dessa diferena de valores est no fato dos defeitos inseridos terem sido enxertados no documento com o objetivo de avaliar a clareza dos itens, ou seja, os defeitos foram colocados de forma que haveria uma grande possibilidade de eles serem facilmente identificados atravs dos itens. Mesmo no sendo o objetivo desse estudo avaliar a quantidade de defeitos que o checklist auxilia identificar, ao consolidar os relatrios de discrepncias, identificou-se que 75% dos defeitos conhecidos foram encontrados pela abordagem. A diferena entre a porcentagem de defeitos encontrados individualmente e a de defeitos encontrados no total indica que cada participante encontrou poucos defeitos no geral,, mas cada um encontrou defeitos diferentes entre si, o que aumentou a cobertura dos defeitos encontrados. Esses resultados nos fornecem dois indcios: (1) de que a experincia dos inspetores em arquitetura de software e no domnio da soluo influencia nos defeitos detectados, a dependncia da experincia do inspetor uma das principais caracterstica de uma abordagem de inspeo baseada em checklist (SHULL et al., 2000), e (2) dos ganhos que podem ser obtidos ao se alocar mais de um inspetor para esse tipo de avaliao. Sendo assim, a realizao desse estudo no permite refutar totalmente a hiptese de que ArqCheck no permite identificar defeitos arquiteturais, uma vez que no possvel obter resultados relevantes a nvel estatstico, principalmente devido pequena quantidade de participantes. Contudo, esses resultados preliminares fornecem alguns indcios que nos levam a crer nessa possibilidade, principalmente, se for levado em considerao que inspees de software encontram, em mdia, 60% dos defeitos contidos no artefato avaliado (BOEHM, 1981) e que nesse estudo 75% dos defeitos conhecidos foram encontrados.

5.4.5 Lies aprendidas

Com base na anlise das discrepncias identificadas e das respostas do questionrio de ps-experimento, foi possvel identificar: Os itens que necessitavam serem reescritos, por no auxiliarem na identificao de defeitos ou no estarem suficientemente compreensveis; Os itens que poderiam ser excludos do checklist por estar avaliando uma mesma caracterstica vrias vezes. A partir do questionrio de ps-experimento, os participantes opinaram em relao relevncia do checklist na identificao de defeitos arquiteturais. Como resultado, todos concordaram com o auxlio que esse checklist oferece para essa tarefa. Alm do mais, com base nessas informaes foi identificada a necessidade de:

103

Treinamento na utilizao do checklist, principalmente relacionado ao uso das Guias de identificao de contexto, utilizadas durante a avaliao do atendimento aos requisitos de qualidade;

Descrio mais detalhada da taxonomia de defeitos utilizada, fornecendo assim maior auxlio ao inspetor durante a classificao do tipo de defeitos identificado; Definio de um glossrio visando auxiliar na compreenso de conceitos utilizados pelos itens de avaliao; Um mecanismo que permita informar ao inspetor que a atribuio de determinado valor para um item implica na presena de um defeito no documento avaliado. Para isso, foi adicionado nova verso do checklist o campo RE- Resultado esperado;

Alocar mais de um inspetor, quando possvel, para participar desse tipo de avaliao. Aps a evoluo da abordagem com base nos resultados obtidos, o passo

seguinte deveria ser a re-execuo desse estudo, utilizando o mesmo documento arquitetural, mas utilizando participantes diferentes. O principal objetivo dele seria de avaliar se as modificaes permitiram a identificao de uma quantidade maior de defeitos. Contudo, por esse estudo fazer parte de uma pesquisa de mestrado, que deve ser finalizada em um determinado espao de tempo, e ter sido executado em um contexto acadmico, onde existe escassez de participantes, seria necessrio esperar o incio do prximo semestre para possibilitar essa re-execuo, o que seria invivel devido ao prazo de defesa de mestrado. Por isso, assumimos os riscos e realizamos o segundo estudo definido pela metodologia: o estudo de observao.

5.5 Estudo de observao

Um estudo de observao ocorre em um ambiente onde indivduos desempenham tarefas enquanto so observados pelos pesquisadores. O propsito deste estudo coletar dados sobre como essas tarefas so executadas. Desta forma, os pesquisadores podem adquirir uma compreenso mais refinada sobre como a nova tecnologia aplicada na prtica, presenciando eventuais dificuldades que os indivduos podem enfrentar (SILVA, 2004). A coleta de dados num estudo de observao pode se dar de duas formas: observao e investigao (SHULL et al., 2001). Dados de observao so coletados enquanto a abordagem est sendo executada, sem a interferncia do pesquisador. Dados de investigao, por sua vez, so coletados ao trmino de determinada etapa

104

da abordagem, quando os indivduos respondem a perguntas pr-definidas, abordando questes sobre as quais eles, normalmente, no pensariam a respeito. No contexto dessa pesquisa, tratamos esse estudo de observao como um prexperimento, pois um nico objeto foi avaliado atravs de uma comparao com uma baseline, tambm conhecido como elemento de controle (AMARAL, 2003). Nesse estudo, ArqCheck foi aplicada para inspecionar um documento arquitetural que j havia sido previamente inspecionado. Em posse dos defeitos detectados por ArqCheck e os detectados pela abordagem previamente aplicada, desejamos realizar uma comparao desses resultados, visando avaliar a abordagem proposta.

5.5.1 Contexto
A principal caracterstica desse estudo de observao, foi que a avaliao de ArqCheck utilizou um documento arquitetural real, que fora produzido em um projeto de desenvolvimento de software de uma empresa. Para permitir essa troca de informaes academia-indstria, um acordo foi firmado entre o grupo de pesquisa ESE/COPPE/UFRJ e a SIEMENS-AM. A empresa SIEMENS-AM9 um instituto de pesquisa e de desenvolvimento de software da SIEMENS Mobile. Esse instituto possui uma indicao de maturidade em desenvolvimento de software (CMMi nvel 2 e aplica prticas do CMMi nvel 3) e por isso possui conscincia na importncia em validar e verificar os artefatos que produzem durante o processo de desenvolvimento de software. Para a avaliao de seus documentos de projeto, por exemplo, eles aplicam uma abordagem ad-hoc de avaliao, que chamaremos no contexto dessa dissertao de abordagem SIEMENS. Nesse instituto so desenvolvidas aplicaes voltadas para a rea de telefonia celular que devem lidar com todas as limitaes presentes nessa plataforma de desenvolvimento. O acordo firmado entre essas duas instituies, com clusulas de confidencialidade, previa a troca de informaes visando realizao desse estudo, o que possibilitou o acesso dos pesquisadores da COPPE aos documentos de requisitos e de projeto de alguns dos projetos da SIEMENS-AM. O projeto escolhido para ter seus documentos avaliados foi o projeto Application Menu X85. Esse projeto foi escolhido por seus documentos de projeto j terem sido avaliados por abordagens prprias da SIEMENS-AM, o que possibilitava usar os dados dessa avaliao como controle, e foi escolhido tambm por possuir

SIEMENS-AM: Empresa filial da SIEMENS Mobile que atua em Manaus/AM no desenvolvimento de software voltado para aparelhos celulares. Durante a realizao desse estudo, essa filial foi adquirida pela BENQ, mas continuaram no mesmo ramo de atuao.

105

caractersticas de qualidade que obrigaram os arquitetos a utilizarem diversas prticas arquiteturais para projet-las. O propsito desse projeto desenvolver um software que atue como gerenciador do menu de servios de um aparelho celular. Esse gerenciador deve disponibilizar itens de menu, que quando selecionados executam a aplicao correspondente, e deve ser altamente configurvel, para permitir as diferentes customizaes que possam ser requisitadas pelas operadoras de telefonia, o principal cliente desse software. Durante a realizao desse estudo, esse projeto j estava em fase de concluso, com isso o documento de projeto a ser avaliado por ArqCheck j tinha sido avaliado atravs da abordagem SIEMENS. Em relao aos defeitos presentes no documento de projeto, fomos informados somente que o documento que nos foi passado apresenta defeitos. Contudo, para minimizar possveis vieses, no foi informado quais so esses defeitos ou de que tipos so. Esses dados foram repassados somente durante a etapa de anlise dos dados do estudo. Uma outra caracterstica especial que compem o contexto onde esse estudo foi executado o fato de haver restries, principalmente de confidencialidade impostas pelo acordo firmado com a SIEMENS-AM, que implicaram em algumas restries, como por exemplo, a limitao do nmero de participantes. Devido a essa limitao, foi possvel utilizar participantes somente na fase de deteco de defeitos. Para as demais fases, principalmente as que envolviam a atuao do moderador, foi o prprio pesquisador que as executou.

5.5.2 Definio do estudo

Com base nos resultados do estudo previamente realizado, foram identificados indcios que nos levam a crer na viabilidade de ArqCheck em detectar defeitos em um documento arquitetural. Visando amadurecer a abordagem e buscar obter mais indcios que confirmem o que j foi observado at o momento, realizamos um estudo de observao. Nesse estudo, os resultados obtidos pela aplicao de ArqCheck foram comparados com os defeitos detectados pela abordagem SIEMENS, uma abordagem utilizada no contexto industrial em que a arquitetura avaliada pertence. Entretanto, a comparao entre as duas abordagens no era o nosso objetivo principal, ou seja, no visamos identificar qual a melhor abordagem de avaliao. A determinao da melhor abordagem no possvel devido ao fato dos resultados obtidos com a aplicao dessas abordagens em um nico estudo de caso no serem

106

suficientes para tirarmos esse tipo de concluso, e tambm devido ao fato de no termos informaes suficientes para caracterizar, em um primeiro momento, a abordagem SIEMENS. Portanto, o objetivo dessa comparao caracterizar ArqCheck em relao a um baseline. Para esse estudo, o baseline escolhido foi a abordagem SIEMENS por ser a abordagem que de fato est sendo utilizada nesse contexto industrial e por atualmente ser a abordagem da SIEMENS-AM para a melhoria da qualidade de documentos de projetos. Portanto, com esse estudo de observao buscamos criar um corpo de conhecimento que nos permita avaliar a aplicao da abordagem proposta. Alm disso, esperamos que os resultados obtidos, e o corpo de conhecimento construdo decorrente de sua conduo, nos forneam subsdios que permitam evoluir a abordagem para otimizar a sua aplicao tanto em relao ao esforo necessrio para execut-la quanto quantidade e tipo de defeitos que ela permite identificar. Para realizar a comparao entre essas duas abordagens, analisamos principalmente a eficincia e eficcia das duas abordagens. A Tabela 5.3 descreve os objetivos desse estudo de forma mais completa.
Tabela 5.3 - Objetivos do estudo de observao seguindo o mtodo GQM (BASILI et al., 1994) Analisar a abordagem proposta para inspeo de documentos arquiteturais (ArqCheck) Com o propsito de caracterizar Com respeito eficcia e custo/eficincia em identificar defeitos Do ponto de vista dos pesquisadores No contexto de uma inspeo de documento arquitetural que fora criado em um contexto industrial por inspetores com experincia em inspeo

Por eficcia, entendemos a quantidade de defeitos em relao ao nmero total de discrepncias encontradas. Por eficincia, entendemos a quantidade de defeitos identificados por unidade de tempo de inspeo. Com base nesses objetivos, definimos os seguintes questionamentos que procuramos responder durante a execuo do estudo: Q1: Qual a eficcia de ArqCheck no que diz respeito deteco de defeitos? Mtrica: o Eficcia da abordagem = Quantidade de defeitos detectados por ArqCheck / Quantidade de discrepncias identificadas.

107

Eficcia 2 da abordagem = Quantidade de defeitos detectados por ArqCheck e comuns a abordagem SIEMENS/ Quantidade de discrepncias identificadas pela abordagem SIEMENS.

Q2: Qual o custo/eficincia de ArqCheck no que diz respeito deteco de defeitos? Mtricas: o o Custo/Eficincia da abordagem (ArqCheck) = Quantidade de defeitos detectados por participante / Tempo de inspeo do participante Custo/Eficincia da abordagem (SIEMENS) = Quantidade de defeitos detectados / Tempo total de inspeo Com base nas respostas obtidas por esses questionamentos, procuramos refutar

atravs da execuo desse estudo a seguinte hiptese nula: H0: No existe diferena entre os resultados encontrados pela abordagem ArqCheck e a abordagem SIEMENS em relao deteco de defeitos arquiteturais. Informaes adicionais relacionadas definio do estudo, ao seu planejamento e sua execuo podem ser encontradas no Plano do Experimento, descrito no Apndice D dessa dissertao.

5.5.3 Planejamento e Execuo

A realizao desse estudo permitiu a observao da aplicao da abordagem proposta em um documento construdo em um contexto real. Visto que ele j havia sido inspecionado, foi possvel tambm comparar os resultados obtidos pelas duas abordagens e caracterizar ArqCheck em relao aos resultados obtidos pela abordagem SIEMENS. Contudo, durante o planejamento do estudo, algumas tarefas de adaptao tiveram que ser realizadas. Essas tarefas consistiram principalmente na adaptao do documento de projeto fornecido pela SIEMENS-AM s caractersticas que devem estar presentes em um documento arquitetural para que ele possa ser avaliado pela abordagem ArqCheck. Alm disso, visto que a arquitetura descrita nesse documento foi representada atravs da notao UML, itens de avaliao tiveram que ser criados para compor o checklist e permitir a avaliao desse tipo de representao.

108

Adaptaes necessrias O documento de projeto fornecido pela SIEMENS-AM10 composto tanto por informaes referentes ao projeto de alto nvel, representando principalmente informaes a nvel arquitetural, quanto por informaes de projeto de baixo nvel, representados principalmente por diagramas orientados a objetos. Portanto, devido presena de informaes que no so relevantes a nvel arquitetural e que poderiam atrapalhar os inspetores durante a deteco de defeitos, o pesquisador teve que realizar uma anlise desse documento visando identificar as informaes necessrias para aplicar a abordagem de inspeo. Essas informaes, depois de identificadas, foram extradas desse documento e utilizadas na criao de um documento arquitetural11 que foi utilizada na etapa de deteco de defeitos desse estudo. A escolha de que informaes extrair do documento de projeto original foi baseada nas caractersticas que um documento arquitetural deve conter e que so essenciais para permitir a aplicao da abordagem ArqCheck. Sendo assim, procuramos principalmente por: Informaes que permitissem representar o software atravs de diferentes perspectivas (diagramas de subsistemas, diagramas de classe de alto-nvel e diagramas de seqncia de alto nvel); Informaes que justificassem a construo dos elementos arquiteturais e sua organizao, ou seja, uma rastreabilidade entre os elementos arquiteturais e os requisitos do software (Tabela de rastreabilidade com os requisitos); Descrio do papel de cada elemento dentro da arquitetura (Descrio textual dos elementos arquiteturais); Vale lembrar que esse esforo foi necessrio devido falta de consenso presente na comunidade de Arquitetura de Software em relao ao que arquitetura e que tipo de informao relevante para represent-la. Alm do mais, essas informaes estavam presentes no documento disponibilizado pelos arquitetos da SIEMENS-AM, foi necessrio somente extrair as informaes relevantes a nvel arquitetural e criar o documento arquitetural do projeto. Portanto, com base nas informaes extradas foi possvel descrever a arquitetura desse software atravs de trs vises arquiteturais: a viso de contexto geral, a modular e a dinmica. A definio da viso de alocao no foi necessria pois todos

10 11

Visto que esse documento representa informaes reais relacionadas a um dos projetos da SIEMENSAM, ele no pode ser apresentado aqui por motivos de confidencialidade.

O documento arquitetural do projeto AppMenu X85 contm 31 pginas.

109

os elementos arquiteturais estavam alocados em um mesmo n computacional. A seguir descrevemos o que continha cada uma dessas informaes: Viso de contexto geral: Composta por informaes que descrevem a decomposio da aplicao em subsistemas e como os sistemas externos se relacionam com eles; Viso Modular: Composta por informaes que descrevem os elementos arquiteturais que compem a soluo e como eles se relacionam Viso Dinmica: Composta por informaes que descrevem o comportamento dos elementos arquiteturais durante a execuo do sistema. Para a criao dessa viso foram utilizadas principalmente informaes oriundas dos diagramas de caso de uso e de seqncia descritos no documento de projeto. A segunda atividade de adaptao que foi realizada foi a criao de itens adicionais do checklist para avaliar as caractersticas especficas da representao arquitetural utilizada pela SIEMENS-AM (notao UML). Essa atividade no consiste na configurao do checklist, onde os itens existentes so escolhidos de acordo com as caractersticas da inspeo e que uma das atividades executadas durante o processo de inspeo. Ela consiste na criao de itens para avaliar especificamente documentos arquiteturais que so representados de atravs da notao UML. Tivemos que realizar essa atividade pois no tnhamos aplicado ArqCheck para avaliar arquiteturas que utilizassem esse tipo de representao. Os itens que tiveram que ser criados foram principalmente itens utilizados para avaliar a consistncia do documento, uma vez que esses tipos de itens, conforme descrito no Captulo 4, so especficos abordagem de representao utilizada. O processo de criao foi divido em duas atividades. Em um primeiro momento procuramos adaptar os itens existentes aos conceitos presentes na notao UML. Aps isso, analisamos a notao UML e procuramos identificar as regras de consistncia semnticas existentes entre os diferentes diagramas que a compem. Essa anlise foi baseada principalmente nas heursticas de rastreabilidade presentes nas tcnicas para leitura horizontal da famlia de tcnicas de leitura OORTs (TRAVASSOS et al., 2002), pois um de seus objetivos avaliar a consistncia entre diagramas UML de um projeto. Como resultado desse processo de adaptao do checklist 12 novos itens de avaliao foram criados. Contudo, eles so utilizados somente quando se deseja avaliar um documento representado atravs da notao UML. Essa escolha feita durante o planejamento da inspeo, atravs das atividades de configurao do checklist.

110

Execuo do estudo A proposta desse estudo de realizar a execuo de todo processo de inspeo que compem a abordagem proposta. Contudo, devido s limitaes impostas pelo contexto em que esse estudo foi realizado, nem todas as atividades puderam ser realizadas, principalmente as que exigiam a presena dos autores do documento, pela impossibilidade de utilizar profissionais da SIEMENS-AM durante sua execuo. Sendo assim, as atividades que puderam ter certo controle nas suas execues, permitindo a realizao de algum tipo de observao e investigao foram as atividades de planejamento e deteco de defeitos. A atividade de planejamento foi realizada pelo prprio pesquisador. Somente na atividade de deteco de defeitos que os participantes foram acionados. Esse estudo de observao foi conduzido em Fevereiro de 2006, seguindo o processo de inspeo definido por ArqCheck, onde a primeira atividade a ser realizada a de planejamento da inspeo. Durante esse planejamento, os inspetores foram escolhidos e o checklist foi configurado para atender s caractersticas do documento arquitetural e atender aos objetivos da inspeo. Visto que o estudo foi realizado em um ambiente acadmico, os inspetores escolhidos foram estudantes de ps-graduao em Engenharia de Software. Contudo, devido s restries impostas pelo acordo de confidencialidade estabelecido com a SIEMENS-AM, o nmero de inspetores se limitou a dois indivduos. Esses inspetores j haviam aplicado ArqCheck, durante a realizao do estudo de viabilidade, portanto eles j possuam conhecimento da abordagem de inspeo utilizada. Alm do mais, conforme pode ser visto na Tabela 5.4, eles possuem conhecimento em inspeo de software, em arquitetura de software, mas nunca atuaram no domnio de desenvolvimento de software para aparelhos mveis. Em relao a deteco de defeitos, alm dos participantes, o pesquisador tambm aplicou ArqCheck no documento visando obter dados de observao para serem utilizados durante a anlise dos resultados. Contudo, os defeitos por ele identificados foram isolados e no sero utilizados durante a anlise dos dados do estudo para evitar possveis vieses nos resultados da avaliao. Em relao configurao do checklist, visto que o documento arquitetural foi descrito atravs de trs vises arquiteturais (contexto geral, modular e dinmica) e que os diagramas que descrevem essas vises foram representadas atravs da UML, somente os itens referentes a essas vises e a essa abordagem de descrio foram selecionados.

111

Tabela 5.4 - Conhecimento e habilidades dos inspetores Experincias Inspetor S1 Com Trabalhou 3 anos como desenvolvimento programador em uma de software empresa que desenvolvia software para web e vem desenvolvendo software a 5 anos no meio acadmico. Em projeto Praticou em 1 projeto em arquitetural sala de aula Em leitura de documento arquitetural Em desenvolver projetos a partir de requisitos e casos de uso Em projetos Orientados a Objetos Com UML Com inspees de software Em desenvolvimento de software para celular Praticou em 1 projeto em sala de aula Praticou em 1 projeto em sala de aula Praticou em projetos em sala de aula Usou em 1 projeto na indstria Praticou em 1 projeto em sala de aula Nenhum Inspetor S2 Trabalhou por 13 anos como programador, analista de sistemas e coordenador de projetos na indstria Usou em vrios projetos na indstria Praticou em 1 projeto em sala de aula Usou em vrios projetos na indstria Usou em vrios projetos na indstria Usou em vrios projetos na indstria Praticou em 1 projeto em sala de aula Nenhum Pesquisador Trabalhou dois anos com desenvolvimento de software para desktop Usou em vrios projetos na indstria Praticou em 1 projeto em sala de aula Usou em vrios projetos na indstria Usou em vrios projetos na indstria Usou em vrios projetos na indstria Praticou em 1 projeto em sala de aula Estudou em aula ou em livro

Em relao avaliao dos requisitos de qualidade, havia principalmente um requisito de modificabilidade que os profissionais da SIEMENS-AM desejavam garantir o correto atendimento, por isso somente itens que avaliam esse tipo de requisito foram selecionados para compor o checklist a ser utilizado durante a inspeo (Figura 5.3). Com isso, o checklist utilizado nesse estudo possua 22 itens de avaliao. A atividade de Deteco foi conduzida em apenas uma sesso de forma remota, ou seja, os participantes no realizaram a inspeo ao mesmo tempo e nem no mesmo lugar. Nessa sesso, os candidatos responderam ao Formulrio de Caracterizao visando identificar a competncia e a experincia relacionada ao propsito do estudo, alm de se buscar identificar o conhecimento do participante no domnio do problema ao qual o artefato inspecionado pertence. Aps a caracterizao, os participantes receberam uma descrio sobre a abordagem ArqCheck, onde os principais conceitos relacionados aplicao dessa abordagem para a deteco de defeitos estavam descritos. Alm disso, foi distribudo o documento arquitetural a ser avaliado, o documento de requisitos utilizado durante a inspeo, o checklist de avaliao configurado e um relatrio de discrepncias que deveria ser preenchido a medida que o participante

112

identificar discrepncias no artefato avaliado. No existe um limite de tempo para que essa avaliao seja realizada, mas solicitamos que os participantes indicassem quanto tempo levaram para realizar a atividade de deteco.

Figura 5.3 Exemplo de itens do checklist utilizado no estudo de observao

Aps a concluso do estudo, foi pedido a cada indivduo que preenchesse o Questionrio de Avaliao Ps-Experimento, para que obtenhamos a sua avaliao qualitativa a respeito da aplicao da abordagem ArqCheck, e dos procedimentos do estudo experimental. De posse dos Relatrios de Discrepncia gerados por cada participante, o pesquisador consolidou os dados e enviou aos profissionais da SIEMENS-AM para que eles nos retornassem quais eram realmente defeitos e uma lista dos defeitos encontrados pela abordagem SIEMENS. Com base nesses dados, pudemos realizar uma anlise visando refutar, ou no, a hiptese definida nesse estudo e identificar lies aprendidas.

5.5.4 Anlise dos dados e resultados obtidos

A anlise descrita nessa seo foi realizada com base em dados: (1) disponibilizados pela SIEMENS-AM (dados de controle) referente utilizao da

113

abordagem SIEMENS na avaliao do documento de projeto, e (2) obtidos atravs do estudo de observao (dados de observao e de investigao), onde o documento arquitetural criado a partir desse documento de projeto foi inspecionado atravs da abordagem ArqCheck. Com base nesses dados, procuramos realizar uma anlise de ordem quantitativa e qualitativa da abordagem ArqCheck, e tambm uma caracterizao da abordagem proposta em relao abordagem SIEMENS.

Anlise quantitativa
Originalmente, eram esperadas como retorno da SIEMENS-AM informaes

relacionadas aos resultados das revises que foram realizadas no documento de projeto que nos foi passado. Contudo, no foi possvel obtermos tais informaes. Como retorno, obtivemos somente resultados de revises que foram realizadas em verses anteriores do artefato que avaliamos. Sendo assim, esses dados disponibilizados criaram o seguinte cenrio: durante o estudo de observao, ArqCheck avaliou um documento que foi melhorado atravs da correo dos defeitos encontrados pela abordagem SIEMENS. Esse fato fez com que alguns dos questionamentos que definimos durante o planejamento do estudo no pudessem ser respondidos e inviabilizou tambm refutar a hiptese nula da forma como foi definida. Contudo, semelhante a um estudo experimental onde cenrio similar foi utilizado (BERLING e THELIN, 2004), com base nos dados que foram coletados durante o estudo e os resultados fornecidos pela SIEMENS-AM, ainda foi possvel realizar algumas consideraes. A seguir os dados obtidos durante os diferentes tipos de coletas esto descritos e a anlise sobre eles foi realizada. Dados de controle Os dados de controle consistem em dados reais obtidos atravs da realizao de duas revises no contexto do projeto AppMenu X85 e que foram disponibilizadas pela SIEMENS-AM. A primeira reviso consiste em um walkthrough realizado por uma equipe de 4 profissionais (um autor, um moderador e dois especialistas no domnio da soluo). A avaliao realizada atravs desse walkthrough foi realizada durante uma nica sesso, onde o documento avaliado foi apresentado pelo autor. Aps essa apresentao, os especialistas realizaram uma anlise do documento de projeto em relao aos requisitos especificados.

114

A segunda reviso foi realizada com o objetivo de comparar o que estava especificado no documento de projeto e a forma como a soluo foi realmente implementada, visando deixar a arquitetura coerente com essa soluo. Contudo, as caractersticas e objetivos dessa reviso so diferentes em relao aos de ArqCheck, que busca avaliar o documento arquitetural em relao aos requisitos que foram especificados. Portanto, optamos por no utilizar na comparao entre as abordagens os dados obtidos nessa segunda reviso. Com isso, a partir das informaes do walkthrough foi possvel extrair medidas para as seguintes mtricas: Quantidade de inspetores que participaram nas revises; Tempo gasto com a reviso arquitetural; Quantidade de defeitos encontrados no documento; Vale ressaltar que o documento de projeto avaliado pelo walkthrough composto tanto por informaes arquiteturais quanto por informaes de projeto de baixo-nvel, tipo de informao que no avaliado por ArqCheck. Portanto, para ser possvel utilizar esses dados referentes a abordagem SIEMENS como dados de controle, foi necessrio a realizao de uma anlise visando identificar quais dos defeitos detectados so defeitos arquiteturais. Baseado no custo/eficincia da abordagem (quantidade de defeitos encontrados por tempo de inspeo), foi possvel estimar a durao total da reviso se ela tivesse avaliado somente as informaes arquiteturais (Tabela 5.5).
Tabela 5.5 - Dados de controle (baseado nos resultados obtidos com a abordagem SIEMENS) Quantidade de inspetores Tempo gasto com a reviso Quantidade de defeitos detectados Custo/eficincia 2 4 horas 5 1,25 defeitos/hora

Dados de observao Durante a inspeo, cada inspetor preencheu um relatrio com as discrepncias por eles identificadas. Em posse desses dados, o pesquisador fez uma consolidao deles, buscando identificar discrepncias comuns aos inspetores ou ento discrepncias que com certeza seriam falsos positivos. As discrepncias que puderam ser classificadas pelo pesquisador como falsopositivo estavam relacionadas principalmente a informaes de projeto de baixo nvel que ficaram documento arquitetural, aps a adaptao do documento de projeto, e que acabaram sendo identificadas pelo checklist, mas que no faziam parte do escopo da avaliao.

115

Portanto, aps a consolidao dessas discrepncias, esse relatrio consolidado foi enviado para os profissionais da SIEMENS-AM que identificaram as discrepncias que so consideradas defeitos ou no. Com base no retorno fornecido pela empresa, podemos extrair medidas para as seguintes mtricas definidas durante o planejamento do estudo: Quantidade de discrepncias identificadas por participante; Quantidade de defeitos detectados por participante; Tempo gasto por cada participante com a avaliao do documento; Quantidade de defeitos detectados por ArqCheck. A etapa de deteco de defeitos com ArqCheck foi realizada por dois participantes (Tabela 5.6) e pelo pesquisador (Tabela 5.7). Esses indivduos realizaram o papel de inspetores.
Tabela 5.6 - Dados obtidos durante a inspeo realizada pelos inspetores Inspetores Discrepncias Defeitos Falsos positivos Tempo gasto Custo/Eficincia Quantidade total de defeitos S1 72 45 27 6 horas 7,5 defeitos/hora S2 45 26 19 3,75 horas 6,93 defeitos/hora 47

Aps a analise desses dados, percebemos que mesmo o documento avaliado por ArqCheck tendo j sido corrigido, com base nos defeitos encontrados pela abordagem SIEMENS, uma grande quantidade de defeitos ainda foi encontrada.
Tabela 5.7 - Dados obtidos durante a inspeo realizada pelo pesquisador Inspetores Discrepncias Falsos positivos Defeitos Tempo gasto Custo/Eficincia Pesquisador 41 14 2 2,3 horas 11,7 defeitos/hora

Contudo, existem algumas limitaes em se comparar os dados obtidos atravs da aplicao da abordagem SIEMENS e a abordagem ArqCheck, uma vez que avaliaram verses diferentes do documento. Contudo, a anlise e a comparao desses dados, permitiram a observao de alguns fatos. 1. Viabilidade da abordagem ArqCheck em identificar defeitos No primeiro estudo experimental, realizado para avaliar a viabilidade da abordagem ArqCheck, um dos pontos investigados foi a capacidade da abordagem em detectar defeitos.

116

Mesmo no sendo o objetivo desse estudo, os resultados obtidos justificaram essa viabilidade uma vez que os prprios profissionais da SIEMENS-AM identificaram que muitas das discrepncias identificadas eram defeitos. 2. Eficcia de ArqCheck Em relao eficcia de ArqCheck, os participantes tiveram uma eficcia em mdia de 60% (Grfico 5.5). Esses resultados no so satisfatrios uma vez que um esforo relativamente alto foi gasto na identificao das discrepncias mas 40%, em mdia, no auxiliaram na melhoria da qualidade do documento avaliado. Um dos principais motivos que levou a esse resultado foi a adaptao do documento de projeto s caractersticas exigidas para a aplicao de ArqCheck. Mesmo aps a realizao desse processo, muitas informaes que no possuam relevncia a nvel arquitetural continuaram no documento, o que levou os inspetores a identificar um excessivo nmero de discrepncias relacionadas a informaes contidas no documento que no pertenciam ao escopo da avaliao.

Grfico 5.5 - Eficcia (defeitos/discrepncias) de cada participante

Alm disso, quando os defeitos encontrados por cada participante so comparados entre si (Figura 5.4). Identificamos uma grande disparidade nos dados obtidos pelo participante S1, principalmente em relao ao nmero de defeitos exclusivamente encontrados por ele. Ao realizarmos uma comparao entre os defeitos encontrados pelos participantes e pelo pesquisador (Figura 5.5), essa disparidade se mantm. Ao analisarmos os demais dados relacionados principalmente ao tempo de inspeo e realizarmos uma entrevista onde questionamos como esse participante realizou esse processo, observamos que devido a diversos motivos ele no pode realizar a deteco de defeitos de uma vez.

117

Figura 5.4 - Interseo entre os defeitos encontrados pelos participantes

Sendo assim, devido necessidade de interromper e retomar a realizao dessa atividade por diversas vezes, ele acabou tendo que reavaliar vrias vezes determinadas partes do documento e alm do mais a realizao de inspees curtas diminuiu os efeitos negativos da fadiga, observados quando se realiza uma inspeo por um longo perodo de tempo.

Figura 5.5 - Interseo entre os defeitos encontrados pelos participantes e pelo pesquisador

3. Custo/Eficincia de ArqCheck em relao abordagem SIEMENS Embora o documento avaliado por ArqCheck tenha sido previamente corrigido com base nos defeitos encontrados pela abordagem SIEMENS-AM, uma grande quantidade de defeitos foi detectada durante essa segunda avaliao. Alm disso, um outro dado que chama a ateno est quando se compara o custo/eficincia das duas abordagens (SIEMENS = 1,25 defeitos/hora; ArqCheck = 7 defeitos/hora), sendo que o tempo gasto por cada uma delas se encontra em uma mesma ordem de grandeza. Uma das explicaes para essa disparidade est no apoio que cada uma das abordagens oferece para a tarefa de deteco de defeitos. A abordagem SIEMENS consiste basicamente em uma abordagem ad-hoc, onde nenhum apoio fornecido aos inspetores, o que torna os resultados dependentes da experincia do inspetor tanto no domnio da soluo quanto na realizao desse tipo de reviso. Contudo, a abordagem ArqCheck apia a deteco de defeitos atravs de um checklist, que fornece uma direo aos inspetores em relao ao que avaliar.

118

Com isso, uma indicao que podemos ressaltar em relao a esses dados que a abordagem SIEMENS, embora esteja contribuindo para a melhoria da qualidade, pode precisar ser ajustada para a realizao dessa tarefa ou ento no esteja sendo aplicada com tempo ou treinamento suficientes. Alm do mais, o fato das duas abordagens consumirem uma quantidade de recursos semelhante, tanto em relao ao tempo de inspeo quanto em relao quantidade de pessoas envolvidas no processo, fornece alguns indcios que apontam para a viabilidade em se implantar ArqCheck no contexto industrial avaliado. Dados de investigao Os dados de investigao so utilizados principalmente durante a anlise qualitativa do objeto em estudo. Esses dados foram coletados a partir de trs fontes: pesquisador, participantes e profissionais da SIEMENS-AM. O pesquisador forneceu dados tanto em relao aplicao do processo de configurao do checklist, quanto em relao deteco de defeitos. Os participantes forneceram informaes relacionadas aplicao da abordagem na deteco de defeitos. Para colet-las, utilizamos como base o questionrio de avaliao ps-experimento (Apndice E). Nesse questionrio buscou-se identificar: Os aspectos que facilitam ou dificultam o uso da abordagem; A opinio dos participantes em relao a utilidade da abordagem e se eles a utilizariam em uma avaliao arquitetural; Os profissionais da SIEMENS-AM forneceram informaes principalmente relacionadas aos resultados obtidos e as expectativas que eles tinham em relao aplicao da abordagem ArqCheck. Com isso, aps realizarmos uma consolidao desses resultados, identificamos que os inspetores, por exemplo, consideram mediana a utilizao da abordagem ArqCheck. Eles a consideraram como tal devido principalmente dificuldade de se utilizar essa abordagem na avaliao de documentos arquiteturais grandes. Essa dificuldade est relacionada ao fato do checklist que compem ArqCheck possuir itens de avaliao que avaliam a consistncia das informaes entre as diferentes vises arquiteturais, o que dependendo do tamanho do documento implica em vrias verificaes que devem ser realizadas, o que acaba tornando a inspeo cansativa e pode influenciar negativamente o resultado final da avaliao. Contudo em relao s facilidades, os seguintes aspectos por eles foram apontados em relao a abordagem:

119

Permite um mapeamento automtico/direto para o tipo do erro, no deixando duvidas em relao a isto; de fcil entendimento, pois os itens deixam claro o escopo que deve ser analisado Possui uma boa organizao, e pode ser utilizado com um passo a passo, pois normalmente o conhecimento utilizado em um item, auxilia na avaliao realizada no item seguinte, o que facilita a realizao de cross-checking.

Em relao aos comentrios fornecidos pelos profissionais da SIEMENS-AM, o que se destaca foi o fato da quantidade de defeitos que foram encontrados, principalmente devido ao fato do documento j ter sido avaliado.

5.5.5 Consideraes em relao hiptese nula

Devido ao fato de no termos dados que permitam uma comparao direta entre as abordagens ArqcCheck e SIEMENS, no foi possvel tecer algum tipo de concluso em relao hiptese nula, definida durante o planejamento do estudo de observao. Contudo, os dados coletados durante esse estudo e as anlises que puderam ser realizadas no diminuem a importncia que foi a sua realizao pois com base neles foi possvel obter indcios em relao viabilidade de aplicar ArqCheck no contexto industrial avaliado, identificar pontos de melhorias permitindo a evoluo da abordagem e tambm a oportunidade de se observar a utilizao da abordagem proposta para avaliar um documento arquitetural criado em um contexto industrial.

5.5.6 Lies aprendidas

As lies aprendidas podem ser divididas principalmente em duas categorias. A primeira consiste em informaes que auxiliaram na evoluo da abordagem. Uma das melhorias identificadas foi a necessidade da descrio do passo-a-passo a ser seguido durante a configurao do checklist. Durante o estudo, percebemos que tal tarefa est muito dependente do conhecimento tcito do pesquisador em realizar essa tarefa e que a descrio desse passo-a-passo facilitaria a realizao dessa atividade por outros. Outra melhoria identificada est relacionada ao Guia de identificao de contexto utilizado pelo inspetor como auxlio para a avaliao do documento em relao ao atendimento dos requisitos de qualidade pela arquitetura. Esses guias no estavam sendo totalmente compreendidos, o que dificultou os inspetores na realizao desse tipo de avaliao. Como soluo para melhorar esse entendimento, definimos que durante a configurao do checklist, o moderador da inspeo, com o auxilio do autor do documento, deve realizar a identificao do contexto a ser avaliado, deixando a

120

cargo do inspetor somente a avaliao da conformidade dos elementos arquiteturais em relao aos requisitos de qualidade indicados. Alm dessas melhorias, evolumos os itens de avaliao 8, 9, 10, 11 e 18 (vide Apndice B.2) pois no estavam sendo totalmente compreendidos. A segunda categoria de lies aprendidas consiste principalmente de observaes que foram realizadas durante esse estudo e que indicam prximos passos a serem seguidos para se ter uma caracterizao mais completa de ArqCheck. Um dessas observaes est na dificuldade apresentada pelos inspetores na avaliao de um documento arquitetural maior. Devido a grande quantidade de verificaes a serem feitas com a utilizao da abordagem, acreditamos que uma forma mais eficiente de utilizar a abordagem seria alocando inspetores, de acordo com os nveis de experincia, para avaliar a arquitetura utilizando somente uma parte do checklist. Acreditamos que indivduos que possuam mais experincia em leitura de documentos arquiteturais poderiam avaliar a consistncia das informaes entre as diferentes vises arquiteturais e indivduos com mais experincia em projeto arquitetural poderia ser alocada para avaliar como a arquitetura est atendendo os requisitos especificados pelo cliente. Uma outra observao que foi feita em relao aos resultados obtidos foi a quantidade de defeitos detectados pelo participante que teve que interromper a avaliao por diversas vezes e, por conseqncia, avaliar diversas vezes determinadas partes do documento. Uma hiptese inicial do que tenha influenciado esse resultado seja o fato dele no ter sido vtima do desgaste observado quando se inspeciona um documento por um grande perodo de tempo. Contudo estudos experimentais deveriam ser realizados para procurar responder a esses questionamentos.

5.6 Concluso
O desenvolvimento de tecnologias de software apoiadas por experimentao tem demonstrado ser uma abordagem adequada, podendo dar um diferencial de qualidade e crdito s tecnologias que vm sendo desenvolvidas na academia. Por esse motivo que para avaliar a abordagem proposta, descrita nesse captulo, realizamos estudos experimentais, utilizando principalmente como base conceitos de uma metodologia para a transferncia de tecnologias para a indstria. A transferncia de tecnologias criadas em um contexto acadmico para um contexto industrial no uma tarefa trivial. Grande parte de seu sucesso depender da cooperao entre as diferentes instituies.

121

Esse tipo de cooperao, como a existente entre o grupo ESE/COPPE/UFRJ e a empresa multinacional SIEMENS, representada atravs de seu instituto de pesquisa instalado em Manaus/AM, possibilita que os pesquisadores tenham acesso e realizem estudos usando informaes produzidas em um ambiente real e no acadmico. Esse fato permite a pesquisa por tecnologias que atendam s necessidades da indstria e diminua o gap existente entre estado da arte e o estado da prtica. Portanto, atravs dos estudos que foram realizados at o momento conseguimos identificar a viabilidade da abordagem na identificao de defeitos e tambm a sua eficcia e custo/eficincia, uma vez que permite identificar defeitos no mnimo de forma to eficiente e eficaz que uma abordagem utilizada no estado da prtica. Contudo acreditamos, mesmo com todos os avanos, melhorias e maturidade obtidos atravs dos estudos realizados, ser aconselhvel a realizao dos dois estudos restantes, de acordo com a metodologia de transferncia utilizada como base, para que se avalie a utilizao da abordagem como um todo dentro de um processo de desenvolvimento, visando identificao de melhorias adicionais e o seu completo amadurecimento. O planejamento desses estudos de caso dever considerar principalmente as caractersticas de ciclo de vida presentes em um contexto industrial. Como exemplo, poderia se utilizar as caractersticas presentes no ambiente para desenvolvimento de software da SIEMENS-AM. Desta forma, o primeiro estudo deve avaliar principalmente o impacto da introduo de um processo completo de inspeo no contexto do processo de desenvolvimento e o segundo consistiria de um estudo piloto na indstria onde ArqCheck seria avaliada de forma on-line, para um projeto em andamento.

122

Captulo 6 Concluses
Nesse captulo so apresentadas as concluses deste trabalho, relatando as suas contribuies, limitaes e perspectivas futuras.

6.1 Consideraes finais

Com o aumento da complexidade dos sistemas, a avaliao arquitetural est sendo cada vez mais usada visando principalmente a identificao e correo de defeitos o mais cedo possvel dentro do processo de desenvolvimento de software. Nos ltimos anos, temos observado que essa prtica no se restringe mais somente ao contexto acadmico, ela est sendo cada vez mais adotada em ambientes industriais (MARANZANO et al., 2005). Contudo, so poucas as abordagens de avaliao arquitetural que esto sendo realmente aplicadas, o que identificamos so principalmente tcnicas ad-hoc criadas com base nas caractersticas especficas do contexto em que so aplicadas. Durante a pesquisa que resultou nessa dissertao identificamos, atravs de reviso sistemtica, abordagens de avaliao arquitetural descritas na literatura, caracterizamos essas abordagens visando identificar seus benefcios e limitaes. Com base nesses dados, sugerimos uma abordagem de avaliao arquitetural que permitisse minimizar essas limitaes e avaliamos essa abordagem atravs de uma srie de estudos experimentais visando, principalmente, a sua transferncia para um contexto industrial. A realizao dessa pesquisa se destaca pela forma como foi realizada. Utilizando vrios conceitos oriundos da Engenharia de Software Experimental, fizemos uso de revises sistemticas para identificar as abordagens existentes de forma objetiva e realizamos estudos experimentais para avaliar a abordagem proposta. Alm disso, fizemos uso de conhecimentos identificados em diversas abordagens de projeto e documento arquitetural na construo da abordagem de avaliao arquitetural proposta. Com isso, construmos uma abordagem que visa a inspeo de documentos arquiteturais atravs do uso de um checklist. Essa abordagem foi criada aps a observao de que as abordagens descritas na literatura no atendiam a requisitos essenciais para o sucesso de uma tecnologia em um ambiente industrial.

Esses requisitos foram identificados com base em condies normalmente presentes em ambientes industriais e que podem influenciar na adoo de uma determinada tecnologia dentro desse contexto (SHULL et al., 2001). Com isso, ArqCheck foi desenvolvida visando: Generalidade: Por generalidade entendemos a possibilidade da abordagem ser aplicada em diferentes contextos de avaliao. Em relao abordagem proposta, devido ao fato da abordagem proposta de permitir avaliar principalmente a informao contida no documento arquitetural e no a abordagem de representao usada para descrever essas informaes, consideramos que ela genrica o suficiente para poder ser utilizada em diferentes contextos. Adaptabilidade: Alm de permitir uma avaliao genrica, a abordagem proposta pode ser adaptada s caractersticas especificas do documento. Essa adaptao feita principalmente atravs das atividades de configurao que permitem configurar o checklist de acordo com as caractersticas do documento a ser avaliado; Simplicidade: A abordagem proposta no necessita da execuo de atividades elaboradas atividades para sua aplicao, da necessidade de tipos de conhecimento especficos ou da alocao de grandes quantidades de recursos, sendo assim aparentemente simples de ser aplicada em um projeto; Extensibilidade: Por extensibilidade entendemos a necessidade de uma abordagem permitir que novos conceitos, que no tinham sido previstos durante a criao da abordagem, sejam avaliados. No contexto da abordagem proposta, ela possui essa extensibilidade, que feita a partir da adio de novos itens de avaliao;

6.2 Contribuies
Com base no que foi realizado durante essa pesquisa, identificamos que as principais contribuies que ela pode oferecer comunidade de Arquitetura de Software so: Identificao das principais abordagens de avaliao arquitetural descritas na literatura. Atravs da realizao de uma reviso sistemtica nas principais fontes de publicaes disponveis, identificamos as 27 principais abordagens de avaliao arquitetural, diferente das publicaes com o mesmo propsito na literatura que no descrevem mais de 8 abordagens. Devido ao tipo abordagem de pesquisa que utilizamos, possvel tambm que qualquer pesquisador repita essa pesquisa, utilizando o protocolo de reviso sistemtica criado (Apndice A);

124

Caracterizao das abordagens. Com base nas principais caractersticas que compem uma abordagem de inspeo de software, definimos um framework de caracterizao. Atravs desse framework e das informaes coletadas atravs da reviso sistemtica foi possvel caracterizar as abordagens identificadas, permitindo um maior entendimento de cada uma delas e a identificao de seus benefcios e limitaes;

Abordagem para inspeo de documentos arquiteturais baseada em checklist. Visando a criao de ArqCheck principalmente trs estudos foram realizados; (1) anlise das principais limitaes presentes nas abordagens de avaliao arquitetural descritas na literatura, (2) anlise do processo de especificao arquitetural e das principais abordagens que podem ser utilizadas para realiz-lo e (3) estudo sobre as abordagens de inspeo de software. Com base nos resultados obtidos aps esses estudos, criamos uma abordagem para inspeo arquitetural que visa avaliar documentos arquiteturais. Essa avaliao feita atravs de um checklist que teve seus itens criados a partir dos tipos de conhecimentos utilizados durante a especificao arquitetural.

Planejamento e execuo de estudos experimentais visando a avaliao e a transferncia dessa tecnologia para a industria. Alm da criao da abordagem, planejamos e executamos estudos experimentais para avaliar a viabilidade e o custo/eficincia da abordagem proposta e transferir essa tecnologia para um contexto industrial. Em relao a esses estudos, eles confirmaram tanto a viabilidade quanto ao custo/eficincia da abordagem. Vale lembrar tambm, que alm de documentos arquiteturais criados em contexto acadmico, utilizamos tambm durante esses estudos documentos arquiteturais reais, construdos no contexto de projetos da empresa SIEMENS-AM, o que nos forneceu resultados preliminares sobre a adaptabilidade e extensibilidade da abordagem.

6.3 Limitaes
Ao analisar a abordagem proposta identificamos algumas limitaes. Uma delas se relaciona ao tipo de conhecimento utilizado como base para a sua criao, as tticas arquiteturais. Alm de usarmos somente esse tipo de conhecimento para avaliar o atendimento aos requisitos de qualidade, o que pode ser uma avaliao limitada dependendo do contexto em que ela for usada, no foi possvel criar itens de avaliao para todas as tticas descritas em (BASS et al., 2003). Esses itens no foram criados, pois muitas das tticas no eram relevantes para a arquitetura do software, mas sim para a

125

arquitetura do sistema, o que envolvia a necessidade de soluo via hardware, que estava fora do escopo da pesquisa. Mesmo assim, por causa disso no possvel assegurar que todas as caractersticas da arquitetura sero avaliadas e que a abordagem permite identificar todos os tipos defeitos. Contudo essa limitao pode ser superada com a criao de novos itens utilizando principalmente o conhecimento de especialistas da rea. Alm disso, os estudos realizados forneceram somente resultados preliminares, e no conclusivos, sobre a abordagem avaliada. Isso ocorreu por no termos um controle adequado em grande parte das variveis envolvidas nos estudos. Como por exemplo, nem todos os itens que compem o checklist puderam ser avaliados pela impossibilidade de se obter arquiteturas de software que possussem caractersticas relacionadas disponibilidade ou testabilidade e que poderia ser usadas em experimentos que avaliaram a aplicabilidade dos itens relacionados. Alm disso, a quantidade de participantes nos estudos no permitiu a obteno de resultados relevantes a nvel estatstico. Ainda em relao aos estudos experimentais, a metodologia experimental de transferncia tecnolgica no foi totalmente executada e, como resultado, os estudos que previam um maior controle sobre as variveis envolvidas no foram realizados. Em relao aplicao da abordagem proposta no estado da prtica identificamos dois pontos que podem limitar o contexto onde ela pode ser utilizada: Acreditamos que para a sua aplicao, seja necessrio que antes de tudo a empresa sinta a necessidade de realizar esse tipo de avaliao. Para isso, a empresa j deve ter a maturidade requerida para a realizao de atividades relacionadas a validao e verificao dos artefatos produzidos, caractersticas comuns a empresas que possuem CMMi nvel 3 / MpsBr nvel C. A necessidade de descrever a arquitetura atravs de um documento arquitetural que atenda as necessidades requeridas por ArqCheck. Como vimos no estudo de viabilidade, muitas vezes essas informaes esto juntas com informaes de projeto de baixo-nvel e criar um documento somente com informaes relevantes a nvel arquitetural pode exigir recursos adicionais e defeitos podem ser inseridos durante essa criao.

6.4 Trabalhos Futuros

Em curto prazo, as prximas atividades de pesquisa relacionadas a ArqCheck sero realizadas visando principalmente a execuo das etapas restantes da metodologia experimental proposta por (SHULL et al., 2001). Esse direcionamento foi

126

definido visando principalmente amadurecer a abordagem proposta e introduzi-la em um contexto industrial. Contudo, em longo prazo pensamos principalmente na melhoria dos itens de avaliao, utilizando principalmente conhecimento oriundo de especialistas em diferentes reas da qualidade de software, como usabilidade e desempenho, por exemplo. Alm disso, um outro trabalho que pode ser feito relacionada construo de uma ferramenta de apoio s atividades do processo de inspeo que compem a abordagem proposta. Uma possvel soluo seria utilizar a ferramenta ISPIS (KALINOWSKI, 2004) visto que ela apia grande parte dessas atividades. Contudo, seria necessrio fazer uma anlise dessa ferramenta visando identificar como ela poderia apoiar computacionalmente as atividades especficas da abordagem proposta, como por exemplo, a configurao do checklist.

127

Referncias Bibliogrficas
ABOWD, G., PITKOW, J., KAZMAN, R., 1996, "Analyzing differences between Internet information system software architectures". In: Proceedings of the International Conference on Communications, v. 1, pp. 203-207, Dallas, TX, June. ABOWD, G., BASS, L., CLEMENTS, P., KAZMAN, R., NORTHROP, L., ZAREMSKI, A., 1997, Recommended Best Industrial Practice for Software Architecture Evaluation, SEI, Carnegie Mellon University, Relatrio Tcnico, CMU/SEI-96-TR025. ABOWD, G.D., 1995, "Defining reference models and software architectural styles for cooperative systems", ACM SIGOIS Bulletin, v. 15, n. 3 (Abril), pp. 4-5. ACM, 2004, "Association for Computing Machinery (ACM) Digital Library". In:

http://portal.acm.org/dl.cfm Acessado em Dezembro / 2005.

AMARAL, E.A.G., 2003, Empacotamento de Experimentos em Engenharia de Software, Dissertao de Mestrado, Programa de Engenharia de Sistemas e Computao - COPPE/UFRJ, Rio de Janeiro. AURUM, A., PETERSSON, H., WOHLIN, C., 2002, "State-of-the-art: software inspections after 25 years", Software Testing, Verification and Reliability, v. 12, n. 3, pp. 133-154. BABAR, M.A., GORTON, I., 2004, "Comparison of scenario-based software architecture evaluation methods". In: Proceedings of the Asia-Pacific Software Engineering Conference, pp. 600-607, Busan, South Korea, November. BABAR, M.A., ZHU, L., JEFFERY, R., 2004, "A framework for classifying and comparing software architecture evaluation methods". In: Proceedings of the Australian Software Engineering Conference, pp. 309-318, Melbourne, Australia, April. BACHMANN, F., BASS, L., CHASTEK, G., DONOHOE, P., PERUZZI, F., 2000, The Architecture Based Design Method, CMU/SEI, Relatrio Tcnico, CMU/SEI-2000TR-001. BAHSOON, R., 2003, "Evaluating Software Architectures for Stability: A Real Options Approach". In: Proceedings of the Doctral Symposium of the International Conference on Software Engineering, pp. 765, Portland, USA. BAHSOON, R., EMMERICH, W., 2003, "Evaluating software architectures: development, stability, and evolution". In: Book of Abstracts of the ACS/IEEE International Conference on Computer Systems and Applications, pp. 47, Tunis, Tunisia, July.

BARBER, K.S., GRASER, T., HOLT, J., 2001, "Providing early feedback in the development cycle through automated application of model checking to software architectures". In: 16th Annual International Conference on Automated Software Engineering, pp. 341-345, Coronado Island, San Diego, CA, USA, November. BARCELOS, R.F., TRAVASSOS, G.H., 2005, "Avaliando documentos arquiteturais atravs de um checklist baseado em atributos de qualidade". In: Proceedings of Workshop de Teses e Dissertao de Engenharia de Software (WTES) - SBES, Uberlndia, MG, Brasil, Outubro. BARCELOS, R.F., TRAVASSOS, G.H., 2006a, "ArqCheck: Uma abordagem para inspeo de documentos arquiteturais baseada em checklist". In: Proceedings of the Simpsio Brasileiro de Qualidade de Software, Vilha Velha, ES, Brasil, Junho. BARCELOS, R.F., TRAVASSOS, G.H., 2006b, "Evaluation Approaches for Software Architectural Documents: a Systematic Review". In: Proceedings of the IberoAmerican Workshop on Requirements Engineering and Software Environments (IDEAS), Buenos Aires, Argentina, Abril. BASILI, V., CALDIEIRA, G., ROMBACH, H., 1994, "Goal Question Metrics Paradigm". In: MARCINIAK, J.J. (eds), Encyclopedia of Software Engineering, Wiley. BASILI, V.R., SELBY, R.W., 1987, "Comparing the Effectiveness of Software Testing Strategies", IEEE Transactions on Software Engineering, v. 13 (Dezembro), pp. 1278-1296. BASILI, V.R., SHULL, F., LANUBILE, F., 1999, "Building Knowledge Through Families of Experiments", IEEE Transactions on Software Engineering, v. 25, n. 4 (July), pp. 456 - 473. BASS, L., CLEMENTS, P., KAZMAN, R., 2003, Software Architecture in Practice, Second Edition, Addison Wesley. BENARIF, S., CHERIF, A.R., LEVY, N., LOSAVIO, F., 2004, "Intelligent tool basedagent for software architecture evaluation". In: Proceedings of the 4th International Conference on Quality Software, pp. 126-133, Braunschweig, Germany, Setembro. BENGTSSON, O., BOSCH, J., 1999, "Architecture Level Prediction of Software Maintenance". In: Proceedings of the Third European Conference on Software Maintenance and Reengineering, pp. 139, Amsterdam, The Netherlands, March. BENGTSSON, P., BOSCH, J., 1998, "Scenario-Based Software Architecture Reengineering". In: Proceedings of the 5th International Conference on Software Reuse, pp. 308, Victoria, B.C, Canada, June.

129

BENGTSSON, P., LASSING, N., BOSCH, J., VAN VLIET, H., 2004, "Architecture-Level Modifiability Analysis (ALMA)", Journal of Systems and Software, v. 69, n. 1-2 (Janeiro), pp. 129-147. BENGTSSON, P.O., 2002, Architecture-Level Modifiability Analysis, Tese de Doutorado, Blekinge Institute of Technology. BERLING, T., THELIN, T., 2004, "A Case Study of Reading Techniques in a Software Company". In: Proceedings of the International Symposium on Empirical Software Engineering, pp. 229-238, Redondo Beach, CA, USA, August. BIOLCHINI, J., MIAN, P.G., NATALI, A.C.C., TRAVASSOS, G.H., 2005, Systematic Review in Software Engineering, COPPE / UFRJ, Relatrio Tcnico, ES-679/05. BOEHM, B.W., 1981, Software Engineering Economics, Prentice-Hall. BOEHM, B.W., ABTS, C., BROWN, A.W., CHULANI, S., CLARK, B.K., HOROWITZ, E., MADACHY, R., REIFER, D., STEECE, B., 2000, Software Cost Estimation with COCOMO II, Prentice Hall. BOEHM, B.W., BASILI, V.R., 2001, "Software Defect Reduction Top 10 List", IEEE Computer, v. 34, n. 1 (Janeiro), pp. 135-137. BOSCH, J., MOLIN, P., 1999, "Software Architecture Design: Evaluation and Transformation". In: Proceedings of the IEEE Engineering of Computer Based Systems Symposium (ECBS99), pp. 4, Nashville, TN, USA, March. BOSCH, J., 2000, Design and use of software architectures: adopting and evolving a product-line approach, ACM Press/Addison-Wesley Publishing Co. BUSCHMANN, F., MEUNIER, R., ROHNERT, H., SOMMERLAD, P., STAL, M., 1996, Pattern-Oriented Software Architecture: A System of Patterns, Jon Wiley and Sons. CARRIERE, S.J., KAZMAN, R., WOODS, S.G., 1999, "Assessing and maintaining architectural quality". In: Proceedings of the Third European Conference on Software Maintenance and Reengineering, pp. 22-30, Amsterdam, The Netherlands, March. CARVER, J., LEMON, K., 2005, "Architecture Reading Techniques: A Feasibility Study". In: Proceedings of the International Symposium on Empirical Software Engineering, pp. 17-20, Noosa Heads, Australia, Novembro. CHEN, T.Y., POON, P.L., TANG, S.F., 2002, "Towards a Problem-Driven Approach to Perspective-Based Reading". In: Proceedings of the 7th IEEE International Symposium on High Assurance Systems Engineering (HASE'02), pp. 221-229, Washington, DC, USA, October. CHOI, H., YEOM, K., 2002, "An approach to software architecture evaluation with the 4+1 view model of architecture". In: Proceedings of the Asia-Pacific Software

130

Engineering Conference, pp. 286-293, Gold Coast, Queensland, Australia, December. CIOLKOWSKI, M., SHULL, F., BIFFL, S., 2002, "A Family of Experiments to Investigate the Influence of Context on the Effect of Inspection Techniques". In: Proceedings of the 6th International Conference on Empirical Assesment in Software Engineering (EASE), pp. 48-60, Keele, UK, April. CLEMENTS, P., KAZMAN, R., KLEIN, M., 2002, Evaluating Software Architectures: Methods and Case Studies, Addison-Wesley. CLEMENTS, P., BACHMANN, F., BASS, L., GARLAN, D., IVERS, J., LITTLE, R., NORD, R., STAFFORD, J., 2004, Documenting Software Architectures, AddisonWesley. CLEMENTS, P.C., 2000, Active Reviews for Intermediate Designs, CMU/SEI, Relatrio Tcnico, CMU/SEI-2000-TN-009. CONRADI, R., MOHAGHEGHI, P., ARIF, T., 2003, "Object-Oriented Reading Techniques for Inspection of UML Models - An Industrial Experiment". In: Proceedings of the European Conference on Object-Oriented Programming, pp. 483-500, Darmstadt, Germany, July. DIAS, M.S., VIEIRA, M.E.R., 2000, "Software architecture analysis based on statechart semantics". In: International Workshop on Software Specification and Design, pp. 133-137, Washington, DC, USA. DOBRICA, L., NIEMELA, E., 2002, "A survey on software architecture analysis methods", IEEE Transactions on Software Engineering, v. 28, n. 7, pp. 638-653. DUENAS, J.C., DE OLIVEIRA, W.L., DE LA PUENTE, J.A., 1998, "A Software Architecture Evaluation Model". In: Procedure of the Second Int'l ESPRIT ARES Workshop, pp. 148-157, Feb. EGYED, A., MEDVIDOVIC, N., 1999, "Extending Architectural Representation in UML with View Integration". In: Proceedings of the 2nd International Conference on the Unified Modeling Language. Beyond the Standard (UML'99), v. 1723, pp. 2-16, Fort Collins, USA, October. EICKELMANN, N.S., RICHARDSON, D.J., 1996, "An evaluation of software test environment architectures". In: Proceedings of the International conference on Software Engineering (ICSE), pp. 353-364, Washington, DC, USA. ERICKSON, R.L., GRIFFETH, N.D., LAI, M.Y., WANG, S.Y., 1993, "Software architecture review for telecommunications software improvement". In: IEEE International Conference on Communications, v. 2, pp. 616-620 vol.2. FAGAN, M.E., 1976, "Design and code inspection to reduce Errors in Program Development", IBM Systems Journal, v. 15, n. 3, pp. 182-211.

131

FALBO, R., 1998, Integrao de Conhecimento em um Ambiente de Desenvolvimento de Software, Tese de Doutorado, Programa de Engenharia de Sistemas e Computao - COPPE/UFRJ. FOLMER, E., V. GURP, J., BOSCH, J., 2003, "A framework for capturing the relationship between usability and software architecture". In: Software Process: Improvement and Practice, pp. 67-87. FOLMER, E., BOSCH, J., 2005, "Case studies on Analyzing Software Architectures for Usability". In: Proceedings of the EUROMICRO Conference on Software Engineering and Advanced Applications, pp. 206-213. FOLMER, E., 2005, Software Architecture Analysis of Usability, Tese de Doutorado, RuG. GACEK, C., 1995, On the Definition of Software System Architecture, University of Southern California, Relatrio Tcnico, USC/CSE-95-TR-500. GAMMA, E., HELM, R., JOHNSON, R., VLISSIDES, J., 1995, Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley. GANNOD, G.C., LUTZ, R.R., 2000, "An approach to architectural analysis of product lines". In: Proceedings of the International conference on Software Engineering (ICSE), pp. 548-557. GARLAN, D., SHAW, M., 1993, "An Introduction to Software Architecture". In: Advances in Software Engineering and Knowledge Engineering, v. I. GARLAN, D., PERRY, D., 1995, "Introduction to the Special Issue on Software Architecture". In: IEEE Transactions on Software Engineering, v. 21, April. GARLAN, D., 2000, "Software architecture: a roadmap". In: Proceedings of The Conference on The Future of Software Engineering, pp. 91-101. GLOGER, M., JOCKUSCH, S., WEBER, N., 1996, "Assessment and optimization of system architectures-experience fromindustrial applications at Siemens". In: Proceedings of the IEEE International Conference on Engineering of Complex Computer Systems, pp. 400-407. GRAAF, B., VAN DIJK, H., VAN DEURSEN, A., 2005, "Evaluating an Embedded Software Reference Architecture: Industrial Experience Report". In: Proceedings of the European Conference on Software Maintenance and Reengineering, pp. 354-363. HOFMEISTER, C., NORD, R.L., SONI, D., 2000, A study on agreement between participants in an architecture assessment, Addison-Wesley. HOLLOCKER, C.P., 1990, Software Reviews and Audits Handbook, New York, John Wiley \& Sons, Inc.

132

IEEE, 1988, "IEEE Standard for Software Reviews and Audits - IEEE Standard 10281988", Institute of Electrical and Eletronics Engineers. IEEE, 2000, "IEEE Recommended Practice For Architectural Description Of SoftwareIntensive Systems - IEEE Standard 1471-2000", Institute of Electrical and Electronics Engineers. IEEE, 2004, "IEEE Xplore". In:

http://ieeexplore.ieee.org/Xplore/guesthome.jsp

Acessado em Dezembro / 2005. ISO/IEC, 1998, "International Technology - Software Product Evaluation - ISO/IEC 9126 Part 1: Quality Model". IVEZIC, N., BARBACCI, M., LIBES, D., POTOK, T., ROBERT, J., 2000, "An analysis of a supply chain management agent architecture". In: Proceedings of the International Conference on MultiAgent Systems, pp. 401-402. JAZAYERI, M., 2002, "On Architectural Stability and Evolution". In: Proceedings of the Ada-Europe International Conference on Reliable Software Technologies, pp. 1323, London, UK. JOHANSSON, E., HST, M., WESSLN, A., BRATTHAL, L., 2001, "The Importance of Quality Requirements in Software Platform Development - A Survey". In: Proceedings of HICSS-34, Maui, Hawaii, January. JONES, C., 1991, Applied Software Measurement, McGraw Hill. KALINOWSKI, M., 2004, Infra-Estrutura Computacional de Apoio ao Processo de Inspeo de Software, Dissertao de Mestrado, Programa de Engenharia de Sistemas e Computao - COPPE/UFRJ, Rio de Janeiro. KAZMAN, R., BASS, L., ABOWD, G., WEBB, M., 1994, "SAAM: a method for analyzing the properties of software architectures". In: Proceedings of the International conference on Software Engineering (ICSE), pp. 81-90. KAZMAN, R., ABOWD, G., BASS, L., CLEMENTS, P., 1996, "Scenario-based analysis of software architecture", IEEE Software, v. 13, n. 6, pp. 47-55. KAZMAN, R., KLEIN, M., CLEMENTS, P., 2000, ATAM: Method for Architecture Evaluation, CMU/SEI, Relatrio Tcnico, CMU/SEI-2000-TR-004. KAZMAN, R., 2001, "Handbook of Software Engineering and Knowledge Engineering". In: CHANG, S.K. (eds), World Scientific Publishing. KAZMAN, R., ASUNDI, J., KLEIN, M., 2001, "Quantifying the costs and benefits of architectural decisions". In: Proceedings of the International conference on Software Engineering (ICSE), pp. 297-306. KAZMAN, R., BASS, L., 2002, "Making architecture reviews work in the real world", IEEE Software, v. 19, n. 1, pp. 67-73.

133

KITCHENHAM, B., 2004, Procedures for Performing Systematic Reviews, Keele University, Relatrio Tcnico. KITCHENHAM, B.A., PFLEEGER, S.L., PICKARD, L.M., JONES, P.W., HOAGLIN, D.C., EMAM, K.E., ROSENBERG, J., 2002, "Preliminary Guidelines for Empirical Research in Software Engineering", IEEE Transactions on Software Engineering, v. 28, n. 8 (Agosto), pp. 721-734. KRUCHTEN, P., 1995, "Architectural Blueprints - The "4+1" View Model of Software Architecture". In: IEEE Software, v. 12, pp. 42-50, November. LAITENBERGER, O., DEBAUD, J., 1998, Scenarios, Quality Attributes, and Patterns: Capturing and Using their Synergistic Relationships for Product Line Architectures, Fraunhofer Institute Experimental Software Engineering, Relatrio Tcnico, ISERN-98-32. LAITENBERGER, O., ATKINSON, C., 1999, "Generalizing Perspective-based Inspection to handle Object-Oriented Development Artifacts". In: Proceedings of the International conference on Software Engineering (ICSE). LAND, R., 2002, "Improving Quality Attributes of a Complex system Through Architectural analysis - A Case Study". In: Proceedings of the 9th IEEE Conference on engineering of Computer-Based Systems, pp. 167-174. LASSING, N., RIJSENBRIJ, D., VAN VLIET, H., 1999a, "On Software Architecture Analysis of Flexibility - Complexity of Changes: Size isn't Everything". In: the Second Nordic Workshop on Software Architecture (NOSA99). LASSING, N., RIJSENBRIJ, D., VAN VLIET, H., 1999b, "Towards a broader view on software architecture analysis of flexibility". In: Sixth Asia Pacific Software Engineering Conference, pp. 238-245. LATTANZE, A.J., 2005, The Architecture Centric Development Method, Carnegie Mellon University, Relatrio Tcnico. LEE, J., HA, S., KANG, K.C., CHOO, Y., HONG, Y., HWANG, H., 2001, "Quality requirement elicitation for the architecture evaluation of process computer systems". In: Procedings of the Eighth Asia-Pacific Software Engineering Conference (APSEC), pp. 335-340. LEE, J.E., CHOI, K., DUTT, N.D., 2003, "Evaluating memory architectures for media applications on coarse-grained reconfigurable architectures". In: Proceedings of the IEEE International Conference on Application-Specific Systems. LEE, Y., CHOI, H.-J., 2005, "Experience of combining qualitative and quantitative analysis methods for evaluating software architecture". In: Fourth Annual ACIS International Conference on Computer and Information Science, pp. 152-157.

134

LICHTNER, K., ALENCAR, P., COWAN, D., 2000, "A framework for software architecture verification". In: Australian Software Engineering Conference, pp. 149-157. LUNG, C.-H., BOT, S., KALAICHELVAN, K., KAZMAN, R., 1997, "An approach to software architecture analysis for evolution and reusability". In: Proceedings of the 1997 Conference of the Centre For Advanced Studies on Collaborative Research, pp. 15. MAFRA, S.N., TRAVASSOS, G.H., 2005, "Tcnicas de Leitura de Software: Uma reviso Sistemtica". In: Proceedings of the Simpsio Brasileiro de Engenharia de Software, Uberlndia, MG, Brasil, Outubro. MAFRA, S.N., TRAVASSOS, G.H., 2006, Estudos primrios e secundrios apoiando a busca por evidncia em engenharia de software, COPPE / UFRJ, 687/06. MARANZANO, J.F., ROZSYPAL, S.A., ZIMMERMAN, G.H., WARNKEN, G.W., WIRTH, P.E., WEISS, D.M., 2005, "Architecture reviews: practice and experience", IEEE Software, v. 22, n. 2, pp. 34-43. MCCRICKARD, D.S., ABOWD, G.D., 1996, "Assessing the impact of changes at the architectural level: a case study on graphical debuggers". In: Proceedings of the International Conference on Software Maintenance. MCT/SEPIN, 2005, "Qualidade e Produtividade no Setor de Software". In:

http://www.mct.gov.br/sepin/Dsi/Software/Menu_Qualidade.htm Acessado em
Fevereiro / 2006. MEDVIDOVIC, N., ROSENBLUM, D., TAYLOR, R., 1999, "A Language and Environment for Architecture-Based Software Development and Evolution". In: Proceedings of the International conference on Software Engineering (ICSE), Los Angeles, CA, Maio. MELO, W., SHULL, F., TRAVASSOS, G.H., 2001, Software Review Guidelines, COPPE/UFRJ, Relatrio Tcnico, ES-556/01. MIAN, P., CHAPETTA, W., SANTOS, P.S., JR, C.R.M., NATALI, A.C.C., BIOLCHINI, J., ROCHA, A.C.R., TRAVASSOS, G., ROCHA, A.R., 2005, "eSEE: an Infrastructure for Supporting Experimental Software Engineering". In: Proceedings the 4th IEEE/ACM International Symposium on Empirical Software Engineering (ISESE) - Late Breaking Paper, Australia, November. MOLTER, G., 1999, "Integrating SAAM in Domain-Centric and Reuse-based Development Processes". In: 2nd Nordic Workshop on Software Architecture. NASA, 1993, Software Formal Inspection Guidebook, NASA, Relatrio Tcnico, NASASTD-2202-9, Disponvel em: citeseer.ist.psu.edu/aeronautics93software.html

135

NETO, A.C.D., BARCELOS, R.F., CHAPETTA, W.A., SANTOS, P.S.M., MAFRA, S.N., TRAVASSOS, G.H., 2004, "Infrastructure for Software Engineering Experiments Definition and Planning". In: Proceedings of the Experimental Software Engineering Latin American Workshop, Brasilia. NETO, A.C.D., TRAVASSOS, G.H., 2005, "Uma infra-estrutura Computacional para Apoio ao Planejamento e Controle de Teste de Software". In: Proceedings of Workshop de Teses e Dissertao de Qualidade de Software (WTQS) - SBQS, Porto Alegre, RS, Brasil. PEREZ, M., GRIMAN, A., LOSAVIO, F., 2002, "Simulation-based architectural evaluation for collaborative systems". In: Proceedings of the 22nd International Conference of the Chilean Computer Science Society, pp. 204 - 213. PFLEEGER, S.L., 2004, Engenharia de Software Teoria e Prtica, Prentice Hall. PORTER, A., VOTTA, J.R., BASILI, V., 1995, "Comparing Detection Methods for Software Requirements Inspection: A Replicted Experiment", IEEE Transactions on Software Engineering, v. 21, n. 6, pp. 563-575. PRESSMAN, R.S., 2001, Software Engineering: A Practitioners Approach, Fifth ed., McGraw Hill. PURHONEN, A., 2004, "Performance optimization of embedded software architecture a case study". In: Proceedings of the Working IEEE/IFIP Conference on Software Architecture (WICSA), pp. 112-121. SEI, 2000, CMMI-SE/SW: Capability Maturity Model Integrated for Systems Engineering/Software Engineering. Version 1.0 staged representation, Software Engineering Institute, Carnegie Mellon University, Relatrio Tcnico, 2000-TR012. SEI, 2004, "SEI Reports". In:

http://www.sei.cmu.edu/publications/index.html

Acessado em Dezembro / 2005. SHAW, M., 1995, "Some Patterns for Software Architectures". SHAW, M., GARLAN, D., 1996, Software Architecture - Perspectives on an Emerging Discipline, Prentice Hall. SHULL, F., RUS, I., BASILI, V., 2000, "How perspective-based reading can improve requirements inspections", IEEE Computer, v. 33, n. 7, pp. 73-79. SHULL, F., CARVER, J., TRAVASSOS, G.H., 2001, "An Empirical Methodology for Introducing Software Processes". In: Proceedings of European Software Engineering Conference, pp. 288-296, September. SHULL, F.J., 1998, Developing techniques for using software documents: a series of empirical studies, Tese de Doutorado, University of Mariland.

136

SILVA, L.F.S., 2004, Uma abordagem com apoio ferramental para aplicao de tcnicas de leitura baseada em perspectiva, Dissertao de Mestrado, Programa de Engenharia de Sistemas e Computao - COPPE/UFRJ. SMITH, D., MERSON, P., 2003, "Using architecture evaluation to prepare a large Web based system for evolution". In: Proceedings of the IEEE International Workshop on Web Site Evolution, pp. 85-92. SVAHNBERG, M., WOHLIN, C., LUNDBERG, L., MATTSSON, M., 2002, "A Method for Understanding Quality Attributes in Software Architecture Structures". In: Proceedings of the 14th International Conference on Software Engineering and Knowledge Engineering (SEKE 2002), pp. 819-826, New York NY. SVAHNBERG, M., 2003, "A study on agreement between participants in an architecture assessment". In: Proceedings of the International Symposium on Empirical Software Engineering (ISESE), pp. 61-70. TEKINERDOGAN, B., 2004, "ASAAM: aspectual software architecture analysis method". In: Proceedings of the Fourth Working IEEE/IFIP Conference on Software Architecture, pp. 5-14. TICHY, W.F., 1998, "Should Computer Scientists Experiment More?" IEEE Software, v. 31, n. 5, pp. 32-39. TRAVASSOS, G.H., SHULL, F., FREDERICKS, M., BASILI, V.R., 1999, "Detecting Defects In Object-Oriented Designs: Using Reading Techniques To Increase Software Quality". In: Proceedings of the Conference on Object-Oriented Programming Systems, Languages \& Applications. TRAVASSOS, G.H., SHULL, F., CARVER, J., 2001, "Working with UML: A Software Design Process Based on Inspections for the Unified Modeling Language". In: Advances in Computer, v. 54, pp. 35-97. TRAVASSOS, G.H., SHULL, F., CARVER, J., BASILI, V.R., 2002, Reading Techniques for OO Design Inspections, Programa de Engenharia de Software COPPE/UFRJ, Relatrio Tcnico. TVEDT, R.T., COSTA, P., LINDVALL, M., 2002, "Does the code match the design? A process for architecture evaluation". In: Proceedings of the International Conference on Software Maintenance, pp. 393 - 401, October. VILLELA, K., 2004, Definio e construo de ambientes de software orientados organizao, Tese de Doutorado, Programa de Engenharia de Sistemas e Computao - COPPE/UFRJ. WEBER, K.C., ROCHA, A.R., ROUILLER, A.C.K., 2004, "Uma Estratgia para Melhoria de Processo de Software nas Empresas Brasileiras". In: Proceedings of the 5th Conference for Quality in Information and Communications.

137

WEINBERG, WILLIAMS,

G.M., L.G.,

FREEDMAN, C.U.,

D.P., 1998,

1984,

"Reviews,

walk-Through of

and

Inspections", IEEE Transactions on Software Engineering, v. 10, n. 5, pp. 68-72. SMITH, "Performance evaluation software architectures". In: Proceedings of the first international workshop on Software and performance (WOSP), pp. 164-177. WOHLIN, C., RUNESON, P., HST, M., OHLSSON, M.C., REGNELL, B., WESSLN, A., 2000, "Experimentation in Software Engineering: an Introduction", Massachusetts. XAVIER, J.R., 2001, Criao e Instanciao de Arquiteturas de Software Especficas de Domnio no Contexto de uma Infra-estrutura de Reutilizao, Dissertao de Mestrado, Programa de Engenharia de Sistemas e Computao - COPPE/UFRJ. YOUNESSI, H., 2002, Object-oriented Defect Management of Software, Prentice Hall. ZHU, L., BABAR, M.A., JEFFERY, R., 2004, "Mining patterns to support software architecture evaluation". In: Proceedings of the 4th Working IEEE/IFIP Conference on Software Architecture, pp. 25 - 34, June.

138

Apndice A Protocolo de Reviso Sistemtica

A.1 Formulao da pergunta
A.1.1 Foco da pergunta de pesquisa
Identificar e caracterizar abordagens utilizadas para avaliar a qualidade de documentos arquiteturais;

A.1.2 Qualidade e Amplitude da pergunta

Contexto: Essas abordagens de avaliao devem ter sido executadas em projetos de desenvolvimento de software que (1) possuam seus requisitos bem definidos, (2) possuam atividades que apiem a construo da arquitetura do software a ser implementado e (3) utilizam abordagens de avaliao para determinar se os atributos de qualidade desejados foram respeitados. Pergunta: De que forma uma arquitetura de software ou um documento arquitetural so avaliados? utilizadas? Palavras-chave: software architecture, software modularity, architectural model, high level design, high level model, evaluate, assurance, review, inspection, verification, analysis; Interveno: abordagens de avaliao de arquiteturas de software Efeito: Caracterizao Controle: (No possui por ser uma caracterizao) Medida de desfecho: nmero de abordagens encontradas Populao: estudos primrios que abordam avaliao arquitetural. Aplicao: projetistas de software Projeto Experimental: nenhum mtodo estatstico ser aplicado Quais as abordagens e em que contexto elas so

A.2 Seleo de fontes de pesquisa

A.2.1 Critrios de seleo de fontes
Disponibilidade de consulta atravs da web; possurem um nvel de avaliao Qualis Capes superior C;

A.2.2 Linguagem dos estudos

Ingls

A.2.3 Identificao das fontes

Mtodos de busca nas fontes: Leitura dos artigos e, quando for mquina de busca, busca atravs dos mecanismos de busca disponibilizados Listagem de fontes: Portal IEEE (IEEE Xplore)(IEEE, 2004), Portal da ACM (ACM, 2004), Relatrios tcnicos do SEI(SEI, 2004), Livros da rea (Documenting Software Architecture (CLEMENTS et al., 2004), Evaluating Software Architecture (CLEMENTS et al., 2002) e Software Architecture in Practice, Second Edition (BASS et al., 2003)). Strings de busca:
IEEE Xplore (software <and> <not>(hardware,synthesize,circuit) <and> architecture <phrase> ( <or> (evaluat*,assurance*,review*,inspection,verification, analysis ))) <in> metadata (software <and> <not>(hardware,synthesize,circuit) <and> high <and> level <and> design <phrase> (<or> (evaluat*,assurance*,review*,inspection,verification, analysis ))) <in> metadata (software <and> <not>(hardware,synthesize,circuit) <and> high <and> level <and> model <phrase> (<or> (evaluat*,assurance*,review*,inspection,verification, analysis ))) <in> metadata (software <and> <not>(hardware,synthesize,circuit) <and> modularity <phrase> ( <or>(evaluat*,assurance*,review*,inspection,verification, analysis ))) <in> metadata (software <and> <not>(hardware,synthesize,circuit) <and> component <phrase> (<or> (evaluat*,assurance*,review*,inspection,verification, analysis ))) <in> metadata ACM +abstract:software +abstract:architecture abstract:evaluate abstract:assurance abstract:review abstract:inspection abstract:verification abstract:analysis -abstract:hardware abstract:synthesize -abstract:circuit -"natural language" -CAD -"memory optimization" processors -microprocessors -java -"human computer interaction" -memory -kernel -gcc -nlp holonic -"hypermedia systems" -olap -networking -"Programming Environments" -"Software process models" +abstract:software +abstract:"high level design" abstract:evaluate abstract:assurance abstract:review abstract:inspection abstract:verification abstract:analysis -abstract:hardware abstract:synthesize -abstract:circuit -"natural language" -CAD -"memory optimization" processors -microprocessors -java -"human computer interaction" -memory -kernel -gcc -nlp holonic -"hypermedia systems" -olap -networking -"Programming Environments" -"Software process models" +abstract:software +abstract:"high level model" abstract:evaluate abstract:assurance abstract:review abstract:inspection abstract:verification abstract:analysis -abstract:hardware abstract:synthesize -abstract:circuit -"natural language" -CAD -"memory optimization" processors -microprocessors -java -"human computer interaction" -memory -kernel -gcc -nlp holonic -"hypermedia systems" -olap -networking -"Programming Environments" -"Software process models"

Fontes selecionadas aps avaliao: a priori, todas as listadas satisfazem os critrios de qualidade. Checagem de referncias: Todas foram aprovadas

140

A.3 Seleo dos estudos

A.3.1 Definio dos estudos
Critrios de incluso e excluso dos estudos: Os artigos devem: estar disponveis; descrever ou apresentar algum mtodo que avalie a arquitetura de um software ou de seus modelos; Definio dos tipos de estudos: Todos os estudos relacionados ao tpico de pesquisa sero selecionados. Procedimentos de seleo dos estudos: As strings de buscas so executadas nas fontes de pesquisa selecionadas. Aps isso, para a seleo de um conjunto inicial de estudos, os critrios de incluso e excluso so aplicados atravs das informaes obtidas com a leitura dos abstracts de cada estudo. Para os estudos restantes, eles so lidos na integra com o objetivo de extrais as informaes desejadas.

A.3.2 Execuo da seleo

Lista dos estudos selecionados: a lista pode ser encontrada no captulo 3 dessa dissertao.

A.4 Extrao das informaes

A.4.1 Critrios de incluso e excluso de informaes
Permita descrever uma abordagem de avaliao arquitetural sem a necessidade de consultar o estudo que a originou

A.4.2 Formulrio de extrao de dados

Os dados a serem extrados devem possibilitar a caracterizao da abordagem atravs do framework descrito no captulo 3 dessa dissertao

A.5 Sumarizao dos resultados

Devido grande quantidade de informaes coletadas no foi possvel fazer um sumrio das abordagens identificadas. O captulo 3 dessa dissertao descreve os resultados encontrados ao executar esse protocolo.

Apndice B Checklist para inspeo arquitetural

141

Este apndice descreve as diferentes verses do checklist utilizados por ArqCheck desde a sua criao at a ltima evoluo, realizada aps o estudo de viabiilidade.

B.1 Verso do checklist utilizado no estudo de viabilidade (verso 1.0)

Checklist para Inspeo de Documento Arquitetural
Instrues
Avalie a documentao arquitetural atravs dos itens de avaliao abaixo; A opo NA (No Aplicvel) deve ser marcada se considerar que no possvel aplicar o item para avaliar a documentao arquitetural; Para os itens de avaliao dos requisitos de qualidade (21 - 42), a documentao arquitetural deve ser avaliada em relao aos requisitos de qualidade identificados na Guia de identificao de contexto. Caso os requisitos no tiverem sido identificados, o inspetor deve avaliar somente se o item aplicvel ou no.

Equipe/Revisor #: ____________________________________
N Itens de avaliao da consistncia das representaes entre os diagramas Nos diagramas, existe algum mdulo/cluster que no possui relacionamentos, ficando isolado dos demais? Todos elementos arquiteturais, identificados atravs de seu nome, foram representados atravs da mesma abstrao nos diferentes diagramas? Sim No NA

1 2

Itens de avaliao da consistncia das representaes entre os diagramas (especficos abordagem de documentao arquitetural utilizada) N Viso Modular Os mdulos internos de cada cluster foram descritos em algum diagrama da viso Modular? Todo relacionamento definido com um cluster foi devidamente mapeado para um de seus mdulos internos? Viso Dinmica Toda porta/interface possui um nome, utilizada com um nico propsito e de forma nica? Os fluxos de execuo, descritos na viso Dinmica, alocam todos os mdulos definidos na viso Modular? Todo mdulo/cluster representado na viso Dinmica foi descrito na viso Modular? Sim No NA Sim No NA

3 4
N

5 6 7

142

8 9
N

Todo fluxo entre dois elementos arquiteturais pode ser mapeado para algum relacionamento da viso Modular? Todo relacionamento, descrito na viso Modular, pode ser mapeado para algum fluxo de comunicao, de dados ou de controle da viso Dinmica? Viso de Alocao Todo mdulo/cluster, representado na viso de Alocao, foi descrito na viso Modular? Toda dependncia, representada na viso de Alocao, pode ser mapeada para um ou mais relacionamentos da viso Modular? Dado os mdulos/clusters representados na viso de Alocao, todos os relacionamentos definidos entre eles na viso Modular tambm foram representados na viso de Alocao? Viso de Contexto Geral Todo mdulo/cluster representado na viso de Contexto Geral foi descrito na viso Modular? Todo relacionamento entre elementos arquiteturais pode ser mapeado para os fluxos de comunicao, descritos na viso Dinmica? Sim No NA Sim No NA

10 11 12
N

13 14

Itens de avaliao do atendimento aos requisitos Todo elemento arquitetural tem a sua presena na arquitetura justificada por um conjunto de requisitos? Todo requisito funcional ou de qualidade ou adicional, criado pelas decises arquiteturais, foi atendido por algum elemento arquitetural? As responsabilidades atribudas a um elemento arquitetural esto relacionadas aos requisitos que ele atende?

Sim

No

NA

15 16 17

Itens de avaliao do atendimento aos requisitos Nos diagramas da Viso Dinmica, todo Fluxo de Execuo justificado por um conjunto de requisitos? Nos diagramas da Viso Dinmica, todos os requisitos que justificam um Fluxo de Execuo so atendidos pelos elementos arquiteturais que compe esse fluxo? Nos diagramas da Viso de Contexto Geral, os relacionamentos entre os elementos externos e os elementos arquiteturais foram justificados por um conjunto de requisitos?

Sim

No

NA

18 19 20

Itens de avaliao da abordagem de atendimento aos requisitos de qualidade N Itens relacionados a Desempenho Sim No NA

Guia de identificao de contexto: De acordo com os requisitos de desempenho que se deseja avaliar, identificar os fluxos de execuo do sistema (Fluxo) relacionados ao atendimento dos requisitos selecionados e os elementos que participam desses fluxos (Elementos Participantes). Essa identificao pode ser feita atravs da anlise do estmulo, do artefato e da resposta descritos nos requisitos selecionados.

21 22

Todos os Elementos Participantes foram alocados em um mesmo n computacional visando aumentar o desempenho do Fluxo? Quando possvel, os fluxos de comunicao que compem o Fluxo so executados concorrentemente?

143

23

Nesse contexto, elementos intermedirios (ex: mquina virtual, servidor de nomes, repositrios) so elementos arquiteturais cuja responsabilidade realizar a comunicao entre dois Elementos Participantes. Existe algum Elemento Relacionado que executa o papel de elemento intermedirio dentro do Fluxo? Todo Elemento Participante pode ter a comunicao com outros Elementos Participantes ou a freqncia de execuo das suas funcionalidades otimizada? Para todo Elemento Participante, a forma como seus servios so requisitados pode ser otimizada?
Itens relacionados a Disponibilidade Sim No NA

24 25
N

Guia de identificao de contexto: De acordo com os requisitos de disponibilidade selecionados, identifique os elementos arquiteturais que devem possuir alta disponibilidade (Elemento Principal). A identificao pode ser feita a partir do artefato e da resposta descritos nos cenrios de disponibilidade

26 27 28
N

Existe algum elemento arquitetural responsvel por verificar periodicamente a disponibilidade dos Elementos Principais? Todo Elemento Principal possui redundncias e algum elemento arquitetural que gerencia a sua disponibilidade? Todo Elemento Principal e suas respectivas redundncias possuem alguma forma de realizar a sincronizao de seus dados e possveis estados? Itens relacionados a Modificabilidade Sim No NA

Requisito RNF3 A infra-estrutura deve ser construda de forma a permitir que os desenvolvedores modifiquem a abordagem de recuperao e persistncia dos artefatos manuseados, sem que seja necessrio realizar alteraes em outras funcionalidades. Essa alterao pode ocorrer durante o desenvolvimento do sistema ou durante a sua manuteno.
Cenrio de Modificabilidade Fonte do estmulo Estmulo Contexto do sistema Artefato Resposta Medida de resposta

Desenvolvedores Modificao da abordagem de manipulao de dados Desenvolvimento do sistema / Manuteno do sistema Repositrios de Dados O sistema deve manipular os dados como antes da modificao ---

Guia de identificao de contexto: De acordo com os requisitos de modificabilidade que se deseja avaliar, identificar os elementos arquiteturais que podem ser modificados (Elemento Modificvel) e tambm os elementos que possuem relacionamentos com os Elementos Modificveis de forma direta (Elemento Relacionado). A identificao dos Elementos Modificveis feita principalmente atravs da anlise do estimulo e contexto dos requisitos selecionados.

29 30 31

As responsabilidades de um Elemento Relacionado pertencem a um mesmo contexto, ou seja, visam atingir um mesmo propsito, manipulam um mesmo tipo de dado ou so utilizadas em um mesmo fluxo de execuo? As funcionalidades dos Elementos Relacionados possuem uma similaridade que, para reduzir os esforos de modificao, poderiam ser agrupadas em um nico elemento? Todo Elemento Modificvel disponibiliza interfaces para realizar os fluxos de comunicao? A comunicao entre um Elemento Relacionado e um Elemento Modificvel, e as funcionalidades disponibilizadas pelo conector (interface/porta) que intermedia essa comunicao so realmente necessrias? Nesse contexto, elementos intermedirios (ex: mquina virtual, servidor de nomes, repositrios) so elementos arquiteturais cuja responsabilidade permitir que outros elementos acessem as funcionalidades ou dados do Elemento Modificvel. Existe

32

33

144

algum Elemento Relacionado que realize o papel de elemento intermedirio? N Requisito RNF4 A infra-estrutura deve permitir, durante a execuo de um processo instanciado, que o Usurio Executor tenha acesso somente s atividades relacionadas aos papis que lhe foram alocados pelo Usurio Engenheiro.
Cenrio de Segurana Fonte do estmulo Estmulo Contexto do sistema Artefato Resposta Medida de resposta

Itens relacionados a Segurana

Sim

No

NA

Usurio Executor Acesso a funcionalidades Durante a execuo normal da infra-estrutura Ambiente para Execuo Acesso somente s funcionalidades alocadas pelo Usurio Engenheiro ao Usurio Executor ---

Guia de identificao de contexto: De acordo com os requisitos de segurana que se deseja avaliar, trs tipos de elementos devem ser identificados: os elementos arquiteturais seguros (Elemento Seguro) que so acessados de forma restrita, os elementos que possuem relacionamentos com os Elementos Seguros (Elemento Relacionado) e os elementos que buscam garantir o acesso seguro ao Elemento Seguro (Elemento Gerenciador). Para que o Elemento Seguro seja identificado, o estmulo e o artefato dos requisitos selecionados devem ser analisados.

34 35 36 37 38
N

Todo Elemento Seguro implementa alguma funcionalidade ou possui algum relacionamento com um Elemento Gerenciador que autentique o acesso aos seus dados ou funcionalidades? Todo Elemento Relacionado realiza alguma autenticao para acessar as funcionalidades de Elemento Seguro? Todo Elemento Seguro disponibiliza somente os servios relacionados aos direitos de acesso do Elemento Relacionado requisitante? Todo Elemento Seguro e os Elementos Relacionados possuem funcionalidades que permitem a codificao e a decodificao dos dados trocados entre eles? Todo Elemento Seguro e os Elementos Relacionados possuem funcionalidades que permitem checar a integridade dos dados?
Itens relacionados a Testabilidade Sim No NA

Guia de identificao de contexto: De acordo com os requisitos de testabilidade que se deseja avaliar, identificar os elementos que participam do atendimento s funcionalidades que se deseja permitir testabilidade (Elemento Testvel). Essa identificao pode ser feita atravs de uma anlise do estmulo e artefato dos requisitos selecionados.

39 40

Todo Elemento Testvel disponibiliza interfaces de comunicao que permitem a sua substituio? Todo Elemento Testvel possui interfaces especficas ou funcionalidades que visam sua monitorao e realizao de testes?

145

N
RequisitoRNF2

Itens relacionados a Usabilidade

Sim

No

NA

A infra-estrutura deve permitir que a execuo de um processo ocorra de forma desacoplada das atividades de configurao e instanciao de modelos.
Cenrio de Usabilidade Fonte do estmulo Estmulo Contexto do sistema Artefato Resposta Medida de resposta

Usurio Engenheiro Modelar ou Instanciar processos Durante a execuo normal da infra-estrutura Ambientes para Instanciao e Configurao Novos modelos ou ambientes instanciados No afeta a execuo de ambientes previamente instanciados

Guia de identificao de contexto: Para atender a requisitos de usabilidade, funcionalidades ou elementos arquiteturais podem ser definidos ou adaptados. Portanto, de acordo com os requisitos de usabilidade que se deseja avaliar, caso seja necessrio, essas funcionalidades (Funcionalidades Envolvidas) devem ser identificadas. Alm disso, devem-se identificar quais elementos arquiteturais sero adaptados ou criados para atender diretamente ao Requisito ou s Funcionalidades Adicionais (Elementos Relacionados). A identificao das funcionalidades e dos elementos arquiteturais pode ser feita atravs da anlise do estmulo, da resposta e da medida de resposta descritos nos requisitos.

41 42

Toda Funcionalidade Envolvida, caso tenha sido definida, est associada a algum elemento arquitetural? Os Elementos Relacionados possuem responsabilidades ou foram organizados visando atender ao requisito avaliado?

146

B.2 Verso do checklist utilizado no estudo de observao (verso 2.1)

Instrues para utilizao do Checklist para Inspeo de Documento Arquitetural
Instrues
Avalie a documentao arquitetural atravs dos itens de avaliao que compem o checklist apresentado na prxima pgina; Antes de utilizar um item que objetiva avaliar a consistncia do documento arquitetural, identifique a que tipo de viso ele se aplica; Para avaliar o atendimento aos requisitos de qualidade, utilize as Guias de identificao de contexto. Essas guias permitem identificar que elementos arquiteturais devem ser avaliados para se verificar o atendimento aos requisitos de qualidade; Ao avaliar uma viso arquitetural ou as funcionalidades de um elemento arquitetural, leia a descrio textual que compem o documento e no somente os diagramas grficos; Caso a sua resposta seja diferente da Resposta Esperada RE (No N, Sim S), um defeito deve ser identificado no Relatrio de Discrepncias; Caso haja dvida em relao aos termos utilizados nos itens de avaliao, utilize o glossrio abaixo;

Glossrio com os termos utilizados no checklist

Documento arquitetural: Documento que descreve a arquitetura de um software atravs do uso de vises arquiteturais. Cada viso pode ser composta por diagramas que representam os elementos arquiteturais sob determinada perspectiva. Esse documento composto tambm por uma descrio textual, que detalha o papel de cada elemento representado nos diferentes diagramas e identifica a rastreabilidade dos elementos arquiteturais com os requisitos especificados; Elemento arquitetural: Elemento bsico da arquitetura responsvel por implementar determinadas funcionalidades; Viso Modular: Perspectiva utilizada para representar como os elementos que compem a arquitetura esto organizados; Viso de Contexto Geral: Essa perspectiva tem como objetivo representar uma viso geral dos principais componentes que formam a arquitetura do software e de como ela se relaciona com os elementos externos ao seu contexto (atores e sistemas externos). Viso Dinmica: Esta perspectiva procura descrever o comportamento dos elementos arquiteturais durante a realizao das diferentes seqncias de execuo presentes no sistema; Viso de Alocao: Esta perspectiva busca representar o mapeamento das unidades de software para elementos fsicos do ambiente (hardware, arquivos do sistema); Seqncia de Execuo: Conjunto de fluxos de mensagens entre os elementos arquiteturais que determina o comportamento esperado do sistema quando se deseja realizar uma determinada tarefa. Em UML, esse comportamento pode ser representado atravs de diagramas de seqncia;
[Termo teis somente para representao de caixa e setas ]

147

Mdulo/Mdulo Interno: Elemento pertencente ao mais baixo nvel de abstrao e cuja representao dos elementos internos no relevante para o entendimento da soluo. Esse elemento arquitetural realiza diversas responsabilidades e se relaciona com outros elementos visando atender a um conjunto de requisitos; Cluster: Elemento arquitetural utilizado para agrupar mdulos que pertencem a um mesmo contexto, ou seja, que possuem responsabilidades similares ou que lidam com um mesmo tipo de dados. Esse elemento composto por mdulos internos cuja representao essencial para o entendimento da soluo; Dependncia: Tipo de relacionamento entre dois elementos arquiteturais (mdulo e cluster) que indica algum tipo de dependncia entre eles; Porta: Uma porta utilizada para representar as propriedades de um elemento que devem ser visveis aos demais. Uma porta formada pelas seguintes informaes: (1) o nome que a identifica, (2) o tipo de comunicao que ela realiza, classificados em trs tipos: fluxo de dados, onde somente dados trafegam, fluxo de controle, por onde so feitas exclusivamente invocaes para funcionalidades presentes em outro elemento, e fluxo de comunicao, que permite o fluxo dos outros dois tipos, (3) a forma como a comunicao realizada: na recuperao dados/recebimento controle, ou persistncia dados/invocao de servios ou ambos e (4) a descrio das funcionalidades que a compem. Interface: Especializao de uma Porta. A principal diferena entre uma Interface e uma Porta est no fato da Interface ser desassociada do Mdulo. Com isso, caso o mdulo que a disponibiliza seja alterado, as modificaes dificilmente sero notadas pelos mdulos que implementam essa interface

148

Checklist para Inspeo de Documento Arquitetural

Equipe/Revisor #: ____________________________________
Itens de avaliao da consistncia do documento N Todas as vises Ao analisar todos os diagramas, foi identificado algum elemento arquitetural que no possua relacionamentos, ficando isolado dos demais? Ao analisar todos os diagramas, foi identificado algum elemento arquitetural que no tenha sido representado atravs da mesma abstrao em diferentes diagramas? A descrio textual que compem o documento est de acordo com o que foi representado nos diferentes diagramas grficos? Sim No RE N N S

1 2 3

Itens de avaliao da consistncia do documento N Viso Modular Para todo componente, foi identificado em algum diagrama da viso Modular as classes ou sub-componentes que o compem? Todo relacionamento definido entre dois componentes pode ser mapeado para relacionamentos realizados entre classes/sub-componentes que o compem? Todo relacionamento realizado entre classes/sub-componentes alocados em componentes pais distintos foi definido como uma dependncia entre esses componentes pais em algum outro diagrama? Toda interface disponibilizada por um nico componente/classe? Viso de Contexto Geral Todo relacionamento entre os componentes, descrito na viso de Contexto Geral, pode ser mapeado para os relacionamentos descritos na viso Modular? Todo elemento externo que se relaciona diretamente com um componente da arquitetura foi representado na viso Modular? Todo relacionamento existente entre um elemento externo e um componente da arquitetura foi mapeado para alguma classe representada na viso Modular? Toda interface disponibilizada/implementada pelos componentes descritos na viso de Contexto Geral podem ser mapeadas para uma classe que a disponibiliza/implementa na viso Modular? Viso Dinmica Ao analisar as seqncias de execuo, descritas na viso Dinmica, pode-se dizer que todas as classes definidas na viso Modular foram alocadas em ao menos uma dessas seqncias? Toda mensagem trocada entre duas classes/componentes, descritas na viso Dinmica, pode ser mapeada para algum relacionamento definido entre essas classes/componentes da viso Modular? Todo relacionamento, descrito na viso Modular, pode ser mapeado para alguma mensagem de comunicao descrita na viso Dinmica? Sim No Sim No Sim No RE S S S S RE S S S S RE S

4 5 6 7
N

8 9 10 11
N

12 13 14

S S

149

15
N

Todo componente externo representado na viso Dinmica foi representado em algum diagrama da viso Modular? Viso de Alocao Toda dependncia, representada na viso de Alocao, pode ser mapeada para um ou mais relacionamentos da viso Modular? Dado as classes/componentes representados na viso de Alocao, todos os relacionamentos definidos entre eles na viso Modular tambm foram representados na viso de Alocao? Itens de avaliao do atendimento aos requisitos Todo elemento arquitetural tem a sua presena na arquitetura justificada por um conjunto de requisitos? As responsabilidades dos elementos arquiteturais esto condizentes com os requisitos que eles atendem? Sim No

S RE S S

16 17

Sim

No

RE S S

18 19

Itens de avaliao da abordagem de atendimento aos requisitos de qualidade N Requisito 26 The architectural design of the component must be prepared for the use of exchangeable GUIs (Graphical User Interface) Fonte do estmulo Estmulo Contexto do sistema Artefato Resposta Medida de resposta Cenrio de Modificabilidade Usurio Mudana da GUI do Menu Durante a execuo do sistema GUI do menu O componente deve modificar a GUI do Menu --Itens relacionados a Modificabilidade Sim No RE

Guia de identificao de contexto: De acordo com os requisitos de modificabilidade selecionados, identifique os elementos arquiteturais que podem ser modificados (Elemento Modificvel) e tambm os elementos que se relacionam com esses Elementos Modificveis de forma direta (Elemento Relacionado). A identificao dos Elementos Modificveis feita atravs da anlise do estimulo, do contexto e do artefato descritos nos cenrios de modificabilidade.

20 21 22 23

As responsabilidades especificadas para cada Elemento Relacionado pertencem a um mesmo contexto, ou seja, visam atingir um mesmo propsito, manipulam um mesmo tipo de dado ou so utilizadas em uma mesma seqncia de execuo? Elementos Relacionados possuem responsabilidades comuns ou similares que podem ser alocadas em um nico elemento? Todo Elemento Modificvel disponibiliza interfaces para se comunicar com os demais elementos? A comunicao entre um Elemento Relacionado e um Elemento Modificvel, e as funcionalidades disponibilizadas pelo conector (interface/porta) que intermedia essa comunicao so realmente necessrias? Elementos intermedirios (ex: mquina virtual, servidor de nomes, repositrios) so utilizados como mediadores de comunicao entre o Elemento Modificvel e os demais elementos arquiteturais, diminuindo o impacto das alteraes realizadas nos Elementos Modificveis. Existe algum Elemento Relacionado que realize esse papel de intermedirio?

S N S S

24

150

Apndice C Relatrio de discrepncias

Grupo de Engenharia de Software Experimental
Relatrio de Discrepncias
Equipe/Revisor #: ____________________________________ Tempo de inspeo (em minutos): ____________________________________ Instrues Os Diagramas envolvidos devem ser identificados atravs do seu nome e do nome da viso que eles pertencem (Viso::Diagrama) Os tipos de defeito podem ser: omisso, ambigidade, inconsistncia, informao estranha ou fato incorreto.
Descrio 1. Quando um elemento arquitetural necessrio para o atendimento a um requisito no foi definido; 2. Quando a forma como os elementos arquiteturais ou suas responsabilidades foram definidos dificulta ou impossibilita o atendimento a um requisito de qualidade. 3. Quando elementos descritos em vises distintas possuem o mesmo nome, mas responsabilidades diferentes (Homnimo); 4. Quando elementos descritos em vises distintas possuem mesma responsabilidade, mas nomes distintos (Sinnimo); 5. Quando um elemento arquitetural presente em diagramas das demais vises no foi definido no diagrama avaliado; 6. Quando a representao no condiz com a semntica estabelecida pela abordagem de documentao. 7. Quando um elemento arquitetural definido com responsabilidades distintas em duas ou mais vises. 8. Quando um elemento representado de maneira diferente em duas vises. 9. Quando um elemento no foi descrito ou representado de forma correta 10. Quando no possvel mapear um elemento arquitetural para algum elemento descrito em outra viso. 11. Quando no possvel determinar o papel de um elemento arquitetural ou de uma de suas responsabilidades no atendimento aos requisitos especificados.

Tipos de defeitos Omisso Ambigidade

Inconsistncia

Fato Incorreto

Informao Estranha

Item do checklist

Diagramas envolvidos

Descrio da Discrepncia

Tipo de Defeito

1 2

151

Apndice D Plano do Experimento

UNIVERSIDADE FEDERAL DO RIO DE JANEIRO PROGRAMA DE ENGENHARIA DE SISTEMAS E COMPUTAO

ENGENHARIA DE SOFTWARE EXPERIMENTAL

1. IDENTIFICAO
Ttulo: Estudo de caso / Abordagem para inspeo de documentos arquiteturais baseada em checklist (ArqCheck) Tema: rea Tcnica: Autores: Rafael Ferreira Barcelos Guilherme Horta Travassos Afiliao: barcelos@cos.ufrj.br ght@cos.ufrj.br Avaliao de documentos arquiteturais Arquitetura de Software / Qualidade de Software

ESE - Engenharia de Software Experimental COPPE/UFRJ Programa de Engenharia de Sistemas e Computao Universidade Federal do Rio de Janeiro, Cx. Postal 68.511, CEP 21945-970, Rio de Janeiro RJ Brasil.

Local: Verso: Data:

COPPE/UFRJ 2.1 19/02/2006

2. CARACTERIZAO
2.1. Tipo
Estudo de observao: Este tipo de estudo ocorre em um ambiente de estudo, onde indivduos desempenham alguma tarefa enquanto so observados pelos pesquisadores. O propsito deste estudo coletar dados sobre como uma tarefa executada. Desta forma, os pesquisadores podem adquirir uma compreenso mais

refinada sobre como a nova tecnologia aplicada na prtica, presenciando eventuais dificuldades que os indivduos podem enfrentar (SILVA, 2004). No contexto dessa pesquisa, tratamos esse estudo de observao como um prexperimento, ou seja, a sua execuo consistiu na aplicao de um tratamento a somente um caso, onde uma comparao realizada em relao a um determinado baseline (AMARAL, 2003). Com isso, aplicamos a abordagem proposta para inspecionar um documento arquitetural que j foi avaliado atravs de uma outra abordagem.

2.2. Domnio
Engenharia de Software.

2.3. Lngua
O estudo ser conduzido tendo o checklist que compem a abordagem de inspeo proposta descrito em portugus e o documento arquitetural avaliado descrito em ingls.

2.4. Parceiros
O estudo ser conduzido no contexto do grupo de Engenharia de Software Experimental (ESE) da COPPE/UFRJ. Alm disso, foi estabelecido um acordo com a empresa SIEMENS-AM, onde eles se comprometem em disponibilizar o documento arquitetural de um de seus projetos e os respectivos defeitos encontrados atravs da execuo de uma abordagem de inspeo prpria. Em contrapartida, os experimentalistas se comprometem em fornecer um feedback em relao aos resultados obtidos nesse estudo.

2.5. Links
Programa de Engenharia de Sistemas e Computao da COPPE/UFRJ http://www.cos.ufrj.br Equipe de Engenharia de Software Experimental da COPPE/UFRJ http://www.cos.ufrj.br/~ese Instituto de Pesquisa da SIEMENS-AM http://www.siemens.com.br

2.6. Expectativa de Execuo

Com base nos resultados do estudo de viabilidade j realizado, identificamos que a abordagem proposta (ARQCHECK) possibilita a identificao de defeitos em um

153

documento arquitetural. Com isso, no estudo proposto, procuramos identificar agora a eficcia/eficincia do checklist que compem a abordagem ARQCHECK em avaliar um documento arquitetural. Por eficcia, entendemos a quantidade de defeitos em relao ao nmero total de discrepncias encontradas. Por eficincia, entendemos a quantidade de defeitos identificados por unidade de tempo de inspeo. Para isso, iremos aplicar ARQCHECK a um documento arquitetural que j foi avaliado por uma abordagem ad-hoc e que identificou defeitos que permitiram a melhoria da sua qualidade. Esse documento foi criado e avaliado no contexto de um projeto real de desenvolvimento de software da SIEMENS-AM. Sendo assim, pretendemos observar a inspeo de um documento arquitetural real atravs do checklist proposto e comparar atravs da realizao desse estudo os resultados obtidos pelas duas abordagens, visando caracterizar a nossa abordagem em relao aos resultados obtidos pela SIEMENS-AM. Para isso, utilizaremos os dados coletados durante esse estudo e os dados fornecidos pela SIEMENS-AM para obter o custo/eficincia e eficcia das duas abordagens. Entretanto, a comparao entre as duas abordagens no o nosso objetivo principal, ou seja, no visamos identificar qual a melhor abordagem de avaliao atravs dessa comparao. Isso ocorre visto que, alm dos resultados obtidos com a aplicao dessas abordagens em somente um caso no serem suficientes para tirarmos esse tipo de concluso, no temos acesso a algumas informaes que permitem caracterizar a inspeo realizada pela SIEMENS-AM. Portanto, o objetivo dessa comparao de caracterizar ARQCHECK em relao a um controle, ou baseline. Para esse estudo, o baseline escolhido foi a abordagem SIEMENS, pois, mesmo sendo uma abordagem ad-hoc, a abordagem que de fato est sendo utilizada nesse contexto industrial e seus resultados j foram utilizados para a melhoria da qualidade da arquitetura avaliada. Com isso, neste estudo de observao buscamos criar um corpo de conhecimento que nos permita avaliar a aplicao da abordagem proposta. Alm disso, esperamos que os resultado obtidos, e o corpo de conhecimento construdo decorrente de sua conduo, nos fornea subsdios que permitam evoluir a abordagem para otimizar a sua aplicao tanto em relao ao esforo necessrio para execut-la quanto quantidade e tipo de defeitos que ela permite identificar.

2.7. Nmero Estimado de Repeties

A princpio, o estudo de viabilidade ser conduzido uma nica vez. Caso os resultados do estudo apontem para o sucesso da abordagem ARQCHECK, pretendemos

154

continuar na conduo de estudos, seguindo a metodologia de (SHULL et al., 2001), visando a transferncia dessa tecnologia apara a industria. Caso contrrio, pretendemos rever as premissas que sustentam a abordagem e, com base nos resultados obtidos por esse estudo, propor melhorias que permitam sua evoluo.

2.8. Glossrio de Termos

Defeito: propriedade de um artefato que o impea de satisfazer seus requisitos de qualidade (LAITENBERGER e ATKINSON, 1999). Discrepncia: potenciais defeitos detectados por revisores de software durante uma sesso de inspeo de software. Utilidade da abordagem de inspeo: capacidade da abordagem em identificar defeitos arquiteturais que permitam a melhoria da qualidade do documento e que justifiquem o custo/benefcio dessa avaliao. Uma forma de caracterizar essa utilidade atravs da avaliao da sua eficcia e seu custo/eficincia. Falso-positivo: discrepncia identificada pelo revisor durante uma sesso de inspeo que, quando avaliada posteriormente, no representou de fato um defeito real no documento arquitetural.

3. INTRODUO
Devido importncia da arquitetura de software no processo de desenvolvimento, a avaliao dos documentos arquiteturais passa a ter extrema importncia para os stakeholders. A avaliao arquitetural consiste em caracterizar e avaliar os documentos arquiteturais atravs de mtodos ou procedimento sistemticos. Essa avaliao verifica principalmente se a arquitetura descrita atravs do documento arquitetural atende aos requisitos especificados pelo cliente. Visto que so os requisitos de qualidade os que mais influenciam a construo de uma arquitetura, portanto, principalmente sob a perspectiva dos atributos de qualidade que a avaliao realizada. Devido importncia dessa atividade para a melhoria da qualidade do produto de software e para o sucesso do projeto, os experimentalistas optaram por definir uma abordagem para inspeo baseada em checklist (ARQCHECK) visando identificar defeitos arquiteturais em relao aos requisitos que foram especificados pelo cliente. Aps a construo desse checklist, os experimentalistas decidiram realizar alguns estudos de avaliao visando caracterizar essa nova abordagem em relao sua

155

capacidade em identificar defeitos e visando permitir a transferncia dessa tecnologia para o contexto industrial. Para isso, a metodologia definida por SHULL et al. (2001) est sendo utilizada. Portanto, seguindo essa metodologia, um primeiro estudo de viabilidade j foi realizado com o principal objetivo de caracterizar os itens de avaliao que formam o checklist de ARQCHECK em relao sua clareza e aplicabilidade na identificao de defeitos. O estudo ao qual esse plano se refere um estudo de observao com o objetivo de caracterizar a utilidade da abordagem ARQCHECK em identificar defeitos em documentos arquiteturais.

4. DEFINIO DO ESTUDO EXPERIMENTAL

4.1. Objeto de Estudo
A abordagem para inspeo de documentos arquiteturais baseadas em checklist (ARQCHECK) composta pelos seguintes elementos: Atividades de configurao utilizadas para adequar o checklist ao contexto da arquitetura a ser avaliada; Atividades de execuo que devem ser seguidas pelos inspetores para identificar defeitos em um documento arquitetural utilizando como principal ferramenta um checklist; Checklist de avaliao composto por itens que buscam avaliar os documentos sob diferentes perspectivas. A taxonomia de defeitos que visa classificar as discrepncias que podem ser identificadas em um documento arquitetural atravs da ARQCHECK; No contexto deste estudo, procuramos avaliar o checklist de avaliao, j configurado s caractersticas da arquitetura, e a taxonomia de defeitos utilizada.

4.2. Propsito
O propsito desse estudo realizar uma avaliao da eficincia e eficcia da abordagem ARQCHECK em relao identificao de defeitos.

4.3. Foco da Qualidade

A avaliao experimental da aplicao da abordagem ARQCHECK em inspees de documentos arquiteturais tem seu foco de qualidade: Na avaliao quantitativa da eficcia da abordagem ARQCHECK em relao deteco de defeitos;

156

Na avaliao quantitativa da eficincia da abordagem ARQCHECK em relao deteco de defeitos; Na avaliao quantitativa do tipo de defeitos encontrados; Na avaliao qualitativa da usabilidade da abordagem, ou seja, o quo bem os participantes do estudo acreditam que a aplicao da abordagem ARQCHECK os auxiliaram na tarefa de deteco de defeitos.

4.4. Perspectiva
A perspectiva do ponto de vista dos experimentalistas, que desejam avaliar a aplicao prtica da abordagem ARQCHECK.

4.5. Contexto
O estudo experimental de observao ser realizado em ambiente acadmico utilizando estudantes de ps-graduao em Engenharia de Software como participantes. O estudo consistir na simulao de uma sesso de inspeo de software, onde os participantes aplicaro a abordagem ARQCHECK em um documento arquitetural. Portanto, a conduo do estudo caracteriza-se por ser off-line. O documento arquitetural consiste em um modelo real, criado no contexto de um projeto da SIEMENS-AM. Esse artefato j foi avaliado atravs de uma abordagem prpria. Sabe-se somente que esse documento possui defeitos contudo no se tem idia a princpio de que defeitos so esses ou de que tipos so. Esses dados ser fornecidos pela SIEMENS-AM somente aps a execuo do estudo, quando iniciarmos a anlise dos dados. O estudo experimental trata de um problema real no domnio da Engenharia de Software, que a falta de apoio adequado aos revisores durante a conduo da atividade de deteco de defeitos em inspees de um documento arquitetural. Mesmo utilizando um documento arquitetural criado em um contexto industrial, no ser possvel generalizar os resultados para o contexto de projetos reais da indstria devida principalmente s ameaas de validade identificadas na seo 5.8.

4.6. Objetivos Especficos

Analisar com o propsito de em relao do ponto de vista no contexto a aplicao da abordagem ARQCHECK caracteriz-la eficcia em identificar defeitos em documentos arquiteturais Experimentalistas da inspeo de um documento arquitetural que fora criado em um contexto industrial

157

Analisar com o propsito de em relao do ponto de vista no contexto

a aplicao da abordagem ARQCHECK caracteriz-la Custo/eficincia arquiteturais Experimentalistas da inspeo de um documento arquitetural que fora criado em um contexto industrial em identificar defeitos em documentos

4.7. Questes e Mtricas

As questes abaixo se referem aplicao da abordagem ARQCHECK em sesses de inspeo de documentos arquiteturais. A saber: Questes referentes investigao se a abordagem ARQCHECK atinge o objetivo ao qual foi proposta (apoiar a deteco de defeitos em documentos arquiteturais).

Q1: Qual a eficcia da abordagem ARQCHECK no que diz respeito deteco

de defeitos? Mtricas: Quantidade consolidada de defeitos detectados por ARQCHECK Quantidade consolidada de defeitos detectados por ARQCHECK e pela SIEMENS Quantidade de defeitos encontrados pela SIEMENS. Eficcia da abordagem = Quantidade de defeitos detectados por ArqCheck / Quantidade de discrepncias identificadas. Eficcia 2 da abordagem = Quantidade de defeitos detectados por ArqCheck e comuns a abordagem SIEMENS/ Quantidade de discrepncias identificadas pela abordagem SIEMENS.

Q2: Qual o custo/eficincia da aplicao de ARQCHECK no que diz respeito

deteco de defeitos? Mtricas: Custo/Eficincia da abordagem (ArqCheck) = Quantidade de defeitos detectados por participante / Tempo de inspeo do participante Custo/Eficincia da abordagem (SIEMENS) = Quantidade de defeitos detectados / Tempo total de inspeo Questes envolvendo a anlise da usabilidade da abordagem ARQCHECK.

Q3: A aplicao de ARQCHECK til na tarefa de deteco de defeitos?

Mtrica: avaliao qualitativa do participante.

Q4: Qual o grau de dificuldade na aplicao de ARQCHECK?

Mtrica: avaliao qualitativa do participante.

158

Obs.: as avaliaes qualitativas dos participantes sobre a abordagem ARQCHECK sero coletadas atravs do Questionrio de Avaliao Ps-Experimento (Q4 questes 3, 5, 6, 8; Q5 questes 1, 2).

4.8. Questes em aberto

Qual a influncia do nvel de conhecimento do inspetor no domnio do problema ao utilizar a abordagem ARQCHECK ou SIEMENS para identificar defeitos? Qual a influncia do nvel de conhecimento do inspetor em arquitetura de software ao utilizar a abordagem ARQCHECK ou SIEMENS para identificar defeitos? Qual o principal tipo de defeito encontrado por ARQCHECK ?

5. PLANEJAMENTO
5.1. Formulao de Hipteses
A premissa por trs de uma abordagem de inspeo em geral a orientao provida ao usurio no que diz respeito conduo da atividade em questo. Para avaliar essa premissa, realizamos uma comparao entre os defeitos detectados pela abordagem proposta e os resultados obtidos por uma abordagem utilizada em um contexto industrial. Portanto a hiptese nula que desejamos refutar atravs desse estudo :
Hiptese nula (H0): No existe diferena entre os resultados encontrados pela abordagem ARQCHECK e a abordagem SIEMENS em relao deteco de defeitos arquiteturais

Para se obter resultados que venham a refutar ou a confirmar a hiptese H0, a eficcia e a eficincia das abordagens foram as caractersticas avaliadas. Portanto, para cada uma dessas duas caractersticas, as seguintes hipteses foram definidas: Eficcia DA = Lista de defeitos encontrados pelos inspetores que utilizaram a abordagem ARQCHECK. DS = Lista de defeitos encontrados pela abordagem SIEMENS.
Hiptese nula A (H0 A): A abordagem ARQCHECK permite identificar os mesmos defeitos identificados atravs da abordagem SIEMENS. H0 A: DA = DS Hiptese Alternativa A (H1 A): ARQCHECK permite encontrar defeitos que no foram encontrados pela abordagem SIEMENS.

159

H1 A: DA > DS Hiptese Alternativa A (H2 A): A abordagem da SIEMENS permite encontrar defeitos que no foram encontrados pela abordagem ARQCHECK. H2 A: DA > DS

Eficincia TA = Tempo mdio das inspees utilizando a abordagem ARQCHECK. QA = Quantidade de defeitos encontrados pela abordagem ARQCHECK TS = Tempo mdio das inspees utilizando a abordagem SIEMENS. QS = Quantidade de defeitos encontrados pela abordagem SIEMENS
Hiptese nula B (H0 B): A relao entre a quantidade de defeitos encontrados e o tempo mdio de inspeo utilizando a abordagem ARQCHECK e a abordagem SIEMENS so similares. H0 B: QA/TA QS/TS Hiptese Alternativa B (H1 B): A relao entre a quantidade de defeitos encontrados e o tempo mdio de inspeo utilizando a abordagem ARQCHECK maior que o da abordagem SIEMENS. H0 B: QA/TA > QS/TS Hiptese Alternativa B (H2 B): A relao entre a quantidade de defeitos encontrados e o tempo mdio de inspeo utilizando a abordagem ARQCHECK menor que o da abordagem SIEMENS. H1 B: TI < TS

5.2. Seleo de Variveis 5.2.1. Independentes

Varivel DOC DOC TEC Valores Arquitetura_AppMenuX85.pdf Requisitos_AppMenuX85.pdf ARQCHECK ou SIEMENS Descrio Documento arquitetural a ser inspecionado. Documento de requisitos Abordagem utilizada. EXP A: acima da mdia B: na mdia C: abaixo da mdia 0: No especialista 1: Especialista Caracterizao dos participantes em relao s competncias de TEC necessrias e em para a ao aplicao relao de inspeo arquitetural

conhecimento do problema.

5.2.2. Dependentes 160

Varivel TEMP DEF FAL TEC_TIP

Valores Inteiro Inteiro Inteiro Inteiro

Descrio O tempo gasto por cada participante durante a deteco de defeitos. O tempo contabilizado em minutos. A quantidade de defeitos encontrados por cada participante registrada. A quantidade de falso-positivos participante registrada. encontrados por cada

Quantidade de defeitos de um determinado tipo encontrados por cada abordagem.

5.3. Seleo dos Participantes 5.3.1. Critrio de Seleo de Participantes

Os participantes do estudo sero provenientes da lista de estudantes matriculados nos cursos de ps-graduao do PESC da COPPE/UFRJ. Entretanto, para participar do estudo, os estudantes devero obrigatoriamente: Manifestar interesse em participar do estudo, assinando o Formulrio de Consentimento, e J terem participado do primeiro experimento realizado com o ARQCHECK. Pois, durante esse experimento, foi realizado um extenso treinamento sobre os conceitos relacionados arquitetura de software e que por motivos de tempo no poder ser repetido.

5.3.2. Critrio de Seleo de Grupos

Caso a quantidade de participantes seja superior a trs e a avaliao de suas competncias individuais aponte diferenas significativas entre os nveis de qualificao, os participantes podero ser agrupados em dois diferentes grupos, como forma de minimizar o impacto do nvel de qualificao dos participantes nos resultados do estudo. Dessa forma, haveria um grupo com alta experincia e outro grupo com baixa experincia, no que diz respeito s competncias necessrias para o projeto de arquitetura de software.

5.3.3. Tcnicas de Amostragem

Os participantes do estudo sero escolhidos atravs de uma amostra noprobabilstica baseada por convenincia (WOHLIN et al., 2000).

5.4. Projeto do Experimento 5.4.1. Objetos

161

A abordagem para inspeo de documentos arquiteturais baseada em checklist.

5.4.2. Princpios
Aleatoriedade. No h aleatoriedade na atribuio do objeto de estudo aos participantes, visto que todos os participantes iro utilizar o mesmo objeto. Os participantes, conforme descrito na seo 5.3, no sero selecionados aleatoriamente da populao, pois sero provenientes do grupo ESE da COPPE/UFRJ, que estiverem disponveis. Blocagem. No ser possvel a realizao de agrupamentos devido ao nmero limitado de participantes. Balanceamento. Como a amostra de participantes ser proveniente do grupo ESE da COPPE/UFRJ, no ser possvel garantir o balanceamento do conjunto de dados do estudo de acordo com a qualificao individual dos participantes.

5.4.3. Tipo
O estudo experimental caracterizado como um pr-experimento onde ser avaliado um nico objeto (ARQCHECK) atravs da comparao com um controle (SIEMENS).

5.5. Instrumentao 5.5.1. Descrio da Instrumentao

Para obter as competncias e experincias dos participantes do estudo sero utilizados o Formulrio de Caracterizao de Experincia. Esses dados so a entrada para a caracterizao da qualificao dos participantes e, portanto, so variveis independentes do estudo. Durante a inspeo, um dos documentos necessrios para sua realizao o Documento de Requisitos. Esse documento deve identificar os requisitos que sero utilizados como base para a identificao de discrepncias na arquitetura do software. Alm do Documento de Requisitos, um outro documento essencial pra a realizao do experimento o Documento Arquitetural. Esse documento responsvel por descrever a arquitetura do software a ser avaliada. As medidas quantitativas do estudo sero coletadas atravs do preenchimento do Relatrio de Discrepncias. As medidas qualitativas dos participantes sobre a aplicao da tcnica, alm da conduo do experimento, sero coletadas ao final do estudo atravs do Questionrio de Avaliao Ps-Experimento e do Registro de Entrevistas.

5.5.2. Apoio Anlise Quantitativa 162

A avaliao quantitativa ser realizada em cima dos dados coletados nos formulrios de discrepncias pertencentes ARQCHECK.

5.5.3. Apoio Anlise Qualitativa

A avaliao qualitativa ser em cima dos dados preenchidos pelos participantes do Questionrio de Avaliao Ps-Experimento e do Registro de Entrevistas coletados ao final da etapa de deteco de defeitos.

5.6. Mecanismos de Anlise 5.6.1. Testes Estatsticos

De forma a avaliar se a aplicao de ARQCHECK apia em maior grau a deteco de defeitos, em relao ao apoio deteco de falso-positivos, ser utilizado o teste Binomial, que se caracteriza por ser do tipo no-paramtrico (WOHLIN et al., 2000).

5.6.2. Critrios para Eliminao de Outlier

No se aplica devido ao nmero limitado de participantes

5.7. Planejamento de execuo 5.7.1. Definio de Execuo do Estudo Experimental

O estudo experimental de viabilidade ser conduzido em apenas uma sesso mas de forma remota, ou seja, os participantes no realizaram a inspeo ao mesmo tempo e nem no mesmo lugar. Nessa sesso, os candidatos respondero ao Formulrio de Caracterizao visando identificar a competncia e a experincia relacionadas ao propsito do estudo, alm de se buscar identificar o conhecimento do participante no domnio do problema ao qual o artefato inspecionado pertence. Aps a caracterizao, os participantes sero orientados a preencher um Formulrio de Consentimento e recebero um documento que descreve a abordagem ARQCHECK. Esse documento visa explicar os principais conceitos relacionados aplicao dessa abordagem para a deteco de defeitos. Alm disso, ser distribudo um documento arquitetural que dever ser avaliado e o checklist de avaliao que compem a abordagem ARQCHECK. Alm desses artefatos, ser distribudo um documento de requisitos que dever ser utilizado como base para a avaliao e um relatrio de discrepncias que dever ser preenchido a medida que o participante identificar discrepncias no artefato avaliado. No existe um limite de tempo para que essa avaliao seja realizada.

163

Aps a concluso do experimento, ser pedido a cada estudante, o preenchimento do Questionrio de Avaliao Ps-Experimento, de forma a obter-se a sua avaliao qualitativa a respeito da aplicao da abordagem ARQCHECK, e dos procedimentos do estudo experimental. Alm disso, entrevistas individuais podem ser conduzidas, onde cada participante ser incentivado a emitir quaisquer opinies a respeito da abordagem e da conduo do experimento, que sero descritas em um Registro de Entrevistas. Em posse dos Relatrios de Discrepncia gerados por cada participante, o experimentalista, com o apoio dos participantes e de especialistas em arquitetura, ir classificar as discrepncias identificadas em defeitos ou em falso-positivos. Essas duas listas sero analisadas pelos autores do documento arquitetural (profissionais da SIEMENS) que avaliaro se a classificao foi corretamente realizada. Aps um retorno dessa avaliao, o experimentalista ter acesso aos dados obtidos pela inspeo realizada atravs da abordagem da SIEMENS e a anlise dos dados poder ser iniciada.

5.7.2. Artefatos
A documentao a ser utilizada no estudo inclui: Formulrio de Consentimento na Participao do Estudo; Formulrio de Caracterizao de Experincia dos Participantes; Documento explicativo sobre a abordagem A abordagem ARQCHECK, que inclui: o Checklist de avaliao, a Taxonomia de Defeitos e o Relatrio de Discrepncias; Documento de Requisitos e Documento Arquitetural usados durante a avaliao Questionrio de Avaliao Ps-Experimento; Registro de Entrevistas.

5.8. Validade dos Resultados

Apesar de havermos identificado possveis ameaas validade dos resultados, no extrairemos concluses alm das limitaes impostas por estas ameaas, o que no invalidar, portanto, os resultados do estudo.

5.8.1. Validade de Concluso

Relacionada a questes que ameaam a habilidade de traar concluses corretas sobre o relacionamento entre tratamentos e resultados de um estudo experimental.

164

Confiana das Medidas: Dois dos objetivos que procuramos alcanar com esse estudo identificar, em comparao aos resultados obtidos pela SIEMENS, o nmero de defeitos reais e que tipo de defeito a abordagem ARQCHECK identificou com maior intensidade. Sendo assim, uma potencial ameaa validade de concluso do estudo pode ser identificada. Essa ameaa se refere classificao de cada discrepncia em defeitos por parte dos profissionais da SIEMENS, por serem os autores do documento arquitetural. Entretanto, esse processo deveras subjetivo, o que representa uma ameaa.

Heterogeneidade Aleatria dos Participantes: os participantes sero alunos de ps-graduao em Engenharia de Software, portanto, no esperamos participantes com nveis de competncias to discrepantes, que possa a vir comprometer a validade do estudo. Contudo devido pequena quantidade de participantes, opes como a blocagem, no podero ser usadas visando minimizar esse tipo de ameaa, caso ocorra.

Confiabilidade na Implementao do Tratamento: Este risco est relacionado aplicao do tratamento no ser similar entre os diferentes participantes do estudo. A abordagem ARQCHECK compreende um conjunto de documentos padronizados para sua aplicao e um treinamento ser realizado visando tambm padronizar a aplicao da abordagem

5.8.2. Validade Interna

Relacionada ao risco de outros fatores no identificados a priori, terem influenciado um eventual relacionamento de causalidade entre tratamento e resultado, sem o conhecimento prvio do experimentador. Histria: os participantes j aplicaram a abordagem ARQCHECK em um primeiro estudo. Contudo, pelo uso de checklist no utilizar um procedimento de execuo obrigatrio e devido s evolues significativas que foram feitas sobre esse artefato, acreditamos que o efeito de histria no seja pertinente ao estudo. Instrumentao: os formulrios a serem utilizados no estudo experimental podem influenciar de forma significativa a conduo do estudo, afetando negativamente seus resultados. Entretanto, por tratar-se de um estudo de viabilidade, essa questo no representa uma ameaa significativa validade do estudo, haja vista que a avaliao da viabilidade de ARQCHECK tambm aplica-se sua documentao associada. Seleo: a amostra dos participantes no ser aleatria, visto que ser proveniente da disponibilidade de pesquisadores do grupo de pesquisa em que o experimentalista pertence.

165

Plgio (plagiarism): um tpico risco na conduo de estudos experimentais em ambiente acadmico a potencial troca de informaes entre os participantes sobre as tarefas do estudo. Entretanto, essa ameaa no pertinente, visto que os participantes se comprometeram a no se comunicarem durante a realizao do estudo.

Ameaas a Mltiplos Grupos: essas ameaas no se aplicam ao estudo uma vez que no ser possvel a realizao de blocagem.

5.8.3. Validade de Construo

Problemas relacionados ameaa de generalizar os resultados do estudo teoria que o sustenta. As principais ameaas so: Vis mono-operao: o estudo experimental ir utilizar um nico documento arquitetural como objeto de inspeo; portanto, o estudo pode no ser representativo da teoria sob a qual se sustenta, uma vez que pode no ficar claro se a causa dos resultados do estudo decorrente da aplicao de ARQCHECK ou da facilidade de deteco de defeitos no documento utilizado. Teste: como forma de evitar possveis influncias no desempenho dos participantes, o objetivo do estudo no ser apresentado aos participantes. Alm disso, os participantes no sero envolvidos com discusso sobre as supostas vantagens e desvantagens da utilizao de ARQCHECK, e de abordagens de avaliao arquitetural em geral. Entretanto, devido presena da ameaa Interao entre Tratamentos Diferentes descrita abaixo, no temos como garantir a ausncia dessa ameaa. Interao entre Teste e Tratamento: O fato dos participantes terem participados de um estudo piloto de ARQCHECK faz com que eles conheam o propsito da abordagem ARQCHECK, o que deve ser levado em considerao quando as concluses sobre esse estudo forem realizadas.. Apreenso de Avaliao: uma possvel ameaa a probabilidade dos participantes maquiarem seus dados devido a expectativas pessoais sobre a avaliao de seus resultados. Entretanto, essa ameaa no ser levada em considerao visto que o estudo ser conduzido por pesquisadores que participaro por livre vontade ao estudo.

5.8.4. Validade Externa

Questes relacionadas ameaa dos resultados do estudo no serem generalizveis a projetos reais na indstria. As principais ameaas identificadas foram:

166

Interao entre seleo e tratamento: a amostra dos participantes selecionados no representativa dos profissionais da indstria brasileira de software. Alm de possurem relativa experincia industrial, grande parte dos pesquisadores ESE da COPPE/UFRJ possui acesso aos resultados da aplicao de uma pesquisa tecnolgica de ponta, o que no ocorre maioria dos profissionais da indstria de software. Pesquisas tm demonstrado que muitos dos conceitos de Engenharia de Software ainda no esto difundidos adequadamente na indstria de software brasileira (VILLELA, 2004). Portanto, uma ameaa considervel aos resultados do estudo seria atribuir um eventual sucesso do estudo aplicao da tcnica em si, quando na realidade poderia ter sido efeito da alta qualificao do participante, representando um confounding factor.

Interao entre Ambiente e Tratamento: por utilizar um documento arquitetural criado em um ambiente industrial, acreditamos que essa ameaa no seja concretizada.

167

Apndice E Questionrio de Avaliao PsExperimento

Grupo de Engenharia de Software Experimental
Questionrio de Avaliao Ps-Experimento
Por favor, responda o questionrio abaixo de forma a nos permitir o registro de sua opinio sobre a aplicao da abordagem para inspeo de documentos arquitetural baseada em checklist (ArqCheck), alm dos procedimentos envolvidos na conduo do exerccio. A sua opinio muito importante para ns. 1. Como voc classificou o grau de dificuldade da aplicao do checklist?
___Muito Fcil ___Fcil ___Mediano ___Difcil ___Muito Difcil

2. Na sua opinio, quais aspectos da tcnica tornam sua aplicao fcil / difcil de usar? 3. Voc identificou os defeitos utilizando somente os itens de avaliao presentes no checklist?
___ ___ Sim. Utilizei somente o conhecimento presente nos itens para avaliar o documento arquitetural fornecido. No. Eu utilizei conhecimento prprio

4. Caso voc tenha identificado defeitos com o auxlio de outro tipo de conhecimento, alm do presente no checklist, por exemplo, conhecimento do domnio, identifique para que defeitos isso ocorreu e que tipo de conhecimento que voc utilizou.

5. Como o checklist o auxiliou a identificar defeitos nos requisitos?

___ ___ ___ Negativamente. O checklist atuou como um obstculo. O meu desempenho teria sido melhor se eu no o tivesse utilizado. Neutro. Acho que encontraria os mesmos defeitos caso no tivesse utilizado o checklist Positivamente. O checklist me auxiliou na deteco de defeitos. Talvez no tivesse detectado alguns defeitos caso no o tivesse utilizado.

6. Como as Guias de identificao de contexto auxiliaram na identificao de defeitos relacionados a requisitos de qualidade?
___ ___ Negativamente. As guias atuaram como um obstculo. O meu desempenho teria sido melhor se eu no a tivesse utilizado. Neutro. Acho que encontraria os mesmos defeitos caso no tivesse utilizado as guias

168

___

Positivamente. As guias me auxiliaram na deteco de defeitos. Talvez no tivesse detectado alguns defeitos caso no a tivesse utilizado.

7. Existe algum item de avaliao que no foi compreendido? Se sim, identifique-o. 8. Voc utilizaria a tcnica em inspees futuras?
___No. ___ Talvez. ___ Sim.

9. Na sua opinio, como a tcnica poderia ser melhorada? Itens de avaliao para identificar defeitos: Taxonomia para categorizao de defeitos: 10. Por favor, registre quaisquer comentrios que julgar pertinente.

Muito obrigado por sua participao!

169

Anexo A Notao para Modelar Processo de Software

Este anexo apresenta a notao apresentada em (VILLELA, 2004) utilizada na modelagem de processo de software. Esta notao foi utilizada para descrever todos os processos presentes nessa dissertao.

A descrio de um processo apresenta os aspectos que devem ser considerados, os produtos gerados e os responsveis ou envolvidos em cada atividade. FALBO (1998) definiu uma ontologia de processo de software visando identificar e descrever os principais elementos que o compem. VILLELA (2004) definiu uma abordagem de modelagem de processos organizacionais que permite a representao grfica dos itens de um processo. Essa representao grfica est parcialmente descrita na Tabela A.1.
Tabela A.1 Notao de modelagem de processo de software Entidade Processo ou Subprocessos Ator Descrio Sub-processos so processos que fazem parte de um processo mais amplo. Objeto que representa uma pessoa, agente ou unidade organizacional. Atividades so tarefas ou trabalhos a serem realizados. Uma atividade requer recursos e pode consumir ou produzir artefatos. Uma atividade atmica consiste em uma atividade que no pode ser decomposta em outras atividades. Uma atividade composta consiste em uma atividade que pode ser decomposta em outras atividades. Objeto que representa um conhecimento que pode ser expresso em palavras e nmeros e ser facilmente transmitido e compartilhado. Objeto que representa um conhecimento que altamente pessoal e difcil de formalizar, o que o torna tambm difcil de ser compartilhado. Ligao que estabelece um insumo (se o fluxo de entrada) ou um produto de uma atividade (se o fluxo de sada). Atividades, em qualquer nvel, podem depender da finalizao de outras atividades, denominadas pr-atividades. A dependncia entre as atividades do processo representada por esse smbolo. Forma de Representao

Atividade Elementar

Atividade Composta Conhecimento Explcito Conhecimento Tcito Fluxo de Entrada / Sada Dependncia entre Atividades

Documento

Documento so produtos de software produzidos ou consumidos por atividades durante a sua realizao Objeto puramente notacional, proveniente dos diagramas de estado e que indica onde iniciado o fluxo de atividades que definem um processo ou uma atividade composta. Objeto puramente notacional, proveniente dos diagramas de estado e que indica onde encerrado o fluxo de atividades que definem um processo ou uma atividade composta.

Estado Inicial

Estado Final

171

Anexo B Tticas Arquiteturais

Esse apndice tem como objetivo descrever as diferentes tticas arquiteturais usadas como base para a criao dos itens do checklist que compe a abordagem para inspeo de documentos arquiteturais apresentada nessa dissertao. Essas tticas foram extradas principalmente de (BASS et al., 2003).

B.1 Tticas relativas ao atributo de qualidade Desempenho

Desempenho para um software consiste principalmente no tempo gasto para realizar um determinado servio. Essa quantidade de tempo est relacionada a duas coisas: disponibilidade do recurso para realizar o servio e forma como o servio executado. No contexto de arquitetura, o atendimento a um requisito de desempenho influencia principalmente na forma como os fluxos de execuo so realizados, ou seja, na forma como os elementos arquiteturais se comunicam para realizar uma determinada responsabilidade. Entre as principais tticas arquiteturais que podem ser usadas visando atender requisitos desse tipo, temos: Controle da gerao de eventos: Procurar definir elementos arquiteturais e seus relacionamentos visando reduzir a freqncia de execuo de um determinado evento. Como por exemplo, o uso de um cache para armazenar informao no lugar de ter que re-executar o processo de obteno quando necessitar ter acesso informao, o que permitiria um maior desempenho na realizao da tarefa. Controle da freqncia de eventos externos: Se no existe nenhum controle sobre a chegada de eventos gerados externamente, uma fila de requisies pode perder informaes principalmente se a freqncia de processamento dessas requisies for muito baixa. No lugar de tratar cada evento de forma independente, essa ttica prope agrupar esses eventos em blocos para que possam ser tratados. se fossem processadas de forma individual. Reduo do overhead computacional: Elementos intermedirios so elementos utilizados normalmente como mediadores de comunicao. A presena de desse tipo de elementos pode aumentar o processamento de um fluxo de eventos, por exemplo. Sendo assim, a eliminao desse tipo de elemento aconselhvel. O processamento de requisies em bloco costuma ter um melhor desempenho do que

172

Aumento da concorrncia lgica: Durante a definio da arquitetura, deve-se identificar que seqncias de execuo podem ser realizadas em paralelo, o que pode melhorar o desempenho do software. Dependendo das caractersticas do sistema, abordagens como cliente-servidor pode ser utilizada. Nesse caso, os diferentes clientes executariam funcionalidades distintas, por exemplo.

B.2 Tticas relativas ao atributo de qualidade Disponibilidade

Disponibilidade consiste em permitir que o software execute as funcionalidades sempre que o usurio necessite. No contexto de arquitetura de software, a disponibilidade se traduz na garantia do bom funcionamento dos elementos arquiteturais relacionados a uma responsabilidade. As possveis tticas arquiteturais que podem ser utilizadas para garantir essa disponibilidade so: Ping/echo: Prope a definio de um elemento arquitetural que seja responsvel por enviar um ping ao elemento que deve sempre estar disponvel. Esse elemento espera portanto receber o eco de volta, dentro de um tempo pr-estabelecido, indicando a disponibilidade do elemento principal. Heartbeat: Prope que o elemento arquitetural emita um sinal (heartbeat) periodicamente e que deve ser recebido por um determinado elemento. Se o heartbeat falhar, supe-se que o elemento emissor falhou e um procedimento de correo de falhas executado. Redundncia Ativa: Prope que determinados componentes possuam redundncias. Esses componentes redundantes respondem aos eventos em paralelo para que ele fique sincronizado com o componente principal. Caso o principal fique indisponvel, a redundncia deve ocupar o seu lugar.

B.3 Tticas relativas ao atributo de qualidade Modificabilidade

Atender a um requisito de modificabilidade significa que, para as funcionalidades relacionadas a esse requisito, o custo de alterao deve ser o menor possvel. No contexto de uma arquitetura de software, modificabilidade est relacionada forma como a arquitetura foi projetada. Para que ela seja facilmente modificvel, os elementos que possuem grande chance de sofrerem alteraes devem ser projetados visando, caso ocorra alteraes em determinados elementos arquiteturais, evitar a propagao dessas modificaes em outros elementos que compem a arquitetura. Este grupo de tticas tem por objetivo reduzir o nmero de mdulos afetados por uma modificao:

173

Manter a coerncia semntica: Propem que seja feita ateno aos mdulos em relao s funcionalidades que eles implementam e os relacionamentos que eles realizam. O ideal que tudo isso seja feito em um mesmo contexto semntico, o que facilitaria a identificao dos elementos que devem ser modificados e dificultaria a propagao das mudanas no caso de alteraes. Um exemplo seria as separaes de responsabilidades proposta pelo MVC.

Isolar servios comuns: Funcionalidades que so comuns a vrios mdulos deveriam ser isoladas em um nico mdulo e quem necessitasse execut-las o fariam a travs desse mdulo.

Isolar candidatos a alteraes: Identificar as funcionalidades que possuem grande possibilidade de serem alteras e isol-las das que so estveis. Esse tipo de ttica costuma ser aplicada em um contexto de linha de produto, por exemplo.

Abstrair informaes: Propem dividir as informaes acessveis de um mdulo em dois tipos: pblicas e privadas. Diminuindo assim a propagao de mudanas caso esse mdulo deva ser alterado.

Separar as interfaces da implementao do mdulo: Definir interfaces para os mdulos que apresentem alta probabilidade de modificaes e evitar realizar modificaes nessas interfaces.

Usar intermedirios: Se B possui algum tipo de dependncia em relao a A que no seja semntica, possvel inserir um intermedirio entre B e A que gerencie as atividades associadas com esta dependncia, diminuindo assim a dependncia entre A e B.

B.4 Tticas relativas ao atributo de qualidade Segurana

Segurana est relacionado habilidade do software em restringir o uso no-autorizado de seus servios, permitindo o seu uso somente por usurios legtimos. No contexto arquitetural, esse tipo de requisito influencia o projeto da arquitetura atravs de novas funcionalidades adicionais que devem ser atendidas. Autenticao de usurios: Autenticar assegurar que um usurio ou computador remoto de fato quem diz ser. Autorizao dos usurios: Autorizar assegurar que um usurio autenticado possui os direitos para acessar ou modificar tanto dados quanto servios. Limitar a exposio: Garantir que o acesso a um componente que contm dados seguros feito somente por quem realmente necessita ter acesso a esses dados.

174

B.5 Tticas relativas ao atributo de qualidade Testabilidade

Visto que testar consome uma grande percentagem do custo de desenvolvimento do sistema, qualquer coisa que o usurio possa fazer para reduzir este custo ir render grandes benefcios. Sendo assim, testabilidade em um software consiste em oferecer facilidades para a realizao de teste em relao a determinadas funcionalidades. No contexto arquitetural, um requisito de testabilidade influencia atravs da necessidade em criar formas adicionais de acessar e controlar as funcionalidades e os dados dos elementos arquiteturais relacionados ao requisito especificado. Separar a interface da implementao: Separar a interface da implementao permite a substituio das implementaes por vrios propsitos relativos aos testes. Interfaces especficas de acesso: A definio de interfaces especfica para a realizao de teste permite capturar ou atribuir de valores de variveis para um componente durante a realizao dos testes, independente da sua execuo normal. Monitores: O componente pode registrar a situao, o nvel de performance, a capacidade, a segurana ou outra informao acessvel atravs de uma interface. Esta interface pode ser uma interface permanente do componente ou pode ser introduzida temporariamente atravs de uma tcnica de instrumentao como programao orientada a aspectos ou macros pr-processadas. Uma tcnica comum registrar eventos quando situaes monitoradas forem alcanadas.

B.6 Tticas relativas ao atributo de qualidade Usabilidade

Usabilidade em um software consiste em permitir sua fcil utilizao por parte do usurio, ou seja, facilidade em entender o uso das funcionalidades, permitir a adaptao do software suas necessidades e minimiza o impacto de possveis erros omitidos pelo usurio. No contexto de arquitetura de software, principalmente as caractersticas relacionadas minimizao de erros e adaptao s necessidades do usurio oferecem relevncia. Portanto, o atendimento a um requisito desse tipo consistem atender funcionalidades adicionais, significando assim o projeto de novos elementos ou a distribuio das novas responsabilidades a elementos j existentes.

175