Вы находитесь на странице: 1из 10

.nv. x.i. )ux. l :oo, l .xo xv, x ,, l III-I:o ix1vcv.

1o 111
Arquitetura de sofware: uma abordagem para Gesto
de Riscos em projetos de TI
cvis1ix. coviuo nv .nvvu vixx.*
vvcix.ino .v.x.xi**
Resumo l Visando a lidar com as crescentes complexidades dos sistemas de informao e aumentar a
maturidade do processo de desenvolvimento de sofware por meio da minimizao dos riscos e incertezas,
a disciplina de Gesto de Riscos tem-se apresentado como tema crescente na indstria e na academia de
sofware e de Gesto da Tecnologia da Informao. Keil e colaboradores (1998) afrmam que grande parte
da taxa de falhas nos projetos de sofware devida a medidas inadequadas de avaliao e gerenciamento dos
riscos envolvidos nos projetos. Um gerenciamento de riscos adequado pode implicar melhoria do produto
e o aumento da produtividade do processo de desenvolvimento de sofware, ou seja, melhor qualidade e
menor custo. O objetivo deste trabalho apresentar uma especializao do processo de Gesto de Riscos
para projetos de sofware. Esta especializao consiste em uma estratgia preventiva da Gesto de Riscos
que permite transformar riscos e incertezas de projetos em requisitos de Arquitetura de sofware, garantindo
assim qualidade do produto e produtividade do processo. Como resultado, so discutidas as vantagens e os
pontos crticos para a aplicao da estratgia proposta em projetos do dia a dia das organizaes.
Palavras-chave l Gesto de Tecnologia da Informao. Gesto de Riscos. Arquitetura de sofware. Riscos
e incertezas. Engenharia de sofware
Title l Sofware architecture: an approach to Risk Management in IT projects
Abstract l In order to handle the growing complexities of sofware systems and increase the maturity of
the development process through the minimization of risks and uncertainties, the Risk Management has
been presented as an important subject in the sofware and TI Management industry and academy. An
adequate risk management can result in product quality improvement as well as increase the productivity
of the sofware development process. Tis paper presents a specialization of Risk Management process for
sofware projects. Tis specialization consists of a preventive strategy of Risk Management, which makes
possible turning risks and uncertainties of sofware projects into requirements of sofware Architecture,
therefore assuring the product quality and the process productivity. As a result, the advantages and critical
points for the application of the proposed strategy in regular projects are discussed.
Keywords l Management of Information Technology. Risk Management. Sofware architecture. Risks
and uncertainties. Sofware Engineering
Data de recebimento: 12/11/2008.
Data de aceitao: 26/11/2008.
* Mestre em Engenharia de Sofware pela EP-USP, trabalha no
Dep. de Engenharia de Computao e Sistemas Digitais da EP-USP.
E-mail: cristina.abreu@poli.usp.br.
** Professor doutor da EP-USP, trabalha no Dep. de Engenharia de
Computao e Sistemas Digitais da EP-USP.
E-mail: reginaldo.arakaki@poli.usp.br.
I. ix1vonu1o
Segundo Keil e colaboradores (1998), os projetos
de TI so particularmente difceis de gerenciar,
e muitos deles terminam em insucesso. Em 1995,
o gasto anual dos Estados Unidos da Amrica
em projetos de TI atingiu aproximadamente 250
bilhes de dlares, englobando aproximadamente
175.000 projetos. No mesmo ano, empresas ame-
ricanas sozinhas gastaram 59 bilhes de dlares em
excedentes em projetos de sistemas de informa-
o e 81 bilhes de dlares em projetos que foram
cancelados.
Uma pesquisa realizada pelo Standish Group
em 1995 apresentou um resultado segundo o qual
somente um sexto de todos os projetos foi realiza-
do dentro do prazo e do oramento previstos, um
tero de todos os projetos foi cancelado e mais da
metade foi considerada insatisfatria (Addison;
Vallabh, 2002).
Com base nessas informaes, pode-se per-
ceber uma alta taxa de falhas e custos nos proje-
tos de TI. Esta uma realidade no apenas de
112 ix1vcv.1o vixx. .v.x.xi l Arquitetura de sofware
organizaes norte-americanas, mas tambm de
organizaes brasileiras.
Keil e colaboradores (1998) afrmam que grande
parte dessa taxa de falhas nos projetos de sofware
devida a medidas inadequadas de avaliao e
gerenciamento dos riscos envolvidos nos projetos.
Defensores das tcnicas de Gesto de Riscos
argumentam que o tratamento adequado dessas
ameaas pode reduzir os incidentes de falhas em
projetos de sofware. No entanto, antes de desen-
volver-se estratgias de Gesto de Riscos, deve-se
identifcar e quantifcar os riscos, de acordo com
o grau de importncia. Isto necessrio, pois a
ateno gerencial deve focar-se nos pontos que
constituem as maiores ameaas.
Sabe-se que grande parte dos riscos e incerte-
zas que incidem em projetos de sofware comum
a vrios outros, considerando o contexto e/ou pro-
cesso de negcio conhecido (Boehm, 1989). Ento,
como minimizar estes riscos mais comuns em
projetos de sofware?
A Gesto de Riscos uma abordagem que
pretende garantir o sucesso do projeto por meio
de um conjunto de tcnicas e procedimentos para
a identifcao, anlise e controle dos riscos de
sofware. A incorporao da Gesto de Riscos como
instrumento no processo de desenvolvimento de
sofware permite a reduo da exposio ao risco,
possibilitando aumentar a qualidade do produto e
melhorar o processo de desenvolvimento (Roppo-
nen; Lyytinen, 2000, citados em Addison; Vallabh,
2002). Como aplicar ento de maneira efetiva as
tcnicas de Gesto de Riscos para minimizao
dos riscos e incertezas em projetos de sofware,
de forma que se garantam qualidade e produtivi-
dade? Atualmente poucas organizaes aplicam
as tcnicas de avaliao de riscos para a verifcao,
controle e gerenciamento destes. Para a maioria
dos projetos de TI, a avaliao de riscos condu-
zida de maneira informal, no frequente e no
sistemtica (Ropponen; Lyytinen, 1993; citados
em Addison; Vallabh, 2002).
Para Wallace e Keil (2004), isso se deve ao fato
de os gerentes de projeto terem disponveis pou-
cos procedimentos formais e sistematizados para
gui-los na identifcao dos fatores de risco e,
consequentemente, na anlise de seus efeitos.
De acordo com Cule e colaboradores (2000,
citados em Addison; Vallabh, 2002), alguns sin-
tomas de que as organizaes no esto aplicando
efetivamente o gerenciamento de risco incluem
os constantes incndios, replanejamentos, alte-
raes de cronograma, operaes em constante
stress, entre outros.
Diante destas difculdades, como a estratgia de
Gesto de Riscos pode ser aplicada a projetos no
dia a dia das organizaes de forma sistemtica e
prtica?
De maneira resumida, pode-se concluir que
uma parcela considervel das falhas em projetos
de software deve-se gesto inadequada dos
riscos do projeto.
Um melhor gerenciamento dos riscos pode
implicar melhoria da qualidade do produto e da
produtividade do processo.
O objetivo deste trabalho apresentar uma
estratgia de Gesto de Riscos especializada para
projetos de TI que possa ser utilizada no dia a dia
das organizaes e que permita melhorar a quali-
dade dos projetos de sofware.
:. .svvc1os xv1onoicicos
A metodologia desenvolvida para a elaborao
deste trabalho compreende as seguintes etapas:
Estudo de aspectos conceituais relacio- 1.
nados com riscos e incertezas, Gesto de
Riscos em projetos de TI e Arquitetura de
sofware;
Avaliao da problemtica de uma situa- 2.
o de desenvolvimento de projetos de TI,
por meio de estudo de caso;
Proposio de roteiro para Gesto de 3.
Riscos especfca para projetos de sofwa-
re, com base nos problemas discutidos no
estudo de caso;
Aplicaes do roteiro proposto a outros 4.
projetos e avaliao dos resultados.
Ao fnal do trabalho, so apresentadas as con-
cluses e recomendaes do estudo, bem como
discutidas as vantagens e pontos crticos do rotei-
ro proposto e suas necessidades de evoluo.
.nv. x.i. )ux. l :oo, l .xo xv, x ,, l III-I:o ix1vcv.1o 113
,. viscos v . cvs11o nv viscos vx
vvo)v1os
Podem-se caracterizar de maneira geral e indis-
tinta como risco ou incerteza todos os aspectos
que de alguma forma impactam o planejamento
de um projeto, considerando as dimenses prazo,
custo e qualidade (Pressman, 2002; PMBOK,
2004).
Para o Sofware Engineering Institute (SEI), o
risco corresponde possibilidade de sofrer uma
perda. Em um projeto de desenvolvimento de
sofware, a perda pode ser visualizada como os
impactos do projeto, descritos na forma de dimi-
nuio da qualidade do produto fnal, aumento
nos custos, atrasos e falhas.
O trabalho elaborado por Ziv e colaboradores
(1997) defne o Princpio da Incerteza na Enge-
nharia de Sofware. Segundo este princpio, as in-
certezas e riscos so inerentes e inevitveis no
processo de desenvolvimento de sofware e nos
produtos gerados. Isto signifca que tais ameaas
esto sempre presentes, e cabe ao gerente de
projeto e sua equipe identifcar e defnir o que
ser feito com cada uma delas.
Esse princpio bastante geral e abstrato sobre
a natureza do processo de desenvolvimento de
sofware e aplicvel ao longo do ciclo de vida.
Desta forma, no se pode conceber um projeto de
desenvolvimento de sofware que no seja suscep-
tvel ocorrncia nele de riscos e incertezas.
Alguns exemplos de incertezas e riscos do pro-
cesso de desenvolvimento de sofware incluem:
Dimensionamento do esforo, prazo e re-
cursos necessrios a um projeto;
Completeza dos requisitos de negcio e
tcnicos levantados e identifcados;
Envolvimento adequado dos usurios, clien-
tes e demais stakeholders na defnio dos
requisitos do projeto;
Mudanas de requisitos ao longo do tempo;
Viabilidade tcnica de utilizao de uma
nova tecnologia;
Disponibilidade de recursos na quantidade
e com o conhecimento e experincia ade-
quados;
Variaes em datas de eventos (lanamen-
tos e entregas);
Limitaes de resposta dos elementos de
hardware ou outros elementos fsicos,
entre outros.
O desenvolvimento de um sistema de TI pode
ser considerado um empreendimento complexo
e, como tal, est sujeito a incertezas, riscos e inde-
fnies. No entanto, este desenvolvimento deve
prosseguir mesmo na presena destas situaes.
Adicionalmente, as tendncias atuais das in-
dstrias de sofware, que impem restries de
prazos, custos e qualidade, cada vez mais auda-
ciosas, bem como o mercado altamente competi-
tivo, aumentam os riscos inerentes dos projetos
de sofware. Assim, devem ser utilizados mtodos
e tcnicas especfcas que permitam gerenciar os
riscos e incertezas de forma que o projeto se via-
bilize, aumentando suas chances de sucesso.
Diversos modelos de Gesto de Riscos podem
ser encontrados na literatura, como, por exemplo,
os propostos por Boehm (1989), pelo Project Ma-
nagement Institute (PMI) e pelo SEI. No entanto,
todos convergem para um modelo que pode ser
representado como uma ferramenta do processo
de desenvolvimento de sofware, conforme apre-
sentado na Figura 1, segundo a notao SADT/
IDEF0 (Marca; McGowan, 1988).
Nesse caso, os riscos e incertezas atuam como
limitaes do processo de desenvolvimento, res-
tringindo seu resultado, ou seja, o sistema fnal
com qualidade.
Os subprocessos que compem o processo de
Gesto de Riscos so:
Figura 1. Gesto de Riscos como ferramenta do Processo de
Desenvolvimento.
114 ix1vcv.1o vixx. .v.x.xi l Arquitetura de sofware
Identifcao de riscos e incertezas 1)
De acordo com o PMBOK (2004), neste sub-
processo so identifcados os riscos que podem
afetar o projeto, bem como so documentadas as
caractersticas destes riscos. Esta identifcao
no constitui um simples evento, devendo ocor-
rer continuamente ao longo do projeto.
Quantifcao e priorizao 2)
Cada risco identifcado deve ser analisado in-
dividualmente do ponto de vista da probabilidade
de ocorrncia e da gravidade dos impactos e efei-
tos do risco. Uma vez analisados, deve ser feito
um julgamento dos riscos mais importantes a se-
rem considerados no projeto; ou seja, os riscos
devem ser priorizados.
Respostas aos riscos e aes 3)
Este subprocesso considera cada um dos ris-
cos classifcados como importantes e priorizados
no subprocesso anterior e defne estratgias e
aes para gerenci-los e resolv-los.
Monitorao e controle 4)
Este subprocesso envolve a avaliao constante
de cada um dos riscos individualmente, a fm de
verifcar se aquele risco especfco est se tornando
mais ou menos provvel e quais os seus efeitos.
Esta monitorao e controle dos riscos pode
ser realizada por meio de inspees constantes ao
longo do ciclo de vida do projeto.
No entanto, apesar da importncia da Gesto
de Riscos discutida anteriormente, esta esbarra
em uma srie de restries e exigncias, a saber:
Forte disciplina e experincia por parte do
gerente do projeto e dos engenheiros de
sofware, que devem estar alertas e monito-
rando quaisquer indcios de fatores que
podem impactar negativamente os resulta-
dos do projeto;
Necessidade de identifcao do risco e da
incerteza, o que nem sempre ocorre pre-
ventivamente nos projetos de desenvolvi-
mento de sistemas de TI. Em geral, no
possvel identifcar antecipadamente diver-
sas situaes, como, por exemplo, alguma
mudana de membros da equipe ao longo
do desenvolvimento do projeto;
Aps sua identifcao, o risco deve ser
quantifcado e priorizado em termos de
probabilidade de ocorrncia e grau de im-
pacto, o que tambm nem sempre fcil de
se determinar e mensurar.
Segundo Sommerville (2003), a anlise de ris-
cos no uma atividade fcil, por depender do
julgamento e da experincia do gerente de projeto
e dos membros da equipe. De forma semelhante,
Boehm (1989) ressalta que a avaliao dos riscos
de projetos depende da habilidade dos engenhei-
ros de sofware em identifcar e gerenciar as fontes
de risco.
Assim, a efcincia da Gesto de Riscos est
associada disciplina dos gerentes e da equipe de
projeto, bem como introduz esforos e custos adi-
cionais decorrentes de aplicaes de tcnicas for-
mais para identifcao, mensurao e priorizao
dos riscos e incertezas.
A aplicao prtica da Gesto de Riscos nos
projetos de TI do dia a dia das organizaes exi-
giria, a princpio, alguma adequao ou especiali-
zao do processo.
vvquisi1os nv .vqui1v1uv. nv
software
Quando o usurio estabelece os requisitos de um
sofware, em geral, ele preocupa-se com os requi-
sitos 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 infraes-
trutura de hardware, sofware, comunicao e
segurana. Tais requisitos so muitas vezes deno-
minados requisitos no-funcionais.
Segundo You-Sheng e Yu-Yun (2003), com o
aumento da escala e do grau de complexidade dos
sistemas de sofware, o problema de desenvolvi-
mento de projetos de TI deixou de ser a disponi-
bilizao de funcionalidades para os usurios e
passou a estar relacionado com os requisitos no-
funcionais do sofware, tais como desempenho,
adaptabilidade, reso, entre outros que so mais
difceis de gerenciar.
.nv. x.i. )ux. l :oo, l .xo xv, x ,, l III-I:o ix1vcv.1o 115
Segundo Mendes (2002), os requisitos no-
funcionais abordam aspectos de qualidade impor-
tantes nos sistemas de sofware. Se tais requisitos
no forem levados em considerao, o sistema
resultar inconsistente e de baixa qualidade. Alm
disso, os usurios fcaro insatisfeitos, e o prazo e
oramento do projeto no sero cumpridos.
Para efeitos deste trabalho, a expresso requi-
sito de Arquitetura refere-se aos elementos que
direcionam a implementao da Arquitetura de
sofware, englobando tanto requisitos funcionais
como no-funcionais. A Figura 2 destaca os requi-
sitos de Arquitetura dentro do processo de desen-
volvimento de sofware.
Assim, de acordo com os dois modelos cita-
dos, para as empresas em estudo, a importncia
estratgica da Tecnologia de Informao grande
e essencial para o processo de negcio. Desta
forma, problemas relacionados com TI devem ser
tratados de forma crtica.
Os sistemas fornecidos eram desenvolvidos se-
gundo um padro de Arquitetura previamente de-
fnido entre as empresas. Aps aproximadamente
dois anos de fornecimento, foi realizada uma an-
lise crtica da situao de fornecimento, em que o
cenrio apresentado era:
Grande parte dos projetos no era entregue 1)
no prazo e com a qualidade esperada pela
empresa cliente;
Muitos projetos terminavam com o ora- 2)
mento superior ao oramento previsto ini-
cialmente;
Alguns sistemas no atendiam as reais ne- 3)
cessidades dos usurios;
Considervel descontentamento por parte 4)
da empresa cliente e tambm por parte dos
investidores e patrocinadores dos projetos.
Durante esse perodo de fornecimento reu-
nies frequentes foram feitas com o grupo de
gerentes e lderes desses projetos para avaliao
da situao. Analisando-se os histricos de apro-
ximadamente 50 projetos, todos apresentaram
as seguintes caractersticas:
Indefnio de regras de negcio, as quais
deveriam estar defnidas nas fases iniciais
do ciclo de vida, o que gerava atrasos nas
fases posteriores do projeto;
Mudanas constantes de requisitos de neg-
cio e tcnicos ao longo de todo o processo
de desenvolvimento, feitas pelos usurios e
empresa cliente, com uma mdia de 20
mudanas signifcativas por projeto. Tais
mudanas, quando no bem gerenciadas,
impactavam o prazo e o oramento do
projeto;
Dependncia de componentes e sistemas
externos, que tambm estavam em desenvol-
vimento por outras empresas fornecedoras
,, o c.so coxsinvv.no
O caso em estudo de uma empresa de desenvol-
vimento de sofware de porte mdio que fornece
sistemas Web para uma empresa cliente do setor
fnanceiro.
Para caracterizar melhor as empresas desse
caso, so utilizados dois modelos: Grid Estratgi-
co e Matriz de Intensidade da Informao.
De acordo com o Grid Estratgico proposto
por McFarlan (1984), que corresponde a um mo-
delo que permite analisar o impacto das aplicaes
de TI presentes e futuras no negcio da empresa,
ambas as empresas encontram-se no quadrante
Estratgico, uma vez que as aplicaes de TI afe-
tam diretamente o ramo de negcio em que elas
atuam. A Matriz de Intensidade da Informao,
proposta por Millar e Porter (1985), permite a an-
lise de quanto a informao est contida no proces-
so e no produto, considerando sua cadeia de valor.
Para o caso analisado, tanto o produto como o pro-
cesso possuem alta intensidade de informao.
Figura 2. Requisitos de Arquitetura e o processo de
desenvolvimento de sofware.
116 ix1vcv.1o vixx. .v.x.xi l Arquitetura de sofware
e que comprometiam os prazos de entrega
do sistema fnal;
Indefnio a respeito do formato de inte-
grao e comunicao entre o sistema em
desenvolvimento e os componentes e siste-
mas externos.
Os processos de desenvolvimento de sofware
estavam defnidos e bem consolidados pelas equi-
pes. No se poderia conceber que as mudanas de
requisitos e indefnies no iriam existir ou que
no seriam incorporadas ao projeto, pois elas
eram inerentes e inevitveis ao processo, impos-
tas pela empresa cliente. A gesto inadequada dos
riscos mencionados foi, ento, identifcada como
a maior defcincia do processo.
Para os projetos em anlise, seus principais
riscos eram identifcados no incio do desenvolvi-
mento, no entanto, estes no eram monitorados e
rastreados constantemente ao longo do ciclo de vida,
causando os resultados no favorveis descritos.
Desta forma, uma equipe foi destacada para
analisar e estudar a situao, visando a melhorar a
qualidade dos projetos e do produto fnal.
Analisando as principais difculdades apresen-
tadas no caso em estudo, estas esto relacionadas
com a defnio de processos de gesto e com sua
utilizao pelas equipes de desenvolvimento.
Considerando tambm as restries apresenta-
das na Seo 3 deste trabalho, referentes Gesto
de Riscos, uma nova abordagem do processo de
Gesto de Riscos deve ser proposta visando sua
aceitao e incorporao nos processos de desen-
volvimento e gesto da organizao.
Dessa forma, a abordagem de gesto proposta
deve tratar de aspectos de defnio de processos
de Gesto de Riscos e da implantao destes
processos na organizao, visando a reduo dos
problemas apresentados no caso em estudo. A
abordagem de gesto proposta detalhada no item
6 deste trabalho.
o. . .novn.cvx nv cvs11o nv vis-
cos vvovos1.
De acordo com o que foi discutido na seo
anterior, a defnio e a implantao de processos
de Gesto de Riscos adequados e especializados
para projetos de TI permitem minimizar os pro-
blemas apresentados no caso em estudo e as res-
tries apresentadas na Seo 3.
Dessa forma, a abordagem de Gesto de Riscos
proposta consiste em uma abordagem sistemtica
para minimizao dos riscos e incertezas mais
comuns em projetos de TI, por meio do mapea-
mento em requisitos de Arquitetura de sofware.
O roteiro proposto baseado na Gesto de
Riscos tradicional (descrita na Seo 3 deste traba-
lho), endereando mais diretamente as aes para
minimizao dos riscos e incertezas como requi-
sitos de Arquitetura de sofware. Esta abordagem
pretende ser mais preventiva, na medida em que
estabelece requisitos que servem como realimenta-
o e controle ao processo de desenvolvimento, de
forma que se garanta a qualidade do produto fnal.
A Figura 3 apresenta a aplicao do roteiro
centrado em Arquitetura ao processo de desen-
volvimento de sofware, como ferramenta adicio-
nal Gesto de Riscos tradicional.
Especializando o processo de Gesto de Riscos
tradicional, possvel ter os subprocessos da Ges-
to de Riscos centrada em Arquitetura, a saber
(vide Figura 4):
Categorizao de riscos e incertezas 1)
Dado um contexto, os riscos e incertezas que
ocorrem em um projeto de sofware so comuns a
vrios outros. Assim, possvel tratar categorias
dos principais riscos e incertezas, levando-se em
considerao o tipo de processo de negcio e os
padres de Arquitetura de sofware existentes na
empresa.
Figura 3. Gesto de Riscos centrada em Arquitetura.
.nv. x.i. )ux. l :oo, l .xo xv, x ,, l III-I:o ix1vcv.1o 117
Considerando o histrico de projetos de um
determinado processo de negcio, este subpro-
cesso poderia ser suprimido, devido experincia
das pessoas que atuam neste contexto. Outra in-
terpretao seria considerar que tais riscos e in-
certezas j foram previamente identifcados. Isto
signifca que, para tais situaes, assume-se que a
probabilidade de ocorrncia de determinados
riscos prxima a 100%, partindo-se direto para
o estabelecimento de aes.
Esse subprocesso corresponde aos subproces-
sos de Identifcao, Quantifcao e Priorizao
de riscos da Gesto de Riscos tradicional.
Defnio de requisitos da arquitetura 2)
Com base nas categorias de riscos e incertezas,
possvel defnir os requisitos de Arquitetura de
sofware a serem aplicados para a minimizao
destes riscos e incertezas. Exemplos de requisitos
de Arquitetura so: desacoplamento tcnico entre
as funes de negcio e as funes de infraestru-
tura de um sistema de TI, centralizao das fun-
es de comunicao com sistemas externos em
componentes modularizados, entre outros.
Monitorao e controle 3)
Da mesma forma que na Gesto de Riscos
descrita na Seo 3, os riscos e incertezas devem
ser monitorados e acompanhados. Neste caso,
parmetros adicionais a serem considerados na
monitorao so os requisitos de Arquitetura de
sofware estabelecidos, de forma que se verif-
quem a efcincia da minimizao dos riscos e a
possibilidade de surgimento de novos.
O roteiro centrado em Arquitetura apresenta a
caracterstica de, caso um certo risco no seja
identifcado nem quantifcado a tempo, defnir
uma postura natural para buscar e estabelecer
princpios e requisitos de Arquitetura de sofware,
com base em categorias de riscos mais frequentes
e pr-identifcados, de modo que se garanta a qua-
lidade do produto fnal.
A especializao da Gesto de Riscos centrada
em Arquitetura com base no processo de Gesto de
Riscos tradicional justifca-se em funo da comple-
xidade crescente dos projetos de TI e de sua estrat-
gia preventiva, que permite estabelecer aes, no
caso, requisitos de Arquitetura de sof-ware, que re-
duzem custos de erros e retrabalhos, aumentando a
qualidade e produtividade. A abordagem proposta
tambm se baseia no fato da existncia de categorias
de riscos comuns e reincidentes em projetos de TI.
,. vvsui1.nos
Aps a defnio do processo de Gesto de Riscos
centrada em Arquitetura descrito na seo ante-
rior, a abordagem proposta foi aplicada a novos
projetos dentro do mesmo contexto, ou seja, pro-
jetos desenvolvidos para a mesma empresa cliente
e considerando o mesmo padro de Arquitetura.
Alguns exemplos de requisitos de Arquitetura
que passaram a ser incorporados ao processo de
desenvolvimento visando a minimizar as princi-
pais categorias de riscos e incertezas citadas no
caso em estudo:
Arquitetura que suporte o uso de compo-
nentes de sofware que encapsulam a com-
plexidade, considerando as afnidades de
negcio, e que sejam fexveis e parametri-
zados. Segundo Conrow e Shishido (1997),
para a minimizao de riscos relacionados
com requisitos instveis e imaturos, um re-
quisito de Arquitetura a modularizao
do sofware visando a facilitar eventuais
mudanas;
Desacoplamento das funes de negcio
das funes de infraestrutura, visando a
minimizar os impactos de alteraes. De
acordo com DSouza e Wills (1999), a utili-
zao de componentes de sofware facilita a
manuteno e a evoluo dos sistemas;
Figura 4. sSubprocessos da gesto de riscos centrada em
arquitetura.
118 ix1vcv.1o vixx. .v.x.xi l Arquitetura de sofware
Arquitetura de negcio escalvel, permi-
tindo a incluso de novos requisitos e m-
dulos ao sistema de forma facilitada;
Projeto da Arquitetura de sofware que per-
mita o particionamento e desenvolvimento
incremental, de forma que novos requisitos
sejam planejados para incrementos poste-
riores (desde que possveis);
Componentes de sofware desacoplados,
confgurveis e parametrizados, visando a
minimizar os impactos de alteraes em
sistemas externos;
Centralizao das funcionalidades de comu-
nicao e interao com sistemas externos
em componentes desacoplados dos compo-
nentes e funes de negcio da aplicao;
Arquitetura de sofware preparada para a uti-
lizao de simuladores de sistemas externos
para a realizao de testes, de forma que seja
permitida a execuo dos testes do sistema
em desenvolvimento independentemente da
disponibilizao do sistema externo;
Logs tcnicos para possibilitar o rastrea-
mento de operaes e informaes prove-
nientes de sistemas externos, entre outros.
Com a incorporao desses requisitos de Arqui-
tetura aos projetos, os riscos puderam ser mini-
mizados, o que pde ser observado qualitativamente
por meio dos resultados que se mostraram mais
satisfatrios, a saber:
Os impactos em prazos e custos dos proje- 1.
tos foram minimizados: praticamente me-
tade dos projetos passou a fcar dentro do
prazo e do oramento planejado inicial-
mente. Para os demais projetos, foi possvel
o replanejamento de maneira antecipada e
controlada;
A qualidade dos sistemas fnais foi melho- 2.
rada, o que pode ser verifcado por meio
dos resultados dos testes e das validaes
feitas pelos clientes solicitantes, diminuin-
do os retrabalhos;
E, consequentemente, houve maior satis- 3.
fao do cliente e do patrocinador dos
projetos.
Como j mencionado, como as categorias 4.
de riscos incidentes nos diversos projetos
eram comuns, as equipes de projeto dimi-
nuram os esforos na identifcao, quanti-
fcao e rastreamento dos riscos, focando-se
mais diretamente na defnio e implemen-
tao dos requisitos de Arquitetura.
Um questionamento que surgiu na equipe foi
em relao ao custo adicional introduzido nos
projetos para a incorporao dos requisitos de
Arquitetura, visando fexibilidade e robustez. Tal
aspecto, para o caso em estudo, no foi mensura-
do quantitativamente, mas observou-se que os
prejuzos decorrentes de entregas em atraso, en-
tregas de baixa qualidade e que no satisfaziam as
necessidades dos clientes eram grandes do ponto
de vista de negcio, considerando a importncia
da TI para as empresas em anlise.
8. coxciusovs v vvcoxvxn.ovs
O presente trabalho apresentou uma abordagem,
dada uma incerteza ou risco identifcado no pro-
cesso de desenvolvimento, de como este pode ser
minimizado por meio de requisitos da Arquitetura
de sofware, de forma que se garanta a qualidade
do projeto de sistema de TI, considerando prazos,
custos e requisitos especifcados.
A abordagem proposta baseada e especiali-
zada com base na Gesto de Riscos tradicional,
descrita na Seo 3 deste trabalho. Nesta aborda-
gem, mesmo que uma incerteza ou risco no seja
identifcado e quantifcado antecipadamente, o
que uma situao bastante comum nos projetos
de sofware, estabelece-se a postura de pensar nos
diversos requisitos da Arquitetura, e no somente
nas funcionalidades de negcio que geralmente
constituem os requisitos explicitados pelos usu-
rios. Tais requisitos implcitos ou no-funcionais
so fundamentais para garantir a qualidade do
produto e do processo de sofware.
Os pontos positivos da abordagem de Arqui-
tetura discutidas neste trabalho se resumem a:
Estabelecer requisitos da Arquitetura de
sofware e, indiretamente, uma postura para
.nv. x.i. )ux. l :oo, l .xo xv, x ,, l III-I:o ix1vcv.1o 119
lidar com estas incertezas e riscos de proje-
tos de TI;
A abordagem pode ser aplicada nas fases
iniciais do ciclo de vida do sofware, o que
permite a reduo de custos decorrentes de
riscos e incertezas;
Os principais riscos e incertezas podem ser
categorizados por processos de negcio e/
ou base histrica e, para estas categorias,
podem ser pr-estabelecidos requisitos de
Arquitetura de sofware que minimizem os
seus efeitos. Isto permite o reso de Arqui-
tetura com base em perfs de risco conhe-
cidos;
Estabelecer uma gesto preventiva consi-
derando que, para categorias de riscos co-
muns ou genricos, as aes de minimizao
dos riscos so estabelecidas de forma obje-
tiva por meio de requisitos de Arquitetura.
Assim, a Gesto de Riscos centrada em
Arquitetura apresenta-se efciente em
contextos e processos de negcio cujas
categorias de risco so mais bem conheci-
das, considerando at mesmo a base hist-
rica de projetos;
Abordagem prtica a ser aplicada em pro-
jetos do dia a dia nas organizaes.
Entre os pontos crticos da implantao desta
abordagem destacam-se:
Vencer as barreiras culturais das equipes
de projeto em lidar com as incertezas e ris-
cos, levando-as a aceit-los como presentes
e inerentes ao processo. Para os projetistas,
o caminho mais natural possuir todas as
defnies, requisitos e certezas a respeito
de um sistema que dever ser desenvolvido;
Exige alta maturidade do processo e da
equipe de desenvolvimento;
Anlise de custo/benefcio: balano entre o
custo para obteno da Arquitetura e os
benefcios alcanados.
Uma questo a ser discutida tambm como a
abordagem proposta no trabalho pode ser aplica-
da em projetos de manuteno. Sem dvida, a
Gesto de Riscos com foco na Arquitetura facilita
futuras evolues e correes; no entanto, caso o
projeto consista na manuteno de um sistema
legado cuja Arquitetura de sofware no esteja
adequada, a abordagem proposta no poder ser
aplicada na ntegra, em funo de algumas restri-
es possivelmente impostas pela Arquitetura
legada.
Voltando s trs questes fundamentais do
trabalho apresentadas na Seo 1, a saber:
Como aplicar de maneira efetiva as tcni- 1)
cas de Gesto de Riscos para minimizao
dos riscos e incertezas em projetos de sof-
ware, de forma que se garantam qualidade
e produtividade?
Como minimizar os riscos mais comuns 2)
em projetos de sofware?
Como esta estratgia de Gesto de Riscos 3)
pode ser aplicada a projetos no dia a dia das
organizaes de forma sistemtica e prtica?
Conclui-se que a abordagem de Gesto de
Riscos centrada em Arquitetura a resposta a
elas, uma vez que:
Permite minimizar os riscos e incertezas 1)
mais comuns ou genricos dos projetos de
sofware;
Permite garantir qualidade do produto fnal 2)
e produtividade, uma vez que centrada
em requisitos de Arquitetura e reduz erros
decorrentes de retrabalhos j nas fases ini-
ciais do processo de desenvolvimento;
Consiste em uma estratgia preventiva es- 3)
pecializada feita com base na Gesto de
Riscos tradicional, que uma abordagem
consagrada;
A abordagem proposta pode ser utilizada 4)
de maneira sistemtica e prtica nos proje-
tos, uma vez que se utiliza de ferramentas e
conceitos simples, da mesma forma que foi
aplicada no caso em estudo apresentado.
Naturalmente, apesar de a abordagem proposta
ter apresentado resultados satisfatrios para uma
categoria de projetos em um contexto especfco,
120 ix1vcv.1o vixx. .v.x.xi l Arquitetura de sofware
com base apenas no caso apresentado no pos-
svel garantir generalizao. Assim, deve-se aplic-
la, para efeitos de estudo, a outros projetos em
contextos diversos visando a avaliao de sua ef-
ccia. Este estudo pode compor o escopo de tra-
balhos futuros.
Adicionalmente, outro aspecto importante a
ser ressaltado, e j observado neste trabalho, que
a abordagem proposta exige certa maturidade da
equipe de desenvolvimento, uma vez que esta
deve estar apta e capacitada nos aspectos de mo-
delagem de negcio e tcnica para incorporao
de requisitos de Arquitetura. Desta forma, uma
evoluo da abordagem proposta seria traduzir os
padres de riscos e incertezas em modelos de
Arquitetura (patterns) e, consequentemente, em
padres de componentes e mdulos de sofware
que implementam os requisitos de Arquitetura.
A Figura 5 apresenta uma viso da evoluo
do roteiro proposto.
BOEHM, B. W. Sofware Risk Management. Washington:
IEEE Computer Society Press, 1989.
CONROW, E. H.; SHISHIDO, P. S. Implementing Risk
Management on Sofware Intensive Projects. IEEE
Sofware, v. 14, n. 3, maio-junho de 1997, p. 83-9.
DSOUZA, D. F.; WILLS, A. C. Objects, Components and
Frameworks with UML: Te Catalysis Approach.
Massachusetts: Addison Wesley, 1999.
KEIL, M.; CULE, P. E.; LYYTINEN, K.; SCHMIDT, R. C. A
Framework for Identifying Sofware Project Risks.
Communications of the ACM, v. 41, n. 11, novembro de
1998.
MARCA, D. A.; McGOWAN, C. L. IDEF0/SADT: Business
Process and Enterprise Modeling. San Diego (Ca):
Eclectic Solutions, 1988.
McFARLAN, W. E. Information Technology Changes the
Way You Compete. Harvard Business Review, maio-
junho de 1984.
MENDES, A. Arquitetura de sofware: desenvolvimento
orientado para arquitetura. Rio de Janeiro: Campus,
2002.
MILLAR, V. E.; PORTER, M. E. How Information Gives
You Competitive Advantage. Harvard Business Review,
julho-agosto de 1985.
PMBOK Guide A Guide to the Project Management Body
of Knowledge. Newtown Square (Penn): PMI, 2004.
PRESSMAN, R. S. Engenharia de sofware. 5. ed. Trad. de
M. M. G. Traviesso. Rio de Janeiro: McGraw-Hill, 2002.
SEI Sofware Engineering Institute. Apresenta padres,
modelos, processos e conceitos da engenharia de sofware.
Pittsburgh (Penn). Disponvel em <http://www.sei.cmu.
edu>. Acesso em 14 de maio de 2004.
SOMMERVILLE, I. Engenharia de sofware. 6. ed. Trad. de
A. M. de A. Ribeiro. So Paulo: Addison Wesley, 2003.
WALLACE, L.; KEIL, M. Sofware Project Risks and their
Efect on Outcomes. Communications of the ACM, v. 47,
n. 4, abril de 2004, p. 68-73.
YOU-SHENG, Z.; YU-YUN, H. Architecture-Based
Sofware Process Model. ACM SIGSOFT Sofware
Engineering Notes, v. 28, n. 2, maro de 2003, Nova
York, p. 1-5.
ZIV, H.; RICHARDSON, D. J.; KLOSCH, R. Te
Uncertainty Principle in Sofware Engineering. In:
Annals of the 19
th
International Conference on Sofware
Engineering, Massachusetts, 1997.
Figura 5. Viso do Roteiro de Gesto de Riscos proposto neste
trabalho e Roteiro Estendido.
Esta evoluo, tambm escopo de estudo futu-
ro, permitiria sistematizar e automatizar ainda
mais a minimizao dos riscos e incertezas de
projetos de sofware, transformando-os em requi-
sitos tcnicos implementados em componentes e
mdulos de sofware.
Referncias bibliogrfcas
ADDISON, T.; VALLABH, S. Controlling Sofware Project
Risks an Empirical Study of Methods used by
Experienced Project Managers. In: Proceedings of the
2002 Annual Research Conference of the South African
Institute of Computer Scientists and Information
Technologist on Enablement through Technology,
setembro de 2002, frica do Sul, p. 128-40 [ACM
International Conference Proceeding Series].