Bruno Ferreira

UMA TCNICA PARA VALIDAO DE PROCESSOS DE

DESENVOLVIMENTO DE SOFTWARE

Bruno Ferreira

UMA TCNICA PARA VALIDAO DE PROCESSOS DE

DESENVOLVIMENTO DE SOFTWARE

Dissertao apresentada ao Curso de Mestrado em

Modelagem Matemtica e Computacional (MMC) do
Centro Federal de Educao Tecnolgica de Minas
Gerais, como requisito parcial obteno do ttulo
de Mestre em Modelagem Matemtica e
Computacional.
rea de pesquisa: Sistemas Inteligentes.
Orientador: Prof. Dr. Gray Farias Moita

Belo Horizonte
Centro Federal de Educao Tecnolgica de Minas Gerais
Diretoria de Pesquisa e Ps-Graduao 2008

F383t
2008

Ferreira, Bruno
Uma tcnica para validao de processos de desenvolvimento de
software. 2008.
146 f.
Orientador: Gray Farias Moita
Dissertao (mestrado) Centro Federal de Educao Tecnolgica
de Minas Gerais.
1. Engenharia de software Teses. 2. Software Verificao.
3. Software Validao. I. Moita, Gray Farias. II. Centro Federal de
Educao Tecnolgica de Minas Gerais. III. Ttulo.
CDD 005.1

Elaborao da ficha catalogrfica por Biblioteca-Campus II / CEFET-MG

Folha de aprovao. Esta folha ser

fornecida pelo Programa de PsGraduao e dever substituir esta
pgina.

Dedico este trabalho aos meus pais, Divino e Maria e aos meus irmos Efrem e
Viviane, que sempre me incentivam a seguir em frente e a superar os desafios.
minha namorada Danielle, que compreendeu meus momentos de ausncia e
impacincia.

AGRADECIMENTOS

A Deus, por me proporcionar todas as oportunidades de aprendizado

vivenciadas at o presente momento.

Ao meu orientador, Prof. Dr. Gray Farias Moita, pelas diretrizes de pesquisa,
pelo incentivo durante todo o projeto e pela pacincia e apoio mesmo nos
momentos adversos.

A TOTVS/SA, pela confiana e pela participao nos estudos realizados nessa

pesquisa. Um agradecimento especial para Isabela Iunes de Oliveira, Tllio
Mendes Rodrigues e Srgio Gontijo do Nascimento por aceitarem o convite de
participao nas pesquisas.

Aos colegas e amigos da TOTVS/SA e ao Prof. Vitor da Fundao Educacional

de Oliveira pelo apoio nos momentos de dificuldade.

Aos professores e colegas do Grupo de Pesquisa em Sistemas Inteligentes

GPSI, do CEFET-MG.

todos aqueles que contriburam de alguma forma com este trabalho.

Comece fazendo o que necessrio, depois o que

possvel, e de repente voc estar fazendo o
impossvel. (So Francisco de Assis)

RESUMO

A grande demanda e o crescente grau de complexidade do software nas

ltimas dcadas obrigaram as empresas desenvolvedoras de sistemas a
utilizarem processos de desenvolvimento de software. Embora, existam na
literatura vrios processos de desenvolvimento, com caractersticas diferentes
que atendem os diversos ramos do desenvolvimento, tais processos no se
mostram suficientes. As prticas de desenvolvimento diferem entre as
organizaes, o que as obrigam a criar ou aprimorar processos j conhecidos.
No entanto, para que um processo possa garantir sua eficincia ele deve ser
vlido. Neste trabalho proposto um modelo de validao de processo,
baseado nos conceitos de Verificao & Validao (V&V), fazendo uso da
tcnica de Inspeo de Software para validar processos de desenvolvimento de
software. Ao final, apresentado um estudo de caso que foi realizado como
uma primeira tentativa de analisar o modelo proposto. Os resultados
apresentados indicam que vivel e simples validar processos pelo uso
desses conceitos e tcnicas de V&V.

ABSTRACT
The increasing demand for software in the last decades led to a most
intensively use of specific software development processes. Although there are
several software development processes with different characteristics in the
literature, such processes are not enough to encompass the numerous fields of
software applications. The practices of development differ among the
developers and, therefore, sometimes it is necessary to improve or join
processes already known to guarantee one needs. Consequently some
software producers are still in need of specific processes that can attend their
particular interests and, in some situations, forcing them to conceive new
processes. However, a process can only guarantee its correctness and
efficiency after being thoroughly tested and validated. The validation is
conceptually complex and related to a wide range of issues, many times
subjective, what leads to a possible absence of guidelines or benchmarks to
validate a process of development of software. In this research a process
validation model is proposed, based on the concepts of Verification and
Validation (V&V), making use of the Software Inspection Technique to validate
software development processes. It is presented a case study that was carried
out as a first attempt of analysing the proposed model. The presented results
indicate that it is viable and simple to validate processes with the use of V&V
concepts and techniques.

10

LISTA DE ABREVIATURAS E SIGLAS

CASE Computer Aided Software Engineering
CEFET/MG Centro Federal de Educao Tecnolgica de Minas Gerais
CMMI Capability Maturity Model Integration
ERP Enterprise Resource Planning
GPSI Grupo de Pesquisa de Sistemas Inteligentes
IBIS Internet Based Inspection System
IEEE Instituto de Engenheiros Eletricistas e Eletrnicos
ISPIS Infra-estrutura de Suporte ao Processo de Inspeo
ISO International Organization for Standardization
IV&V Verificao e Validao Independente
LSI Laboratrio de Sistemas Inteligentes
MVP Planos de Verificao Principal
NAS Manual de Engenharia de Sistemas
NASA Administrao Nacional de Aeronutica e Espao Norte Americana
NA No aplicvel
PESC Processo de Desenvolvimento Especfico para Software Cientfico
PU Processo Unificado
RAD Rapid Application Development
RE Resposta esperada
RVCD Documento de Cumprimento de Verificao dos Requisitos
SEI Software Engineering Institute
SDK Kits de Desenvolvimento de Software
SQA Garantia da Qualidade de Software
UML Unified Modeling Language
VRTM Matriz de Responsabilidade de Verificao criado
VProcInsp Validao de Processos por Inspeo
V&V Verificao e Validao
XP Extreme Programming

11

LISTA DE FIGURAS
Figura 1.1 Apresentao da dissertao em captulo ................................... 21
Figura 2.1 Camadas da engenharia de software (Fonte: Pressman, 2006). . 23
Figura 2.2.1 Modelo em Cascata (Fonte: Pressman, 2006). ......................... 26
Figura 2.2.2 Modelo Incremental (Fonte: Pressman, 2006). ......................... 27
Figura 2.2.3 Modelo RAD (Fonte: Adaptado de Pressman, 2006). ............... 28
Figura 2.2.4 Modelo de Prototipagem (Fonte: Pressman, 2006). .................. 30
Figura 2.2.5 Modelo Espiral (Fonte: Pressman, 2006). ................................. 31
Figura 2.3.1 Termos relativos ao cronograma de um PU (Fonte: Larman,
2004). ............................................................................................................... 33
Figura 2.3.2 Artefatos mais importantes produzidos durante as fases do PU
(Fonte: Pressman, 2006). ................................................................................. 34
Figura 2.3.4 Ciclo de desenvolvimento proposto pelo PESC. (Fonte: Pereira
Jr, 2007). .......................................................................................................... 38
Figura 2.5 Framework de comparao de eventos (Fonte: Cook e Wolf,
1999). ............................................................................................................... 47
Figura 3.1 Atividades de Verificao e Validao (Adaptada de NAS, 2006).
......................................................................................................................... 51
Figura 3.2 Diagrama em V da Engenharia de Sistemas (Adaptada de NAS,
2006). ............................................................................................................... 52
Figura 3.3 Modelo clssico de V&V (Adaptada de Sargent, 2000). ............... 53
Figura 3.4.1 Redistribuio do retrabalho pelas atividades de
desenvolvimento de software. (Adaptado de Wheeler et al., 1996). ................ 65
Figura 3.4.2 Custo relativo para corrigir um defeito (Adaptado de Boehm,
1981). ............................................................................................................... 65
Figura 3.4.3 Processo de inspeo de software (Fonte: Fagan, 1976) ......... 67
Figura 3.4.4 Processo de Inspeo de Software Assncrono (Fonte: Sauer et
al., 2000). ......................................................................................................... 69
Figura 4.1 Inspeo de Software em diferentes artefatos (Fonte: Ackerman et
al.,1989) ........................................................................................................... 73
Figura 4.2 Verso padro do Checklist proposto pelo VProcInsp ................. 80
Figura 4.3 Modelo de Inspeo proposto pelo VProcInsp (Adaptado de Sauer
et al., 2000). ..................................................................................................... 82
Figura 4.3.2 Atividades pertencentes fase de Planejamento...................... 84
Figura 4.3.3 Documento de Planejamento de Validao por Inspeo
proposto pelo VProcInsp .................................................................................. 85

12

Figura 4.3.4 Documento de Cadastro de Inspetores proposto pelo VProcInsp

......................................................................................................................... 86
Figura 4.3.5 Documento de Atribuies de Inspetores proposto pelo
VProcInsp ......................................................................................................... 87
Figura 4.3.6 Atividades pertencentes fase de Anlise e Comparao ....... 88
Figura 4.3.7 Relatrio de Discrepncia proposto pelo VProcInsp ................. 89
Figura 5.1 Processo de desenvolvimento criado pela RM Sistemas ............. 99
Figura 5.2 Fase de Especificao do processo de desenvolvimento criado
pela RM .......................................................................................................... 100
Figura 5.3 Fase de Implementao do processo de desenvolvimento criado
pela RM .......................................................................................................... 101
Figura 5.4 Contexto em que o VProcInsp foi aplicado no estudo de caso .. 103
Figura 5.5 Relatrio de Discrepncia preenchido com os dados do estudo de
caso ................................................................................................................ 104
Figura 5.6 Relatrio de Discrepncia preenchido com os dados do estudo de
caso ................................................................................................................ 106

13

LISTA DE TABELAS
Tabela 2.1 Princpios da XP (Adaptado de Astels et al., (2002). ................... 35
Tabela 2.2 Mtodo de validao de processos baseados em atividades.
(Fonte: Moor e Delugach, 2006)....................................................................... 46
Tabela 3.1 Taxonomia de Tcnicas de Verificao & Validao (Fonte: Balci,
1995). ............................................................................................................... 56
Tabela 3.2 Caractersticas da tcnica de Desk-Checking. (Fonte: Perry,
1995). ............................................................................................................... 57
Tabela 3.3 Caractersticas da tcnica de Peer-Review. (Fonte: Perry, 1995).
......................................................................................................................... 58
Tabela 3.4 Caractersticas da tcnica de Design Review (Fonte: Perry, 1995)
......................................................................................................................... 59
Tabela 3.5 Caractersticas da tcnica de Auditoria (Fonte: Perry, 1995). ..... 60
Tabela 3.6 Caractersticas da tcnica de Walkthrough (Fonte: Perry, 1995). 61
Tabela 3.7 Caractersticas da tcnica de Inspees (Fonte: Perry, 1995) .... 62
Tabela 4.1 Taxonomia de defeitos propostos pelo VProcInsp ...................... 77
Tabela 4.2 Tcnica de Insp. de Software (Adaptado de Barcelos e Travassos,
2005). ............................................................................................................... 78
Tabela 5.1 Planejamento de experimento. .................................................... 97
Tabela 5.2 Informaes levantadas pelo VProcInsp antes da fase de
Discriminao ................................................................................................. 109
Tabela 5.3 Descrio dos itens com discrepncias do cheklist de
especificao.................................................................................................. 111
Tabela 5.4 Informaes levantadas pelo VProcInsp na etapa de
Especificao na fase de Discriminao ........................................................ 113

SUMRIO
CAPTULO 1 .................................................................................................... 16
INTRODUO ................................................................................................. 16
1.1 Motivao ............................................................................................... 17
1.2 Caracterizao do Problema .................................................................. 18
1.3 Objetivos: Geral e Especfico ................................................................. 20
1.4 Organizao da Dissertao .................................................................. 20
CAPTULO 2 .................................................................................................... 22
PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE ............................. 22
2.1 Processo de desenvolvimento: viso geral ............................................ 22
2.2 Modelos de Processo de Desenvolvimento ........................................... 24
2.2.1

Modelo em Cascata ...................................................................... 25

2.2.2

Modelos Incrementais ................................................................... 26

2.2.3

Modelos Evolucionrios ................................................................ 29

2.3 Processos de Desenvolvimento de Software ......................................... 31

2.4 Questes sobre avaliao e validao em processos de desenvolvimento
de software ................................................................................................... 40
2.5 Anlise das tcnicas empregadas em processos de desenvolvimento de
software ........................................................................................................ 42
CAPTULO 3 .................................................................................................... 49
VERIFICAO E VALIDAO DE SOFTWARE ............................................. 49
3.1 Conceitos de Verificao & Validao .................................................... 49
3.2 Tcnicas de Verificao & Validao ...................................................... 55
3.3 Anlise das Tcnicas Informais............................................................... 57
3.4 Conceitos de Inspeo de Software........................................................ 63
3.4.1 Benefcios da Inspeo de Software................................................. 64
3.4.2 O Processo de Inspeo de Software............................................... 66
CAPTULO 4 .................................................................................................... 71
PROPOSTA DE UMA TCNICA DE VALIDAO DE PROCESSO POR
INSPEO ....................................................................................................... 71
4.1 A tcnica proposta: viso geral e justificativas ....................................... 71
4.2

Validao de Processo de Desenvolvimento de Software por Inspeo

............................................................................................................ 74

4.2.1 Detalhamento do Processo de Validao Proposto ...................... 74

4.2.1.1 Determinar os artefatos do processo .......................................... 75
4.2.1.2 Definio do papel e do perfil da equipe participante do processo
de inspeo para validao .................................................................... 75
4.2.1.3 Taxonomia de defeitos ............................................................... 77
4.2.1.4 Tcnica de inspeo utilizada..................................................... 78
4.2.1.5 Processo utilizado na inspeo .................................................. 82
CAPTULO 5 .................................................................................................... 92
AVALIAO DA TCNICA DE VALIDAO DE PROCESSO POR INSPEO
PROPOSTA ..................................................................................................... 92
5.1 Discusso .............................................................................................. 92
5.2 Definio ................................................................................................ 95
5.3 Planejamento ......................................................................................... 95
5.4 Operao ............................................................................................... 98
5.5 Anlise dos Dados e Resultados Obtidos ............................................. 107
5.5.1 Anlise dos resultados da abordagem ............................................ 107
5.5.2 Anlise da utilizao da abordagem ............................................... 114
5.6 Consideraes em relao hiptese do estudo ................................. 114
CAPTULO 6 .................................................................................................. 116
CONCLUSES E CONSIDERAES FINAIS .............................................. 116
6.1 Resumo ................................................................................................ 116
6.2 Contribuies ........................................................................................ 119
6.3 Limitaes ............................................................................................. 120
6.4 Trabalhos Futuros ................................................................................. 120
REFERNCIAS BIBLIOGRFICAS ............................................................... 122
Apndice A ..................................................................................................... 128
Documentos do VProcInsp Aplicados no Estudo de Caso ............................. 128
Apndice B ..................................................................................................... 143
Questionrio de Avaliao Ps-Experimento ................................................. 143

16

CAPTULO 1
INTRODUO

O desenvolvimento e o uso de software tm passado por profundas

modificaes, seguindo o aumento da capacidade de processamento e de
memria das mquinas. Seu uso estende-se praticamente por todos os setores
da atividade humana. A automatizao de tarefas repetitivas, o aumento de
controle e eficincia em procedimentos especficos, a possibilidade de
antecipao de problemas e apresentao de uma soluo prvia, como o
caso de simulaes computacionais, so apenas algumas das possveis
aplicaes dessa tecnologia. Mas, em conseqncia deste contexto, a criao
e manuteno de software vm apresentando um significativo aumento na
complexidade, fato este que favorece a maior incidncia de erros e,
conseqentemente, queda na qualidade.
Para contornar esta situao, tcnicas de Engenharia de Software so
empregadas nos casos em que se deseja obter a garantia da qualidade do
software que ser desenvolvido. Estas tcnicas - conhecidas como Processos
de

Desenvolvimento

de

Software,

ou

simplesmente,

processo

de

desenvolvimento - quando bem empregadas, possibilitam um desenvolvimento

de software de alta confiabilidade e qualidade.
Apesar das vantagens no uso dos vrios processos de desenvolvimento
propostos, a implantao e a aplicao desses processos se revelam uma
tarefa complexa, sendo altamente dependentes do ambiente em que eles so
inseridos. Em conseqncia desse panorama, um considervel nmero de
processos vm sendo criados, aperfeioados ou simplesmente otimizados para
atender as necessidades das equipes de projetos.
Para evitar problemas ao criar ou otimizar um processo, Humphrey (1995),
apresentou uma metodologia de criao que consiste dos seguintes passos: (1)

17

Determinar as necessidades e as prioridades do novo processo; (2) Definir os

objetivos e os critrios de qualidade; (3) Caracterizar o processo atual; (4)
Caracterizar o processo desejado; (5) Estabelecer uma estratgia de
desenvolvimento do processo; (6) Definir um processo inicial; (7) Validar o
processo inicial; (8) Melhorar o processo. Esses passos so importantes
porque podem diminuir a subjetividade de criao, formalizando as atividades
necessrias a serem seguidas.
A validao do processo inicial um passo importante e pode responder a uma
preocupao natural da gerncia de projetos a garantia que o processo de
desenvolvimento guia os participantes de forma correta e eficiente durante a
criao do software. Burocracia excessiva ou uma orientao ambgua podem
atrapalhar, ao invs de orientar, o desenvolvimento no ciclo de criao do
produto.
Neste contexto, este trabalho tem o intuito de apresentar uma tcnica para
validar um processo de desenvolvimento de software, fundamentada em
conceitos, diretrizes e tcnicas de Verificao & Validao de Software,
minimizando a subjetividade de criao de processos. Para essa tcnica,
definiram-se algumas caractersticas que so consideradas importantes e que
seria interessante estarem presentes na atividade de validao: (1) Genrica e
Adaptvel para que a tcnica possa ser aplicada na avaliao de diferentes
artefatos do processo de desenvolvimento, ficando independente, portanto, da
abordagem utilizada para cri-los; (2) Simples para que no seja necessria
a execuo de atividades elaboradas para sua aplicao, a exigncia de tipos
de conhecimento especficos ou a alocao de grandes quantidades de
recursos; (3) Extensvel para que seja facilmente modificvel e permita ser
aplicada com outras tcnicas de validao de processos de desenvolvimento.

1.1 Motivao
O cenrio mundial nunca foi to competitivo como hoje e isso no est restrito
a um setor especfico. No ambiente de competio, onde as empresas
procuram alcanar uma posio de destaque sobre seus concorrentes, elas
adotam estratgias visando criar e sustentar vantagens competitivas.

18

No campo da tecnologia da informao, o processo de desenvolvimento de

software um elemento fundamental para obteno dessas vantagens no que
diz respeito criao de sistemas. As empresas devem produzir software com
qualidade, e em tempo hbil, para que o produto final seja competitivo.
Diante deste cenrio, o processo de desenvolvimento deve guiar os envolvidos
nos projetos de software de forma clara e eficiente. Um processo
excessivamente burocrtico ou que no condiz com a realidade da empresa e,
que exige recursos humanos e material inexistente, ou conhecimento e
treinamento insuficiente, pode confundir os envolvidos na criao de software
que utilizam tal processo.
Sendo assim, o processo de desenvolvimento deve ser eficiente e tangvel
(alcanvel) de ser seguido. Ou seja, a execuo do processo durante um
projeto deve seguir o modelo formal do processo proposto. Indicando que o
processo vlido.
Segundo Cook e Wolf (1999), o processo de validao serve a vrios objetivos,
entre eles garantir a confiana no modelo do processo formal, pois a execuo
do processo deve ser compatvel com o modelo do processo descrito. Isto, por
sua vez, aumenta a confiana nos resultados de qualquer anlise executada no
modelo formal do processo. A validao do processo pode ser usada tambm
como uma ferramenta de garantia do processo, descobrindo diferenas entre o
comportamento desejado e o comportamento real. Finalmente, o processo de
validao pode revelar quando um processo talvez necessite evoluir para
acomodar atividades e requisitos de um novo projeto.

1.2 Caracterizao do Problema

Validar um processo de desenvolvimento no uma tarefa simples. Um
problema que validao conceitualmente complexa, pois se refere a uma
larga escala de questes, muitas vezes subjetivas. Outro problema encontrado
a ausncia de diretrizes, tcnicas ou padres consolidados e documentados
para auxiliar os interessados em executar esta tarefa.

19

As poucas pesquisas nesta rea so complexas e dependentes do contexto em

que foram aplicadas. Logo, evidente a ausncia de uma tcnica que seja: (1)
Genrica e Adaptvel; (2) Simples e (3) Extensvel.
Neste ponto, importante ressaltar que validar no dizer que o produto
criado foi construdo corretamente utilizando o processo, mas sim provar que o
processo atende s necessidades dos colaboradores, quanto s questes de
Engenharia de Software. Mais especificamente, o processo deve representar
com exatido as atividades de comunicao, planejamento, modelagem,
construo, implantao e manuteno, na perspectiva pretendida pelos
envolvidos no projeto, que justamente a idia de Validao (Cook e Wolf,
1999).
Contudo, criar ou mesmo padronizar tcnicas de validao de processos,
tornando-as disponveis, ajudaria qualquer instituio que tenha a necessidade
de gerar seu prprio processo, evitando incertezas ou mesmo falhas no
produto, por conseqncia de ambigidade, inconsistncias ou erros em um
processo de software recm criado.
Diante dessas colocaes, surge ento o problema, objeto de discusso, para
o qual se intenta encontrar respostas no decorrer da presente pesquisa. Como
validar novos processos de desenvolvimento de software de forma simples,
extensvel e adaptvel?
Baseada na questo em estudo nesta dissertao, a hiptese formulada : Se
forem aplicados conceitos e tcnicas de Verificao e Validao de Software,
ento a tarefa de validar um processo pode se tornar simples, adaptvel e
extensvel.
Sendo assim, focando no problema mencionado, prope-se utilizar tcnicas de
Verificao e Validao de Software, mais precisamente, Inspeo de
Software. Essa uma tcnica metdica, mas de fcil aplicao, e vem sendo
utilizada para validar documentos conceituais em outros ramos da Engenharia
de Software.

20

1.3 Objetivos: Geral e Especfico

O objetivo geral deste trabalho desenvolver uma tcnica de validao de
processos de desenvolvimento de software utilizando de conceitos e tcnicas
de Verificao & Validao empregadas em softwares.
Para tanto, este trabalho se props aos seguintes objetivos especficos:

Apresentar um referencial terico acerca das tcnicas utilizadas para

validar e verificar software e possveis tcnicas para validao de
processos.

Propor uma tcnica de validao a partir da identificao das melhores

prticas e tcnicas de Verificao &Validao, que se aplique aos
processos de desenvolvimento de software.

Validar a tcnica proposta aplicando-a em um processo j conhecido e

utilizado em grande escala.

1.4 Organizao da Dissertao

Esse trabalho foi organizado em seis captulos. Aps a introduo so
apresentados conceitos de processos de desenvolvimento de software e
Verificao & Validao de Software, alm de uma anlise sobre certificao
de processo e de trabalhos correlatos. Em seguida, apresentada a tcnica de
validao proposta, o estudo de caso realizado e uma anlise dos resultados.
Aps as consideraes finais so listadas as referncias bibliogrficas
utilizadas e os apndices com os documentos gerados pelo estudo de caso. A
Figura 1.1 apresenta graficamente a organizao dessa dissertao em
captulos.

21

Problema:
Como validar novos processos de
desenvolvimento de software de
forma simples, extensvel e
adaptvel?

Hiptese:
Se forem aplicados conceitos e
tcnicas de Verificao e
Validao de Software, ento a
tarefa de validar um processo
pode se tornar simples, adaptvel
e extensvel.

Soluo Proposta:
Propor uma tcnica de validao
baseada em Inspeo de
Software. Para medir a
discrepncia entre o modelo
formal e a execuo do processo.

Avaliao da soluo:
Aplicar a tcnica de validao em
um processo j validado. Para
analisar a valia e possveis
melhorias da tcnica proposta.

2. Processo de Desenvolvimento:
Apresenta conceitos acerca de Processos
de Desenvolvimento de Software,
Certificao de Processos e uma anlise
dos trabalhos correlatos.

3. Verificao e Validao:
Apresenta conceitos e tcnicas de
Verificao & Validao de Software.
feita uma anlise das tcnicas informais e
os conceitos de Inspeo de Software so
apresentados.
4. Tcnica de Validao Proposta:
Apresenta uma proposta para validar
processos de desenvolvimento de forma
metdica, denominada VProcInsp.

5. Avaliao da soluo - Estudo de Caso:

Apresenta o Estudo de Caso para analisar
a aplicabilidade da tcnica proposta, que
teve como objetivo confirmar a hiptese
que orienta essa dissertao. Por fim a
anlise dos resultados apresentada.
6. Concluses:
Resumo da pesquisa descrita nessa
dissertao enfatizando as principais
contribuies e sugestes para
prosseguimento do trabalho.

Figura 1.1 Apresentao grfica da organizao da dissertao em captulos

22

CAPTULO 2
PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE

Neste captulo so apresentadas algumas definies que permitem identificar o

contexto dos processos de desenvolvimento de software. Para embasar o
trabalho, foram estudados os modelos de processos, dois processos de
desenvolvimento de software convencionais, existentes na literatura e um
processo proposto recentemente para a comunidade cientfica, mas que
necessita de uma validao formal. apresentada tambm a diferena entre
avaliar e validar um processo e, para finalizar, um panorama sobre as tcnicas
de validao e de melhorias de processo existentes na literatura levantado.

2.1 Processo de desenvolvimento: viso geral

Na dcada de 70, a atividade de desenvolvimento de software era executada
de forma desorganizada, desestruturada e sem planejamento, gerando um
produto final de m qualidade. Essa poca ficou conhecida como Crise do
Software (Melo, 2004). A partir deste cenrio, surgiu a necessidade de tornar o
desenvolvimento

de

software

um

processo

estruturado,

planejado

padronizado.
Segundo Paula (2003, p.11), um processo um conjunto de passos
parcialmente ordenados, constitudos por atividades, mtodos, prticas e
transformaes, usados para atingir uma meta.
Para Pressman (2006, p.17), os processos de software formam a base para o
controle gerencial de projetos de software e estabelecem o contexto no qual os
mtodos tcnicos so aplicados, os produtos de trabalho (modelos,
documentos, dados, relatrios, formulrios) so produzidos, os marcos so

23

estabelecidos, a qualidade assegurada e modificaes so adequadamente

geridas.
Ainda segundo Pressman, o processo o elo que mantm unidas as camadas
de tecnologia e permite o desenvolvimento racional e oportuno de software de
computador. A Figura 2.1 ilustra a camada de processo e as demais camadas
da engenharia de software.
Ferramentas
Mtodos
Processos
Foco na Qualidade

Figura 2.1 Camadas da engenharia de software (Fonte: Pressman, 2006).

A engenharia de software tem como foco principal a qualidade final do produto

gerado, e uma maneira de atingi-la atravs do aperfeioamento do processo
de desenvolvimento. Para auxiliar nessa tarefa os mtodos fornecem as
tcnicas de construo, que abrangem um amplo conjunto de operaes que
incluem anlise de requisitos, projeto, construo de programas, teste e
manuteno. As ferramentas de engenharia de software fornecem apoio
automatizado ou semiautomatizado tanto para o processo quanto para os
mtodos.
Somerville (2007, p.42) observa que embora existam muitos processos de
software diferentes, algumas atividades fundamentais so comuns a todos
eles, como:

Especificao: a funcionalidade do software e as restries sobre sua

operao devem ser definidas;

Projeto e implementao: o software que atenda especificao deve

ser produzido;

Validao: o software deve ser validado para garantir que ele faa o que
o cliente deseja;

24

Evoluo: O software deve evoluir para atender s necessidades

mutveis do cliente.

Assim, um processo considerado importante principalmente porque fornece

estabilidade, controle e organizao para a atividade de desenvolvimento de
software, que pode tornar-se catica caso no seja bem acompanhada. Para
tornar o desenvolvimento de software uma atividade mais efetiva, importante
definir modelos de processo de software.
Atualmente existe um grande nmero de processos de desenvolvimento
software e esses processos seguem os modelos propostos pela literatura. As
sees seguintes apresentam os principais modelos de processo existentes e
trs processos de desenvolvimento de software, que foram considerados
importantes para o entendimento geral do problema descrito nessa dissertao.
As sees a seguir descrevem sucintamente os modelos e processos
fundamentando-se em Pressman (2006), Somerville (2007) e Paula (2003).

2.2 Modelos de Processo de Desenvolvimento

Em um processo de desenvolvimento de software o ponto de partida para a
arquitetura de um processo a escolha de um modelo de processo de
software. Dependendo do tipo de projeto a ser desenvolvido, modelos
diferentes

sero

utilizados.

Segundo

Pressman

(2006,

p.

19),

independentemente do modelo de processo selecionado, os engenheiros de

software tm, tradicionalmente, escolhido um arcabouo genrico que inclui as
seguintes atividades:

Comunicao: envolve alta comunicao e colaborao com o cliente e

outros interessados e abrange o levantamento de requisitos e outras
atividades relacionadas. Procura descobrir, definir, especificar e
documentar as funcionalidades gerais do software;

Planejamento: estabelece um plano para o trabalho de desenvolvimento

do software, ou seja, descreve as tarefas tcnicas a serem conduzidas,

25

os riscos do projeto, os recursos necessrios, os artefatos a serem

produzidos e um cronograma de trabalho;

Modelagem: cria os modelos que permitem entender melhor os

requisitos do software e o projeto que vai satisfazer esses requisitos. a
representao de engenharia do software que vai ser construdo;

Construo: combina a gerao do cdigo-fonte, que deve implementar

as funcionalidades especificadas, e os testes necessrios para descobrir
os erros na funo, no comportamento e no desempenho do software;

Implantao: entrega do software ao cliente, que avalia o produto e

fornece feedback com base na avaliao.

As atividades podem ser organizadas em seqncia ou intercaladas

dependendo do tipo de software, pessoas e estruturas organizacionais
envolvidas. A forma de organizao das atividades pode ser definida segundo
os modelos apresentados a seguir.
2.2.1 Modelo em Cascata
O Modelo em Cascata, proposto em 1970, tambm conhecido como ciclo de
vida clssico onde as fases definidas para o desenvolvimento do software so
sistematicamente seguidas de maneira seqencial. Essa abordagem comea
pela especificao de requisitos pelo cliente e progride ao longo do
planejamento, modelagem, construo, implantao e manuteno progressiva
do software, como apresentado na Figura 2.2.1.
Segundo Pressman (2006, p.39), o modelo em cascata o mais antigo, no
entanto, sua eficcia questionvel devido alguns problemas levantados
quando o modelo aplicado. Projetos reais raramente seguem o fluxo
seqencial que o modelo prope. Neste modelo, existe a necessidade de se
estabelecer todos os requisitos na fase inicial, fato que em geral difcil tanto
para o cliente quanto para o desenvolvedor, j que os requisitos mudam
constantemente. Outro problema a demora para apresentao de uma
verso executvel do software, que s estar disponvel para o cliente no final
do projeto.

26

Comunicao
Iniciao do Projeto
Levantamento de
Requisitos
Planejamento
Estimativas
Cronogramas
Monitorao
Modelagem
Anlise
Projeto
Construo
Codificao
Teste
Implantao
Entrega
Manuteno

Figura 2.2.1 Modelo em Cascata (Fonte: Pressman, 2006).

2.2.2 Modelos Incrementais

Esses modelos assumem que o software desenvolvido pode sempre crescer e
agregar novas funcionalidades, sendo que cada uma dessas funcionalidades,
ou o conjunto delas, ser desenvolvido por um incremento e esse incremento
segue todas as etapas descritas no modelo em cascata.
O primeiro incremento deste modelo chamado de ncleo do produto, pois
nele estaro os requisitos bsicos do sistema. Os prximos incrementos
desenvolvidos agregaro os requisitos do ncleo do produto e dos incrementos
anteriores j desenvolvidos. Ao final de cada incremento, gerada uma verso
simplificada do produto final, que apresentada ao cliente. Este modelo um
melhoramento do modelo em cascata, pois permite a alterao dos requisitos
durante o desenvolvimento do software. A Figura 2.2.2 apresenta o modelo
incremental.

27

Incremento 1
1

Entrega do 1
incremento

Incremento 2

Entrega do 2
incremento

Incremento n

Entrega do
incremento N

Tempo decorrido

1 Comunicao

2 Planejamento

3 Modelagem

4 Construo

5 Implantao

Figura 2.2.2 Modelo Incremental (Fonte: Pressman, 2006).

Modelo RAD
O Modelo RAD (Rapid Application Development) um exemplo de modelo
incremental, considerado uma adaptao para projetos curtos, geralmente com
prazo mximo de 90 dias. Sua principal caracterstica que o produto de
software seja desenvolvido em componentes, pois a reutilizao de cdigo
permite que a equipe de desenvolvimento possa desenvolver um sistema
completamente funcional em pouco tempo.
Este modelo de desenvolvimento tem aplicao nos casos em que o sistema
pode ser modularizado. Cada uma das equipes RAD de desenvolvimento fica
responsvel por um mdulo, enquanto que outras equipes desenvolvem outros
mdulos, de forma concorrente. Ao final da construo de cada mdulo h uma
integrao entre eles. Este ciclo se repete at que o software esteja
completamente pronto. Este modelo possui cinco fases mostradas na Figura
2.2.3.
A comunicao trabalha para entender os problemas do negcio. O
planejamento para gerenciar o trabalho paralelo das equipes. A fase de

28

modelagem abrange a modelagem do negcio, a qual visa organizao dos

requisitos do sistema a ser construdo. A modelagem dos dados identifica as
caractersticas e relaes entre objetos de dados, e na modelagem do
processo, os objetos de dados definidos anteriormente so transformados para
construir o fluxo de informao necessrio para implementar uma funo do
negcio. A fase de construo enfatiza o uso de componentes de software
preexistentes e a aplicao de gerao automtica de cdigo. Finalmente a
fase de implantao faz a integrao entre os mdulos e recolhe um feedback
de utilizao do sistema criado.
Modelagem
Modelagem de negcios
Modelagem de dados
Modelagem de processo
Equipe n

Comunicao

Modelagem
Modelagem de negcios
Modelagem de dados
Modelagem de processo
Equipe 2

Construo
Reuso de componentes
Gerao automtica de
cdigo
Testes

Construo
Reuso de componentes
Gerao automtica de
cdigo
Testes

Planejamento

Modelagem
Modelagem de negcios
Modelagem de dados
Modelagem de processo
Equipe 1

Construo
Reuso de componentes
Gerao automtica de
cdigo
Testes
60 a 90 dias

Figura 2.2.3 Modelo RAD (Fonte: Adaptado de Pressman, 2006).

Implantao
Integrao
Entrega
Feedback

29

2.2.3 Modelos Evolucionrios

Os Modelos Evolucionrios baseiam-se na idia de desenvolvimento de uma
implementao inicial, expondo o resultado ao cliente e refinando esse
resultado por meio de vrias verses, para que ento seja desenvolvido o
sistema adequado.
Os modelos servem como um importante mecanismo para explorar os
requisitos, uma vez que o desenvolvimento comea com as partes do sistema
compreendidas e evolui por meio da adio de novas caractersticas propostas
pelos clientes. Diferentemente do Modelo Incremental, as verses no
necessariamente so produtos operacionais. Segundo Pressman (2006, p.47),
partindo do ponto de vista da engenharia e do gerenciamento, a abordagem
evolucionria traz algumas preocupaes: o planejamento incerto (no existe
um mtodo para calcular com preciso o nmero de ciclos que sero
necessrios) e se a evoluo de desenvolvimento for muito rpida, o processo
pode se transformar em caos (algumas atividades importantes do processo
podem ser desconsideradas, gerando problemas na construo e manuteno
do software).
So exemplos de Modelos Evolucionrios: o modelo de prototipagem e o
modelo espiral.
Modelo de Prototipagem
A prototipagem um modelo de processo que possibilita ao desenvolvedor
criar um modelo do software que deve ser construdo. Assim, uma prvia
avaliao tanto do cliente, quanto do desenvolvedor pode ser feita. Este
modelo pode ser usado como um modelo de processo independente, ou como
uma tcnica, que pode ser implantada no contexto de qualquer um dos
modelos de processo existentes. A vantagem da prototipagem auxiliar o
engenheiro de software e o cliente, a entenderem melhor o que deve ser
construdo, quando os requisitos esto confusos.
Este modelo comea pela comunicao. Os envolvidos no projeto identificam
os objetivos gerais do software e as necessidades conhecidas. Em seguida

30

uma iterao
rao planejada e o prottipo modelado de forma rpida. Aps a
modelagem; o prottipo criado, implantado e depois avaliado pelo usurio.
Esta avaliao usada para refinar os requisitos e fornecer um melhor
entendimento do problema.
Aps a identificao
cao de todos os requisitos, o prottipo deve ento ser
descartado, j que no foi construdo observando-se
observando se critrios para a garantia
da qualidade do produto. Em seguida, o produto final construdo, com foco na
qualidade. A Figura 2.2.4 exibe o ciclo d
de
e desenvolvimento do modelo de
prototipagem ressaltando a sua forma cclica.

Figura 2.2.4 Modelo de Prototipagem (Fonte: Pressman, 2006).

Modelo Espiral
O Modelo Espiral um modelo iterativo, como o Modelo de Prototipagem, e
sistemtico como o Modelo em Cascata. Essas caractersticas facilita
facilitam com
que sejam lanadas verses utilizveis do projeto ao final de cada iterao do
modelo, similar ao modelo incremental.
Esse modelo se subdivide em regies que abrigam conjuntos de tarefas que
crescem proporcionalmente
nalmente ao risco e ao tamanho do projeto. So elas:
Comunicao com o Cliente, a fim de manter contato com o cliente, adquirindo
informaes teis ao sistema; Planejamento, que definir custo
custo e tempo de
desenvolvimento, alm de realizar uma anlise de risco,
co, onde os riscos da

31

implementao so avaliados para que o desenvolvimento no se torne

invivel na prxima etapa do modelo; Modelagem, responsvel pela criao da
representao conceitual da aplicao; Construo, onde acontecem a
implementao e testes; Implantao, responsvel pela instalao, suporte e
feedback do incremento desenvolvido.
Iniciado o processo, ele passa por todas as regies e depois volta primeira,
executando novamente as regies seguindo uma espiral at que se tenha o
produto desejado, como mostra a Figura 2.2.5
Uma forte caracterstica desse modelo, que o difere de outros modelos, o fato
de acompanhar toda a vida do software, mesmo depois da entrega ao cliente.
Este modelo considerado o mais realstico possvel, pois assume que
usurios, analistas e desenvolvedores adquirem maior conhecimento sobre o
projeto com o decorrer do tempo. As falhas do software so identificadas e
corrigidas, impedindo que se propaguem para as prximas iteraes do ciclo
de desenvolvimento do software.
Planejamento
Estimativa
Cronograma
Anlise de Risco
Comunicao

Modelagem
Anlise de
Projeto
Incio

Implantao
Entrega
Feedback

Construo
Cdigo
Teste

Figura 2.2.5 Modelo Espiral (Fonte: Pressman, 2006).

2.3 Processos de Desenvolvimento de Software

Com base nos conceitos propostos pelos modelos de processo, vrios
processos de desenvolvimento de software so criados para atender as
diversas exigncias do contexto em que so aplicados. Nesta seo so
apresentados trs processos de desenvolvimento com algumas caractersticas
semelhantes, como as de serem leves e adaptativos, ao invs de exigirem

32

muitos artefatos, criando uma atmosfera pesada (burocrtica), e de serem

preditivos, ao tentar planejar e prever as atividades em detalhes por um longo
intervalo no ciclo de desenvolvimento.
Processo Unificado (PU)
O Processo Unificado um processo de desenvolvimento de software que
descreve uma abordagem para a construo, implantao e manuteno de
projetos orientado a objetos. Ele foi proposto por Ivar Jacobson, James
Rumbaugh e Grady Booch e utiliza a Linguagem de Modelagem Unificada
(UML Unified Modeling Language). Essa linguagem serve como notao para
uma srie de modelos que compem os principais resultados das atividades
deste processo (Jacobson, 1999).
Segundo Larman (2004, p. 42), a idia central a ser apreciada e praticada no
PU a de usar iteraes curtas com durao fixa, em um processo de
desenvolvimento iterativo e adaptativo. Algumas das melhores prticas e
conceitos-chave adotados pelo PU so:

Enfrentar os problemas que envolvem altos riscos e alto valor j nas

iteraes iniciais;

Envolver continuamente os usurios na avaliao, na realimentao e

nos requisitos;

Construir uma arquitetura central coesa nas iteraes iniciais;

Verificar continuamente a qualidade; fazer testes logo de incio, com

freqncia e em situaes realsticas;

Aplicar casos de uso;

Modelar visualmente o software (com a UML);

Gerenciar requisitos cuidadosamente;

Usar solicitaes de mudana e praticar a gerncia de configurao.

O Processo Unificado promove, principalmente, o desenvolvimento iterativo.

Nesta abordagem, o desenvolvimento organizado em uma srie de miniprojetos, de durao fixa, chamados iteraes. O produto de cada iterao
um sistema testado, integrado e executvel. Cada iterao inclui suas prprias
atividades de anlise de requisitos, projeto, implementao e teste. Entre as

33

vantagens
antagens dessa abordagem pode-se
pode
citar (1) a mitigao precoce, em vez de
tardia, de riscos, (2) o progresso visvel desde o incio e (3) a complexidade
administrada, a equipe no sobrecarregada
sobrecarregada pela "paralisia da anlise" ou por
passos muito longos e complexos;
Como mostra a Figura
igura 2.3
2.3.1 o PU organiza o trabalho de cada iterao em
quatro fases principais e Larman (2004, p. 43) as descreve como a seguir
seguir:
1. Concepo viso aproximada, regras de negcio, escopo e
estimativas vagas. (estudo de viabilidade);
2. Elaborao viso refinada, implementao iterativa da arquitetura
central, resoluo dos riscos, identificao da maioria dos requisitos e do
escopo
o e estimativas mais realistas;
3. Construo implementao iterativa dos elementos restantes e
preparao para a implantao;
4. Transio testes beta e implantao;
implantao

Figura 2.3.1 Termos relativos ao cronograma de um PU (Fonte: Larman, 2004)

2004).

Em cada fase devem ser executadas diferentes atividades, produzindo

artefatos especficos. O Processo Unificado trata as atividades de trabalho
como disciplinas e define artefato como qualquer produto gerado durante as
atividades
dades do processo: documentos textuais,
textuais, modelos, cdigo, grficos, casos
de teste e manuais so exemplos de artefatos (Larman,, 2004). Existem vrias
disciplinas no PU, como, por exemplo: Modelagem de Negcio, Requisitos,
Projeto, Teste, Implantao, Gesto de Mudana e Configurao, Gesto de
Projeto e Ambiente.. A Figura 2.3.2
2
ilustra
stra os artefatos mais importantes,
importantes
produzidos em conseqncia,
conseqncia das quatro fases tcnicas do PU,, de acordo com
Pressman (2006, p.54).

34
Concepo
- Documento de viso.
- Modelo inicial de
caso de uso.
- Glossrio inicial do
projeto.
- Caso de negcio
inicial.
- Avaliao inicial de
risco.
- Plano de projeto.
- Modelo de negcio.
- Prottipos.

Elaborao
- Modelo de caso de
uso.
- Requisitos
suplementares.
- Modelo de anlise.
- Descrio da
arquitetura do
software.
- Prottipo arquitetural
executvel.
- Modelo de projeto
preliminar.
- Lista de risco
revisada.
- Plano de projeto,
incluindo: planos de
iterao, fluxos de
trabalho, marcos.

Construo
- Modelo de projeto.
- Componentes de
software.
- Incremento integrado
de software.
- Plano de teste.
- Caso de teste.
- Documentao de
apoio como: manuais
do usurio e de
instalao, descrio
do incremento atual.

Transio
- Incremento de
software entregue.
- Relatrio de teste
beta.
- Realimentao
geral do usurio.

Figura 2.3.2 Artefatos mais importantes produzidos durante as fases do PU (Fonte:

Pressman, 2006).

Outro ponto a ser considerado sobre o PU que algumas das prticas e dos
princpios do PU so invariantes, como o desenvolvimento iterativo e orientado
ao controle de riscos, bem como a retificao contnua da qualidade.
Entretanto, um aspecto-chave do PU que todas as atividades e os artefatos
so opcionais, tornando o processo leve e adaptativo.
Extreme Programming (XP)
Extreme Programming um processo de desenvolvimento gil. Segundo Beck
(2000), os processos geis aplicam-se com especial relevncia em pequenos
projetos ou projetos com equipes de trabalho co-localizadas. Apresentam uma
viso semelhante sobre as boas prticas necessrias ao desenvolvimento de
software e a obteno da qualidade, como, por exemplo, o desenvolvimento
iterativo, a preocupao com os requisitos e o envolvimento dos usurios finais
no processo.
Segundo Astels et al. (2002), as prticas do XP so criadas para funcionar
juntas e fornecer mais valor do que cada uma poderia fornecer individualmente.
O XP apresenta uma grande preocupao com relao a alterao constante

35

dos requisitos do sistema. Sobre esta questo, a XP enftica; o

desenvolvedor deve permitir que o projeto seja flexvel. Em outras palavras, o
desenvolvedor deve aceitar as alteraes e no lutar contra elas.
A Extreme Programming define 13 princpios bsicos, que devem ser adotados
em conjunto por qualquer projeto que se baseie nesta tcnica. Estes 13
princpios so mostrados na Tabela 2.1, juntamente com uma explicao
resumida.
Tabela 2.1 Princpios da XP (Adaptado de Astels et al., (2002).
Princpio
1. Cliente faz parte da
equipe de desenvolvimento
2. Uso de metforas

3. Planejamento

4. Reunies curtas
5. Teste contnuo

6. Simplicidade
7. Programao em Pares

8. Padro de Codificao
9. Propriedade coletiva
sobre o cdigo-fonte
10. Integrao contnua

11. Refatorao contnua

12. Concepo de
pequenas verses

13. Jornada de Trabalho

Descrio resumida
O cliente deve participar do desenvolvimento, fornecendo o
feedback necessrio para a correo precoce de falhas.
Deve-se utilizar metforas para a definio de termos
complexos, para permitir um conhecimento uniforme de toda a
equipe.
O projeto deve ser constantemente planejado para permitir
uma real
identificao do seu progresso.
As reunies devem ser curtas, de preferncia sem o uso de
cadeiras, para que se discuta os termos estritamente relevantes.
Deve-se efetuar testes antes mesmo da implementao de um
cdigo. Este teste precoce permite um controle otimizado sobre
as falhas de um projeto.
O projeto deve ser o mais simples possvel.
A programao deve ser feita em pares. Enquanto um
programador tem um foco no cdigo que est desenvolvendo, o
observador tem uma viso macro do processo, permitindo a
identificao facilitada de falhas.
Todos as pessoas envolvidas no processo devem definir e seguir
um mesmo padro de codificao.
Todas as pessoas devem ter acesso livre ao cdigo-fonte, de
modo que possa acrescentar melhorias e corrigir falhas
identificadas.
Deve-se efetuar uma contnua integrao do novo cdigo
gerado, para que seja possvel identificar precocemente falhas
na integrao deste novo cdigo.
O desenvolvedor deve alterar a estrutura interna sempre, de
forma a melhorar a sua performance, sem alterar o
funcionamento externo do cdigo.
Devem ser concebidas pequenas verses de cdigo de cada vez,
para que os usurios tenham rapidamente um contato com uma
verso executvel do software e conseqentemente consigam
gerar o feedback necessrio.
A equipe de desenvolvimento deve ter uma jornada de trabalho
flexvel e leve, para que no exista fadiga e estresse dos seus
membros.

36

Processo de Desenvolvimento Especfico para Software Cientfico (PESC)

O PESC um processo de desenvolvimento especfico para software
cientficos. Ele considera o termo software cientfico como, software
desenvolvido por pesquisadores em seus projetos de pesquisa cientfica. A
grande maioria destes projetos de natureza acadmica, ou seja, projetos de
pesquisa de iniciao cientfica, mestrado, doutorado, ps-doutorado, dentre
outros, que necessitam da construo de software para auxiliar estas
pesquisas (Purri et al., 2006).
O PESC fruto do trabalho de dois alunos de mestrado do curso de
Modelagem Matemtica e Computacional do CEFET/MG. Purri (2006), em sua
dissertao de mestrado, formulou e validou 12 hipteses acerca do
desenvolvimento de software que praticado atualmente no meio acadmico.
Para

tanto,

foi

realizada

uma

pesquisa

semiqualitativa,

atravs

da

implementao de um questionrio Web (disponibilizado na internet), onde

pesquisadores das mais diversas reas caracterizaram como desenvolvem
seus softwares e o que julgam importante em seu desenvolvimento. Tal
questionrio foi fundamental para que as atividades propostas por Humphrey
(1995) fossem realizadas. Com base nas respostas, Purri (2006), apresentou
as seguintes diretrizes iniciais que o processo deveria contemplar:
1. Ciclo iterativo e incremental;
2. Base no Processo Unificado;
3. Deve ser um processo simples;
4. Deve ser voltado para uma equipe pequena de desenvolvimento;
5. Deve utilizar a linguagem UML como base;
6. Deve permitir o gerenciamento de cdigo aberto e concorrente;
7. A utilizao dos artefatos deve ser opcional.
Assim como o processo apresenta algumas caractersticas essenciais, os
artefatos tambm devero possuir algumas peculiaridades. Segundo Purri
(2006), as caractersticas so as seguintes:
1. Descrio das funcionalidades gerais do software;
2. Projeto arquitetural;
3. Definio do tipo de licena do software;

37

4. Descrio da relevncia cientfica do software;

5. Documentao do cdigo-fonte e regras de codificao;
6. Descrio das restries e viabilidade do projeto;
7. Levantamento completo e especificao detalhada dos requisitos;
8. Diagramas de casos de uso, descrio e especificao;
9. Diagrama de classes completo;
10. Citao das referncias cientficas nas quais a implementao ir se
basear;
11. Descrio dos algoritmos complexos;
12. Documentao dos

componentes reutilizados na construo do

software;
13. Documentao de mdulos lgicos reutilizveis em outros projetos;
14. Plano e descrio dos testes;
15. Relatrios de erros encontrados e causas;
16. Registro das falhas e dos sucessos do projeto de software;
17. Manual do usurio do software.
Tomando como ponto de partida as diretrizes citadas acima, Pereira Jr (2007)
props um processo de desenvolvimento inicial. Esse processo sofreu fortes
influncias do Processo Unificado e do Extreme Programming, adaptando os
conceitos j consagrados do ciclo de vida iterativo e incremental do PU e a
padronizao e propriedade coletiva do cdigo-fonte, a simplicidade do
processo e a integrao contnua propostos pelo XP.
O ciclo de desenvolvimento utilizado no PESC definido como iterativo e
incremental, que empregado no Processo Unificado e na XP. Como o ciclo de
vida evolutivo, ele composto por iteraes. Ao final de cada iterao, temse uma parte executvel do sistema, conhecido como liberao ou verso. Em
cada uma das iteraes so contempladas as seguintes fases:

Planejamento Cada uma das iteraes deve ser extremamente

reduzida. Isto permite um controle muito maior do desenvolvimento, j
que se pensa apenas em uma pequena parte do projeto de cada vez.
Cada uma das iteraes deve ser planejada de modo que seja simples,

38

mas

que

no

deixe

de

lado nenhum

detalhe

importante

ao

desenvolvimento.

Desenvolvimento

Com

base

no

planejamento

rpido

feito

anteriormente, desenvolvida a verso da iterao em questo,

observando-se os padres de codificao. gerada ento uma verso
em cada iterao do ciclo de vida.

Testes Aps o seu desenvolvimento, cada verso deve passar pelos

testes de unidade e integrao. Os testes de unidade servem para
garantir que esta verso esteja funcionando de acordo com o
planejamento efetuado. Aps a aprovao desta verso no teste de
unidade, deve-se proceder com o teste de integrao, onde ser
verificada a compatibilidade deste novo cdigo com o que j existia
anteriormente.

Implantao Depois de passar pelos testes de unidade e integrao, a

nova verso deve ser incorporada ao cdigo-fonte oficial.

A Figura 2.3.4 mostra o ciclo de desenvolvimento proposto, com seus artefatos

definidos para cada fase do desenvolvimento. Logo em seguida, uma descrio
dos artefatos apresentada de acordo com Pereira Jr (2007).

Figura 2.3.4 Ciclo de desenvolvimento proposto pelo PESC. (Fonte: Pereira Jr,
2007).

39

Controle Geral de Desenvolvimento este artefato conhecido como

artefato guarda-chuva. Sendo assim, este artefato especfico para o
controle geral do desenvolvimento do software.

Requisitos e Escopo da Verso este artefato utilizado e/ou

modificado na fase de planejamento, que a primeira etapa do ciclo de
desenvolvimento do PESC. Neste artefato, o desenvolvedor deve
registrar o que foi planejado para aquela iterao.

Detalhamento dos Casos de Uso este artefato modificado ainda na

fase de planejamento. Ele confeccionado com base nas informaes
coletadas

e documentadas

Desenvolvimento.

Este

no

artefato

documento

de

de

Controle Geral

detalhamento

possui

de
os

diagramas de caso de uso e suas especificaes.

Plano de Codificao da Verso este artefato modificado na fase de

planejamento e deve ser consultado e, se necessrio, modificado na
fase de desenvolvimento. Esse artefato particularmente importante
para o sucesso do desenvolvimento, pois define todos os detalhes
pertinentes ao desenvolvimento do cdigo-fonte propriamente dito,
incluindo os diagramas de classes.

Plano de Testes este artefato utilizado na fase de testes. O cdigofonte gerado na fase anterior do ciclo de vida servir de base para a
aplicao dos testes que sero documentados neste artefato.

Registro das Falhas e Sucessos este artefato utilizado ao final da

fase de implantao do ciclo de vida do PESC. Aps uma iterao
completa da evoluo do desenvolvimento, o pesquisador ter
enfrentado dificuldades e possveis falhas, bem como ter conseguido
sucessos no seu desenvolvimento. Este artefato permite que o
desenvolvedor possa registrar as falhas e sucessos obtidos no
desenvolvimento de cada verso.

O PESC, como todo processo de desenvolvimento proposto ou customizado

seguindo a metodologia de Humphrey (1995), deve executar o stimo passo
dessa metodologia, que consiste em validar o processo inicial. Neste contexto,
o PESC sentiu a ausncia de tcnicas de validao de processo bem

40

documentadas e serviu para confirmar a caracterizao e a pergunta problema

desta pesquisa.

2.4 Questes sobre avaliao e validao em processos de

desenvolvimento de software
Esta seo discute questes relevantes acerca de avaliao e validao de
processos de desenvolvimento de software. Essa discusso leva em
considerao os pontos levantados por Cook e Visconti (1993), que
diferenciam as atividades de avaliao das atividades de validao. Estas
definies so importantes, pois esta pesquisa tem o objetivo de criar uma
tcnica de validao e no de avaliao.

Avaliao
O propsito dos procedimentos de avaliao de processos de software
determinar onde os padres organizacionais do processo se familiarizam com
um modelo pr-determinado. A idia da avaliao determinar o estado atual
das prticas da equipe de desenvolvimento. Essa determinao a base para
a criao de um plano para melhorias nos procedimentos, mtodos e
ferramentas de engenharia de software. O objetivo principal melhorar a
qualidade do produto e a produtividade das pessoas que esto usufruindo do
processo. Portanto, uma avaliao de processo ajuda uma organizao a
caracterizar e entender o estado atual do seu processo de software e fornece
informaes e recomendaes para facilitar as melhorias.
A avaliao realizada atravs de instrumentos que podem ser um
questionrio de avaliao ou um especialista (ou time de especialistas) que
avalia o estado das prticas, fazendo uso de entrevistas, observaes, ou
mesmo outros mtodos subjetivos; ou uma mistura deles. O instrumento de
avaliao

deve

competentemente.

ser

aplicado

em

um

contexto

prprio

usado

41

As avaliaes so realizadas seguindo metodologias, que tm como idia

principal identificar o status ou o nvel de maturidade do processo de software,
estabelecendo assim, as questes mais crticas a serem melhoradas. Uma vez
definido seu nvel na estrutura de maturidade, a organizao pode concentrarse nos itens que os permitam avanar para outro nvel. Logo, o resultado da
avaliao um rtulo com o nvel de maturidade do processo de software e
uma lista de aes recomendadas para melhorias. Em seguida, uma equipe de
gerncia estabelece uma estrutura para implementar as aes prioritrias
necessrias para melhorar o processo.
Estes nveis so conhecidos na engenharia de software como nveis de
maturidade,

onde

cada

nvel

indica

um

procedimento

gradativo

de

amadurecimento estabelecido pelo Instituto de Engenharia de Software (SEI

Software Engineering Institute). Para evitar que inconsistncias de termos de
nomenclatura, processo de avaliao e modo de implementao fossem
gerados, a Organizao Internacional de padres (ISO International
Organization Standardization) em conjunto com o SEI criaram o padro de
maturidade (Wallin, 2002).
A vantagem de se usar o padro ISO que as empresas, de modo geral,
procuram prestadores de servio que sejam certificados por esta organizao
internacional de padres e excluem fornecedores que no se preocupam em
certificar-se. Como resultado, empresas devem ter explcita a certificao ISO,
a fim de fornecer suas capacidades.
Validao
A avaliao inevitvel em qualquer plano de melhoria. absolutamente
necessrio saber a posio atual da organizao avaliada para identificar os
possveis problemas, ser capaz de propor aes de melhorias e medir os seus
efeitos. O termo validao considerado essencial e acaba sendo executada
antes da avaliao, mesmo que de forma Ad-hoc1.

Expresso em latim que quer dizer com este objetivo. Geralmente significa uma soluo designada
para um problema ou tarefa especfica, que no pode ser aplicada em outros casos. (Wikipedia, 2008).

42

Ejiogu (1993) afirma que a validao de um modelo significa provar que as

suas definies, atributos de comportamento e os postulados de funo
matemticas so corretos. Por necessidade um modelo s incorpora o que
acreditado ser importante e exclui o que no considerado importante. Ejiogu
(1993), ainda afirma que a validao pode ser feita por uma anlise de
correlao que tem como objetivo, calcular o grau de relao ou concordncia
entre dois ou mais objetivos do modelo.
Moor e Delugach (2006) apresentam uma definio aplicada a processos de
desenvolvimento de software. Segundo estes autores, para um processo de
desenvolvimento ser vlido, sua execuo deve ser coincidente com o modelo
proposto pelo processo. Ou seja, o modelo formal deve ser executado como
proposto, caso contrrio, o modelo possui pontos desnecessrios ou no
abrangentes o suficiente.
Cook e Wolf (1999) acreditam que a validao de um modelo formal de um
processo de software uma atividade para desenvolver evidncias
convincentes que o modelo pode ser seguido, isto , o modelo realmente
apresenta as etapas, atividades e procedimentos de interesse dos envolvidos
no desenvolvimento de software.

2.5 Anlise das tcnicas empregadas em processos de

desenvolvimento de software
Visando a melhoria nos processos de desenvolvimento de software, vrios
trabalhos vm sendo realizados com a idia central em medir, analisar e propor
mudanas nos processos de desenvolvimento. Alguns dos objetivos desses
trabalhos so: (1) minimizar o nmero de defeitos durante todo o processo de
desenvolvimento, (2) maximizar a eficcia e a confiabilidade do produto final e
(3) dimensionar adequadamente o esforo dedicado a atividades do projeto.
Nesta seo so apresentados dois trabalhos com o aspecto de melhoria de
processos e dois trabalhos com o foco em validar os processos.

43

Em Chmura et al. (1990), descrita uma tcnica de anlise de dados

levantados a partir de alteraes realizadas nos vrios artefatos do software ao
longo do processo de desenvolvimento. Segundo os autores, j existem
estudos com este objetivo, mas eles tentam coletar dados durante todo o
processo, o que gera um esforo adicional de 5 a 15% em um projeto. O
mtodo adotado por Chmura et al. (1990) analisa dados no fim de cada
iterao do processo, aproveitando dados j coletados pela prpria Gerncia
de Configurao do projeto.
Durante a anlise, gerado um documento conceitual, chamado de Formulrio
de Relatrio de Alteraes, o qual capaz de descrever as alteraes
realizadas na especificao e na implementao do projeto de forma textual.
Os formulrios so analisados para garantir um grau de confiabilidade,
evitando, por exemplo, duplicidades de relatrios, mltiplas informaes em um
mesmo formulrio ou ausncia de informaes fundamentais, como as que
indicam o tempo gasto e em que ponto do projeto as alteraes ocorreram.
Outra informao relevante se as alteraes so fruto de novas
implementaes ou correes.
Com os formulrios armazenados, informaes so levantadas e mostradas
atravs de grficos e tabelas. Com os grficos so verificadas, por exemplo, se
as alteraes ocorreram durante o projeto, em funes de testes eficientes ou
se as alteraes so realizadas depois que o produto foi entregue.
Outra pesquisa aplicada a processos de desenvolvimento apresentada por
Garg et al. (1993). Esta pesquisa tem com objetivo criar um processo
especfico para a criao de Kits de Desenvolvimento de Software (SDK).
Segundo os autores, atualmente o desenvolvimento de SDK restringido, pois
as organizaes de desenvolvimento de software precisam re-projetar seus
processos de desenvolvimento. Com este intuito os autores buscam a criao
de um processo e necessitam: (1) empiricamente validar o processo de
software proposto e (2) monitorar e aperfeioar tal processo.
Garg et al. (1993), define SDK como um conjunto de ferramentas de
desenvolvimento que permite os engenheiros de software criar aplicaes

44

como, por exemplo, jogos eletrnicos ou sistemas operacionais, substituindo o

grande esforo de codificao por operaes de customizao.
A fim de monitorar e aperfeioar tal processo, os estudos de Garg et al. (1993)
buscam avaliar informaes em cada iterao de um projeto, monitorando
todas as etapas para que possa ser obtido um entendimento completo do
processo sob estudo. Os dados so obtidos em entrevistas com os
participantes, que so conduzidas para capturar a histria do processo. Esta
histria analisada para determinar os pontos fortes e fracos do processo e os
resultados so apresentados a equipe de desenvolvimento. O histrico
capturado analisando quatro elementos, que so caracterizados por Garg et al.
como: (1) Agentes o pessoal envolvido no processo, assumindo seus
diferentes papeis, (2) Tarefas Primrias (P-Tasks) as atividades ou tarefas
planejadas que foram executadas no processo para realizar os objetivos, (3)
Tarefas de Articulao (A-Tasks) tarefas realizadas para consertar erros nas
P-Tasks e (4) Produtos o resultado das P-Tasks e A-Tasks.
Com o histrico capturado, o objetivo passa a ser analisar as informaes para
entender o que aconteceu durante o processo, utilizando-se de: (1) Anlise de
Objetivos, (2) Anlise de Tarefas e (3) Anlises de Participantes, que so
apresentadas em Garg et al. (1993). A primeira anlise avalia se os objetivos
dos agentes e das tarefas esto congruentes durante as etapas do processo.
Como hiptese, se os objetivos dos agentes no esto alinhados com os
objetivos da tarefa o trabalho no ser executado com sucesso. Na Anlise de
Tarefa so avaliados os atributos e relacionamentos das tarefas, por exemplo,
se a tarefa tem um nico agente responsvel, ou se a comunicao entre as
tarefas concorrentes e interdependentes ocorrem com sucesso. Na ltima
anlise, as opinies dos participantes e pontos importantes so levantadas
buscando um feedback com o intuito de melhorar o processo.
Baseado nestas anlises de histrico do processo, os autores relatam que
vrios problemas so encontrados e discutidos, entre eles o alinhamento dos
objetivos, as responsabilidades das tarefas e a sincronizao de tarefas
concorrentes resultando em melhorias a partir da primeira iterao do processo

45

em um projeto. Outros trabalhos relacionados melhoria de processos so

apresentados em Ferreira e Moita (2008 a) e Ferreira e Moita (2008 b).
Com o foco em validar um processo de desenvolvimento de software, pode-se
citar as pesquisas de Moor e Delugach (2006) e Cook e Wolf (1999). Seus
trabalhos tm como ponto em comum a comparao entre a execuo do
processo com o modelo formal proposto, mas o fazem de formas distintas.
Moor e Delugach (2006) apontam que, embora os modelos formais de
processo sejam importantes em fornecer uma orientao geral, eles so
raramente seguidos risca, ou seja, h uma diferena entre o modelo formal
do processo, que o modo normativo ou prescritivo, e as prticas, que so o
que realmente os envolvidos no projeto executam. Prticas permitem que a
equipe aprenda, inove, e lide com erros. Elas so, assim, uma parte essencial
do desenvolvimento do software, especialmente em um ambiente gil ou
distribudo, onde as incertezas e os erros necessitam ser tratados o tempo
todo.
Assim, a pesquisa destes autores foca em explorar as diferenas entre o
modelo formal do processo e a prtica, com o alvo de fornecer idias teis para
melhorar ambos os processos de engenharia de software e seus resultados
prticos, sendo essa comparao essencial para detectar, por exemplo, Qual
o tamanho da diferena?, Quanto significativamente a diferena?, Em
quais passos o processo de desenvolvimento ocorre? De acordo com qual
ponto de vista o processo est visvel? (Moor e Delugach, 2006).
Para que as diferenas sejam apontadas, Moor e Delugach (2006) adotam um
formalismo baseados na teoria de grfico conceitual, de forma que o modelo e
a prtica sejam representados e comparados. A Tabela 2.2 mostra o mtodo
criado por esses autores que tem como unidade bsica de anlise as
atividades pertencentes ao processo.

46
Tabela 2.2 Mtodo de validao de processos baseados em atividades.
(Fonte: Moor e Delugach, 2006)

Criar o padro de atividades para o modelo

Criar dois modelos
o Modelos podem ser o modelo prtico e o modelo do processo
o Identifique os passos dos modelos
o Construa modelos instanciando ou especializando padres de atividades
gerais para cada passo
Compare os modelos
o Identifique atividades nos modelos, e delimite passos em uma seqncia
o Compare os passos entre os modelos
o Crie a diferena de modo grfico
Interprete as diferenas entre os modelos
o Apresente as diferenas de forma grfica aos profissionais envolvidos no
processo
o Adapte o processo e/ou a prtica
o Execute as alteraes no programa

Cook e Wolf (1999) tambm compartilham da idia de que quando os modelos

de processo e as execues do processo divergem, alguma coisa significante
est acontecendo. Com essa idia em mente, eles desenvolveram sua prpria
tcnica para descobrir e medir as discrepncias entre modelos e execues,
que chamada pelos autores de Processo de Validao. Segundo Cook e
Wolf, a validao serve a vrios objetivos entre eles, garantir a confiana no
modelo do processo formal aumentando a confiana nos resultados.
O fundamento que a tcnica de Cook e Wolf utiliza uma viso de processos
como uma seqncia de aes executadas por agentes humanos ou
autmatos, ou seja, usam um modelo baseado em eventos de aes de
processo, onde um evento usado para caracterizar o comportamento
dinmico de um processo em termos identificveis. Esses eventos so tipados
e podem ter atributos como, por exemplo, o tempo em que ocorreu o evento,
itens como agentes e artefatos associados ao evento, os resultados tangveis
da ao, por exemplo, passar/falhar em uma reviso de projeto; erro/execuo
de uma compilao, e qualquer outra informao que d o carter ocorrncia
especfica daquele tipo de evento. Os eventos so extrados, por exemplo, de
sistemas de controle de verso e mensagens de compiladores. Os eventos no
computacionais so registrados manualmente.

47

A Figura 2.5 mostra o modelo conceitual do framework implementado por Cook

e Wolf (1999).. Observe que h uma distino entre o modelo formal do
processo e a execuo do processo, ou seja, existem dois universos de tipos
de eventos. Um universo o conjunto de tipos de evento associados com o
modelo de um processo, enquanto o outro o conjunto de tipos de evento
associados com a execuo do processo. O framework capaz de armazenar,
consultar e medir Stream2 de Eventos, que os autores classificam com
como uma
seqncia de eventos capturados em uma atividade.

Figura 2.5 Framework

mework de comparao de eventos (Fonte: Cook e Wolf, 1999).

O mtodo adotado por Cook e Wolf para medir as diferenas entre os streams
a Edio de String,, onde o nmero de inseres, delees e substituies
simblicas (tokens)) necessrias para transformar uma string em outra so
analisadas. Para mais detalhes sobre Edio de String consulte (Kruskal,
1983).
Uma investigao sobre validao de p
processos
rocessos mostra a existncia de poucos
trabalhos nesta rea. Ass poucas referncias encontradas (Cook
Cook e Wolf, Moor e
Delugach) adotam como princpio a comparao entre modelo e prtica, mas o
fazem de formas distintas, conforme mostrado acima, e no consideram
conside
questes como a eficincia e os resultados finais obtidos pelo processo.
Preocupao com a adaptabilidade destas tcnicas aos vrios ambientes de
desenvolvimento e a possibilidade de extenso das tcnicas no esto
2

Cook e Wolf (2006) implementam Streams atravs de vetores para armazenar os eventos capturados
pelo framework de validao.

48

presentes na literatura pesquisada. No foi encontrada documentao

publicada comprovando ou demonstrado a aplicabilidade das tcnicas de
validao em uma quantidade relevante de ambientes reais.
Apesar disto, a proposta de comparar o modelo formal do processo e sua
execuo, como defendida por Cook e Wold (1999) e Moor e Delugach (2006),
mostra-se capaz de produzir resultados interessantes para validar um
processo. Contudo, a utilizao de conceitos de teoria dos grafos ou edio de
string pode inviabilizar a validao de processos de desenvolvimento geis,
que pregam a flexibilidade e a facilidade de uso.
Processos como o PESC, apresentado na Seo 2.3, so criados com o intuito
de prover qualidade no desenvolvimento de software sem a aplicao de
grande quantidade de recursos humanos ou financeiros, e se a validao do
processo no seguir esse intuito, ela pode inviabilizar a utilizao do mesmo.
Dessa forma, nesta dissertao proposta uma nova abordagem para
comparar o modelo formal com a execuo do processo, adotando conceitos e
tcnicas de verificao e validao de software, para simplificar e dar
flexibilidade a esta comparao.

49

CAPTULO 3
VERIFICAO E VALIDAO DE SOFTWARE

Visando diminuir a complexidade e a subjetividade ao validar processos de

desenvolvimento, buscou-se embasamento terico na validao de software.
Este captulo apresenta uma viso geral de Verificao e Validao, analisando
os conceitos, diretrizes e tcnicas aplicadas em software para a utilizao dos
mesmos em processos de desenvolvimento.

3.1 Conceitos de Verificao & Validao

Softwares so amplamente utilizados para resolver problemas e tomar

decises. Os usurios passam a acreditar e a trabalhar nos resultados
apresentados por eles. Para isto, o software deve ser construdo atendendo s
especificaes do projeto e o produto final deve servir s necessidades reais
do usurio. A Verificao e a Validao, ou simplesmente V&V, tm
respectivamente estes interesses (Oberkampf e Trucano, 2007).
Em uma definio formal, Pressman (2006) afirma que Verificao se refere a
um conjunto de atividades que garantem que o software implementa
corretamente uma funo especfica e a Validao se refere a um conjunto de
atividades diferentes que garante que o software construdo corresponde aos
requisitos do cliente. Segundo o mesmo autor, a definio de V&V engloba
muitas das atividades que so abrangidas pela Garantia da Qualidade de
Software (SQA), como por exemplo: revises tcnicas formais, auditoria de
qualidade e configurao, monitoramento de desempenho, estudo de
viabilidade, reviso da documentao, entre outras.
Boehm (1981) faz a seguinte definio. Verificao: Estamos construindo certo
o produto? Validao: Estamos construindo o produto certo?. Wallin (2002) diz

50

que o propsito da verificao garantir que o componente de software ou

sistemas baseados nele cumpra suas especificaes e que o propsito da
validao demonstrar que um componente de software ou um sistema
customizado atinja o uso desejado em um ambiente desejado.
Pode-se notar que as definies acerca de Verificao e Validao so
semelhantes e servem ao mesmo propsito, mas a V&V pode ser executada de
diversas maneiras dependendo do campo de pesquisa. Ramos et al. (1999)
usa ferramentas de verificao baseados em mtodos formais para detectar
anomalias em bases de conhecimento de Sistemas Inteligentes. Wallin (2002)
faz uso de tcnicas de Inspees de Software e Testes de Caixa Branca e
Caixa Preta em sistemas comerciais. Pressman ressalta que:
[...] h uma forte divergncia de opinio sobre que tipos de teste constituem
validao. Algumas pessoas acreditam que todo teste verificao e que
validao conduzida quando requisitos so revisados e aprovados, e
posteriormente, pelo usurio, quando o sistema estiver operacional. Outras
pessoas consideram teste unitrio e de integrao como verificao e testes de
alta ordem como validao (PRESSMAN, 2006).

John e Steve (2000) destacam, em um estudo de caso realizado na

Administrao Nacional de Aeronutica e Espao Norte Americana (NASA),
que o uso de V&V um dos fatores para garantir a qualidade de software em
sistemas desenvolvidos por meio do Desenvolvimento de Aplicaes Rpidas
(RAD). A questo usufruir das vantagens desse desenvolvimento, como a
alta produtividade e o baixo custo, sem que os problemas levantados no estudo
comprometam tais vantagens. Neste caso, a V&V fornece anlises teis ao
grupo de projeto em uma contnua tarefa para monitorar a co-evoluo das
ferramentas CASE usadas e analisa os diferentes cdigos gerados de acordo
com a verso das ferramentas.
Pode-se citar tambm o uso de V&V em Wallin (2002), o qual ressalta o
sucesso e as vantagens do desenvolvimento de softwares baseado em
componentes e diz que esta tecnologia requer, entre outras coisas, que o
componente usado tenha alta funcionalidade, qualidade e que seja bem
documentado, o que obtido por organizaes de software maduras com alta
qualidade, fazendo uso de um processo que previnam problemas por meio da
Verificao & Validao.

51

A V&V pode se relacionar com o processo de desenvolvimento de diversas

maneiras. A literatura trata essa forma de relacionamento como paradigma.
Cada paradigma dita quais atividades e em que momento elas sero aplicadas.
A especificao dos documentos ou artefatos de entrada e a apresentao dos
resultados tambm so definidas. A Figura 3.1 mostra o paradigma de V&V
apresentado pelo Manual de Engenharia de Sistemas (NAS, 2006) e sumariza
as atividades de V&V da seguinte forma:
1. Os Documentos de requisitos do sistema alimentam a validao.
Durante as atividades de validao, uma tabela de validao criada.
2. Com os requisitos validados, a Tabela de Validao torna-se a base
para as atividades de Verificao. Nesse momento as atividades de
planejamento da Verificao so iniciadas e o documento chamado de
Planos de Verificao Principal (MVP) criado e ser atualizada durante
todo o ciclo de desenvolvimento.
3. As tcnicas de verificao so especificadas para analisar cada requisito
descrito na Tabela de Validao. Neste momento, um documento
chamado Matriz de Responsabilidade de Verificao criado (VRTM).
4. Depois que as atividades de verificao so concludas, o VRTM
atualizado e o Documento de Cumprimento de Verificao dos
Requisitos (RVCD) criado para registrar a realizao dos esforos de
verificao.
Validao

Requisitos do Sistema
Tabela de
Validao

Validao

Documento
de
Requisitos

Especificao
da
Verificao

1
Documento
de
Requisitos

Planejamento
Tcnico

Verificao
Requisitos do Sistema

VRTM

MVP

4
MVP

Verificao

Figura 3.1 Atividades de Verificao e Validao (Adaptada de NAS, 2006).

52

Como mostra a Figura 3.2, o modelo proposto pelo Manual de Engenharia de

Sistemas aplica Verificao e Validao durante todo o processo de
desenvolvimento de software. Esse modelo prope que a V&V seja aplicada
incrementalmente sob todos os requisitos durante o ciclo de desenvolvimento,
seguindo a evoluo natural e hierrquica da criao de software. Assim,
quando cada incremento de requisitos levantado e desenvolvido, eles sofrem
Validao e Verificao.

Figura 3.2 Diagrama em V da Engenharia de Sistemas (Adaptada de NAS, 2006).

Ainda sobre a Figura 3.2, fica claro que o modelo proposto em NAS (2006) tem
dois momentos distintos na aplicao de V&V, onde a validao aplicada s
fases iniciais e a verificao aplicada no decorrer do ciclo de
desenvolvimento. Alguns autores como Sargent (2000) e Balci (1994) propem
a aplicao de Validao em outras fases do desenvolvimento, criando uma
maior evidncia que o produto final est correto e que atende as necessidades
do usurio. A Figura 3.3 mostra um paradigma clssico de V&V, onde fica claro
que alm da validao da especificao ou do modelo conceitual, existem as
atividades de validao operacional e dos dados.

53

Entidade
Problema
Validao
do Modelo
Conceitual

Validao
Operacional
Experimentao

Anlise e
Modelagem

Validade
de Dados
Modelo
Computacional

Implementao

Modelo
Conceitual

Verificao do
Modelo
Computacional
Figura 3.3 Modelo clssico de V&V (Adaptada de Sargent, 2000).

Sargent (2000) descreve este modelo como: A Entidade Problema um

sistema (real ou proposto) de uma idia, uma situao, uma poltica, ou um
fenmeno a ser modelado; o Modelo Conceitual a representao
matemtica/lgica/verbal da Entidade Problema desenvolvida por um estudo
particular; e o Modelo Computacional o Modelo Conceitual implementado
em um computador. O modelo conceitual desenvolvido por meio de uma
etapa de Anlise e Modelagem. O Modelo Computacional desenvolvido com
o uso de um compilador na fase de Implementao. Logo, inferncias sobre o
problema so obtidas por experimentos de computador aplicados ao Modelo
Computacional na fase de Experimentos.
Na Figura 3.3 pode-se notar que o Modelo Conceitual passa por uma fase de
Validao. Na qual se assume que a conceitualizao est correta e que o
modelo representacional do problema est razovel3 para o uso pretendido.
Nota-se tambm que o Modelo Computacional passa pela fase de Verificao,
a qual garante que o programa de computador implementado est correto. Na
Validao Operacional definido como ser garantido que o comportamento
3

Segundo Balci (1995), a exatido dos resultados julgada de acordo com os objetivos do estudo, por
exemplo, em alguns casos 60% de exatido suficiente, em outros casos so exigidos 95%.

54

das sadas do modelo ter a exatido desejada. neste ponto onde muitos dos
testes de validao ocorrem, sendo possvel encontrar diferenas e apurar em
quais das etapas do modelo apresentam falhas. Na Validade dos Dados
definido como garantir que os dados necessrios para a construo e avaliao
do software so adequados e corretos. importante ressaltar que esse
paradigma, apresentado na Figura 3.3, aplicado durante todo o ciclo de
desenvolvimento de forma iterativa. Vrias verses de softwares so criadas e
melhoradas at que se obtenha um produto que satisfaa a exatido
pretendida.
Os paradigmas apresentados por NAS (2006) e Sargent (2001) mostram
pontos em comuns e algumas dissonncias. Este fato comum entre os
diversos paradigmas e pode ser percebido em outros trabalhos como Banks et
al. (1988) e Knepell e Arangno (1993). Mas, independente das diferenas,
todos os paradigmas exigem que uma equipe de profissionais conduza as
atividades de verificao e validao.
Sargent (2001) aponta quatro formas diferentes ao se aplicar V&V em relao
equipe envolvida:
1. A prpria equipe de desenvolvimento toma as decises de como o
software vlido. Estas decises so subjetivas e feitas baseadas nos
resultados de vrios testes e avaliaes conduzidas como parte do
processo de desenvolvimento do modelo.
2. Outro mtodo ter os usurios do modelo fortemente envolvidos com o
time de desenvolvimento para determinar a validade do modelo de
simulao. Neste mtodo, o foco de quem determina a validade do
software

deve

mudar

dos

desenvolvedores

para

os

usurios,

melhorando assim a credibilidade.

3. O prximo mtodo conhecido como Verificao e Validao
Independente (IV&V), onde uma empresa ou equipe independente dos
desenvolvedores e dos usurios do software iro valid-lo. Este um
mtodo aplicado quando existem vrias equipes de desenvolvimento
envolvidas no projeto e com desenvolvimento de sistemas em larga
escala. importante ressaltar que este mtodo envolve um custo

55

elevado e que pode ser feito de duas maneiras: de modo concorrente

com o desenvolvimento do projeto ou quando o projeto estiver
implementado ou concludo.
4. O Modelo de Pontos o ltimo mtodo apresentado por Sargent para
determinar se um modelo vlido. Pontos (ou pesos) so determinados
subjetivamente sobre as questes referentes ao processo de validao.
Um modelo de sistema considerado vlido se o total geral dos pontos
adquiridos de acordo com cada questo ultrapassarem a nota mnima,
mas, segundo o prprio Sargent, este mtodo raramente utilizado na
prtica.

3.2 Tcnicas de Verificao & Validao

Como dito anteriormente, a literatura prope diversos paradigmas que se
diferem uns dos outros pela forma de interao com o processo de
desenvolvimento. Mas, apesar das diferenas, esses paradigmas utilizam
tcnicas comuns para realizar as atividades de Verificao e de Validao.
Alguns autores (Balci, 1994 e Nance, 1994) descrevem essas tcnicas como
Tcnicas de Testes e afirmam que elas tm o propsito de demonstrar a
inexatido e a existncia de erros no software. Logo, alguns testes so
conduzidos sob o modelo conceitual e outros sob o modelo computacional,
durante todo o ciclo de vida de desenvolvimento do sistema proposto.
A Tabela 3.1 mostra uma taxonomia apresentada em Balci (1995), a qual
categoriza as tcnicas de V&V em seis perspectivas. O nvel de formalismo
matemtico de cada categoria aumenta de muito informal na primeira linha de
classificao da tabela, a muito formal na ultima linha, implicando tambm no
aumento da complexidade.

56
Tabela 3.1 Taxonomia de Tcnicas de Verificao & Validao (Fonte: Balci, 1995).
Tcnicas de Verificao & Validao e Testes
Tcnicas
Auditoria, Validao de Face, Inspees, Revises, Teste de Turing,
Walkthroughs
Checagem de Inconsistncia, Anlise de Fluxo de Dados, Anlise Baseada
em Grafos, Anlise Semntica, Analise Estrutural, Anlise Sinttica
Teste de Caixa Branca, Teste Button-Up, Monitorao de Execuo,
Execuo de Perfil, Execuo de Trao, Testes de Campo, Comparao
Grfica, Validao Preditiva, Teste de Regresso, Anlise Sensitiva,
Tcnicas Estatsticas, Teste de estresse, Testes de Sub-Modelo, Debug
Simblico, Teste Top-down, Visualizao, Teste de Caixa Branca
Grfico de Causa Efeito, Anlise de Partio, Anlise de Caminhos,
Execuo Simblica
Checagem de Suposies, Anlise de Limites, Suposio Indutiva
Induo, Inferncia, Deduo Lgica, Clculos Preditivos, Transformao
Preditiva, Prova de Exatido

Classificao
Informal
Esttica
Dinmica

Simblica
Restries
Formal

Segundo Balci (1995), as tcnicas informais de V&V esto entre as mais

usadas. So chamadas informais porque as ferramentas e mtodos usados
confiam pesadamente no raciocnio e na subjetividade humana sem
formalismos matemticos estritos. O rtulo "informal" no implica em qualquer
falta de estrutura ou diretrizes formais para o uso das tcnicas.
As tcnicas estticas so aplicadas no cdigo fonte dos sistemas sem exigir a
execuo do mesmo. O compilador da linguagem utilizada no desenvolvimento
do software um exemplo de ferramenta esttica. J as tcnicas dinmicas
requerem

execuo

do

sistema

tendo

como

funo

avaliar

seu

comportamento.
As tcnicas simblicas tambm avaliam o comportamento dinmico do sistema
fornecendo entradas simblicas e expresses so produzidas como resultado
da transformao dos dados simblicos durante o caminho de execuo do
software. As tcnicas de restries de V&V so empregadas para avaliar a
exatido do modelo usando afirmao de checagem, anlise do limite, e
afirmaes indutivas.
Por ltimo, as tcnicas formais de V&V so baseadas na prova formal
matemtica de exatido. Segundo Balci (1995), se atingvel, esse tipo de prova
o meio mais eficaz, mas estas tcnicas, e principalmente as tcnicas

57

baseadas em testes estatsticos, necessitam de um nmero muito grande de

ponto de dados. Portanto, mesmo quando as hipteses so observveis e
satisfeitas, os testes estatsticos so considerados significativos somente se o
volume de dados for suficiente. E que em alguns casos impraticvel do ponto
de vista financeiro.

3.3 Anlise das Tcnicas Informais

Esta seo apresenta uma anlise mais detalhada das tcnicas informais.
Tcnicas s quais tm a caracterstica de serem aplicadas a todo o ciclo de
desenvolvimento do software de forma metdica e simples, analisando os
artefatos e atividades de todas as etapas de um processo de software (Balci,
1995). Esta caracterstica importante para este trabalho, pois a validao de
um processo no pode ser feita analisando somente uma etapa ou mesmo um
nico artefato, e sim o processo de desenvolvimento como um todo.
Abaixo so descritas seis tcnicas informais comumente usadas na verificao
e validao de software. A descrio de cada tcnica apresentada
separadamente nas Tabelas 3.2 3.7 para auxiliar na escolha da tcnica ou
tcnicas que podem vir a ser usadas na validao de processos.
Tabela 3.2 Caractersticas da tcnica de Desk-Checking. (Fonte: Perry, 1995).
Nome: Reviso de Mesa (Desk-Checking),
Tipo:
Manual Automtica
Dinmica

Esttica

Estrutural

Funcional

Descrio: Desk checking o meio mais tradicional de anlise de um software. Essa tcnica
conduzida pelo prprio analista ou programador. O processo envolve uma reviso completa
do produto para garantir que ele est estruturalmente correto e que os padres e requisitos
foram obtidos.
Sugesto de Utilizao: Realizar Desk Cheking normalmente uma parte integral de projeto e
da codificao. Essa tcnica requer que o desenvolvedor valide a forma de trabalhar do
produto desenvolvido de acordo com os requisitos. O processo envolve uma avaliao passo a
passo do produto final. Vrios testes individuais so usados como base para conduzir esta
avaliao.
Custo de Uso: Desk Cheking executada por um indivduo completamente informado dos
requisitos do produto.
Habilidades para Uso: As habilidades necessrias para utilizar essa tcnica so as mesmas
necessrias para desenvolver o produto analisado.
Vantagens: Fornece uma checagem redundante na validao do produto desenvolvido.
Desvantagens: freqentemente difcil para o indivduo que desenvolveu o produto
identificar os defeitos.

58
Tabela 3.3 Caractersticas da tcnica de Peer-Review. (Fonte: Perry, 1995).
Nome: Reviso por Pares4 (Peer-Review)
Tipo:
Manual Automtica
Dinmica

Esttica

Estrutural

Funcional

Descrio: A reviso por pares uma anlise em dupla aonde os envolvidos realizam as
mesmas funes durante a reviso. Por exemplo, os analistas de sistemas revisando as
especificaes do projeto e os programadores revisando os cdigos fontes. Esse tipo de
reviso pode ser conduzida por uma ou mais duplas. A reviso normalmente conduzida
observando a eficincia, estilo e aderncia aos padres.
Sugesto de Utilizao: O uso de reviso em pares deve ser um processo formal e empregado
a todo setor de desenvolvimento de software. Quando essa tcnica usada, todos os
sistemas devem ser sujeitos s revises e no apenas selecionando um projeto. Os pares
devem receber diretrizes durante as revises para garantir sua consistncia. Geralmente, os
relatrios formais no esto preparados ao final da reviso em pares, mas os resultados so
enviados diretamente ao desenvolvedor.
Custo de Uso: Reviso em pares um trabalho intensivo em que o custo depende do nmero
de pares conduzindo a reviso e do escopo das revises. Normalmente ela uma tcnica de
custo mdio.
Habilidades para Uso: Os pares que conduzem a reviso devem ser instrudos em como
conduzir essas revises e os indivduos que formam as duplas devem ter o mesmo nvel de
conhecimento sobre os principais tpicos.
Vantagens: Reviso em pares aplica uma dupla anlise para garantir um produto de
qualidade. Freqentemente, essa anlise em dupla pode incentivar os membros da equipe
quando no existe um supervisor.
Desvantagens: Membros dos pares podem ser relutantes em criticar outras duplas, ou faz-lo
em excesso, o que pode causar ressentimento dentro das equipes.

O termo Pares pode ter o sentido de pessoas com funes semelhantes

59

Tabela 3.4 Caractersticas da tcnica de Design Review (Fonte: Perry, 1995)

Nome: Revises de Projetos (Design Review)
Tipo:
Manual Automtica
Dinmica

Esttica

Estrutural

Funcional

Descrio: Reviso de projetos comumente realizada em muito dos diferentes estgios do

desenvolvimento de software. Revises formais freqentemente ocorrem perto da concluso
dos requisitos do sistema, do projeto do sistema, do projeto preliminar, do projeto de
codificao, da programao, e na concluso dos testes. A Reviso freqentemente
direcionada mais para o projeto do que o produto.
Sugesto de Utilizao: O processo de reviso de projeto pode ser parte da metodologia do
projeto de sistema. Muitas metodologias formais incluem a reviso de projeto como uma
parte integral do processo. Algumas metodologias recomendam que a reviso de projeto seja
conduzida pelo pessoal da garantia da qualidade. Freqentemente as revises incluem
checklist formalizados para garantir que todos os passos da metodologia foram realizados
Custo de Uso: Reviso de projetos so revises de trabalho intensivo e o custo depende do
tamanho do time de reviso e do tamanho da reviso. As revises so normalmente limitadas
em escopo, logo o custo mdio.
Habilidades para Uso: O time de reviso de projeto necessita ter habilidade no processo de
reviso de projetos e deve ter habilidades em projetos de sistemas
Vantagens: O uso de revises de projeto so normalmente necessrias para garantir a
confiana e o entendimento do desenvolvimento do sistema e da metodologia de
manuteno.
Desvantagens: As revises de projeto geralmente no so necessrias quando os
desenvolvedores tm grande conhecimento da metodologia de projeto e so fornecidos
recursos adequados para que eles possam seguir completamente a metodologia.

60

Tabela 3.5 Caractersticas da tcnica de Auditoria (Fonte: Perry, 1995).

Nome: Auditoria
Tipo:
Manual Automtica

Dinmica

Esttica

Estrutural

Funcional

Descrio: Auditoria de Software um tipo de reviso no qual um ou mais auditores que no

so membros da organizao responsvel pelo desenvolvimento do produto examinam de
forma independente o software garantido um alto grau de confiana nas especificaes,
padres e relatrios.
Sugesto de Utilizao: A Auditoria deve ser independente, realizada sob um ponto de visa
tico e com o devido cuidado profissional. Seguindo um planejamento, onde o objetivo e
escopo traado. Logo em seguida a auditoria realizada utilizando-se de checklists e
questionrios aplicados em reunies com os envolvidos no processo. Na auditoria, as
conformidades, oportunidades de melhorias e boas prticas so levantadas e apresentadas.
Custo de Uso: Auditoria uma tarefa de trabalho intensivo envolvendo a participao de
terceiros. Ou seja, uma equipe com experincia em auditoria deve ser contratada para
manter a independncia das avaliaes implicando em um custo elevado.
Habilidades para Uso: Os auditores de software necessitam ter habilidade em auditoria
executando boas praticas como motivar a identificao de problemas e no atacar pessoas e
sim fatos concretos, alm de possuir um conhecimento em processos e desenvolvimento de
software.
Vantagens: Auditoria de software fornece uma avaliao independente das conformidades do
software
Desvantagens: Auditores tendem a ficar defasados tecnologicamente em relao ao
ambiente computacional da organizao devido crescente complexidade do ambiente
computacional. Tornando-se difcil encontrar auditores experientes.

61

Tabela 3.6 Caractersticas da tcnica de Walkthrough (Fonte: Perry, 1995).

Nome: Walkthrough
Tipo:
Manual Automtica

Dinmica

Esttica

Estrutural

Funcional

Descrio: Durante o Walkthrough, o criador de um produto, ou o lder da equipe repassa ou

faz uma checagem desse produto, atravs de uma simulao manual do sistema usando
dados de testes. Os dados de testes devem ser simples, considerando os constrangimentos da
simulao humana. A equipe deve fazer perguntas e levantar questes sobre o produto que
pode identificar defeitos.
Sugesto de Utilizao: Walkthroughs so uma evoluo da tcnica de Desk Checking. Eles
usam um mtodo em equipe, onde essa equipe normalmente composta de vrios peritos
sobre o assunto em questo, sobre analise de sistemas e testes. Diretrizes gerais devem ser
estabelecidas em como conduzir a anlise e os participantes devem ser treinados nesses
procedimentos. geralmente aconselhvel para o time responsvel em executar essa funo
aconselhe o desenvolvedor sobre pontos especficos que ele deve cobrir durante a avaliao.
Custo de Uso: Walkthrough um processo de uso intensivo de pessoas com o custo variando
de acordo com o nmero de participantes, da equipe e do tamanho do projeto analisado. Mas
normalmente classificado como tendo um custo mdio no sendo considerado nem alto
nem baixo.
Habilidades para Uso: Em avaliaes de especificaes de alto-nvel requer habilidades de
usurio do sistema e para avaliaes de baixo-nvel requer habilidades de programadores
Vantagens: Walkthrough fornece uma base para questionar a lgica do programador e ajudar
o desenvolvedor a identificar problemas no sistema.
Desvantagens: relativamente desestruturado, fazendo com que sua eficincia seja
dependente da habilidade e do interesse da equipe envolvida.

62

Tabela 3.7 Caractersticas da tcnica de Inspees (Fonte: Perry, 1995)

Nome: Inspees
Tipo:
Manual Automtica

Dinmica

Esttica

Estrutural

Funcional

Descrio: As inspees so revises formalizadas que usa pessoal alm do desenvolvedor

para avaliar a exatido de um produto. O produto verificado contra critrios de entrada
predeterminados ou contra as especificaes que foram usadas para construir o produto. O
processo necessita de uma reviso minuciosa da especificao de entrada e do produto, por
pessoas competentes que foram reunidos para formar uma equipe de inspeo.
Sugesto de Utilizao: As inspees necessitam de uma equipe de inspeo treinada e uma
lista predeterminada de critrios ou especificaes de entrada anteriormente verificadas que
formam a base da inspeo. A equipe de inspeo normalmente inclui um moderador, em
conjunto com representantes de pares de vrios grupos. A eficcia do processo de inspeo
depende da habilidade da equipe, o tempo de preparao gasto, e a escolha dos critrios de
inspeo.
Custo de Uso: As inspees so um processo de trabalho intensivo, com o preo dependendo
do tamanho da equipe e a profundidade da inspeo. Geralmente ela tem um alto preo.
Habilidades para Uso: As inspees necessitam uma equipe com conhecimento no processo
de inspeo e do processo usado para produzir o produto que inspecionado (isto ,
codificao, anlise e projeto). Contudo, as inspees no necessitam de conhecimento
detalhado da aplicao que inspecionada.
Vantagens: As inspees so um processo formalizado de avaliar sistemas. O processo
estruturado fornece uma alta probabilidade para descobrir problemas.
Desvantagens: As inspees so muito detalhistas, o processo consome tempo olhando cada
componente de um sistema. Mas por causa da eficcia, os analistas e os programadores
confiam pesadamente nas inspees.

As tabelas apresentadas nesta seo com as tcnicas de validao contm

classificaes de tipos com o propsito de orientar o leitor a escolher a tcnica
adequada. Esses tipos so explicados por Perry (1995) como a seguir:

Avaliaes Estruturais versus Funcionais O conjunto de testes

baseados na anlise estrutural tende a descobrir erros que ocorrem
durante "a codificao" do programa, enquanto o conjunto de testes com
base na anlise funcional tende, a descobrir erros que ocorrem no
levantamento de requisitos ou especificaes de projetos. Ou seja, o
teste funcional assegura que as exigncias sejam propriamente
satisfeitas na aplicao do sistema.

Avaliaes Dinmicas versus Estticas A anlise dinmica necessita

que o programa seja utilizado. Isto , o programa executado sob
alguns casos de teste e os resultados da execuo do programa so
examinados para verificar se ele funcionou como esperado. A anlise

63

esttica no implica normalmente na execuo do programa real. As

tcnicas de anlise estticas comuns incluem tarefas como verificao
de sintaxe.

Avaliaes Automticas versus Manuais As tcnicas manuais so

executadas por uma equipe e as tcnicas automatizadas pelo
computador. Quanto mais automatizado o processo de desenvolvido,
mais fcil fica para automatizar o processo de teste. Por outro lado, se a
equipe executa a anlise, a documentao, e o desenvolvimento de
forma manual, os testes no podem ser automatizados.

3.4 Conceitos de Inspeo de Software

A inspeo de software uma importante tcnica de V&V. Segundo Somerville

(2007 p.358), atravs de inspees pode-se analisar as representaes do
sistema como documentos de requisitos, diagramas de projeto e o cdigo fonte
do programa. As inspees podem ser aplicadas em todos os estgios do
processo e no necessitam que o software seja executado. Se aplicada ao
modelo conceitual, a inspeo considerada como uma tcnica de validao.
Mas, se a tcnica aplicada sob o cdigo fonte, ela toma o foco de verificao.
Somerville (2007 p.363) afirma que erros podem ser encontrados de um modo
mais barato, por meio da inspeo, do que com extensivos programas de
testes. Isso foi demonstrado em um experimento feito por Gilb e Graham
(1993), que empiricamente compararam a eficcia das inspees.
As tcnicas de inspees de software tm como principal objetivo encontrar
erros. Para tanto, as tcnicas de inspees adotam como padro a taxonomia
de classificao de erros apresentadas pelo Instituto de Engenheiros
Eletricistas e Eletrnicos (IEEE 830, 1998). Ela define atributos de qualidade
para requisitos de software e a falta de qualquer um desses atributos
constituiria um tipo de defeito (Shull, 1998). Assim, os tipos so:

64

Omisso (1) Algum requisito importante relacionado funcionalidade,

ao desempenho, s restries de projeto, ao atributo, ou interface
externa no foi includo; (2) no est definida a resposta do software
para todas as possveis situaes de entrada de dados; (3) faltam
sees na especificao de requisitos; (4) faltam referncias de figuras,
tabelas, e diagramas; (5) falta definio de termos e unidades de
medidas.

Ambigidade Um requisito tem vrias interpretaes devido a

diferentes termos utilizados para uma mesma caracterstica ou vrios
significados de um termo para um contexto em particular.

Inconsistncia Dois ou mais requisitos so conflitantes

Fato Incorreto Um requisito descreve um fato que no verdadeiro,

considerando as condies solicitadas para o sistema.

Informao Estranha As informaes fornecidas no requisito no so

necessrias ou mesmo usadas.

Outros Outros defeitos como a incluso de um requisito numa seo

errada do documento.

3.4.1 Benefcios da Inspeo de Software

De acordo com Biffl e Grossmann (2001), o esforo gasto por organizaes de
software com retrabalho varia em mdia entre 40% e 50% do esforo total do
desenvolvimento de um projeto. Uma estimativa da distribuio do retrabalho
pelas atividades de desenvolvimento de software feita por Wheeler et al. (1996)
est ilustrada na Figura 3.4.1.

65
Figura 3.4.1 Redistribuio do retrabalho pelas atividades de desenvolvimento de
software. (Adaptado de Wheeler et al., 1996).

Analisando a figura acima, possvel verificar que o retrabalho tende a

aumentar na medida em que o desenvolvimento progride. Uma das razes
para isto o aumento no esforo para corrigir defeitos nas atividades finais do
processo de desenvolvimento. Atravs da anlise de 63 projetos, Boehm
(1981) apresenta o custo relativo da correo de defeitos encontrados em cada
uma das atividades de desenvolvimento (Figura 3.4.2).

Figura 3.4.2 Custo relativo para corrigir um defeito (Adaptado de Boehm, 1981).

Assim, um dos maiores benefcios de se utilizar inspees de software a

deteco de defeitos nas fases iniciais do processo de desenvolvimento de
software, facilitando a correo destes defeitos com menor esforo e custo.
Desta forma, de acordo com Jones (1991), o esforo com retrabalho reduzido
em mdia para 10% a 20% do esforo total de desenvolvimento. Esta reduo
no retrabalho pode implicar em melhorias significativas para a produtividade de
software. Laitenberger e Atkinson (1999) e Gilb e Graham (1993) afirmam em
suas pesquisas que alm da reduo do esforo com retrabalho, a
produtividade, o tempo de projeto e o custo so reduzidos significantemente.
De acordo com Kalinowski (2004) a aplicao de inspees de forma bem
planejada pode trazer diversos outros benefcios. Dentre eles se encontram:

Aprendizado Inspetores experientes podem tentar detectar padres de

como os defeitos ocorrem e definir diretrizes que ajudem na deteco
destes. Alm disto, bons padres de desenvolvimento podem ser

66

observados durante a inspeo, sendo possvel sua descrio como

melhores prticas para a organizao.

Integrao entre processos de deteco e de preveno de defeitos

Saber onde e quando os defeitos ocorrem pode ajudar a estabelecer
planos de contingncia que evitem a sua ocorrncia.

Produtos mais inteligveis Os autores dos diversos artefatos, sabendo

que estes sero inspecionados, passaro a produzir artefatos de uma
forma que sua compreenso seja facilitada. A produo de artefatos
mais inteligveis, alm de facilitar a inspeo, trar benefcios para as
fases

seguintes

do

processo

de

desenvolvimento,

incluindo

principalmente a fase de manuteno.

Dados defeituosos ajudam a melhorar o processo de software do projeto

Analisando a causa dos defeitos encontrados possvel fazer ajustes
no processo para evitar a ocorrncia de defeitos deste mesmo tipo.

3.4.2 O Processo de Inspeo de Software

Fagan (1976) desenvolveu o processo tradicional de inspeo de software.
Esse processo largamente utilizado e serve como base para vrios outros
processos de inspees propostos. A Figura 3.4.3 ilustra o processo de Fagan.
Neste processo, existem cinco atividades principais:

Planejamento Um usurio, desempenhando o papel de moderador da

inspeo, define o contexto da inspeo (descrio da inspeo, tcnica
a ser utilizada na deteco de defeitos, documentos a serem
inspecionados, autor do documento, entre outros), seleciona os
inspetores e distribui o material a ser inspecionado.

Preparao Os inspetores estudam os artefatos individualmente, e

eventualmente, fazem anotaes sobre estes, produzindo uma lista de
discrepncias. O fornecimento de tcnicas de leitura pode facilitar a
execuo desta tarefa.

Reunio Uma reunio em equipe ocorre, envolvendo o moderador, os

inspetores e os autores do documento. Discrepncias so discutidas e
classificadas como defeito ou falso positivo. A deciso final sobre a
classificao de uma discrepncia sendo discutida do moderador. A

67

soluo dos defeitos no discutida durante a reunio, que no deve

exceder duas horas, uma vez
vez que aps este tempo a concentrao e a
capacidade de anlise dos inspetores costuma reduzir drasticamente.
No caso em que uma reunio precisar de mais de duas horas,
sugerido que o trabalho de inspeo continue no prximo dia.

Retrabalho O autor cor

corrige
rige os defeitos encontrados pelos inspetores e
confirmados pelo moderador.

Continuao O material corrigido pelos autores repassado para o

moderador, que faz uma anlise da inspeo como um todo e re
re-avalia a
qualidade do artefato inspecionado. Ele tem
tem a liberdade de decidir se
uma nova inspeo deve ocorrer ou no.

Figura 3.4.3 Processo de inspeo de software (Fonte: Fagan, 1976)

Kalinowski (2004) mostra que outros processos vm sendo

o propostos como o
processo de Humphrey (1989),
1989), que muda o foco da atividade de preparao
individual, pois, ao invs de entender o artefato a ser inspecionado,
inspecionado o inspetor
tenta encontrar defeitos. Assim, cada um dos inspetores entrega uma lista de
discrepncias para o moderador da inspeo antes da reunio de inspeo se
iniciar. O objetivo da reunio passa ento a ser discutir as discrepncias
encontradas e classific-las
las como defeito ou falso positivo.
Seguindo a idia de Humphrey, Johnson (1994) introduz o conceito de Reunio
Assncrona,, ou seja, um moderador pode se
e reunir apenas com o nmero de
inspetores que a anlise
lise do artefato necessita, no mobilizando assim toda a

68

equipe de inspeo. Segundo o autor, ao se evitar reunies, custos e conflitos

de alocao de recurso so reduzidos sem sacrificar a eficincia das
inspees. O processo proposto por Johnson composto das fases de
planejamento, apresentao, reviso particular e reviso pblica.
A deteco de defeitos propriamente dita comea na fase de Reviso
Particular. Os revisores podem cadastrar pontos de dvida, requisitar que
alguma ao seja tomada ou simplesmente tecer um comentrio. Somente os
comentrios estaro visveis para os demais revisores. Entretanto, o
moderador tem acesso a todos estes registros, o que lhe permite monitorar o
progresso das revises particulares.
Na fase de Reviso Pblica todos os registros (dvidas, aes e comentrios)
so visveis aos inspetores que podem votar (concordncia, discordncia ou
neutralidade) de forma assncrona ou gerar novos registros. A fase s se
encerra quando todos os registros estiverem estabilizados.
Sauer et al. (2000) usa das idias de Humphrey e Johnson e prope uma
reestruturao do modelo tradicional de Fagan, adicionando suporte a reunies
assncronas com equipes geograficamente separadas. A idia de Sauer et al.,
manter a estrutura rgida e os aspectos colaborativos do processo tradicional
e substituir as atividades de preparao e de reunio do processo tradicional
por trs novas atividades seqenciais: deteco de defeitos, coleo de
defeitos e discriminao de defeitos. Estas atividades podem ser descritas da
seguinte forma:

Deteco de Defeitos Cada um dos inspetores selecionados pelo

moderador no planejamento realizar uma atividade de deteco de
defeitos. A principal tarefa desta atividade consiste em buscar defeitos
no documento a ser inspecionado e assim produzir uma lista de
discrepncias.

Coleo de Defeitos O moderador agrupa as listas de discrepncias

dos inspetores. Esta atividade envolve eliminar discrepncias repetidas
(encontradas por mais de um inspetor), mantendo s um registro para
cada discrepncia.

69

Discriminao de Defeitos O moderador, o autor do documento e os

inspetores discutem as discrepncias de forma assncrona. Durante esta
discusso, algumas discrepncias sero classificadas como falso
positivo e outras como defeito. Os falsos positivos sero descartados e
os defeitos sero registrados em uma lista de defeitos, que ento ser
passada para o autor para que a correo possa ocorrer.

Segundo Sauer et al. (2000), este processo mais eficiente no que se diz
respeito ao tempo, pois os inspetores trabalham em paralelo e discrepncias
encontradas por mais de um inspetor vo direto para a fase de retrabalho e as
discrepncias encontradas por um inspetor no precisa ser discutida com todos
os outros inspetores. A Figura 3.4.4 mostra o processo proposto.

Figura 3.4.4 Processo de Inspeo de Software Assncrono (Fonte: Sauer et al.,

2000).

Visando utilizar a Inspeo de Software na prtica de forma mais sistemtica

fazendo uso do modelo sugerido por Sauer et al. (2000), alguns autores prope
o uso de apoio ferramental, dentre estes autores pode-se citar o trabalho de
Travassos et al. (2007) e Lanubile et al. (2003). Estas ferramentas podem
realizar inspees de diferentes artefatos com equipes geograficamente
distribudas.

70

A ferramenta proposta por Lanubile et al. (2003), chamada de Internet Based

Inspection System (IBIS) utiliza a Web em conjunto com notificaes por e-mail
para apoiar inspees assncronas com equipes geograficamente distribudas.
A IBIS no limita o tipo de artefato a ser inspecionado e na deteco de
defeitos atualmente permite apenas a utilizao das tcnicas ad-hoc e de
checklists. Na reunio de inspeo desta proposta as discrepncias
encontradas na deteco de defeitos so tratadas como tpicos de discusso,
onde mensagens podem ser acrescentadas e o moderador pode realizar a
classificao das discrepncias como defeito ou falso positivo. A IBIS no
fornece apoio aos pontos de tomada de deciso do processo de inspeo,
sendo as atividades de planejamento e de continuao do processo tratadas
como simples cadastros, sem apoio para a realizao de suas tarefas.
Segundo Travassos et al. (2007), a ferramenta proposta por eles, intitulada de
Infra-estrutura de Suporte ao Processo de Inspeo (ISPIS) a nica
ferramenta que disponibiliza recursos para a ajuda na tomada de deciso
apoiadas por resultados de tcnicas de estimativa e dados quantitativos
representando a realidade da prpria organizao. A ISPIS pode ser utilizada
para coordenar e apoiar a inspeo de qualquer tipo de artefato de software
(documentos de requisitos, de projeto, cdigo) e, opcionalmente, faz uso de um
mecanismo de integrao para se comunicar com ferramentas de deteco de
defeitos existentes para artefatos especficos. Outra caracterstica da
ferramenta

permitir

reunies

de

inspeo

tanto

sncronas

quanto

assncronas.
Os conceitos, tcnicas e ferramentas de V&V de software apresentados neste
captulo so utilizados com eficincia, para minimizar a possibilidade de que
um sistema no apresenta falhas e que realmente atenda as necessidades do
usurio final. Estes mesmos conceitos e em particular a tcnica de Inspeo de
Software e suas ferramentas foram utilizados como base para a criao da
tcnica proposta, que apresentada no prximo captulo para validar
processos de desenvolvimento de software.

71

CAPTULO 4
PROPOSTA DE UMA TCNICA DE VALIDAO DE PROCESSO
POR INSPEO

Este captulo apresenta uma proposta para validar processos de desenvolvimento a

ser aplicada em ambientes de construo de software. O modelo proposto foi baseado
em conceitos e tcnicas de Verificao & Validao de software. A tcnica de
Inspeo foi investigada para prover solues ao problema descrito nessa dissertao.
A seguir so apresentadas as justificativas para a seleo e uma descrio detalhada
da tcnica.

4.1 A tcnica proposta: viso geral e justificativas

Nos ltimos anos, a Simulao Computacional vem assumindo uma
importncia cada vez maior como ferramenta de aquisio de conhecimento.
Simular o meio de confrontar teorias com experimentao, de antecipar
resultados experimentais ou de realizar experincias de outro modo
inacessveis (Oberkampf e Trucano, 2007). Os softwares de Simulao
Computacional so usados em muitas vezes em situaes crticas, o que exige
um nvel elevado de credibilidade nos resultados exibidos.
Segundo Oberkampf e Trucano (2007), Sargent(2001) e Balci (1995), a
credibilidade de tais resultados pode ser obtida atravs de tcnicas de
Verificao e Validao. Devido ao histrico bem sucedido desses trabalhos a
tcnica proposta para validar processos tem como base a V&V.
Entre alguns conceitos apresentados em Oberkampf e Trucano (2007),
destaca-se uma diretriz, a qual indica que um experimento de validao deve
ser conjuntamente projetado por pesquisadores, desenvolvedores do modelo e
usurio, trabalhando prximos durante todo o ciclo de vida de um projeto. No

72

entanto, a independncia deve ser mantida para obter os resultados

pretendidos.
A tcnica proposta no presente trabalho preocupa-se em provar que o
processo atende s necessidades dos colaboradores quanto s questes de
Engenharia de Software (Validao) e no em verificar se um produto foi
construdo corretamente de acordo com o processo (Verificao).
Como exposto na Seo 3.3, existem vrias tcnicas de validao formais ou
informais que podem ser aplicadas em conjunto ou separadamente. Assim,
deve-se selecionar a mais adequada para a validao de processos de
software.
Segundo Balci (1995), as tcnicas formais necessitam de dados matemticos e
so o meio mais eficaz de avaliar um software. Porm, em um processo de
software, dados matemticos no so gerados. Existem na literatura trabalhos
como de Paula e Borges (2003) que realizam medies do processo, mas com
o intuito de apresentar possveis melhorias. No entanto, a validao realizada
na criao do processo ou em um estgio inicial de utilizao e nesses
perodos, dados estatsticos no existem. Alm disso, as tcnicas formais so
consideradas complexas e uma outra preocupao deste trabalho foi
selecionar uma tcnica simples, pois um processo de validao no deve ter
um grau de complexidade maior que o processo que ser validado.
As tcnicas informais segundo Balci (1994) so as mais utilizadas, simples e
podem ser aplicadas durante todo o ciclo de desenvolvimento. Considerando
uma outra diretriz defendida por Sargent (2000) e Oberkampf e Trucano (2007)
de que o processo de validao de software deve ser aplicado durante todo o
ciclo de desenvolvimento, as tcnicas informais atendem a essa diretriz.
Dentre as tcnicas informais apresentadas na Seo 3.3, a inspeo de
software se destaca por ser uma tcnica muito utilizada em diversos artefatos
durante o ciclo de vida do software. A inspeo vem sendo usada em
pesquisas para validar documentos como casos de testes e modelos
arquiteturais de software, fornecendo conhecimento e exemplos prticos de

73

uso da validao
dao em documentos conceituais (Perry, 1995; Barcelos e
Travassos, 2005).
). A Figura 4.1 ilustra a possibilidade de se realizar inspees
nos diferentes artefatos de software.

Figura 4.1 Inspeo de Software em diferentes artefatos (Fonte: Ackerman et

al.,1989)

Para um processo de desenvolvimento

esenvolvimento de software ser considerado vlido, ele
deve ser tangvel de ser seguido e atender ao que se propem.
propem Se a
metodologia do processo no est sendo seguida, ou seja, se os usurios no
obedecem a seus
s elementos (etapas, tarefas ou atividades), algo
lgo no est
est
correto. O processo pode ser burocrtico ao ponto de no ser seguido ou
alguns desses
sses elementos so desnecessrios
desnecessrios no dia a dia de uma equipe de
projeto. Assim, com o intuito de examinar se o proce
processo
sso est sendo seguido,
seguido a
inspeo de software
oftware pode ser utilizada.
Como mencionado na Seo
eo 3.3,
3.3 na inspeo de software,
oftware, o produto
analisado contra critrios de entrada predeterminados ou contra as
especificaes que foram usadas para construir o produto.
p
o. Aplicando essa
tcnica validao de processos, tem-se
tem
como critrio predeterminado a
documentao do processo,
cesso, ou seja, o modelo formal, o qual ser comparado
com todos os documentos produzidos
produzidos, e o prprio software. Esses
sses artefatos
so considerados as entradas para que as comparaes sejam feitas.

74

4.2 Validao de Processo de Desenvolvimento de Software

por Inspeo
A tcnica de inspeo proposta para a validao de processos consiste na
adaptao da tcnica de Sauer et al. (2000) para validao de software, j
detalhada na Seo 3.4.2. Algumas modificaes tiveram que ser realizadas
afim de atender a inspeo de processos. A seguir, so descritas as principais
caractersticas que compem a tcnica a ser executada para realizar a
validao, detalhando as modificaes realizadas.
4.2.1 Detalhamento do Processo de Validao Proposto
De acordo com Laitenberger e Atikson (1998), do ponto de vista tcnico, uma
abordagem para inspeo de software formada pelo tipo do artefato de
software a ser avaliado, pela forma como a equipe de profissionais ser
definida para realizar a inspeo, pela tcnica de avaliao utilizada e pelo
processo de execuo seguido. Portanto, uma possvel forma para se definir
uma abordagem para inspeo atravs da realizao das seguintes tarefas:
1. Determinar o artefato de software que deve ser avaliado e o tipo de
informao que o compem;
2. Identificar os perfis das pessoas que devem ser envolvidas nessa
inspeo, assim como o papel que desempenham durante a avaliao;
3. Definir os tipos de defeitos que a abordagem busca identificar;
4. Definir a tcnica de avaliao utilizada para identificar os defeitos no
artefato a ser avaliado, e;
5. Especificar o processo composto pelas atividades a serem executadas
para atingir o objetivo final da avaliao.
A seguir, apresentada a tcnica de validao de processos de
desenvolvimento proposta neste trabalho, seguindo a abordagem

de

Laitenberger e Atikson (1998). Essa tcnica denominada VProcInsp

(Validao de Processos por Inspeo).

75

4.2.1.1 Determinar os artefatos do processo

Geralmente artefatos de software (ou simplesmente artefato) so considerados
como qualquer produto gerado em qualquer etapa do processo de
desenvolvimento de software. Um artefato de software normalmente envolve a
compreenso do problema, a modelagem do problema, a identificao de
possveis alternativas de soluo para este problema, a anlise destas
alternativas, a tomada de deciso sobre quais solues sero usadas na
construo do software, o prprio software e sua documentao.
importante ressaltar que no VProcInsp, o artefato tem uma abrangncia um
pouco maior, pois a idia da tcnica proposta de validao comparar o
modelo formal, ou seja, a documentao do processo, com os produtos
gerados na execuo de tal processo. Logo, esse modelo formal se torna um
importante artefato para a validao de processo.
Alm

da

documentao

do

processo,

as

informaes

dos

software

(comunicadores eletrnicos, softwares de controle de verses, compiladores,

entre outros) utilizados no dia a dia da equipe de desenvolvimento tambm so
artefatos considerados no VProcInsp. Atravs da anlise das informaes
desses softwares pode-se descobrir:
a) Anlise de logs e informaes dos softwares de controle de verses
pode-se garantir que a gerncia de configurao est sendo feita e o
padro do cdigo seguido, caso o processo de desenvolvimento
especifique esses pontos.
b) Comunicadores eletrnicos pode-se descobrir se reunies tcnicas e
contatos com o cliente esto sendo feitos, caso o processo de
desenvolvimento exija.
Sendo assim o VProcInsp expandiu o termo de artefato de software para
artefato de processos de desenvolvimento.
4.2.1.2 Definio do papel e do perfil da equipe participante do processo
de inspeo para validao
O VProcInsp constitudo de quatro papis com caractersticas bem definidas
de atuao. A diferena para o modelo de inspeo proposto por Sauer et al.

76

(2000) a criao do papel chamado de Analista. Os papeis so definidos

abaixo:

Moderador uma pessoa independente, individual e imparcial que

coordena o planejamento, a preparao, a conduta de inspeo, e
reunies. Durante a inspeo, ele assegura que a inspeo seja
eficientemente conduzida quanto utilizao de recurso e a realizao
do esforo mximo em direo ao descobrimento de problemas.

Autor a pessoa ou uma equipe responsvel pelo modelo formal do

processo de desenvolvimento de software. Essa pessoa ou equipe pode
ser a mesma que desenvolveu o processo sob validao ou uma pessoa
com um conhecimento avanado nesse processo. Muitas vezes, essa
pessoa pode ser um gerente de projeto que tem um treinamento
suficiente. A responsabilidade do autor explicar e introduzir a
documentao

do

processo,

alm

de

esclarecer

os

objetivos,

peculiaridades e expectativas sobre a validao. Se o processo for bem

documentado, o moderador pode assumir o papel de autor, desde que
ele tenha o conhecimento avanado do processo sob validao.

Inspetor o responsvel por identificar, analisar e comparar o modelo

formal do processo, com o processo executado na prtica, ou seja,
comparar os artefatos criados pelos stakeholders com a documentao
fornecida pelo moderador (modelo formal). O inspetor no tem a funo
de encontrar erros nos artefatos e sim analisar se o que foi proposto
pelo processo est sendo feito.

Analista a pessoa, ou grupo de pessoas, envolvidas no projeto de

desenvolvimento de software, que esto fazendo uso do processo de
software sob validao. Os analistas tambm so conhecidos como
stakeholders.

Em relao ao nmero de moderadores e de autores, a realizao de uma

inspeo do processo geralmente necessita somente de uma pessoa alocada
para cada um desses papis, ou como mencionado anteriormente, o
moderador pode desempenhar o papel do autor, desde que ele tenha o
conhecimento necessrio.

77

Quanto ao nmero de inspetores, pode-se ter a idia que quanto mais pessoas
forem alocadas para esse papel, maior seria o nmero de defeitos
identificados. Contudo, o custo da avaliao poderia se tornar muito alto e,
alm disso, estudos experimentais mostram que no a quantidade de
inspetores que importa, mas sim a utilizao de profissionais com diferentes
nveis de experincia (Svahnberg, 2003). E, a realizao da reviso, a partir
de diferentes perspectivas, que influenciam no tipo e na quantidade de defeitos
encontrados (Shull, 1998).

4.2.1.3 Taxonomia de defeitos

Como dito anteriormente, o VProcInsp no tem o objetivo de achar defeitos nos
artefatos e sim validar os artefatos quanto a utilizao e criao de acordo com
o processo, descobrindo se o processo est sendo executado como previsto.
Shull (1998), no apresenta como podem ser identificados os possveis tipos
de defeitos, mas define uma taxonomia que foi utilizada por Barcelos e
Travassos (2005) para inspeo de documentos arquiteturais. O VProcInsp
utiliza a mesma taxonomia e a interpreta para o contexto da inspeo de
processos. A Tabela 4.1 apresenta a taxonomia.
Tabela 4.1 Taxonomia de defeitos propostos pelo VProcInsp
Tipos de Defeitos
Omisso

1.
2.

Ambigidade

3.
4.
5.

Inconsistncia

6.
7.
8.

Outro

9.
10.

Descrio dos Defeitos

Quando um dos elementos (artefato, atividade, tarefa, etapa)
necessrios ao processo no foram definidos.
Quando faltam sees de especificao de como os artefatos,
atividades, tarefa e etapas sero definidas.
Quando falta definio de termos utilizados no processo.
Quando a forma como os elementos do processo foi definida
dificultam ou impossibilitam o seu uso.
Quando elementos possuem o mesmo nome, mas responsabilidades
diferentes (Homnimos).
Quando elementos descritos possuem mesma responsabilidade, mas
nomes distintos (Sinnimos).
Quando um elemento presente na execuo do processo no foi
definido no modelo formal.
Quando a representao no condiz com o significado estabelecido
pela abordagem de documentao.
Quando as responsabilidades dos stakeholders no foram definidas.
Quando o defeito no se encaixa nas categorias acima.

78

4.2.1.4 Tcnica de inspeo utilizada

O principal diferencial de uma abordagem de inspeo est no formalismo e na
maneira como ela auxilia o inspetor a encontrar os defeitos. O que determina
essa maneira a tcnica de deteco de defeitos utilizada. A Tabela 4.2
apresenta as tcnicas e suas caractersticas.
Tabela 4.2 Tcnica de Insp. de Software (Adaptado de Barcelos e Travassos, 2005).
Tcnica
Ad-hoc

Checklist

Tcnicas de
Leitura

Descrio
Tcnicas ad-hoc so as tcnicas mais simples para identificar defeitos em
artefatos de software. Elas no oferecem nenhum tipo de apoio ou
procedimento de execuo formal e sistemtico de inspeo. Sendo
assim, os defeitos identificados dependem exclusivamente da
capacidade, competncia e experincia do inspetor. Um dos pontos
negativos em usar tcnicas ad-hoc o fato delas no oferecerem auxlio
aos inspetores para identificar defeitos.
Checklist uma evoluo da tcnica ad-hoc. Ao se utilizar checklist para
revisar artefatos de software, fornecido ao inspetor um conjunto de
questionamentos que o auxiliam a identificar em que parte do artefato
avaliado ele deve procurar por defeitos
Tcnicas de leitura so procedimentos que visam guiar individualmente
os inspetores no entendimento de um artefato de software e, por
conseqncia, na identificao de discrepncias.
Porm, para que esse tipo de tcnica seja utilizado, o artefato deve ser
representado de forma especfica e padronizada, caracterstica que ainda
no pode ser atingida nos processos de desenvolvimento de software

Levando em considerao as peculiaridades da rea de processos de

desenvolvimento de software e as caractersticas apresentadas na Tabela 4.2,
a tcnica de checklist mostra-se mais adequada ao contexto de inspeo para
validao de processos, pois no existem tcnicas de leitura para processos e
as tcnicas Ad-hoc no orientam e so altamente dependentes dos inspetores.
Logo, o VProcInsp procurar validar processos usando como guia, os
questionamentos definidos em um checklist de avaliao.
A idia no criar um checklist fixo, j definido e sim, mostrar um template com
diretrizes para permitir que o moderador crie o checklist de acordo com as
necessidades impostas por cada processo de desenvolvimento. Espera-se que
o uso de checklist como tcnica de inspeo possibilite comparar o modelo
formal com a execuo do processo.

79

Para auxiliar na identificao de discrepncias o checklist deve atender

algumas caractersticas que visam maximizar os resultados da validao. So
elas:

Os itens de avaliao que compem o checklist devem usar conceitos

oriundos da Engenharia de Software. Com isso, pretende-se reduzir a
subjetividade em relao ao que avaliado;

O procedimento deve ser de fcil execuo da avaliao, sem a

necessidade de elaboradas atividades, como as necessrias para a
especificao de cenrios, permitindo a realizao de avaliaes com
baixos custos;

O moderador deve entender que preciso existir pelo menos um

checklist para cada etapa do processo. Isso no ser difcil de ser
criado,

pois,

apesar

de

existirem

inmeros

processos

de

desenvolvimento todos eles se encaixam em algum dos modelos de

processo de desenvolvimento existentes, que, por sua vez, tem suas
etapas bem definidas;

Para orientar o moderador na criao do checklist, o VProcInsp tem

definidas algumas sees, em que orientaes podem ser dadas aos
inspetores e grupos de perguntas podem ser subdivididas de forma a
organizar melhor as questes avaliadas. Alm desses itens, o
moderador tem a liberdade de criar novas sees para que mais de uma
tcnica de validao possa ser usada. Por exemplo, criar uma seo de
perguntas abertas, seguindo os moldes da tcnica de Validao de
Face;

A Figura 4.2 apresenta o checklist inicial proposto pelo VProcInsp. Nessa

figura, todas as sees identificadas com o caractere * so de preenchimento
obrigatrio e, conseqentemente, essas sees no podem ser removidas do
checklist. As outras sees so opcionais, ou seja, o Moderador pode
customiz-las como bem entender. Por exemplo, se a seo Templates no se
aplica ao processo sob validao ela pode ser retirada ou at mesmo
renomeada.

80

Em cada item de checagem (pergunta) existem as seguintes informaes: (1)

Nmero seqencial nico de um item dentro de uma seo; (2) Descrio do
item a ser checado; (3) Resposta afirmativa de um item checado; (4) Resposta
negativa de um item checado e (5) Resposta Esperada (RE) pelo Moderador.
Estes trs ltimos campos so fundamentais para a comparao entre
processo e prtica, pois, espera-se que a resposta afirmativa ou negativa
coincida com a resposta esperada evidenciando que a atividade do processo
representada pelo item do checklist est sendo executada. Em seguida, feita
uma descrio das sees com itens de checagem (Entradas, Sadas, Passos,
Ferramentas, Templates e Responsveis).
VProcInsp Validao de Processo de Desenvolvimento de Software por Inspeo
Checklist de Inspeo
*Instrues
[seo reservada a instrues aos inspetores]

*Inspetor..............:____________________________
*Fase/Atividade...:____________________________
*Principais Objetivos
[seo reservada para descrever os objetivos gerais propostos pelo processo ou etapa do processo que est sob
validao]

*Importncia
[seo reservada para descrever a importncia do processo ou etapa sob validao]

Entradas
N
Descrio do Item de Avaliao

Sim

No

RE

Sadas
N
Descrio do Item de Avaliao

Sim

No

RE

Passos
N
Descrio do Item de Avaliao

Sim

No

RE

Ferramentas
N
Descrio do Item de Avaliao

Sim

No

RE

Templates
N
Descrio do Item de Avaliao

Sim

No

RE

Responsveis
N
Descrio do Item de Avaliao

Sim

No

RE

Observaes
[seo reservada ao moderador ou inspetores para descrever informaes relevantes para validao do processo]

Figura 4.2 Verso padro do Checklist proposto pelo VProcInsp

81

Na seo Entradas, busca-se agrupar os itens relacionados avaliao de

todas as entradas exigidas nas atividades de cada etapa do processo sob
validao. Por exemplo, o modelo formal do processo exige como entrada para
a atividade de Criao do Glossrio (Etapa de Especificao) um documento
de especificao.
A seo denominada Sadas agrupa os itens que buscam avaliar se todos os
artefatos de sada exigidos pelo modelo formal do processo foram cumpridos.
Por exemplo, o processo de desenvolvimento exige que a atividade de
Definio do Projeto (foco, tempo e iteraes do projeto) na fase de
Planejamento tenha como resultado um documento textual com as informaes
pr-estabelecidas.
Passos o nome da seo que busca avaliar se todos os passos
especificados no modelo formal do processo foram seguidos para uma
determinada atividade ou fase. Por exemplo, na fase de Teste a atividade de
Teste de Caixa Preta segue todo o roteiro pr-determinado pela equipe de
qualidade de software.
A subdiviso Ferramentas uma agrupadora de itens com o objetivo de
checar

se

todas

as

ferramentas

especificadas

pelo

processo

de

desenvolvimento foram utilizadas, evitando assim incompatibilidade de

arquivos e perda de informaes. Por exemplo, todos os diagramas foram
criados e salvos por um mesmo software que gera imagens com uma mesma
resoluo e extenso, todos os cdigos do sistema foram gerados com a
mesma verso do compilador.
Templates agrupa os itens que buscam avaliar se todos os padres de
documentao e codificao foram seguidos. Por exemplo, todos os
documentos de Caso de Uso seguem o padro da empresa.
E, por fim, a seo de Responsveis tem como funo reunir os itens do
processo de desenvolvimento referentes s especificaes de responsabilidade
dos stakeholders em cada atividade ou fase. Por exemplo, o gerente
responsvel pela aprovao de alteraes crticas no sistema aprovou as

82

alteraes assinando os documentos de codificao necessrios na fase de

implementao.

4.2.1.5 Processo utilizado na inspeo

Como exposto anteriormente, a aplicao da tcnica de validao de inspeo
de software em processo de desenvolvimento, no tem a funo de encontrar
defeitos e sim validar se o processo est sendo seguido como proposto.
Portanto, a metodologia de inspeo ser usada para que os artefatos e o fluxo
do processo sejam inspecionados e comparados com os artefatos e o fluxo do
modelo formal. Para isso o modelo de Sauer et al. (2000), apresentado na
seo 3.4.2, foi alterado e a etapa de Deteco foi substituda pela etapa de
Anlise e Comparao.
Outra mudana ocorreu na etapa de planejamento. A idia que essa etapa
seja executada pelo moderador e pelo autor (ou autores) do processo. Essa
participao possibilita ao autor fazer uma apresentao do processo indicando
pontos que devem ser atingidos, tipo de ambiente proposto para utilizao
(comercial, acadmico), expectativas e anseios. A Figura 4.3 mostra o modelo
proposto pelo VProcInsp e a descrio desse modelo feita em seguida.

Figura 4.3 Modelo de Inspeo proposto pelo VProcInsp (Adaptado de Sauer et al.,
2000).

83

Planejamento
Nessa fase, o primeiro passo identificar um profissional que exercer o papel
do moderador da inspeo. O Planejamento similar a uma Gerncia de
Projetos, pois nessa atividade o Moderador define a equipe, prazos, custos,
entre outras funes cabveis gerncia.
Durante essa fase, o Moderador deve definir a abrangncia em que a inspeo
de validao do processo vai ser realizada (por etapa, por iterao, ao final do
ciclo de desenvolvimento, entre outros), alm de informaes como datas e
tamanho da equipe. O Moderador define tambm os participantes, com base
na experincia de desenvolvimento, conhecimento do domnio e experincia
com validao de processos.
A principal atividade do Planejamento a configurao do checklist para a
inspeo de validao. Para configurar o checklist, o Moderador conta com a
documentao ou modelo formal do processo sob validao e com o apoio do
Autor do processo. Em uma reunio, os profissionais que assumiram os papis
de Moderador e Autor criam o checklist seguindo diretrizes propostas na
atividade de Definio do Checklist, que foi apresentada na Seo 4.2.1.4, e
identificam os artefatos a serem avaliados.
A ltima atividade cronolgica do Planejamento a apresentao do processo
sob validao, dos objetivos da inspeo e dos checklists aos inspetores
selecionados. Essa atividade pode ser omitida se os inspetores possuem
conhecimento sobre o processo e sobre os artefatos a serem inspecionados.
Nessa apresentao, os documentos a serem utilizados durante a inspeo
so entregues. A Figura 4.3.2 mostra o fluxo das atividades e os documentos
necessrios e produzidos durante a etapa de planejamento. Nessa figura, as
setas slidas indicam o fluxo das atividades e as setas tracejadas representam
os documentos de entrada e sada das atividades.

84

Figura 4.3.2 Atividades

tividades pertencentes fase de Planejamento

Como mostra a Figura 4.3.2 acima, a atividade de Planejamento conta com o

Modelo Formal do Processo que de responsabilidade
responsabilidade do Autor. O Moderador
Moderador,
por sua vez, tem a responsabilidade de levantar e manter as informaes dos
Inspetores disponveis para a Inspeo.
Inspe
Com esses documentos, o Moderador
M
produz o Documento de Definio,
D
os checklists e um relatrio com a relao
de inspetores por checklists
hecklists.
A Figura 4.3.3 mostra o Documento de Definies do Planejamento. Ele
contm informaes definidas no planejamento,
planejamento levantando informaes do
contexto em que a validao ser realizada. Uma vez armazenadas
azenadas, as
informaes ficam disponveis para futuras consultas e atende
de a uma diretriz
proposta por Balci (1995),
1995), que afirma que os documentos produzidos durante a
validao devem estar disponveis para consulta e de preferncia junto com os
documentos do software ou modelo validado.
Nesse documento constam os nomes dos participantes assumindo seus
papis, alm de informaes
rmaes do processo e sobre e quando a validao
ocorreu. Para isso, todos os campos so de preenchimento obrigatrio.

85
VProcInsp Validao de Processo de Desenvolvimento de Software por Inspeo
Documento de Definies do Planejamento
*Moderador..:_________________________________________
*Autor(res)...: _________________________________________
_________________________________________
*Data de Inicio:
*Data de Trmino prevista:
*Nome do Processo de Desenvolvimento:
*Descrio do Processo de Desenvolvimento:
[seo reservada para a descrio de informaes sobre o processo. O prprio documento formal do processo
pode ser anexado.]

*Aplicar inspeo no final das (os):

Etapas
Iteraes
Projeto
Outros
*Inspetores Selecionados:
1) _______________________________________________ Checklist entregue
2) _______________________________________________ Checklist entregue
3) _______________________________________________ Checklist entregue
4) _______________________________________________ Checklist entregue
5) _______________________________________________ Checklist entregue

*Apresentao Realizada
Observaes:

Sim

No

*Data da Realizao:

[seo reservada ao moderador para descrever informaes relevantes para o planejamento da validao do
processo]

Figura 4.3.3 Documento de Planejamento de Validao por Inspeo proposto pelo

VProcInsp

A Figura 4.3.4 mostra o Documento de Informaes dos Inspetores. O

documento funciona como uma ficha cadastral dos inspetores, onde cada
inspetor recebe um identificador nico, para indicar quem o responsvel por
um checklist, ou pelas discrepncias encontradas entre o modelo e a execuo
do processo. Depois que o processo de validao terminar, o Moderador deve
atualizar a ficha cadastral com o nmero de discrepncias encontradas e incluir
no histrico do inspetor a sua participao no processo de validao atual.
Essas informaes ajudaro o prprio Moderador na seleo da prxima
equipe de validao em trabalhos futuros.

86

VProcInsp Validao de Processo de Desenvolvimento de Software por Inspeo

Documento de Informaes dos Inspetores
*ID:
*Inspetor..:_________________________________________
*Nvel de experincia com desenvolvimento de software
1
2
3
4
5
*Nvel de experincia com o domnio do ambiente processo de desenvolvimento
1
2
3
4
5
*Nvel de experincia com validao de processos
1
2
3
4
5
1-Nenhum
2-Pouco
3-Razovel
4-Suficiente
5-Alto
*Nome dos Processos de Desenvolvimento j validados pelo inspetor
1) _______________________________________________
2) _______________________________________________
3) _______________________________________________
4) _______________________________________________
5) _______________________________________________
*Estatstica com o nmero de erros por categorias levantados pelo inspetor
_______Omisso ________Ambigidade ________Inconsistncia ________Outro
Observaes:
[seo reservada ao moderador para descrever informaes relevantes sobre o inspetor]

Figura 4.3.4 Documento de Cadastro de Inspetores proposto pelo VProcInsp

A Figura 4.3.5 mostra o Documento de Atribuio de Inspetores. Este

documento o ltimo documento criado na fase de Planejamento. Ele
descreve os deveres de cada inspetor no processo de validao. Essa
informao til para que o Moderador tenha conhecimento de quem foi
responsvel por cada item pertencente a cada checklist. Assim os inspetores
podem responder dvidas existentes durante as reunies.
Neste documento todos os campos so de preenchimento obrigatrio e os
dados so basicamente o identificador nico do inspetor, o identificador nico
do checklist e a lista com os itens do checklist. Com essas informaes, o
Moderador consegue descobrir o que cada inspetor inspecionou.

87

VProcInsp Validao de Processo de Desenvolvimento de Software por Inspeo

Documento de atribuies de Inspetores
ID:
Inspetor..:_________________________________________
Lista com os identificadores dos checklists sob responsabilidade do inspetor.

ID:
Inspetor..:_________________________________________
Lista com os identificadores dos checklists sob responsabilidade do inspetor.

ID:
Inspetor..:_________________________________________
Lista com os identificadores dos checklists sob responsabilidade do inspetor.

Observaes:
[seo reservada ao moderador para descrever informaes relevantes sobre as atribuies dos inspetores]

Figura 4.3.5 Documento de Atribuies de Inspetores proposto pelo VProcInsp

Anlise e Comparao
Na fase de Anlise e Comparao, os inspetores individualmente analisam os
artefatos e os comparam com o modelo formal do processo, guiados pelos
checklists, identificando discrepncia entre os dois conjuntos de documentos.
importante ressaltar que na maioria das vezes, os inspetores tero que
investigar

todas

as

informaes

produzidas

durante

processo

de

desenvolvimento. Como mencionado anteriormente, o termo artefato no

VProcInsp mais abrangente e envolve, por exemplo, logs e informaes
produzidos por softwares utilizados durante o processo de desenvolvimento.
Durante a execuo dessa fase, o inspetor deve registrar e classificar as
discrepncias em um relatrio. A classificao feita de acordo com o tipo de
caracterstica da discrepncia, usando para isso a taxonomia de defeitos que

88

fora definida na Seo 4.2.1.3.

4.2.1.3 A Figura 4.3.6 mostra o fluxo de atividades
dessa fase e oss documentos de entrada e sada.

Figura 4.3.6 Atividades pertencentes fase de Anlise e Comparao

A fase de Anlise
lise e Comparao conta com os checklists criados pelo
Moderador na fase de Planejamento, com os documentos do modelo formal do
processo, caso os inspetores julguem insuficientes os dados do checklist,
checklist e
com os artefatos criados durante a execuo do processo de desenvolvimento.
Com esses documentos em mos, os inspetores comparam o modelo formal
com a execuo. Os resultados dessa fase so o checklist e os relatrios de
discrepncias preenchidos.
O documento de checklist foi apresentado na Seo 4.2.1.4 e o Relatrio de
Discrepncia
pncia mostrado na Figura 4.3.7. Neste documento, o Inspetor deve
preencher o seu
eu identificador nico e qual item do checklist foi encontrado uma
discrepncia. Deve ser preenchido,
preenchid
tambm, o campo Descrio
Descrio com
informaes de como a discrepncia acontece. O inspetor no deve preencher
o campo Discrepncia Aceita.
Aceita Ele preenchido pelo Moderador
oderador na fase de
Coleo e confirmado, ou no,
no na fase de Discriminao. Logo, o inspetor
nspetor deve
desconsiderar esse campo.

89

VProcInsp Validao de Processo de Desenvolvimento de Software por Inspeo

Relatrio de Discrepncias
Taxonomia de Defeitos:
[seo informada pelo moderador para descrever a taxonomia de defeitos utilizada. Esta seo tem o intuito de
orientar o inspetor a classificar as discrepncias encontradas.]

*ID Inspetor........:______
*N Discrepncia:______
*Descrio:

*Inspetor..:______________________________________
*ID Checklist.:________ *ID Item do Checlist.:________

*Classificao da Discrepncia:
Omisso
Ambigidade
Inconsistncia
Outros
Discrepncia aceita:
Sim
No Motivo:_______________________________
*N Discrepncia:______
*ID Checklist.:_________ *ID Item do Checlist.:________
*Descrio:

*Classificao da Discrepncia:
Omisso
Ambigidade
Inconsistncia
Outros
Discrepncia aceita:
Sim
No Motivo:_______________________________
*N Discrepncia:______
*ID Checklist.:_________ *ID Item do Checlist.:________
*Descrio:

*Classificao da Discrepncia:
Omisso
Ambigidade
Inconsistncia
Outros
Discrepncia aceita:
Sim
No Motivo:_______________________________
Observaes:

Quantidade total de discrepncias levantadas:_________

Figura 4.3.7 Relatrio de Discrepncia proposto pelo VProcInsp

Coleo
Na etapa de Coleo, o Moderador da inspeo tem acesso a todas as listas
de discrepncias atravs dos Relatrios de Discrepncias produzidos pelos
Inspetores na atividade de Anlise e Comparao. O Moderador poder, ento,
selecionar discrepncias destas listas e as descartar ou classificar como
replicadas, caso haja mais de uma discrepncia representando o mesmo
defeito. Quando uma discrepncia descartada, ela retirada das prximas
atividades do VProcInsp.

90

Quando discrepncias so classificadas como replicadas, por sua vez, fica sob
responsabilidade do moderador selecionar uma das verses da discrepncia. A
verso selecionada poder ainda ser editada, de modo que informaes
importantes contidas nas rplicas possam ser acrescentadas. Deve-se lembrar
que essas rplicas devem entrar nos dados estatsticos do inspetor que
levantou tais discrepncias.
O Inspetor nessa etapa deve preencher o campo do Relatrio de Discrepncias
informando se a discrepncia foi, ou no, aceita. Em caso negativo, ele deve
informar tambm o motivo.
Discriminao
O Moderador, o Autor e os Inspetores tm participao nesta atividade.
Durante a discriminao, as discrepncias so tratadas como tpicos de
discusso. Cada participante pode acrescentar seus comentrios relativos a
cada uma das discrepncias, que fica disponvel, como tpico de discusso
enquanto o Moderador e o Autor no decidem se o item representa realmente
uma discrepncia ou no.
Por fim, se de fato a discrepncia for constatada, o Moderador deve marcar no
Relatrio de Discrepncias que ela foi realmente aceita e deve-se atualizar as
estatsticas do inspetor responsvel por essa discrepncia.
importante ressaltar que a soluo para as discrepncias no so discutidas
nessa etapa. Esta uma tarefa do autor do processo. Logo, cabe ao autor
gerar, da forma que lhe convier, documentao para que alteraes no
processo sejam feitas.
Retrabalho
Nessa fase, o autor corrige as discrepncias detectadas durante a inspeo.
Continuao
O material corrigido pelos autores repassado para o Moderador, que faz uma
anlise da inspeo como um todo e re-avalia a qualidade do artefato

91

inspecionado. Ele tem a liberdade de decidir se uma nova inspeo deve

ocorrer ou no.
Este captulo apresentou uma proposta de uma tcnica de validao de
processos de desenvolvimento utilizando-se de inspeo de software. O uso de
inspeo visa comparar o modelo formal do processo com sua execuo,
validando o processo de forma metdica e simples.
Metdica por ser composta de atividades e documentos pr-estabelecidos para
cada uma das cinco fases que compe a tcnica, e simples por utilizar
checklists compostos por um conjunto de questionamentos com a funo de
guiar os inspetores durante a validao.
Os conceitos e aplicao da tcnica de inspeo em software tm resultados
conhecidos, mas a aplicao de inspeo em processos uma nova proposta
que deve ser avaliada. Assim, o primeiro passo em direo a avaliar a tcnica
proposta foi um estudo experimental apresentado no captulo seguinte.

92

CAPTULO 5
AVALIAO DA TCNICA DE VALIDAO DE PROCESSO POR
INSPEO PROPOSTA

descrito neste captulo o estudo de caso realizado para verificar a viabilidade

da soluo implementada, que teve como objetivo avaliar a hiptese que
orienta essa dissertao. O estudo de caso foi realizado em um cenrio real de
desenvolvimento de software fazendo uso de um processo de desenvolvimento
de software bem documentado.

5.1 Discusso
O VProcInsp, apresentado no captulo anterior, foi desenvolvido com um
embasamento terico adquirido nos estudos de Processo de Desenvolvimento
de Software e de conceitos de Verificao e Validao apresentados na
literatura, alm da experincia profissional dos envolvidos na pesquisa com o
uso de boas prticas da Engenharia de Software no desenvolvimento de
sistemas. Mas, no se pode assegurar, apenas com esse conhecimento
adquirido, que a tcnica proposta obtenha os resultados esperados. Portanto,
alm de desenvolver o mtodo de validao, importante avaliar se ele atende
aos objetivos inicialmente definidos.
Para que isso seja possvel, diversas perguntas devem ser respondidas at
que se possa afirmar que o VProcInsp realmente atende aos seus objetivos.
Entre os questionamentos possveis, procura-se responder, inicialmente, se
vivel utilizar a abordagem proposta na validao de processos e se ela
eficaz.

93

Segundo Amaral (2003), experimentao o centro do processo cientfico e

novas tcnicas, mtodos, linguagens e ferramentas no devem ser apenas
propostas, elas devem passar pelo menos por uma avaliao inicial.
Em suma, a utilizao de mtodos experimentais pode trazer os seguintes
benefcios (Tichy, 1998):

Ajudar a construir uma base confivel de conhecimento e desta forma

reduzir a incerteza sobre quais teorias, mtodos e ferramentas so
adequados;

Poder

levar

novas

compreenses

sobre

reas

atualmente

pesquisadas;

Explorar reas desconhecidas, permitindo estender a fronteira do

conhecimento;

Acelerar o progresso atravs da rpida eliminao de abordagens no

fundamentadas, suposies errneas e modismos, ajudando a orientar a
engenharia e a teoria para direes promissoras:

Ajudar no processo de formao da Engenharia de Software como

cincia, atravs do crescimento do nmero de trabalhos cientficos com
uma avaliao experimental significativa.

Na demonstrao dos benefcio de uma nova tecnologia e no registro de

experincias em relao a sua utilidade;

Segundo Wohlin (2000), a escolha dos mtodos experimentais depende dos

pr-requisitos da investigao, do propsito, da disponibilidade de recursos e
de como se pretende analisar os dados coletados. Wohlin classifica os
mtodos como:

Survey: investigao executada em retrospecto quando, por exemplo,

uma ferramenta ou tcnica tem sido utilizada em uma empresa e
pretende-se avali-la sob algum aspecto. Algumas formas para coleta de
dados como entrevistas e questionrios so bastante conhecidas e
utilizadas.

Estudos de caso: usados para monitorar projetos, atividades ou

exerccios, objetivando rastrear um atributo especfico, ou estabelecer

94

relacionamentos entre diferentes atributos, sem um controle muito formal

sobre as atividades relacionadas ao mtodo experimental.

Experimentos:

atividades

com

propsito

de

descobrir

algo

desconhecido ou de testar uma hiptese envolvendo uma investigao

de coleta de dados e de execuo de uma anlise para determinar o
significado dos dados. Experimentos so apropriados para confirmar
teorias, o conhecimento convencional, explorar os relacionamentos,
avaliar a predio dos modelos ou validar as medidas. As suas
principais caractersticas so de permitir o controle total sobre processo
e variveis e de ser possvel repeti-lo.
No contexto dessa pesquisa, adotou-se o estudo de caso levando em
considerao a idia de introduzir o VProcInsp em um ambiente industrial, que
j utiliza um processo de desenvolvimento validado no meio em que est sendo
aplicado. Caso contrrio, seria questionvel aplicar uma tcnica que est sendo
avaliada em um processo de desenvolvimento que tambm precisa passar por
uma avaliao. importante ressaltar que aplicar um mtodo imaturo em um
ambiente real com o intuito de obter resultados confiveis perigoso.
O principal objetivo do estudo de caso realizado o de identificar e solucionar
possveis problemas observados durante o experimento, para que a tecnologia
em estudo se torne mais madura e seus resultados no sejam oriundos de
variaes humanas ou erros experimentais. O estudo de caso proposto por
Wohlin et al. (2000) consiste nas seguintes etapas, assim ordenadas: 1)
Definio, 2) Planejamento, 3) Operao, 4) Anlise e Interpretao e 5)
Apresentao e Empacotamento.
A definio a primeira atividade, onde o experimento expresso em termos
dos problemas e objetivos. A atividade de planejamento vem em seguida, onde
o projeto do experimento determinado, a instrumentao considerada e os
aspectos da validade do experimento so avaliados. A Execuo do
experimento segue o planejamento. Neste momento, os dados experimentais
so coletados para serem analisados e avaliados na atividade de anlise e
interpretao. Finalmente, os resultados so apresentados e empacotados.

95

As trs subsees abaixo apresentam as primeiras etapas desse processo

experimental. A Anlise e Interpretao so realizadas na Seo 5.5 e 5.6
fazendo uso de alguns documentos produzidos pela tcnica proposta, a fim de
simplificar e proporcionar um maior entendimento dos resultados, a etapa de
Apresentao e Empacotamento pode ser vista nos Apndice A e B, que
contm o restante dos documentos produzidos no experimento.

5.2 Definio
A fase de definio do estudo experimental descreve os objetivos de sua
realizao. No contexto desse trabalho, o objetivo avaliar se o apoio
fornecido pelo VProcInsp para a atividade de validao de processos de
desenvolvimento adequado e se traz benefcios. Assim pretende-se
responder as seguintes perguntas:
Q1 O mtodo facilmente aplicvel (simples, adaptvel, extensvel) e conduz
os envolvidos na validao do processo de forma correta?
Q2 A documentao proposta pelo VProcInsp realmente necessria e
fornece informaes teis?
Q3 possvel comparar o modelo formal com a execuo do modelo?

5.3 Planejamento
Segundo Wohlin et al. (2000), a fase de planejamento descreve como o
experimento deve ser realizado. Esta descrio envolve: (1) a seleo do
contexto, (2) a formulao das hipteses, (3) a seleo das variveis, (4) a
seleo dos indivduos, (5) o projeto do experimento, (6) instrumentao e (7) a
avaliao da validade.
De acordo com Wohlin et al. (2000), a seleo do contexto pode ser
caracterizada em quatro dimenses: (1) processo monitoramente contnuo ou

96

no contnuo, (2) participantes acadmicos ou profissionais, (3) realidade

problema real ou modelado e (4) generalidade geral ou especfica. A
formulao da hiptese estabelece uma ou mais hipteses preliminares que
deduzem as concluses e ao final do estudo as hipteses devem ser falseadas
ou confirmadas. A seleo das variveis a escolha das caractersticas
medidas, controladas ou manipuladas durante a pesquisa. Elas podem ser: (1)
Independentes da reao inicial, intenes ou aes dos envolvidos na
pesquisa,

ou

(2)

Dependentes

da

manipulao

ou

das

condies

experimentais, ou seja, elas dependem do que as pessoas faro. Na seleo

dos indivduos, pessoas com o perfil desejado para executar ou fornecer
dados para a pesquisa so selecionadas. O projeto de experimento
determina a maneira como um experimento ser conduzido. A deciso sobre a
alocao dos objetos e dos participantes feita nesse momento, logo, a
instrumentao, que so todos os objetos ligados pesquisa, est vinculada
ao projeto de experimento. Por fim, a avaliao da validade executada
mostrando o quo vlido so os resultados.
A Tabela 5.1 mostra o planejamento do estudo de caso realizado nesta
dissertao seguindo a descrio apresentada acima.

97
Tabela 5.1 Planejamento de experimento.
Seleo de Contexto:
Esse estudo de caso se prope a ser executado sem um monitorando contnuo das
atividades, pois os dados sero coletados de informaes existentes apenas em duas fases
do processo de desenvolvimento, e os participantes so profissionais da rea de
desenvolvimento e qualidade de softwares aplicando o VProcInsp em um ambiente real de
desenvolvimento de sistemas.
Formulao da Hiptese:
Com vista na idia apresentada anteriormente de que um processo vlido se tangvel
de ser seguido e faz o que se prope, a seguinte hiptese nula foi elaborada:
Hiptese Nula: A utilizao do VProcInsp no permite aos participantes do processo
de validao comparar o modelo formal com a execuo do processo.
Com os resultados da fase de anlise e interpretao dos dados do estudo de caso,
pretende-se chegar a uma concluso sobre a possibilidade da rejeio desta hiptese nula.
Seleo das variveis:
Esse experimento utiliza as seguintes variveis:
Varivel Independente:
o A documentao do Modelo formal do Processo de Desenvolvimento de Software
sob validao.
Varivel Dependente:
o Os documentos gerados pelo VProcInsp.
o Os artefatos gerados pela execuo do processo.
Seleo dos indivduos:
O participantes devem deter conhecimento sobre o VProcInsp e/ou sobre o Processo de
desenvolvimento de software e se possvel experincia com Inspees de Software. Os
participantes selecionados iro assumir os papeis pr-estabelecidos pelo VProcInsp. Assim,
um participante assume o papel do Moderador, outro, o papel de Autor e duas pessoas
tm a funo de Inspetor.
Projeto do Experimento:
O projeto de estudo experimental segue o fluxo normal das fases proposta pelo VProcInsp,
atribuindo, assim, os papeis, as atividades e os documentos que devem ser executados.
Logo, os participantes devem aplicar o VProcInsp em um ambiente industrial coletando as
informaes necessrias para a validao do processo, mas com o foco central em analisar
o VProcInsp. Como o estudo de caso tem o foco em analisar a tcnica proposta e no o
processo de software, a fase de Continuao apresentada na Seo 4.2.1.5, a princpio,
no se faz necessria, pois, a continuao a re-execuo da validao em pontos
reestruturados do processo.
Instrumentao:
Na realizao do experimento, os dois inspetores utilizaro como instrumento os checklists
criados pelo Moderador. A partir destes checklists, os inspetores criam os relatrios de
discrepncias que se tornam o instrumento para que o moderador e o autor discutam e
definam se realmente as informaes so relevantes validao do processo ou no.
Sendo que, o resultado dessa definio utilizado pelo Autor na tentativa de executar as
adaptaes necessrias para que o processo seja considerado vlido.
Avaliao da Validade:
O estudo envolve profissionais da rea de desenvolvimento e de engenharia de software
em um ambiente real de desenvolvimento. Mas, somente com esse estudo de caso, no
possvel generalizar os resultados para todos os ambientes de desenvolvimento, sendo
necessrio para isto realizar novos estudos de casos. Esse estudo, porm, ir dar subsdios
para que melhorias e confirmaes sejam realizadas no processo e, principalmente, no
VProcInsp.

98

5.4 Operao
O experimento foi realizado na empresa TOTVS S.A. que segundo a 19
Pesquisa de Informtica realizada pela Fundao Getlio Vargas a lder do
mercado nacional em pacotes ERP e atua em pases como Mxico, Argentina
e Portugal. A empresa agrupa as marcas Microsiga, Logocenter e RM Sistemas
tendo uma base de aproximadamente quinze mil clientes. O estudo foi
realizado exclusivamente sobre a marca RM Sistema que tem sua matriz na
cidade de Belo Horizonte (FGV, 2008).
A empresa foi selecionada por usar um processo validado que controla com
eficincia todo o setor de desenvolvimento de sistemas, gerenciando os mais
de 200 participantes que esto envolvidos diretamente com os produtos RM.
Outro ponto importante, que o processo de desenvolvimento dessa empresa
certificado CMMI nvel 2 ou MPS.BR nvel F.
No o intuito deste trabalho, e nem de interesse da empresa, detalhar todo o
processo utilizado pela RM Sistemas. Mas o processo segue a tendncia
mundial no uso de um processo iterativo e incremental com suas fases bem
definidas, organizando a construo, implantao e manuteno. O processo
lembra as caractersticas do Processo Unificado, propondo artefatos comuns e
deixando a cargo dos stakeholders a escolha do que realmente necessrio,
para que a burocracia no atrapalhe o desempenho dos mesmos.
O processo utilizado pelo RM faz uso da UML para modelagem dos seus
projetos que adotam o paradigma orientado a objetos com uma arquitetura
compostas em duas ou trs camadas. A Figura 5.1, mostra, de forma geral, o
processo de desenvolvimento criado pela RM Sistemas.

99

Figura 5.1 Processo de desenvolvimento criado pela RM Sistemas

Para a aplicao do VProcInsp foi selecionado o produto RM Solum que visa a

Gesto de Projetos e Obras. Logo,
Logo toda a anlise foi realizada com a equipe e
os dados gerados por esse produto. O RM Solum foi escolhido por ser um
software que est h vrios anos no mercado e j passou por todas as fases
de desenvolvimento. Atualmente
Atualmente, o sistema vem sendo migrado para a
plataforma Dot Net e essa migrao acontece com uma grande preoc
preocupao
com a qualidade, que no pode ser alcanada sem o uso do processo de
desenvolvimento de software da empresa.
A proposta inicial do estudo de caso era
era validar todo o processo de software da
RM Sistemas. Contudo, devido a limitaes impostas pelo contexto em que o
estudo foi realizado, somente duas etapas do processo de desenvolvimento
foram validadas. Essa limitao ocorreu por motivos estratgicos da empresa
de no divulgar, mesmo que em um meio acadmico,
acadmico todo o processo de
desenvolvimento de software e porque no foi possvel para a e
empresa
disponibilizar pessoal noss diversos
divers setores que o processo
o de desenvolvimento
se aplica.
Outra limitao foi quanto a questo de permisso de acesso aos softwares e a
documentos, que uma tarefa cara e sigilosa. Primeiramente,, os participantes

100

da pesquisa deveriam receber tais permisses e isto demandaria um trabalho

extra para o pessoal de infra-estrutura de tecnologia. Segundo, informaes
sigilosas seriam expostas sem necessidade do ponto de vista estratgico da
empresa.
Sendo assim, as etapas escolhidas dentre as opes apresentadas para a
realizao do estudo de caso foram a de Especificao e Implementao. As
Figuras 5.2 e 5.3 mostram respectivamente essas duas fases do processo,
nota-se, nas duas figuras, que as atividades seguem um fluxo pr-estabelecido
e envolve pessoas com trs papis definidos fazendo uso e produzindo
artefatos.
A fase de Especificao possibilita o entendimento da funcionalidade do
sistema, em um nvel voltado ao negcio, para todos os envolvidos no projeto
define, tambm, a terminologia especfica do problema de domnio, explicando
termos que possam ser desconhecidos ao leitor, com respeito s descries
dos artefatos gerados.

Figura 5.2 Fase de Especificao do processo de desenvolvimento criado pela RM

101

A fase de Implementao verifica se todas as informaes necessrias a

implementao esto contidas na especificao dos requisitos, identificando
eventuais inconsistncias. Tambm so atividades dessa fase: escrever o
cdigo que implementa o requisito, armazenar o cdigo fonte em lugar
centralizado, de forma a possibilitar execuo de backups, e verificar se o
cdigo fonte funciona efetivamente.

Figura 5.3 Fase de Implementao do processo de desenvolvimento criado pela RM

O estudo de caso foi conduzido, seguindo a tcnica de validao definida pelo

VProcInsp, onde a primeira atividade a ser realizada a de planejamento da
inspeo. Durante esse planejamento, o escopo da inspeo foi definido e os
participantes

foram

escolhidos.

apresentados aos inspetores.

Os

checklists

foram

configurados

102

A definio do escopo, ou seja, a escolha de atuar em apenas duas fases do

processo, foi tomada em uma reunio com uma funcionria que faz parte da
equipe de engenharia de software da empresa. Nessa ocasio a mesma
aceitou o convite para fazer parte do estudo de caso, assumindo o papel de
Autor (a).
Nessa mesma reunio ficou acordado que a anlise contemplaria dez
requisitos de software. Assim, os inspetores puderam aplicar o checklist nas
duas fases do processo, comparando o modelo formal com a execuo do
aplicado sob dez requisitos escolhidos aleatoriamente. O objetivo foi analisar
se os requisitos seguiram as atividades ou tarefas como o modelo formal
prope.
importante ressaltar que a quantidade de requisitos analisados e a escolha
das duas fases do processo, no seriam suficientes para validar inteiramente
um processo de desenvolvimento. Mas, como o objetivo no validar o
processo, e sim analisar a aplicabilidade e eficincia do VProcInsp, considerase esse nmero razovel.
Com o escopo definido, o prximo passo foi a definio dos participantes do
estudo de caso. O prprio pesquisador exerceu o papel de Moderador. Essa
deciso foi tomada para facilitar a identificao das necessidades de melhorias
nos documentos propostos e para que o mesmo tenha um contato direto no
processo de validao. Foi definido entre o Moderador e o Autor que dois
inspetores seriam suficientes onde cada um inspecionou uma etapa do
processo.
Os inspetores foram selecionados levando em considerao a experincia com
o processo da empresa e com o desenvolvimento de software, alm de terem
acesso aos artefatos produzidos pelo produto RM Solum. A Figura 5.4 mostra
de forma simples o escopo e o papel dos inspetores definido na etapa de
planejamento do VProcInsp.

103

Figura 5.4 Contexto em que o VProcInsp foi aplicado no estudo de caso

A etapa de planejamento foi encerrada com uma reunio entre os quatro

participantes do VProcInsp e com os analistas da empresa. Neste Momento
foram entregues os checklists,
checklists, os objetivos da pesquisa foram explicados,
alguns conceitos de inspeo de software foram apresentados e dvidas foram
esclarecidas.
Com os checklists em mos,
mos os dois inspetores analisaram os artefatos
produzidos seguindo os itens elaborados pelo moderador. Ao final dessa
atividade os inspetores preencheram o Relatrio de Discrepncia,
Discrepncia que um
centralizador das informaes coletadas e ajuda o Moderador na etapa de
Coleo.
Seguindo o fluxo normal das fases propostas pelo VProcInsp, o Moderador
analisou as discrepncias como prope a etapa de Coleo apresentada na
Seo 4.2.1.5, e apesar de constatar
const
que os cinco primeiros itens do relatrio
estavam ligados a criao de diagramas UML,
UML ele optou por no agrupar ou
descartar esses itens, pois cada um estava em atividades diferentes do
processo (Veja os itens na Figura 5.6)
5.6). Logo, esses
sses itens poderiam incrementar
a discusso sobre o processo na etapa de discriminao do VProcInsp
VProcInsp. Nesse
momento, o Moderador tambm atualizou as estatsticas dos inspetores
informando a quantidade de discrepncias por omisso, ambigidade e
inconsistncia
ia que os mesmos levantaram na participao
par
dessa inspeo.
A validao
idao do processo enc
encerrou-se com a etapa de discriminao, pois o
VProcInsp no contempla a fase de Retrabalho e como descrito na Tabela 5.1,
no iria ser realizado outra validao do processo
processo que corresponde a fase de
Continuao.

104

A discriminao foi realizada pelo Moderador, pelo Autor, por dois inspetores e
por um analista, que trataram todos os itens do checklist como pontos de
discusso, com nfase nos sete tpicos de discrepncia apontados no relatrio
referente fase de Especificao do processo. Como pode ser visto na Figura
5.5, o relatrio de discrepncias da fase de Implementao est vazio, porque
no foram encontradas evidencias de que o modelo e a execuo estavam
sendo aplicados de forma diferente.

VProcInsp Validao de Processo de Desenvolvimento de Software por Inspeo

Relatrio de Discrepncias
Taxonomia de Defeito:
Omisso:

Quando um dos elementos (artefato, atividade, tarefa, etapa) necessrios ao processo
no foram definidos.

Quando faltam sees de especificao de como os artefatos, atividades, tarefa e
etapas sero definidos.

Quando falta definio de termos utilizados no processo.
Ambigidade:

Quando a forma como os elementos do processo ou suas responsabilidades foram
definidos dificultam ou impossibilitam seu uso.

Quando elementos possuem o mesmo nome, mas responsabilidades diferentes
(Homnimo);
Inconsistncia:

Quando elementos descritos possuem mesma responsabilidade, mas nomes distintos
(Sinnimo)

Quando um elemento presente na execuo do processo no foi definido no modelo
formal

Quando a representao no condiz com a semntica estabelecida pela abordagem
de documentao.

Quando as responsabilidades dos stakeholders no foram definidas.
Outro:
Quando o defeito no se encaixa nas categorias acima.
ID Inspetor........: 00001
Inspetor..: Srgio Gontijo do Nascimento
Observaes:
No foram encontradas discrepncia para o a fase de Implementao ao executar o
checklist com os 19 itens.
Quantidade total de discrepncias levantadas: 0
Quantidade total de discrepncias aceitas.......: 0
Figura 5.5 Relatrio de Discrepncia preenchido com os dados do estudo de caso

A Figura 5.6 mostra o relatrio de discrepncia da etapa de especificao do

processo de desenvolvimento abordado pelo estudo de caso. Nota-se que sete
discrepncias foram encontradas, sendo que cinco foram classificadas como
omisso e duas classificadas como inconsistncia.

105
VProcInsp Validao de Processo de Desenvolvimento de Software por Inspeo
Relatrio de Discrepncias
Taxonomia de Defeito:
Omisso:

Quando um dos elementos (artefato, atividade, tarefa, etapa) necessrios ao processo
no foram definidos.

Quando faltam sees de especificao de como os artefatos, atividades, tarefa e
etapas sero definidos.

Quando falta definio de termos utilizados no processo.
Ambigidade:

Quando a forma como os elementos do processo ou suas responsabilidades foram
definidos dificultam ou impossibilitam seu uso.

Quando elementos possuem o mesmo nome, mas responsabilidades diferentes
(Homnimo);
Inconsistncia:

Quando elementos descritos possuem mesma responsabilidade, mas nomes distintos
(Sinnimo)

Quando um elemento presente na execuo do processo no foi definido no modelo
formal

Quando a representao no condiz com a semntica estabelecida pela abordagem
de documentao.

Quando as responsabilidades dos stakeholders no foram definidas.
Outro:

Quando o defeito no se encaixa nas categorias acima.
ID Inspetor........: 00002
Inspetor..: Tllio Mendes Rodrigues
N Discrepncia: 01
ID Checklist.: 001
ID Item do Checklist.: 02
Descrio:
No foram encontrados diagramas UML para os dez requisitos inspecionados. Logo, no
foram usados os documentos expostos no item como entrada.
Classificao da Discrepncia:
Omisso
Ambigidade
Inconsistncia
Outros
Discrepncia aceita:
Sim
No Motivo:
N Discrepncia: 02
ID Checklist.: 001
ID Item do Checklist.: 07
Descrio:
No foram encontrados diagramas UML para os dez requisitos inspecionados. Logo, no
foram produzidos documentos de caso de uso e outros diagramas como sada.
Classificao da Discrepncia:
Omisso
Ambigidade
Inconsistncia
Outros
Discrepncia aceita:
Sim
No Motivo:
N Discrepncia: 03
ID Checklist.: 001
ID Item do Checklist.: 12
Descrio:
No foram criados diagramas de caso de uso para os requisitos. Logo no havia arquivos
para serem atualizados no SourceSafe.
Classificao da Discrepncia:
Omisso
Ambigidade
Inconsistncia
Outros
Discrepncia aceita:
Sim
No Motivo:
N Discrepncia: 04
ID Checklist.: 001
ID Item do Checklist.: 21
Descrio:
No foram criados diagramas de caso de uso. Logo os templates no foram utilizados.
Classificao da Discrepncia:

106
Omisso
Ambigidade
Inconsistncia
Outros
Discrepncia aceita:
Sim
No Motivo:
N Discrepncia: 05
ID Checklist.: 001
ID Item do Checklist.: 24
Descrio:
No existem diagramas UML para esses requisitos no SourceSafe. Logo o desenvolvedor
no criou nenhum diagrama.
Classificao da Discrepncia:
Omisso
Ambigidade
Inconsistncia
Outros
Discrepncia aceita:
Sim
No Motivo:
N Discrepncia: 06
ID Checklist.: 001
ID Item do Checklist.: 26
Descrio:
Todas as solicitaes de criao de script foram feitas pelo prprio desenvolvedor.
Classificao da Discrepncia:
Omisso
Ambigidade
Inconsistncia
Outros
Discrepncia aceita:
Sim
No Motivo:
N Discrepncia: 07
ID Checklist.: 001
ID Item do Checklist.: Inexistente
Descrio:
Ao inspecionar os artefatos para responder o item 26 o inspetor relatou a seguinte
discrepncia: A solicitao de criao de script feita na etapa de Implementao e no na
Etapa de Especificao.
Evidncia: A data de abertura de ocorrncia para os scritps eram posteriores ao
apontamento de horas na fase de implementao. Ou seja, as datas de abertura de
solicitao eram feitas depois do encerramento da fase de Especificao
Classificao da Discrepncia:
Omisso
Ambigidade
Inconsistncia
Outros
Discrepncia aceita:
Sim
No Motivo:
Observaes:
A discrepncia 07 no existia no checklist, mas foi uma discrepncia levantada a partir do
item 26 e que deve ser verificada.
Quantidade total de discrepncias levantadas: 7
Quantidade total de discrepncias aceitas.......: 7
Figura 5.6 Relatrio de Discrepncia preenchido com os dados do estudo de caso

Examinando a Figura 5.6 acima, perceber-se que todas as discrepncias foram

aceitas nessa fase de Coleo. Mas, essas informaes podem ser alteradas
na fase de discriminao porque nessa fase os itens sero alvo de debates, e
caso fique acordado que a discrepncia no procede, o Moderador remarca o
item sob debate como uma discrepncia no aceita.

107

5.5 Anlise dos Dados e Resultados Obtidos

A anlise feita nessa seo considera os dados produzidos pela abordagem do
VProcInsp no estudo de caso, as observaes do pesquisador e opinies dos
envolvidos no estudo de caso. Para melhor compreenso, a anlise dividida
em: anlise dos resultados e anlise da utilizao da abordagem.

5.5.1 Anlise dos resultados da abordagem

Atravs dos dados presentes no relatrio de discrepncia levantados no estudo
de caso, foram geradas tabelas com o intuito de transformar dados em
informaes teis. Essas tabelas so compostas por linhas que representam os
dados de cada item pertencente aos checklists. Em cada linha existem colunas
com as possveis respostas (Sim, No e No Aplicvel NA), do item do
checklist.
Essas colunas so preenchidas com a quantidade de respostas Sim, No ou
NA para os dez requisitos inspecionados. A Resposta Esperado (RE) outra
coluna pertencente s tabelas. Ela importante, pois representa a resposta
que o modelo formal exige. Logo, se as respostas encontradas pelo inspetor
so iguais s respostas esperadas, a execuo do processo segue o modelo
formal.
importante ressaltar dois pontos nessa anlise: (1) alguns itens dos
checklists no so aplicveis a todos os requisitos analisados e, por isso, no
podem ser considerados discrepncias. Por exemplo, no item 04 (O script e a
ocorrncia foram encaminhados para o Analista responsvel?) seis requisitos no

apresentaram a necessidade de criao de script, logo essa tarefa no deveria

ser executada. Portanto, os requisitos foram classificados como No
Aplicveis; (2) a discrepncia analisada de acordo com o nmero de
requisitos que no obedeceram RE, desconsiderando as respostas NA.
Os dados foram analisados em dois momentos distintos. A Tabela 5.2 mostra o
primeiro instante dessa anlise, onde os resultados foram apresentados sem
as discusses proposta pela fase de discriminao do VProcInsp apresentada

108

na Seo 4.2.1.5, ou seja, a anlise foi feita a partir das discrepncias aceitas
somente pelo moderador, sem levar em considerao as opinies do autor, dos
inspetores e dos analistas. Esta tabela dividida em Tabela 5.2-A e 5.2-B que
representam respectivamente os dados da etapa de especificao e
implementao. Estas tabelas so importantes, pois, se pode comparar de
forma simples o que era esperado com o que realmente foi executado no
processo de desenvolvimento de software.

109
Tabela 5.2 Informaes levantadas pelo VProcInsp antes da fase de Discriminao
Itens do
RE
Sim
No
NA
Checklist
10
0
0
1
Sim
0
10
0
2
Sim
10
0
0
3
Sim
4
0
6
4
Sim
4
0
6
5
Sim
10
0
0
6
Sim
0
10
0
7
Sim
10
0
0
8
Sim
4
0
6
9
Sim
4
0
6
10
Sim
10
0
0
11
Sim
10
0
0
12
Sim
10
0
0
13
Sim
4
0
6
14
Sim
10
0
0
15
Sim
10
0
0
16
Sim
10
0
0
17
Sim
10
0
0
18
Sim
10
0
0
19
Sim
10
0
0
20
Sim
0
10
0
21
Sim
10
0
0
22
Sim
10
0
0
23
Sim
10
0
0
24
Sim
10
0
0
25
Sim
0
4
6
26
Sim
4
0
6
27
Sim
0
4
6
28
Sim
Tabela A Dados levantados na etapa de
Especificao

Itens do
RE
Sim
No
NA
Checklist
10
0
0
1
Sim
10
0
0
2
Sim
10
0
0
3
Sim
10
0
0
4
Sim
10
0
0
5
Sim
10
0
0
6
Sim
10
0
0
7
Sim
10
0
0
8
Sim
10
0
0
9
Sim
10
0
0
10
Sim
10
0
0
11
Sim
10
0
0
12
Sim
10
0
0
13
Sim
10
0
0
14
Sim
10
0
0
15
Sim
10
0
0
16
Sim
10
0
0
17
Sim
10
0
0
18
Sim
10
0
0
19
Sim
Tabela B Dados levantados na etapa de
Implementao

A Tabela 5.2-A e 5.2-B so compostas por linhas representando as respostas

obtidas dos 28 itens do checklist da etapa de especificao e dos 19 itens do
checklist

da

etapa

de

implementao.

Estas

tabelas

possuem

coincidentemente a resposta Sim para todas as suas linhas da coluna RE.

dito coincidente, pois, como proposto pelo VProcInsp na Seo 4.2.1.5, a RE
informada pelo Moderador na fase de Planejamento durante a atividade de

110

criao dos checklists, e neste estudo de caso, o Moderador atribui o valor

Sim para todos os itens levando em considerao o processo de
desenvolvimento da TOTVS S.A.
A Tabela 5.2-A mostra que os itens 2, 7, 12, 21 e 24 tinham como resposta
esperada para os dez requisitos, o Sim. No entanto, nenhum desses itens
obteve tal resposta, mostrando que os itens no so executados pelos
stackholders e aparentemente pode indicar uma atividade que no vlida no
processo. Os itens 26 e 28 tambm tm como resposta esperada o Sim, mas
em ambos, quatro requisitos no obedeceram a essa resposta. Os outros seis
no so aplicveis, sendo assim desconsiderados. Portanto, essa tabela indica
que os sete itens do checklist (2, 7, 12, 21, 24, 26 e 28) no esto sendo
executados apresentando uma discrepncia entre o modelo e a prtica do
processo.
A Tabela 5.2-B mostra que a execuo do processo segue o modelo formal
proposto, pois os 19 itens do checklist tm a mesma resposta que a coluna RE.
Logo, pode-se concluir que a execuo est seguindo exatamente o que o
modelo prope, no existindo assim discrepncias nessa etapa.
Como o estudo de caso no apresentou uma descrio aprofundada sobre o
processo de desenvolvimento da TOTVS S.A., a Tabela 5.3 explica os itens da
Tabela 5.2-A que apresentam discrepncias para facilitar o entendimento da
anlise dos resultados.

111
Tabela 5.3 Descrio dos itens com discrepncias do cheklist de especificao.
N do
Item
2

Descrio do Item

Explicao do item

A aplicao Delphi e o RM Especifica

contendo todos os requisitos do produto
serviram como entrada para
criar/atualizar casos de uso e/ou outros
diagramas

Como a empresa est migrando seus produtos de

Delphi para Dot Net, o processo orienta os
desenvolvedores a fazer uso do cdigo fonte em
Delphi e tambm de um software chamado RM
Especifica, que centraliza os documentos de
modelagem para criar/atualizar os diagramas e
casos de uso.
A fase de especificao de softwares
fundamental para os processos de
desenvolvimento modernos, sabendo da
importncia desta fase, a TOTVS exige que os
diagramas e casos de uso sejam criados quando
necessrios.
A empresa usa o software da Microsoft chamado
SourceSafe para fazer o controle de verses dos
documentos. Logo, os documentos de casos de
uso e diagramas devem ser salvos neste
software.
O processo da TOTVS fornece documentos
padres para a especificao das
implementaes. Logo, os desenvolvedores
devem seguir estes padres, que ficam
disponveis no SourceSafe.
Fica a cargo das pessoas que assumem o papel
de Desenvolvedor criar/atualizar os diagramas e
caso de uso.
A pessoa que assume o papel de Analista
Responsvel tem a funo de gerenciar uma
equipe de desenvolvedores, e uma das
atribuies do Analista Responsvel fazer a
solicitao para a equipe de banco de dados,
quando os desenvolvedores especificam que
necessrio criar ou alterar a base de dado dos
software criados pela empresa. Estas
criaes/alteraes na base de dados so
delicadas e, por isso, devem ser feitas pelo
Analista Responsvel.
As solicitaes de criao ou alterao na base
de dados feita pelo Analista Responsvel para a
equipe de banco de dados da empresa devem ser
feitas na fase de especificao

Foi gerada a especificao dos casos de

uso ou outros diagramas?

12

Ao final da atividade de criar/atualizar

casos de uso e/ou outros diagramas, os
documentos de sada foram atualizados
no Source Safe?

21

Os templates disponveis em
SS\RM.NET\Souce\RM.Templates\RM.
Docs\ E_UC - Caso de Uso.doc foram
utilizados ao criar/atualizar casos de uso
e/ou outros diagramas?
O Desenvolvedor foi responsvel por
criar/atualizar casos de uso e/ou outros
diagramas?
Analista Responsvel foi o responsvel
por solicitar ao criao/atualizao do
script?

24
26

28

A solicitao de criao de script feita

na etapa de Especificao

Passado a primeira fase, as tabelas 5.2 A e B e todos os documentos

produzidos pelo estudo de caso foram analisados em uma reunio. Nesta
reunio proposta pela fase de discriminao do VProcInsp, os itens foram
debatidos e os participantes chegaram a um consenso. Ficou acordado que os
itens 2, 7, 12, 21 e 24 que so relacionados com os diagramas UML no so
considerados discrepncias. Nessa reunio, o Autor alegou que esses itens
relacionados UML so considerados opcionais pelos desenvolvedores,
porque somente os documentos de regra de negcio gerados na fase de

112

entendimento foram suficientes para adquirir o conhecimento do problema.

Outra questo apontada pela equipe, que na empresa ainda no existe um
modelo padro de especificao utilizando linguagem UML para representar
aplicaes em trs camadas. Sem esse padro as equipes ficam confusas
quanto ao nvel de detalhes que os diagramas devem atingir. Para resolver
esse problema um padro est sendo proposto e as equipes sero treinadas.
Com essas aes o Autor acredita que os diagramas UML sero mais
utilizados. Nesse momento, esses cinco itens da fase de especificao tiveram
suas respostas no checklist alteradas de No para NA.
Os itens 26 e 28 foram considerados como discrepncias. O primeiro item se
refere obrigatoriedade da atividade de solicitao de script ser feita pelo
Analista Responsvel da equipe. Os desenvolvedores declararam que essa
atividade desnecessria, pois eles acabam tendo mais domnio do problema
do que o Analista Responsvel, o qual concorda com essa discrepncia, pois
esse um cargo com muitos afazeres como anlise de bug, solicitaes de
implementao, planejamento da verso, acompanhamento de cronograma,
entre outras.
O item 28 trata da obrigatoriedade de fazer a solicitao de script na etapa de
especificao. Os desenvolvedores alegam que muitas vezes no podem
esperar pela criao do script para que seja feita a implementao e, em outras
vezes, a especificao no deixou claro se ser realmente necessrio a
alterao na base de dados, sendo que existe um custo para que a base de
dados seja alterada para o estado anterior. importante lembrar que a maioria
dos processos de desenvolvimento hoje so incrementais e iterativos. Ou seja,
a especificao pode ser alterada vrias vezes at que o problema seja
finalmente implementado.
Ao final da etapa de discriminao, o relatrio de discrepncia e a Tabela 5.2-A
foram atualizados. A nova tabela pode ser vista abaixo (Tabela 5.4), onde fica
claro que as discrepncias ocorreram somente nos itens 26 e 28. O item 26
serviu de confirmao para uma alterao da fase de Especificao que,
coincidentemente, estava sendo feita pela equipe de engenharia de software
da empresa. A alterao consistia justamente em retirar da responsabilidade do

113

analista Responsvel a funo de solicitao de criao dos scripts de banco

de dados.
O item 28 foi considerado como uma questo nova e interessante, que pode
ser revista no modelo do processo de desenvolvimento. Mas, obviamente
precisa de mais estudos e outras opinies, at mesmo pelo porte da empresa,
que possuem aproximadamente 200 pessoas envolvidas diretamente com o
processo de desenvolvimento.
Tabela 5.4 Informaes levantadas pelo VProcInsp na etapa de Especificao na
fase de Discriminao
Itens do
Checklist
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

RE

Sim

No

NA

Sim
Sim
Sim
Sim
Sim
Sim
Sim
Sim
Sim
Sim
Sim
Sim
Sim
Sim
Sim
Sim
Sim
Sim
Sim
Sim
Sim
Sim
Sim
Sim
Sim
Sim
Sim
Sim

10
0
10
4
4
10
0
10
4
4
10
0
10
4
10
10
10
10
10
10
0
10
10
0
10
0
4
0

0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
4
0
4

0
10
0
6
6
0
10
0
6
6
0
10
0
6
0
0
0
0
0
0
10
0
0
10
0
6
6
6

114

5.5.2 Anlise da utilizao da abordagem

Em paralelo a utilizao e a anlise dos resultados do VProcInsp, foi realizada
uma avaliao da qualidade da tcnica proposta considerando dados coletados
por observao e por questionrios, nos quais, os Inspetores e o Autor
responderam questes relacionadas utilizao da tcnica.
Por observao, presenciou-se a necessidade de criao de dois campos de
informao e uma coluna para os itens do checklist. Os campos: comentrios
e evidncia mostraram-se importantes na etapa de discriminao, deixando
os dados mais coerentes e confiveis. A criao da coluna No aplicvel foi
fundamental para representar o cenrio real da inspeo na etapa de anlise e
comparao. Conseqentemente, esses dois campos e a coluna foram
integrados ao modelo padro do checklist proposto pelo VProcInsp.
A facilidade de inspecionar o processo atravs de checklists foi apontada como
vantajosa, pois, segundo os entrevistados, deixa a inspeo automtica e
simples, sendo caracterizada pelos participantes como um passo a passo, ou
seja, os inspetores so guiados pelos checklists. Foi ressaltada, tambm, a boa
organizao que as etapas propostas pelo VProcInsp proporciona.
Pontos negativos, quanto dificuldade de manipulao dos vrios documentos
no informatizados e quanto manuteno da verso digital, feita em um editor
de texto foram constatados, esses dados podiam ser facilmente alterados ou
mesmo apagados. A ausncia de um feedback online sobre o andamento da
inspeo e um controle de usurios sobre as informaes e documentos
tambm foram citados como desvantagens.

5.6 Consideraes em relao hiptese do estudo

Com base na anlise dos dados da abordagem apresentada na seo 5.5.1,
percebe-se que o VProcInsp foi capaz de apontar duas discrepncias entre a
execuo do modelo e o modelo formal do processo de desenvolvimento sob
estudo. A prpria equipe de engenharia de software da empresa afirmou que
os resultados so relevantes e que j estavam estudando a alterao no
modelo formal do processo para a questo relativa ao item 26 do checklist, e o

115

estudo confirmou essa necessidade. A discrepncia no item 28 tambm foi

considerada uma descoberta importante e que ser alvo de estudos.
Contudo, as consideraes dos itens 26 e 28 podem falsear a hiptese nula
formuladas no estudo de caso. O VProcInsp foi capaz de confirmar uma
discrepncia j conhecida, mas no documentada pela equipe de engenharia
de software, e levantar uma nova discrepncia em um processo que utilizado
h anos e considerado validado mesmo que de forma ad-hoc. Logo, o
VProcInsp mostrou-se capaz de levantar discrepncias entre o modelo de
processo e a execuo do mesmo.
Em relao hiptese que norteia essa dissertao, o estudo mostrou
evidncias que ela pode ser atingida. O VProcInsp foi capaz de executar a
validao de um processo de forma simples, sem a preocupao com um
amplo treinamento e sem a utilizao de grande quantidade de recursos
humano e financeiro.
O VProcInsp pode ser considerado adaptvel, uma vez que os documentos
foram modificados para atender as necessidades dos inspetores e autores e, o
modo em que a validao foi aplicada (somente em duas etapas do processo
durante uma iterao) atendendo as exigncias da gerncia sobre o controle
de acesso de documento.
No foram executadas operaes que comprovariam a capacidade de
extenso do VProcInsp, mas o estudo de caso apontou a possibilidade de se
aplicar outras tcnicas como a Validao de Face ou o uso de tcnicas formais
para medir e exibir os dados coletados pelos checklists.
Assim, o estudo de caso para avaliar o VProcInsp mostrou resultados
preliminares satisfatrios e do indcios que a tcnica de validao proposta
consegue comparar de forma simples, o modelo formal e a execuo do
processo de desenvolvimento. Alm disto, o estudo de caso mostrou a
viabilidade de ser utilizada em ambientes reais. Dessa forma, organizaes
podem realizar a validao de processos de maneira mais sistematizada e
menos subjetiva.

116

CAPTULO 6
CONCLUSES E CONSIDERAES FINAIS

Neste captulo so apresentadas as concluses deste trabalho, relatando as

suas contribuies, limitaes e perspectivas futuras

6.1 Resumo
Com o aumento da demanda e da complexidade dos sistemas, os processos
de desenvolvimento de software vm sendo considerados fundamentais para
que um produto de qualidade seja obtido. Atualmente, empresas de todos os
portes e instituies cientficas fazem uso dos benefcios adquiridos pelo uso
desses processos.
Contudo, os vrios processos de desenvolvimento vm sendo customizados e
outros propostos para atender as necessidades de cada meio produtor de
software, como o caso, respectivamente, do processo da RM Sistemas e do
PESC. Isto faz surgir a necessidade de validar os processos para garantir que
so tangveis de serem seguidos, descartando burocracias desnecessrias ou
constatando a ausncia de uma orientao mais metdica.
Durante a pesquisa que resultou nessa dissertao foram identificadas, atravs
de uma reviso sistemtica, algumas tcnicas de validao de processos
descritas na literatura. Com a caracterizao dessas tcnicas, foi possvel
identificar seus benefcios e limitaes, e foi sugerida uma tcnica de validao
que permite minimizar as limitaes e, suprir a ausncia constatada de tcnicas
de validao de processos bem documentadas e genricas.
A tcnica proposta, intitulada de VProcInsp, caracterizada pela simplicidade
de uso, sem deixar de ser metdica, com fases, papis, atividades e

117

documentos pr-estabelecidos. O VProcInsp tem o objetivo de inspecionar

como os envolvidos na criao de software esto executando o modelo formal
do processo. Para isso, a tcnica proposta faz uso de checklists que so
configurados de acordo com cada processo de desenvolvimento.
A tcnica sugerida foi submetida a um estudo de caso para averiguar suas
atividades, papis e documentos propostos, alm de analisar a sua capacidade
de produzir informaes para validar ou no um processo.
A realizao dessa pesquisa se destaca pela forma como foi desempenhada,
utilizando conceitos oriundos de Verificao & Validao de Software, para
validar processos, seguindo a mesma linha de raciocnio adotada por outros
autores, que visam comparar o modelo formal do processo com a execuo
desse modelo.
Com isso, foi proposta uma tcnica que visa comparar o modelo com a
execuo baseada em inspeo de software, ou seja, conceitos e tcnicas
amplamente utilizados em software, agora, foram utilizados em processos de
desenvolvimento de software, essa tcnica chamada de VProcInsp.
O VProcInsp foi desenvolvido visando ser:

Genrico e Adaptvel para que a tcnica possa ser aplicada na

avaliao de diferentes artefatos do processo de desenvolvimento,
ficando independente, portanto, da abordagem utilizada para cri-los;

Simples para que no seja necessria a execuo de elaboradas

atividades para sua aplicao, a necessidade de tipos de conhecimento
especficos ou a alocao de grandes quantidades de recursos;

Extensvel para que seja facilmente modificvel e permita ser aplicada

com outras tcnicas de validao de processos de desenvolvimento.

Ao trmino deste trabalho, pode-se concluir que:

118

(a) Comparar o modelo formal com a execuo do processo pode ser uma
boa estratgia para validar um processo. Atividades no existentes no
modelo formal, mas freqentemente executadas, ou que so propostas,
e nunca utilizadas pelos stakeholders, podem ser facilmente percebidas
e mostram evidencias que algo no est correto.
(b) A utilizao de conceitos de V&V e, principalmente, da tcnica de
Inspeo de Software torna a validao de processos metdica, pois os
envolvidos sabem exatamente o que devem realizar em cada etapa
estabelecida sem comprometer a simplicidade.
(c) Para aplicar a tcnica, a empresa deve sentir sua necessidade e todos
os envolvidos na validao devem estar empenhados em descobrir
discrepncias e no levar a inspeo para o lado pessoal, pois no a
inteno apontar quem no est seguindo o modelo formal e sim,
apontar por que o modelo no est sendo seguido.
(d) A tcnica proposta pode ficar dependente da estrutura da empresa para
alcanar bons resultados, pois a empresa ou instituio cientfica devem
possibilitar que os inspetores analisem os artefatos, que para o
VProcInsp podem ser documentos de especificao, logs de aplicativos,
caixa de emails, programas de controle de fluxo de atividades, atas de
reunies, entre outros. Logo, se a empresa no armazena ou
disponibiliza tais informaes a credibilidade da tcnica pode ser
reduzida, pois os dados seriam coletados somente atravs de
entrevistas.
Apesar de mostrar indcios que comparar o modelo formal com a
execuo do processo pode ser uma boa estratgia para validar
processos, vrias questes ainda podem ser abordadas. Isto se deve ao
fato que validar um produto, processo ou fenmeno conceitualmente
complexo e se refere a muitas questes subjetivas.
(e) Um processo pode no ser seguido e produzir um resultado satisfatrio,
ou a prtica e o processo podem ser coincidentes, mas o produto final

119

no corresponder s expectativas. Logo, percebe-se a necessidade de

abordar outras variveis no processo de validao, como analisar a
satisfao dos desenvolvedores, usurios e da gerncia da empresa
produtora de software.
(f) A Eficincia pode ser outro ponto interessante de anlise, aonde recurso
e tempo envolvido durante o processo so analisados se so
compatveis com o nvel de desempenho esperado.

6.2 Contribuies
Com base no que foi realizado durante essa pesquisa, pode-se identificar as
seguintes contribuies oferecidas comunidade produtora de software:

Identificao das tcnicas de validao de processo. Atravs da

realizao de uma reviso sistemtica nas principais fontes de
publicaes disponveis, foram levantados trabalhos de diferentes
autores que aplicavam diferentes tcnicas para avaliar e validar um
processo. Foi apresentada, tambm, uma diferenciao entre avaliar e
validar um processo.

Identificao das tcnicas de Verificao e Validao de Software.

Atravs da realizao de uma reviso sistemtica nas principais fontes
de publicaes disponveis, foram levantados conceitos e tcnicas de
V&V, principalmente, tcnicas informais.

Proposta de uma tcnica de Validao por Inspeo. Fazendo uso

de conceitos, diretrizes e tcnicas consolidadas de V&V de software, o
VProcInsp foi proposto, tornando a tarefa de validar um processo de
desenvolvimento, metdica, com fases, papis e atividades bem
definidas, sem deixar de ser simples, adaptvel e extensvel.

Planejamento e execuo do Estudo de caso visando a avaliao

da tcnica em um ambiente real. Alm da criao da abordagem, um

120

estudo experimental foi planejado e executado para avaliar a viabilidade

e a eficincia da tcnica proposta. Esse estudo serviu para transferir
essa tecnologia do meio acadmico para um ambiente real e mostrou
fortes evidncias de sua viabilidade e eficincia, contribuindo com
informaes relevantes para a empresa TOTVS S.A.

6.3 Limitaes
Ao analisar a tcnica proposta foram identificadas algumas limitaes. Uma
delas que o estudo realizado forneceu somente resultados preliminares sobre
o processo validado. Isso ocorreu por no ser possvel realizar um estudo mais
amplo na empresa, englobando todas as etapas, um maior nmero de produtos
e requisitos.
Seria importante aplicar a tcnica proposta em outras empresas, com
diferentes processos para que os resultados fossem considerados definitivos

6.4 Trabalhos Futuros

Entre os trabalhos futuros sugeridos no intuito de dar continuidade a esta
pesquisa podemos citar:

A realizao de outros estudos de caso, aplicando o VProcInsp em

outras empresas ou mesmo no meio acadmico, buscando resultados
definitivos, uma vez que o estudo de caso apresentado nessa pesquisa
foi direcionado somente ao amadurecimento da tcnica proposta.

A pesquisa pode ser ampliada aplicando outras tcnicas de validao

como, por exemplo, a validao de fase ou tcnicas formais (uso
matemtico) para auxiliar o uso do checklist e a apresentao dos

121

resultados, ponderando os valores encontrados e comprovando, assim,

a extensibilidade do VProcInsp.

Outra contribuio importante a construo de uma ferramenta

computacional de apoio a todas as fases, atividades e documentos
propostos pelo VProcInsp. Esta ferramenta pode controlar o fluxo das
atividades, limitar permisses de acesso a documentos de acordo com o
perfil de cada usurio e, armazenar informaes sobre os participantes e
processos validados criando um banco de dados de validao para
possveis consultas.

Verificar a aplicabilidade de outras tcnicas de V&V ou das normas da

ISO 9126, ISO 12207 ou do modelo CMMI para auxiliar na busca por
anlises da satisfao e eficincia do processo de desenvolvimento de
software a ser validado.

122

REFERNCIAS BIBLIOGRFICAS

ACKERMAN, A., BUCHWALD, L., LEWSKI, F., Software Inspections: An

Effective Verification Process, IEEE Software, Vol. 6 No. 3 p. 31-37, 1989.
ASTELS D., MILLER G., NOVAK M., eXtreme Programming: Guia prtico,
Campus, Rio de Janeiro, 2002.
AMARAL, E.A.G. Empacotamento de Experimentos em Engenharia de
Software, Dissertao de Mestrado, Programa de Engenharia de Sistemas e
Computao COOPE/RJ, 2003.
BALCI Osman. Validation, Verification, and Testing Techniques throughout the
Life Cycle of a Simulation Study. Proceedings of the 26 th Winter Simulation
Conference, Blacksburg, Virginia. p 215-220, 1994
BALCI Osman. Principles and Techniques of Simulation Validation, Verification,
and Testing. Proceedings of the 27 th Winter Simulation Conference, Arlington,
Virginia. p 147-154, 1995.
BARCELOS, R.F., TRAVASSOS, G.H., Avaliando documentos arquiteturais
atravs de um checklist baseado em atributos de qualidade. In proceedings of
Workshop de Teses e Dissertaes de Engenharia de Software (WTES)
SBES, Uberlncia, MG, 2005.
BANKS, J., GERSTEIN, D., SEARLES, S. P., Modeling processes, validation,
and verification of complex simulations: A survey, Methodology and Validation,
Simulations Series, vol. 19 No. 1. The Society of Computer Simulation, 13 18,
1988
BECK K., Extreme Programming Explained. Boston, MA: Addison-Wesley,
2000.

123

BIFFL, S., GROSSMANN, W., 2001, Evaluating the accuracy of objective

estimation models based on inspection data from multiple inspeciont cycles.
ACM/IEEE ICSE, Toronto, Canada, IEEE Comp. Soc. Press, 2001.
BOEHM B., Software Engineering Economics, 1st edition. Prentice-Hall, 1981.
BORGES E.P., PAULA, W.P. Um modelo de medio para processos de
desenvolvimento de software, SIMPROS, 2003.
EJIOGU, Lem O. Five principles for the formal validation of models of software
metrics. ACM SIGPLAN Notices, vol 28, No 8, 1993.
CHMURA, L. J., WICINSKI, T. J., and NORCIO, A. F. Evaluating software
design processes by analyzing change data over time. IEEE Transactions on
Software Engineering. vol. 16, p. 729740, 1990
COOK, Jonathan E., WOLF, Alexander L. Software Validation: Quantitatively
Measuring the Correspondence of a Process to a Model. ACM Transactions on
Software Engineering and Methodology. vol 8 No 2, p. 147-176,1999.
COOK, C., VISCONTI, M. Issues in Software Process Assessment and
Validation. Proceedings 21st ACM Computer Science Conference, Indianapolis
IN, 1993.
FAGAN, M.E. Design and code inspection to reduce Errors in Program
Development, IBM Systems Journal, v. 15, n. 3, pp 182-211,1976
FERREIRA, B.; MOITA, G. F. Avaliao de tcnicas para validao em
processos de desenvolvimento de software. In: VIII Simpsio de Mecnica
Computacional, Belo Horizonte: PUC MInas,. vol. 1. p. 1-15, 2008 a
FERREIRA, B.; MOITA, G. F. The evaluation of different validation techniques
for software development process. In: 8th World Congress on Computational

124

Mechanics WCCM8, Veneza. Proceedings of the 8th World Congress on

Computational Mechanics, v. 1. p. 1-2, 2008 b.
FGV,

Site

da

Fundao

Getlio

Vargas

acessado

em

25/08/2008

http://www.fgv.br/fgvportal/principal/idx_materia.asp?str_chave=11269&sessao=2,

2008
GARG, P. K., Process Modeling of Software Reuse, 1992. In Proceedings of
the 5th International Workshop on Institutionalizing Software Reuse, Palo Alto.
GILB, T., GRAHAM, D. Software Inspecion. Addison-Wesley, 1993.
HUMPHREY, W. S. A Discipline for Software Engineering. Addison-Wesley.
Reading-MA, 1995.
IEEE, IEEE Recommended Practice for Software Requirements Specifications
Description, Standart 830, IEEE Press. 1998.
JACOBSON, I.; RUMBAUGH, J.; BOOCH, G. The Unified Software
Development Process. Addison-Wesley, Reading MA, 1999.
JOHN R. C., STEVE M. E. Verification and Validation in a Rapid Software
Development Process, NASA Software IV&V Facility, 2000.
JOHNSON, P. An Instrumented Approach to Improving Software Quality
through Formal Technical Review, in proc. 16th International Conference on
Sotware Engineering, Sorrento, Italy, 1994.
KNEPELL, P. L., ARANGNO, D. C., Simulation validation: A confidence
assessment methodology, IEEE Computer Society Simulation, 1993.
KALINOWSKI, M. Infra-Estrutura Computacional de Apoio ao Processo de
Inspeo de Software, Dissertao de Mestrado, Programa de Engenharia de
Sistemas e Computao COPPE/UFRJ, Rio de Janeiro, 2004

125

KRUSKAL, J. B. An overview of sequence comparison. In Time Warps, String

Edits, and Macromolecules: The Theory and Practice of Sequence Comparison.
In Proceedings of SIAM 1983 - Society for Industrial and Applied Mathematics.
vol 25 No 2 p 201-237, 1983.
LAITENBERGER,

O.,

ATKINSON,

C.

Generalized

Perspective

Based

Inspection to handle Object Oriented Development Artifacts, Proccedings of

ICSE 99, p. 494-503., 1998
LARMAN, C. Utilizando UML e Padres: uma introduo anlise e ao projeto
orientado a objetos e ao Processo Unificado. Trad. Luiz Augusto Meirelles
Salgado e Joo Tortello. 2 ed. Porto Alegre: Bookman, 2004.
LANUBILE,

F.,

MALLARDO,

T.,

CALEFATO,

F.,

Tool

support

for

Geographically Dispersed Inspection Teams, Software Process Improvement

and Practice, Vol. 8: p.217-231 (DOI: 10.1002/spip.184)., 2003.
MELLO, A.M.V. Processo de Desenvolvimento de Software: Uma abordagem
para

Melhoria

Contnua

da

Qualidade.2004.

Disponvel

em

http://santafe.ipt.br/tede/tde_busca/arquivo.php?codArquivo=226 Acesso em: 28

de julho de 2008.
MOOR, A., DELUGACH H. Software Process Validation: Comparing Process
and Practice Models. In Contributions to ICCS 2005, Kassel, Germany. p 533540, 2005
NAS

System

Engineering

Manual

verso

3.1

fonte:

http://www.faa.gov/about/office_org/headquarters_offices/ato/service_units/oper
ations/sysengsaf/seman/SEM3.1/Section%204.14%20v3.pdf

acessado

em

30/03/2008, 2006
OBERKAMPF, W.L., TRUCANO, T.G., Verification and validation benchmarks,
Nuclear Eng. Design, Validation and Uncertainty Estimation Department,
Sandia National Laboratories, vol 238 p. 716-743, 2007.

126

PAULA, W. P. Engenharia de Software Fundamentos, Mtodos e Padres. 2

ed. LTC Editora. Rio de Janeiro - RJ, 2003.
PEREIRA Jr, M. Concepo de um Processo Especfico para Software
Cientfico. Dissertao de Mestrado. Centro Federal de Educao Tecnolgica
de Minas Gerais CEFET-MG. Belo Horizonte, 2007.
PERRY, William. Effective Methods for Software Testing. John Wiley & Sons,
1995.
PRESSMAN, R. S. Engenharia de Software. 6 ed. Rio de Janeiro: McGrawHill, 2006.
PURRI, M. C. M. S; PEREIRA Jr, M.,; MOITA, G. F. PESC Processo de
Desenvolvimento Especfico para Software Cientfico: Propostas Iniciais. XXVII
CILAMCE Iberian Latin American Congress on Computational Methods in
Engineering Belm-PA, 2006
PURRI, M. C. M. S. Estudo e Propostas Iniciais para a Definio de um
Processo de Desenvolvimento para Software Cientfico. Dissertao de
Mestrado. Centro Federal de Educao Tecnolgica de Minas Gerais
CEFET-MG. Belo Horizonte, 2006.
RAMOS, C., ZITA A., VALE, L., SANTOS, J., Aplicaes Inteligentes em
Centros de Controlo: Verificao e Validao, Jornadas Luso-Espanholas de
Engenharia Electrotcnica, Salamanca, Spain, July 1997
SARGENT, Robert G., Verification, Validation, and Acreditation of Simulations
Model, Proc. Of the 2000 Winter Simulation Conference. p. 50-59, 2000
SARGENT, Robert G., Some Approaches and Paradigms for Verification and
Validation Simulations Model, Proc. Of the 2001 Winter Simulation Conference.
p. 50-59, 2001.

127

SAUER, C., JEFFERY, D.R., LAND, L., YETTON, P. The Effectiveness of

Software Development Technical Review: A Behaviorally Motivated Program of
Research, IEEE Transactions on Software Engineering 26, 1-14, 2000.
SHULL, F. Developing Techniques for Using Software Documents: A Series of
Empirical Studies, Ph.D. thesis, University of Maryland, College Park, 1998.
SOMMERVILLE, I., Engenharia de Software. 8 ed. So Paulo: Addison
Wesley, 2007.
SVAHNBERG, M., A study on agreement between participants in an
architecture assessment. In proceedings of the International Symposium on
Empirical Software Enginneering ISESE, p 61-70, 2003.
TRAVASSOS G. H., KALINOWSKI, M, SPNOLA R. O., Introduo Inspeo
de Software Aumento da qualidade atravs de verificaes intermedirias,
Engenharia de Software Magazine, Ano 1, 1 edio, 2007.
TICHY, W.F. Should Computer Scientists Experiment More? IEEE Software,
Vol. 31, No. 5, p. 32-39, 1998.
WALLIN, C. Verification and Validation of Software Components and
Components Based Software Systems. - Based Software Systems. Artech
House Publishers, 2002. fonte: http://www.idt.mdh.se/cbse-book/extendedreports/05_Extended_Report.pdf acessado em 01/11/2007.
WHEELER, D.A., BRYKEZYNSKI, B., MEESON, R.N., Software Inspetion: Na
Insdustry Best Practice, IEEE Computer Society, 1996.
WOHLIN, C., RUNESON, P., HOST, M. OHLSSON, M.C., REGNELL, B.,
WESSLEN, A. Experimentation in Software Engineering: an Introduction, 2000.
WIKIPEDIA A enciclopdia livre. Disponvel em: http://www.wikipedia.com.br.
Acessado em 05/06/2008.

128

Apndice A
Documentos do VProcInsp Aplicados no Estudo de Caso
Planejamento
VProcInsp Validao de Processo de Desenvolvimento de Software por Inspeo
Documento de Definies do Planejamento
Moderador..: Bruno Ferreira
Autor(es)...: Isabela Iunes de Oliveira
Sandra Cristina de Andrade Soares
Data de Inicio: 30/06/2008
Data de Trmino prevista: 04/07/2008
Nome do Processo de Desenvolvimento: Processo de Desenvolvimento RM V. 2.0
Descrio do Processo de Desenvolvimento:

Caractersticas:
- Baseado no Processo Unificado
- Iterativo e Incremental
- Poucos artefatos obrigatrios
- Modelagem com UML
- Criao de produtos orientado a objetos em duas e trs camadas
Aplicar inspeo no final das (os):
Etapas
Iteraes
Projeto
Inspetores Selecionados:

Outros

1) Tllio Mendes Rodrigues

Checklist entregue

2) Srgio Gontijo do Nascimento

Checklist entregue

3) Clique aqui para digitar texto.

Checklist entregue

4) Clique aqui para digitar texto.

5) Clique aqui para digitar texto.

Checklist entregue
Checklist entregue

Apresentao Realizada
Sim
No
Data da Realizao: 01/07/2008
Observaes:
As inspees sero realizadas em duas etapas em uma iterao do processo.

129
Abaixo so listados os 10 requisitos que foram inspecionados durante a execuo do
processo de desenvolvimento.
01) 1287098 Rateio Default de Itens de Contrato
02) 874346 Centro de Custo
03) 790414 Manter Contrato
04) 790435 Implementar Associao Total ao item do contrato
05) 790436 Implementar Associao parcial ao item do contrato
06) 790446 Implementar Realinhamento de Preo
07) 1286910 Calculo de Projeto Calculo de Insumo com vigncias
08) 1286913 Calculo de Projeto Calculo de Composies com vigncias
09) 1286920 Calculo de Projeto Calculo de Tarefas com vigncias
10) 1278552 Calculo de Projeto Calculo da Curva ABC e S utilizando Vigncia

VProcInsp Validao de Processo de Desenvolvimento de Software por Inspeo

Documento de Informaes dos Inspetores
ID: 00001
Inspetor..: Sergio Gontijo do Nascimento
Nvel de experincia com desenvolvimento de software
1
2
3
4
5
Nvel de experincia com o domnio do ambiente processo de desenvolvimento
1
2
3
4
5
Nvel de experincia com validao de processos
1
2
3
4
5
1-Nenhum
2-Pouco
3-Razovel
4-Suficiente
5-Alto
Nome dos Processos de Desenvolvimento j validados pelo inspetor
1) _______________________________________________
2) _______________________________________________
3) _______________________________________________
4) _______________________________________________
5) _______________________________________________
Estatstica com o nmero de erros por categorias levantados pelo inspetor
_______Omisso ________Ambigidade ________Inconsistncia ________Outro
Curriculum:
Analista de sistemas com mais de 15 anos de experincia no desenvolvimento de
aplicaes para ambiente Windows utilizando orientao a objetos, multicamadas, bancos
de dados relacionais e ferramentas de modelagem de dados e processos. Experincia no
uso de Delphi e Microsoft .NET. Formao acadmica em Cincia da Computao pela PUC
Minas e MBA pelo Ibmec.
Observaes:

VProcInsp Validao de Processo de Desenvolvimento de Software por Inspeo

130
Documento de Informaes dos Inspetores
ID: 00002
Inspetor..: Tllio Mendes Rodrigues
Nvel de experincia com desenvolvimento de software
1
2
3
4
5
Nvel de experincia com o domnio do ambiente processo de desenvolvimento
1
2
3
4
5
Nvel de experincia com validao de processos
1
2
3
4
5
1-Nenhum
2-Pouco
3-Razovel
4-Suficiente
5-Alto
Nome dos Processos de Desenvolvimento j validados pelo inspetor
1) _______________________________________________
2) _______________________________________________
3) _______________________________________________
4) _______________________________________________
5) _______________________________________________
Estatstica com o nmero de erros por categorias levantados pelo inspetor
_______Omisso ________Ambigidade ________Inconsistncia ________Outro
Curriculum:

Desenvolvedor de sistemas com sete anos de experincia criando aplicaes orientada

a objetos utilizando Delphi e Dot Net. Experincia com manuteno em banco de
dados relacionais e implantao de sistemas. Formao tcnica em Processamento de
dados e graduado em Gesto Financeira.
Observaes:

VProcInsp Validao de Processo de Desenvolvimento de Software por Inspeo

Documento de atribuies de Inspetores
ID do Inspetor: 00001
Inspetor..: Sergio Gontijo do Nascimento
Lista com os identificadores dos checklists sob responsabilidade do inspetor.
- 002 [responsvel por todos os itens do checklist de Implementao]
ID do Inspetor: 00002
Inspetor..: Tllio Mendes Rodrigues
Lista com os identificadores dos checklists sob responsabilidade do inspetor.
- 001 [responsvel por todos os itens do checklist de Especificao]

Observaes:
Como sero validadas somente duas etapas, no foi necessrio dividir os itens de um
mesmo checklist entre os inspetores. Sendo que cada inspetor responsvel por todos os
itens do seu checklist.

131

Anlise e Comparao

VProcInsp Validao de Processo de Desenvolvimento de Software por Inspeo

Checklist de Inspeo
*Instrues

Avalie as discrepncias entre o modelo formal do processo e a execuo do mesmo somente na fase
de Especificao atravs dos itens de avaliao que compem o checklist.

Busque discrepncias entre o processo e a execuo do mesmo. Sem identificar possveis erros de
anlises, modelagem, implementao ou testes. Se atente apenas s discrepncias.

Analise as discrepncias nos requisitos listados abaixo.
01) 1287098 Rateio Default de Itens de Contrato
02) 874346 Centro de Custo
03) 790414 Manter Contrato
04) 790435 Implementar Associao Total ao item do contrato
05) 790436 Implementar Associao parcial ao item do contrato
06) 790446 Implementar Realinhamento de Preo
07) 1286910 Calculo de Projeto Calculo de Insumo com vigncias
08) 1286913 Calculo de Projeto Calculo de Composies com vigncias
09) 1286920 Calculo de Projeto Calculo de Tarefas com vigncias
10) 1278552 Calculo de Projeto Calculo da Curva ABC e S utilizando Vigncia

Caso a sua resposta seja diferente da Resposta Esperada - RE (No - N, Sim - S); uma discrepncia
entre o modelo formal e a execuo foi descoberta.

Nas colunas Sim, No e NA (No aplicvel) de cada item do checklist devem ser preenchidas com
valores inteiros entre zero e dez. Aonde zero significa que nenhum requisito obteve a resposta e dez
significa que todos os dez requisitos obtiveram a resposta sim ou no ou NA. Ateno: A soma das
trs colunas deve ser igual a dez.

O campo Comentrio fica disponvel caso o inspetor queira fazer algum comentrio a respeito de um
requisito ou alguma situao em que a discrepncia precisa ser esclarecida.

O campo Evidncia tem a funo de indicar a origem da inspeo que gerou uma discrepncia ou
no. Ou seja, informa o artefato que foi inspecionado. Esse campo pode assumir os valores:
Ferramentas, Doc. Tcnicos, Doc. Gesto, Logs, Ata de Reunio, Email, softwares utilizados no
processo e outros.

Caso haja dvida em relao aos termos utilizados ou nos itens do checklist pea informaes ao
moderador.

Leia as subsees Fase/Atividade, Principais Objetivos e Importncia para ampliar o conhecimento
sobre o contexto da inspeo.
*ID do CheckList..: 001
*Inspetor..............:Tllio Mendes Rodrigues
*Fase/Atividade..:

132

*Principais Objetivos
Criar/Atualizar Regras de Negcio

Especificar detalhadamente as regras de negcio contidas no processo que est sendo
desenvolvido.
Criar/Atualizar Casos de Uso/Outros Diagramas

Possibilitar o entendimento da funcionalidade do sistema em um nvel mais voltado ao
negcio a todos os envolvidos no projeto.
Criar/Atualizar Glossrio

Definir a terminologia especfica do problema de domnio, explicando termos que
possam ser desconhecidos ao leitor das descries dos casos de uso ou outros
documentos do projeto.
Solicitar Criao/Atualizao de Script

Escrever scripts com as alteraes na base de dados necessrias para as
implementaes do Caso de Uso.
Criar Script de Alterao na Base de Dados

Escrever scripts com as alteraes na base de dados necessrias para as
implementaes do Caso de Uso.

*Importncia
Criar/Atualizar Regras de Negcio

Fonte de informao para entendimento das regras de negcio pertinentes a cada
funcionalidade que est sendo especificada.
Criar/Atualizar Casos de Uso/Outros Diagramas

Fonte de informao para realizao dos casos de testes, futuros testes de
funcionalidade e contribuio na documentao do produto. Fonte de consulta futura de
novas implementaes e anlise de impacto.
Criar/Atualizar Glossrio

Documentar os termos utilizados na especificao.
Solicitar Criao/Atualizao de Script

Escrever scripts padronizados que sero enviados para os clientes, em forma de
Conversor de base de dados em uma data pr-estabelecida, com o objetivo de ter a
bases de dados de todos os clientes com a mesma estrutura.

133
Criar Script de Alterao na Base de Dados

Escrever scripts padronizados que sero enviados para os clientes, em forma de
Conversor de base de dados em uma data pr-estabelecida, com o objetivo de ter a
bases de dados de todos os clientes com a mesma estrutura.

Entradas
N Descrio do Item de Avaliao
A Aplicao Delphi ou Documentos de Especificao ou outros
01

Sim
10

documentos de especificao que por ventura j existam

serviu como entrada para Criar/Atualizar Regras de Negcio?
Comentrio: Os requisitos 01 ao 06 utilizaram o Delphi como

Evidncia: Entrevista

No
0

NA
0

RE
Sim

documento de especificao. Os requisitos 07 at 10 utilizaram

documentos de especificao j existentes.
02

requisitos.

Evidncia: Entrevista e o RM
Especfica
10
0
0
Sim

A aplicao Delphi e o RM Especifica contendo todos os

requisitos do produto serviram como entrada para
Criar/Atualizar Casos de Uso e/ou Outros Diagramas?
Comentrio: No foram encontrados diagramas UML para esses

03

O Documento de especificao serviu como entrada para

Criar/Atualizar Glossrio?
Comentrio: O glossrio foi construindo seguindo a especificao

dos

dez requisitos
04

Uma Ocorrncia foi utilizada como entrada para Solicitar

Criao/Alterao de Script?
Comentrio: Os requisitos 01 ao 06 no necessitaram de alteraes

10

Sim

Evidncia: Entrevista e o
Glossrio
4
0
6
Sim
Evidncia: RM Agilis

na Base de dados. Somente os requisitos 07, 08, 09 e 10 utilizaram

scripts.
05

Uma Ocorrncia foi utilizada como entrada para a atividade de

Criar Script de Alterao na Base de Dados?
Comentrio: Os requisitos 01 ao 06 no necessitaram de alteraes

Sim

Evidncia: RM Agilis

na Base de dados. Somente os requisitos 07, 08, 09 e 10 utilizaram

scripts.
Sadas
N Descrio do Item de Avaliao
Foi criada a Especificao de Regras de Negcio?
06

O documento ss\RM.Net\Source\PrjProjetos\Projeto\
E_BR-Regra deNegocio.doc foi atualizado com as informaes

Comentrio:

07

Foi gerada a Especificao dos Casos de Uso ou Outros

Diagramas?
Comentrio: No foram encontrados diagramas UML para esses

requisitos.
08

Foi criado ou atualizado o Glossrio?

Comentrio: O documento ss\RM.Net\Source\PrjProjetos\Projeto\

E_G-Glossrio.doc foi atualizado com as informaes

09

Foi criada uma ocorrncia para o DBA vinculada com a

ocorrncia de origem?
Comentrio: Os requisitos 01 ao 06 no tiveram novas ocorrncias

Sim
No
NA
RE
10
0
0
Sim
Evidncia: Documento de
Especificao
0
10
0
Sim
Evidncia: Documento de
Especificao
10
0
0
Sim
Evidncia: Documento de
Especificao
4
0
6
Sim
Evidncia: RM Agilis

vinculadas ocorrncia original. Somente os requisitos 07, 08, 09 e 10

utilizaram scripts e foram vinculadas.
10

recebidos para os requisitos 07 ao 10.

Evidncia: RM Agilis e MS
Outlook

O script e a ocorrncia foram encaminhados para o Analista

responsvel?
Comentrio: No email do desenvolvedor continham os scripts

Sim

134

N
11

Passos
Descrio do Item de Avaliao

Ao final da Criao/Atualizao das Regras de Negcio, os

documentos de sada foram atualizados no Source Safe?
Comentrio:Analisando a ultima verso do documento no SourceSafe

Sim
10

No
0

NA
0

RE
Sim

Evidncia: MS SourceSafe

pode-se verificar que o documento foi atualizado

12

Ao final da atividade de Criar/Atualizar Casos de Uso e/ou

Outros Diagramas, os documentos de sada foram atualizados
no Source Safe?
Comentrio: No existem diagramas UML para esses requisitos no

10

Sim

Evidncia: MS SourceSafe

SourceSafe
13

O check out/in foi executado no Glossrio ao ser

Criado/Atualizado ?
Comentrio: Analisando a ultima verso do documento no SourceSafe

10

Sim

Evidncia: MS SourceSafe

pode-se verificar que o documento foi atualizado

14

percebe-se que os scripts para os requisitos 07 ao 10 foram recebidos.

Evidncia: MS SourceSafe e
email

Ferramentas
N Descrio do Item de Avaliao
Foi utilizado o MS Word, MS Visio ou Source Safe ao
15

Sim
10

O DBA encaminhou o Script para o Analista Responsvel e o

arquivo
ss/RMGlobalDados/RMConversor/RMConversor_[BancodeDado
s] foi atualizado ao Criar Script de Alterao na Base de
Dados?
Comentrio:Verificando o email e do desenvolvedor e no SourceSafe

Criar/Atualizar Regras de Negcio?

Comentrio: Software padres e controlados

pela equipe de Infra-

Estrutura da empresa.
16

Foi utilizado o MS Visio, MS Word, MS Excel, VSS, RM

Especifica ao Criar/Atualizar Casos de Uso e/ou Outros
Diagramas?
Comentrio: Software padres e controlados pela equipe de Infra-

Estrutura da empresa.
17

Foi utilizado o MS Word e o SourceSafe ao Criar/Atualizar o

Glossrio?
Comentrio: Software padres e controlados pela equipe de Infra-

Estrutura da empresa.
18

Foi utilizado o RM Agilis para criar e vincular as ocorrncias de

entrada e sada ao Solicitar Criao/Alterao de Script?
Comentrio: Software padres e controlados pela equipe de Infra-

Estrutura da empresa.
19

Foi utilizado o RM Agilis, SQL Server e Oracle ao Criar Script

de Alterao na Base de Dados?
Comentrio: Software padres e controlados pela equipe de Infra-

Estrutura da empresa.

N
20

Templates
Descrio do Item de Avaliao
Os templates disponveis em

No
0

Sim

NA
0

RE
Sim

Evidncia: Software
Instalados e Extenso dos
artefatos
10
0
0
Sim
Evidncia: Software
Instalados e Extenso dos
artefatos
10
0
0
Sim
Evidncia: Software
Instalados e Extenso dos
artefatos
10
0
0
Sim
Evidncia: Software
Instalados e Extenso dos
artefatos
10
0
0
Sim
Evidncia: Software
Instalados e Extenso dos
artefatos
Sim
10

No
0

NA
0

RE
Sim

135
SS\RM.NET\Source\RM.Templates\RM.Docs\E_BR RegrasNegocio.dot
foram utilizados ao Criar/Atualizar Regras de Negcio?
Comentrio: Os documentos preenchidos tm a mesma estrutura

dos

arquivos default dispostos no SourceSafe.

21

Os templates disponveis em
SS\RM.NET\Souce\RM.Templates\RM.Docs\ E_UC - Caso
de Uso.dot foram utilizados ao Criar/Atualizar Casos de Uso
e/ou Outros Diagramas?
Comentrio: No foram criados diagramas de caso de uso para os

requisitos. Logo os templates no foram utilizados.

22

Os templates disponveis em
SS\RM.NET\Source\RM.Templates\RM.Docs\E_G
Glossario.dot foram utilizados ao Criar/Atualizar o
Glossrio?
Comentrio: Os documentos preenchidos tm a mesma estrutura dos

Evidncia: Documento de
especificao
0
10
0
Sim

Evidncia: Documento de
especificao
10
0
0
Sim

Evidncia: Documento de
especificao

arquivos default dispostos no SourceSafe.

Responsveis
N Descrio do Item de Avaliao
Sim
O Desenvolvedor foi responsvel por Criar/Atualizar Regras de 10
23
Negcio?
Comentrio: Log de quem executou o check in do arquivo
O Desenvolvedor foi responsvel por Criar/Atualizar Casos de
24
Uso e/ou Outros Diagramas?
Comentrio: No existem diagramas UML para esses requisitos no

No
0

NA
0

RE
Sim

Evidncia: MS SourceSafe
0
10
0
Sim
Evidncia: MS SourceSafe

SourceSafe
25

O Desenvolvedor foi responsvel por Criar/Atualizar o

Glossrio?
Comentrio: Log de quem executou o check in do arquivo
Analista Responsvel foi o responsvel por Solicitar ao
26
Criao/Atualizao do Script?
Comentrio: Informaes retirada da viso de Repasses no RM Agilis
O Administrador de Banco de Dados foi o responsvel por
27
Criar Script de Alterao na Base de Dados?
Comentrio:Log de quem executou o check in do arquivo

10

Sim

Evidncia: MS SourceSafe
0
4
6
Sim

Evidncia: RMAgilis
0
6
Sim

Evidncia: MS SourceSafe

Observaes
Ao inspecionar os artefatos para responder o item 26 o inspetor relatou a seguinte discrepncia: A
solicitao de criao de script feita na etapa de Implementao e no na Etapa de Especificao.
Evidncia: A data de abertura de ocorrncia para os scritps eram posteriores ao apontamento de horas
na fase de implementao. Ou seja, as datas de abertura de solicitao eram feitas depois do
encerramento da fase de Especificao

136
VProcInsp Validao de Processo de Desenvolvimento de Software por Inspeo
Checklist de Inspeo
*Instrues

Avalie as discrepncias entre o modelo formal do processo e a execuo do mesmo somente na fase
de Especificao atravs dos itens de avaliao que compem o checklist.

Busque discrepncias entre o processo e a execuo do mesmo. Sem identificar possveis erros de
anlises, modelagem, implementao ou testes. Se atente apenas s discrepncias.

Analise as discrepncias nos requisitos listados abaixo.
01) 1287098 Rateio Default de Itens de Contrato
02) 874346 Centro de Custo
03) 790414 Manter Contrato
04) 790435 Implementar Associao Total ao item do contrato
05) 790436 Implementar Associao parcial ao item do contrato
06) 790446 Implementar Realinhamento de Preo
07) 1286910 Calculo de Projeto Calculo de Insumo com vigncias
08) 1286913 Calculo de Projeto Calculo de Composies com vigncias
09) 1286920 Calculo de Projeto Calculo de Tarefas com vigncias
10) 1278552 Calculo de Projeto Calculo da Curva ABC e S utilizando Vigncia

Caso a sua resposta seja diferente da Resposta Esperada - RE (No - N, Sim - S); uma discrepncia
entre o modelo formal e a execuo foi descoberta.

Nas colunas Sim, No e NA (No aplicvel) de cada item do checklist devem ser preenchidas com
valores inteiros entre zero e dez. Aonde zero significa que nenhum requisito obteve a resposta e dez
significa que todos os dez requisitos obtiveram a resposta sim ou no ou NA. Ateno: A soma das
trs colunas deve ser igual a dez.

O campo Comentrio fica disponvel caso o inspetor queira fazer algum comentrio a respeito de um
requisito ou alguma situao em que a discrepncia precisa ser esclarecida.

O campo Evidncia tem a funo de indicar a origem da inspeo que gerou uma discrepncia ou
no. Ou seja, informa o artefato que foi inspecionado. Esse campo pode assumir os valores:
Ferramentas, Doc. Tcnicos, Doc. Gesto, Logs, Ata de Reunio, Email, softwares utilizados no
processo e outros.

Caso haja dvida em relao aos termos utilizados ou nos itens do checklist pea informaes ao
moderador.

Leia as subsees Fase/Atividade, Principais Objetivos e Importncia para ampliar o conhecimento
sobre o contexto da inspeo.
*ID do checklist.........: 002
*Inspetor.........:Srgio Gontijo do Nascimento
*Fase/Atividade..:

137

*Principais Objetivos
Analisar implementao

Buscar o entendimento do requisito antes da implementao/correo do mesmo;

Verificar se todas as informaes necessrias a implementao esto contidas na
especificao do requisito;

Identificar eventuais inconsistncias.
Implementar

Escrever o cdigo que implementa o requisito.
Realizar Teste Preliminar

Verificar se o cdigo fonte funciona efetivamente, independente do resto do sistema;

Identificar se existe algum gargalo de processamento;

Verificar a cobertura do cdigo;

Verificar utilizao de memria;

Verificar impactos em outros pontos do sistema.
Publicar Implementao

Armazenar o cdigo fonte em local previamente estabelecido;

Armazenar o Cdigo Fonte em lugar centralizado, de forma a possibilitar execuo de
backups;

Proteger o Cdigo Fonte contra problemas na mquina do Desenvolvedor;

Possibilitar o compartilhamento do Cdigo Fonte com os demais desenvolvedores;

Manter histrico das alteraes no Cdigo Fonte.

*Importncia
Analisar implementao

138

Conhecer o que precisa ser implementado/corrigido para saber qual ao tomar.
Implementar

Atravs desta atividade estamos concretizando uma implementao.
Realizar Teste Preliminar

Esta tarefa importante, pois uma vez que este teste seja bem feito, quando o
desenvolvedor encaminhar uma verso para o QSW homologar, a chance de existirem
erros menor, evitando assim possveis retrabalhos.
Publicar Implementao

Depois do cdigo fonte devidamente implementado (estiver compilando) deve-se
disponibilizar o cdigo fonte no SourceSafe. Esta tarefa importante para proteger e
compartilhar o cdigo fonte.

N
01

Entradas
Descrio do Item de Avaliao

Existe uma Ocorrncia para a Anlise de

Implementao?
Comentrio: Verificado as ocorrncias cadastradas
02
Os Documentos de Especificao do Mdulo,
Ocorrncia e Wizard de Gerao de Cdigo serviram
como entrada para a Implementao?
Comentrio:
03
O Cdigo Fonte, Documento de Especificao e a
Ocorrncia serviram de entrada para os Testes
Preliminares?
Comentrio:
04
O Cdigo Fonte e a Ocorrncia serviram de entrada
para Publicar a implementao?
Comentrio:

Sim
10

No
0

NA

RE

Sim

Evidncia: RM Agilis
10
0
0

Sim

Evidncia: Entrevista
10
0
0

Sim

Evidncia: Entrevista
10
0
0

Sim

Evidncia: Entrevista

Sadas
N
05

Descrio do Item de Avaliao

A ocorrncia foi analisada e classificada como Bug ou

implementao e a prioridade foi definida na Anlise de
Implementao?
Comentrio: No momento da inspeo essas informaes

Sim
10

No
0

NA
0

RE
Sim

Evidncia: No verificvel

estavam cadastradas. Mas no se pode afirmar se na fase de

Anlise de Implementao isso foi feito.
06

O Cdigo Fonte foi criado e as Actions foram

cadastradas no RM Especifica na Implementao?
Comentrio:Anlise realizada no cdigo fonte e buscar

10

Sim

Evidncia: RM Especifica

realizadas no RM Especifica foram as fontes de informao desse

item.
07

SouceSafe foi atualizado juntamente com o campo

discusso de acordo com o padro ao Publicar a
Implementao?
Comentrio: No SourceSafe e no RM Agilis as informaes foram

10

Sim

Evidncia: MS SourceSafe

comprovadas.
Passos
N
08

Descrio do Item de Avaliao

Antes da Implementao o Get no diretrio Global e nos fontes
do sistema foi realizado?
Comentrio: O log produzido pelo SourceSafe coincide com a data do
primeiro apontamento de horas da fase de Implementao
09
Depois da Implementao foi Verificado mensagens de
Warnings?

Sim
10

No
0

NA
0

RE
Sim

Evidncia: MS SourceSafe
10

Sim

139
Comentrio: Foi requisitado ao desenvolver que compile o cdigo
fonte no Visual Studio com a ultima verso disponvel no SourceSafe
10 Foi verificado se outros pontos do sistema no foram afetados
nos Testes Preliminares?
Comentrio: Essa informao no pode ser verificvel em logs e ou
softwares utilizados..
11 Foi inserido comentrios ao executar o check in no
SourceSafe?
Comentrio: Na opo Details do SourceSafe todas as ocorrncias
foram preenchidas com comentrios.
Ferramentas
N
Descrio do Item de Avaliao
Foi utilizado o RM Agilis e o RM Especifica na Anlise da
12

Evidncia: MS Visual Studio

10

Sim

Evidncia: Entrevista
10

Sim

Evidncia: MS SourceSafe

Sim
10

No
0

NA
0

RE
Sim

Implementao?
Comentrio: Os campos Solicitao,

discusso entre outros so

fundamentais segundo os entrevistados.

Evidncia: Entrevista

13

10

Infra-Estrutura da empresa.

Evidncia: Software Instalados e

Extenso dos artefatos
10
0
0
Sim

Foi utilizado o Visual SourceSafe, Visual Studio, MS

Visio, MS Word, RM Agilis, Delphi na Implementao?
Comentrio: Software padres e controlados pela equipe de

14

Foi utilizado o Visual Studio.NET, MS Word, MS Visio,

RM Agilis, Delphi nos Testes Preliminares?
Comentrio: Software padres e controlados pela equipe de

Sim

15

Evidncia: Software Instalados e

Extenso dos artefatos
10
0
0
Sim

Infra-Estrutura da empresa.

Evidncia: Software Instalados e

Extenso dos artefatos

Infra-Estrutura da empresa.
Foi utilizado o Visual Studio.NET, Visual SourceSafe, RM
Agilis, Delphi para Publicar a Implementao?
Comentrio: Software padres e controlados pela equipe de

Responsveis
N
Descrio do Item de Avaliao
16

O Desenvolvedor foi responsvel por Analisar a

Implementao?
Comentrio: Foi verificado o Apontamento de Horas
O Desenvolvedor foi responsvel pela Implementao?
17
Comentrio: Foi verificado o Apontamento de Horas
O Desenvolvedor foi responsvel pelos Testes
18
Preliminares?
Comentrio: Os usurio afirmaram que sempre testem as
implementao.
O Desenvolvedor foi responsvel por Publicar a
19
Implementao?
Comentrio: Os campos e o cdigo fonte foi atualizado no
SourceSafe produzindo logs do usurio.

Observaes

Sim
10

No
0

NA
0

Evidncia: RM Agilis
10 0
0
Evidncia: RM Agilis
10 0
0

RE
Sim

Sim
Sim

Evidncia: Entrevista
10

Sim

Evidncia: SourceSafe e RM Agilis

140
VProcInsp Validao de Processo de Desenvolvimento de Software por Inspeo
Relatrio de Discrepncias
Taxonomia de Defeito:
Omisso:

Quando um dos elementos (artefato, atividade, tarefa, etapa) necessrios ao processo
no foram definidos.

Quando faltam sees de especificao de como os artefatos, atividades, tarefa e
etapas sero definidos.

Quando falta definio de termos utilizados no processo.
Ambigidade:

Quando a forma como os elementos do processo ou suas responsabilidades foram
definidos dificultam ou impossibilitam seu uso.

Quando elementos possuem o mesmo nome, mas responsabilidades diferentes
(Homnimo);
Inconsistncia:

Quando elementos descritos possuem mesma responsabilidade, mas nomes distintos
(Sinnimo)

Quando um elemento presente na execuo do processo no foi definido no modelo
formal

Quando a representao no condiz com a semntica estabelecida pela abordagem
de documentao.

Quando as responsabilidades dos stakeholders no foram definidas.
Outro:

Quando o defeito no se encaixa nas categorias acima.
ID Inspetor........: 00002
Inspetor..: Tllio Mendes Rodrigues
N Discrepncia: 01
ID Checklist.: 001
ID Item do Checklist.: 02
Descrio:
No foram encontrados diagramas UML para os dez requisitos inspecionados. Logo, no
foram usados os documentos expostos no item como entrada.
Classificao da Discrepncia:
Omisso
Ambigidade
Inconsistncia
Outros
Discrepncia aceita:
Sim
No Motivo:
N Discrepncia: 02
ID Checklist.: 001
ID Item do Checklist.: 07
Descrio:
No foram encontrados diagramas UML para os dez requisitos inspecionados. Logo, no
foram produzidos documentos de caso de uso e outros diagramas como sada.
Classificao da Discrepncia:
Omisso
Ambigidade
Inconsistncia
Outros
Discrepncia aceita:
Sim
No Motivo:
N Discrepncia: 03
ID Checklist.: 001
ID Item do Checklist.: 12
Descrio:
No foram criados diagramas de caso de uso para os requisitos. Logo no havia arquivos
para serem atualizados no SourceSafe.
Classificao da Discrepncia:
Omisso
Ambigidade
Inconsistncia
Discrepncia aceita:
Sim
No Motivo:
N Discrepncia: 04
ID Checklist.: 001
Descrio:

Outros
ID Item do Checklist.: 21

141
No foram criados diagramas de caso de uso. Logo os templates no foram utilizados.
Classificao da Discrepncia:
Omisso
Ambigidade
Inconsistncia
Outros
Discrepncia aceita:
Sim
No Motivo:
N Discrepncia: 05
ID Checklist.: 001
ID Item do Checklist.: 24
Descrio:
No existem diagramas UML para esses requisitos no SourceSafe. Logo o desenvolvedor
no criou nenhum diagrama.
Classificao da Discrepncia:
Omisso
Ambigidade
Inconsistncia
Outros
Discrepncia aceita:
Sim
No Motivo:
N Discrepncia: 06
ID Checklist.: 001
ID Item do Checklist.: 26
Descrio:
Todas as solicitaes de criao de script foram feitas pelo prprio desenvolvedor.
Classificao da Discrepncia:
Omisso
Ambigidade
Inconsistncia
Outros
Discrepncia aceita:
Sim
No Motivo:
N Discrepncia: 07
ID Checklist.: 001
ID Item do Checklist.: Inexistente
Descrio:
Ao inspecionar os artefatos para responder o item 26 o inspetor relatou a seguinte
discrepncia: A solicitao de criao de script feita na etapa de Implementao e no na
Etapa de Especificao.
Evidncia: A data de abertura de ocorrncia para os scritps eram posteriores ao
apontamento de horas na fase de implementao. Ou seja, as datas de abertura de
solicitao eram feitas depois do encerramento da fase de Especificao
Classificao da Discrepncia:
Omisso
Ambigidade
Inconsistncia
Outros
Discrepncia aceita:
Sim
No Motivo:
Observaes:
A discrepncia 07 no existia no checklist, mas foi uma discrepncia levantada a partir do
item 26 e que deve ser verificada.
Quantidade total de discrepncias levantadas: 7
Quantidade total de discrepncias aceitas.......: 7

142
VProcInsp Validao de Processo de Desenvolvimento de Software por Inspeo
Relatrio de Discrepncias
Taxonomia de Defeito:
Omisso:

Quando um dos elementos (artefato, atividade, tarefa, etapa) necessrios ao processo
no foram definidos.

Quando faltam sees de especificao de como os artefatos, atividades, tarefa e
etapas sero definidos.

Quando falta definio de termos utilizados no processo.
Ambigidade:

Quando a forma como os elementos do processo ou suas responsabilidades foram
definidos dificultam ou impossibilitam seu uso.

Quando elementos possuem o mesmo nome, mas responsabilidades diferentes
(Homnimo);
Inconsistncia:

Quando elementos descritos possuem mesma responsabilidade, mas nomes distintos
(Sinnimo)

Quando um elemento presente na execuo do processo no foi definido no modelo
formal

Quando a representao no condiz com a semntica estabelecida pela abordagem
de documentao.

Quando as responsabilidades dos stakeholders no foram definidas.
Outro:
Quando o defeito no se encaixa nas categorias acima.
ID Inspetor........: 00001
Inspetor..: Srgio Gontijo do Nascimento
Observaes:
No foram encontradas discrepncia para o a fase de Implementao ao executar o checklist com os 19 itens.

Quantidade total de discrepncias levantadas: 0

Quantidade total de discrepncias aceitas.......: 0

143

Apndice B
Questionrio de Avaliao Ps-Experimento
Por favor, responda o questionrio abaixo, de forma a nos permitir o registro de
sua opinio sobre a aplicao da abordagem para a validao de processo de
desenvolvimento de software baseado na tcnica proposta pelo VProcInsp
Nome:Bruno Ferreira
Papel: Moderador
1) Como voc classifica o grau de dificuldade de utilizao do VProcInsp?
Muito Fcil

Fcil

Mediana

Difcil

Muito Difcil

2) Na sua opinio, quais aspectos da tcnica tornam sua aplicao

fcil/difcil de usar?
A diviso do processo de validao em fases bem definidas e a utilizao de checklists tornam a
utilizao fcil. Mas a ausncia de um feedback online sobre o andamento da inspeo uma
informao difcil. Pois o moderador tem que procurar cada inspetor para saber como anda a
execuo do checklist

3) Na sua opinio, o VProcInsp se adequou a realidade da empresa e do

processo validado?
Totalmente
Satisfatrio
Atendeu as necessidades
Poderia ser melhor
No
4) Como o VProcInsp o auxiliou a identificar discrepncias entre a
execuo e o modelo do processo?
Negativamente. Os artefatos e fases atuaram como um obstculo. O
meu desempenho teria sido melhor se no tivesse utilizado.
Neutro. Acho que encontraria as mesmas discrepncias caso no
tivesse utilizado o VProcInsp.
Positivamente. Os artefatos e fases me auxiliou na deteco das
discrepncias. Talvez no tivesse detectado algumas discrepncias caso
no tivesse utilizado.
5) Na sua opinio, como a tcnica poderia ser melhorada
Criar um software online, que informe quantos itens foram preenchidos e quantos faltam ser
inspecionados para cada inspetor.

144

Questionrio de Avaliao Ps-Experimento

Por favor, responda o questionrio abaixo, de forma a nos permitir o registro de
sua opinio sobre a aplicao da abordagem para a validao de processo de
desenvolvimento de software baseado na tcnica proposta pelo VProcInsp
Nome: Isabela Iunes de Oliveira
Papel: Autor
1) Como voc classifica o grau de dificuldade de utilizao do VProcInsp?
Muito Fcil

Fcil

Mediana

Difcil

Muito Difcil

2) Na sua opinio, quais aspectos da tcnica tornam sua aplicao

fcil/difcil de usar?
Fcil: A utilizao de inspeo fazendo uso de checklist para verificar a discrepncias do
processo
Difcil: A manipulao de muitos documentos (papeis).

3) Na sua opinio, o VProcInsp se adequou a realidade da empresa e do

processo validado?
Totalmente
Satisfatrio
Atendeu as necessidades
Poderia ser melhor
No
4) Como o VProcInsp o auxiliou a identificar discrepncias entre a
execuo e o modelo do processo?
Negativamente. Os artefatos e fases atuaram como um obstculo. O
meu desempenho teria sido melhor se no tivesse utilizado.
Neutro. Acho que encontraria as mesmas discrepncias caso no
tivesse utilizado o VProcInsp.
Positivamente. Os artefatos e fases me auxiliou na deteco das
discrepncias. Talvez no tivesse detectado algumas discrepncias caso
no tivesse utilizado.
5) Na sua opinio, como a tcnica poderia ser melhorada
Criao de um sistema para substituir os vrios documentos e criar um controle de usurio
para que cada participante tenha acesso a somente as informaes que lhe convm.

145

Questionrio de Avaliao Ps-Experimento

Por favor, responda o questionrio abaixo, de forma a nos permitir o registro de
sua opinio sobre a aplicao da abordagem para a validao de processo de
desenvolvimento de software baseado na tcnica proposta pelo VProcInsp
Nome: Sergio Gontijo do Nascimento
Papel:Inspetor
1) Como voc classifica o grau de dificuldade de utilizao do VProcInsp?
Muito Fcil

Fcil

Mediana

Difcil

Muito Difcil

2) Na sua opinio, quais aspectos da tcnica tornam sua aplicao

fcil/difcil de usar?
Pode-se apontar como facilidade o uso do checklist, pois ele serve como um passo a passo.
E como ponto negativo a utilizao de documentos do Microsoft Word, pois pode-se
apagar um item do checklist ou uma informao j preenchida acidentalmente.

3) Na sua opinio, o VProcInsp se adequou a realidade da empresa e do

processo validado?
Totalmente
Satisfatrio
Atendeu as necessidades
Poderia ser melhor
No
4) Como o VProcInsp o auxiliou a identificar discrepncias entre a
execuo e o modelo do processo?
Negativamente. Os artefatos e fases atuaram como um obstculo. O
meu desempenho teria sido melhor se no tivesse utilizado.
Neutro. Acho que encontraria as mesmas discrepncias caso no
tivesse utilizado o VProcInsp.
Positivamente. Os artefatos e fases me auxiliou na deteco das
discrepncias. Talvez no tivesse detectado algumas discrepncias caso
no tivesse utilizado.
5) Na sua opinio, como a tcnica poderia ser melhorada
Criar um software para auxiliar no uso do checklist durante a inspeo, ou utilizar o
Microsoft Excel com algumas clulas travadas para proteger o contedo das planilhas.

146

Questionrio de Avaliao Ps-Experimento

Por favor, responda o questionrio abaixo, de forma a nos permitir o registro de
sua opinio sobre a aplicao da abordagem para a validao de processo de
desenvolvimento de software baseado na tcnica proposta pelo VProcInsp
Nome: Tllio Mendes Rodrigues
Papel: Inspetor
1) Como voc classifica o grau de dificuldade de utilizao do VProcInsp?
Muito Fcil

Fcil

Mediana

Difcil

Muito Difcil

2) Na sua opinio, quais aspectos da tcnica tornam sua aplicao

fcil/difcil de usar?
O uso do checklist auxiliou bastante. Mas os checklists poderiam ser informatizados.

3) Na sua opinio, o VProcInsp se adequou a realidade da empresa e do

processo validado?
Totalmente
Satisfatrio
Atendeu as necessidades
Poderia ser melhor
No
4) Como o VProcInsp o auxiliou a identificar discrepncias entre a
execuo e o modelo do processo?
Negativamente. Os artefatos e fases atuaram como um obstculo. O
meu desempenho teria sido melhor se no tivesse utilizado.
Neutro. Acho que encontraria as mesmas discrepncias caso no
tivesse utilizado o VProcInsp.
Positivamente. Os artefatos e fases me auxiliou na deteco das
discrepncias. Talvez no tivesse detectado algumas discrepncias caso
no tivesse utilizado.
5) Na sua opinio, como a tcnica poderia ser melhorada
Se a tcnica tivesse um software para auxiliar todo o processo de validao, o trabalho
seria minimizado. Logo, sugiro a criao de um software.