Qualidade de software

Engenharia de Software

engenharia
Saiba seu significado e para que serve

magazine
de software
Edição Especial

Entenda os principais conceitos
sobre Testes e Inspeção de Software
Verificação, Validação & Teste
Ferramentas Open Source e melhores
práticas na gestão de defeitos
Requisitos Projeto
Conheça os principais conceitos envolvidos Entenda o conceito de Arquitetura de Software e
na Engenharia de Requisitos como trabalhar com os Estilos Arquiteturais

Especial Processos
Melhore seus processos através da Veja como integrar conceitos de Veja como integrar o Processo
análise de risco e conformidade Modelos Tradicionais e Ágeis Unificado ao desenvolvimento Web

Atendimento ao Leitor

engenharia

magazine
A DevMedia conta com um departamento exclusivo para o atendimento ao
leitor. Se você tiver algum problema no recebimento do seu exemplar ou

de software
precisar de algum esclarecimento sobre assinaturas, exemplares anteriores,
endereço de bancas de jornal, entre outros, entre em contato com:

Carmelita Mulin – Atendimento ao Leitor
www.devmedia.com.br/central/default.asp
(21) 2220-5375
Ano 1 - 1ª Edição 2007 - - Impresso no Brasil
Kaline Dolabella
Gerente de Marketing e Atendimento
kalined@terra.com.br
Corpo Editorial (21) 2220-5375

Colaboradores Publicidade
Rodrigo Oliveira Spínola Para informações sobre veiculação de anúncio na revista ou no site entre
rodrigo@sqlmagazine.com.br em contato com:

Marco Antônio Pereira Araújo Kaline Dolabella
Eduardo Oliveira Spínola publicidade@devmedia.com.br

Fale com o Editor!
É muito importante para a equipe saber o que você está achando da revista: que tipo de
Editor de Arte
Vinicius O. Andrade artigo você gostaria de ler, que artigo você mais gostou e qual artigo você menos gostou.
viniciusoandrade@gmail.com Fique a vontade para entrar em contato com os editores e dar a sua sugestão!
Se você estiver interessado em publicar um artigo na revista ou no site SQL Magazine,
Capa entre em contato com os editores, informando o título e mini-resumo do tema que você
Vinicius O. Andrade gostaria de publicar:
viniciusoandrade@gmail.com
Rodrigo Oliveira Spínola - Colaborador
Na Web editor@sqlmagazine.com.br
www.devmedia.com.br/esm

Apoio Parceiros:

ÍNDICE
ÍNDICE
04 - Alguns Fundamentos da Engenharia de Software
Wilson de Pádua Paula Filho
10 - Melhorando Processos Através da Análise de Risco e Conformidade
Rafael Espinha, João Sousa

22 - Agilidade ou Controle Operacional? Os dois!
Alexandre Bartie

28 - O processo unificado integrado ao desenvolvimento Web
Rodrigo S. Prudente de Aquino

38 - Arquitetura de Software
Antonio Mendes da Silva Filho

46 - Introdução à Engenharia de Requisitos
Ana Luiza Ávila e Rodrigo Oliveira Spínola

54 - Introdução a Teste de Software
Arilo Cláudio Dias Neto

60 - Gestão de defeitos
Cristiano Caetano
68 - Introdução à Inspeção de Software
Marcos Kalinowski e Rodrigo Oliveira Spínola

Alguns Fundamentos da Engenharia de
Software

O que é Engenharia de Software? duzem grande quantidade de software, ou
É a mesma coisa que Ciência da Com- até naquelas em que o desenvolvimento
putação? Ou é uma entre muitas espe- de software é atividade fim. Programas
cialidades da Ciência da Computação? e exames de certificação em Engenharia
Ou dos Sistemas de Informação, ou do de Software são pouco conhecidos, ao
Processamento de Dados, ou da Informá- contrário do que acontece com algumas
tica, ou da Tecnologia da Informação? Ou linguagens e tecnologias usados por esses
é uma especialidade diferente de todas profissionais.
as anteriores? Em outros países, a situação é um pouco
Na maioria das instituições brasileiras diferente. Algumas universidades ameri-
de ensino superior, o conjunto de co- canas oferecem programas de graduação,
nhecimentos e técnicas conhecido como mestrado e doutorado na área. O IEEE
Engenharia de Software é ensinado em (Institute of Electrical and Electronics Engi-
uma ou duas disciplinas dos cursos que neers), principal organização internacional
têm os nomes de Ciência da Computação, de profissionais de Engenharia Elétrica,
Wilson de Pádua Paula Filho Informática ou Sistemas de Informação. através da Computer Society, que forma o
(wppf@ieee.org) Raramente, em mais disciplinas, muitas seu ramo em Computação, oferece a qua-
Engenheiro Mecânico pelo ITA, Doutor em
vezes opcionais, e muitas vezes oferecidas lificação de Profissional Certificado para
Engenharia Elétrica pela Escola Politécnica da
USP, Professor Titular aposentado do Departa- apenas em nível de pós-graduação. Algu- o Desenvolvimento de Software.
mento de Ciência da Computação da UFMG. mas instituições oferecem cursos de pós-
Autor dos Livros “Engenharia de Software: graduação em Engenharia de Software, Ciência, Engenharia e Valor
Fundamentos, Métodos e Padrões” e “Multi- geralmente no nível de especialização. Sem pretender fazer distinções defini-
mídia: Conceitos e Aplicações” Atualmente é
.
O uso do termo para designar uma tivas, vamos explorar o que dizem os di-
consultor em Engenharia de Software e traba-
lha no Synergia – Laboratório de Engenharia carreira profissional também não é muito cionários. O Dicionário Aurélio Eletrônico
de Software e Sistemas da UFMG. comum, mesmo em organizações que pro- V.2.0 assim define Ciência e Engenharia:

4 Engenharia de Software Magazine – Alguns Fundamentos da Engenharia de Software

engenharia

Ciência - Conjunto organizado de conheci- tes das Belas Artes, e valorizam critérios tosos, e, em certos casos, até riscos à vida
mentos relativos a um determinado objeto, es- estéticos na criação de seus programas. humana; muitas vezes empreendimentos
pecialmente os obtidos mediante a observação, a Isso pode ter conseqüências boas e ruins, de software são afetados por um contexto
experiência dos fatos e um método próprio. do ponto de vista de gerar valor. Por um econômico, político ou social.
Engenharia - Arte de aplicar conhecimen- lado, a busca da elegância pode levar
tos científicos e empíricos e certas habilitações à economia e simplicidade de formas, Produtos e Ciclos de Vida
específicas à criação de estruturas, dispositi- fazendo com que resultados de melhor A íntima relação entre a Engenharia de
vos e processos que se utilizam para converter qualidade sejam obtidos de maneira mais Software e a noção de valor significa que
recursos naturais em formas adequadas ao produtiva. E, principalmente, levando essa profissão trata o software como pro-
atendimento das necessidades humanas. a escrever programas que possam ser duto. Estão fora do escopo da Engenharia
mais facilmente reutilizados, mantidos e de Software programas que são feitos
Vê-se que, pelas definições acima, a expandidos. Por outro lado, a auto-satisfa- com objetivo exclusivamente lúdico: a
Ciência focaliza acumulação do conheci- ção do programador pode ter como preço diversão do programador. Estão fora de
mento através do método científico, com
base em experimentos e observações. Já
a Engenharia aplica esses conhecimen-
tos “ao atendimento das necessidades A íntima relação entre a Engenharia de Software e a noção
humanas”. Embora o conhecimento seja
certamente uma necessidade humana, de valor significa que essa profissão trata o software como
trata-se de uma entre várias outras,
sejam necessidades materiais, como produto.
alimentação, moradia, segurança, ou
imateriais, como afeição ou auto-estima.
A tudo aquilo que satisfaz a necessidades,
atribui-se um valor. A Engenharia está, os interesses de quem está pagando pelo seu escopo também pequenos programas
portanto, ligada à noção de valor, e a En- trabalho dele, ou de quem o usará. Seja, descartáveis, feitos por alguém apenas
genharia de Software busca gerar valor por exemplo, produzindo programas que para resolver um problema dessa pessoa,
com o processamento de informação. A ninguém entende, senão o próprio autor e que não serão utilizados por outros.
noção de valor tem muitas conseqüên- (e, depois de certo tempo, nem ele mesmo). Mas, se um desses programas interessar
cias práticas importantes, e, de fato, a Seja, como outro exemplo, introduzindo a outras pessoas, e assim passar a ter va-
teoria conhecida como “Engenharia de funções que o autor achou interessantes, lor, aparecerão demandas para melhorar
Software Baseada em Valor” representa mas não são realmente necessárias, nem suas qualidades, aumentar suas funções,
uma importante escola de pensamento foram solicitadas. prolongar sua vida. E aparecerá quem
dentro da área. E muito próxima de “Arte” está a esteja disposto a investir nisso, com a
palavra “Artesanato”, que lembra pro- expectativa de ganhar dinheiro. Nesse
Arte, Técnica, Artesanato, Indústria? dução caseira, em pequena escala, sem momento, o programa entrou no escopo
Outros termos constantes da definição a utilização de métodos industriais, que da Engenharia de Software e se tornou um
de Engenharia podem ser explorados são caracterizados pela padronização e produto. Muitos dos produtos de software
de várias formas, com conseqüências pela repetição. E, realmente, parece mais mais usados seguiram esse caminho.
interessantes. Por exemplo, é usada a difícil aplicar esses métodos industriais Todo produto tem usuários: aqueles que
palavra “Arte”, que o mesmo dicionário na confecção de software, do que nos efetivamente usam o produto. Alguns
define como a “capacidade que tem o ramos da engenharia do mundo material. produtos são feitos por encomenda de um
homem de pôr em prática uma idéia, Nestes, as leis físicas impõem limites cliente: aquele que pagará por sua produ-
valendo-se da faculdade de dominar a claramente visíveis ao que pode ser feito. ção. Outros, chamados de produtos de
matéria”, ou “a utilização de tal capa- Na Engenharia de Software, a criativida- prateleira, são vendidos no mercado aber-
cidade, com vistas a um resultado que de não é limitada por leis físicas, e sim to, a quem se interessar. Neste caso, quem
pode ser obtido por meios diferentes”. pela capacidade humana de entender e faz o papel do cliente é quem define que
Na Engenharia de Software, a matéria dominar a complexidade. recursos e funções se esperam do produto;
dominada pelas faculdades humanas Mas não se pode escapar do fato de que a talvez um departamento de vendas, ou de
consiste em máquinas de processamento Engenharia de Software tem que resolver marketing, ou de definição de produtos de
da informação, devidamente configura- muitos problemas de ordem industrial. uma organização, ou até, para produtos
das e programadas. Nesse sentido, os Raramente é possível construir software menores, os próprios desenvolvedores, co-
conceitos de “Arte” e “Técnica” são bem profissional sem envolver equipes, às ve- locando o chapéu de investidores de risco.
próximos; aliás, a palavra grega techné zes de dezenas ou até centenas de pessoas; E existem todos os casos intermediários,
significa, exatamente, Arte. raramente é possível trabalhar na área em que um produto parcialmente pronto
O termo “Arte” abre outras discussões. sem a pressão de prazos e orçamentos é completado, adaptado ou incrementado,
Não poucos programadores se conside- apertados; freqüentemente defeitos de por encomenda de um cliente.
ram como artistas, no sentido de pratican- software podem acarretar prejuízos vul- Como todo produto industrial, o produ-

Edição 01 – Engenharia de Software Magazine 5

to de software tem seu ciclo de vida: notação é usada para descrever muitos mostram detalhes; cada seta representa
• ele é concebido para tentar atender a aspectos diferentes do desenvolvimento uma transição entre atividades; as barras
uma necessidade; de software, inclusive as seqüências de paralelas representam início e término
• é especificado, quando essas necessida- atividades que compõem esse desenvol- de atividades executadas em paralelo;
des são traduzidas em requisitos viáveis; vimento. O tipo específico de diagrama um retângulo de cantos arredondados
• é desenvolvido, transformando-se que é mostrado na figura é o Diagrama de com detalhes internos representa uma
em um conjunto formado por código e Atividades, que representa uma evolução atividade estruturada, que é composta
outros itens, como modelos, documentos dos tradicionais fluxogramas, usados pe- de outras atividades.
e dados; los programadores há décadas.
• passa por algum procedimento de É interessante observar que a codifica- Projetos, Atividades e Estruturas
aceitação e é entregue a um cliente; ção, que representa a escrita final de um Analíticas
• entra em operação, é usado, e sofre programa em forma inteligível para um Normalmente, o software é desenvolvi-
atividades de manutenção, quando ne- computador, é apenas uma pequena parte do dentro de projetos. Todo projeto tem
cessário; do ciclo de vida. Muitas pessoas, inclu- uma data de início, uma data de fim, uma
• é retirado de operação ao final de sua sive alguns profissionais da informática, equipe e outros recursos. O responsável
vida útil. acham que a codificação é a única tarefa por um projeto é chamado de gerente de
de um engenheiro de software. projeto. O trabalho realizado dentro de um
O ciclo de vida compreende muitas ativi- Nos Diagramas de Atividades da UML, projeto pode ser descrito por um conjunto
dades, que são assunto das diferentes áre- a bolinha cheia representa Início; a boli- de atividades, que podem possuir relações
as da Engenharia de Software. A Figura 1 nha com um anel adicional representa de dependência, paralelismo, e decom-
mostra um modelo do ciclo de vida do sof- fim; cada retângulo simples de cantos posição em atividades mais elementares,
tware, usando a notação conhecida como arredondados representa uma ação, ou como no diagrama da Figura 1.
UML (Unified Modeling Language). Essa seja, uma atividade simples, da qual não As atividades são delimitadas por mar-
cos, isto é, pontos que representam esta-
dos significativos do projeto. Geralmente,
os marcos são associados a resultados
concretos: documentos, modelos ou por-
ções do produto, que podem fazer parte
do conjunto prometido aos clientes, ou
ter apenas utilização interna ao projeto. O
próprio produto é um resultado concreto
associado ao marco de conclusão do pro-
jeto, que pode ser utilizado sozinho, ou
como componente de um sistema.
O PMI (Project Management Institute)
é uma organização internacional, com
seções em muitos países, inclusive o
Brasil, que tem o objetivo de promover e
difundir boas práticas de gestão de pro-
jetos. Para isso, administra programas de
certificação de profissionais nessa área, e
publica o guia conhecido PMBOK (Project
Management Body of Knowledge).
Nesse guia, define-se um projeto como
um empreendimento temporário reali-
zado para criar um produto, serviço ou
resultado distinto. Um produto, por sua
vez, é definido como um objeto produzi-
do, quantificável e que pode ser um item
final ou um item componente. Uma ativi-
dade é definida como um componente de
trabalho realizado durante o andamento
de um projeto.
Os relacionamentos entre as atividades
que compõem um projeto são mostrados
em uma estrutura analítica, que o PM-
BOK define como uma decomposição hie-
Figura 1. Modelo UML do ciclo de vida do software rárquica orientada à entrega do trabalho


engenharia

a ser executado pela equipe do projeto, na Engenharia de Software é o CMMI Projeto - Conjunto gerido de recursos
para atingir os objetivos do projeto e (Capability Maturity Model Integration), que inter-relacionados, que entrega um ou mais
criar as entregas necessárias. Estruturas foi formulado pelo Software Engineering produtos a um cliente ou usuário, com início
analíticas de projeto podem ser apresen- Institute da Carnegie-Mellon University. O definido e que, tipicamente, opera conforme
tadas de muitas maneiras. Diagramas de CMMI foi encomendado e patrocinado um plano.
atividade são uma das representações pelo Departamento de Defesa ameri- Estrutura analítica do projeto - Um ar-
mais usadas atualmente. Outro tipo cano, popularmente conhecido como ranjo dos elementos do trabalho e dos relaciona-
de representação usual é fornecida por Pentágono, que o utiliza para avaliação mentos deles entre si e com o produto final.
planilhas e cronogramas, como aqueles da capacidade de seus fornecedores de
que são produzidos pela ferramenta Mi- software. Sendo o Pentágono provavel- Ao contrário do PMBOK, o CMMI não
crosoft Project (Figura 2). mente a maior organização compradora se limita aos conhecimentos sobre gestão
de software do mundo, o CMMI tem de projetos. Cobre também áreas técni-
Modelos de Referência e Fatores de grande aceitação da indústria americana cas, e focaliza principalmente a aplicação
Produção de software, e considerável influência no dos processos ao desenvolvimento de
O PMBOK é um exemplo de modelo de resto do mundo. A rigor, suas práticas não produtos. Um processo, segundo o IEEE,
referência: uma estrutura de conheci- são restritas à indústria de software, po- é uma seqüência de passos executados
mento que organiza conceitos, práticas dendo ser aplicadas ao desenvolvimento com um determinado objetivo; segundo
e padrões de uma área. No caso do de outros tipos de produtos. o PMBOK, é um conjunto de ações e
PMBOK, a área focalizada é a gestão de Os conceitos do CMMI têm raízes em atividades inter-relacionadas, realizadas
projetos de qualquer natureza, cobrindo comum com o PMBOK, como se pode para obter um conjunto especificado de
assuntos como integração, escopo, tempo, observar pela similaridade das definições produtos, resultados ou serviços.
custos, qualidade, recursos humanos, que adota: Um projeto representa a execução de
comunicações, riscos e aquisições. Produto - Resultado que se pretende entre- um processo, e um processo é uma receita
Outro modelo de referência importante gar a um cliente ou usuário. que é seguida durante a realização um

Figura 2. Cronograma de um projeto.


projeto; em outras palavras, o projeto é menos produtivas, durante algum tempo. esperado. E a principal contribuição de
o empreendimento que concretiza uma Algumas tecnologias mais complexas só modelos de referência como o CMMI é
abstração, que é o processo. Não se deve se pagam depois de muitos projetos. indicar o caminho das pedras e o mapa da
confundir um processo (digamos, uma Investir na capacitação das pessoas é mina: onde a experiência coletada indica
receita de bolo) com o respectivo produto certamente necessário. Entretanto, for- que o investimento em melhorias é mais
(o bolo) ou com a execução do processo mar pessoas é difícil, caro e demorado. rentável, em cada passo da evolução das
através de um projeto (a confecção de Recrutar pessoas capacitadas também: organizações.
um bolo por determinada pessoa, em não há sinais de que a oferta de pessoas
determinado dia). com alta qualificação no desenvolvi-
Processos, pessoas e tecnologia consti- mento de software venha a se igualar Conclusão
tuem os fatores de produção, que deter- à demanda, em futuro próximo. Além A Engenharia de Software visa à criação
minam o grau de sucesso dos projetos, disso, muitas pessoas produzem menos de produtos de software que atendam as
ou seja: se eles conseguem entregar um que a sua capacidade permitiria, por necessidades de pessoas e instituições e,
produto de qualidade suficiente, dentro falta de liderança, por deficiência de fer- portanto, tenham valor econômico. Para
de um prazo aceitável e com custos viá- ramentas e suporte, ou por inadequação isso, usa conhecimentos científicos, téc-
veis. Portanto, desses fatores dependem de processos. nicos e gerenciais, tanto teóricos quanto
a rentabilidade e a sobrevivência das Dos investimentos nos fatores de pro- empíricos. Ela atinge seus objetivos de
organizações produtoras. dução, os investimentos nos processos produzir software com alta qualidade
Para muitos profissionais, a tecnologia é são geralmente aqueles que podem trazer e produtividade quanto é praticada por
o fator mais atraente; muitas vezes, há um retorno em prazo mais curto. Processos profissionais treinados e bem informa-
otimismo exagerado quanto aos resulta- também não fazem milagres, mas a dos, utilizando tecnologias adequadas,
dos da aplicação de novas tecnologias. melhoria dos processos costuma trazer dentro de processos que tirem proveito
Entretanto, tecnologias aparentemente benefícios em prazos relativamente cur- tanto da criatividade quando da raciona-
promissoras podem levar para um beco tos, como é ilustrado por inúmeros relatos lização do trabalho.
sem saída, e, às vezes, tecnologias con- de experiência publicados. No mínimo,
sideradas inferiores pelos especialistas contribuem para reduzir o desperdício
lançam raízes permanentes, graças a for- e o retrabalho, o que geralmente já traz
ças de mercado. Além disso, a tecnologia ganhos muito significativos. Links
só se paga quando colocada nas mãos de A melhoria dos três fatores (tecnolo-
SEI
pessoas capacitadas, trabalhando dentro gias, pessoas e processos) também requer http://www.sei.cmu.edu/
de processos adequados. Toda introdução seu próprio processo: ela deve ser feita CMMI
de nova tecnologia tem uma curva de em etapas bem-definidas e controladas, http://www.sei.cmu.edu/cmmi/
aprendizado: as pessoas precisam ser para que as organizações, em prazos PMI Brasil
treinadas, cometem inicialmente muitos relativamente curtos, possam avaliar se http://www.pmi.org.br/

erros e, por isso, podem até se tornarem seu investimento está tendo o retorno


Desde 2004 Trazendo Teoria para a Prática

Treinamento e Consultoria
em Engenharia de Software

Profissionais com ampla experiência prática (Consusltores Certificados) e
acadêmica (Professores Universitários, Mestres e Doutores)

Know-how para implementar processos de software de acordo com modelos
de qualidade (MPS e CMMI) e maximizar o retorno de investimento

Certificados emitidos pela Kali Software
Cursos 2008: Inscrições Abertas Aulas aos sábados na Zona Sul do Rio, próximo ao metrô
Para outras localidades, por favor entre em contato

Março | Abril Processos de Software com ênfase em CMMI e MPS – 32 horas
Teste de Software – 16 horas

Maio | Junho Engenharia de Requisitos – 32 horas
Gerência de Configuração de Software – 16 horas

Julho | Agosto Gerência de Projetos de Software – 32 horas
Projeto Orientado a Objetos com UML e Padrões – 32 horas

Confira as ementas, investementos e condições de pagamento: www.kalisoftware.com
Oferecemos também cursos de programação (Java, Java para Web e Ajax)
Inscrição e outras informações: info@kalisoftware.com

kalisoftware.com | info@kalisoftware.com

Melhorando Processos Através da Análise de
Risco e Conformidade

U
m dos fatores importantes para ISO/IEC 15504 e 12207 definem um con-
a construção de um software junto de boas práticas e características
de qualidade é o processo de que devem estar presentes em um pro-
desenvolvimento utilizado e como este é cesso para que este possa ser gerenciado
implantado na organização. A inexistên- e resulte na entrega de produtos de qua-
cia ou a não utilização de processos bem lidade. Entretanto, como têm o objetivo
definidos e de boas práticas de desen- de serem aplicáveis a quase todo tipo de
volvimento, mesmo que informais, faz organização, estes modelos ou normas
Rafael Espinha com que o desenvolvimento de software muitas vezes não definem como estas
rafael.espinha@primeup.com.br seja realizado de forma ad-hoc, ficando boas práticas e características devem ser
É Engenheiro de Computação e Mestre em altamente dependente da experiência e implementadas e implantadas. Uma das
Engenharia de Software pela PUC-Rio. Foi
do conhecimento das pessoas envolvidas. maiores dificuldades de organizações
pesquisador do Laboratório de Engenharia a
de Software da PUC-Rio e atualmente é con- Este cenário resulta na realização de pro- que iniciam um programa de melhoria
sultor e diretor da PrimeUp, onde desenvolve jetos cujos resultados são imprevisíveis, de processos enfrentam é a dificuldade
projetos na área de melhoria de processos e onde cada um realiza as suas atividades de adaptar este conjunto de boas práticas
qualidade de software. Possui cursos e certifi- da forma que lhe convém, e dificulta a para a sua realidade, identificando quais
cações em CMMI e MPS.BR.
reutilização de boas práticas e de lições áreas são mais relevantes e devem ser
aprendidas. abordadas com maior urgência. Cada or-
João Sousa
joaomss@primeup.com.br Com a crescente demanda por qualida- ganização possui políticas, crenças e uma
É Bacharel em Informática pela UERJ e pós- de dos produtos de software, a adoção cultura específica, que deve ser levada em
graduado pela UFRJ. Possui mais de 15 anos de modelos de maturidade, normas de conta para que as melhorias sejam bem
de experiência no desenvolvimento de sis- qualidade e guias de boas práticas na aceitas e realmente contribuam com um
temas e melhoria de processos. Atualmente
definição de processos tem se tornado desenvolvimento mais eficiente.
é consultor da PrimeUp, onde desenvolve
projetos na área de melhoria de processos e cada vez mais freqüente. Modelos como Para orientar a necessidade de adapta-
qualidade de software. CMMI-DEV e MPS.BR e normas como a ção apresentada acima, utilizamos o con-

10 Engenharia de Software Magazine – Melhorando Processos Através da Análise de Risco e Conformidade

proc ess o

ceito de risco associado à não utilização tunidades de melhoria. Em geral, nesta A próxima seção apresenta alguns
das boas práticas de desenvolvimento fase é realizado um estudo no qual um conceitos básicos sobre riscos e como
de software nos projetos e processos da cenário esperado é definido e o cenário este conceito é utilizado neste domínio.
organização. Consideramos também que atual é avaliado segundo algum critério Em seguida a estratégia e a ferramenta
a qualidade do produto (software) está de qualidade (“Gap Analysis”). O cenário que compõem a abordagem serão apre-
diretamente relacionada à qualidade dos esperado pode ser definido a partir de um sentadas e um exemplo da sua utilização
processos utilizados na sua produção e ou mais modelos ou normas de referência, será discutido.
ao conhecimento técnico que os usuários como, CMMI-DEV 1.2 ou ISO 9001:2000.
deste processo têm sobre as práticas de- Dessa forma, obtém-se a diferença entre Análise de Risco
finidas (institucionalização do processo). o que se espera dos processos da organi- Risco é a “exposição à chance de perdas
Partindo-se destas premissas pode-se zação e onde eles realmente estão. A partir ou danos”. Embora exista também uma
concluir que qualquer risco à qualidade e daí, elaboram-se planos de ação para que chance de alguma coisa sair melhor do
à institucionalização do processo se refle- esta distância seja diminuída ou elimina- que o esperado, o risco geralmente cos-
te em riscos na qualidade do produto que da, a partir da priorização e seleção dos tuma ser associado a possíveis perdas ou
será entregue e, consequentemente, em planos de ação que serão implantados danos. O conceito de risco resulta da incer-
riscos para a organização. Sendo assim, (fase de Estabelecimento). teza quanto a eventos futuros e é parte de
ações de gerência de risco nos processos
podem contribuir diretamente com a
garantia da qualidade do produto final
e fornecem dados que permitem identi- Por mais controlada e precisa que seja a execução de uma
ficar quais ações devem ser tomadas com
maior urgência. atividade de desenvolvimento, sempre existe o risco, mes-
Neste artigo apresentamos uma abor-
dagem de análise de processos na qual é mo que muito remoto, de algo dar errado.
identificado de forma customizada tanto
o nível de conformidade (quantidade de
recomendações do modelo de referência A abordagem que apresentaremos todas as atividades de desenvolvimento.
implementadas nos processos da organi- facilita a realização das fases de Diag- Um processo de desenvolvimento bem
zação) quanto o nível de risco (quantidade nóstico e Estabelecimento de um ciclo de definido e institucionalizado visa reduzir
de riscos presentes no processo de desen- melhoria contínua, identificando clara- a chance de ocorrência de ameaças (perdas
volvimento devido às recomendações não mente os riscos associados aos processos ou danos). Toda oportunidade de sucesso
implementadas) em cada área de processo. definidos (Diagnóstico) e fornecendo um sempre carrega consigo uma possibilidade
Dessa maneira, uma análise dos processos critério de priorização destes riscos (Es- de falha, cabendo a cada empresa avaliar
da organização fornece duas classes de tabelecimento). Para isso, são utilizadas a relação risco versus retorno e determinar
dados para a tomada de decisão e dire- uma estratégia de avaliação e atividades se “estar” sujeito a esta perda é aceitável,
cionamento de recursos, indicando o que de avaliação e melhoria de processos se este evento é muito grave, ou ainda
deve ser feito para melhorar o processo de desenvolvimento de software. A se o procedimento para a mitigação não
(conformidade) e quais ações devem ser avaliação verifica tanto a dimensão de oferece um retorno satisfatório.
tomadas primeiro (risco). conformidade entre o processo e modelos Por mais controlada e precisa que seja a
Uma das formas mais indicadas para a de maturidade ou normas de qualidade, execução de uma atividade de desenvol-
definição e implantação de processos de quanto à dimensão dos riscos que a não vimento, sempre existe o risco, mesmo
maneira eficiente é a utilização de um utilização das boas práticas definidas que muito remoto, de algo dar errado.
ciclo de melhoria contínua. Esta forma nestas referências oferecem à qualidade Este fato decorre do grande número de
pode ser comparada ao desenvolvimento do produto desenvolvido pela organiza- variáveis que podem influenciar no resul-
iterativo de um sistema, onde o processo é ção e aos seus objetivos de negócio. Esta tado final e da sua natureza muitas vezes
definido e implantado na organização em ferramenta também indica como estes imprevisível. A partir desse cenário,
fases direcionadas pelas necessidades e pontos podem ser solucionados de forma torna-se necessário aprender a conviver
características da organização. O modelo que a organização obtenha uma maior com riscos, minimizando suas possíveis
IDEAL, desenvolvido pelo Software Engi- qualidade ou resultados a partir deste conseqüências negativas.
neering Institute (SEI), ilustra a utilização ciclo. O diferencial desta abordagem é a As principais atividades da disciplina
deste conceito. A implantação deste ciclo utilização da análise de risco como um de gerência de riscos são:
de melhoria faz com que os processos de instrumento de priorização das ações que • Identificação corresponde à identifi-
uma organização sejam constantemente devem ser tomadas pelas empresas para cação dos riscos inerentes a uma etapa do
avaliados e melhorados. mitigar (reduzir as chances de ocorrên- desenvolvimento (fase, processo, itera-
No modelo IDEAL destacam-se duas cia) os riscos identificados durante a fase ção). Isto é feito através do levantamento
fases: Diagnóstico e Estabelecimento. A de diagnóstico fornecendo um critério das ameaças presentes e do impacto que
fase de Diagnóstico consiste em avaliar o concreto para definição do escopo de podem provocar caso se realizem.
ambiente produtivo e identificar as opor- cada ciclo de melhoria. • Análise corresponde à reflexão so-


bre os riscos identificados, a partir da é possível obter um retrato mais preciso são definidas quais áreas devem ser o
identificação do nível de exposição de da distribuição e do impacto dos riscos. foco de uma avaliação mais rigorosa e
cada projeto. É também realizado um A estratégia de diminuição de riscos da próxima iteração do ciclo de melhoria
estudo de classificação dos riscos no qual, utilizada nos planos elaborados durante contínua (qual é o problema e como ele
baseando-se no relacionamento entre a a atividade de planejamento pode tentar pode ser solucionado). Em cada uma
exposição e conseqüência negativa do reduzir sensivelmente a probabilidade do das etapas, são realizadas as fases de
risco e o benefício da oportunidade, de- risco se realizar, fazendo com que a con- Diagnóstico (identificação dos riscos) e
termina-se quais serão eliminados, quais cretização da perda seja algo muito difícil Estabelecimento (priorização e definição
serão mitigados, quais serão aceitáveis e de ocorrer. É possível tentar reduzir o dos planos de ação). Na etapa de Abran-
quais serão acompanhados. impacto do risco, fazendo com que a con- gência o diagnóstico é mais abrangente e
• Planejamento observa e determina seqüência da materialização dele seja tão os planos de ação são menos detalhados e,
como e quando os riscos serão aborda- pequena que a sua ocorrência pouco afe- na etapa de Profundidade, o diagnóstico
dos ao longo do projeto. Comumente tará o resultado final do projeto. Por fim, é mais específico e os planos de ação são
são elaborados planos de mitigação, é possível reduzir tanto a probabilidade mais detalhados.
eliminação e acompanhamento de riscos quanto a severidade do risco, resultando O objetivo desta estratégia é com-
que serão utilizados como base para a em um balanceamento razoável entre as plementar métodos como SCAMPI,
gerência de riscos. possíveis perdas e a probabilidade de sua MA-MPS e ISO/IEC 15504, oferecendo
propostas de soluções a alguns potenciais
problemas encontrados na aplicação des-
tes métodos. Os princípios que guiam a
A eliminação total dos riscos associados a um projeto ou estratégia são:
• Mapear resultados aos objetivos do
iniciativa é um conceito utópico. negócio da organização;
• Minimizar o esforço de avaliação se-
gundo critérios de importância definidos
pela própria organização;
• Controle corresponde à execução e ao ocorrência no projeto. • Obter maior aproveitamento dos re-
acompanhamento dos planos elaborados A eliminação total dos riscos associados sultados gerados;
para o projeto. Os riscos identificados a um projeto ou iniciativa é um conceito • Utilizar duas dimensões de análise:
são analisados constantemente para a utópico. Cada ação de identificação, conformidade e risco.
identificação do seu estado atual e atu- acompanhamento e controle (redução,
alização dos planos elaborados. Novos mitigação ou contenção de riscos) possui O primeiro princípio tem como objetivo
riscos podem ser identificados também. um custo associado, cabendo a cada indi- sanar uma característica identificada
A gerência de riscos utiliza como base o víduo ou organização identificar o ponto na maioria dos métodos de avaliação
conceito de exposição de risco. Para cada de equilíbrio entre o nível de exposição de processos de desenvolvimento. De
ameaça ou possível fonte de problema aos riscos e o custo de redução. Para cada forma geral, a aplicação destes métodos
que possa causar perdas ao projeto, a projeto ou iniciativa deve-se determinar gera conclusões ou resultados que estão
exposição (Exp) é definida como o pro- um índice aceitável de exposição aos restritos ao nível das diretivas do modelo
duto da probabilidade da perda ocorrer riscos, que seja suficiente para as carac- de maturidade ou norma de qualidade
(P) e do tamanho da perda (impacto I terísticas do projeto e tenha um custo que utilizada. Este fato faz com que o trabalho
no projeto, artefato, ativo ou qualquer não comprometa os resultados. de convencimento da alta gerência (geral-
elemento que seja o foco da análise de mente não técnica) acerca da importância
risco): Exp = P * I . A Estratégia de Avaliação dos investimentos em engenharia de
Na abordagem apresentada, o conceito A estratégia de avaliação que utiliza- software ou qualidade seja dificultado e,
de exposição foi estendido, permitindo remos se baseia no conceito de análise consequentemente, o projeto de melhoria
uma melhor determinação do impacto de risco na verificação dos processos de processos fique ameaçado devido à
da concretização de um risco. Para cada de uma organização e compreende os falta de comprometimento dos patrocina-
ativo da organização ou projeto avaliado conceitos apresentados na ISO/IEC 17799. dores. O objetivo destes princípios é dar
(pessoa que participa do desenvolvimen- Esta estratégia recomenda a avaliação ênfase às necessidades e prioridades da
to ou processos utilizados) é determinado de uma equipe de desenvolvimento ou empresa, ao invés de impor uma estru-
um índice de exposição balanceado. Este processo de software em duas etapas, tura que pode não ser a mais adequada a
índice, denominado PSR, determina a onde a primeira (etapa de Abrangência) ela. O mapeamento dos resultados do ní-
exposição através da probabilidade da representa uma verificação mais abran- vel de TI para o nível de negócios facilita
ocorrência do risco (P), a severidade gente e menos rigorosa da implementação o seu entendimento, podendo orientar a
dessa ocorrência para o projeto ou para dos modelos e normas de referência, para empresa a como atingir suas metas.
a organização (S) e a relevância do ativo identificar quais são as áreas críticas para O segundo e terceiro princípio é resul-
da organização (pessoa ou processo) na a organização (onde está o problema). Na tado da constatação de um ponto fraco
qualidade do produto final. Dessa forma etapa seguinte (etapa de Profundidade) identificado nos métodos mais utilizados.


proc ess o

A grande maioria realiza inspeções e de quando a avaliação foi realizada, a capacidade esperada e a avaliada, qual
análises rigorosas, que abrangem todo o tornando obsoletos os dados relativos às deve receber os recursos?). A utilização
modelo de referência e geram relatórios áreas de processos e as oportunidades de uma análise de risco oferece um cri-
com uma grande quantidade de informa- de melhoria que não foram abordadas. tério de desempate ou uma opção para a
ções sobre diversas áreas da engenharia A utilização de uma estratégia em duas priorização de investimentos.
de software mas, na maioria dos casos, etapas permite identificar, através de
outra grande quantidade de informações uma análise menos elaborada, as áreas Ferramenta de apoio à avaliação
é desperdiçada. Uma avaliação indica mais relevantes e realizar uma análise Para auxiliar a realização da avalia-
o estado atual da organização e aponta mais elaborada apenas nestas áreas. ção dos processos de uma organização
as oportunidades de melhoria na im- Finalmente, o quarto princípio tem utilizamos uma ferramenta de apoio à
plementação das diretivas do modelo como objetivo oferecer dados de um ní- execução de avaliações.
de maturidade ou norma de qualidade vel de abstração menos granular para a A metodologia de análise de risco
utilizada como referência. Entretanto, tomada de decisão. Embora a utilização implementada pela ferramenta se baseia
devido a restrições de orçamento e ao da capacidade de processo e do nível de na avaliação de características de ativos
impacto que elas representam no am- maturidade seja o parâmetro mais utili- da organização, que podem representar
biente produtivo, apenas uma pequena zado no direcionamento de recursos na pessoas da organização, processos uti-
parte destas recomendações pode ser área de desenvolvimento de software, lizados, tecnologias e características do
implementada na próxima iteração do estes conceitos são um tanto abstratos ambiente de desenvolvimento. Cada ativo
programa de melhoria. Após a implemen- e em muitos casos dificultam esta ativi- é mapeado em componentes de negócio
tação da primeira iteração de melhoria, o dade (se vários processos apresentam a (para o contexto de desenvolvimento de
estado da organização já não é o mesmo mesma capacidade e o mesmo gap entre software foram utilizados objetivos do

Figura 1. Mapeamento dos ativos em objetivos do negócio da organização


negócio ou de TI) da organização e pos- possui uma estrutura com os seguintes pode ser implementado para diminuir
sui uma relevância que está diretamente elementos: a exposição da organização aos riscos e
relacionada à relevância dos objetivos aos • Nome do Controle indica uma carac- atingir a conformidade desejada com o
quais ele se relaciona. A Figura 1 ilustra terística (boa prática ou requisito) que modelo ou norma de referência.
este conceito. deve estar presente no ativo para que o • Referências relacionam referências
A cada ativo podem ser associados um controle seja considerado implementado bibliográficas para que mais informações
ou mais componentes, que represen- e seu risco associado seja eliminado. acerca do controle e da sua implementa-
tam características que serão avaliadas • Justificativa define os termos e concei- ção possam ser obtidas.
em um projeto de avaliação que estão tos necessários para o entendimento do • Probabilidade representa a probabili-
relacionadas à participação deste ativo, controle e fornece uma justificativa que dade de uma ameaça se manifestar caso o
ou seja, ao adicionar um componente a explique porque aquele controle deve ser controle não esteja implementado na or-
um ativo estamos dizendo que ele é um implementado. Neste elemento são apre- ganização. Este elemento é representado
coletor de dados que indicam o estado sentadas as vantagens que se obtém com por um número de 1 (menor) a 5 (maior
de implementação de um conjunto de a implementação do controle e as conse- probabilidade).
boas práticas na organização. Um pro- qüências da sua não implementação. • Severidade indica o grau do impacto
jeto de avaliação pode utilizar todos os • Ameaças indicam quais elementos po- negativo na organização, caso uma ou
componentes ou apenas um conjunto dem se aproveitar da não implementação mais ameaças se manifestem. Este ele-
que seja relevante para esta instância de do controle para se manifestar e causar mento é representado por um número
avaliação. Cada componente possui um danos ao negócio da organização. de 1 (menor) a 5 (maior severidade).
checklist associado, composto por um ou • Recomendação fornece razões e dados • Agrupamento indica a qual agrupa-
mais controles, que representam os itens para a elaboração de um plano de ação mento o controle pertence. Os agrupa-
atômicos de verificação da implemen- após a realização da avaliação, através mentos são comuns a todos os checklists,
tação das boas práticas. Cada controle de uma sugestão de como o controle permitindo verificar o estado da imple-

Controle Processo - CMMI – Gerência de Configuração – Prática 3.1 - 2 - As versões anteriores de um item de configuração devem ser passíveis de recuperação.

Uma versão anterior de um item de configuração deve ser recuperada caso uma modificação não seja corretamente implementada, caso os arquivos atuais (na nova configuração
Justificativa do software) estejam corrompidos, caso seja efetuada uma junção (merge) incorretamente entre um ramo (linha temporária de desenvolvimento) e a linha principal de
desenvolvimento. Nestas situações, pode ser apropriado restaurar uma versão anterior para que esta se torne a atual.

Este controle pode ser implementado através dos seguintes procedimentos:
- Disponibilizar as versões dos itens de configuração.
- Reportar os procedimentos para: (1) recuperar uma versão anterior, (2) verificar as revisões de um item de configuração e (3) analisar as diferenças entre a versão anterior e a
atual. Essas informações devem constar no plano de gerência de configuração e nos procedimentos de controle de versões. Caso não estejam, sugere-se alterá-los.
- Garantir a integridade e a disponibilidade dos repositórios de configurações.
Recomendação Observação: A ferramenta de controle de versões deve facilitar a visualização e recuperação das versões dos itens de configuração. Portanto, contém funcionalidades que facilitam
a implementação deste controle.

Exemplos de Artefatos Produzidos:
- Lista de versões de itens de configurações
- Procedimentos para controle de versões

Probabilidade 4 Severidade 3

Std 1042 - IEEE Guide to Software Configuration Management, Institute of Electrical and Electronics Engineers, 1987.
ISO/IEC 12207 - Information technology - Software life cycle processes, International Organization for Standardization, 1995.
ISO/IEC 15504 - Information technology - Process Assessment, International Organization for Standardization, 2004.
Referências
CMMI-Dev: Área de Processo: Gerência de Configuração
Bibliografia de apoio:
H. R. Berlack, Software Configuration Management. New York: John Wiley & Sons, 1992.

Baixa manutenibilidade
Ameaças
Perda de controle de solicitações de mudança

Agrupamento Gerência de Configuração

Tabela 1. Exemplo de controle


proc ess o

mentação de características espalhadas de um processo padrão para a área de ganização, das pessoas, dos fornecedores
em vários checklists. processo de definida em algum modelo ou do projeto ao qual ele pertence. Sendo
ou norma de referência, como Gerência assim, chegou-se a seguinte taxonomia
A Tabela 1 apresenta um exemplo de de Configuração e Solução Técnica do para os ativos:
controle de uma prática de gerência de CMMI, ou grupo de áreas de processo, • Processos representam fluxos de tra-
configuração. que será utilizado como base para a balho, áreas de processo ou disciplinas da
A avaliação consiste em responder aos elaboração das recomendações de im- organização. Cada checklists associado
checklists associados aos ativos e sele- plementação de controles. Esta atividade a este tipo de ativo possui o escopo de
cionados na configuração do projeto de possui tarefas de elaboração e revisão uma área de processo do modelo de
avaliação. Estes podem ser respondidos de conteúdo e aderência aos modelos ou maturidade ou norma de qualidade. A
diretamente ou através de questionários normas de qualidade utilizadas como utilização destes ativos define uma di-
enviados via WEB, onde o conteúdo dos referência. Em seguida, atividades de mensão da avaliação onde os processos
controles pode ser interpretado para um geração e revisão de arquitetura dos che- são o principal fator para o alcance dos
domínio específico, por exemplo, para cklists são executadas de forma iterativa objetivos da organização e, consequen-
os diversos papéis de uma organização. e concorrente, até que um produto com temente, a principal fonte de evidências
A utilização dos questionários permite
um ganho de escala e de cobertura da
avaliação, ao mesmo tempo em que di-
minui o impacto da avaliação e aumenta
A arquitetura do checklist consiste da identificação dos
a aceitação das melhorias no processo de
desenvolvimento uma vez que todos se
controles que serão desenvolvidos e dos questionários que
sentem parte da avaliação e podem con-
tribuir com comentários e sugestões.
serão utilizados como coletores automáticos de dados.
Após a coleta dos dados, é gerado um
conjunto de relatórios contendo tabelas e
gráficos que indicam o estado da imple- qualidade assegurada seja desenvolvido. da implementação do modelo ou norma
mentação das boas práticas e os riscos A arquitetura do checklist consiste da de referência.
presentes na organização e fornecem identificação dos controles que serão • Pessoa representa os atores da orga-
dados para a tomada de decisão (o que e desenvolvidos e dos questionários que nização. Os checklists associados a este
como deve ser feito). Cada controle não serão utilizados como coletores automá- tipo de ativo verificam as diretivas da
implementado ou implementado parcial- ticos de dados. norma relativas a um papel da organi-
mente, contribui com um índice de risco Tendo um conjunto revisado dos contro- zação (desenvolvedor, gerente, analista
(PSR) que é obtido pela multiplicação da les que devem ser implementados e um de requisitos, etc.) que é assumido pela
relevância do ativo avaliado (R), da pro- questionário que interpreta e responde pessoa que é referenciada pelo ativo. A
babilidade da concretização das ameaças estes controles do checklist através de utilização de ativos do tipo Pessoa defi-
possíveis (P) e da severidade desta con- uma lógica bem definida para as suas ne uma dimensão da avaliação onde as
cretização (S) . Além do PSR, os seguintes perguntas, inicia-se uma nova etapa de pessoas e os papéis que elas executam
indicadores são utilizados: implementação e revisão dos controles, são o principal fator para o alcance dos
onde o conteúdo dos controles iden- objetivos da organização e, consequen-
Índice de PSR controles (elemento
) tificados é elaborado e o questionário temente, a principal fonte de evidências
Segurança = implementados

PSR (Total)
desenvolvido é refinado. Finalmente, os da implementação do modelo ou norma
checklists são homologados e adiciona- de referência.
dos à ferramenta. • Ambiente representam o ambiente
Índice de
€ Num.Controles Im plementado
s
Tendo um guia para a elaboração dos organizacional, caracterizado pelas
Conformidade = Num.ControlesTotal checklists, o segundo passo é a identifica- acomodações, aspectos inter-pessoais,
ção dos checklists que seriam utilizados política motivacional e outros fatores
A partir destes índices, pode-se gerar para a realização das avaliações. Como que afetam indiretamente a execução dos
um grande número de interpretações, os checklists são associados aos ativos da processos. Os checklists associados a este
através da filtragem e agrupamento de organização, através dos componentes, tipo de ativo verificam as características
dados das áreas de processo, ativos, esta atividade foi realizada utilizando gerais da organização e como ela contri-
ameaças, departamentos ou objetivos como parâmetro os tipos de ativos. bui ou não com o alcance dos objetivos
de negócio. A ferramenta define quatro tipos de da organização.
ativo para a realização das avaliações: • Tecnologia representa a estrutura
Utilizando a Abordagem “Pessoa”, “Processo”, “Ambiente” e “Tec- tecnológica da organização, definida por
Para utilização desta abordagem em nologia”. Para o domínio de processos de suas máquinas e ferramentas. Os che-
uma avaliação, utilizamos um conjunto desenvolvimento, definiu-se que cada cklists associados a este tipo de ativo ve-
de atividades. ativo funciona como uma dimensão de rificam características da infra-estrutura
A primeira atividade consiste na criação coleta de dados sobre os processos da or- referenciada pelo ativo, como segurança


em servidores, funcionalidades de ferra- Organizacional, Desenvolvimento de análise da atomicidade. Esta análise tem
mentas, entre outros. Requisitos, Foco no Processo Organiza- como objetivo quebrar o item em ele-
cional, Garantia da Qualidade, Gerência mentos de verificação atômicos, evitando
Como terceiro passo da customização, de Configuração e Gerência de Requisi- situações de falha no preenchimento do
a estrutura para a geração de checklists tos que representam as características controle (se existem dois ou mais pontos
foi elaborada. Esta atividade contou com específicas de cada área de processo e o de verificação conectados por um ope-
a definição dos agrupamentos, ameaças agrupamento GG2 – Processo Gerenciado rador “e” ou “ou” em um controle, como
e do escopo dos controles. representa as características genéricas. respondê-lo no caso de alguns estarem
Como o objetivo da avaliação é obter Estão também ilustrados controles dos implementados e outras não?).
resultados mapeados nas áreas de proces- agrupamentos de Gerência de Configu- Finalmente, para uniformizar as análi-
so do modelo ou norma de qualidade de ração e Gerência de Requisitos. Cada ses de risco e conformidade em processos
referência, independente de quais ativos agrupamento contém um conjunto de de desenvolvimento realizados com a
foram utilizados para coletar os dados, foi controles. utilização da ferramenta, foi elaborada
definido que os agrupamentos utilizados Com a estrutura de agrupamentos defi- uma lista de ameaças.
seriam as áreas de processo. nida, os resultados das análises de risco Tendo em vista que a grande maioria
Uma área de processo possui carac- e conformidade podem ser consolidados dos métodos de avaliação de processos
terísticas específicas, que determinam pelos agrupamentos, resultando em rela- de desenvolvimento (SCAMPI, MA-MPS,
a sua implementação, e características tórios (exemplificados no próximo tópi- ISO/IEC 15504) utiliza uma estrutura
comuns a todas as áreas, que indicam a co), que indicam risco e conformidade de de níveis para a classificação da imple-
sua capacidade. Para facilitar a utilização cada área de processo, e que deixam de mentação de uma diretiva do modelo ou
de modelos de maturidade que utilizam forma transparente quais tipos de ativo norma, utilizamos nesta solução a mesma
o conceito de capacidade de processos foram utilizados. abordagem. Desta forma, cada controle
foi definido também que deve existir Para o escopo dos controles, foi definida pode ser classificado como “Implemen-
um agrupamento para cada nível de a utilização do item de menor granulari- tado”, “Não Implementado” ou “Parcial-
capacidade. dade do modelo ou norma de referência. mente Implementado”. Partindo do fato
A Figura 2 ilustra este conceito para o Como em muitos modelos e normas o de que um controle parcialmente imple-
CMMI-DEV 1.2, onde um Checklist para item de menor granularidade possui mais mentado não se encontra implementado,
o ativo desenvolvedor (papel) contém os de um item de verificação em seu escopo, foi determinado que, quando a análise
agrupamentos Definição do Processo foi definida também a realização de uma realizada indicasse que um controle não

Figura 2. Checklist com agrupamentos para características específicas e genéricas


proc ess o

foi totalmente atendido, este deve ser os controles parcialmente implementados de desenvolvedor, portanto o peso das
preenchido como “Não implementado”. contribuirão com menos risco do que os áreas técnicas do modelo será maior que
Utilizando a premissa de que um controle controles do mesmo tipo classificados o peso das áreas de gestão ou das áreas
parcialmente implementado possui uma como não implementados. organizacionais. Além disso, nesta etapa,
probabilidade menor de causar danos do os objetivos do negócio da organização
que um controle não implementado, foi Utilizando a abordagem não foram identificados e mapeados nos
determinado que, para cada nível de im- Para demonstrar a aplicabilidade da ativos de software.
plementação atingido pelo controle, a sua abordagem proposta, foram realizados Abaixo são apresentados os resultados
probabilidade será diminuída em uma vários estudos de caso, nos quais o da avaliação:
unidade, até chegar ao valor mínimo 1. processo utilizado por equipes de desen- Conforme apresentado na Tabela 3 e
Para exemplificar a abordagem, consi- volvimento de software de organizações na Figura 3, as áreas de Planejamento
dere um controle cuja probabilidade seja distintas foi avaliado. A seguir, é apre- de Projetos, Solução Técnica e Defini-
quatro. Em uma avaliação que utiliza sentado um resumo de uma das avalia- ção do Processo Organizacional têm o
o modelo CMMI como referência, um ções realizadas onde se realizou apenas maior índice de Segurança indicando que
controle classificado como parcialmente a etapa de Abrangência. Para preservar a maior parte das práticas destas áreas
implementado será preenchido como Não a confidencialidade, as informações estão implementadas. Ao contrário, as
Implementado e a sua probabilidade será apresentadas foram descaracterizadas áreas de Treinamento Organizacional,
alterada para três. O resultado desta abor- (ver Tabela 2). Gerência de Requisitos, Integração
dagem é que, ao final da análise de risco, A avaliação considerou somente o perfil do Produto e Gerência de Configura-

Empresa ABC

Objetivos: Avaliar o processo utilizado no desenvolvimento dos softwares da organização utilizando o modelo CMMI DEV 1.2 como referência e identificar oportunidades de melhoria nas áreas de processo
de maior impacto no desenvolvimento dos softwares.

Fase de Abrangência

Escopo Organizacional Participantes Escopo do Modelo Duração (h/dias)

Projetos de desenvolvimento de - 9 Desenvolvedores do Setor 1 Áreas de níveis 2 e 3 do CMMI DEV 1.2, exceto : Garantia da Qualidade, Gerencia de Fornecedores,
16/4
sistemas internos da organização - 9 Desenvolvedores do Setor 2 Gerência de Risco, Gerenciamento Integrado e Análise de Decisões e Resoluções

Tabela 2. Resumo do objetivo e escopo da avaliação

PSR Controles PSR Controles Não Índice de Conformidade Índice de Segurança
Área de Processo PSR Total
Implementados Implementados (%) (%)
Avaliação e Melhoria do Processo 64 194 256 32,16 25,00

Definição do Processo Organizacional 160 96 256 85,13 62,50

Desenvolvimento de Requisitos 304 1328 1632 19,16 18,63

Gerência de Configuração 388 1912 2300 25,34 12,52

Gerência de Requisitos 72 1152 1224 0,00 5,88

Integração do Produto 148 1364 1512 15,05 9,79

Medição e Análise 248 264 512 76,18 48,44

Monitoramento e Controle de Projetos 580 780 1360 74,05 42,65

Planejamento de Projetos 1024 200 1224 78,15 83,66

Solução Técnica 2140 852 2992 67,12 71,52

Treinamento Organizacional 8 400 408 0,00 1,96

Validação 108 468 576 22,25 18,75

Verificação 316 1472 1788 18,15 17,67

Total 5560 10482 16040 67,15 53,04
Tabela 3. Resultados da avaliação em abrangência por área de Processo


V is ão G eral - Área P roc es s o

Planejamento de Projetos
Solução Técnica
Definição do Processo Organizacional
Medição e Análise
Monitoramento e Controle de Projetos
Avaliação e Melhoria do Processo
Segurança
Validação
Conformidade
Desenvolvimento de Requisitos
Verificação
Gerência de Configuração
Integração do Produto
Gerência de Requisitos
Treinamento Organizacional

0 20 40 60 80 100
%

Figura 3. Resultados da avaliação em Abrangência – Gráfico de Índices de conformidade e segurança para cada área de Processo (Ordenação decrescente
pelas áreas de maior índice de Segurança)

R is c o Abs oluto - Área P roc es s o

Verificação
Solução Técnica
Validação

0 500 1000 1500 2000 2500
PSR

PSR Implementado PSR Não Implementado

Figura 4. Resultados da avaliação em Abrangência – Gráfico de PSR por área de Processo (Ordenação decrescente pelas áreas de maior PSR)


proc ess o

R is c o Abs oluto - S etor 1

Solução Técnica
Verificação
Validação

0 200 400 600 800 1000 1200
PSR


Figura 5. Resultados da avaliação em Abrangência – Gráfico de PSR do Setor 1 por Processo (Ordenação decrescente pelas áreas de maior PSR)

R is c o Abs oluto - S etor 2

Verificação
Validação
Solução Técnica

0 200 400 600 800 1000 1200 1400
PSR


Figura 6. Resultados da avaliação em Abrangência – Gráfico de PSR do Setor 2 por Processo (Ordenação decrescente pelas áreas de maior PSR)


ção têm o menor índice de Segurança Verificando as informações apresen- mais relevantes estão relacionadas com:
indicando que poucas práticas destas tadas na Tabela 4 e nas Figuras 5 e 6, o
áreas estão implementadas. As áreas de conclui-se que na organização, as áreas Produto não atender às necessidades dos
Definição do Processo Organizacional, de Gerência de Configuração, Verifi- clientes - Desenvolvimento de Requisitos,
Medição e Análise, Monitoramento cação, Integração do Produto, Desen- Verificação e Validação;
e Controle de Projetos e Gerência de volvimento de Requisitos e Gerência o
Configuração têm um índice de Confor- de Requisitos têm maior probabilidade Requisitos incompletos, inconsistentes ou
midade relativamente maior que o índice de manifestação dos riscos durante sua incorretos - Gerência e o Desenvolvimen-
de Segurança indicando a implementação execução. Entretanto, quando os dois to de Requisitos e Verificação;
de práticas pouco eficientes na mitigação setores são avaliados separadamente o oftware apresentar falhas – Solução Téc-
S
dos riscos. conclui-se que: nica, Integração do Produto e Verificação;
De acordo com a Figura 4, pode-se o o
verificar que as áreas de Gerência de No Setor 1 as áreas de Gerência de Confi- Perder controle sobre as solicitações de mu-
Configuração, Verificação, Integração guração, Solução Técnica, Integração do dança - Gerência de Requisitos e Gerência
do Produto, Desenvolvimento de Re- Produto, Verificação, Desenvolvimento de Configuração.
quisitos e Gerência de Requisitos têm de Requisitos e Gerência de Requisitos
maior PSR Não implementado indicando têm maior probabilidade de manifestação Como resultado final da avaliação,
maior probabilidade de manifestação dos dos riscos durante sua execução, ou seja, definiu-se um plano priorizando ações
riscos durante sua execução. Ao contrá- a área de Solução Técnica tem um peso de melhoria nas áreas de Gerência de
rio, as áreas de Definição do Processo importante nos riscos das atividades do Configuração, Desenvolvimento de
Organizacional, Avaliação e Melhoria Setor 1; Requisitos e Gerência de Requisitos,
do Processo, Planejamento de Projetos o que apresentaram um alto PSR não im-
e Medição e Análise têm menor PSR No Setor 2, as áreas de Verificação, De- plementado, combinado com um baixo
não implementado, indicando menor senvolvimento de Requisitos, Gerência índice de segurança. Para um melhor
probabilidade de manifestação dos riscos de Configuração, Integração do Produto detalhamento das ações de melhoria foi
durante sua execução. e Gerência de Requisitos têm maior sugerida também a realização de uma
As áreas de Solução Técnica, Planeja- probabilidade de manifestação dos riscos avaliação em Profundidade para cada
mento de Projetos e Monitoramento e durante sua execução, ou seja, o mesmo uma das três áreas mencionadas.
Controle de Projetos têm maior PSR im- resultado da organização com a inversão Em um segundo momento, foram su-
plementado, indicando a implementação de algumas posições. geridas ações de melhoria para as áreas
de práticas que evitaram a manifestação de Verificação e Integração do Produto,
de um maior número de riscos. Pelo apresentado na Figura 7, as ameaças devido ao alto PSR não implementado

Setor 1 Setor 2

PSR Controles PSR Controles Não PSR Controles PSR Controles Não
Área de Processo PSR Total PSR Total
Implementados Implementados Implementados Implementados

Avaliação e Melhoria do Processo 30 98 128 34 94 128

Definição do Processo Organizacional 82 46 128 78 50 128

Desenvolvimento de Requisitos 272 544 816 32 784 816

Gerência de Configuração 16 1134 1150 372 778 1150

Gerência de Requisitos 72 540 612 0 612 612

Integração do Produto 70 686 756 78 678 756

Medição e Análise 82 174 256 166 90 256

Monitoramento e Controle de Projetos 316 364 680 264 416 680

Planejamento de Projetos 518 94 612 506 106 612

Solução Técnica 796 700 1496 1244 252 1496

Treinamento Organizacional 4 200 204 4 200 204

Validação 84 204 288 24 264 288

Verificação 256 638 894 60 834 894
2598 5422 8020 2862 5158 8020
Tabela 4. Resultados da avaliação em Abrangência – por Setor e Área de Processo


Qualidade de software

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (20)

Semelhante a Qualidade de software

Semelhante a Qualidade de software (20)

Mais de Fabiano Da Ventura

Mais de Fabiano Da Ventura (16)

Qualidade de software