Universidade Federal de Santa Catarina Florianpolis SC - Brasil www.producaoonline.ufsc.br ISSN 1676 - 1901 / Vol. 8/ Num.

1/ maro de 2008

GESTO DE ESCOPO EM PROJETOS DE APLICAES WEB SCOPE MANAGEMENT IN WEB APPLICATION PROJECTS
Cristina Coelho de Abreu Pinna Mestre em Engenharia Universidade de So Paulo Sistemas Digitais Av. Prof. Almeida Prado, tr. 2, n 128 cpinna@uol.com.br Marly Monteiro de Carvalho Professora Livre-docente Universidade de So Paulo Departamento Engenharia de Produo Av. Prof. Almeida Prado n 531 2 Andar CEP: 05508-900 - Cidade Universitria - So Paulo Tel.: (11) 3091-5363 marlymc@usp.br

RESUMO Os projetos de software esto sujeitos a uma srie de incertezas e riscos, especialmente aqueles que envolvem aplicaes Web, em virtude da competio mercadolgica na busca de disponibilizar cada vez mais novidades em servios eletrnicos e virtuais em tempos cada vez menores (Internet timing). Outro ponto crtico est no foco adotado para a gesto de projetos de aplicaes Web foco na tecnologia ou no processo de negcio ? Este fato gera dificuldades na homologao do software pelo cliente, que poderiam ser contornadas com um bom gerenciamento do escopo do projeto desde fases iniciais do projeto (concepo e planejamento). O trabalho ir apresentar uma abordagem que pode ser utilizada na gesto de projetos de aplicaes Web para minimizao das incertezas e riscos na definio de escopo e de requisitos que afetam projetos desta natureza. Ser realizada uma anlise comparativa e crtica entre diversos instrumentos e tcnicas que podem ser utilizados na definio de escopo e

Universidade Federal de Santa Catarina Florianpolis SC - Brasil www.producaoonline.ufsc.br ISSN 1676 - 1901 / Vol. 8/ Num. 1/ maro de 2008

prioridades, tais como: Quality Function Deployment (QFD), Modelo do Processo de Negcio e Particionamento. Palavras-chave: Gesto de Projetos, Gesto de Escopo, Aplicao Web, QFD. ABSTRACT Software projects are subjected to certain risks and uncertainties, especially those that include Web applications, due to the fact that market competition aims to have electronic and virtual services available in a shorter and shorter period of time (also known as Internet timing). Another critical factor relates to the focus to be adopted into the management of Web application projects should technology or business process be emphasized? This fact produces some difficulties in the acceptance of the software by the customer. This problem could be minimized by appropriate management of the project scope from its earliest phases (conception and planning). The article will present an approach that can be utilized on the management of Web applications projects for the minimization of uncertainties and risks when defining scope. A comparative and critical analysis will be carried out among several instruments and techniques that can be utilized on the definition of scope and priorities such as: QFD, Business Process Modeling and Partitioning. Key-words: Project Management, Scope Management, Web applications, QFD.

1. INTRODUO

Os projetos de software, devido a sua natureza, esto sujeitos a uma srie de incertezas e riscos relacionados com custos, escopo/requisitos, recursos humanos e materiais, prazos, expectativas do cliente, da equipe, do investidor, dentre outros. Tais incertezas e riscos so acentuados em projetos que envolvem aplicaes Internet, desde a construo de um simples site institucional at sites de comrcio eletrnico (B2C Business-to-Consumer e B2B Business-to-Business), em virtude da competio mercadolgica na busca de disponibilizar cada vez mais novidades em servios eletrnicos e virtuais em tempos cada vez menores (denominado Internet timing) (BROWN, 2000). Quando estas incertezas e riscos no so adequadamente gerenciados, a qualidade do produto final pode ser comprometida, a expectativa do cliente pode no ser atendida, e a equipe que precisa conviver com ansiedades e conflitos durante a vida do projeto pode ter sua produtividade reduzida.

Universidade Federal de Santa Catarina Florianpolis SC - Brasil www.producaoonline.ufsc.br ISSN 1676 - 1901 / Vol. 8/ Num. 1/ maro de 2008

Em projetos de desenvolvimento de aplicaes Web, muitas vezes, os prazos de implantao dos sistemas so curtos e pr-definidos pelo cliente (conceito de time-boxing), cabendo ento uma definio de escopo e requisitos adequada para garantir a qualidade e adequao da expectativa em relao ao produto a ser entregue. Outro ponto crtico est no foco adotado para a gesto de projetos de aplicaes Web foco na tecnologia ou foco no processo de negcio. Muitas vezes, por preciosismo, o projetista ou o desenvolvedor se foca nos requisitos tecnolgicos mais sofisticados ou inovadores, mas que no trazem benefcios para o cliente do ponto de vista de negcio. Este fato causa ento dificuldades na homologao do software pelo cliente, por este no atender suas expectativas e/ou necessidades (McCONNEL, 1996). Considerando o ciclo de vida de um projeto, as incertezas e riscos relacionados com o escopo do projeto e requisitos do produto so grandes nas fases iniciais do projeto (concepo e planejamento) e tendem a diminuir nas fases posteriores. Por outro lado, os custos envolvidos na identificao de problemas e inconsistncias nas fases iniciais de um projeto so muito menores se comparados com os custos na identificao de problemas em fases posteriores, em virtude dos retrabalhos. Segundo Pressman (2005), uma mudana identificada na fase de desenvolvimento custa de 1,5 a 6 vezes mais do que se ela fosse identificada na fase de definio de requisitos e de 60 a 100 vezes mais na fase de manuteno, depois que o sistema est implantado. Portanto, a adoo de mtodos e tcnicas que apiam a definio clara e precisa do escopo de um projeto de software, bem como a priorizao e aderncia dos requisitos do produto com as necessidades do cliente j nas fases iniciais do projeto permitem garantir a qualidade do produto final, reduzindo custos de retrabalho e expectativas inadequadas. De maneira resumida, pode-se afirmar que os projetos de aplicaes Web esto frequentemente sujeitos a aumento de custos, prazos e retrabalhos. O objetivo deve trabalho demonstrar que a adoo de alguns mtodos e ferramentas conceituais de gesto j nas fases iniciais do projeto podem apoiar na minimizao dos riscos e das incertezas referentes definio de escopo e de requisitos para desenvolvimento de projetos de software, com enfoque especial para projetos de aplicaes Web. Assim, a abordagem proposta visa aumentar a qualidade e a produtividade do desenvolvimento, bem como garantir a reduo de custos em projetos de aplicaes Web.

Universidade Federal de Santa Catarina Florianpolis SC - Brasil www.producaoonline.ufsc.br ISSN 1676 - 1901 / Vol. 8/ Num. 1/ maro de 2008

O trabalho tambm visa apresentar o resultado da anlise crtica da aplicao destas tcnicas e ferramentas em projetos de software, atravs da verificao dos benefcios alcanados e das dificuldades encontradas na sua utilizao. Este artigo est estruturado em seis sees. Na seo 2 apresenta-se a sntese do quadro terico utilizado para o desenvolvimento deste trabalho. Na seo 3 so apresentados os aspectos metodolgicos da pesquisa. As sees 4 e 5 apresentam uma aplicao do mtodo desenvolvido e a discusso dos resultados do caso analisado. Finalmente, na seo 6, apresentam-se as concluses deste trabalho.

2. CONCEITUAO

Para o desenvolvimento deste trabalho foram utilizados os seguintes fundamentos conceituais: Modelo do Processo de Negcio, Particionamento, Arquitetura de Sistema e Desdobramento da Funo Qualidade (QFD - Quality Function Deployment). Uma breve explicao de cada um destes fundamentos apresentada a seguir.

Modelo do Processo de Negcio

O modelo do processo de negcio permite estabelecer os fluxos dos processos e informaes de um processo de negcio, independente do grau de automao previsto. A formalizao destes modelos pode ser feita utilizando-se diversas notaes. As mais utilizadas atualmente so o SADT/IDEF0, que permite a descrio dos processos e subprocessos de negcio, destacando as entradas, sadas, ferramentas, mecanismo e regras de negcio (MARCA, 1988) e o UML Use Case, que permite a descrio detalhada das diversas situaes de uso do processo de negcio segundo as necessidades do usurio. Tais modelos formalizados podem ser validados com o cliente ou usurio, garantindo o entendimento e alinhamento do processo e das regras de negcio. O estabelecimento do escopo e dos requisitos do produto de software de acordo com este modelo permite o alinhamento da automao com os objetivos do negcio. Este o foco mais adequado para um sistema de software: ser uma ferramenta que apia um processo de negcio e nunca o contrrio, ou seja, o foco deve ser eficcia e no eficincia.

Universidade Federal de Santa Catarina Florianpolis SC - Brasil www.producaoonline.ufsc.br ISSN 1676 - 1901 / Vol. 8/ Num. 1/ maro de 2008

Portanto, destaca-se que o modelo de negcio uma entrada fundamental para o estabelecimento do escopo do projeto de software. No desenvolvimento de software, escopo pode ser definido como:

Capturar o contexto, os requisitos e restries mais importantes para assim, definir os critrios de aceite do produto final. (KRUCHTEN, 1998)

A utilizao de tcnicas de gerenciamento de projetos em organizaes focadas em Tecnologia da Informao (TI) tem se intensificado nos ltimos anos. No contexto organizacional, os modelos de maturidade tm se difundido entre eles destacam-se o Capability Maturity Model (CMM e CMMI) e o Organizational Project Management Maturity Model (OPM3) (CARVALHO et al, 2003). J no mbito do gerenciamento de projetos o uso de guias de referncia como o Project Management Body of Knowledge (PMBoK) e a certificao profissional Profissional Project Management (PMP), fornecido pelo Project Management Institute (PMI), tm crescido significativamente entre os profissionais da rea de TI (CARVALHO; RABECHINI Jr, 2005). Segundo o guia PMBOK (PMI, 2004), existem cinco processos relevantes para a conduo da gerncia do escopo do projeto, quais sejam: planejamento do escopo, definio do escopo, criao da estrutura analtica do projeto - EAP (work breakdown structure - WBS), verificao do escopo e controle de mudanas do escopo. Este trabalho enfatiza os trs processos iniciais da Gesto do Escopo, ou seja, o desdobramento dos principais subprodutos do projeto de software em partes menores e mais fceis de gerenciar. A abordagem do PMBOK (2004) sugere a utilizao de modelos de estrutura analtica do projeto (EAP) e decomposio como ferramentas para o detalhamento do escopo. No obstante, no contexto da engenharia de software, a tcnica de particionamento proposta por Pressman (2005) pode trazer uma contribuio relevante como ferramenta para o processo de detalhamento do projeto, aliada ao mtodo QFD para a decomposio sucessiva em partes mais gerenciveis para a equipe, mas garantindo o alinhamento com os objetivos do negcio.

Universidade Federal de Santa Catarina Florianpolis SC - Brasil www.producaoonline.ufsc.br ISSN 1676 - 1901 / Vol. 8/ Num. 1/ maro de 2008

Particionamento

Segundo Pressman (2005), o particionamento uma tcnica que permite dividir um projeto complexo em partes menores, garantindo um melhor gerenciamento e controle dos requisitos e escopo da partio (conceito do dividir para conquistar). Esta tcnica tambm permite que os prazos de entrega sejam reduzidos, em virtude de entregas parciais e desenvolvimentos simultneos. Assim, quando se trata de projetos para Internet, esta tcnica pode ser bem aplicada, garantindo entregas mais rpidas, mesmo que com escopo reduzido, porm controlado e negociado com o cliente. Verses posteriores do produto iro complementar as entregas parciais iniciais, permitindo o desenvolvimento incremental e evolutivo. O desafio na aplicao desta tcnica consiste em escolher as parties a serem entregues para o cliente e que lhes sejam teis. Neste sentido, esta tcnica utilizada em conjunto com o modelo de processo de negcio, ou seja, o particionamento orientado pelo processo de negcio, o que consiste em uma estratgia adequada para o cliente.

Arquitetura de Sistema

Quando o usurio estabelece os requisitos de um software, em geral, ele se preocupa com os requisitos e funcionalidades de negcio, pois so estes que atendem diretamente suas necessidades. No entanto, outros requisitos so de fundamental importncia para garantir a qualidade do produto de software como um todo, tais como infra-estrutura de hardware, software, comunicao e segurana. A arquitetura de um sistema pode ser caracterizada por um conjunto de vises, como apresentado na Figura 1 (ver ISO 9126/ NBR 13596, ABNT, 1997). Esta abordagem permite estabelecer todos os requisitos considerando os requisitos solicitados pelo cliente (geralmente os de negcio) e tambm os demais requisitos fundamentais para a qualidade do produto final. Assim, a abordagem da Arquitetura de Sistema permite garantir completeza dos requisitos de um sistema de software.

Universidade Federal de Santa Catarina Florianpolis SC - Brasil www.producaoonline.ufsc.br ISSN 1676 - 1901 / Vol. 8/ Num. 1/ maro de 2008

Viso Negcio
Negcio Operao

Abrangncia Funcionalidades, Interao HomemMquina, Modelos de Processo de Negcio. Processo que sustentam o sistema, monitorao e parametrizao de regras de negcio pelos gestores. Integridade, privacidade, confiabilidade e rastreabilidade. Ambientes, processos de desenvolvimento, testes, homologao, implantao, ferramentas e controle de qualidade. Hardware, software, Bases de Dados e comunicao.

Operao
ARQUITETURA

Segurana
Segurana Desenvolvimento

Desenvolvi mento
Infra-estrutura

Infraestrutura

Figura 1: Vises da Arquitetura de um Sistema. Fonte: ISO 9126 / NBR 13596 (ABNT, 1997).

Desdobramento da Funo Qualidade - QFD

O QFD (Quality Function Deployment) um mtodo que permite o desdobramento e priorizao dos requisitos do cliente nas caractersticas e processos de qualidade a serem implementados, garantindo alinhamento com as necessidades do cliente. O QFD orienta a organizao dos recursos disponveis, priorizando-os de acordo com a viso do cliente. O SQFD (Software Quality Function Deployment) representa a transferncia da utilizao do QFD em um ambiente industrial para o mundo do desenvolvimento de software (Spinola, 2000). As principais vantagens da utilizao do SQFD so: Aumento da produtividade no perodo de programao, por garantia de escopo bem definido; Menor necessidade de realizar modificaes futuras no software; Menor necessidade de manuteno, possibilitando que os recursos sejam destinados para o desenvolvimento de novos projetos. O Quadro 1 apresenta um resumo das ferramentas conceituais apresentadas nesta seo, bem como seus benefcios e pontos crticos.

Universidade Federal de Santa Catarina Florianpolis SC - Brasil www.producaoonline.ufsc.br ISSN 1676 - 1901 / Vol. 8/ Num. 1/ maro de 2008

Quadro 1: Resumo - Ferramentas, Benefcios e Pontos Crticos

Ferramenta Particionamento

Minimiza incertezas de ... - Prazo, escopo e custo (projetos menores so mais gerenciveis). - Expectativas (aderncia ao negcio); - Escopo e requisitos. - Escopo, expectativas e prioridades (alinhamento com as necessidades de negcio do cliente) -

Benefcio Entregas parciais e mais rpidas; Validaes intermedirias pelo usurio. Completeza de requisitos; Aderncia ao negcio. -

Ponto Crtico Integrao das partes (comunicao e arquitetura so fundamentais); - Expectativas devem ser bem gerenciadas. - Aderncia com as demais vises da arquitetura de sistema.

Arquitetura e Processo de Negcio QFD

- Direcionamento e otimizao dos - Complexidade de utilizao (quando esforos despendidos. a quantidade de requisitos for muito grande, trabalhar com particionamento).

3. ASPECTOS METODOLGICOS

O planejamento de um projeto de software deve englobar, basicamente, dois aspectos: o qu deve ser feito e como deve ser feito. Em relao ao o qu deve ser feito, deve ser realizado o entendimento e modelagem do processo de negcio para, a partir da, serem estabelecidos os requisitos de automao e o escopo do projeto. O como pode ser respondido pela definio das prioridades e estratgias que sero utilizadas na obteno do software. A abordagem proposta compreende os seguintes passos: Passo 1 - Modelagem de Negcio: A partir do levantamento junto ao cliente/ usurio, formalizar o processo de negcio em um modelo, por exemplo, utilizando a notao IDEF0, que descreve para cada processo, as entradas, sadas, ferramentas, mecanismos, regras e controles. Tal modelo deve ser validado com o cliente/ usurio e serve de referncia para estabelecimento dos itens a serem automatizados em um software. Passo 2 - Requisitos de Automao: Com base no modelo de processo de negcio, levantar junto ao cliente/ usurio os requisitos desejados para o software. Em geral, o cliente relaciona aspectos funcionais e de negcio, esquecendo-se de outros aspectos relevantes para o processo de desenvolvimento de software, denominados requisitos no-funcionais como por exemplo, modularidade, reutilizao, segurana e infra-estrutura. Assim, a lista de requisitos deve ser acrescida com estes outros requisitos, utilizando como estratgia as vises de arquitetura de um sistema.

Universidade Federal de Santa Catarina Florianpolis SC - Brasil www.producaoonline.ufsc.br ISSN 1676 - 1901 / Vol. 8/ Num. 1/ maro de 2008

Passo 3 - Particionamento e Priorizao: Como os tempos envolvidos no desenvolvimento de aplicaes Web so pequenos e muitas vezes preestabelecidos, importante realizar a priorizao dos requisitos solicitados pelo cliente, de forma a estabelecer o que ser disponibilizado na primeira verso e o que fica para as prximas verses. Esta estratgia exige um bom gerenciamento e negociao com o cliente. Assim, pode-se utilizar o particionamento com base no modelo de processo de negcio, visando disponibilizar para o cliente algo til e que possa entrar em operao. Parties de negcio englobam um conjunto de requisitos de negcio e podem ser desenvolvidas simultaneamente. As parties devem ser priorizadas pelo cliente. Passo 4 - Estabelecimento das Caractersticas do Software e Construo da Casa da Qualidade: Os requisitos do cliente devem ser traduzidos em caractersticas tcnicas que possam ser tratadas pelas equipes tcnicas de projeto. Alm disso, importante saber quais caractersticas da arquitetura do software devem ser reforadas durante o projeto. A utilizao do SQFD ajuda nesta definio. Considerando a matriz da Casa da Qualidade (Akao, 1990) (Carvalho, 1997), a coluna referente Voz do Consumidor (VOC) deve ser preenchida com os requisitos de negcio estabelecidos pelo cliente, ou pelas parties, nos casos de projetos com muitos requisitos. Na linha referente s caractersticas da qualidade (CQ) devem ser alocados os requisitos tcnicos de acordo com as vises de Arquitetura de Sistema. A correlao entre estes itens da Casa da Qualidade permite estabelecer os requisitos de negcio prioritrios do ponto de vista do cliente e como tais requisitos impactam e priorizam os aspectos tcnicos a serem tratados no desenvolvimento do projeto de software. Como existe uma srie de incertezas em relao a estes requisitos e prioridades; a aplicao das tcnicas e ferramentas apresentadas pode minimizar estas incertezas. A Figura 2 apresenta as etapas do processo de planejamento de um projeto e as possveis ferramentas conceituais a serem utilizadas.

Universidade Federal de Santa Catarina Florianpolis SC - Brasil www.producaoonline.ufsc.br ISSN 1676 - 1901 / Vol. 8/ Num. 1/ maro de 2008

Levantamento do Processo de Negcio

Ferramentas Modelo do Processo de Negcio (IDEF0) Vises da Arquitetura

O QU

Requisitos de Automao

COMO

Priorizao/ Estratgia de Obteno

Particionamento SQFD

Figura 2: Etapas do Processo de Planejamento e Ferramentas.

4. APLICAO DO MTODO: CASO DO BANCO ELETRNICO VIRTUAL

Para demonstrao da abordagem proposta, a seguir apresentado o estudo de um caso real aplicado a uma empresa do setor financeiro, onde o mtodo foi utilizado na definio dos requisitos de um projeto de desenvolvimento de um Banco Eletrnico Virtual. Apenas o passo 4 Casa da Qualidade no foi aplicado ao caso real, e ser objeto de trabalho futuro. A Casa da Qualidade construda e apresentada neste item possui carter ilustrativo, contribuindo para a anlise dos resultados do mtodo. A Figura 3 apresenta o modelo do processo de negcio, passo 1 do mtodo, para o Banco Eletrnico Virtual, descrito na notao IDEF0.

Universidade Federal de Santa Catarina Florianpolis SC - Brasil www.producaoonline.ufsc.br ISSN 1676 - 1901 / Vol. 8/ Num. 1/ maro de 2008

Informaes/ Parmetros

Contedo Administrao/ Gesto Cadastro do Cliente Operao/ Servios Servios (consultas, transferncias, etc.) Logs

Solicitao servio e identificao

Solicitao

Monitorao/ Estatsticas

Indicadores

Backroom

Cliente

Backroom

Figura 3: Modelo do Processo de Negcio do Banco Eletrnico Virtual Notao IDEF0. Este modelo foi construdo em conjunto com os departamentos de negcio e de tecnologia da empresa envolvida no caso em estudo, tomando por base os processos reais do mundo fsico e os processos levantados atravs de benchmarks realizados com outros bancos eletrnicos virtuais concorrentes. A Figura 3 apresenta apenas o primeiro nvel do diagrama, que foi detalhado em mais dois nveis, mas que no so apresentados neste artigo. O modelo apresentado, basicamente, compreende os processos de Administrao e Gesto do site envolvendo gesto de contedo e de informaes, cadastramento de clientes e tratamento de ocorrncias; Operao e Servios disponibilizados para os usurios finais, tais como transaes financeiras de saldo, extrato, transferncia de recursos e pagamento de contas e os processos de Monitorao e Estatsticas, atravs da disponibilizao de indicadores de negcio e infra-estrutura e da extrao de relatrios e estatsticas. Participam deste processo de negcio o cliente da instituio financeira (tambm denominado de usurio final) e o backroom (tambm denominado de backoffice ou equipe de retaguarda). Os requisitos levantados a partir das solicitaes dos representantes de negcio e de tecnologia da empresa foram agrupados de acordo com estes grandes processos. O Quadro 2 apresenta os requisitos levantados, compondo a Voz do Consumidor, considerando os pontos de vista do usurio final e do backroom. Tais requisitos foram complementados pela equipe de projeto, de acordo com as cinco vises de Arquitetura, conforme estabelecido no passo 2 - requisitos de automao.

Universidade Federal de Santa Catarina Florianpolis SC - Brasil www.producaoonline.ufsc.br ISSN 1676 - 1901 / Vol. 8/ Num. 1/ maro de 2008

Quadro 2: Requisitos de Automao Solicitaes dos Representantes de Negcio e Vises da Arquitetura.

Solicitaes dos Representantes de Negcio

Requisitos de acordo com as Vises de Arquitetura Administrao/ Gesto Viso Negcio - Gesto de contedo e informaes; - Funcionalidades de negcio (usurio final e - Cadastro de clientes; backroom); - Tratamento de ocorrncias; Viso Segurana Operao/ Servios - Controle de acesso; - Transaes financeiras de saldo, extrato, - Rastreabilidade; transferncia de recursos e pagamentos; - Integridade; Monitorao/ Estatsticas Viso Infra-estrutura - Indicadores de negcio e infra-estrutura; - Desempenho; - Relatrios e estatsticas (quantidade de - Hardware adequado; acessos, volumes, perfil do cliente); Viso de Desenvolvimento Facilidade de Uso; - Reuso; Rapidez de Acesso; - Facilidade de Manuteno; Tempo de entrega rpido. Viso Operao - Monitorao.

No Quadro 2, a coluna da esquerda representa a Voz do Consumidor e a coluna da direita as Caractersticas da Qualidade, o que permite a construo da Casa da Qualidade. No entanto, como o conjunto de requisitos estabelecidos pelos clientes pode ser muito grande, recomenda-se a utilizao do particionamento. Neste caso, o particionamento proposto de acordo com o modelo do processo de negcio o seguinte: partio 1: administrao/gesto; partio 2: operao/servios; e partio 3: monitorao/estatsticas. A Figura 4 apresenta o particionamento a partir do modelo do processo de negcio do Banco Eletrnico Virtual apresentado na Figura 3. A representao grfica do modelo apia a identificao das parties, utilizando a notao IDEF0.

Universidade Federal de Santa Catarina Florianpolis SC - Brasil www.producaoonline.ufsc.br ISSN 1676 - 1901 / Vol. 8/ Num. 1/ maro de 2008

Informaes/ Parmetros

Contedo Administrao/ Gesto Cadastro do Cliente Servios (consultas, transferncias, etc.) Logs

Solicitao servio e identificao

Operao/ Servios

solicitao

Monitorao/ Estatsticas

Indicadores

Partio 1

Partio 2
Backroom Cliente Backroom

Partio 3

Figura 4: Particionamento com base no modelo do processo de negcio. De acordo com as prioridades estabelecidas pelos representantes da empresa, a partio prioritria a 2, pois compreende as transaes financeiras. A primeira verso do software pode suportar as funcionalidades desta partio, sendo as demais funes executadas manualmente. No entanto, a arquitetura do software deve estar preparada para evoluir, considerando automao do processo completo. A estratgia de particionamento permite tambm o desenvolvimento simultneo, em que para cada partio sero realizadas as etapas de anlise, projeto, implementao e testes. Esta estratgia permite tambm agilizar a entrega do produto de software final. No caso em estudo, a primeira partio implantada foi a 2, seguida das parties 1 e 3 respectivamente. O fato das implantaes do banco eletrnico virtual serem realizadas de forma parcial e incremental minimizou as incertezas e ansiedades em relao s entregas do software. Finalmente, a Figura 5 apresenta a Casa da Qualidade, considerando as parties estabelecidas e as caractersticas da qualidade.

Universidade Federal de Santa Catarina Florianpolis SC - Brasil www.producaoonline.ufsc.br ISSN 1676 - 1901 / Vol. 8/ Num. 1/ maro de 2008

Grau de Importncia

CCQ 2 - Segurana

Peso Absoluto-WAi

Parties

VOC1 - P1: Administrao/ Gesto VOC2 - P2: Operao/ Servios VOC3 - P3: Monitorao/ Estatstica VOC4 - Facilidade de Uso VOC5 - Rapidez de Acesso VOC6 - Tempo de Entrega

3 5 3 3 4 4

27 45 27

27 45 27 3 36

5 5 27 5 5 5

5 5 5 5 5 5

1.0 1.0 1.0 1.0 1.0 1.0

1.0 1.0 1.0 1.0 1.0

3.0 5.0 3.0 3.0 4.0

Peso Relativo-WRi

CCQ5 - Operao

Pontos de Venda

Taxa de Melhoria

CCQ 1 - Negcio

Vises da Arquitetura

Valor Atual - Nosso Produto

CCQ 4 - Desenvolvimento

CCQ 3 - Infra-estrutura

Meta para o RC

Concorrente Y

Concorrente X

13.6 22.7 13.6 13.6 18.2 18.2 100.0

Peso Absoluto-WAj Peso Absoluto-WRj Valor Atual -Nosso Concorrente X Concorrente Y Meta

1759.1 35.25

5 TOTAL 1800 654.55 777.27 368.18 4990.9 36.07 13.11 15.57 7.38 100

36

1.0 4.0 TOTAL 22.0

Correlao Triangular Infra-estrutura Positiva Forte

Segurana

Figura 5: Casa da Qualidade. A partir da anlise da Casa da Qualidade possvel identificar os pontos de concentrao de esforos do projeto. No caso do exemplo, as vises de Negcio e Segurana so as de maior enfoque. Esta anlise importante pois, do ponto de vista do usurio, as funcionalidades de negcio so essenciais, mas o aspecto de segurana um ponto crucial a ser tratado na arquitetura desta aplicao Web, de forma a assegurar e garantir o prprio processo de negcio. Esta caracterstica nem sempre percebida pelo usurio ou cliente. Outra concluso extrada a partir da Casa da Qualidade que a correlao positiva entre a infra-estrutura e a segurana exige que, para implementar os requisitos de segurana estabelecidos, ser necessrio avaliar a evoluo da infra-estrutura de hardware, software e Base de Dados. Muitas vezes, este aspecto relegado, comprometendo todo o sistema. Esta evoluo da infra-estrutura garante tambm a escalabilidade do ponto de vista de negcio (plug and play), ou seja, permite a incluso ou alterao de servios de negcio sem gerar impactos para a infra-estrutura e nem para o usurio, como por exemplo, aumento dos tempos de resposta.

Universidade Federal de Santa Catarina Florianpolis SC - Brasil www.producaoonline.ufsc.br ISSN 1676 - 1901 / Vol. 8/ Num. 1/ maro de 2008

5. ANLISE DE RESULTADOS

Os passos 1, 2 e 3 do estudo de caso apresentado garantiram um alinhamento dos requisitos com as necessidades do solicitante, bem como a organizao e planejamento para o desenvolvimento simultneo das parties. Entre as dificuldades de uso desta abordagem destacam-se: Entendimento e levantamento do processo de negcio. Em algumas situaes, a empresa no se sente confortvel em expor o seu processo de negcio. Nestes casos, a tcnica de observao do processo pode ser utilizada para facilitar o levantamento; Estabelecimento e gerenciamento das prioridades das parties, considerando um pblico com interesses diferentes (gestor, usurio final, etc.); O passo 4 no foi aplicado em um caso real, mas pode-se vislumbrar que a sua aplicao permite o enfoque dos esforos nos requisitos mais importantes da Arquitetura. Como trabalhos futuros a serem realizados destacam-se: Aplicao do passo 4 da abordagem proposta no artigo (Estabelecimento das Caractersticas do Software e Construo da Casa da Qualidade) em projetos reais de desenvolvimento de aplicaes Web para a indstria financeira; Estudo e anlise da aplicao do AHP (Analytic Hierarchy Process) como instrumento para priorizao quantitativa dos requisitos do cliente.

6. CONSIDERAES FINAIS

A abordagem de gesto apresentada neste trabalho incorpora tcnicas e ferramentas que permitem minimizar as incertezas e riscos de um projeto de software, podendo ser utilizada nas fases iniciais do projeto. Entre as vantagens desta abordagem, destaca-se: reduo dos tempos de entrega, atravs de entregas parciais, desenvolvimento evolutivo e simultneo, alinhamento do sistema de software com o processo de negcio, esforos direcionados s necessidades dos clientes,

Universidade Federal de Santa Catarina Florianpolis SC - Brasil www.producaoonline.ufsc.br ISSN 1676 - 1901 / Vol. 8/ Num. 1/ maro de 2008

reduo dos custos decorrentes de retrabalho e garantia de maior completeza dos requisitos do projeto. Apesar da abordagem proposta ser utilizada e analisada para o caso de um projeto de aplicao Web, a mesma pode ser utilizada no planejamento de projetos de software de outras reas de aplicao. Assim os principais objetivos deste trabalho podem ser desdobrados em reduo de custos, aumento de qualidade e de produtividade no desenvolvimento dos projetos de software. A abordagem apresentada neste trabalho para minimizao de riscos e incertezas de projetos de software pode ser aplicada de maneira complementar estratgia de minimizao de riscos e incertezas com base em requisitos da Arquitetura de software (PINNA, 2004). Estas duas abordagens podem ser utilizadas de maneira complementar, uma mais focada nas fases iniciais do ciclo de vida de desenvolvimento e a segunda aplicada ao ciclo todo. No entanto, alguns pontos crticos podem ser destacados para utilizao destas ferramentas, como a dificuldade de aplicao do QFD quando a quantidade de requisitos for muito grande (matriz fica muito grande). Neste caso, sugere-se trabalhar com parties. Recomenda-se ainda: o gerenciamento e a negociao com o cliente em relao s entregas parciais devem ser feitos de forma transparente, a diversidade de interesses e de usurios em relao aos requisitos e suas prioridades deve ser tratada cuidadosamente, a viso do todo, da integrao e gerenciamento das expectativas, quando se trabalha com particionamento e a postura de gesto forte e constante durante todo o projeto.

REFERNCIAS AKAO, Y. Quality Function Deployment: Integrating Customer Requirements into Product Design. Portland: Productivity Press, 1990. ABNT Associao Brasileira de Normas Tcnicas - NBR 13596 (ISO 9126 ) Tecnologia de Informao: Avaliao de Produto de Software Caractersticas de Qualidade e Diretrizes para o seu Uso, 1997. BROWN, A. W. Large-Scale, Component-Based Development. Prentice Hall PTR, 2000.

Universidade Federal de Santa Catarina Florianpolis SC - Brasil www.producaoonline.ufsc.br ISSN 1676 - 1901 / Vol. 8/ Num. 1/ maro de 2008

CARVALHO, M. M; LAURINDO, F.J.B.; PESSA, M.S.P. Information Technology Project Management to achieve efficiency in Brazilian Companies. In: KAMEL, Sherif. (Org.). Managing Globally with Information Technology. Hershey, pp.260-271, 2003. CARVALHO, M.M.; RABECHINI JR.,R. Construindo Competncias para Gerenciar Projetos: teoria e casos. So Paulo: Editora Atlas, 2005. CARVALHO, M. M. QFD: uma ferramenta de tomada de deciso em projeto. 1997. Tese de Doutorado - Departamento de Engenharia de Produo e Sistema, Universidade Federal de Santa Catarina, Florianpolis, 1997. KRUCHTEN, P.; The Rational Unified Process: An Introduction, Reading, MA: AddisonWesley, 1998. IDEF0 - Integration Definition For Function Modeling Federal Information Processing Standards Publication (FIPS Std 183), Dezembro, 1993 URL

www.idef.com/Downloads/free_downloads.html. MARCA, D. A.; McGOWAN, C. L. IDEF0/SADT: Business Process and Enterprise Modeling. Califrnia: Eclectic Solutions, 1988. McCONNELL, S. Rapid Development: Taning wild software schedules. Washington: Microsoft Press, 1996. PINNA, C. C. A.: Um Roteiro centrado em Arquitetura para Minimizao de Riscos e Incertezas em Projetos de Software. 2004. Dissertao de Mestrado - Departamento de Engenharia Eltrica, Escola Politcnica da Universidade de So Paulo, So Paulo, 2004. PMI. PROJECT MANAGEMENT INSTITUTE. A Guide to the Project Management Body of Knowledge (PMBoK). 3rd edition. Project Management Institute Inc., 2004. PRESSMAN, R. S. Software Engineering A Practitioners Approach. 6 ed. New York: McGraw-Hill, 2005.

Universidade Federal de Santa Catarina Florianpolis SC - Brasil www.producaoonline.ufsc.br ISSN 1676 - 1901 / Vol. 8/ Num. 1/ maro de 2008

SPINOLA, M. M.; CARDOSO, L. A. Aplicao de QFD para a Especificao de um Sistema de Informaes. In: 2 Congresso Brasileiro de Gesto de Desenvolvimento de Produto, 2000, So Carlos, 2000.

Artigo recebido em 12/04/2007 e aceito para publicao em 01/03/2008