PROCESSO DE MANUTENÇÃO DE SOFTWARE WEB APOIADO PELA MODELAGEM IHC

3rd International Conference on Information Systems and Technology Management 3º Congresso Internacional de Gestão da Tecnologia e Sistemas de Informação th World Continuous Auditing Conference De 3 de Maio a 02 de Junho de 2006 São Paulo/SP Brasil PROCESSO DE MANUTENÇÃO DE SOFTWARE WEB APOIADO PELA MODELAGEM IHC Alexandra Aparecida de Souza (POLI-Universidade de São Paulo, São Paulo, Brasil) alexandra.souza@poli.usp.br Jorge Luis Risco Becerra (POLI-Universidade de São Paulo, São Paulo, Brasil) jorge.becerra@poli.usp.br ABSTRACT Software systems for internet (web systems) have changed dynamically because they are able to reach the clients at low costs. Thus, the demand for product and service offers intensively creates new functions and changes the existing ones, with reduced response times, and most of the time with simultaneous development of parts of the systems. This kind of software must present strong performance specifications and secure transactions and information. The purpose of this study is to present the usage of the dynamic vision of HCI (Navigation Flow) of a web system as a support tool for the Software Maintenance process, offering help to define the maintenance scope, identify precisely the risks and impact points, obtain a precise estimate of time and effort, check the consistency of the interface and the navigation flow, and define quality methods and procedures. The analysis of this Software Maintenance process was done through case studies of the development of evolutionary and corrective maintenance projects of a web system of a financial sector, and the positive points and difficulties experimented were highlighted. Keywords: Human-Computer Interaction / User Interface, Software Architecture, Software Mintenance Poject Mnagement, Web Sites. RESUMO Sistemas de software para internet (sistemas web) são alterados com dinamismo crescente devido ao alcance dos clientes a baixo custo. Assim, a demanda de ofertas de produtos e serviços faz com que novas funções e alterações das existentes sejam muito intensas, com tempos reduzidos e muitas vezes com desenvolvimentos simultâneos de partes do sistema. Esse tipo de software deve apresentar fortes requisitos de desempenho e segurança transacional e de informações. O objetivo desse estudo é apresentar a utilização da visão dinâmica da IHC (Fluxo de Navegação) de um sistema web, como uma ferramenta de apoio no processo de Manutenção de software auxiliando muito fortemente nas tarefas de: definição do escopo da manutenção, identificação precisa dos riscos e dos pontos de impactos, obtenção de uma estimativa precisa do esforço e tempo, verificação da consistência da interface e do Fluxo de Navegação e definição de métodos e procedimentos de qualidade.a análise desse processo de Manutenção de software foi executada através de estudos de casos realizados no desenvolvimento de projetos de manutenção evolutivas e corretivas de um sistema web da área financeira, onde se destacaram os pontos positivos e as dificuldades vivenciadas. Palavras-chave: Interface Homem-Computador, Arquitetura de Software, Gestão de Projetos de Manutenção de Softwares, Web Sites. Agradecimentos: Ao Prof. Dr. Reginaldo Arakaki pelo apoio na elaboração deste trabalho. TECSI - Laboratório de Tecnologia e Sistemas de Informação FEA USP - www.tecsi.fea.usp.br 385

. Introdução O sucesso de um software consiste em, na fase de desenvolvimento, atender qualitativamente as necessidades do usuário e do seu negócio, levando em consideração prazos e custos compatíveis com a realidade do mercado. Assim, é possível atribuir a qualidade alcançada através da concepção de uma arquitetura sólida e flexível às mudanças, ao desenvolvimento de software com rapidez, efetividade e eficiência, com um mínimo de código e retrabalho. Para atender esse objetivo são utilizadas técnicas como modelagem de processo de negócio, modelagem de requisitos (utilizando o conceito de Orientação ao Objeto), projeto da interface e navegação, técnicas de componentização e procedimentos de validação do software, como testes e revisões técnicas, tanto no processo de concepção de um novo sistema, como nos procedimentos de manutenção corretiva e/ou inovadora de sistemas em operação, conforme roteiros de desenvolvimento existentes na literatura, entre eles pode-se citar o proposto por Pressman (995). Desta forma, com a contínua necessidade de intervenções em um software e sua extrema importância para viabilizar a operacionalidade de um sistema, os aspectos de correções de erros, a adequação e as novas características do negócio no qual está inserido são considerações importantes a se fazer. Em sistemas para Internet, essas intervenções tendem a ser muito mais dinâmicas devido à necessidade de disponibilidade imediata e à grande concorrência existente, na qual quem primeiro oferece um serviço e com um alto nível de qualidade tem grande possibilidade de ganhar a preferência dos usuários, conforme descrito por Nielsen (2000). Esse tipo de software deve apresentar fortes requisitos de desempenho e segurança transacional e de informações, características ainda mais importantes quando se trata de sistemas web para o segmento financeiro. Assim projetos de manutenção efetuados nesse tipo de software devem, sobretudo, garantir o desempenho (tempo de resposta) e a disponibilidade em tempo integral. Segundo Linger; Moore (200), o processo de manutenção de software mal realizado em um sistema em produção pode levar à sua indisponibilidade temporária, proporcionando prejuízos de negócio e a redução do tempo de vida do software devido à inserção de novos defeitos. Com o intuito de minimizar esses impactos, Fiutem et al. (996) propôs em seu estudo que a cada atividade de manutenção de um sistema é necessário o entendimento da sua arquitetura, identificando os elementos de software que a compõem e os seus relacionamentos. O objetivo deste trabalho é apresentar como a visão dinâmica da IHC, centrada no fluxo de navegação, de um sistema web em operação, com a estrutura proposta nesse estudo, que utiliza uma configuração especializada do diagrama de atividades da UML, representa o mapeamento existente nas interligações entre os vários elementos que compõem a sua arquitetura (páginas e links, componentes, módulos e elementos de base de dados, interfaces com sistemas externos, entre outros) através do comportamento de navegação. É objetivo também desse estudo apresentar esse diagrama como uma importante ferramenta de apoio no processo de Manutenção de Software auxiliando muito fortemente nas tarefas de: definição do escopo da manutenção (equivalente aos processos de Planejamento e Detalhamento do Escopo, conforme recomendações do PMBOK (PMI,2004)), identificação precisa dos riscos e dos pontos de impactos (equivalente ao processo de Identificação dos Riscos, conforme recomendações do PMBOK (PMI,2004)), obtenção de uma estimativa precisa do esforço e tempo (através de técnicas como Pontos de Função), verificação da consistência da interface e do Fluxo de Navegação e definição de métodos e procedimentos de qualidade. 386

2. Metodologia A Metodologia desenvolvida para a elaboração deste trabalho compreende as seguintes etapas: ) Proposição de uma estrutura de Fluxo de Navegação para Sistemas Web, com base em estudos de aspectos conceituais relacionados com Interface Humano Computador, Arquitetura de Software e Notação UML; 2) Apresentação do Fluxo de Navegação proposto como ferramenta de apoio no processo de desenvolvimento de manutenção de software web; 3) Aplicação da abordagem proposta a projetos de software web e avaliação dos resultados. Ao final do trabalho, são apresentadas as conclusões e as contribuições do estudo, bem como algumas propostas de trabalhos futuros a serem desenvolvidos nesta área. 3. A Estrutura do Fluxo de Navegação para Sistema Web Proposta O Fluxo de Navegação de um sistema web, apresentado nesse estudo, consiste em uma ferramenta gráfica que representa as interfaces gráficas (páginas e links) dos sites, juntamente com seus produtos e serviços, bem como o fluxo da navegação da interface e as transações locais e remotas acessadas, devendo ser orientado pelo fluxo do processo de negócio. Trata-se de representação gráfica especializada, que contém os diversos elementos que compõem a arquitetura do software, tais como: as páginas e links, os componentes, módulos e elementos de base de dados, as interfaces com sistemas externos (protocolos de comunicação), entre outros, bem como a interligação desses elementos através do Fluxo de Navegação da interface. Esse tipo de representação é uma importante ferramenta no processo de manutenção de sistemas softwares, pois segundo Fiutem et al. (996) a primeira atividade nesse tipo de projeto é identificar os itens que compõem a arquitetura do sistema bem como os seus relacionamentos (definição do escopo do projeto de manutenção). Entre os elementos de software mapeados no modelo apresentado neste estudo, a página possui uma característica especial.trata-se da definição de uma estrutura estática padrão para esse objeto, conforme proposto por Ricca; Tonella (200), pois para o mapeamento do Fluxo de Navegação de um sistema web, é necessário que todas as páginas que o compõem sejam semelhantes (padronização visual) e possuam o mesmo tipo de comportamento (estilo funcional). Para se obter a visão estática de uma IHC, pode-se valer da utilização de ferramentas gráficas, como por exemplo, o Diagrama de Classes da notação UML, que, nessa abordagem, será utilizado para apresentar as diferentes partes que compõem a página da IHC de um sistema web, seguindo um padrão estabelecido, e como elas estão relacionadas. A figura 3. apresenta a estrutura estática de uma página, representada pelo Diagrama de Classes, composta de Cabeçalho, Barra de Link, Barra de Menu, Corpo da Página e Rodapé. 387

Pagina * Cabeçalho Rodape * Barra de Link Barra de Menu Corpo da Pagina Fig. 3. Visão Estática da IHC Utilizando Diagramas de Classes. Conforme proposto por Ricca; Tonella (200), a partir da definição da arquitetura estática da página é possível mapear a visão dinâmica da IHC, ou seja, o Fluxo de Navegação dos elementos de software que compõem um sistema web. A obtenção dessa ferramenta gráfica pode ser realizada através da utilização do diagrama de atividades da notação UML. A modelagem do Fluxo de Navegação proposta nesse trabalho utiliza esse diagrama (com uma configuração especializada apresentada a seguir) para representar o Fluxo de Navegação de um sistema web, porém não mapeando somente a ligação existente entre páginas e links, mas também na interligação existente, através desse fluxo, dos vários elementos que compõem a arquitetura do sistema web (páginas e links, componentes, módulos e elementos de base de dados, interfaces com sistemas externos, entre outros). Nesta configuração particular do Diagrama de Atividades da notação UML, os estados e as atividades representam os artefatos de software que possuem grande importância na garantia da manutenibilidade do sistema, tais como páginas (apresentação ao usuário), transações ou protocolos de comunicação (acesso a legado ou a sistemas externos), elementos de base de dados, módulos e componentes (lógica de negócio), utilizando a abordagem da representação gráfica especializada, (como por exemplo, a utilização de cores) para identificar facilmente, no aspecto visual, cada um desses elementos apresentados no diagrama. Além disso, cada um desses itens possui um código estruturado de identificação que será referenciado nos demais documentos que compõem o projeto. A identificação dos pontos de início e de término de cada diagrama, também é realizada através de estados que neste caso utilizam a representação gráfica de estado inicial e final do diagrama de atividades. As ações de transição de estados (setas) representam os links existentes entre as páginas, além dos acessos e retornos aos componentes, módulos, elementos de base de dados, transações ou protocolos de comunicação. O Fluxo de Navegação deve espelhar o fluxo do processo de negócio do sistema, ou seja, apresentar os elementos de software que estão envolvidos e a maneira como são acionados na execução de uma funcionalidade, e conter uma organização baseada em níveis para facilitar o seu entendimento, além de possuir um identificador que contenha informações destinadas a sua identificação, como por exemplo: nome do site, do serviço e nível de explosão que está representado. Segundo Conallen (2000), para grandes sistemas web é melhor que os Fluxos de Navegação sejam divididos em vários diagramas, cada um focando uma funcionalidade. 388

C a b e ç a l h o P a g i n a B a r r a d e M e n u estão da Tecnologia e Sistemas de Informação A figura 3.2 a seguir foi elaborada para apresentar um modelo de Fluxo de Navegação construído com base na notação descrita acima, para um serviço de um site genérico, destacando telas, links, e componentes acionados. C o r p o d a P a g i n a I t e m P á g i n a I n i c i a l ( S e r v i ç o d o I t e m ) G E P G 0 0 5 L in k C o m p o n e n t e P r o c e s s o N e g ó c i o G E C M 0 0 L i n k d e R e t o r n o F l u x o d e E x c e ç ã o S i t e : G e n é r i c o S e r v i ç o : S e r v i ç o I t e m T i p o M a p a : C o r p o d e P á g i n a N í v e l : F l u x o V á li d o S i t e : G e n é r i c o S e r v i ç o : E x e m p l o T i p o M a p a : B a r r a d e M e n u N í v e l : P á g i n a N e g ó c i o ( R e s u l t a d o s d a O p e r a ç ã o ) G E P G 0 0 F l u x o V á li d o 2 P á g i n a I n i c i a l ( S e r v i ç o d o I t e m ) G E P G 0 0 5 U r l d e A c e s s o I t e m I t e m 5 B a r r a d e M e n u ( I t e n s d e M e n u ) G E P G 0 0 3 I t e m 2 P á g i n a I n i c i a l ( S e r v i ç o d o I t e m 2 ) G E P G 0 0 8 C o m p o n e n t e P r o c e s s o N e g ó c i o 2 G E C M 0 2 0 F l u x o V á li d o 2 F lu x o d e E x c e ç ã o 2 I t e m 3 I t e m 4 P á g i n a N e g ó c i o 2 ( R e s u l t a d o s d a O p e r a ç ã o ) G E P G 0 0 2 P á g i n a d e E r r o ( M e n s a g e m ) G E P G 0 0 4 P á g i n a I n i c i a l ( S e r v i ç o d o I t e m 3 ) G E P G 0 0 6 P á g i n a I n i c i a l ( S e r v i ç o d o I t e m 4 ) G E P G 0 0 7 L i n k F i n a l N o t a ç ã o P á g i n a A ç ã o, l i n k o u a c i o n a m e n t o / r e t o r n o d e t r a n s a ç ã o C o m p o n e n t e E s t a d o I n i c i a l S i t e : < > S e r v i ç o : < > T i p o M a p a : < > N í v e l : < > I d e n t i f i c a d o r d e M a p a s G E P G X X X C o d i f i c a ç ã o u t i l i z a d a p a r a i d e n t i f i c a r p á g i n a s E s t a d o F i n a l G E C M X X X C o d i f i c a ç ã o u t i l i z a d a p / i d e n t i f i c a r c o m p o n e n t e s Fig 3.2 Exemplo de Fluxo de Navegação Construído com Base na Notação Proposta. 389

Conforme ilustra a figura anterior, as páginas do sistema Genérico são compostas por cabeçalho, barra de menu e corpo de página. Todas as páginas possuem uma barra de menu com comportamento apresentado pelo Fluxo Barra de Menu, diferenciando somente o corpo de página. O serviço Serviço Item possui, em seu corpo de página, uma funcionalidade composta por quatro páginas e duas lógicas de negócio, assim o Fluxo de Navegação relativo a esse serviço mapeia o fluxo dessa funcionalidade e pode ser modelado em dois processos: Processo de Negócio e Processo de Negócio 2. O primeiro é representado pelos estados GEPG005, GECM00 e GEPG00 e o segundo pelos estados GECM020 e GEPG002. Esta figura apresenta também a notação especializada que foi utilizada para construção desse Fluxo, destacando a diferenciação do aspecto visual de cada um dos elementos apresentados no diagrama: as páginas são representadas pelos estados com sombreamento na cor branco e os componentes pelos estados com sombreamento na cor cinza. 4. O Fluxo de Navegação como Ferramenta de Apoio no Processo de Manutenção de Software Web A modelagem da IHC, é um importante mecanismo no processo de desenvolvimento de manutenção de software de um sistema web, apoiando na elaboração dos artefatos gerados em cada etapa do ciclo de desenvolvimento como, por exemplo, o proposto por Pressman (995). Dentre as ferramentas existentes para a modelagem da IHC está o modelo do Fluxo de Navegação. A modelagem do Fluxo de Navegação proposta nesse estudo e descrita no item 3 tratase de uma representação gráfica dos artefatos de software que compõem o sistema e suas interações, o que a torna uma ferramenta de apoio no ciclo de desenvolvimento de manutenção de software, pois a cada atividade de manutenção de um sistema é necessário o entendimento da sua arquitetura, identificando os elementos de software que a compõem e os seus relacionamentos para apoiar nas tarefas de: definição do escopo da manutenção, identificação precisa dos riscos e dos pontos de impactos, obtenção de uma estimativa precisa do esforço e tempo, verificação da consistência da interface e do Fluxo de Navegação e definição de métodos e procedimentos de qualidade. Esta seção tem como objetivo apresentar como este tipo de apoio é realizado. 4. Subsídios para Definição de Escopo de um Projeto de Manutenção em Sistemas Web Em projetos de manutenção de software é gasto um grande esforço para entender o sistema e identificar as partes ou itens de software que devem ser modificados, devido à dificuldade existente na realização dessas atividades, o que ocorre, em sua grande maioria, por falta de um modelo que represente a arquitetura do sistema (elementos que a compõem e seus relacionamentos). Como já dito anteriormente, o Fluxo de Navegação apresenta os elementos de software que compõem o sistema e deve espelhar o fluxo do processo de negócio. Assim, utilizando essa ferramenta gráfica, a definição do escopo da manutenção torna-se mais clara, pois é possível identificar mais facilmente quais itens de software estão contidos no modelo do domínio do problema. Esse processo de identificação se constitui de dois aspectos: a utilização de técnicas de modelagem de processo de negócio para mapear os requisitos, e o confronto desse modelo com o Fluxo de Navegação referente ao fluxo de negócio mapeado. Além da definição do escopo da manutenção é possível também identificar, através da leitura de códigos fontes ou de documentos de especificação técnica de implementação, quais itens de software (páginas, componentes, módulos, entre outros já citados) que compõem o escopo definido, efetivamente sofrerão intervenção de código. 390

A figura 4.. apresenta um exemplo de identificação de contexto de uma manutenção e dos itens de software que serão alterados, através do Fluxo de Navegação. Supondo-se que seja identificada uma manutenção inovadora no Processo de Negócio 2 no sistema Genérico, devido à necessidade de incluir novos requisitos, o contexto dessa manutenção é referente ao serviço Serviço Item desse sistema, representado pelo Fluxo de Navegação da figura 4.., ou seja, todos os elementos de software apresentados nesse diagrama poderão sofrer interferências direta ou indiretamente na realização dessa intervenção. Nesse sistema todos os requisitos do Processo de Negócio 2 estão implementados no componente Componente Processo Negócio 2, representado pelo estado GECM020, assim a intervenção será realizada somente nesse ponto (interferência direta), ou melhor, todos os produtos de software do sistema em operação, referentes ou ligados a essa lógica de negócio, deverão ser utilizados no processo de definição da arquitetura da manutenção de software que será efetuado. Item Página Inicial (Serviço do Item ) GEPG0 0 5 Link de Retorno S ite : Ge n é rico Serviço : Serviço Item Tipo Mapa: Corpo de Página N íve l: Link Com ponente Proces s o Negócio GEC M0 0 Flux o de Ex c eç ão Flux o V álido Página Negócio (Res ultados da Operação) GEPG0 0 Flux o V álido 2 Com ponente Proces s o Negócio 2 GEC M0 2 0 Flux o de Ex c eç ão 2 Fluxo Válido 2 Página Negócio 2 (Res ultados da Operação) GE P G0 0 2 Página de Erro (Me n s a g e m ) GE P G0 0 4 Link Final L eg en d a Item de software que sofrerá interferência direta na m anutenção. Fig. 4.. Fluxo de Navegação Identificando o Elemento de Software de Interferência Direta da Manutenção. A tabela 4.. a seguir apresenta um resumo parcial do escopo desse projeto de manutenção do Processo de Negócio 2 no sistema Genérico, apresentando o item de software de interferência direta identificado no Fluxo de navegação representado na figura 4... 39

Grau de Complexidade Interferência Direta (Código Fonte) Escopo da Manutenção Itens de Software GECM020 Tab. 4.. Resumo Parcial do Escopo do Projeto de Manutenção de Software 4.2 Análise de Impactos e Subsídios para Elaboração de Estimativas de Prazo e Esforço na Manutenção de Sistemas Web O Fluxo de Navegação é também uma importante ferramenta de apoio na análise de impactos, riscos e viabilidade de uma manutenção corretiva ou evolutiva. Essa análise pode ser obtida a partir da identificação dos elementos de software que sofrerão intervenção de código, no qual é possível visualizar e analisar com mais precisão os impactos dessa alteração (a abrangência) no sistema como um todo, identificando quais itens de software que, apesar de não sofrerem intervenções diretas (código fonte), serão atingidos indiretamente (através dos caminhos facilmente identificáveis no diagrama apresentado na figura 4.2.) e assim deverão ser também testados no processo de qualidade da manutenção. Com base nessa análise de impactos, pode-se identificar os riscos intrínsecos na alteração além de subsidiar a avaliação da viabilidade (custo/benefício) do projeto de manutenção (evolutiva e/ou corretiva). A figura 4.2. apresenta o mesmo exemplo de contexto de manutenção identificado no item anterior desse capítulo ( Serviço Item ), contudo demonstra os impactos que a intervenção que será realizada no Componente Processo Negócio 2, representado pelo estado GECM020, acarretarão aos outros elementos de software que compõem essa funcionalidade, representados pelos estados GEPG005, GEPG00, GECM00, GEPG002 e GEPG004, visto que todos estão fortemente acoplados. Assim, o risco intrínseco nessa alteração caracteriza-se como alto, dado que o processo de negócio do Serviço do Item poderá ficar parcialmente ou totalmente comprometido, caso a execução dessa manutenção de software não seja bem sucedida. O processo necessário para a estabelecer a qualidade dessa manutenção de software não será efetuado somente através do componente representado pelo estado GECM020, mas também por todos os itens de software que serão atingidos pelo impacto dessa intervenção, representados pelos estados GEPG005, GEPG00, GECM00, GEPG002 e GEPG004. A partir das informações já apresentadas nesse projeto de manutenção de software - escopo definido, item de software que sofrerá interferência direta, itens de software que sofrerão impactos e a intensidade do risco presente nessa atividade - é possível elaborar a estimativa de prazo e esforço necessários para sua execução, através de técnicas de estimativas como, por exemplo, Pontos de Função. 392

Item Página Inicial (Serviço do Item ) GEPG005 Link de Retorno Site: Genérico Serviço: Serviço Item Tipo Mapa: Corpo de Página N ível: Link Com ponente Processo Negócio GEC M00 Fluxo de Exceção Fluxo Válido Página Negócio (Resultados da Operação) GEPG00 Fluxo Válido 2 Com ponente Processo Negócio 2 GEC M020 Fluxo de Exceção 2 Fluxo Válido 2 Página Negócio 2 (Resultados da Operação) GEPG002 Página de Erro (Mensagem ) GEPG004 Link Final Legenda Item de software que sofrerá interferência direta na manutenção. Item de software que sofrerá impacto na manutenção. Fig. 4.2. Fluxo de Navegação Identificando os Impactos da Manutenção. A tabela 4.2. a seguir apresenta um resumo do escopo desse projeto de manutenção do Processo de Negócio 2 no sistema Genérico, apresentando os itens de software de interferência direta e os que sofrerão impactos, bem como os riscos existentes na execução desse projeto, identificados no Fluxo de navegação representado na figura 4.2.. 393

Grau de Complexidade Interferência Direta (Código Fonte) Impacto Risco Escopo da Manutenção Tab. 4.2. Resumo do Escopo do Projeto de Manutenção de Software Itens de Software GECM020 GEPG005, GECM00, GEPG00 e GEPG002. Alto acoplamento dos elementos de software: GEPG005, GECM00, GEPG00 e GEPG002 ao componente GECM020. 4.3 Verificação da Consistência da Interface e do Fluxo da Navegação A importância de se garantir a consistência da interface e do Fluxo de Navegação está na resistência a mudanças que é uma das características psicológicas do ser humano. Somos extremamente intransigentes em relação a alterações na maneira com que realizamos qualquer coisa na vida, inclusive para os sistemas computacionais com que interagimos. Quando se trata de sistemas corporativos, essa resistência à mudança pode ser minimizada através de treinamentos e vivências, contudo quando se trata de sistemas web esse sentimento pode levar a perda de clientes, devido à quantidade esmagadora de opções e da facilidade de ir para outros sites, conforme Nielsen (Nielsen, 2000: 0). Os usuários da Web demonstram uma notável impaciência e insistência na gratificação instantânea. Se não conseguirem descobrir como usar um website em aproximadamente um minuto, concluem que não vale a pena gastar seu tempo. O Fluxo de Navegação apresenta-se como uma importante ferramenta para verificar a aderência da alteração efetuada em sistemas web, no que se refere ao padrão funcional (comportamento) e visual (imagem) da IHC, verificando a consistência entre o alterado e o real (apontando o risco de divergência entre o real e o projetado). A partir dessa ferramenta é possível obter a permanência do padrão de estilos (sistema com imagem única - single-image system) definido para o sistema, garantindo assim a estética, a ergonomia e o estilo visual definidos, proporcionando uma maior facilidade de interação com os usuários e, conseqüentemente, menor necessidade de treinamento. 4.4 Elaboração da Cobertura de Testes da Manutenção em Sistemas Web O Fluxo de Navegação caracteriza-se também como uma ferramenta de apoio na obtenção de um processo de validação, conforme sugerido por Ricca; Tonella (200) e Tonella; Ricca (2002), e como controle de qualidade da manutenção, pois auxilia na elaboração dos planos de teste do sistema, identificando e roteirizando os casos de testes (cobertura) através dos caminhos facilmente identificáveis no diagrama. Abaixo, a figura 4.4. ilustra os caminhos existentes no diagrama que representa o Fluxo de Navegação do serviço Serviço Item do site Genérico. 394

Item Página Inicial (Serviço do Item ) GEPG005 Link de Retorno Site: Genérico Serviço: Serviço Item Tipo Mapa: Corpo de Página Nível: Link Com ponente Processo Negócio GECM00 Fluxo de Exceção Fluxo Válido Página Negócio (Resultados da Operação) GEPG00 Fluxo Válido 2 Com ponente Processo Negócio 2 GECM020 Fluxo de Exceção 2 Fluxo Válido 2 Página Negócio 2 (Resultados da Operação) GEPG002 Página de Erro (Mensagem ) GEPG004 Link Final Fig. 4.4. Fluxo de Navegação do Serviço Item. No Fluxo de Navegação apresentado na figura acima, é possível identificar, com facilidade, três caminhos existentes no diagrama e que serão convertidos como casos de testes no sistema, apresentados na tabela 4.4. a seguir. Cobertura de Testes # Caso de Teste (Objetivo) Composição de Estados Caso de Teste 2 Caso de Teste 2 3 Caso de Teste 3 Tab. 4.4. Cobertura de Testes Composto pelos estados: GEPG005, GECM00, GEPG00, GECM020 e GEPG002. Composto pelos estados: GEPG005, GECM00, GEPG004 e GEPG005. Composto pelos estados: GEPG005, GECM00, GEPG00, GECM020, GEPG004 e GEPG005. 395

Essa ferramenta pode também auxiliar na execução dos testes de validação de um sistema em empresas que não tenham adotado o procedimento de elaboração de Planos de Validação e Roteiros de Testes, pois através das setas é possível identificar os comportamentos que o software deve reproduzir a partir das interações efetuadas. 5. Resultados A abordagem proposta, descrita na seção anterior, foi aplicada a projetos de software com ênfase em aplicações financeiras para Web. Dados extraídos desses projetos, coletados durante o período de aproximadamente um ano junto a um grupo de desenvolvedores de uma organização, demonstraram algumas dificuldades em relação aos aspectos de desenvolvimento de manutenção nos sistemas em operação. Entre elas destacam-se: Elaboração de planejamentos de execução de projetos de manutenção deficiente, no que se refere à definição de escopo e elaboração de estimativas de prazo e esforço, devido a total falta de domínio do processo de negócio, bem como o Fluxo de Navegação das informações, e o não conhecimento da arquitetura técnica das soluções implementadas que, neste caso, possuem um alto acoplamento; Dificuldades na identificação, na análise dos impactos que podem ser ocasionados no sistema em operação e na execução de um projeto de manutenção (o famoso mexe aqui, estraga ali ); Dificuldades na verificação e mensuração dos riscos existentes e, conseqüentemente, no processo de análise de viabilidade de um projeto de manutenção; Inexistência de um processo de qualidade das intervenções de software efetuadas no sistema, como revisões técnicas sobre os artefatos gerados e a execução de procedimentos de testes que validam o atendimento aos requisitos de negócio solicitados no projeto de manutenção corretiva ou evolutiva. Os testes somente eram realizados pelo desenvolvedor da aplicação (inspeção de código) o que pode camuflar situações de inconsistência que serão apresentadas ao cliente no momento em que estiver utilizando o site, causando assim desconforto e perda de confiabilidade; Diminuição da qualidade geral dos sistemas desenvolvidos, em particular, em relação à interface com o usuário. Com a incorporação de novos colaboradores com menor experiência ao grupo e como os serviços são implementados e implantados de maneira gradual e evolutiva, problemas de falta de consistência em um site e entre sites foram notados, transparecendo para o usuário final que desenvolvedores diferentes implementaram partes diferentes do site. Os aspectos apresentados ocorreram em virtude da falta de documentação de negócio, da arquitetura das soluções desenvolvidas, da interface (IHC) e do Fluxo de Navegação do sistema em produção, bem como a atualização desses artefatos a cada manutenção efetuada no sistema. O referido grupo passou a utilizar a por aproximadamente um ano a abordagem proposta neste trabalho para alguns projetos de manutenção de sites que sofreram um processo de reengenharia de elaboração da documentação de negócio, do esboço da arquitetura técnica da solução em operação, bem como de modelagem da interface (IHC) e de mapeamento do Fluxo de Navegação. Os novos sites que foram desenvolvidos sobre o novo processo de desenvolvimento e assim possuem todos os artefatos de software já citados, também estão utilizando a abordagem proposta no processo de desenvolvimento de manutenção corretiva e/ou inovadora. 396

Como características particulares deste caso em estudo, pode-se destacar: O modelo do processo de negócio é elaborado na notação IDEF0, após o levantamento das necessidades e tarefas do usuário. Tal modelo é posteriormente validado com o mesmo e utilizado como referência para identificação dos pontos de automação; Um protótipo de telas preliminar é elaborado, com base no padrão de estilos (sistema com imagem única - single-image system) adotado, também com o intuito de levantar mais requisitos e necessidades do usuário; Todas as páginas que compõem os sites geridos por este grupo possuem uma estrutura estática padrão, conforme apresentado na figura 5. a seguir, definida no padrão de estilos (sistema com imagem única - single-image system) adotado; Pagina * Cabe çalho Rodape * Barra de Link Barra de M e nu Corpo da Pagina Fig. 5. Arquitetura das Páginas. O Fluxo de Navegação é construído/atualizado para projetar as telas e a navegação do sistema, com base no Modelo de Processo de Negócio, bem como para verificar a consistência com as telas e o Fluxo de Navegação já existente e em operação no site. A utilização do Fluxo de Navegação como ferramenta de apoio na elaboração do escopo da intervenção, da estimativa de prazo e esforço, da análise de impactos (identificação de riscos) e da viabilidade do projeto; Os módulos e componentes do sistema eram divididos pela equipe para serem implementados. As equipes utilizam o Fluxo de Navegação do site completo como referência para o desenvolvimento e integração entre as partes; O Fluxo de Navegação também é utilizado na validação do impacto da manutenção no comportamento e no aspecto visual da IHC do sistema; A elaboração do plano de teste do sistema se utiliza do Fluxo de Navegação para a identificação dos casos de testes, através da identificação dos diversos caminhos. Para cada estado do fluxo são previstas situações de exceção, tais como time-outs, erros de entrada de dados, entre outros. 397

Entre as vantagens alcançadas pela incorporação desta abordagem no processo de desenvolvimento de manutenção de software destacam-se: Maior facilidade na definição do escopo do projeto de manutenção e nos itens de software envolvidos na intervenção; Melhor avaliação dos riscos inerentes aos projetos de manutenção possibilitando assim elaboração de planejamentos de implantações e de contingências para evitar situações de indisponibilidade do site em produção; Maior facilidade na análise dos impactos de manutenção resultando em atendimentos mais rápidos. Solicitações emergenciais de correção e pequenas evoluções passaram a ser atendidas mais rapidamente (da ordem de 30% mais rápido do que no processo anterior), considerando todas as atividades existentes no ciclo de desenvolvimento de software proposto Pressman (995) - adotado neste estudo - como entendimento da solicitação, análise dos impactos e planejamento da intervenção, manutenção dos programas e os respectivos testes; Elaboração de estimativas de prazo e esforço para execução do projeto com maior precisão (da ordem 30%); Garantia da consistência e homogeneidade nas interfaces desenvolvidas; Maior cobertura de testes nos planos de validação e, conseqüentemente, maior qualidade do produto de software final, através da análise dos caminhos do Fluxo de Navegação; Redução dos tempos de homologação pelo cliente solicitante da aplicação da ordem de 20%; Melhor aceitação dos sites pelo usuário final, por refletir o processo de negócio. Entretanto, algumas dificuldades e pontos críticos da utilização da abordagem proposta foram encontrados, entre eles: Treinamento e aculturamento das equipes nos métodos e ferramentas propostas, que passam a deslocar esforços da fase de implementação para a fase de análise e projeto da interface; Dificuldade na definição da granularidade do Fluxo de Navegação, ou seja, na identificação de quais itens de software que devem ser mapeados com o intuito de não transformar o diagrama em uma tradução gráfica do código fonte dos softwares que compõem o sistema; Dificuldades no processo de divisão do Fluxo de Navegação proporcionando assim uma organização baseada em níveis; Necessidade de um Padrão de Estilos (sistema com imagem única - single-image system) muito bem definido e amplamente divulgado entre os integrantes da equipe de desenvolvimento; Falta de notação padronizada e de ferramenta automatizadas no mercado para a construção e manutenção do Fluxo de Navegação, exigindo esforço considerável por parte do desenvolvedor na sua elaboração e atualização. 398

6. Conclusões e Recomendações O estudo de caso realizado apresentou resultados satisfatórios na utilização da modelagem do Fluxo de Navegação proposta nesse estudo como ferramenta de apoio no processo de desenvolvimento de manutenção de software web. Devido a sua estrutura, composta pelos artefatos de software que compõem o sistema e suas interações, esse mecanismo foi utilizado em todas as atividades existentes nesse processo como entendimento da solicitação, análise dos impactos e planejamento da intervenção, manutenção dos programas e suas respectivas validações, fornecendo subsídios para elaborar os produtos referentes a: estimativa de prazo e esforço; análise de impactos, risco e viabilidade; integridade da consistência da IHC e do Fluxo de Navegação e na definição da cobertura de testes; além de disponibilizar uma ferramenta conceitual que traduz a linguagem do comportamento do usuário para outra que apóia o desenvolvedor na construção/alteração da aplicação. Esse trabalho foi focado em projetos de manutenção de sistemas web para uma instituição financeira, ou seja, não é possível garantir uma generalização dessa proposta para todos os tipos de sistemas existentes na área de software, como por exemplo, em projetos de robótica, pois podem ocorrer divergências no comportamento de navegação devido às características particulares da arquitetura. Assim, a aplicação da abordagem proposta em ambientes sistêmicos diferentes ao estudado pode ser escopo para trabalhos futuros. Conforme apresentado, a modelagem do Fluxo de Navegação proposta nesse estudo, apresentou bons resultados sendo utilizada como ferramenta de apoio no processo de desenvolvimento de manutenção de software web. Contudo foram identificados pontos críticos que devem ser vencidos, entre eles o processo de aculturamento das equipes e a falta de notação padronizada para esse tipo de representação, além da ausência de ferramentas automatizadas para elaboração e manutenção do Fluxo de Navegação nos moldes propostos nesse artigo, que mapeia não só as páginas do sistema como também outros produtos de software. A especificação e a construção desse tipo de ferramenta também pode ser escopo para trabalhos futuros. 399

7. Referências Bibliográficas BACHMANN, F. et al. Documenting Software Architecture: Documenting Behavior. Carnigie-Melon Software Engineering Institute, Pittsburgh, Tecnical Note, CMU/SEI-2002- TN-00, Janeiro 2002. CONALLEN, J. Building Web Applications with UML. Boston, Addison-Wesley Publishing Company, 2000. FIUTEM, R. et al. A Cliché-Based Environment to Support Architectural Reverse Engineering. IEEE Computer Society, Proceedings of the 996 International Conference on Software Maintenance (ICSM '96), 063-6773/96, 996. LINGER, R.; MOORE, A. Foundations for Survivable System Development: Service Traces, Intrusion Traces, and Evaluation Models. Carnigie-Melon Software Engineering Institute, Pittsburgh, Tecnical Report, CMU/SEI-200-TR-029, Outubro 200. NIELSEN, J. Projetando Web Sites. Rio de Janeiro, Editora Campus, 2000. PRESSMAN, R. Engenharia de Software. São Paulo, Makron Books, 995. PMBOK GUIDE. Project Management Body of Knowledge. Pennsylvania; PMI, 2004. RICCA, F.; TONELLA, P. Analysis and Testing of Web Applications. IEEE Computer Society, 0-7695-050-7/0, p.25-34, 200. RICCA, F.; TONELLA, P. Construction of the System Dependence Graph for Web Application Slicing. IEEE Computer Society, Proceedings of the Second IEEE International Workshop on Source Code Analysis and Manipulation (SCAM 02), 0-7695-793-5/02, 2002. TONELLA, P.; RICCA, F. Dynamic Model Extraction and Statistical Analysis of Web Applications. IEEE Computer Society, Proceedings of the Fourth International Workshop on Web Site Evolution (WSE 02), 0-7695-804-4/02, 2002. 400