APPLYING THE ATAM ON THE ARCHITECTURAL EVOLUTION OF AN ENTERPRISE SYSTEM

Transcrição

1 APPLYING THE ATAM ON THE ARCHITECTURAL EVOLUTION OF AN ENTERPRISE SYSTEM Thiago da Cruz Santos (Universidade de São Paulo, São Paulo, Brasil) The evolution of architectural aspects of software that is in full use, justified by the need to adapt to the business processes they support, requires the use of methods and techniques of engineering. This paper makes a study of the ATAM method in this context. From historical records of the evolution of software using ad hoc techniques, will be analyzed the application of ATAM, adapting the method to the reality of the company, identifying the gains that could have been obtained if the method had been applied. Keywords: ATAM, software architecture, architecture evaluation. APLICAÇÃO DO ATAM CORPORATIVO NA EVOLUÇÃO ARQUITETURAL DE UM SISTEMA A evolução de aspectos arquiteturais de um software que está em pleno uso, justificada pela necessidade de adequação aos processos de negócio que suportam, exige o uso de métodos e técnicas de engenharia. Este trabalho realiza um estudo do método ATAM dentro deste contexto. A partir de registros históricos da evolução de um software utilizando técnicas ad hoc, será analisada a aplicação do ATAM, adaptando o método a realidade da empresa, identificando os ganhos que poderiam ter sido obtidos se o método tivesse sido aplicado. Palavras chave: ATAM, arquitetura de software, evolução arquitetural. 0974

2 1. Introdução A Tecnologia de Informação, hoje, é considerada um dos componentes mais importantes em ambientes corporativos e sua utilização se dá em níveis operacionais e estratégicos (Fundação Getúlio Vargas, 2005). Os sistemas de informação atuais deixaram de ser simples algoritmos e se transformaram em aplicativos complexos detentores de estratégias e regras de negócio vitais para o funcionamento das corporações (Buscariolli, 2010). Diante deste cenário, a complexidade dos sistemas de informação cresceu proporcionalmente a sua importância e os projetos de software passaram a ser estratégicos para as empresas. A qualidade do produto final de um projeto de software é relacionada diretamente com a qualidade dos serviços disponibilizados para clientes e até mesmo a imagem que o cliente tem das organizações. Essa associação da qualidade dos sistemas de informação e a qualidade de serviços prestados pelas corporações faz com que seja necessária a possibilidade de medir e avaliar se os projetos de software atenderão aos requisitos de negócio que solicitados (Buscariolli, 2010). De acordo com Oliveira e Nakagawa (2009), a engenharia de software tem dado crescente atenção para a área de arquitetura de software e esta, em um futuro próximo, atingirá o mesmo grau de importância de outras tecnologias bem sucedidas. A arquitetura de software é considerada como sendo a principal estrutura de um software e mostra os elementos de um software, as propriedades externamente visíveis e a relação entre eles. As decisões referentes à arquitetura podem influenciar o sistema a ser construído, podendo habilitar, facilitar, dificultar ou interferir no alcance dos requisitos funcionais e não funcionais de um software (Oliveira & Nakagawa, 2009). Levando em consideração a importância das arquiteturas de software, a sua aderência em relação aos requisitos funcionais e atributos de qualidade faz com que a condução de avaliações antes, durante ou depois do processo de desenvolvimento seja diretamente relacionadas a qualidade final de um software e permite a descoberta de potenciais problemas e a resolução dos mesmos (Oliveira & Nakagawa, 2009). Segundo Clements, Kazman e Klein (2009), a avaliação de arquitetura de software é considerada boa maneira de se evitar o futuro insucesso de um sistema e a partir da avaliação arquitetural a qualidade do software pode ser encontrada. Dessa forma uma arquitetura de software que passa por um processo de avaliação apresenta melhores perspectivas de que o desenvolvimento e a operação do sistema tenham a qualidade requerida em seus requisitos funcionais e não funcionais (Oliveira & Nakagawa, 2009). Um dos maiores desafios da arquitetura de software é lidar com requisitos não funcionais, pois eles são reconhecidos como fatores críticos para o sucesso de um projeto de um projeto de software. Requisitos não definidos claramente, incorretos ou incompletos podem levar o projeto ao fracasso (Xavier et al., 2008). A avaliação de arquitetura de software utilizando o ATAM visa analisar se a solução arquitetural proposta vai atender os atributos de qualidade requeridos pelo negócio. A evolução arquitetural de um software é natural e inevitável, pois os processos de negócio das empresas estão em constante evolução e o com o decorrer do tempo os sistemas corporativos que estão instanciados no mercado podem apresentar problemas estruturais que afetam requisitos de qualidade do sistema como flexibilidade, portabilidade e segurança. A alteração em algum aspecto arquitetural de um software sem utilizar 0975

3 técnicas pode influenciar negativamente algum atributo de qualidade. O caminho para implementar mudanças é o uso de técnicas que permitam o controle de qualidade da arquitetura (Pontes, 2012). 2. Fundamentação científica 2.1. Arquitetura de software O termo arquitetura de software possui diversas definições nas pesquisas sobre engenharia de software. Dentre as definições pesquisadas para a elaboração deste trabalho estão as seguintes: A arquitetura de software é considerada a principal estrutura de um sistema e compreende os elementos do software, as propriedades externamente visíveis e também o relacionamento entre estes. (Bass, Clements, & Kazman, 2003). A arquitetura de software é o elemento que leva ao entendimento da estrutura de um software. Através dela que é obtido o entendimento dos componentes e seus inter-relacionamentos; é relacionada com os atributos de qualidade do sistema e por isso impacta diretamente a qualidade do produto final de um projeto de software (Lessa, 2012). Muitas pessoas dentro das organizações estão interessadas na construção de um novo software. Estes serão denominados stakeholders 1. Clientes, usuários finais, desenvolvedores, gerentes de projetos e patrocinadores são alguns exemplos de stakeholders. Cada um desses stakeholders possuem diferentes preocupações que vão desde fatores técnicos e de infraestrutura até mesmo fatores ligados diretamente ao negócio como time to market 2, por exemplo (Bass et al., 2003).. Todos os stakeholders influenciam diretamente a arquitetura e o arquiteto deve considerar todos os fatores levantados por eles para propor a arquitetura do sistema (Bass et al., 2003). O trabalho realizado por Bass et al. (2003) mostra a arquitetura de software como sendo determinada no inicio do processo de desenvolvimento e dessa forma os requisitos funcionais e não funcionais do projeto podem ter suas soluções arquiteturais melhores definidas e avaliadas e assim os eventuais conflitos no atendimento desses requisitos possam ser analisados e conciliados entre os stakeholders do sistema. Segundo Oliveira e Nakagawa (2009), dada a importância da arquitetura de software na construção de um sistema, as decisões tomadas em relação a ela podem interferir no sistema que será concebido, habilitando, facilitando ou dificultando o alcance dos requisitos necessários para o sucesso do projeto. Segundo Bass et al. (2003), o processo necessário para a criação de uma arquitetura de software utilizada para desenhar, implementar e atingir as metas do software podem ser representadas pelas atividades abaixo: Criar o business case para o sistema; 1 Stakeholder, em português parte interessada, é um termo utilizado em gestão de projetos, administração e arquitetura de software. De maneira mais ampla, um stakeholder pode ser qualquer pessoa envolvida no processo ou projeto. 2 Time to market em administração e marketing significa o tempo de lançamento de um produto para o consumidor 0976

4 Entender os requisitos; Criar ou selecionar a arquitetura; Documentar e comunicar a arquitetura criada; Analisar e avaliar a arquitetura; Implementar o sistema baseado na arquitetura; Garantir que a implementação está conforme a arquitetura; 2.2. Atributos de qualidade Atributos de qualidade em projetos de software são relacionados a funcionalidades. A relação entre estes itens é se as funcionalidades do sistema serão desempenhadas de forma satisfatória e dentro das expectativas dos diferentes stakeholders do sistema (Oliveira & Nakagawa, 2009). Uma funcionalidade é a habilidade de o sistema desempenhar o trabalho para o qual ele foi projetado. Porém, é possível que uma funcionalidade desempenhe a seu objetivo de diferentes formas. Diferentes soluções podem ser dadas ao mesmo problema e o desafio da arquitetura de software é conseguir encontrar a melhor solução para que uma funcionalidade tenha o melhor desempenho possível (Bass et al., 2003). Durante o projeto para a construção de um software, o alcance dos atributos de qualidade deve ser considerado em todas as fases desde o desenho, passando por implementação até o deploy 3 e operação do sistema. Durante o desenho de uma arquitetura de software é importante definir cenários para cada atributo de qualidade para verificar se a solução adotada vai atendê-los adequadamente. A definição dada por Bass et al. (2003) mostra um cenário de atributo de qualidade dividido em seis partes: Fonte do estimulo: Uma entidade responsável por gerar o estímulo ao sistema; Estimulo: É a condição que precisa ser considerada quando ela acontece no sistema; Ambiente: As condições em que ocorrem o estímulo; Artefato: Qual parte do sistema será afetada pelo cenário; Resposta: É a resposta enviada pelo sistema quando ocorre o estimulo; Métrica da resposta: Quando ocorre uma resposta a um estimulo, estas respostas devem ser medidas para que os atributos de qualidade possam ser testados; 2.3. Avaliação de arquitetura de software 3 Deploy em tecnologia da informação significa disponibilizar algum software ou componente para uso. 0977

5 Dada a importância da arquitetura de software no que diz respeito à qualidade final de um projeto de software, se faz necessário um processo que garanta a aderência da arquitetura com os requisitos do sistema. De acordo com Clements et al., (2002), a avaliação de arquitetura de software visa atender a três propósitos: Conseguir identificar se a arquitetura do software proposta é aderente aos requisitos antes do software ser construído evitando assim eventuais retrabalhos. Elaborar cenários para todas as possibilidades arquiteturais e dessa forma conseguir identificar qual é a melhor opção de arquitetura para atender os requisitos de negócio. Identificar os riscos e pontos de sensibilidade de uma proposta de arquitetura. Segundo Bass et al. (2003) é importante que o foco da avaliação de arquitetura seja focada nos requisitos não funcionais, pois eles que são fatores decisivos no alcance dos atributos de qualidade e fortes influenciadores na arquitetura. No trabalho realizado por Xavier et al. (2008), os requisitos não funcionais são vistos como um ponto com baixa clareza e visibilidade nos projetos de software e os problemas referentes a requisitos não funcionais mal definidos são os mais caros e difíceis de corrigir. Dessa forma uma arquitetura que passa por um processo de avaliação tem uma perspectiva de apresentar melhores resultados no que se refere a qualidade do software ATAM O ATAM é visto na literatura como uma evolução do SAAM. Segundo Oliveira e Nakagawa (2009), a principal característica do ATAM é a utilização de tradeoffs. Na aplicação do ATAM são abordadas características de apoio a capacidade de modificação, confiabilidade, desempenho, segurança dentre outros atributos de qualidade descritos na norma NBR ISO/IEC Na arquitetura de software é importante ressaltar que algumas características são ortogonais, isto é, são dependentes de outras. Isso pode fazer que com ao alterar alguma característica da arquitetura, outra possa ser afetada. Essa peculiaridade da arquitetura de software faz com que seja necessária uma análise aprofundada de todas as características do software para que sejam produzidos os melhores tradeoffs das características em que a arquitetura de software está inserida (Oliveira & Nakagawa, 2009). É importante ressaltar que a análise de arquitetura de software não deve apenas considerar apenas aspectos técnicos na elaboração de tradeoffs e sim aspectos importantes a todos os stakeholders do sistema como aspectos financeiros e de negócio. Os principais insumos para a aplicação do ATAM são as metas de negócio, descrição da arquitetura de software e a especificação de software e tem como principais saídas uma lista de cenários, descrição de riscos, pontos de sensibilidade, mecanismos arquiteturais e tradeoffs. A figura 1 mostra, em IDEF0, os artefatos de entrada e saída para o processo de avaliação do ATAM. 0978

6 Figura 1 Representação do ATAM em IDEF0 Fonte: Lessa (2011) O ATAM é um método de avaliação constituído por duas fases e nove atividades conforme mostra a figura 2. Figura 2 Atividades do ATAM Fonte: Oliveira e Nakagawa (2009) Segundo Lessa (2012) as atividades descritas na figura 2 podem ser descritas da seguinte forma. Apresentação do ATAM: esclarecimento do processo de avaliação que será conduzido na análise da arquitetura 0979

7 Apresentação das diretivas de negócio: apresentação dos business drivers e o relacionamento destes com a arquitetura. Apresentação da arquitetura: apresentação da arquitetura inicialmente proposta. Identificação das abordagens arquiteturais: apresentam-se os mecanismos arquiteturais que suportarão os business drivers. Geração da árvore de utilidade: identificação dos atributos de qualidade e elaboração de cenários para estes atributos. Análise de proposições arquiteturais: avaliação de cada cenário gerado no passo anterior, levantando riscos, pontos de sensibilidade e tradeoffs. Brainstorm e priorização de cenários: complemento de cenários e priorização dos mesmos. Análise de proposições arquiteturais: avaliação de cada cenário gerado no passo anterior, levantando riscos, pontos de sensibilidade e tradeoffs dos novos cenários levantados no passo anterior. Apresentação dos resultados: As informações levantadas no processo de avaliação são compiladas e são apresentadas a todos os envolvidos. Segundo Bass et al. (2003), a aplicação do ATAM requer a participação de três grupos: Time de avaliação: Este grupo deve ser externo ao projeto que será avaliado. Usualmente faz parte deste grupo um número de 3 a 5 pessoas que serão as responsáveis pela condução dos trabalhos que serão realizados; Responsáveis pelas decisões do projeto: Neste grupo os principais responsáveis pelo projeto são os participantes: o arquiteto é uma figura indispensável nesta fase, assim como o gerente do projeto e um representante do cliente também pode participar; Stakeholders da arquitetura: São todas as pessoas que possuem alguma relação com o projeto que está sendo avaliado. Este grupo pode incluir desenvolvedores, testadores, usuários entre outros; Os procedimentos que vão do 1 ao 6 são considerados a primeira fase, onde o time de avaliação e os principais responsáveis pelas decisões realizam as análises. As demais atividades fazem parte da segunda fase, onde todos os demais stakeholders do software em avaliação participam da analise. 3. Experimento: Proposta de aplicação do ATAM na evolução de um software Para a aplicação do ATAM na evolução arquitetural de um sistema já existente este trabalho traz como proposta a aplicação do método em dois momentos distintos e complementares. Em primeiro lugar o ATAM deverá ser aplicado para avaliar o sistema já existente. Neste momento importantes conclusões podem ser levantadas, como por exemplo, a estratégia que será adotada na atualização da arquitetura. É possível que existam casos em 0980

8 que a avaliação arquitetural mostre a necessidade de um projeto de construção de um novo sistema e em outras situações a avaliação pode mostrar que a evolução de alguns componentes do atual sistema podem elevar a produtividade e aproximar o desempenho do software aos atributos de qualidade requeridos pelas áreas de negócio. Além disso, os artefatos gerados pelo ATAM nesse momento poderão ser utilizados pela área de arquitetura da empresa na elaboração da proposta de melhoria no sistema atual ou até mesmo na construção de um novo software. Após a execução da primeira análise, o ATAM deverá ser aplicado na proposta de atualização da arquitetura atual ou na proposta da nova arquitetura. O principal objetivo desta análise é verificar a aderência da proposta arquitetural aos requisitos de negócio. A aplicação do ATAM como descrito acima foi simulada em um projeto de uma seguradora. Na execução real do projeto a companhia necessitava migrar um sistema legado para uma nova arquitetura, mas após a implantação do novo sistema diversos problemas em relação ao atendimento dos requisitos de negócio foram encontrados. A solução final somente foi encontrada após a análise dos problemas ocorridos já com o sistema em produção. A proposta deste trabalho é apresentar uma proposta de aplicação do método ATAM para que esse tipo de problema possa ser evitado e os projetos de software atendam aos requisitos de negócio. Quando se fala na aplicação de um método logo se tem a impressão de processos complexos que demandam equipes especializadas e um alto custo para a execução. A proposta que será apresentada irá mostrar que sem que haja a necessidade de um aumento de equipe ou custos seria possível aplicar o método ATAM, de forma adaptada de acordo com as características da empresa, na avaliação de um sistema em processo de evolução. O exemplo dado abaixo mostra a aplicação do método ATAM conforme descrito acima Ambiente Este trabalho vai analisar um projeto implantado em uma seguradora. O software em que a analise será aplicada é um sistema de integração entre o sistema de cálculo e efetivação de propostas de seguros e o sistema de emissão de apólices. O projeto foi conduzido pela seguradora, mas todo o desenvolvimento foi feito por uma consultoria especializada. A área de tecnologia da seguradora não possuía um processo de desenvolvimento definido, ou seja, cada projeto era desenvolvido de uma forma, sem padronização, controles e, principalmente, garantia de qualidade Motivos para a aplicação do ATAM na arquitetura do sistema legado Neste momento será aplicado o ATAM na arquitetura do sistema legado. Este procedimento visa avaliar se de fato o sistema legado precisa ser substituído e principalmente levantar os Business Drivers e cenários que em um projeto em fase inicial poderiam servir como ponto de partida para a elaboração do modelo arquitetural. Envolvidos: Gerente do projeto, gerente da fábrica de software, arquiteto e representante da área de negócio. O ATAM sugere que o processo seja conduzido por uma equipe avaliadora, mas neste estudo, apenas os papeis citados acima serão envolvidos no processo de avaliação. 0981

9 1-Apresentar ATAM Responsável: Gerente do projeto Procedimentos: Passar os passos do método para um melhor entendimento de todos; Apresentar uma sucinta definição de requisitos funcionais, não funcionais e atributos de qualidade; Nesta etapa o método de avaliação é apresentado para os envolvidos no processo, os benefícios que podem ser obtidos são mostrados e a relação entre o tempo gasto no processo de avaliação e a qualidade do produto final do projeto deve ser esclarecida. 2-Apresentar diretivas do negócio Responsável: Gerente do projeto, arquiteto e representante da área de negócio. Procedimentos: Apresentam-se os Business Drivers Apresentam-se os requisitos não funcionais Classificam-se os requisitos não funcionais de acordo com a norma NBR ISO/IEC ; Nesta atividade a partir da documentação do projeto, realizada a partir de levantamentos com a área de negócio formaliza-se os requisitos do sistema e os apresenta aos envolvidos no processo de avaliação. 3-Apresentar arquitetura Responsável: Arquiteto Procedimentos: O arquiteto mostra a arquitetura atual do sistema; Como o objeto de análise nesta fase é o sistema legado o arquiteto apenas apresenta este sistema e o seu funcionamento para os participantes do processo de avaliação conhecerem o sistema que deverá ser evoluído. 4-Identificação das proposições arquiteturais Responsável: Arquiteto Procedimentos: Apresentar os mecanismos que a arquitetura possui para o atendimento dos atributos de qualidade definidos na segunda atividade aplicada; Por se tratar do sistema legado, a maioria dos atributos de qualidade não possuíam mecanismos que os atendesse. Após esta atividade do método ATAM já seria possível verificar que o sistema legado não alcançaria os atributos de qualidade requeridos para o atendimento dos dois business drivers requeridos pela seguradora. 0982

10 5-Geração da árvore de utilidade Mesmo que nesta fase já estivesse claro que a arquitetura do sistema legado não atenderia aos business drivers levantados, esta atividade do ATAM será executada, pois os cenários aqui levantados poderiam ser utilizados na elaboração do modelo de arquitetura do novo sistema. Responsável: Todos os envolvidos no processo de avaliação Procedimentos: Nesta fase os envolvidos no processo de avaliação levantam cenários a serem atendidos por cada atributo de qualidade, conforme exemplificado na tabela 1; Após o levantamento dos cenários, estes devem ser classificados. O trabalho realizado por Barbacci, Clements, Lattanze, Northrop, e Wood (2003), esta classificação se dá por votação entre os envolvidos. Este trabalho fará a classificação como a realizada por Lessa (2011), a partir de critérios, conforme exemplificado na tabela 1. Os critérios escolhidos para esta avaliação foram a dificuldade de implementação e a importância para o negócio. O resultado final se dá por soma simples; A partir dos cenários classificados monta-se uma lista com os cenários priorizados; Tabela 1 Cenários por atributos de qualidade Atributo de qualidade Funcionalidade Subcaracterística Adequação Requisito Desacoplar o sistema de cálculo do sistema de emissão Preocupação Manter o sistema de cálculo em funcionamento independente de problemas no sistema de emissão ID Cenários 1 1-Sistema de emissão indisponível 2 2-Sistema de emissão apresentando lentidão Fonte: o autor A geração da árvore de utilidade foi o último procedimento realizado nesta etapa do trabalho. Por se tratar da análise do sistema legado, os demais passos não foram considerados relevantes para serem executados. Nesta primeira fase de análise os seguintes artefatos foram gerados: Lista de business drivers formalizados; Lista de requisitos não funcionais classificados em forma de atributos de qualidade conforme norma NBR ISO/IEC ; Análise de arquitetura do sistema legado e conclusões sobre a relação dela com os requisitos necessários para a evolução do sistema; 0983

11 Lista de cenários referentes a cada requisito classificados e priorizados para a análise; Após essa análise chegou-se a conclusão de que o sistema legado, de fato, não era capaz de atender aos requisitos e por isso a decisão foi de construir um novo sistema Aplicação do ATAM na arquitetura proposta Conforme definição de Barbacci et al. (2003) o ATAM tem sua aplicação focada apenas no contexto dos atributos de qualidade que devem ser parte do sistema. Por isso, os artefatos gerados na avaliação do sistema legado serão utilizados também nesta fase da avaliação, uma vez que os requisitos de negócio não sofreram nenhuma alteração de uma fase para a outra. 1-Apresentar ATAM Esta atividade não será necessária, pois já foi realizada na avaliação do sistema legado e os participantes deste processo serão os mesmos. 2-Apresentar diretivas de negócio As diretivas de negócio são as mesmas que foram apresentadas na avaliação do sistema legado. 3-Apresentar a arquitetura Nesta fase a arquitetura proposta será apresentada pelo arquiteto aos demais participantes do processo de avaliação. Com a utilização dos artefatos gerados na avaliação do sistema legado a arquitetura que será alvo nesta avaliação é a proposta arquitetural considerando as evoluções realizadas pela área de arquitetura. 4-Identificação das proposições arquiteturais Responsável: Arquiteto Procedimentos: Nesta atividade, os mecanismos presentes na arquitetura são associados aos requisitos do sistema. Não há análise neste momento. Esta será a primeira atividade realizada integralmente nesta segunda avaliação. Foi elaborada a tabela 2, exemplificada abaixo, para associar os mecanismos previstos na arquitetura com os requisitos do sistema. Tabela 2 Mecanismos por requisito Sistema evoluído Mecanismos Funcionalidade Desacoplar o sistema de cálculo do sistema Requisito de emissão Subcaracterística Mecanismo 0984

12 Adequação Fonte: o autor Criar uma estrutura de integração, com base de dados replicada e aplicações BizTalk para cada produto comercializado. Esta estrutura será independente, ou seja, seu funcionamento não afeta ao sistema de cálculo e problemas no sistema de emissão serão imperceptíveis ao cálculo. 5-Geração da árvore de utilidade Serão utilizados os mesmo artefatos gerados na avaliação do sistema legado. 6-Análise das proposições arquiteturais Responsável: Arquiteto Procedimentos: Nesta atividade do processo de avaliação os cenários identificados na atividade anterior são analisados. O objetivo é determinar os riscos, não riscos, pontos de sensibilidade e tradeoffs. Tabela 3 Análise de cenários priorizados Atributo de qualidade Funcionalidade Subcaracterística Adequação Requisito Desacoplar o sistema de cálculo do sistema de emissão Preocupação Manter o sistema de cálculo em funcionamento independente de problemas no sistema de emissão Cenário 1-Sistema de emissão indisponível 2-Sistema de emissão apresentando lentidão Ambiente Sistema de cálculo em operação normal Estimulo Problema de infraestrutura em um dos componentes do sistema de emissão Mecanismo Criar uma estrutura de integração, com base de dados replicada e aplicações BizTalk para cada produto comercializado. Esta estrutura será independente, ou seja, seu funcionamento não afeta ao sistema de cálculo e problemas no sistema de emissão serão imperceptíveis ao cálculo. Medidas de Corrente Desejável Melhor Pior Resposta 100% 100% 100% <100% Considerações sobre a arquitetura Riscos Não existe 0985

13 Não riscos Pontos de sensibilidade Tradeoffs Fonte: o autor Este requisito será 100% atendido sob qualquer circunstância. Não existe Não existe 7-Brainstorm e priorização de cenários Nesta fase, o ATAM sugere que outros stakeholders sejam incluídos no processo de avaliação e que os cenários levantados até este momento sejam discutidos com esse novo grupo. Além disso, novos cenários podem ser incluídos na lista atual e o processo de classificação deve ser repetido. Por se tratar da análise de um projeto já concluído, este procedimento não será executado neste estudo. Em uma aplicação real do ATAM esta fase é de grande importância, pois é nela que possíveis falhas e lacunas nas análises anteriores seriam descobertas e a abrangência da avaliação cobriria uma parcela maior dos cenários possíveis do sistema. 8-Análise das proposições arquiteturais Esta atividade é complementar a atividade 6, onde os novos cenários levantados na atividade 7 são analisados da mesma forma em que são analisados na atividade 6. Como não foi executada a atividade 7, não existem novos cenários a serem analisados. 9-Apresentação dos resultados Neste último momento do processo de avaliação os resultados são apresentados. Todas as informações são compiladas e é gerada a documentação do processo. Como a avaliação realizada neste trabalho foi feita em duas etapas, primeiro no sistema legado e depois na arquitetura proposta, os artefatos gerados nos dois momentos devem ser apresentados. O processo de avaliação gerou os seguintes artefatos: Lista de business drivers formalizados; Lista de requisitos não funcionais classificados em forma de atributos de qualidade conforme norma NBR ISO/IEC ; Análise de arquitetura do sistema legado e conclusões sobre a relação dela com os requisitos necessários para o novo sistema; Lista de cenários necessários para a avaliação do sistema; Análise técnica dos cenários; Lista de riscos, não riscos, pontos de sensibilidade e tradeoffs referentes a arquitetura; 0986

14 3.4. Resultado A aplicação do ATAM em um sistema corporativo, embora pouco difundida, se mostra viável desde que o método seja adaptado a realidade da empresa. Os resultados alcançados com a aplicação desse trabalho se mostraram satisfatórios, pois a assertividade do produto final deveria se mostrar maior do que em outros projetos desenvolvidos pela empresa e não haveria um aumento significativo no tempo do projeto e também a necessidade de aumento na equipe. A partir do resultado obtido neste estudo notou-se que o tempo despendido com manutenções imediatas a implantação do projeto e também os custos com retrabalhos resultantes de falhas na definição da arquitetura do projeto seriam menores do que em projetos similares. 4. Conclusões A partir da motivação de diminuir os problemas inerentes a falta de um processo de desenvolvimento assertivo e que sejam capazes de atender os processos de negócio dentro de padrões esperados pelas áreas clientes das corporações, este trabalho propôs a utilização de um método de avaliação arquitetural, o ATAM, para avaliar no inicio do processo de evolução de um software de integração de sistemas. A experiência com o projeto realizado na seguradora mostrou que a falta de alinhamento entre o negócio e a tecnologia trouxe problemas de implementação que só puderam ser encontrados após o software estar em produção. O atual papel da tecnologia de informação mostra que esse tipo de falha nos projetos, pode causar problemas irreparáveis a imagem da empresa perante seus clientes ou até mesmo perdas financeiras. Os trabalhos elaborados pelo SEI mostram a utilização do ATAM em projetos de aplicações críticas como projetos militares e governamentais, que não era o caso do software alvo de analise neste estudo. Diante da diferença entre a natureza das aplicações pesquisadas como referência e a aplicação deste estudo algumas alterações foram feitas no processo sugerido por Bass et al. (2003). O grupo de avaliação foi diminuído e apenas os envolvidos diretamente com o projeto participaram. A falta de uma equipe de avaliação não se mostrou como um impedimento no alcance dos objetivos do processo de avaliação, pois todos os participantes possuíam os conhecimentos técnicos e processuais necessários para fazer uma avaliação adequada. Além da mudança nos envolvidos no processo, não foram executadas as atividades 7 e 8 do ATAM, pois a sua execução não foi considerada relevante devido ao fato do estudo estar sendo feito sobre um projeto já realizado. A aplicação do método em duas etapas, primeiro na avaliação de um sistema legado e depois na avaliação da proposta de arquitetura de um novo sistema, se mostra factível e se tivesse, de fato, sido aplicada no projeto, os artefatos gerados na avaliação do sistema legado poderiam ser utilizados na elaboração da nova arquitetura e assim seria possível chegar a um resultado mais próximo de alcançar os requisitos do negócio do que realmente aconteceu. Durante o projeto o sistema implantado passou por uma grande reformulação, pois a primeira arquitetura não atendia minimamente aos requisitos do negócio, ou seja, a solução mais próxima do ideal foi encontrada após tentativas e erros. Durante a elaboração desta pesquisa chegou-se a seguinte lista de pontos positivos e pontos negativo decorrentes da utilização do ATAM na avaliação arquitetural do projeto. Pontos positivos observados 0987

15 - Exposição formal dos requisitos não funcionais; - Avaliação da arquitetura do software em relação aos requisitos de negócio; - Exposição de riscos, pontos de sensibilidade, tradeoffs para todos os stakeholders do sistema; - Possibilidade de prever o comportamento do sistema através da elaboração de cenários; - Análise detalhada dos pontos mais importantes do sistema; Pontos negativos observados - Falta de maturidade da empresa para colocar em prática um processo de avaliação; - Falta de conhecimento dos envolvidos a respeito do processo de negócio; - Dificuldade na priorização dos cenários; - Falta de tempo para executar o processo durante o andamento do projeto; - Dificuldade em disseminar a importância de um processo de avaliação; Referências bibliográficas Barbacci, M; Clements, P.; Lattanze, A; Northrop, L; Wood, W. (2003) Using the Architecture Tradeoff Analysis Method (ATAM) to Evaluate the Software Architecture for a Product Line of Avionics Systems: A Case Study. Software Engineering Institute, Carnegie Mellon University, Pittsburgh. Bass, L.; Clements, P.; Kazman, R. (2003) Software Architecture in Pratice. Addison Wesley. Buscariolli, M. L. (2010) Estratégia de priorização de testes de software com base em controle e fatores de risco. Dissertação (Mestrado em Engenharia de Computação). Instituto de Pesquisas Tecnológicas, São Paulo. Clements, P; Kazman, R.; Klein, M. (2002) Evaluating Software Architecture. Addison Wesley. Fundação Getúlio Vargas. (2005) Benefício do Uso de Tecnologia da Informação no Desempenho Empresarial. Rio de Janeiro. Laurindo, F. et al. (2001) O papel da Tecnologia de Informação (TI) na Estratégia das Organizações. Universidade de São Paulo. São Paulo. Leopoldino, C. (2004) Avaliação de Riscos em Desenvolvimento de Software. Dissertação (Mestrado em Administração de Empresas). Universidade Federal do Rio Grande do Sul, Porto Alegre. Lessa, C. (2011) Avaliação Arquitetural de Sistema de Apoio à Decisão Utilizando ATAM e CBM Integradamente. Dissertação (Mestrado em Engenharia de Computação). Instituto de Pesquisas Tecnológicas, São Paulo. NBR ISO/IEC (2003) Engenharia de Software - Qualidade de Produto. Parte 1: Modelo de Qualidade. 0988

16 Oliveira, L.; Nakagawa, E. (2009) Um Levantamento de Métodos de Avaliação de Arquiteturas de Software Específicas. Universidade de São Paulo. São Carlos. Pontes, D. (2012) Evolução de software baseada em avaliações de arquiteturas. Dissertação (Mestrado em Engenharia). Universidade de São Paulo, São Paulo. Shaw, M; Clements P. (2006) The Golden Age of Software Architecture: A Comprehensive Survey. Software Engineering Institute, Carnegie Mellon University, Pittsburgh. Xavier, L. et al. (2008) Integração de Requisitos Não-Funcionais a Processos de Negócio: Integrando BPMN e NFR. Universidade Federal de Pernambuco. Pernambuco. 0989