universidade estadual de maringÁ programa de pÓs …mestrado/diss/2011/ribeiro.pdf · ao dds. o...
TRANSCRIPT
UNIVERSIDADE ESTADUAL DE MARINGÁ CENTRO DE TECNOLOGIA
DEPARTAMENTO DE INFORMÁTICA PROGRAMA DE PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO
CARLOS EDUARDO RIBEIRO
Estratégia de apoio à inspeção de software no desenvolvimento distribuído de software
Maringá 2011
CARLOS EDUARDO RIBEIRO
Estratégia de apoio à inspeção de software no desenvolvimento distribuído de software
Dissertação apresentada ao Programa de Pós-Graduação em Ciência da Computação do Departamento de Informática, Centro de Tecnologia da Universidade Estadual de Maringá, como requisito parcial para obtenção do título de Mestre em Ciência da Computação Orientadora: Profª. Drª. Elisa Hatsue Moriya Huzita
Maringá 2011
Dados Internacionais de Catalogação-na-Publicação (CIP)
(Biblioteca Central - UEM, Maringá – PR., Brasil) Ribeiro, Carlos Eduardo R484e Estratégia de apoio à inspeção de software no
desenvolvimento distribuído de software / Carlos Eduardo Ribeiro. -- Maringá, 2011.
133 f. : il. col., figs., tabs. Orientadora: Prof.a Dr.a Elisa Hatsue Moriya Huzita Dissertação (mestrado) - Universidade Estadual de
Maringá, Centro de Tecnologia, Departamento de Informática, Programa de Pós-Graduação em Ciência da Computação, 2011.
1. Inspeção de software. 2. Desenvolvimento distribuído
de software (DDS). 3. Equipes distribuídas. 4. Modelo de negócio. I. Huzita, Elisa Hatsue Moriya, orient. II. Universidade Estadual de Maringá. Centro de Tecnologia. Departamento de Informática. Programa de Pós-Graduação em Ciência da Computação. III. Título.
CDD 21.ed. 004.21 SOI-000218
DEDICATÓRIA
Dedico a minha Mamãe, minha heroína e meu eterno amor...
AGRADECIMENTOS
Agradeço primeiramente a DEUS que me guiou e deu forças durante essa dura jornada e por
ter colocado pessoas maravilhosas no meu caminho, alguns são verdadeiros anjos em forma
de ser humano...
À professora Dra. Elisa Hatsue Moriya Huzita, minha orientadora, pela paciência, apoio e
incentivo durante essa jornada...
Em especial à minha maravilhosa e amada Esposa Leila, por sempre estar ao meu lado me
incentivando...
À minha Mamãe, Irene, pelo amor incondicional, à minha Vó ZeZé, grande guerreira,
exemplo de dedicação, à minha irmã Patrícia, ao meu sobrinho Mike e ao meu irmão Márcio
(Ponês) pelo apoio...
Aos meus grandes companheiros de caminhada, Cláudia, Miguel, Andrezão e ao grande
amigo Merlin, obrigado pelos bons momentos que passamos juntos, acredito que muitos
outros virão....
Aos meus “irmãos” de mestrado: Rafael Vivian, Gustavo Sato, parceiros de Laboratório, e à
Camila pela sua atenção e apoio...
Aos amigos do cafezinho: Lurdete, André, Matusse, Beletti, Rogério, Everton, Paulo, Filipe,
Juliano, Rodrigo, Danilo, Vinícius, Wagner, enfim a todos das duas turmas que participei...
Aos amigos e companheiros de trabalho da UENP: Sgarbi, Dani, Vivi, Alba, Cris, Fernando,
Menolli, Ricardo, Glauco, Christian, Cidinha, Fábio, Estevan, Mariana, Lomba, Márcia...
Aos professores e funcionários da Pós-graduação em Ciência da Computação da UEM, em
especial a querida Inês, pelo carinho e simpatia...
Aos participantes da pesquisa efetuada neste trabalho e à Fundação Araucária do Estado
Paraná pelo apoio financeiro...
EPÍGRAFE
DEUS é amor.
E o que vive no amor, vive em DEUS, e DEUS vive nele.
Se amarmos uns aos outros, DEUS viverá em nós.
(SÃO JOÃO)
Estratégia de apoio à inspeção de software no desenvolvimento distribuído de software
RESUMO
O mundo globalizado, aliado à evolução das tecnologias da informação e comunicação, tem
incentivado as organizações a distribuírem seus esforços de produção em várias localidades,
em busca do aumento de produtividade e, assim, tornarem-se mais competitivas. Essa
estratégia de distribuição de atividades e recursos, sejam materiais ou humanos, também tem
sido utilizada pelas organizações de desenvolvimento de software, o que deu origem ao
desenvolvimento distribuído de software (DDS). Essa nova realidade trouxe consigo
benefícios e desafios. Entre os desafios estão a busca por melhor comunicação entre os
envolvidos, adaptação dos processos tradicionalmente utilizados na engenharia de software ou
quando necessária proposição de novas atividades para que estas ofereçam o apoio adequado
ao DDS. O presente trabalho tem por objetivo propor uma estratégia de apoio à inspeção para
organizações que utilizam o desenvolvimento distribuído de software. Um dos aspectos que
foi considerado é o modelo de negócio, decorrente da distribuição e do relacionamento
adotado pelas empresas envolvidas.
Palavras-chave: Desenvolvimento distribuído de software. Inspeção de software. Documento de requisitos de software.
Strategy to support the software inspection in distributed software development
ABSTRACT
The globalized world combined with the progress of information technology and
communication have encouraged organizations to distribute their production efforts in various
locations aiming at to increase their productivity and turn them more competitive. This
distribution strategy of activities and resources both material and humans, has also been
used by software development organizations. It led to the distributed software
development (DDS) approach. This new reality has brought benefits and
challenges. Among their challenges are seeking to improve communication among those
involved, to adapt the processes commonly used in software engineering area or, when
necessary, propose new activities to provide adequate support to the DDS. This work aims
to propose a strategy to support the inspection to organizations that adopt the distributed
software development approach. One of important aspect considered by this strategy is the
establishment of business model, due to the distribution and relationship adopted by involved
organizations.
Keywords: Distributed Software Development. Software Inspection. Software Requirements Specification.
LISTA DE FIGURAS
Figura 1 – Impacto da distância (adaptado de Carmel e Argarwal 2001) ............................... 22 Figura 2 – Estimativa de retrabalho evitável utilizando-se inspeção de software. Fonte: Boehm e Basili (2001) ......................................................................................................... 35 Figura 3 – Processo tradicional de inspeção. Fonte: Fagan (1976) ........................................ 38 Figura 4 – a) Processo de inspeção tradicional, b) processo de inspeção reorganizado. Adaptado de Fagan (1976) e Sauer (2000) ............................................................................ 41 Figura 5 – Atividades sequenciais sugeridas por Sauer et al. (2000) ..................................... 42 Figura 6 – Processo Simplificado de Inspeção. Fonte: Mishra e Mishra (2009) .................... 42 Figura 7 – Processo de Inspeção de Software Global. Fonte: Mishra e Mishra (2010) .......... 43 Figura 8 – Parte de um checklist. Fonte: McMeekin et al. (2008) ......................................... 45 Figura 9 – Tipos de leitura na leitura baseada em rastreabilidade. Fonte: Travassos (1999) .. 48 Figura 10 – Abordagem de inspeção proposta ...................................................................... 54 Figura 11 – Abordagem integrada de desenvolvimento e teste. Fonte: Leal (2010) ............... 65 Figura 12 – Inspeção de software no proc. de desenvolvimento. Fonte: Ackerman et al. (1989) ............................................................................................................................................ 66 Figura 13 – Diagrama de pacotes da abordagem de desenvolvimento. Fonte: Leal (2010) .... 66 Figura 14 – Diagrama de pacotes da definição de trabalho – Configurar o processo. Adaptado de Leal (2010) ...................................................................................................................... 69 Figura 15 – Diagrama de casos de uso da definição de trabalho – Configurar o processo. Adaptado de Leal (2010) ...................................................................................................... 70 Figura 16 – Diagrama de Classes. Adaptado de Leal (2010) ................................................. 71 Figura 17 – Diagrama de atividades. Adaptado de Leal (2010) ............................................. 71 Figura 18 – Diagrama de Pacotes da Disciplina Requisitos. Adaptado de Leal (2010) .......... 72 Figura 19 – Diagrama de Pacotes das Definições de Trabalho. (Leal, 2010) ......................... 72 Figura 20 – Pacote de trabalho da definição de trabalho Aplicar Inspeção ............................ 73 Figura 21 – Diagrama de Classes – Aplicar Inspeção ........................................................... 74 Figura 22 – Diagrama de Casos de uso – Aplicar Inspeção ................................................... 75 Figura 23 – Diagrama de atividades – Aplicar Inspeção ....................................................... 76 Figura 24 – Delimitação do estudo ....................................................................................... 78 Figura 25 – Sobreposição de horários. Fonte: 24TimeZones.com ......................................... 81 Figura 26 – Horário definido para reunião. Fonte: 24TimeZones.com .................................. 82 Figura 27 – Listas de Discrepâncias ..................................................................................... 83 Figura 28 – Lista de Erro de Digitação ................................................................................. 84 Figura 29 – Lista de Defeitos ............................................................................................... 85 Figura 30 – Lista de Defeitos ............................................................................................... 86 Figura 31 – Checklist utilizado na inspeção .......................................................................... 92 Figura 32 – Lista de Defeitos ............................................................................................... 93
LISTA DE TABELAS
Tabela 1 – Classificação de defeitos ..................................................................................... 29 Tabela 2 – Classificação de defeitos ..................................................................................... 30 Tabela 3 – Classificação de defeitos ..................................................................................... 31 Tabela 4 – Classificação de defeitos ..................................................................................... 31 Tabela 5 – Classificação de defeitos ..................................................................................... 32 Tabela 6 – Tipos de revisões e as recomendações de uso conforme Wiegers (2002) ............. 34 Tabela 7 – Análise dos trabalhos .......................................................................................... 50 Tabela 8 – Características das ferramentas analisadas........................................................... 52 Tabela 9 – Atividades da etapa Gestão da Preparação........................................................... 57 Tabela 10 – Atividades da etapa Planejamento da Inspeção .................................................. 60 Tabela 11 – Atividades da etapa Apresentação ..................................................................... 61 Tabela 12 – Atividades da etapa Detecção de Defeitos ......................................................... 62 Tabela 13 – Atividades da etapa Coleção de Defeitos ........................................................... 62 Tabela 14 – Atividades da etapa Discriminação de Defeitos ................................................. 63 Tabela 15 – Atividades da etapa Retrabalho ......................................................................... 63 Tabela 16 – Atividades da etapa Acompanhamento .............................................................. 64 Tabela 17 – Papéis envolvidos na abordagem. Adaptado de Leal(2010). .............................. 67 Tabela 18 – Classificação de defeitos utilizada no estudo ..................................................... 83 Tabela 19 – Quantidade de defeitos detectados..................................................................... 86
LISTA DE GRÁFICOS
Gráfico 1 – Nível de Formação dos Participantes ................................................................. 87 Gráfico 2 – Tempo de atuação na área de SI ......................................................................... 88 Gráfico 3 – Experiência em desenvolvimento de software .................................................... 88 Gráfico 4 – Experiência em inspeção de software ................................................................. 89 Gráfico 5 – Experiência em DDS ......................................................................................... 89 Gráfico 6 – Questões de estudo ............................................................................................ 90
LISTA DE ABREVIATURAS E SIGLAS
ADR Active Design Review
AISA Asynchronous Inspector of Software Artifacts
ASSIST Asynchronous/Synchronous Software Inspection Support Tool
CBR Checklist-Based Reading
CSI Collaborative Software Inspection
DBR Defect Based Reading
DDS Desenvolvimento Distribuído de Software
DiSEN Distributed Software Engineering Environment
DRS Documento de Requisitos de Software
DSD Distributed Software Development
FTArm Formal Technical Asynchronous review method
GDD Geographically Distributed Development
GRIP Groupware supported Inspection Process
GSD Global Software Development
IBIS Internet Based Inspection System
IBM International Business Machines
ICICLE Intelligent Code Inspection Environment in a C Language Environment
IEEE Institute of Electrical and Electronics Engineers
ISPIS Infraestrutura de Suporte ao Processo de Inspeção de Software
NASA National Aeronautics and Space Administration
PBR Perspective Based Reading
SBR Scenario-Based Reading
TBR Traceability Based Reading
TMS Theory of Media Synchronicity
TSMC Teoria Da Sincronicidade Dos Meios De Comunicação
UML Unified Modeling Language
XATI XML Annotation Tool for Inspection
SUMÁRIO
Introdução .......................................................................................................................... 17
1.1. Contexto e Motivação ............................................................................................. 18
1.2. Objetivo .................................................................................................................. 19
1.3. Metodologia ............................................................................................................ 19
1.4. Organização do Trabalho ...................................................................................... 20
Revisão Bibliográfica ......................................................................................................... 21
2.1. Considerações Iniciais ............................................................................................ 21
2.2. Desenvolvimento Distribuído de Software............................................................. 21
2.3. Modelos de Negócio de Desenvolvimento Distribuído de Software ...................... 23
2.4. Documento de Requisitos de Software ................................................................... 24
2.4.1. Modelo de qualidade de especificação de requisitos ....................................... 25
2.4.2. Defeitos em Requisitos de Software ................................................................ 28
2.5. Revisões ................................................................................................................... 32
2.5.1. Inspeção de Software ....................................................................................... 33
2.5.1.1. Processo de Inspeção........................................................................................ 36
2.5.1.2. Técnicas de Leitura .......................................................................................... 44
2.6. Inspeção de Software e DDS .................................................................................. 49
2.7. Ferramentas de Inspeção de Software ................................................................... 50
2.8. Considerações finais ............................................................................................... 52
Abordagem proposta ......................................................................................................... 53
3.1. Abordagem de inspeção ......................................................................................... 53
3.1.1. Descrição de cada etapa da abordagem proposta ........................................... 54
3.1.2. Estratégia de apoio à inspeção de software em DDS ...................................... 56
3.2. Abordagem de Desenv. e Teste de Software para Equipes Distribuídas .............. 65
3.2.1. Disciplina Planejamento .................................................................................. 68
3.2.2. Disciplina Requisitos ........................................................................................ 72
3.3. Considerações Finais .............................................................................................. 76
Exemplo de aplicação da abordagem ................................................................................ 77
4.1. Aplicação da Abordagem de Inspeção ................................................................... 77
4.1.1. Etapa Gestão da Preparação ........................................................................... 79
4.1.2. Etapa Planejamento da Inspeção .................................................................... 80
4.1.3. Etapa Apresentação ......................................................................................... 81
4.1.4. Etapa Detecção de Defeitos .............................................................................. 82
4.1.5. Etapa Coleção de Defeitos ............................................................................... 84
4.1.6. Etapa Discriminação de Defeitos ..................................................................... 85
4.1.7. Etapas Retrabalho e Acompanhamento.......................................................... 86
4.1.8. Dados do estudo ............................................................................................... 87
4.2. Aplicação da inspeção na abordagem de Leal (2010) ............................................ 91
4.3. Considerações Finais .............................................................................................. 93
Conclusão ........................................................................................................................... 95
5.1. Dificuldades e Limitações ....................................................................................... 96
5.2. Trabalhos Futuros .................................................................................................. 96
Referências....................................................................................................................... 98
Apêndice A ..................................................................................................................... 103
Anexo A ........................................................................................................................... 107
Anexo B ........................................................................................................................... 125
17
Introdução
A globalização possibilita contatos comerciais, culturais, financeiros e tecnológicos em nível
mundial. Ela traz consigo, por exemplo, a criação da modalidade de outsourcing de
empregos/serviços, que possibilita a distribuição destes entre vários países, e a empresa que se
utilizar dessa distribuição ganhará vantagem competitiva. A cada dia, mais empresas
necessitam de produtos de software seguros e estratégicos para auxiliar seus negócios. Da
mesma forma que os demais produtos disponíveis no mercado, o produto de software deve
apresentar boa qualidade. Uma das formas de agregar qualidade ao software é incluir, como
parte do processo de seu desenvolvimento, atividades de verificação e validação, dentre elas
pode-se citar a inspeção de software.
O principal objetivo da inspeção é descobrir antecipadamente defeitos que se
caracterizam pela produção de uma saída incorreta em relação à especificação. A inspeção
pode minimizar a falta de precisão dos documentos, pois possui um processo de detecção de
defeitos rigoroso e bem definido. Desta forma, evita-se a propagação dos defeitos para o
passo seguinte do processo de software.
A inspeção é uma das técnicas de detecção de defeitos de maior eficiência, pois
elimina de 50% a 90% dos defeitos no processo de desenvolvimento, isso antes de se
iniciarem os testes. Ainda, a inspeção pode reduzir o tempo de desenvolvimento, já que
remove defeitos antes que o artefato passe para as fases posteriores, reduzindo o custo com o
retrabalho (Pagliusi et al., 2000).
1 Capítulo
18
O desenvolvimento distribuído de software (DDS) é uma abordagem de
desenvolvimento de software na qual os envolvidos em um determinado projeto estão
dispersos. Essa dispersão pode ser caracterizada por distâncias geográfica, temporal e
sociocultural que causam impacto nas etapas de desenvolvimento de software, acentuando-se
alguns desafios já existentes no desenvolvimento co-localizado e também criando novos
desafios a serem superados.
Assim, apesar de tornar as atividades de desenvolvimento mais difíceis, uma vez que
as características do DDS impõem problemas de comunicação, de controle, de confiança e de
atrasos no compartilhamento de conhecimento para validação dos requisitos no
desenvolvimento do software, há várias razões que apoiam a adoção do DDS. Dentre elas
destacam-se: a capacidade de estender o trabalho para além do horário normal de expediente
em um único local; redução de custos de desenvolvimento de software em centros offshore;
aumento da capacidade de força de trabalho em unidades remotas localizadas em economias
emergentes e os avanços nas tecnologias da informação e comunicação, facilitando a
colaboração entre as forças de trabalho remotas.
1.1. Contexto e Motivação
Conforme constatado na revisão de literatura, o DDS traz alguns desafios à Engenharia de
Software. Pode-se dizer que a verificação de software é um destes desafios, do qual o
processo de inspeção faz parte. O DDS, por si só, requer que sejam considerados o
relacionamento que se estabelece entre as organizações envolvidas, bem como a dispersão das
equipes. Isto gera vários modelos de negócio. Assim, as características inerentes ao DDS, em
conjunto com a escolha por um modelo de negócio, podem impactar positiva ou
negativamente a forma em que deve ser conduzido o processo de inspeção. A ausência de uma
estratégia pode tornar mais difícil enfrentar as características do DDS.
Na Universidade Estadual de Maringá encontra-se em desenvolvimento um projeto de
pesquisa para a construção de um ambiente de desenvolvimento distribuído de software
denominado DiSEN – Distributed Software Engineering Environment, do qual faz parte o
trabalho intitulado “Uma abordagem integrada de desenvolvimento e teste de software para
equipes distribuídas” (Leal, 2010).
Diante desse cenário, desenvolveu-se uma abordagem para que fossem definidas as
atividades da estratégia de apoio à inspeção de software em DDS, apresentadas neste trabalho.
Dessa forma, propõe-se a inclusão de inspeção de software na abordagem integrada de Leal
19
(2010), pois, segundo a autora, há vários trabalhos, como os de Damian (2002), Mockus e
Herbsleb (2001), Herbsleb et al. (2001) e (Sangwan et al., 2006)) que abordam DDS, no
entanto não tratam especificamente de inspeção.
1.2. Objetivo
O objetivo geral deste trabalho é definir uma estratégia de apoio à inspeção em DDS levando
em consideração um determinado modelo de negócio adotado pelas organizações envolvidas.
Como objetivos específicos têm-se:
elaborar uma abordagem de inspeção de software;
definir uma estratégia para aplicação da abordagem proposta; e
incluir a inspeção de software na abordagem proposta por Leal (2010).
1.3. Metodologia
O presente trabalho caracteriza-se como pesquisa aplicada, pois objetiva a aquisição de
conhecimento para a aplicação prática em problemas específicos. Com relação à abordagem
do problema é pesquisa qualitativa, por não se tratar de um estudo que requeira uso de recurso
e de técnicas estatísticas. Além disso, o trabalho apresenta característica exploratória e
descritiva, pois foi realizado por meio de um levantamento bibliográfico para subsidiar a
elaboração de uma abordagem e de sua estratégia, além da aplicação da abordagem e de
análises que auxiliem na compreensão da avaliação (Gil, 1996).
Para o desenvolvimento deste trabalho, foram estabelecidos os seguintes passos
metodológicos:
1. elaboração da abordagem de inspeção;
2. definição da estratégia de apoio à inspeção em DDS;
3. aplicação da abordagem proposta, utilizando um Documento de Requisitos de
Software, disponibilizado por uma empresa;
4. Análise qualitativa realizada pelo autor do estudo.
20
1.4. Organização do Trabalho
Esta dissertação está organizada da seguinte forma: no Capítulo 2 é apresentada uma revisão
bibliográfica referente ao DDS; modelos de negócio em DDS; um esboço de um documento
de requisitos de software, bem como os possíveis defeitos nesse tipo de documento; os
conceitos de inspeção: processo, técnica de leitura e ferramenta. No Capítulo 3 são
apresentadas a abordagem de inspeção e a estratégia de apoio à inspeção de software em
DDS, considerando um modelo de negócio offshore outsourcing; apresenta-se também uma
sugestão de inclusão de inspeção de software na abordagem integrada de desenvolvimento e
teste para equipe distribuída proposta por Leal (2010). No Capítulo 4 é apresentado o
exemplo de aplicação da abordagem e da estratégia proposta neste trabalho. Por fim, o
Capítulo 5 apresenta as conclusões e trabalhos futuros. O Apêndice e os Anexos apresentam
os documentos utilizados nesta dissertação.
21
Revisão Bibliográfica
2.1. Considerações Iniciais
Neste capítulo são apresentados os conceitos que deram subsídio a este trabalho:
Desenvolvimento Distribuído de Software, Modelos de Negócio de D, Documento de
Requisitos de Software, Inspeção de Software e DDS e Ferramentas de Inspeção de Software.
2.2. Desenvolvimento Distribuído de Software
A distribuição de esforços de desenvolvimento, mais especificamente a distribuição das
equipes, está se tornando prática constante nas organizações, muitas estão investindo no
desenvolvimento distribuído de software, terceirizando ou contratando equipes em outros
locais, tanto nacional como internacionalmente. Huzita et al. (2008) reforçam que diversas
organizações, em busca de vantagem competitiva, decidiram por distribuir seu processo de
desenvolvimento de software, caracterizando assim o DDS.
A literatura traz outros termos que, muitas vezes, são considerados sinônimos, Global
Software Development (GSD), que segundo Karolak (1998) constitui-se no desenvolvimento
distribuído de software em que a distância física entre os envolvidos no projeto engloba mais
de um país, o Geographically Distributed Development (GDD) e o Distributed Software
Development (DSD).
Conforme Carmel (1999), as distâncias geográfica, temporal e sociocultural são
características do DDS que trouxeram novos desafios ao desenvolvimento de software. A
2 Capítulo
22
distância geográfica é uma medida da dispersão geográfica que ocorre quando os membros da
equipe estão dispersos em diferentes locais. A distância temporal é uma medida da dispersão
temporal que ocorre quando os membros da equipe se encontram em diferentes fusos
horários. A distância sócio-cultural é a medida da compreensão pelos membros da equipe,
localizada em um local, dos valores, padrões, práticas e regras de outra equipe localizada em
outro local.
Conforme Carmel e Agarwal (2001), cada uma dessas distâncias tem um impacto
sobre todas as formas de cooperação dentro de uma equipe: a coordenação, o controle e a
comunicação. Na Figura 1 são ilustrados esses impactos.
Controle é o processo de adesão aos objetivos, políticas, normas ou níveis de
qualidade. Ele pode ser formal, quando se tem orientações explícitas e pode ser ainda
informal em relação às pressões exercidas pelos pares. A coordenação é a gestão eficaz das
dependências entre as sub-tarefas, os recursos e as pessoas. A comunicação é um fator de
mediação que afeta tanto a coordenação quanto o controle, permitindo que as informações
sejam trocadas entre os membros da equipe. Observa-se na Figura 1 que a distância não só
afeta a coordenação e o controle diretamente, mas também indiretamente, por meio dos
impactos negativos que têm sobre a comunicação (Carmel e Agarwal, 2001).
A dispersão geográfica reduz a comunicação informal, acarretando um efeito negativo
para as atividades de comunicação no desenvolvimento do software, principalmente àquelas
que requerem interação face-a-face. Essa dispersão também afeta a colaboração, pois as
equipes podem deixar de divulgar informações, perdendo assim a oportunidade de reutilizar
as mesmas soluções que já foram utilizadas em outros locais.
Conforme Herbsleb et al. (2005), a dispersão temporal reduz as horas de sobreposição
entre os diferentes locais de desenvolvimento de software, introduzindo assim, atrasos no
Negativo
Negativo
Negativo
Comunicação
Coordenação
Controle
Figura 1 – Impacto da distância (adaptado de Carmel e Argarwal 2001)
23
projeto. Carmel (1999) afirma que essa diferença de fuso horário aumenta o problema de
comunicação, pois diminui as oportunidades de comunicação síncrona. Nesse caso, a
comunicação assíncrona é normalmente mais utilizada, podendo aumentar o risco de mal-
entendidos (Kiel, 2003).
Afirmam Herbsleb e Moitra (2001) que a distância sociocultural acentua os problemas
de comunicação, pois se tem a comunicação verbal, não verbal, gestos e posturas. Os autores
alegam que a comunicação não verbal é especialmente afetada pela diferença sociocultural,
produzindo assim mal-entendidos culturais que podem reduzir a coordenação. Ågerfalk et al.
(2005) afirmam que isso ocorre especialmente se há uma falta de padrões e práticas
compartilhadas entre as equipes.
Apesar dos problemas comentados anteriormente, as distâncias geográfica, temporal e
sociocultural também têm seus pontos positivos. Damian e Zowghi (2003) afirmam que a
distância geográfica permite às empresas terem acesso aos desenvolvedores de software
especializados com preços mais reduzidos e, dessa forma, reduzem-se os custos com o
desenvolvimento, uma vez que as empresas podem modularizar o trabalho e ainda estarem
mais próximas de seus clientes.
A distância temporal permite às empresas provarem o desenvolvimento de software
“follow-the-sun” ao redor do relógio, reduzindo-se o time-to-market, ou seja, diminui o tempo
para a inserção de um produto no mercado consumidor (Herbsleb e Grinter, 1999). Ebert e de
Neve (2001) afirmam que a distância sociocultural oferece a oportunidade de inovar e
compartilhar as melhores práticas entre os locais de desenvolvimento de software.
2.3. Modelos de Negócio de Desenvolvimento Distribuído de Software
Devido à globalização, as organizações buscam meios que permitam aumentar a sua
lucratividade. Uma das formas encontradas por elas é buscar por soluções externas, em outros
países diferentes da matriz, utilizando-se de offshoring, ou buscar soluções no mesmo país,
por meio da terceirização, outsourcing. Deve-se ter em mente que para operacionalizar o DDS
há a necessidade de se definir o relacionamento das empresas envolvidas (outsourcing,
insourcing, colaboração), assim como de definir a caracterização da equipe no que se refere à
localização geográfica (onshore, offshore) e, assim, obter o modelo de negócio para
operacionalizar o DDS (Robinson e Kalakota, 2004).
24
Conforme Robinson e Kalakota (2004), as organizações podem operacionalizar o DDS
da seguinte forma:
i. Onshore insourcing ou demanda doméstica interna: nesse modelo há um departamento
dentro da empresa ou uma subsidiária da empresa no mesmo país (onshore) que
fornece serviços de desenvolvimento de software por meio de projetos internos
(insourcing).
ii. Onshore outsourcing ou outsourcing: nesse modelo há a contratação de uma empresa
terceirizada (outsourcing), localizada no mesmo país da contratante (onshore), para o
desenvolvimento de determinados serviços ou produtos de software para a empresa.
iii. Offshore outsourcing ou offshoring: há a contratação de uma empresa terceirizada
(outsourcing), localizada em um país diferente da contratante (offshore), para o
desenvolvimento de determinados serviços ou produtos de software.
iv. Offshore insourcing ou captive/internal offshoring: há a contratação de uma empresa
subsidiária da própria empresa para prover serviços de desenvolvimento de software
(insourcing), a subsidiária necessariamente deve estar localizada em um país diferente
da matriz da empresa ou empresa contratante (offshore).
Outro modelo é o nearshore que indica a transferência de atividades para equipes
localizadas em países geograficamente mais próximos e, dessa forma, tenta-se evitar as
diferenças culturais e temporais entre os envolvidos (Robinson e Kalakota, 2004).
2.4. Documento de Requisitos de Software
O Documento de Requisitos de Software (DRS) ou Documento de Especificação de Software
é um documento importante elaborado no início do desenvolvimento que contém uma
descrição detalhada do problema que o software deve resolver e documenta o conteúdo, o
fluxo e a estrutura da informação. O DRS também descreve o hardware, o software e as
interfaces humanas, descritos para os elementos externos do sistema e as funções internas do
software.
Na descrição funcional são apresentadas a descrição de cada função necessária para
resolver o problema, uma narrativa de processamento para cada função, e são declaradas e
justificadas as restrições de projetos e as características de desempenho. Para Sommerville
(1998) o documento de requisitos é uma declaração formal dos requisitos para todos os
envolvidos, que podem ser clientes, usuários finais ou a equipe de desenvolvimento do
software.
25
2.4.1. Modelo de qualidade de especificação de requisitos
Segundo recomendações do IEEE (1998) há algumas características de qualidade que devem
consideradas para que se tenha uma boa especificação de requisitos de software. Essas
características são as seguintes: correção ou corretude, não ambiguidades, completeza ou
completude, consistência, verificabilidade, modificabilidade e rastreabilidade. As respectivas
definições são descritas a seguir.
Correção ou corretude – conforme o IEEE (1998) uma especificação de
requisitos de software é correta se todo requisito especificado reflete
exatamente o que o sistema de fazer. Segundo Pressman (1995) um requisito
está semanticamente correto se o documento do sistema está de acordo com a
descrição do problema a ser solucionado, assim o sistema deve satisfazer sua
especificação e atingir as necessidades do cliente.
Não ambiguidade – o IEEE recomenda que uma especificação de software não
seja ambígua, dessa forma todo requisito especificado deve ter apenas uma
interpretação, o requisito especificado não deve causar confusão. Em casos em
que um termo possa ter múltiplos significados, ele deve ser incluído em
glossário, no qual seu significado será especificado de forma clara.
Completeza ou completude – segundo as recomendações do IEEE (1998), uma
especificação de requisitos de software é completa se satisfizer os seguintes
elementos: definição do sistema para todas as entradas de dados em todas as
situações, considerando valores de entradas válidos e inválidos, e explicações
para todas as figuras, tabelas e diagramas, e definição de todos os termos e
unidades de medida.
Consistência – uma especificação de requisitos de software é consistente se os
requisitos não se conflitam. Isso pode ocorrer quando um requisito é descrito
de uma forma em um lugar e, em outro lugar, é descrito de forma diferente e
conflitante com o primeiro.
Classificar por importância e/ou estabilidade – a recomendação do IEEE
(1998) é que cada requisito pode ter um identificador para indicar sua
importância ou estabilidade, salienta que alguns requisitos podem ser
essenciais, especificamente para aplicações críticas de vida, enquanto outros
podem ser apenas desejáveis.
26
Verificabilidade – uma especificação de requisitos de software é verificável se
cada requisito é passível de ser verificado.
Modificabilidade – segundo as recomendações do IEEE (1998) uma
especificação de requisitos de software é modificável se sua estrutura e estilo
são tais que quaisquer mudanças nos requisitos possam ser realizadas.
Rastreabilidade – uma especificação de requisitos de software é rastreável
somente se a origem de cada um de seus requisitos é clara e se isto facilita a
referência para cada requisito em desenvolvimento futuro. A rastreabilidade é
importante quando os requisitos declarados mudarem durante o processo de
desenvolvimento ou quando for detectado um defeito no DRS, ou ainda
quando um cliente desejar mudar ou acrescentar requisitos. Nesses casos as
mudas devem ser facilmente rastreadas. Conforme o IEEE (1998) há dois tipos
de rastreabilidade, uma para trás, na qual cada requisito tem que ter sua origem
em documentos iniciais do projeto, e a outra, para frente, na qual cada requisito
tem que ter um único nome ou número de referência.
Além dessas características há outras sugeridas na literatura, Davis et al. (1993)
sugerem 18 atributos de qualidade que devem constar em uma especificação, alguns deles são
iguais aos recomendados pelo IEEE (1998) e outras diferentes, por exemplo, Alcançabilidade,
Prototipação, Armazenamento Eletrônico, Referência à versão. Neste trabalho teve como foco
as características recomendadas pelo IEEE (1998).
Conforme a IEEE (1998) um Documento de Requisitos de Software deve conter as
seguintes seções e subseções:
1. Introdução – fornece uma visão geral de todo o documento e apresenta as seguintes
subseções:
1.1. Objetivo – descreve o objetivo do DRS e especifica o seu público-alvo
1.2. Escopo – identifica o(s) produto(s) de software a ser(em) gerado(s), apresenta o que
esse(s) produto(s) fará(ao), qual sua aplicação e seus benefícios.
1.3. Definições, acrônimos e abreviações – nesta subseção são apresentados todos os
termos, acrônimos e abreviações utilizadas no documento.
1.4. Referências – fornecem uma lista completa de todos os documentos referenciados ao
longo do DRS.
1.5. Visão Geral – descreve o conteúdo das seções relevantes e explica como o DRS será
organizado.
27
2. Descrição Geral – descreve os fatores gerais que afetam os produtos e os seus requisitos:
2.1. Descrição do Produto – especifica os produtos dentro da perspectiva de outros
produtos ou projetos relacionados.
2.2. Funções do Produto – fornece um resumo das funções que o software executará.
2.3. Característica do Usuário – descreve as características gerais dos eventuais usuários
do produto.
2.4. Restrições Gerais – fornece uma descrição geral de quaisquer outros itens que
possam limitar as opções do desenvolvedor durante o projeto do sistema.
2.5. Pressupostos e Dependências – lista cada um dos fatores que afetam os requisitos
declarados.
3. Requisitos Específicos – contêm todos os detalhes que o projetista de software necessita
para projetar o sistema.
3.1. Informação complementar dos requisitos específicos – descreve os dados dos
produtos de software, deve complementar as descrições da Seção 3, mas sem repetir
informações.
3.1.1. Requisitos Funcionais – especifica como as entradas do produto de software
devem ser transformadas em saídas.
3.2. Requisitos de Desempenho – especifica os requisitos numéricos, estáticos e
dinâmicos, localizados no software ou na interação do software com o humano.
3.3. Restrições de Projeto – descreve as limitações do projeto impostas por outros
padrões, limitações de hardware, dentre outros.
3.3.1. Padrões a serem atendidos – especifica os requisitos derivados de padrões ou
de regras existentes.
3.3.2. Limitações de Hardware – inclui os requisitos para o software operar dentro
das limitações do hardware.
3.4. Atributos – descreve os atributos que podem especificar os requisitos do software.
3.4.1. Disponibilidade – especifica os fatores necessários para garantir um nível de
disponibilidade definido para todo o sistema.
3.4.2. Segurança – especifica os fatores necessários para proteger o software de
acessos indevidos.
3.4.3. Manutenção – especifica os fatores assegurando que o software é passível de
manutenção.
28
3.4.4. Transferência e Conversão – especifica os procedimentos do usuário, as
limitações de interface, necessários para transportar o software de um meio para
outro.
3.5. Requisitos de Interface externa – descreve as interfaces do sistema.
3.5.1. Interface de Usuário – apresenta o formato da tela requerida, o layout da
página e o tempo relativo de entradas e saídas.
3.5.2. Interface de Hardware – especifica as características entre o software e os
componentes de hardware do sistema.
3.5.3. Interface de Software – especifica o uso de outros produtos de software
necessários e interfaces com outros sistemas de aplicação.
3.5.4. Interface de Comunicação – especifica as interfaces de comunicação, por
exemplo, os protocolos de redes.
3.6. Outros Requisitos – descreve outros requisitos do sistema.
3.6.1. Banco de dados – especifica os requisitos para qualquer banco de dados que
tenha sido desenvolvido como parte do produto.
3.6.2. Operações – especifica as operações normais e especiais requeridas pelo
usuário.
3.6.3. Requisitos de Adaptação – define os requisitos para quaisquer dados ou
sequência de inicialização que sejam especificados para um dado.
3.7. Informação de Suporte – contêm a tabela de conteúdo, os apêndices e o índice, que
facilitam o uso do DRS.
Foi solicitado à empresa que se disponibiliza um DRS para ser utilizado no presente
trabalho, o qual seguiu as recomendações do IEEE (1998).
2.4.2. Defeitos em Requisitos de Software
A definição de defeito no contexto de requisitos de software é qualquer fato no documento
que possa causar um comportamento diferente do esperado, ou seja, qualquer ambiguidade,
falta ou inconsistência representa um defeito no documento de requisitos. Conforme Fagan
(1976) a maior parte desses defeitos podem ser identificados no início do processo de
desenvolvimento.
Há vários esquemas de classificação de defeitos (taxonomia de defeitos) propostos na
literatura, segundo a qual os defeitos são classificados em esquemas de: classificação de
29
defeitos para requisitos, classificação de defeitos por projeto e classificação de defeitos por
código. Percebe-se que a classificação de defeitos depende da fase do ciclo de vida na qual a
inspeção ocorrerá.
Basili e Weiss (1981) propuseram uma classificação de defeitos para documentos de
software com sete categorias, na Tabela 1 são apresentadas a classificação de defeitos para os
documentos de software.
Tabela 1 – Classificação de defeitos
Categoria Descrição
De digitação Problemas relativamente simples no documento de requisitos Ambiguidade Algo no documento que possui mais de um significado Omissão Algo que foi omitido no documento Inconsistência Duas partes no documento são incompatíveis com uma ou outra Fato incorreto Algo no documento que está incorreto em relação ao domínio Informação em seções erradas Informação incluída no documento em seção errada
Fato de implementação não fornecido
Informação necessária para o propósito da implementação não foi fornecido
Outros Defeitos que não se enquadram nas categorias anteriores
Ackerman et al. (1989) propuseram uma taxonomia que contem dois níveis, o
primeiro representa as informações da organização e o segundo é representado por perguntas
mais específicas para a descoberta dos defeitos. Na Tabela 2 é ilustrada a proposta dos
autores.
30
Tabela 2 – Classificação de defeitos
Nível Pergunta específica
Completude
1. Todas as fontes de entrada foram especificadas? 2. Qual é a entrada principal? 3. Há conjuntos “sem cuidados” na entrada principal? 4. Há necessidade de maior robustez na entrada de dados? 5. Há alguma restrição com relação ao tempo nas entradas? 6. Todos os tipos de saídas foram identificados? 7. Qual é a saída principal? 8. Há algum constrangimento de tempo nas saídas? 9. Há conjuntos que estão em ambos, na entrada e na saída? 10. Quais são os tipos de execução? 11. Qual é a entrada e a saída para cada tipo de execução? 12. Para cada tipo de execução, um valor de saída é especificado para cada
valor de entrada? 13. Estão definidos todos os mecanismos dos estados iniciais? 14. Todas as restrições do ambiente foram descritas? 15. São providos exemplos de amostras de entrada/saída apropriados? 16. Todos os requisitos de desempenho necessários estão descritos? 17. Todos os requisitos de confiabilidade foram especificados?
Ambiguidade
1. Todos os termos especiais estão claramente definidos? 2. Cada sentença tem uma interpretação única no domínio do problema? 3. O delineamento da entrada-para-saída está claramente definido para
cada tipo de execução?
Consistência
1. Qualquer um dos requisitos designados está em conflito com o material analisado?
2. Existe alguma entrada que está delineada para mais de uma saída? 3. Há um conjunto de unidades quantitativas a ser usada? 4. Todas as quantidades numéricas são consistentes?
Martin et al. (1992) propuseram uma classificação de defeitos que tem duas classes de
alto nível com subclasses.
Na Tabela 3 é ilustrada essa classificação.
31
Tabela 3 – Classificação de defeitos
Classes de Alto Nível
Subclasses Características
Informação Perdida
Funcionalidade ou característica perdida
A informação que descreve o comportamento interno do sistema foi omitida.
Interface perdida A informação sobre como o sistema comunica-se com os objetos fora dele foi omitida.
Desempenho perdido Especificações de desempenho foram omitidas ou não foram descritos os modos de teste.
Ambiente perdido Informações externas sobre hardware/software/banco de dados/pessoal envolvido foram omitidas.
Informação Errada
Informação ambígua Um termo importante não foi definido ou apresenta interpretações múltiplas.
Informação inconsistente
Duas partes do documento se contradizem.
A classificação de defeitos adotada no estudo realizado por Porter et al. (1994, 1995),
no qual discutem a técnica de leitura baseada em cenários (SBR), foi obtida a partir dos
estudos de Martin et al. (1992). Os autores comparam as técnicas de leitura: Ad Hoc,
Checklist e Cenários. Essa classificação de defeitos tem dois níveis, conforme apresentado na
Tabela 4. O primeiro nível é mais genérico e o segundo é mais específico, sendo útil para a
descoberta de defeitos. Tabela 4 – Classificação de defeitos
Classes Subclasses Características
Omissão
1. Funcionalidade omitida
A informação descreve que o comportamento operacional interno desejado do sistema foi omitido.
2. Desempenho omitido
A informação descrita para a especificação do desempenho desejada foi omitida ou foi descrita de forma inaceitável para os testes.
3. Ambiente omitido Informação descreve que os requisitos de hardware/software/banco de dados/pessoal envolvido foram omitidas.
4. Interface omitida Informação descrê que a comunicação do sistema proposto com os objetos que estão fora do escopo do sistema foram omitidas.
Comissão
1. Informação ambígua
Um termo importante, frase ou sentença para o entendimento do sistema foi indefinido ou definido de modo que possa causar confusão ou mau entendimento.
2. Informação inconsistente
Duas sentenças se contradizem ou expressam ações de que não estão corretas.
3. Funcionalidade incorreta
Alguma sentença afirma um fato que não pode ser verdade diante das condições especificadas.
4. Outros Outros defeitos que não se classificam nas subclasses anteriores.
32
Shull et al. (2000) propuseram a taxonomia ilustrada na Tabela 5, a qual é muito
utilizada na classificação de defeito detectado pela técnica de leitura baseada em perspectiva
(PBR). Essa classificação será utilizada neste trabalho.
Tabela 5 – Classificação de defeitos
Classificação do Defeito Característica
Omissão Qualquer requisito significante relacionado à funcionalidade, desempenho, restrições de projeto, atributos, ou interface externa que tenha sido omitido do documento de requisitos.
Informação ambígua Informação do documento de requisitos que pode ser interpretada de várias maneiras
Informação inconsistente Dois ou mais requisitos que se contradizem.
Fato incorreto Algum fato declarado no documento que não pode ser verdade diante das condições especificadas pelo sistema.
Informação estranha Informação desnecessária ou não usada.
Defeitos diversos Outros defeitos, tais como incluir um requisito na seção errada do documento de requisitos.
2.5. Revisões
Pressman (2005) considera as revisões de software como um filtro à Engenharia de Software,
pois elas podem ser aplicadas em vários pontos durante o desenvolvimento, servindo para
descobrir defeitos o mais cedo possível.
A detecção de erros de análise e projeto em relação à especificação, a identificação de
desvios de estilos de processos e convenções, a promoção do conhecimento em relação às
técnicas de desenvolvimento, ferramentas e métodos utilizados são exemplos de alguns
objetivos das revisões.
Conforme a IEEE 1028-97, a revisão é o processo ou reunião na qual um artefato é
apresentado à equipe, usuários, clientes e/ou gerentes para ser aprovado ou comentado. As
revisões podem ser:
Revisão técnica
Conforme Filho (2005), o objetivo dessa revisão é avaliar artefatos verificando se eles
estão em conformidade com os padrões e especificações e se suas eventuais modificações
foram efetuadas corretamente.
Wiegers (2002) afirma que a revisão técnica é como uma pequena inspeção, no entanto é
menos formal e menos rigorosa. Essa revisão permite que um grupo de pessoas treinadas
33
avalie quando um produto está apropriado para o uso e identifique se o produto atende às
especificações.
Revisão gerencial
Conforme a IEEE1028-97, a finalidade dessa revisão é monitorar o progresso, determinar
o status de planos e agendamentos e avaliar a eficácia da abordagem da revisão gerencial. A
revisão gerencial dá apoio à tomada de decisão referente às ações corretivas, realocação de
recurso ou alterações no escopo do projeto.
Revisão por pares (Peer Review)
Para Galin (2004), essa revisão consiste em detectar desvios de padrões e erro, seus
participantes geralmente são líderes do projeto e membros da equipe, seu principal objetivo é
detectar erros e desvios de padrões adotados para o projeto. O maior fator de contribuição
para o sucesso de um Peer Review é a integração do grupo.
Revisão de apresentação (Walkthroughs)
Para Filho (2002), nessa revisão o autor apresenta o material em ordem lógica, sem limite
de tempo, para um grupo que o verifica a medida que é apresentado. Nessa revisão pode-se ter
um número maior de participantes, os quais não precisam ter uma preparação prévia. Essa,
segundo Wiegers (2002), é uma revisão informal, na qual o autor descreve o artefato para um
grupo de pares e solicita comentários.
Passaround
Nessa revisão o autor seleciona os participantes, os quais não têm papéis específicos.
Conforme Wiegers (2002), seu objetivo é encontrar defeitos, verificar a conformidade com
padrões e especificações. Ajuda na educação dos participantes em relação ao artefato.
Inspeção
A inspeção, por ser o foco deste trabalho, segue na próxima seção.
2.5.1. Inspeção de Software
Inspeção é um tipo de revisão mais formal e rigorosa, cujo objetivo é detectar e remover os
defeitos. É obrigatória a geração de uma lista de defeitos com classificação padronizada e o
autor deve remover os defeitos detectados. (FILHO, 2005)
Para Wiegers (2002), uma inspeção é o tipo mais sistemático e rigoroso de revisão e é
identificada como a melhor prática de revisão na indústria de software, enquanto que revisões
menos formais não possuem esta característica.
34
A Tabela 6 apresenta os tipos de revisões e as recomendações de uso, conforme
Wiegers (2002).
Tabela 6 – Tipos de revisões e as recomendações de uso conforme Wiegers (2002)
Objetivo Inspeção Revisão
técnica
Revisão de
apresentação
Programação
por pares Passaround
Detectar defeitos X X X X X
Verificar conformidade
com especificações X X X
Verificar conformidade
com padrões X X
Verificar completeza e
correção do artefato X X
Avaliar compreensão e
manutenibilidade X X X X
Coletar dados para
melhoria de processos X X
Medir qualidade do
artefato X
Educar a equipe sobre o
artefato X X X X
Alcançar consenso sobre
uma abordagem X X X
Garantir a correção dos
defeitos X X
Explorar abordagens
alternativas X
Conforme Delamaro et al. (2007), a construção de software não é uma tarefa simples e
dependendo das características e dimensões do sistema, ela pode se tornar uma tarefa bastante
complexa. Dessa forma, o software está sujeito a diversos tipos de problemas resultando em
um produto diferente do esperado, sendo que a maioria dos problemas tem como fonte o erro
humano.
35
Segundo Myers (2004) quanto mais cedo os defeitos nos sistemas forem corrigidos,
menor é o seu custo de correção para o projeto. Rakitin (2001) reforça que o custo relativo
para encontrar e corrigir um defeito aumenta dramaticamente quando esse defeito é
encontrado no produto já desenvolvido. Logo encontrar os defeitos no software na fase inicial
reduzirá os custos operacionais e incrementará o nível de satisfação dos usuários.
A qualidade de software torna-se cada vez mais importante devido ao aumento do uso
de software por toda sociedade. Inspeção (Fagan 1976; Ackerman et al. 1989) e teste (Hetzel
1998) são duas técnicas amplamente recomendadas para a melhoria da qualidade de software.
As inspeções podem ser aplicadas nos estágios iniciais do processo de desenvolvimento do
software e ajudam a evitar um dispendioso retrabalho, Fagan (1976) afirma que é no início do
processo de desenvolvimento que é injetado maior quantidade de defeitos e que é menos
dispendioso detectar e reparar os defeitos na etapa em que eles forem inseridos do que tentar
detectar e remover os defeitos durante o teste do software. Russel (1991) ressalta que a
inspeção não substitui os testes, afirma que eles devem ser combinados.
Conforme Boehm e Basili (2001) a inspeção de software permite detectar defeitos no
início do desenvolvimento de software, reduzindo assim o custo do retrabalho, que em geral é
responsável por 40-50% do desenvolvimento. Na Figura 2 é ilustrada uma estimativa de
retrabalho que se pode evitar utilizando-se de inspeção de software.
Figura 2 – Estimativa de retrabalho evitável utilizando-se inspeção de software. Fonte: Boehm e
Basili (2001)
36
Com a remoção dos defeitos melhora-se a qualidade do artefato sob inspeção, assim
como se fornece dados para melhorar o processo de desenvolvimento. Além disso, a leitura do
artefato melhora a comunicação entre os membros da equipe e serve para treinamento dos
participantes para se evitar defeitos.
Apesar dos benefícios comprovados da inspeção, ela apresenta alguns problemas.
Conforme Harjumaa et al. (2004), a falta de tempo e recursos humanos são os fatores mais
influentes para não se ter inspeções nas organizações. Por esta razão, os gerentes são céticos
em adotar a inspeção. Esses problemas acentuam-se no desenvolvimento distribuído de
software, uma vez que a inspeção é uma atividade centrada em reunião. Na tentativa de
diminuir o custo, o tempo total do processo de inspeção, a necessidade de reunião face-a-face
da equipe, pesquisadores (Votta (1993); Johnson (1994); Sauer et al. (2000)) têm debatido a
possibilidade de otimizar o processo de inspeção, preservando as vantagens da inspeção.
2.5.1.1. Processo de Inspeção
A inspeção de software, como processo estruturado, foi primeiramente descrito por Fagan
(1976) para controlar e melhorar o processo de desenvolvimento de software, resultando em
maior produtividade e qualidade do produto.
Rakitin (2001) afirma que o processo de inspeção pode ser aplicado a todos os
artefatos produzidos no ciclo de desenvolvimento, pois a inspeção é um processo formal e as
atividades e os papéis estão bem definidos. É considerado um processo formal, uma vez que o
processo, suas etapas, os papéis dos participantes são bem definidos, existem critérios de
entrada e saída de dados e há dados a serem coletados, que o difere das revisões informais,
como por exemplo, walkthroughs.
Um artefato é um critério de entrada, ele deve estar em conformidade com as normas
aplicáveis ao projeto. Existe um fluxo de trabalho a ser seguido no processo de inspeção, ou
seja, há várias etapas a serem cumpridas. Os papéis são bem definidas, por exemplo, inspetor,
moderador, autor etc. Vale salientar que tanto as funções quanto as etapas diferem entre os
vários processos existentes. A coleta de dados captura as discrepâncias encontradas, que
podem ser categorizadas e, também, registra o tempo que cada membro da inspeção levou
para executar seu trabalho. Com esses dados poder-se-á analisar a eficácia das inspeções na
detecção dos defeitos, o esforço médio, defeito/hora, na detecção dos defeitos, os gastos
poupados por evitar o retrabalho. Como critério de saída ter-se-á um artefato inspecionado,
37
em conformidade com as normas que foram incluídas no critério de entrada. Conforme Fagan
(1986) defeito é uma instância em que um requisito não é cumprido.
Na literatura corrente podem ser encontrados diferentes processos para apoiar a
inspeção, entre eles podem ser citados: Fagan (1976), Parnas e Weiss (1987), Humphrey
(1989), Bisant e Lyle (1989), Johnson (1994) e Sauer et al. (2000) entre outros. Vale salientar
que Fagan (1976), foi quem desenvolveu o processo tradicional de inspeção de software,
composto de seis atividades principais, que são: Planejamento; Apresentação; Preparação;
Reunião; Retrabalho e Acompanhamento.
No Planejamento, selecionam-se os inspetores, define-se o escopo da inspeção e são
distribuídos os artefatos a serem inspecionados. Na Apresentação, o grupo, os envolvidos na
inspeção, recebem orientações essenciais sobre os artefatos a serem inspecionados. Os autores
dos artefatos apresentam as características dos artefatos que serão inspecionados. Na
Preparação, os inspetores inspecionam o artefato individualmente produzindo, se necessário,
uma lista de discrepâncias encontradas.
Na Reunião de Inspeção, da qual participam o moderador, os inspetores e o autor do
artefato, as discrepâncias são discutidas e categorizadas como defeito ou falso positivo. O
moderador é quem tem a decisão final referente à categorização de uma discrepância, caso ela
seja definida como defeito, pode-se diferenciá-lo utilizando a classificação de defeitos
definida por Shull (1998) categorizando o defeito como: omissão, ambiguidade,
inconsistência, fato incorreto, informação estranha e outro. Caso a reunião precise de mais de
duas horas, o moderador sugere que continue no próximo dia.
No Retrabalho, o autor do artefato corrige os defeitos apresentados pelos inspetores e
confirmados pelo moderador.
No Acompanhamento, o artefato corrigido é encaminhado ao moderador, que o
verifica como um todo e, se for necessário, decidirá se uma nova inspeção deve ou não
ocorrer. Na Figura 3 é ilustrado o processo de inspeção segundo Fagan (1976).
38
Figura 3 – Processo tradicional de inspeção. Fonte: Fagan (1976)
No processo original de Fagan (1976), a etapa Preparação é usada pelos inspetores
para obter uma compreensão mais profunda do artefato e a etapa Reunião é utilizada pelos
inspetores para detectar os defeitos. Embora os defeitos possam ser detectados durante a
Preparação, muitas vezes é assumido que a Reunião permite aos inspetores detectar mais
defeitos.
No entanto, uma série de estudos empíricos verifica a utilidade da reunião de inspeção
na questão de saber se elas são realmente necessárias. Votta (1993) sugere que as reuniões de
inspeção não são necessárias, pois o número de novos defeitos detectados nela é relativamente
39
pequeno. Além disso, a reunião de inspeção aumenta o custo e a complexidade logística de
inspeção, devido ao atraso na realização das reuniões.
Parnas e Weiss (1987) apresentaram um processo de inspeção denominado de Active
Design Review (ADR) em que sugerem diminuir o número de pessoas que participam de uma
inspeção, apenas dois papéis são definidos no ADR: revisor e autor. Os revisores devem
especificar sua experiência e seus conhecimentos antes da seleção da equipe. Durante a
revisão do documento, os revisores têm de ler atentamente o documento e responder a um
questionário elaborado pelos autores. Devido à sua experiência e aos conhecimentos, os
revisores devem se concentrar para encontrar diferentes tipos de defeitos. A reunião é feita
apenas entre os autores e revisores.
Humphrey (1989) descreve uma variante do processo de Fagan (1976) em que muda o
foco da atividade de preparação individual, pois, ao invés de entender o artefato a ser
inspecionado, o inspetor tenta efetivamente encontrar seus defeitos. Assim, cada um dos
inspetores entrega uma lista de discrepâncias para o moderador antes do início da reunião de
inspeção, dessa forma o objetivo da reunião passa então a ser discutir as discrepâncias
encontradas e classificá-las como defeito ou falso positivo.
Para reduzir o custo das reuniões, Bisant e Lyle (1989) propõem a inspeção de duas
pessoas (Two-person inspection) em que a equipe de inspeção inclui apenas o autor e um
revisor. O revisor realiza a análise individual do documento a ser inspecionado e, em seguida,
se encontra com o autor em uma sessão de reunião.
Gilb e Graham (1993) propuseram um processo com etapas diferentes dos definidos
por Fagan (1976), embora na prática sejam muito semelhantes. As etapas são as seguintes:
Entrada, Planejamento, Reunião de Partida, Verificação, Registro de Reunião, Brainstorming,
Edição, Acompanhamento, e por fim, Saída. Há três papéis definidos: líder, autor e inspetor.
Este processo difere do tradicional, pois adiciona uma etapa ao processo, chamado
Entrada, que é útil para assegurar que vale a pena inspecionar o documento, e adiciona
também a etapa Brainstorming que é uma atividade pós-reunião que serve para registrar as
sugestões de melhoria para o processo de desenvolvimento.
O processo apresentado por Wiegers (2001) é semelhante de Gilb e Graham (1993) e
consiste de sete etapas: Planejamento, Visão Geral, Preparação, Reunião, Retrabalho,
Acompanhamento e Análise Causal. Na etapa Planejamento, o autor apresenta ao moderador
o objetivo da inspeção e, em conjunto, decidem quem deve participar da equipe de inspeção.
Na etapa Visão Geral, opcionalmente, pode ser realizada uma reunião informal para
apresentar a todos os participantes o material de inspeção. A Preparação e a Reunião são as
40
etapas mais importantes no processo de Wiegers, pois com a remoção da Preparação ter-se-ia
um walkthrough ao invés de uma inspeção, já a remoção da etapa reunião resultaria em um
passaround, ambos, walkthrough e passaround, são considerados revisões informais. Durante
a etapa Reunião o leitor, responsável por fazer a leitura de partes do artefato inspecionado,
descreve o documento sob inspeção a todos os participantes, em seguida, os inspetores podem
fazer perguntas e fazer comentários sobre os defeitos encontrados. Durante a etapa Retrabalho
todos os defeitos registrados são corrigidos pelo autor. Na etapa Acompanhamento, o
moderador e autor se reúnem para verificar se todos os defeitos foram efetivamente resolvidos
e se as correções foram feitas de modo aceitável. Durante a etapa Análise Causal, semelhante
à etapa Brainstorming da inspeção de Gilb e Graham (1993), a causa raiz de cada defeito é
analisada, a fim de melhorar o processo de desenvolvimento.
Johnson (1994) propõe o processo FTArm (Formal Technical Asynchronous review
method – Método de Revisão Técnica Formal Assíncrona), um método de inspeção geral. As
etapas do FTArm são: Configuração, Orientação, Revisão Particular, Revisão Pública,
Consolidação e Revisão do Grupo. O processo começa com a etapa Configuração para
selecionar a equipe de inspeção e preparar o documento a ser inspecionado. A etapa
Orientação tem o mesmo objetivo da etapa Visão Geral do processo tradicional de Fagan
(1976). Na etapa Revisão Privada os inspetores individualmente inspecionam o documento
criando comentários diretamente no documento. Durante a etapa Consulta Pública, os
comentários de todos os inspetores são publicados e os inspetores podem votar (confirmar,
refutar, ou neutro) de forma assíncrona para qualquer comentário. Na etapa Consolidação, o
moderador resume os resultados e, se estiver tudo ok fecha a inspeção, assim, a etapa Revisão
do Grupo, uma reunião face-a-face, pode ser realizada apenas para questões pendentes, se
houverem.
Baseado na teoria comportamental de desempenho do grupo, Sauer et al. (2000)
propuseram uma reorganização do processo tradicional de inspeção para diminuir o custo
total e o tempo total do processo de inspeção. Os autores afirmam que essa reorganização
consiste, principalmente, em substituir as etapas de preparação e reunião de inspeção do
processo tradicional por três novas etapas sequenciais: Detecção, Coleção e Discriminação de
Defeitos, conforme apresentado na Figura 4.
A etapa de descoberta de defeito, Detecção de Defeito, reflete a mudança do objetivo
para a etapa Preparação que mudou de entendimento do artefato para detecção de defeitos.
Logo, os inspetores devem, individualmente, procurar por defeitos no artefato. As outras duas
etapas é o resultado de separar a etapa de coleta, na qual se reúne as listas de defeitos dos
41
inspetores, da etapa de discriminação, na qual se remove os falsos positivos. Sauer et al.
(2000) afirmam que não há necessidade de toda a equipe participar da etapa de discriminação,
portanto, pode-se ter apenas um inspetor experiente em conjunto com o autor.
Outra mudança para poupar tempo e diminuir a sobrecarga de coordenação é a
possibilidade de pular a etapa Discriminação, passando todos os defeitos diretamente para o
autor para a etapa Retrabalho, ou parcialmente, excluindo das discussões defeitos potenciais
(encontrado por inspetores durante a etapa de detecção e unidos na etapa de coleta) são
considerados como tendo grandes chances de serem defeitos verdadeiros, isso devido aos
efeitos de pluralidade, então Sauer et al. (2000) propõem selecionar para etapa de
discriminação apenas defeitos únicos, aqueles que foram encontrados por apenas um inspetor
durante a etapa de detecção. Na Figura 5 são apresentadas as atividades propostas por Sauer et
al. (2000).
Figura 4 – a) Processo de inspeção tradicional, b) processo de inspeção reorganizado. Adaptado de Fagan (1976) e Sauer (2000)
a
Planejamento da Inspeção
Visão Geral
Preparação
Reunião de Insp.
Retrabalho
Acompanhamento
Planejamento da Inspeção
Visão Geral
Detecção de Defeitos
Coleção de Defeitos
Discriminação de Defeitos
Retrabalho
Acompanhamento
b
42
Figura 5 – Atividades sequenciais sugeridas por Sauer et al. (2000)
O processo reorganizado de Sauer et al. (2000) fornece apoio para execução da
inspeção de forma distribuída, uma vez que reduz a necessidade de comunicação síncrona
entre os inspetores e diminui a sobrecarga sobre o moderador.
Existe também o Processo de Inspeção do Institute of Electrical and Electronics
Engineers IEEE (STD-1028-1997 Standard for Software Reviews), que estabelece definições
e requisitos padronizados para processos de revisão e auditoria. Esse processo conta com as
seguintes etapas: Gestão da Preparação, Planejamento da Inspeção, Visão Global do processo
de inspeção, Preparação, Verificação (exame), Retrabalho/Acompanhamento.
A National Aeronautics and Space Administration (NASA) também tem seu processo
de inspeção, Software Formal Inspection Guidebook. Suas etapas são as seguintes:
Planejamento, Visão Global, Preparação, Reunião de Inspeção, Terceira Hora, Retrabalho,
Acompanhamento.
Mishra e Mishra (2009) propõem o processo simplificado de inspeção de software que
é uma combinação de vários processos como Gilb e Graham (1993), Humphrey (1989) e
Fagan (1976). Os autores afirmam que os envolvidos não são obrigados a estarem juntos na
mesma hora e local. As etapas desse processo são: Configuração, Orientação, Inspeção
Particular, Controle de Inspeção, Reunião, Retrabalho, Acompanhamento. Na Figura 6 é
ilustrado o fluxo do processo simplificado de inspeção de software, assim como suas etapas.
Figura 6 – Processo Simplificado de Inspeção. Fonte: Mishra e Mishra (2009)
43
Com base em seu processo simplificado Mishra e Mishra (2010) propõem o processo
de inspeção global, ilustrado na Figura 7, ele é composto pelas seguintes etapas:
Configuração, Inspeção Individual, Reunião, Retrabalho e Acompanhamento. Com base nesse
processo, os autores apresentaram uma ferramenta Web para automatizar a inspeção, ela
disponibiliza os artefatos para download pelos inspetores que podem adicionar seus
comentários, a reunião de inspeção é on-line, caso algum inspetor não puder entrar no horário
da reunião, ele poderá baixar o log da reunião para ter conhecimento dos detalhes. Conforme
os autores há a possibilidade de obter os dados de inspeções anteriores, provendo assim uma
possibilidade de se estimar custos, tempo e recursos para inspeção.
Figura 7 – Processo de Inspeção de Software Global. Fonte: Mishra e Mishra (2010)
Outros processos identificados na literatura, N-fold Inspection, de Martin e Tsai (1990)
dividem os inspetores em N equipes pequenas. Todas essas equipes inspecionam o mesmo
documento, as equipes são supervisionadas por um moderador. Inspecting for Program
Correctness, definido por Britccher (1988), é uma variação do ADR e incorpora correção de
argumentos nos questionários. Phased Inspeciton, apresentado por Knight e Myers (1993), a
inspeção é dividida em várias mini-inspeções ou etapas. Cada etapa garante o artefato tem
propriedades relacionadas.
A partir da análise dos processos discutidos, é proposto neste trabalho uma abordagem
que tem por base os processos de Fagan (1976), IEEE-1028 e Sauer et al. (2000). Utilizou as
etapas dessa abordagem para propor as atividades da estratégia proposta neste trabalho, a qual
dá apoio à inspeção de software em DDS. Observa-se, diante do exposto, que os processos
44
apresentados não levam em consideração o modelo de negócio, isso será considerado na
abordagem proposta neste trabalho.
2.5.1.2. Técnicas de Leitura
Técnica de leitura é uma estratégia de detecção de defeitos que orienta os inspetores durante a
busca por defeitos. Conforme Mafra e Travassos (2005) o termo leitura foi escolhido por ter
similaridades com o processo mental que as pessoas utilizam para entender o significado de
algum texto. Shull (1998) afirma que se deve atentar a três critérios para compor uma técnica:
i) Ela deve ter uma série de passos, orientando o inspetor desde um procedimento
com uma série de passos a um conjunto de questões tendo como objetivo manter o
foco na leitura;
ii) A inspeção é uma tarefa individual, assim a técnica deve se preocupar com o
processo de compreensão de indivíduo; e
iii) A técnica deve apoiar a obtenção de certo nível de entendimento dos aspectos do
artefato.
Conforme Basili et al. (1996) as técnicas de leitura devem ser bem definidas,
orientadas a objetivos e dependentes de contexto. Dessa forma, eles estabeleceram os
seguintes requisitos para uma técnica de leitura:
i) Deve estar associada a um tipo de artefato (p. ex. documento de requisitos),
associada também a uma notação que o artefato foi descrito (p. ex. língua
portuguesa);
ii) Deve ser adaptável de acordo com as características da organização e do
desenvolvimento;
iii) Deve ser bem definida, podendo ser executada em outros projetos; e
iv) Deve ser avaliada experimentalmente para determinar sua viabilidade e seu grau
de efetividade na detecção de defeitos.
Várias técnicas de leitura são propostas na literatura, a seguir são discutidas algumas
delas.
Ad-hoc – esta é a técnica mais simples de leitura, conforme (Porter e Votta, 1994) não
fornece apoio algum aos inspetores. Os inspetores devem confiar em sua própria intuição e
experiência para determinar como encontrarão defeitos no artefato. O ponto positivo nessa
técnica é que os inspetores mais experientes têm a liberdade de usar seus conhecimentos para
encontrar defeitos, enquanto o ponto negativo é que, sem apoio, os inspetores menos
45
experientes têm dificuldades para detectar os defeitos de forma eficaz. Travassos afirma que
nesta técnica o inspetor lê o documento de acordo com sua perspectiva, sua experiência afeta
o resultado final e não há garantia de cobertura do artefato como um todo. Pode ser utilizada
qualquer notação. A técnica ad-hoc não é sistemática, nem adaptável e, também, não necessita
de treinamento.
Leitura baseada em checklist (Checklist-Based Reading – CBR) – é uma técnica
amplamente utilizada desde 1970. Ela fornece aos inspetores uma lista de questões que os
ajudam, a saber qual tipo de defeito procurar no artefato. Os inspetores são convidados a
responder a essas perguntas durante a leitura do artefato de software.
Conforme Gilb e Graham (1993) cada artefato de software tem seu próprio checklist.
As questões que compõem o checklist são criadas com base na origem dos defeitos
identificados nos dados históricos de uma organização. Dessa forma, as questões refletem
defeitos que a organização já havia encontrado anteriormente.
Brykczynski (1999) afirma que o checklist deve caber em um único lado de uma folha
de papel, pois isso evita que o inspetor tenha que virar a página de forma contínua,
interrompendo assim sua concentração.
Na leitura baseada em checklist, o inspetor responde a uma série de perguntas sobre o
artefato. Cada pergunta exige ou “sim” ou “não” como resposta. A resposta “sim” indica que
o artefato em relação a essa pergunta é livre de defeito, já a resposta “não” indica a
possibilidade de um defeito no artefato, exigindo uma investigação mais profunda pelo
inspetor. É apresentado na Figura 8 parte de um checklist.
Figura 8 – Parte de um checklist. Fonte: McMeekin et al. (2008)
Laitenberger e DeBaud (2000) identificaram alguns pontos fracos na leitura baseada
em checklist:
46
i) As perguntas muitas vezes são gerais e não suficientemente adaptadas a um
ambiente de desenvolvimento qualquer;
ii) As instruções de como utilizar os checklists muitas vezes são ausentes. É pouco
claro com base em que informações um inspetor responderá aos questionamentos;
iii) As questões do checklist muitas vezes são limitadas à detecção de defeitos que
pertencem a vários tipos de defeitos em particular.
O ponto forte da CBR é que ela dirige explicitamente o inspetor em busca de defeitos
dentro no artefato, o checklist é um produto de inspeções anteriores, portanto, levando em
consideração a história da organização em relação aos defeitos anteriores. A limitação dessa
técnica, CBR, é que ela é altamente estruturada, o que pode impedir os inspetores
principalmente para aqueles mais experientes, a ter uma leitura de maneira mais natural. Além
disso, os inexperientes podem ser dirigidos para longe dos defeitos não diretamente
direcionados pelas questões do checklist e, portanto, esses defeitos não serão detectados.
Leitura baseada em cenários (Scenario-Based Reading – SBR) – essa técnica foi
criada para suprir a falta de eficácia das técnicas anteriores, Ad-hoc e Leitura baseada em
checklist. Como elas são técnicas não-sistemáticas, elas não oferecem um conjunto concreto
de instrução de leitura, pois a experiência do inspetor tem um impacto significativo sobre a
quantidade de defeitos encontrados. (Laitenberger e DeBaud, 2000). Conforme Porter e Votta
(1994) a SBR foi criada originariamente para detectar defeitos em documento de
especificação de requisitos.
A leitura baseada em cenários fornece um cenário que dá a orientação aos inspetores
sobre como proceder e o que procurar durante a inspeção. Assim, vários cenários são
desenvolvidos com foco específico em determinado ponto de vista. Cada inspetor executa um
único cenário e a combinação de vários cenários fornecerá uma cobertura ampla do artefato.
(Porter e Votta, 1994)
A vantagem da SBR é que cenários bem definidos produzem bons resultados e podem
ser utilizados em momentos posteriores por desenvolvedores e inspetores. Já a desvantagem é
que se os cenários não forem bem definidos reduzirão a eficácia dessa técnica de leitura, pois
geralmente é necessário grande investimento de tempo e esforço para criar cenários para
detectar defeitos e dessa forma pode vir a ser caro a longo prazo para o projeto.
Diversas variantes da leitura baseada em cenários foram propostas: leitura baseada em
perspectiva (Perspective Based Reading – PBR), leitura baseada em defeito (Defect Based
Reading – DBR) e leitura baseada em rastreabilidade (Traceability Based Reading – TBR).
47
Conforme Basili et al. (2000) a idéia principal da técnica de leitura baseada em
perspectiva é que o artefato de software deve ser inspecionado a partir da perspectiva de
diferentes interessados. As perspectivas dependem das funções que as pessoas têm no
desenvolvimento de software. Essa técnica assume que um inspetor com um foco específico
execute melhor do que um inspetor que tenta detectar todos os possíveis defeitos de um
artefato de software, e que a união das perspectivas fornece uma cobertura ampla do artefato.
Basili (1996) apresentou três perspectivas: do usuário do sistema, do projetista e do
responsável pelos testes. Shull et al. (2000) afirma que PBR é utilizada para detecção de
defeitos em documento.
Basili et al. (2000) descrevem a criação dos cenários da PBR em três passos:
i) Escolher a perspectiva com base na qual o artefato será inspecionado;
ii) Escolher um modelo do documento que faça sentido para cada perspectiva; e
iii) Escolher os tipos de defeitos de interesse da organização e utilizar essa informação
para formular as questões específicas sobre cada modelo.
Conforme Laitenberger e Atkinson (1999) para examinar um documento em uma
perspectiva em particular, a técnica PBR consiste em três seções principais:
i) Introdução – descreve os requisitos de qualidade mais relevantes para uma
determinada perspectiva;
ii) Instrução – descreve o tipo de documento que será utilizado, como lê-lo, e como
extrair as informações necessárias. O objetivo principal das instruções é obter uma
melhor cobertura de detecção de defeitos em um artefato de software; e
iii) Perguntas – descreve um conjunto de perguntas que os inspetores terão que
responder durante a inspeção.
Shull et al. (2000) apresentaram os seguintes benefícios da PBR:
i) Sistemática – PBR identifica diferentes usos do documento (perspectivas), e um
procedimento (passos);
ii) Focada – PBR ajuda os inspetores a se concentrarem de forma mais eficaz em
determinados tipos de defeitos, ao invés de ter que olhar para todos os tipos
possíveis;
iii) Orientada para metas e customizável – Perspectivas diferentes podem ser
utilizadas para refletir objetivos específicos, e PBR pode ser facilmente
customizável para um projeto específico ou organização; e
48
iv) Transferível por treinamento – Já que PBR funciona como um procedimento
definido que não depende da experiência do inspetor, novos inspetores podem
receber treinamento nas etapas do procedimento quando forem aplicar a técnica.
Porter et al. (1995) afirmam que a idéia principal da leitura baseada em defeitos,
DBR, é que os inspetores devem se concentrar em diferentes classes de defeitos e, então para
cada classe de defeitos um cenário distinto será desenvolvido. Os autores desenvolveram
cenários para os seguintes tipos de defeitos no documento de especificação de requisitos:
inconsistência de dados, funcionalidade incorreta, ambigüidade, falta de funcionalidade.
Outra variante da técnica de leitura baseada em cenários é a leitura baseada em
rastreabilidade, TBR, a qual foi desenvolvida por Travassos et al. (1999) especificamente
para inspecionar documentos de projetos em Orientação a Objetos criados usando a Unified
Modeling Language (UML). Essa técnica analisa, especificamente, os documentos de alto
nível e realiza a leitura em duas direções conforme ilustrado na Figura 9.
Figura 9 – Tipos de leitura na leitura baseada em rastreabilidade. Fonte: Travassos (1999)
i) Horizontal: o objetivo da leitura horizontal é assegurar que todos os artefatos de
projeto representam o mesmo sistema, dessa forma garante a consistência.
ii) Vertical: o objetivo da leitura vertical é verificar se os documentos de projeto
correspondem aos requisitos e casos de uso, garantindo a rastreabilidade dentro de
um domínio com o objetivo de encontrar defeitos entre eles.
49
2.6. Inspeção de Software e DDS
Yousuf et al. (2008) argumentam que inspeções em DDS, tornam-se complexas, uma vez que
o compartilhamento de informações relacionadas aos requisitos é feito por meio de reuniões
formais. A comunicação informal é quase inexistente no contexto distribuído. Afirmam os
autores que a forma síncrona, comunicação em tempo real, fica prejudicada devido ao fuso
horário. Deve-se atentar às sobreposições dos horários de expediente no fuso-horário e
aproveitar para reunir os envolvidos na inspeção. Já a forma assíncrona gera problema de
atraso, no entanto, é uma forma de trocar os documentos, como ocorre, por exemplo, no uso
do e-mail. Afirmam ainda que na comunicação face-a-face tem-se maior probabilidade de se
construir confiança entre os envolvidos, as características do DDS transformam-se em
barreiras para essa construção.
Pode-se ter no DDS clientes e equipes dispersas por diferentes lugares, até mesmo em
continentes diferentes. Portanto, as atividades de validação dos requisitos diferem do
desenvolvimento tradicional, na avaliação de Yousuf et al. (2008), problemas como
comunicação, controle, compartilhamento de conhecimento, confiança e atraso são muitos
significativos, em particular no que se refere à inspeção.
Calefato et al. (2007) relatam os efeitos da interação síncrona e assíncrona em
reuniões distribuídas com o objetivo de chegar a acordos mútuos entre os envolvidos. Os
resultados mostraram que as reuniões de inspeção síncronas são mais eficientes que as
reuniões assíncronas. Sugerem que, no contexto distribuído, quando o horário comercial se
sobrepõe é preferível reunião síncrona à reunião assíncrona, uma vez que aquela pode
diminuir o tempo total da inspeção. Afirmam que o tipo do artefato que se inspeciona
influencia na eficácia, pois um maior número de acordos mútuos foi alcançado quando se
analisou o documento do projeto em relação ao documento de requisitos. Ainda, quanto maior
o nível de abstração do artefato mais difícil será a identificação de uma falha. A TSMC, teoria
da sincronicidade dos meios de comunicação é utilizada pelos autores para verificar a
integração entre eles. Segundo essa teoria, a comunicação síncrona é mais adequada para
apoiar tarefas de tomada de decisão, tais como nas reuniões de inspeção, onde a convergência
é necessária.
Dennis e Valacich (1999) argumentam que existe convergência quando os
participantes concordam com o significado da informação e quando todos concordam que
estão de acordo com esse significado. Eles afirmam que, geralmente, o processo de
convergência melhora com meios de comunicação com elevado nível de sincronismo.
50
Tabela 7 – Análise dos trabalhos
Características do DDS Calefato et al. (2007)
Yousuf et al. (2008)
Lanubile et al. (2003)
Kalinowski e Travassos (2004)
Distância geográfica Sim Sim Sim Sim
Distância Temporal Sim Sim Não Sim
Distância sociocultural Não Sim Não Não
Modelo de Negócio Não Não Não Não
Observa-se que dos trabalhos relacionados nenhum deles levam em consideração o
modelo de negócio, algo que foi considerado neste trabalho para propor a abordagem e a
estratégia para apoio à inspeção em DDS.
2.7. Ferramentas de Inspeção de Software
Algumas ferramentas de apoio ao processo de inspeção têm sido apresentadas na literatura e,
estas serão apresentadas e analisadas a seguir.
Conforme Brothers et al. (1990), o ICICLE (Intelligent Code Inspection Environment
in a C Language Environment) é um sistema destinado à inspeção de código em Linguagem
C e faz uso do conhecimento específico da linguagem para auxiliar na identificação de
defeitos. Oferece ainda o suporte à discussão e finalização das observações dos inspetores
durante a reunião de inspeção, ela oferece apoio à comunicação síncrona para reuniões de
grupo.
O CSI (Collaborative Software Inspection), apresentado por Mashayekhi et al. (1993),
é uma ferramenta que proporciona um ambiente distribuído, estruturado para realização de
inspeções em todos os artefatos de desenvolvimento de software. O sistema permite controle
dos participantes geograficamente distribuídos.
Scrutiny é um sistema colaborativo e distribuído para inspeção e revisão dos artefatos
de software, Gintell et al. (1993). O sistema implementa um processo de inspeção semelhante
ao modelo de Fagan (1976). O processo consiste em quatro etapas: Iniciação, Preparação,
Resolução (similar à Reunião) e Conclusão (Retrabalho e Acompanhamento). O sistema
acrescenta o papel verificador que é responsável por verificar se todos os defeitos são
corrigidos pelo autor.
Stein et al. (1997) propuseram, AISA (Asynchronous Inspector of Software Artifacts),
um protótipo para inspeção de artefatos de software. O inconveniente é que assim que o
51
inspetor entra com suas anotações, todos os outros recebem notificações e podem visualizá-
las, dessa forma há influência na decisão e dificulta a identificação de possíveis falsos
positivos. Para que isso não ocorra, Murphy e Miller (1997) propuseram o InspectA que
encaminha as notificações somente após a conclusão de todas as etapas de detecção.
Segundo Macdonald e Miller (1998) ASSIST (Asynchronous/Synchronous Software
Inspection Support Tool), é uma ferramenta genérica, criada para permitir a execução e apoio
a qualquer processo de inspeção, isso é conseguido com um processo de modelagem
projetado em linguagem personalizada (Inspection Process Definition Language). ASSIST é
baseado em uma arquitetura cliente/servidor, em que o servidor é usado como um repositório
central de documentos e no cliente ficam os dados. A ferramenta dá suporte à comunicação
síncrona e assíncrona.
Grünbacher et al. (2003) propuseram a GRIP (GRoupware supported Inspection
Process) que provê um framework e ferramentas colaborativas para uma equipe de inspetores,
a ferramenta dá suporte às reuniões de inspeção, bem como ao processo de inspeção como um
todo. Durante a reunião, a ferramenta permite um consenso da severidade dos defeitos
detectados pelos inspetores por meio de um sistema de votação. A ferramenta auxilia o
Moderador, pois elimina automaticamente falso-positivos, com base na votação de todos os
inspetores. O processo de inspeção utilizado pela ferramenta envolve quatro etapas:
Planejamento, Inspeção Individual, Reunião Assíncrona e Avaliação da Inspeção.
Lanubile et al. (2003) propuseram a IBIS (Internet Based Inspection System), uma
ferramenta que se apóia na proposta de Sauer et al. (2000) e é baseada na internet, ela utiliza
notificação por e-mail para apoiar as inspeções assíncronas com equipes distribuídas
geograficamente. As discrepâncias encontradas na detecção de defeitos são tratadas como
tópicos de discussão, o moderador pode categorizar as discrepâncias como defeito ou falso
positivo.
Hedberg e Harjumaa (2002) propuseram a XATI (XML Annotation Tool for
Inspection) que é uma ferramenta para apoiar inspeção. Os autores definiram o conceito
inspeção virtual de software e afirmam que a ferramenta é o processo em si, pois ela obedece
a um fluxo de trabalho definido em si própria. Essa ferramenta foi desenvolvida baseada na
experiência de seus autores em outras ferramentas de inspeção.
ISPIS (Infraestrutura de Suporte ao Processo de Inspeção de Software) foi proposta
por Kalinowski e Travassos (2004) e se apóia também na proposta de Sauer et al. (2000). É
uma ferramenta que possibilita o uso automatizado do conhecimento de inspeção, uma vez
que ISPIS utiliza os conhecimentos apresentados por outros pesquisadores, dessa forma a
52
equipe de inspeção não precisa adquirir esse conhecimento para aplicá-lo manualmente. ISPIS
pode ser utilizada para coordenar e apoiar a inspeção de qualquer tipo de artefato de software.
Ela permite reuniões síncronas ou assíncronas, sendo útil para equipes distribuídas
geograficamente. Na Tabela 8 são apresentadas as características das ferramentas.
Tabela 8 – Características das ferramentas analisadas.
Autores Apoio à equipe
distribuída
Sist. via web
Vídeo conf.
Config. fuso-
horário
Conf. idiomas
Modelo de
negócios
Técnica Modelo baseado
ICICLE Brothers et al (1990)
Não Não Não Não Não Não Própria Fagan
CSI Mashayekhi et al. (1993)
Não Sim Teleconferência
Não Não Não Ad-hoc Humphrey
Scrutiny Gintell et al. (1993)
Sim Não Não Não Não Não Ad-hoc Bull HB Information Systems,
AISA Stein et al. (1997)
Sim Sim Não Não Não Não Ad-hoc Humphrey
InspectA Murphy et al. (1997)
Não Não Não Não Não Não Checklist Fagan
ASSIST Macdonald e Miller (1998)
Sim Sim Não Não Não Não Ad-hoc Checklist
Macdonald
GRIP Grünbacher et al. (2003)
Sim Não Não Não Não Não Ad-hoc Próprio
IBIS Lanubile et al. (2003)
Sim Sim Não Não Não Não Ad-hoc Checklist
Sauer
ISPIS Kalinowski e Travassos
(2004)
Sim Sim Não Não Não Não Ad-hoc Outras através
da integraçã
o
Sauer
2.8. Considerações finais
Alguns conceitos que subsidiaram este trabalho foram apresentados neste capítulo, além
disso, apresentaram-se também algumas ferramentas encontradas na literatura que podem
auxiliar a inspeção de software, indicando ao leitor a possibilidade da utilização de algumas
dessas ferramentas com a estratégia proposta nesta pesquisa.
53
Abordagem proposta
Neste capítulo será apresentada a estratégia de apoio à inspeção de software em
desenvolvimento distribuído de software, assim como a abordagem proposta para execução da
inspeção utilizando-se da estratégia sugerida. Além disso, é sugerida neste capítulo a inclusão
da atividade de inspeção de software na abordagem integrada de desenvolvimento e teste para
equipes distribuídas proposta por Leal (2010).
3.1. Abordagem de inspeção
Rakitin (2001) afirma que a inspeção é um processo formal, rigoroso, uma revisão em
profundidade técnica, destinada a identificar os problemas o mais próximo possível do seu
ponto de origem.
A abordagem aqui apresentada foi elaborada tomando como base a reorganização
proposta por Sauer et al. (2000) e o processo de inspeção IEEE 1028-1997. Para sua
estruturação foram definidos etapas, papéis e artefatos.
Ela é composta pelas seguintes etapas: Gestão da preparação, Planejamento da
Inspeção, Apresentação, Detecção de Defeitos, Coleção de Defeitos, Discriminação de
Defeitos, Retrabalho e, por fim, a etapa Acompanhamento. São propostos os seguintes papéis:
Gestor, Gerente de Projeto Global, Gerente de Projeto Local, Moderador, Inspetor, Autor.
Na Figura 10 é ilustrada a abordagem proposta para inspeção, são apresentados os
papéis que estão relacionados a cada etapa da abordagem.
3 Capítulo
54
3.1.1. Descrição de cada etapa da abordagem proposta
A seguir há uma descrição de cada etapa da abordagem proposta neste trabalho:
i) Gestão da preparação: O gestor responsável garantirá que a inspeção será dotada
dos recursos necessários tais como pessoal, tempo, materiais e ferramentas, e será
conduzido de acordo com os padrões definidos pela organização. Além disso, será
definida nesta etapa, qual a localização geográfica (onshore, offshore) e qual o tipo
de relacionamento entre as empresas (insourcing, outsourcing), que remeterá no
modelo de negócio a ser considerado na inspeção. Essa decisão é tomada pelo
Gestor com auxílio do Gerente de Projeto Global.
Figura 10 – Abordagem de inspeção proposta
Gestor Ger. de Projetos Global
Moderador Autor Ger. de Proj. Global Ger. de Proj. Local
Autor Moderador
Moderador Inspetor Ger. de Proj. Local
Moderador
Moderador Autor Inspetor Ger. de Proj. Local
Autor
Moderador
Planejamento da Inspeção
Apresentação
Detecção de Defeitos
Coleção de Defeitos
Discriminação de Defeitos
Retrabalho
Acompanhamento
Gestão da Preparação
55
ii) Planejamento da Inspeção: O Moderador da inspeção define o contexto da
inspeção (descrição da inspeção, técnica a ser utilizada na detecção de defeitos)
seleciona os Inspetores, com base nas sugestões dos Gerentes de Projeto Locais, e
distribui o material a ser inspecionado. Os materiais são entregues pelo Autor para
o Moderador que define um prazo para que sejam finalizadas as listas de
discrepâncias, bem como quando será encaminhada a lista de defeitos ao Autor;
iii) Apresentação: O Autor deve apresentar as características do artefato de software a
ser inspecionado. Esta etapa pode ser omitida, caso os Inspetores já tenham
conhecimento sobre o artefato que deve ser inspecionado. Nesta etapa o
Moderador deve fazer um breve comentário, responder às perguntas sobre os
checklists ou questionário, apresentar dados da inspeção, como tempo mínimo para
detecção de defeitos e caso haja dados, apresentar a quantidade de anomalias
encontradas no passado em artefatos similares;
iv) Detecção de Defeitos: os Inspetores, individualmente, analisam o artefato tendo
por base o checklist ou questionário fornecido pelo Moderador, as anomalias
identificadas devem ser classificadas e registradas na lista de discrepâncias que
será repassada ao Moderador, caso seja necessário, os Gerentes de Projeto Locais
podem ser acionados para cobrar as atividades dos Inspetores;
v) Coleção de Defeitos: Nesta etapa o Moderador deve agrupar as listas de
discrepâncias dos Inspetores, podendo selecioná-las ou descartá-las. As repetidas
são marcadas e encaminhadas diretamente para a etapa de retrabalho,
economizando assim tempo da inspeção;
vi) Discriminação de Defeitos: nesta etapa, o Moderador, o Autor do artefato e os
Inspetores discutem as discrepâncias de forma assíncrona. As discrepâncias são
tratadas como tópicos de discussões e cada participante pode acrescentar seu
comentário sobre cada uma delas. Enquanto o Moderador e Autor não decidirem
se a discrepância realmente representa um defeito ou um falso positivo os tópicos
ficam ativos. Os falsos positivos identificados serão descartados e os defeitos serão
registrados em uma lista de defeitos, que então será enviada para o Autor para que
proceda a correção. Não é intuito desta etapa encontrar solução para discrepâncias
56
identificadas, isso não é foco de uma inspeção. Se forem identificados poucos
falsos positivos ou se os falsos positivos forem de fácil identificação pelo autor
não há a necessidade de se executar esta etapa, caso seja necessário, os Gerentes
de Projeto Locais podem ser acionados para cobrar as atividades dos participantes;
vii) Retrabalho: o Autor corrige os defeitos que foram identificados na etapa de
discriminação; e
viii) Acompanhamento: o Autor repassa o artefato ao Moderador, que realiza uma
análise do artefato e verifica se há necessidade de voltar à etapa de retrabalho ou se
deve ocorrer uma re-inspeção. Caso se agende uma re-inspeção para verificar o
retrabalho, deve-se analisar as áreas do artefato alterado para resolver as anomalias
identificadas na última inspeção, bem como seus efeitos colaterais.
3.1.2. Estratégia de apoio à inspeção de software em DDS
Utilizando-se da abordagem proposta, definiu-se uma estratégia para o modelo de negócio
Offshore Outsourcing. Na terceira coluna da tabela é apresentada a característica norteadora
referente à DDS em que a atividade poderá auxiliar na estratégia proposta. Por exemplo, a
característica norteadora sugerida para a atividade definir um idioma padrão é a característica
distância sociocultural, a qual afeta diretamente a comunicação.
Para a elaboração da estratégia foram consideradas as etapas apresentadas na Figura
10, definidas as atividades pertinentes a cada uma delas e indicada(s) qual(is) característica
afeta(m) ou seri(am) afetada(s). Essas características se referem às distâncias geográfica,
temporal e sociocultural, as quais afetam direta ou indiretamente a coordenação, comunicação
e controle. Os papéis envolvidos, atividades e características norteadoras são apresentadas da
tabela 9 à 16. Ainda são apresentados os principais artefatos gerados em cada uma das etapas.
57
a.1) Atividades da etapa Gestão da Preparação
Tabela 9 – Atividades da etapa Gestão da Preparação
Papéis Atividades Característica norteadora
Gestor
Garantir recursos financeiros e instalações necessárias para planejar, definir, executar e gerenciar a inspeção.
Distância geográfica Coordenação
Assegurar que as inspeções planejadas sejam realizadas, via notificação do andamento e finalização pelo Gerente de Projeto Global.
Distância geográfica Coordenação
Definir, em conjunto com o Gerente de Projeto Global, o modelo de negócio que será adotado na inspeção do artefato.
Distância geográfica Coordenação
Gerente de Projeto Global
Identificar os Gerentes de Projeto Locais. Distância geográfica Controle
Assegurar que as inspeções planejadas sejam realizadas, via notificação do andamento e finalização pelo Gerente de Projeto Global.
Distância geográfica Coordenação
Assegurar que os membros da equipe de inspeção possuem experiência e conhecimento necessários para compreender o artefato de software sob inspeção.
Distância geográfica Controle
Participar juntamente com o Gestor na definição do modelo de negócio que será adotado na inspeção do artefato.
Distância geográfica Coordenação
Aplicar um questionário para verificar o grau de conhecimento referente às línguas conhecidas pelos integrantes e definir um idioma padrão de comunicação.
Diferença cultural Comunicação
Aplicar o modelo de Hofstede para verificar a dimensão das diferenças culturais. Definir um plano de treinamento da equipe nas diferentes culturas envolvidas.
Diferença cultural Comunicação/Coordenação
Definir uma infraestrutura para comunicação e colaboração.
Diferença cultural Comunicação
Permitir e estimular a comunicação informal entre os membros da inspeção.
Diferença cultural Comunicação
58
Definir quem desempenhará o papel de Moderador na inspeção, com base nas informações repassadas.
Distância geográfica Coordenação
Gerente de Projeto Local
Sugerir os membros que participarão da inspeção.
Distância geográfica Coordenação
Assegurar que os membros da equipe de inspeção possuem níveis apropriados de experiência e conhecimento suficiente para compreender o artefato de software sob inspeção, por meio de uma entrevista com cada um.
Distância geográfica Coordenação
Informar o horário de trabalho da equipe, assim como os feriados locais.
Diferença fuso-horário Coordenação
a.2) Artefato gerado na etapa Gestão da Preparação
1. Documento de gestão da preparação
Atividades são definidas para minimizar os impactos negativos das características do
DDS e acentuar os impactos positivos, dessa forma, busca-se uma estratégia que dê apoio à
inspeção de software no DDS.
A etapa Preparação da Gestão da Preparação teve por base a IEEE 1028, os papéis
envolvidos são: Gestor, Gerente de Projeto Global e Gerente de Projeto Local, vale salientar
que na IEEE 1028, apenas o Gestor é sugerido. Decidiu-se por ter mais os gerentes para poder
adequar ao contexto de dispersão oriundo do DDS. As atividades definidas na Tabela 9 têm
por objetivo, além de minimizar os impactos negativos, orientar o Gestor e Gerente de Projeto
Global para que se defina o modelo de negócio que será utilizado na operacionalização do
DDS em relação à inspeção.
Em relação à atividade que sugere a aplicação do modelo de Hofstede, vale salientar
que para verificar a importância da cultura nacional na forma de administrar, Hofstede (2001)
fez um estudo sobre diferenças culturais existentes em vários países. O autor constatou a
influência da cultura nacional para explicar os valores e atitudes em reação ao trabalho. Ele
desenvolveu um modelo com cinco dimensões para identificar os padrões culturais. Essas
dimensões são as seguintes:
59
i. Distância de Poder – significa até que ponto os membros de uma sociedade
aceitam a distribuição desigual de poder, afetando o comportamento dos menos
poderosos em relação aos mais poderosos, ou seja, explica como se vê o poder
numa sociedade, e seu papel na tomada de decisões;
ii. Controle da incerteza – Analisa a extensão da ansiedade que as pessoas sentem
ao encarar situações inesperadas ou incertas. É o grau de desconforto que os
membros de uma sociedade sentem com a incerteza e a ambigüidade; preferência
por situações mais ou menos estruturadas;
iii. Individualismo e Coletivismo – dá uma idéia da discussão na qual as pessoas
aceitam a interferência do grupo na determinação de suas vidas. Os indivíduos
pertencem a uma ou mais comunidades das quais não podem se destacar. O grupo
protege o interesse dos seus membros e espera destes, sua lealdade constante.
Hofstede (2001) afirma que o individualismo caracteriza as sociedades nas quais
os laços entre os indivíduos são poucos firmes: cada um deve ocupar-se de si
mesmo e da sua família. O coletivismo, pelo contrário, caracteriza as sociedades
nas quais as pessoas são integradas, desde o nascimento, em grupos fortes e
coesos, que as protegem para toda a vida em troca de uma lealdade inquestionável.
O ponto básico é qual o grau de interdependência que a sociedade mantém entre
seus membros;
iv. Masculinidade e Feminilidade – expressa a preferência por sucesso material,
competitividade, agressividade, desempenho e, feminilidade a preferência por
qualidade de vida, relações humanas, dedicação, solidariedade; e
v. Orientação a longo prazo versus a curto prazo – corresponde aos valores
positivos de austeridade e tenacidade e aos valores negativos de respeito pelas
tradições e conformismo social – o medo do que “os outros dirão”. (este indicador
foi incorporado, posteriormente, à pesquisa original de Hofstede, por Bond, da
Universidade Chinesa de Hong Kong).
60
b.1) Atividades da etapa Planejamento da Inspeção
Tabela 10 – Atividades da etapa Planejamento da Inspeção
Papéis Atividades Característica norteadora
Moderador
Garantir que o artefato esteja pronto para inspeção, solicitando a confirmação do Autor
Distância geográfica Controle
Verificar a sobreposição dos horários dentre os membros dispersos.
Diferença fuso-horário Coordenação
Definir os meios de comunicação entre os membros dispersos na inspeção.
Distância geográfica Comunicação
Selecionar os membros da equipe, levando em consideração as sugestões dos Gerentes de Projeto Locais.
Diferença cultural Coordenação
Selecionar as ferramentas de apoio à inspeção e treinar os membros da equipe de inspeção para utilizar as ferramentas selecionadas.
Distância geográfica Comunicação
Sugerir a utilização de mecanismos/ferramentas que possibilitem aos integrantes da inspeção uma comunicação informal.
Diferença cultural Comunicação
Comunicar a todos qual é a responsabilidade de cada um referente à inspeção.
Diferença cultural Coordenação
Definir a técnica de inspeção a ser adotada pela equipe de inspeção.
Distância geográfica Coordenação
Disponibilizar os documentos que serviram de fonte de informação para criação do artefato.
Distância geográfica Coordenação/Comunicação
Decidir se há necessidade de passar pela etapa Apresentação e qual será o tempo para a mesma.
Distância geográfica Coordenação
Consultar e informar os Gerente de Projetos Global e Gerentes de Projetos Locais
Distância geográfica Coordenação/Controle
Autor Disponibilizar o artefato concluído para que seja inspecionado.
Distância geográfica Coordenação
b.2) Artefatos gerados na etapa Planejamento da inspeção
61
1. Plano da inspeção, constando: a. Nomes dos membros da inspeção, assim como a responsabilidade de cada um. b. As sobreposições dos horários. c. Definição dos meios de comunicação entre membros dispersos na inspeção d. Nomes das ferramentas de apoio selecionadas para inspeção e. Técnica a ser utilizada na inspeção f. O artefato objeto da inspeção
2. Plano de treinamento referente às ferramentas de apoio selecionadas para inspeção, se necessário.
A etapa Planejamento da Inspeção teve por base o processo tradicional de Fagan
(1976), além das atividades comuns nos processos de inspeção, por exemplo, definir a
garantir que o artefato esteja pronto para inspeção e definir a técnica de inspeção a ser
adotada, outras atividades foram incluídas, por exemplo, o Moderador deve verificar os
horários de sobreposição para, se necessário, poder agendar uma possível comunicação
síncrona com a equipe, a característica norteadora dessa atividade é a dispersão temporal que
impacta na coordenação.
c.1) Atividades da etapa Apresentação.
Tabela 11 – Atividades da etapa Apresentação
Papéis Atividades Característica norteadora
Autor
Elaborar apresentação do artefato. Essa apresentação será de forma assíncrona para membros que estejam dispersos. Responder aos questionamentos dos membros.
Diferença fuso-horário Coordenação
Moderador Acompanhar a apresentação do Autor. Fazer uma descrição da inspeção e, se necessário, responder aos questionamentos.
Distância geográfica Coordenação
Inspetor Acompanhar a apresentação do Autor e elaborar questionamentos, se necessário.
Distância geográfica Comunicação
c.2) Artefato gerado na etapa Apresentação
1. Documento constando os questionamentos dos membros da inspeção, referente às suas dúvidas, se houver questionamentos.
A etapa Apresentação, opcional, também teve por base o processo tradicional de Fagan
(1976), para minimizar o impacto da dispersão temporal na coordenação a apresentação do
Autor pode ser realizada de forma assíncrona.
62
d.1) Atividades da etapa Detecção de Defeitos
Tabela 12 – Atividades da etapa Detecção de Defeitos
Papéis Atividades Característica norteadora
Inspetor
Realizar atividade de detecção de defeitos. Distância geográfica Coordenação
Utilizar a técnica definida pelo Moderador. Distância geográfica Coordenação
Utilizar os documentos fontes disponibilizados pelo Moderador, para assegurar a conformidade.
Distância geográfica Coordenação/Comunicação
Moderador
Se houver necessidade, solicitar auxílio do Gerente de Projeto Local para que as atividades da inspeção sejam cumpridas conforme definido no documento de planejamento.
Distância geográfica Coordenação
Gerente de Projeto Local
Se solicitado, auxiliar o Moderador para que todas as atividades da inspeção sejam cumpridas.
Distância geográfica Coordenação
d.2) Artefato gerado na etapa Detecção de Defeitos
1. Lista(s) de discrepância(s)
As etapas Detecção de Defeitos, Coleção de Defeitos e Discriminação de Defeitos,
tiveram por base a reorganização proposta por Sauer et al. (2000). Devido à dispersão
geográfica foi adicionado o Gerente de Projeto Local na Detecção e Discriminação,
auxiliando assim o Moderador, dessa forma, pretende-se diminuir o impacto na coordenação. e.1) Atividades da etapa Coleção de Defeitos
Tabela 13 – Atividades da etapa Coleção de Defeitos
Papéis Atividades Característica norteadora
Moderador Agrupar as listas de discrepâncias dos inspetores.
Distância geográfica Controle
e.2) Artefatos gerados na Etapa Coleção de Defeitos
1. Lista de discrepância(s)
63
2. Lista de Defeitos (Lista de discrepâncias repetidas) f.1) Atividades da etapa Discriminação de Defeitos
Tabela 14 – Atividades da etapa Discriminação de Defeitos
Papéis Atividades Característica norteadora
Moderador
Discutir as discrepâncias de forma assíncrona em conjunto com o Autor e Inspetor.
Diferença fuso-horário Coordenação
Se houver necessidade, solicitar auxílio do Gerente de Projeto Local para que as atividades da inspeção sejam cumpridas conforme definido no planejamento.
Distância geográfica Coordenação
Autor Discutir as discrepâncias de forma assíncrona em conjunto com o Moderador e Inspetor.
Diferença fuso-horário Coordenação
Inspetor Se convocado, discutir as discrepâncias de forma assíncrona em conjunto com o Moderador e Autor.
Diferença fuso-horário Coordenação
Gerente de Projeto Local
Se solicitado, auxiliar o Moderador para que todas as atividades da inspeção sejam cumpridas.
Diferença fuso-horário Coordenação
f.2) Artefatos gerados na etapa Discriminação de Defeitos:
1. Lista de defeito(s) 2. Se necessário, Lista de falso(s) positivo(s)
g.1) Atividades da etapa Retrabalho
Tabela 15 – Atividades da etapa Retrabalho
Papéis Atividades Característica norteadora
Autor Proceder a correção dos defeitos identificados na lista de defeitos. Após a correção de todos os defeitos, enviar o artefato ao Moderador.
Distância geográfica Controle
g.2) Artefato gerado na etapa Retrabalho:
1. Artefato corrigido
64
h.1) Atividades da etapa Acompanhamento
Tabela 16 – Atividades da etapa Acompanhamento
Papéis Atividades Característica norteadora
Moderador
Se todos os defeitos foram corrigidos, faz o relatório de acompanhamento. Se os defeitos não foram corrigidos submete o artefato para etapa Retrabalho.
Distância geográfica Coordenação/Controle
Se achar necessário, pode incluir inspetor(es) na etapa Acompanhamento.
Distância geográfica Coordenação
Se a correção dos defeitos for de grandes proporções no artefato, o Moderador pode submeter o artefato para uma re-inspeção.
Distância geográfica Coordenação
Se houver necessidade, solicitar auxílio do Gerente de Projeto Local para que as atividades da inspeção sejam cumpridas conforme definido no documento de planejamento.
Distância geográfica Coordenação
Autor Participar do acompanhamento caso seja solicitado pelo Moderador.
Distância geográfica Comunicação
Gerente de Projeto Local
Se solicitado, auxiliar o Moderador para que todas as atividades da inspeção sejam cumpridas.
Distância geográfica Coordenação
Gerente de Projeto Global
Finalizar a inspeção e dar continuidade ao ciclo de desenvolvimento do software.
Distância geográfica Coordenação/Controle
h.2) Artefato gerado na etapa Acompanhamento:
1. Documento Final contendo: a. Membros da equipe de inspeção b. Duração da inspeção c. Artefato inspecionado d. Tamanho do artefato inspecionado (por exemplo, números de páginas) e. Checklists e se eles foram cumpridos f. Resumo dos defeitos com indicação do número de defeitos identificados por
cada categoria g. Uma estimativa do esforço do retrabalho e data de conclusão do retrabalho h. Tempo total para detecção de defeitos
2. Relatório para gerência
65
a. Notificar que a inspeção já pode ser fechada pelo Gerente de Projeto Global, enviando o Documento final
b. Apresentar os pontos positivos da inspeção c. Apresentar as dificuldades encontradas d. Sugestões de melhorias
As etapas de Retrabalho e Acompanhamento, tiveram por base o processo de Fagan
(1976), na etapa, Acompanhamento, foram incluídos o Gerente de Projeto Global e Local. O
Gerente de Projeto Local auxilia o Moderador, caso seja necessário, cobrando atividades do
inspetor que esteja em sua localidade. O Gerente de Projeto Global finaliza a inspeção após
receber o relatório destinado à gerência.
3.2. Abordagem de Desenvolvimento e Teste de Software para Equipes Distribuídas
Leal (2010) propõe a abordagem integrada de desenvolvimento e teste de software para
equipes distribuídas, nela a autora enfatiza a importância da integração entre os processos de
desenvolvimento e teste, por trazerem vários benefícios, tais como: reduzir o custo de
desenvolvimento, alcançar um alto nível de automação no desenvolvimento de casos de
testes, facilitar a realização de alterações nos requisitos e redução nos custos de manutenção.
Na Figura 11 é ilustrada a abordagem proposta pela autora.
Figura 11 – Abordagem integrada de desenvolvimento e teste. Fonte: Leal (2010)
66
Conforme Ackerman et al. (1989) a inspeção faz parte do processo de
desenvolvimento de software, sendo aplicada na transição de uma fase para outra, conforme
apresentado na Figura 12.
Figura 12 – Inspeção de software no proc. de desenvolvimento. Fonte: Ackerman et al. (1989)
Vale salientar que todos os artefatos gerados em um processo de desenvolvimento são
passíveis de serem inspecionados. Verificou-se na literatura que é prudente inspecionar os
artefatos gerados logo no início do processo de desenvolvimento. Constatou-se que seria
interessante incluir a inspeção na abordagem proposta por Leal (2010).
O conjunto de elementos que compõem a abordagem de desenvolvimento proposta por
Leal (2010) é ilustrada na Figura 13. Embora a inspeção possa ser aplicada em todas as
disciplinas, dar-se-á atenção às disciplinas de Planejamento e Requisitos, na primeira será
produzido o plano de desenvolvimento global e na segunda será aplicada a inspeção na
descrição textual do software e descrição extendida do caso de uso.
Figura 13 – Diagrama de pacotes da abordagem de desenvolvimento. Fonte: Leal (2010)
67
Na Tabela 17 são apresentados os papéis envolvidos na abordagem, assim como sua
descrição. Tabela 17 – Papéis envolvidos na abordagem. Adaptado de Leal(2010).
Papéis da abordagem Descrição
Gestor
Responsável para auxiliar na configuração do desenvolvimento, especificamente no que se refere ao modelo de negócio adotado.
Gerente de Projeto
Global
Responsável pelas atividades relativas ao planejamento estratégico do projeto.
Gerente de Projeto Local
Gerencia as unidades distribuídas, distribuindo e coordenando as atividades
Engenheiro de
Negócios
Lidera e coordena a modelagem de casos de uso empresarial, delimita os processos de negócios que estão envolvidos. Conduz e coordena a obtenção de requisitos.
Especificador
Detalha a especificação dos requisitos de sistema.
Arquiteto
Lidera e coordena as atividades do projeto. Estabelece a estrutura geral de cada visão da arquitetura.
Projetista
Detalha a especificação, descrevendo o fluxo de trabalho e estrutura.
Desenvolvedor
Desenvolve a programação e realiza os testes de unidade de acordo com os padrões técnicos e tecnológicos adotados para o projeto.
Cliente
Pessoa ou entidade que solicita o desenvolvimento do software.
Moderador
Responsável por planejar a inspeção e liderar a equipe de inspeção.
Inspetor
Responsável por inspecionar o artefato sob inspeção, utilizando-se da técnica definida no plano da inspeção.
68
Autor
Responsável pelo artefato sob inspeção.
Para que se possa ter inspeção na abordagem de Leal (2010) foram incluídos os
seguintes papéis: Gestor, Moderador, Inspetor e Autor. Conforme a autora os papéis
identificados na Tabela 17 podem participar de duas maneiras distintas:
i) < < perform > >: representa que um papel executa efetivamente uma atividade; e
ii) < < assist > >: representa que um papel auxilia outro no desempenho de suas
atividades.
3.2.1. Disciplina Planejamento
Conforme Leal (2010) a disciplina planejamento é responsável pela configuração do processo
de desenvolvimentos e dos aspectos relacionados ao gerenciamento do projeto. Foi incluído o
papel do Gestor nessa disciplina para que este possa auxiliar na definição do modelo de
negócio que será adotado na empresa e também respeitada a abordagem de inspeção proposta
neste trabalho.
69
Na Figura 14 é ilustrada a definição do trabalho com a inclusão do Gestor, que
participará na definição da configuração do desenvolvimento, ou seja, no modelo de negócio
adotado para o desenvolvimento.
O diagrama de casos de uso é apresentado na Figura 15. O Gestor auxilia o Gerente de
Projeto Global na definição da configuração do desenvolvimento de acordo com o modelo de
negócio, assim como o Gerente de Projeto Local auxilia o Gerente de Projeto Global em
várias atividades.
Figura 14 – Diagrama de pacotes da definição de trabalho – Configurar o processo. Adaptado de Leal (2010)
70
Figura 15 – Diagrama de casos de uso da definição de trabalho – Configurar o processo. Adaptado
de Leal (2010)
Verifica-se na Figura 16 o Diagrama de Classes, os relacionamento dos papéis e
artefatos gerados. O Plano de Desenvolvimento Global é definido a partir das informações
sobre recursos que são fornecidas pelos Gestor e Gerente de Projeto Global. A partir dessas
informações e do Plano de Desenvolvimento Global é elaborado o Plano de Desenvolvimento
Local.
71
Figura 16 – Diagrama de Classes. Adaptado de Leal (2010)
No diagrama de atividades ilustrado na Figura 17 pode-se verificar a
precedência das atividades, assim como aqueles que podem ser executadas em paralelo. (Leal,
2010)
Figura 17 – Diagrama de atividades. Adaptado de Leal (2010)
72
3.2.2. Disciplina Requisitos
Conforme Leal (2010) a disciplina requisitos tem por objetivo descrever como definir uma
visão do sistema e traduzí-la em modelos. Suas metas são: estabelecer e manter contato com
os stakeholders em relação ao que o sistema deve fazer; facilitar o entendimento do
desenvolvedor sobre os requisitos por meio dos modelos gerados e, por fim, delimitar o
escopo do sistema. Na Figura 18 são ilustradas as definições de trabalho que compõem a
disciplina requisitos. O trabalho Aplicar Inspeção foi incluído na abordagem de Leal (2010) e,
dessa forma, aplicar a inspeção aos artefatos gerados nessa disciplina.
Figura 18 – Diagrama de Pacotes da Disciplina Requisitos. Adaptado de Leal (2010)
São geradas pela abordagem de Leal (2010) a descrição textual e a descrição extendida
de casos de uso, conforme ilustrado na Figura 19.
Figura 19 – Diagrama de Pacotes das Definições de Trabalho. (Leal, 2010)
Assim que algum dos artefatos for gerado, o trabalho Aplicar Inspeção é iniciado. Na
73
Figura 20 é ilustrado o pacote de trabalho da definição de trabalho Aplicar Inspeção.
Figura 20 – Pacote de trabalho da definição de trabalho Aplicar Inspeção
Verifica-se na Figura 21 o Diagrama de Classes, os relacionamento dos papéis e os
artefatos gerados. O Plano de Inspeção é gerado tendo por base as informações sobre os
74
recursos e o Plano de Desenvolvimento Global, a técnica de inspeção é definida levando em
consideração o artefato a ser inspecionado. O Inspetor gera a lista de discrepâncias.
Figura 21 – Diagrama de Classes – Aplicar Inspeção
O diagrama de casos de usos é apresentado na Figura 22. Percebe-se na Figura 22que
o moderador executa várias atividades desde definir a descrição da inspeção até decidir se
haverá reinspeção no artefato que foi inspecionado. O Inspetor executa as atividade
inspecionar o artefato e gerar lista de discrepância, assim como auxilia, se solicitado, na
discussão das discrepâncias identificadas, definindo se elas são falsos positivos ou defeitos
verdadeiro. O Autor disponibiliza o artefato no início da inspeção e o corrige na etapa
Retrabalho, ele também auxília o Moderador na discussão das discrepâncias identificadas. Na
Figura 23 é apresentado o fluxo de trabalho em relação à aplicação da inspeção.
75
Figura 22 – Diagrama de Casos de uso – Aplicar Inspeção
No diagrama de atividade ilustrado na Figura 23 tem-se o Autor, Moderador e
Inspertor, os quais aplicarão a inspeção no artefato.
76
Figura 23 – Diagrama de atividades – Aplicar Inspeção
3.3. Considerações Finais
Neste capítulo foram apresentados as etapas, papéis e artefatos da abordagem de inspeção de
software proposta neste trabalho, assim como a estratégia de apoio à inspeção de software em
DDS com suas atividades, indicando quais características do DDS poderia ser impactadas
com a atividade. Neste capítulo apresentou ainda uma sugestão de integração da abordagem
de inspeção com a abordagem proposta por Leal (2010).
77
Exemplo de aplicação da abordagem
Neste capítulo é apresentado um exemplo de aplicação da abordagem de inspeção e da
estratégia de apóio a inspeção em DDS propostas neste trabalho. Para tanto, foram
convidados para participar deste estudo, tanto profissionais, quanto acadêmicos da área de
Tecnologia da Informação, os quais se encontram dispersos geográfica e temporalmente.
Também será apresentada a aplicação da inspeção na abordagem proposta por Leal (2010).
4.1. Aplicação da Abordagem de Inspeção
A abordagem de inspeção proposta neste trabalho foi aplicada em uma empresa de
desenvolvimento de software da região norte pioneiro do Paraná e, por motivos de segurança,
a empresa solicitou que sua razão social não fosse apresentada neste trabalho. Os participantes
envolvidos nesta aplicação estão dispersos geográfica e temporalmente. Eles estão dispersos
da seguinte forma:
Gestor da empresa localiza-se em Bandeirantes – Paraná – Brasil;
Gerente de projeto global e Moderador localizam-se em Santa Mariana –
Paraná – Brasil;
Autor do artefato, analista de sistemas da empresa, está localizado em
Bandeirantes – Paraná – Brasil;
Cliente da empresa localiza-se em Londrina – Paraná – Brasil;
Inspetores nos seguinte locais:
4 Capítulo
78
o Bandeirantes – Paraná – Brasil;
o Assis – São Paulo – Brasil;
o Curitiba – Paraná – Brasil;
o Dublin – Leinster – Irlanda; e
o San Francisco – Califórnia – Estados Unidos da América.
Para o desenvolvimento deste estudo foram encaminhados aos participantes uma
apresentação geral do estudo, assim como os conceitos de inspeção, desenvolvimento
distribuído de software e um exemplo de um documento de requisitos de software.
Foi solicitado que os participantes preenchessem um Formulário com seus dados
pessoais, sua experiência com DDS, com inspeção de software, com elaboração de DRS, além
de algumas questões a respeito do estudo e das ocorrências deste estudo.
Figura 24 – Delimitação do estudo
Delimitação do estudo
Planejamento da Inspeção
Apresentação
Detecção de Defeitos
Coleção de Defeitos
Discriminação de Defeitos
Retrabalho
Acompanhamento
Gestão da Preparação
79
Conforme ilustrado na Figura 24, tem-se a delimitação da aplicação da abordagem
proposta neste trabalho. A aplicação iniciou na primeira etapa, Gestão da Preparação, e
finalizou na sexta etapa, Discriminação.
A sétima e oitava etapas Retrabalho e Acompanhamento, respectivamente, não foram
executadas, pois o Analista de Sistemas da empresa (Autor do artefato) informou que a
empresa não tem interesse em proceder as correções, pois o sistema já se encontra finalizado.
4.1.1. Etapa Gestão da Preparação
Nesta etapa da abordagem estão envolvidos o Gestor e o Gerente de Projeto Global (GPG).
Utilizando-se da estratégia proposta neste trabalho, conforme descrita na seção 3.1.2, eles
definiram o modelo de negócio como sendo Offshore outsourcing, uma vez que a distância
geográfica envolve outros países o relacionamento entre as equipes é de outsourcing, pois os
demais participantes estão prestando um serviço à empresa. Vale salientar que não há custos
envolvidos nessa execução, pois todos aceitaram participar do estudo. Apenas o Gestor e
Autor do artefato são funcionários da empresa. Conforme Faria (2008) deve existir entre os
envolvidos no outsourcing, empresa contratante e contratada, um acordo de nível de serviço
(ANS) definindo os níveis de qualidade e desempenho para os serviços que serão prestados,
assim como as penalidades ou conseqüências quando o acordo não for cumprido. Para o
presente exemplo não foi estabelecido um ANS, uma vez que os participantes se
prontificaram em participar do estudo sem ônus para ambas as partes.
Os participantes selecionados para aplicação deste exemplo já se conheciam
anteriormente, tendo assim um nível de confiança já estabelecido entre eles, pois conforme
afirma Mansur (2009) para se obter as vantagens do outsourcing, é necessário escolher
parceiros de confiança.
Definiu-se Português Brasileiro como idioma padrão de comunicação. Não foi
necessário aplicar o modelo de Hofstede (2001) para identificar as diferenças socioculturais,
pois os participantes que se encontram em outros países são brasileiros. Dessa forma, não
houve a necessidade de definir um plano de treinamento das equipes nas diferentes culturas.
O Gestor e GPG decidiram por utilizar os recursos do Google, por exemplo, gmail,
gtalk e docs e, também, utilizar o Skype, como infraestrutura para comunicação e colaboração.
Aqueles que não tinham conta no Google e no Skype tiveram que criá-las. Para estimular a
comunicação informal entre os membros, o Gestor determinou que todos que participarem da
80
inspeção encaminhassem e-mail com seus dados devendo constar o endereço de uma rede
social, foi sugerido o Facebook como alternativa.
Na estratégia proposta neste trabalho, há atividades que são de competência do
Gerente de Projetos Local (GPL), entretanto esse papel foi acumulado pelos Inspetores, pois
as equipes que estão dispersas são constituídas por apenas um integrante. Esses Inspetores
informaram os horários de trabalho e os feriados de suas localidades. Com essas informações
o GPG e o Moderador puderam agendar reuniões assíncronas e síncronas.
Após a execução dessas atividades foi gerado o plano de definição do modelo de
negócio relacionado à inspeção (Apêndice A).
4.1.2. Etapa Planejamento da Inspeção
Os papéis que participam dessa etapa são: Moderador, Autor, Gerente de Projeto Global e
Gerente de Projetos Locais, como informado anteriormente, não teremos a participação de um
GPL, pois as equipes dispersas são compostas apenas por um integrante. Assim que o
Moderador finalizou o planejamento, ele informou o GPG.
O Autor disponibilizou o artefato, Documento de Requisitos de Software (DRS), já
finalizado, o qual foi o foco dessa inspeção. O DRS em questão é parte de um maior e a
empresa aceitou em participar desde que não entregasse o DRS de todo o sistema.
Em reunião realizada pelo Moderador e Autor o DRS foi disponibilizado em mídia
digital, o Moderador atestou que o artefato estava pronto para ser inspecionado. Com as
informações repassadas pelos Inspetores ao GPG e disponibilizadas para o Moderador pelo
GPG, o Moderador verificou a sobreposição dos horários em relação aos Inspetores dispersos
que participaram da inspeção, na Figura 25 é ilustrada a sobreposição dos horários.
81
Figura 25 – Sobreposição de horários. Fonte: 24TimeZones.com
Foi definida a técnica de leitura checklist para ser utilizada nesta inspeção, pois
segundo Laitenberger (2000) é uma das técnicas mais empregadas para a detecção de defeitos
no contexto de inspeção de software. Anda et al. (2002) enfatizam que essa é técnica mais
utilizada na indústria, devido à sua fácil aplicabilidade.
O Moderador adicionou o número de linhas ao DRS, após isso, além de disponibilizá-
lo aos Inspetores, disponibilizou também no docs do Google o Formulário contendo o
checklist, o Formulário Lista de Discrepâncias, o Formulário Lista de Erros de Digitação,
Formulário Classificação de Defeitos, encaminhou, via email para todos os Inspetores. Ele
agendou reunião síncrona para o dia 28/07/11 às 13 horas no horário oficial de Brasília, às 09
horas no horário oficial de San Francisco e às 17 horas no horário oficial de Dublin conforme
ilustrado na Figura 25. O Skype foi utilizado para esta atividade.
O Moderador informou o prazo para entrega das listas de discrepâncias pelos
Inspetores, sendo definido 29/07/2011. Com os dados obtidos na etapa Gestão da Preparação
em conjunto com as definições do Moderador, ele finalizou o planejamento da inspeção.
4.1.3. Etapa Apresentação
A etapa Apresentação, que é opcional, ocorreu, pois o Moderador julgou necessário tecer
algumas considerações, além de o Autor fazer apresentação do DRS aos Inspetores. Na hora
82
agendada pelo Moderador para a reunião todos estavam online. Na Figura 26 é apresentado o
horário agendado para reunião.
Figura 26 – Horário definido para reunião. Fonte: 24TimeZones.com
O Moderador iniciou a reunião síncrona argumentou que o Autor criou o DRS e ele,
Autor, solicitou que o ajudassem a deixá-lo melhor. O Moderador enfatizou para todos
focarem seus comentários na melhoria do produto, pois o que deve ser analisado é o artefato
de software e não o responsável pela sua criação. Enfatizou ainda que o objetivo da inspeção
seja detectar defeitos e não soluções. Aqueles que encontrarem defeitos de digitação devem
incluir isso na lista de erros de digitação e não colocar isso como discrepância, pois as
discrepâncias serão discutidas/analisadas posteriormente. Verificou se todos tinham
familiaridade com as ferramentas utilizadas, o que foi confirmado por todos. Solicitou que
todos cronometrassem seus esforços para detectar os defeitos e definiu 30 minutos como
tempo para detecção.
O Autor teceu um breve comentário referente ao DRS e perguntou se alguém tinha
alguma dúvida. A reunião durou 30 minutos.
4.1.4. Etapa Detecção de Defeitos
Nesta etapa os Inspetores individualmente inspecionaram o DRS tendo por base o checklist
disponibilizado pelo Moderador. As discrepâncias encontradas foram anotadas no formulário
de discrepâncias (Anexo A).
Para classificação dos defeitos os Inspetores utilizaram aquela definida por Shull et al.
(2000), conforme ilustrada na Tabela 18.
83
Tabela 18 – Classificação de defeitos utilizada no estudo
Classificação do Defeito Característica
Omissão Qualquer requisito significante relacionado a funcionalidade, desempenho, restrições de projeto, atributos, ou interface externa que tenha sido omitido do documento de requisitos.
Informação ambígua Informação do documento de requisitos que pode ser interpretada de várias maneiras
Informação inconsistente Dois ou mais requisitos que se contradizem.
Fato incorreto Algum fato declarado no documento que não pode ser verdade diante das condições especificadas pelo sistema.
Informação estranha Informação desnecessária ou não usada.
Defeitos diversos Outros defeitos, tais como incluir um requisito na seção errada do documento de requisitos.
Após a inspeção no DRS, os Inspetores encaminharam ao Moderador os formulários
devidamente preenchidos, com suas evidências de possíveis defeitos detectados no
Documento de Requisitos de Software e, também, a lista de erros de digitação. (Anexo A)
Figura 27 – Listas de Discrepâncias
84
Na Figura 27 tem-se o exemplo de duas listas de discrepâncias de dois Inspetores e na
Figura 28 é apresentada uma lista de erros de digitação.
Figura 28 – Lista de Erro de Digitação
4.1.5. Etapa Coleção de Defeitos
Nesta etapa o Moderador agrupou as listas de discrepâncias encaminhadas pelos Inspetores.
Separou as discrepâncias idênticas, ou seja, aquelas identificadas por mais de um Inspetor,
essas discrepâncias foram encaminhadas diretamente à etapa Retrabalho, assim como a lista
de erro de digitação.
Dessa forma, as demais discrepâncias foram agrupadas em apenas uma lista que foi
encaminhada à etapa Discriminação para que se discutisse se a discrepância era realmente um
defeito ou falso positivo.
Geraram-se nesta etapa: a lista de discrepâncias repetidas (lista de defeitos) e lista de
erros de digitação que foram encaminhadas à etapa Retrabalho, e a lista de discrepâncias foi
encaminhada à etapa Discriminação. Na Figura 29 é ilustrada a lista de defeitos gerada nesta
etapa.
85
Figura 29 – Lista de Defeitos
4.1.6. Etapa Discriminação de Defeitos
O Moderador disponibilizou como tópico de discussão as discrepâncias que suscitaram
dúvidas se era um defeito ou um falso positivo. Para tanto, utilizou-se Google docs e o
documento foi compartilhado com o Autor e um Inspetor com maior experiência.
O Moderador informou o prazo para a discussão e o Autor e o Inspetor fizeram suas
considerações.
Apesar de o Inspetor e o Autor estarem distantes geográfica e temporalmente a
comunicação ocorreu sem maiores problemas, pois cada fez sua consideração, podendo o
outro visualizá-las. Caso houvesse a necessidade de uma comunicação síncrona o Moderador
já havia informado um horário comum para que eles pudessem discutir alguma discrepância
ou falso positivo.
Ao término do prazo, o Moderador confeccionou uma lista de defeitos que foi
encaminhada ao Autor do documento para as devidas correções. É ilustrada na Figura 30 parte
da lista de defeitos.
86
Figura 30 – Lista de Defeitos
A quantidade de defeitos, incluindo os que já haviam sidos enviados ao Autor sem
terem passados por esta etapa, observados pelos Inspetores é ilustrada na Tabela 19.
Tabela 19 – Quantidade de defeitos detectados
Classificação do defeito Qtd de defeitos observados pelos Inspetores
Qtd de defeitos observados
A B C D E F Omissão 0 8 1 6 1 3 19 Informação ambígua 4 2 1 1 1 0 9 Informação inconsistente 1 1 1 1 0 0 4 Fato incorreto 2 2 0 1 0 1 6 Informação estranha 2 1 0 0 1 0 4 Defeitos diversos 0 0 0 0 0 0 0
4.1.7. Etapas Retrabalho e Acompanhamento
Conforme definido na delimitação do estudo, as etapas Retrabalho e Acompanhamento não
foram executadas. No entanto, a lista de defeitos gerada foi repassada ao Autor do DRS que
87
comentou que apresentaria aos seus superiores, assim como iria sugerir que a empresa
adotasse a inspeção no seu processo de desenvolvimento.
4.1.8. Dados do estudo
Abaixo segue os gráficos contendo as informações referentes aos participantes do estudo. No
Gráfico 1 é ilustrado o nível de formação dos participantes, sendo que 3 têm formação
superior completa, 2 cursam o mestrado e os outros 2 cursam doutorado.
Gráfico 1 – Nível de Formação dos Participantes
No Gráfico 2 é apresentado o tempo de atuação dos participantes em relação à área de
Sistemas de Informação, 5 dos participantes têm mais de 36 meses de atuação na área.
88
Gráfico 2 – Tempo de atuação na área de SI
Em relação a experiência em desenvolvimento de software, a maior parte dos
participantes têm experiência em desenvolvimento de software em empresas, conforme
Gráfico 3.
Gráfico 3 – Experiência em desenvolvimento de software
Verifica-se no Gráfico 4 que a experiência em inspeção de software da maioria dos
participantes se limita à sala de aula.
89
Gráfico 4 – Experiência em inspeção de software
Observa-se no Gráfico 5 que 4 participantes têm experiência em desenvolvimento
distribuído de software apenas em sala de aula, enquanto apenas 1 tem experiência em
empresas e 2 participante não tem experiência.
Gráfico 5 – Experiência em DDS
No Gráfico 6 são apresentadas as respostas dadas pelos participantes em relação ao
estudo realizado. As questões aplicadas foram as seguintes:
1 - Em que grau o seu conhecimento sobre inspeção foi suficiente para a utilização da
Técnica de Leitura?
90
2 - Em que grau você utilizaria a Inspeção em um projeto de desenvolvimento
distribuído de software no seu ambiente de trabalho?
3 - Em que grau a abordagem apresentada atende as necessidades do desenvolvimento
distribuído?
4 - Em que grau os artefatos apresentados atendem as necessidades do
desenvolvimento distribuído?
5 - Em que grau o uso da abordagem pode amenizar os problemas de comunicação?
6 - Em que grau o uso da abordagem pode amenizar os problemas de coordenação?
7 - Em que grau o uso da abordagem pode amenizar os problemas de controle?
Para cada questão o participante poderia escolher entre as seguintes respostas:
nenhum, baixo, intermediário, satisfatório. Essas respostas são em relação ao grau que cada
pergunta satisfaz no estudo realizado.
No Gráfico 6 é apresentada a quantidade de resposta dos participantes para cada
questão.
Gráfico 6 – Questões de estudo
91
Observa-se que em relação à questão 3 (Em que grau as abordagem apresentada
atende as necessidades do desenvolvimento distribuído?) 3 participantes responderam que a
abordagem atende de forma intermediária as necessidades do DDS, para outros 3 participantes
atende de forma baixa, apenas 1 indica que atende de forma satisfatória. Vale salientar que o
participante que tem experiência em DDS em empresa respondeu que a abordagem atende
pouco as necessidades do DDS, assim como os artefatos apresentados pela abordagem e
estratégia. Ele sugeriu que ao invés de se utilizar o Google docs seria interessante uma
ferramenta específica para inspeção. Em relação à estratégia ele comentou a importância de se
conhecer os horários de sobreposição entre as equipes dispersas, assim como a importância de
se ter um responsável no local em que se encontram os inspetores, dessa forma pode-se
exercer um controle maior para o cumprimento das atividades, que no caso da estratégia
proposta seria a função do Gerente de Projeto Local.
Em relação às questões 5, 6 e 7, as quais perguntam se o uso da abordagem pode
amenizar os problemas de comunicação, de coordenação e de controle, respectivamente, o
participante que tem experiência em DDS respondeu que a abordagem proposta pode
minimizar em baixo grau esses problemas. Já os participantes com experiência acadêmica
referente à DDS afirmaram que a abordagem e a estratégia podem minimizar em grau
intermediário os problemas de DDS.
O Gestor e Analista de Sistemas ficaram satisfeitos com os resultados obtidos por
meio da inspeção realizada, relataram que a ausência de Gerentes de Projeto Local nas
localidades dispersas poderia apresentar um impacto maior em relação à coordenação e
controle caso as equipes nessas localidades fossem maior. O Analista de Sistemas argumentou
que a etapa Apresentação é de grande importância para poder explicar o artefato, pois os
inspetores estão dispersos e geralmente não conhecem o artefato gerado pelo autor, dessa
forma, acredita que esta etapa deveria ser obrigatória e não opcional conforme apresentado
neste trabalho.
4.2. Aplicação da inspeção na abordagem de Leal (2010)
Com o intuito de contribuir ao projeto de pesquisa DiSEN foi incluída uma atividade de
inspeção no trabalho intitulado na abordagem integrada de desenvolvimento e teste de
software para equipes distribuídas, apresentado por Leal (2010). A aplicação dessa inspeção
se limita até a etapa Discriminação.
92
Na etapa Gestão da Preparação o Gestor decidiu por utilizar o plano de
desenvolvimento global definido por Leal, uma vez que o foco neste trabalho é aplicação da
inspeção. Para tanto, utilizou-se a descrição textual e a descrição extendida de casos de uso.
Já na etapa Planejamento o Moderador descreveu da inspeção, assim como definiu que
técnica de leitura a ser utilizada será o checklist que é ilustrado na Figura 31. Os participantes
envolvidos nesta inspeção estão dispersos geográfica e temporalmente. Eles estão dispersos
da seguinte forma:
Dublin – Leinster – Irlanda
Londrina – Paraná – Brasil
Maringá – Paraná – Brasil
Figura 31 – Checklist utilizado na inspeção
O Moderador disponibilizou aos Inspetores o artefato, no Google docs e também por
e-mail, Formulário contendo o checklist, Formulário Lista de Discrepâncias, Formulário Lista
de Erros de Digitação, Formulário Classificação de Defeitos. Nesse email o Moderador
definiu o prazo para finalização da detecção, pois a etapa Apresentação não foi executada,
uma vez que o Moderador verificou que não há necessidade de apresentação do artefato.
Na etapa Detecção de Defeitos os inspetores individualmente efetuaram a inspeção. A
classificação utilizada foi definida por Shull et al. (2000). Os Inspetores encaminharam os
93
formulários ao Moderador e já na etapa Coleção, as discrepâncias foram agrupadas e
submetidas à etapa Discriminação, para, então verificar se haviam falsos positivos ou
defeitos. A seguir, gerou-se a lista de defeitos, ilustrada na Figura 32, que foi encaminhada ao
Ator do artefato para proceder sua correção.
Figura 32 – Lista de Defeitos
A aplicação da inspeção evidencia a necessidade de se incluir na abordagem de Leal
(2010) a definição de trabalho Aplicar Inspeção, dessa forma pode-se contribuir para a
qualidade dos artefatos gerados durante sua abordagem.
4.3. Considerações Finais
Após os relatos dos participantes do estudo, pôde-se observar que o baixo conhecimento em
inspeção de software e falta de prática, tanto na academia quanto na empresa, trouxe
94
dificuldades para analisar o DRS. O checklist utilizado no estudo auxiliou na identificação dos
defeitos, apresentou um conjunto pré-definido de questões, direcionou os inspetores a
responderem as questões que atribuíam respostas sim ou não, preenchendo os possíveis
defeitos na lista de discrepância.
Foram encontrados 42 defeitos, classificados entre Omissão, Informação Ambígua,
Informação Inconsistente, Fato Incorreto, Informação Estranha e Defeito Diverso.
A empresa já havia relatado que não faz inspeção em seu processo de
desenvolvimento. Devido a isso não há dados de inspeções e nem um chekclist definido.
Dessa forma, buscou-se na literatura questões para fazerem parte do checklist selecionado.
A comunicação entre os participantes foi positiva, pois a língua utilizada era comum a
todos, apesar de se ter alguns participantes dispersos geográfica e temporalmente: Dublin na
Irlanda e San Francisco nos Estados Unidos. Foi agendada reunião com horário em que todos
pudessem participar, utilizando-se para tanto o site 24TimeZones que apresenta os 24 fusos
horários. Não houve diferenças socioculturais marcantes, pois todos os participantes eram
brasileiros e da mesma região.
Os participantes relataram que apesar do material disponibilizado com os conceitos de
inspeção de software, eles sentiram a necessidade de um treinamento em relação à inspeção
de software.
Um dos participantes, em seu relato sobre experiência em DDS, fez os seguintes
comentários: vantagens positivas de se trabalhar em casa (home-office) é não enfrentar o
trânsito; almoçar todos os dias em casa; economizar com o combustível e pode ficar mais
próximo da família. Já as desvantagens relatadas por ele foram: a falta de ambiente de
escritório, ficar sozinho sem alguém da empresa para conversar gera uma sensação de solidão;
trabalha-se muito mais, pois responde-se demandas fora do horário de trabalho; a maioria dos
“amigos” na empresa é virtual, pois o contato geralmente é via sametime – serviços de
comunicação integrados (voz, dados e vídeo) em tempo real da IBM.
95
Conclusão
A distribuição de serviços entre vários locais, principalmente entre vários países, já se tornou
realidade para muitas organizações, todos querem serviços e produtos com qualidade,
incluindo-se também os produtos de software, que, para terem qualidade, é necessário atender
aos requisitos identificados e acordados com o cliente.
Para se entregar ao cliente o que este deseja, o software deve ser desenvolvido
obedecendo a um processo no qual, geralmente, várias pessoas estão envolvidas. Dado o
número de pessoas envolvidas, principalmente quando se trata de desenvolvimento
distribuído, pode ocorrer que o que se está desenvolvendo não seja exatamente o que foi
requisitado. Assim, torna-se importante que sejam utilizadas técnicas que ofereçam o apoio
necessário para identificar as discrepâncias, que podem resultar em defeitos, o mais cedo
possível. Com isto, evita-se que estas se propaguem para fases posteriores e,
consequentemente, aumentem o custo do retrabalho para arrumá-lo. Nesse sentido, a inspeção
tem se configurado como uma técnica interessante e importante a ser utilizada nas diferentes
etapas e artefatos gerados durante o desenvolvimento de software.
Assim, uma abordagem de inspeção e a estratégia de apoio à inspeção em
desenvolvimento distribuído de software foram propostas neste trabalho e aplicadas a um
Documento de requisitos de software (DRS). No exemplo, os participantes e o modelo de
negócio considerados configuraram-se como sendo offshore outsourcing.
Os participantes relataram que a principal diferença, em relação aos processos de
inspeção de software que eles conheciam, é que a abordagem proposta neste trabalho inclui
5 Capítulo
96
uma etapa para definir um modelo de negócio. Acredita-se que, embora os demais processos
não tivessem esta etapa, isto não seria um impedimento para se fazer esta escolha. Vale
salientar que uma das diferenças, que se caracterizou como uma das vantagens da abordagem
proposta neste trabalho foi a inclusão de papéis do Gerente de Projeto Global e do Gerente de
Projeto Local, que não foram apresentados na literatura referente à inspeção de software. A
presença de profissionais exercendo estes papéis no contexto de DDS é suma importância,
pois a atuação destes contribui para a redução dos efeitos negativos da dispersão.
Observou-se ainda que a abordagem e a estratégia podem auxiliar mais no
desenvolvimento distribuído de software se houver um software on line para concentrar todos
os artefatos, assim como para registrar as discrepâncias diretamente e controlar o desempenho
de cada inspetor.
De um modo geral, a análise feita pelo participante com maior experiência em DDS é
que, apesar da abordagem e da estratégia terem um impacto pequeno na minimização dos
efeitos negativos do DDS, esse estudo mostrou a importância da inspeção de software no
desenvolvimento distribuído de software e, também, que se deve levar em consideração o
modelo de negócio para poder definir uma estratégia a fim de se aplicar a inspeção.
5.1. Dificuldades e Limitações
Em âmbito regional, houve dificuldade em se encontrar empresas que utilizassem a inspeção
de software no processo de desenvolvimento, assim como, de um modo geral, as empresas
ainda não têm adotado o desenvolvimento distribuído de software.
5.2. Trabalhos Futuros
Abaixo seguem algumas sugestões para trabalhos futuros.
Replicar o estudo para ampliar a aquisição de conhecimento sobre a aplicação
da abordagem e a estratégia proposta neste trabalho e, assim, refinar nas
atividades ou artefatos.
Aplicar o estudo utilizando uma ferramenta de apoio à inspeção em
desenvolvimento distribuído de software, por exemplo, utilizando ISPIS
97
(Infraestrutura de Suporte ao Processo de Inspeção de Software) ou IBIS
(Internet Based Inspection System).
Aplicar o modelo de Hofstede (2001) em uma equipe de desenvolvimento
distribuído de software com culturas diferentes e, assim, realizar uma avaliação
dos aspectos sócios culturais quando se realiza a inspeção.
Finalizar a integração de inspeção na abordagem definida por Leal (2010) e
efetuar uma validação aplicando-a, se possível, a um caso real.
Avaliar a estratégia com utilização de outras técnicas de leitura a fim de se
avaliarem os pontos positivos e negativos de cada uma delas, quando se
considera DDS e os diferentes modelos de negócio.
Definir atividades na estratégia para avaliá-la com outros modelos de negócio
em DDS.
98
Referências
ACKERMAN, A.F.; BUCKWALK, L.S.; LEWSKI, F.H. Software Inspections: An Effective Verification Process. IEEE Software, n. 1, v. 14, pp. 31-36, 1989.
ÅGERFALK, P.J.; FITZGERALD, B.; HOLMSTRÖM, H.; LINGS, B.; LUNDELL, B.; Ó CONCHÚIR, E. A Framework for considering Opportunities and Threats in Distributed Software Development. In Proceedings of the International Workshop on Distributed Software Engineering, pp. 47-61, 2005.
ANDA, B.; SJOBERG, D. I. K. Towards an inspection technique for use case models. In Proceedings of the 14th international conference on Software engineering and knowledge engineering, pp. 127-134, 2002.
ANSI/IEEE Std 1028-1997. IEEE Standard for Software Reviews. IEEE Computer Society Press, 1997.
ANSI/IEEE Std 830-1998. IEEE Guide to Software Requirements Specifications. IEEE Computer Society Press, 1998.
BASILI, V. R.; GREEN, S.; LAITENBERGER, O.; LANUBILE, F.; SHULL, F. The Empirical Investigation of Perspective-based Reading. Empirical Software Engineering, n. 2, v. 1, pp. 133-164, 1996.
BASILI, V. R.; WEISS, D.M. Evaluation of a Software Requirements Document by Analysis of Change Data. In: Proceedings 5th International Conference On Software Engineering, IEEE CS Press, California, EUA, pp. 314-323, 1981.
BASILI, V.. Evolving and Packaging Reading Technologies. The Journal of Systems and Software, 38(1): 3-12, 1997.
BISANT, D. B.; Lyle , J. R. A Two-Person Inspection Method to Improve Programming Productivity. IEEE Trans. Softw. Eng. v. 15, n. 10, pp. 1294-1304. 1989.
BOEHM, B.; BASILI, V. R. Software Defect Reduction Top 10 List. IEEE Computer, n.1, v. 34, pp. 135-137, 2001.
BROTHERS, L.; SEMBUGAMOORTHY, V.; Muller, M.. ICICLE: groupware for code inspection. In Proceedings of the 1990 ACM Conference on Computer-Supported Cooperative Work, pp. 169-181, 1990.
99
BRYKCZYNSKI, B. A survey of software inspection checklists. SIGSOFT Softw. Eng. Notes v. 24, n.1, pp. 82, 1999.
CALEFATO, F.; LANUBILE, F; MALLARDO, T. A Controlled Experiment on the Effects of Synchronicity in Remote Inspection Meetings. First International Symposium on Empirical Software Engineering and Measurement (ESEM 2007), pp.473-475, 2007.
CARMEL, E.. Global Software Teams: Collaborating across Borders and Time Zones. Upper Saddle River, NJ: Prentice-Hall, 1999.
CARMEL, E.; AGARWAL, R. Tactical approaches for alleviating distance in global software development. IEEE Software18, pp. 22–29, 2001.
DAMIAN, D.; ZOWGHI, D. An insight into the interplay between culture, conflict and distance in globally distributed requirements negotiations. In: HAWAII INTERNATIONAL CONFERENCE ON SYSTEM SCIENCES, 36, Hawaii, 2003.
DAVIS, A.; OVERMYER, S.; JORDAN, K. Identifying and Measuring Quality in a Software Requirements Specification. Proceedings of the First International Software Metrics Symposioum. Baltimore. 1993.
DELAMARO, M.E.; MALDONADO, J.C.; JINO, M.. Introdução ao Teste de Software. Rio de Janeiro: Campus, 2007.
DENNIS, A. R.; VALACICH, J. S. Rethinking Media Richness: Towards a Theory of Media Synchronicity, Proc. Hawaii Int’l Conf. on System Sciences (HICSS-32), Vol. 1, 1999.
EBERT, C.; DE NEVE, P. Surviving Global Software Development. IEEE Software, v.18, n.2, pp.62-69, 2001.
FAGAN, M. E.. Advances in Software Inspection, IEEE Transactions on Software Engineering, Vol. SE-12, NO. 7, Julho, 1986.
FAGAN, M. E.. Design and Code Inspections to Reduce Errors in Program Development. IBM System Journal, V. 15, N. 3, pp. 182-211, 1976.
FARIA, Fabio. Qual é o melhor momento para outsourcing de TI nas organizações? In: ALBERTIN, A. L.; SANCHEZ, O. P. (Org.). Outsourcing de TI: Impactos, Dilemas, Discussões e Casos Reais. 1. ed. Rio de Janeiro: Editora FGV, v. 1. 292 p., 2008.
GIL, A. C. Como elaborar projetos de pesquisa. 3º ed. São Paulo: Atlas, 159p, 1996.
GILB, T.; GRAHAM, D.. Software Inspection. Addison-Wesley, 1993.
GINTELL, J.W.; ARNOLD, J.; HOUDE, M.; KRUSZELNICKI, J.; McKenney, R.; MEMMI, G. Scrutiny: a collaborative inspection and review system. Proc. of the 4th European Conf. on Software Engineering, pp.344-360, 1993.
GRÜNBACHER, P.; HALLING, M.; BIFFL, S. An Empirical Study on Groupware Support for Software Inspection Meetings. Proceedings of the 18th IEEE International Conference on Automated Software Engineering, 2003.
100
HARJUMAA, L.; TERVONEN, I.; VUORIO, P. Improving Software Inspection Processes with Patterns. In: IEEE, pp. 118-125, 2004.
HEDBERG, H.; HARJUMAA, L. Virtual Software Inspections for Distributed Software Engineering Projects. In: Proceedings of ICSE International Workshop on Global Software Development, 2002.
HERBSLEB, J. D.; GRINTER, R. E. Architectures, coordination, and distance: Conway's Law and beyond. IEEE Software, pp. 63-70, 1999.
HERBSLEB, J. D.; MOITRA, D. Global software development. IEEE Software, March/April, 16-20, 2001.
HERBSLEB, J.; PAULISH, D.J.; e BASS, M. Global software development at Siemens: Experience from nine projects. International Conference on Software Engineering (ICSE), St. Louis, MO, May 15-21, pp. 524-533, 2005.
HOFSTEDE, G. Culture's Consequences: Comparing Values, Behaviors, Institutions, and Organizations Across Nations. London: Sage, 2 ed., 2001.
HUMPRHEY, W. S. Managing the software process, Canada: Addison-Wesley, 1989.
HUZITA, E. H. M.; SILVA, C. A.; WIESE, I. S.; TAIT, T. F. C.; QUINAIA, M. A.; SCHIAVONE, F. L. Um conjunto de soluções para apoiar o desenvolvimento distribuído de software. In: II Workshop de Desenvolvimento Distribuído de Software, Campinas, SP, p. 101, 2008.
JOHNSON, P. M.. An Instrumented Approach to Improving Software Quality Through Formal Technical Review. Proceedings of the 16th International Conference on Software Engineering (ICSE-16), pp. 113-122, 1994.
KALINOWSKI, M.; TRAVASSOS, G. H.. A Computational Framework for Supporting Software Inspections. In: 19th IEEE International Conference on Automated Software Engineering - ASE'04, pp. 46-55, Linz, Austria, 2004.
KAROLAK, D. W. Global software development – managing virtual teams and environments. IEEE Computer Society, EUA, 1998.
KIEL, L. Experiences in Distributed Development: A Case Study. In: INTERNATIONAL WORKSHOP ON GLOBAL SOFTWARE DEVELOPMENT, Portland, 2003.
KNIGHT, J. C; MYERS, E. A.. An Improved Inspection Technique. Communications of the ACM, V. 36, N. 11, November, pp. 51-61, 1993.
LAITENBERGER, O.; ATKINSON, C. Generalized Perspective Based Inspection to handle Object Oriented Development Artifacts. Proceedings of ICSE 99, pp.494-503, 1999.
LAITENBERGER, O.; DeBAUD, J.M. An encompassing life cycle centric survey of software inspection, Journal of Systems and Software, v. 50, n. 1, pp. 5-31, 2000.
LANUBILE, F.; MALLARDO, T.; CALEFATO, F.. Tool support for Geographically Dispersed Inspection Teams. Software Process: Improvement and Practice, v. 8, n.4, pp 217-
101
231, 2003.
LEAL, G. C. L. Uma abordagem integrada de desenvolvimento e teste de software para equipes distribuídas. Dissertação de Mestrado, Maringá: PCC – UEM, 169p, 2010.
MACDONALD, F.; MILLER, J. A Comparison of Tool-Based and Paper-Based Software Inspection. Empirical Software Engineering, v.3, n. 3, pp.233-253, 1998.
MAFRA, S. N.; TRAVASSOS, G. H. Técnicas de Leitura de Software: Uma Revisão Sistemática. Simpósio Brasileiro de Engenharia de Software (SBES), 2005.
MARTIN, J.; SCHENEIDER, G.M.; TSAI, W.T. An Experimental Study of Fault Detection in User Requeriments Documents. ACM Transactions on Software Engineering and Methodology, n. 2, v.1, pp. 188-204, 1992.
MARTIN, J; TSAI, W. T.. N-Fold Inspection: A Requirements Analysis Technique. Communications of the ACM, v. 33, n. 2, pp. 225-232, 1990.
MASHAYEKHI, V.; DRAKE, J. M.; TSAI, W. T.; Riedl, J. Distributed, collaborative software inspection. Software, IEEE, v.10, n.5, pp.66-75, 1993.
MCMEEKIN D. A; KONSKY B. R. von; CHANG E.; COOPER D. J. A. Checklist Based Reading’s Influence on a Developer's Understanding, 19th Australian Software Engineering Conference, pp. 489-496, 2008.
MISHRA, D.; MISHRA, A. A Software Inspection Process for Globally Distributed Teams. On the Move to Meaningful Internet Systems: OTM 2010 Workshops (Lecture Notes in Computer Science), v. 6428, pp. 289-296, 2010.
MISHRA, D.; MISHRA, A. Simplified software inspection process in compliance with international standards. Computer Standards & Interfaces, v. 31, n. 4, pp. 763-771, 2009.
MURPHY, P.; MILLER, J.. A process for asynchronous software inspection. Proc. of the 8th Int. Workshop on Software Technology and Engineering Practice, London, UK, pp.96-104, 1997.
MYERS, G. J.. The Art of Software Testing. 2. Ed. New York: John Wiley & Sons, 2004.
NASA std., Software Formal Inspections Guidebook, National Aeronautics and Space Administration, Washington, DC 20546, 1993.
PARNAS, D. L; WEISS, D. M.. Active Design Reviews: Principles and Practices. Proceedings of the Eighth International Conference on Software Engineering, 1985.
PORTER, A. A.; VOTTA, L. G. An Experiment to Assess Different Defect Detection Methods for Software Requirements Inspections. IEEE Computer Society Press, n. 3, v. 10, pp. 103-112, 1994.
PORTER, A. A.; VOTTA, L. G.; BASILI, V.R. Comparing Detection Methods for Software Requirements Inspections: A Replicated Experiment. IEEE Computer Society Press, n. 6, v. 21, pp. 563-575, 1995.
102
RAKITIN, S. R. Software verification and validation for practitioners and managers. 2. ed. USA: Editora Artech House, 2001.
RAMASUBBU, N.; BALAN, R.K.. Globally distributed software development project performance: an empirical analysis. Proceedings of the ESEC/ACM SIGSOFT FSE 2007. Dubrovink, Croatia, pp 25-134, 2007.
ROBINSON, M.; KALAKOTA, R.. Offshore Outsourcing: Business Models, ROI and Best Practices. EUA: Mivar Press, 2004.
SAUER, C.; JEFFERY, D.R.; LAND, L., YETTON, P. The Effecticveness of Software Development Technical Review: A Behaviorally Motivated Program of Research. IEEE Transactions on Software Engineering, 26 (1), pp 1-14, 2000.
SHULL, F. J. Developing techniques for using software documents: a series of empirical studies. Tese de Doutorado, University of Mariland, USA, 1998.
SHULL, F.; RUS, I.; BASILI, V.R. How Perspective-Based Reading Can Improve Requirements Inspections. Computer, v. 33, n. 7, pp. 73-79, 2000.
SOMMERVILLE, I. Software Engineering, 7. ed.: Addison-Wesley, 1998.
STEIN, M.; RIEDL, J.; HARNER, S.J.; MASHAYEKHI, V. A case study of distributed, asynchronous software inspection. Proc. of the 19th Int. Conf. on Software Engineering, Boston, MA, USA, pp.107-117, 1997.
THELIN, T.; RUNESON, P.; Wohlin, C.. An Experimental Comparison of Usage-Based and Checklist-Based Reading. IEEE Transactions on Software Engineering, v. 29, pp. 687-704, 2003.
TRAVASSOS, G. H.. Mini-Curso: Revisão e Inspeção de Software. IV Experimental Software Engineering Latin America Workshop, São Paulo, 2007.
VOTTA, L. G. Does every inspection need a meeting?. In Proceedings of the 1st ACM SIGSOFT symposium on Foundations of software engineering (SIGSOFT '93), pp. 107-114, 1993.
WIEGERS, Karl E.. Peer Reviews in Software: A Pratical Guide. London: Pearson Education, Inc, 232p, 2002.
YOUSUF, Farzana. ZAMAN, Zahid. IKRAM, Naveed. Requirements Validation Techniques in GSD: A Survey. Multitopic Conference INMIC 2008. IEEE International, pp. 553-557, 2008.
103
Apêndice A
Neste apêndice encontram-se os seguintes documentos:
Documento de Gestão da Preparação;
Formulário de dados pessoas e questionário de estudo;
104
Documento da Gestão da Preparação Dados do Projeto
ID do Projeto Descrição do Projeto Responsável Idioma do Projeto
Data Início Data Fim (previsto)
Definição do modelo de negócio
Dispersão geográfica Relacionamento entre as empresas Modelo Definido
Site Central Fuso-horário Idioma Gerente de Projetos Global
Sites envolvidos
Site Gerente de Projetos Local Diferença de Fuso-horário Idioma
Estrutura Organizacional
Site Colaborador Função Horário de Trabalho
Recursos (Hardware/Software) Site Hardware Software
Treinamentos Colaborador 1 Colaborador 2 Colaborador n
Culturas diferentes Idioma
Software
Feriados Site 1 - Cidade - Estado - Pais
Data Dia Referência
105
Site 2 - Cidade - Estado - Pais Data Dia Referência
Site n - Cidade - Estado - Pais
Data Dia Referência
Formulário de dados Pessoais
Nome:______________________________________________________________________ Telefone: ___________________________________________________________________ E-mail: _____________________________________________________________________ Profissão: ___________________________________________________________________ Localização (Cidade/Estado/País): ________________________________________________
Nível de Formação Tempo de atuação na área de SI ( ) Superior Incompleto ( ) até 6 meses
( ) Superior Completo ( ) 6 a 12 meses
( ) Mestrando ( ) 13 a 24 meses
( ) Mestre
( ) 25 a 36 meses
( ) Doutorando ( ) 37 a 60 meses
( ) Doutor ( ) acima de 60 meses
Tem experiência em Inspeção de Software Tem experiência em desenvolvimento de sistemas
( ) nenhuma
( ) nenhuma
( ) em sala de aula ( ) em sala de aula
( ) em empresa ( ) em empresa
( ) em sala de aula e empresa ( ) em sala de aula e empresa Tem experiência em elaboração de
Documento de Requisitos de Software
Tem experiência em desenvolvimento distribuído de software
( ) nenhuma
( ) nenhuma
( ) em sala de aula
( ) em sala de aula
( ) em empresa
( ) em empresa
( ) em sala de aula e empresa ( ) em sala de aula e empresa
Questionário de estudo
1 - Em que grau o seu conhecimento sobre inspeção foi suficiente para a utilização da Técnica de Leitura?
( ) Nenhum ( ) Baixo ( ) Intermediário ( ) Satisfatório
106
2 - Em que grau você utilizaria a Inspeção em um projeto de desenvolvimento distribuído de software no seu ambiente de trabalho?
( ) Nenhum ( ) Baixo ( ) Intermediário ( ) Satisfatório
3 - Em que grau a abordagem apresentada atende as necessidades do desenvolvimento distribuído?
( ) Nenhum ( ) Baixo ( ) Intermediário ( ) Satisfatório
4 - Em que grau os artefatos apresentados atendem as necessidades do desenvolvimento distribuído?
( ) Nenhum ( ) Baixo ( ) Intermediário ( ) Satisfatório
5 - Em que grau o uso da abordagem pode amenizar os problemas de comunicação? ( ) Nenhum ( ) Baixo ( ) Intermediário ( ) Satisfatório
6 - Em que grau o uso da abordagem pode amenizar os problemas de coordenação?
( ) Nenhum ( ) Baixo ( ) Intermediário ( ) Satisfatório
7 - Em que grau o uso da abordagem pode amenizar os problemas de controle? ( ) Nenhum ( ) Baixo ( ) Intermediário ( ) Satisfatório
Faça um relato sobre sua experiência profissional referente à inspeção e/ou referente ao DDS.
107
Anexo A
Neste anexo encontram-se os seguintes documentos:
Formulário de Detecção de Defeitos da Técnica de Leitura Checklist;
Lista de discrepâncias utilizada pelos Inspetores;
Lista de erros de digitação;
Lista de defeitos; e
Documento de Requisitos de Software;
108
Formulário de Detecção de Defeitos da Técnica de Leitura Checklist
Item para inspeção SIM NÃO 1. As funções descritas são suficientes para se conhecer os objetivos do
sistema?
2. Todas as entradas para cada função são suficientes para a execução da função requerida?
3. Eventos indesejáveis são considerados e suas respostas são especificadas?
4. O estado inicial e os estados especiais (tais como: inicialização do sistema, término anormal, etc.) são considerados?
5. O sistema pode ser testado, demonstrado, analisado ou inspecionado para mostrar que satisfaz os requisitos?
6. As características relativas à descrição dos itens de dados, como: tipo, taxa de variação unidade, exatidão, resolução, limites, média e valores críticos são definidos sempre que necessário?
7. As características relativas à descrição das entradas e saídas de cada função (tais como precisão, média, freqüência, volume, etc.) foram definidas?
8. A funcionalidade do hardware, software, banco de dados ou fluxo de atividades, relacionadas com o sistema estão descritos?
9. As entradas e as saídas definidas para cada uma das interfaces são suficientes?
10. Os requisitos de interface entre o sistema em si e os componentes que estão fora do escopo do sistema foram definidos?
11. Cada requisito está definido de forma discreta, não ambíguo e testável?
12. Todas as transições entre modos ou estados do sistema são especificados claramente e corretamente?
13. Os requisitos funcionais são consistentes entre si? 14. Os requisitos funcionais são consistentes com a visão geral? 15. Os requisitos funcionais são consistentes com o ambiente em que
o sistema será executado?
16. Todas as funções descritas são necessárias para se alcançar os objetivos do sistema?
17. Todas as entradas para cada função são necessárias para implementar a função?
18. As entradas e saídas, para todas as interfaces definidas, são necessárias?
19. Todas as saídas produzidas, para cada função, são usadas por outras funções ou transferidas através de alguma interface externa?
20. Todos os requisitos, interfaces, restrições, etc, estão listados nas seções apropriadas?
109
Lista de discrepância
Gravar nesta lista quaisquer discrepâncias encontradas durante a detecção da inspeção. Inspetor: Tempo de duração da detecção (minutos):_____________________________ Nome do projeto: ______________________________________ Descrição do produto de trab: Data:__________________________________________________________ Legenda: O – Omissão | A – Ambiguidade | I – Inconsistência | FI – Fato Incorreto | IE – Informação Estranha | DD – Defeitos Diversos
Nº da pág
Nº da linha
Nº do req.
Nº da fíg.
Tipo do defeito
Descrição do defeito
110
Lista de erro de digitação
Gravar nesta lista quaisquer erros tipográficos encontrados durante a detecção de defeitos, incluindo erros ortográficos, gramaticais, formatação e de estilo. Eles serão corrigidos, mas não precisam ser discutidos. Eles não contarão como defeitos. Inspetor: Nome do projeto: ______________________________________ Descrição do produto de trab: Data:__________________________________________________________
Nº da pág
Nº da linha
Nº do req.
Nº da fíg.
Descrição do erro de digitação
111
Lista de defeitos
Gravar nesta lista os defeitos identificados pelos Inspetores. Moderador: __________________________________________ Tempo de duração da coleção (minutos): ___________________ Nome do projeto: ______________________________________ Descrição do produto de trab: ____________________________ Data: ________________________________________________ Legenda: O – Omissão | A – Ambiguidade | I – Inconsistência | FI – Fato Incorreto | IE – Informação Estranha | DD – Defeitos Diversos
Nº da pág
Nº da linha
Nº do req.
Nº da fíg.
Tipo do defeito
Descrição do defeito
112
Documento de Requisitos de Software 1 Gestão Empresarial B 2
3 Conteúdo 4 1. Introdução 5 a. Objetivo 6
Este documento apresenta a especificação de requisitos para 7 um sistema de informação denominado Gestão Empresarial B, utilizado 8 principalmente por pequenas e médias empresas para controle do faturamento, 9 estoque, compras e financeiro. Esses requisitos representam o entendimento 10 do sistema, obtidos por meio de entrevistas, pesquisas e consultas. Os 11 objetivos do documento são: 12
Demonstrar aos stakeholders que o analista de 13 sistemas entendeu corretamente todos os requisitos do 14 sistema Gestão Empresarial B; 15 Servir como um guia durante o projeto do sistema. 16
17 b. Escopo 18
Este documento contém, primordialmente, os requisitos 19 necessários para automatizar o processo de cadastro de fornecedores, locais 20 de estoque e movimentação do Estoque. Assim, requisitos para outras áreas 21 como emissão de nota fiscal, faturamento, financeiro e compras ficam fora do 22 escopo deste documento. 23 24 c. Definições, Siglas e Abreviações 25
Cliente: Pessoa física ou jurídica, que tem alguma 26 dívida com a empresa em questão, onde consumido algum 27 serviço/produto adquiri uma dívida com a empresa; 28 Fornecedor: Pessoa física ou jurídica que fornece 29 algum tipo de produto/serviço para a empresa e a empresa 30 adquiriu uma dívida com o mesmo. 31 Rede: Interligação entre computadores que 32 permitem trocar informações e utilizar recursos disponíveis 33 na mesma; 34 IE: Inscrição Estadual; 35 CNPJ: Cadastro Nacional de Pessoa Jurídica; 36 UF: Unidade Federal; e 37 PC: Computador Pessoal. 38 39
d. Visão Geral 40 O restante deste documento é dividido em duas seções. A 41
seção 2 contém uma visão geral e informal do sistema de informação. A seção 42 3 apresenta os requisitos funcionais e os requisitos de performance do sistema. 43 2. Descrição Geral do Sistema 44 a. Perspectiva do Produto 45
O Sistema Gestão Empresarial B irá automatizar as operações 46
113
diárias de uma empresa. O sistema permitirá o cadastro de diferentes locais de 47 estoque, bem como o cadastro de fornecedores e produtos. O sistema pode 48 rodar em um PC que se encontra na empresa ou pode até mesmo ser instalado 49 em um servidor e utilizado por diversos usuários. Ele também pode interagir 50 com leitores de código de barras, além de impressoras para emissão de 51 relatórios. Todas as informações gravadas serão armazenadas em um arquivo 52 dentro do computador, ou em outro computador conectado na mesma rede. 53 b. Funções do Produto 54
Um funcionário da própria empresa fica responsável por 55 gerenciar o estoque da mesma. Este funcionário deverá constantemente 56 atualizar o sistema para que o sistema represente a realidade dos produtos no 57 estoque. Antes de o funcionário entrar no sistema, ele informará seu usuário e 58 senha para ter acesso as permissões oferecidas a ele. Na tela principal o 59 usuário tem as opções Cadastro, Estoque, Relatórios e Sair. Dentro de 60 Cadastro ele encontrará as seguintes operações: 61
Cadastrar os fornecedores, informando seus dados como 62 nome, razão social, CNPJ ou CPF, Endereço e Telefone; 63 Cadastrar os produtos, informando seu nome, nome 64 abreviado, peso líquido, peso bruto, tipo de unidade e 65 vinculando o produto a um ou mais locais de estoque. Neste 66 cadastro que você define também qual é o mínimo aceitável 67 em cada local de estoque. 68 Dentro de Estoque o usuário encontrará as seguintes 69 opções: 70 Listagem de produtos, onde o usuário pode verificar quanto 71 de cada produto que tem no estoque e puxar o custo do 72 produto baseado no valor da última compra. 73 Listagem de movimentações, onde o sistema traz todas as 74 movimentações de um período informado pelo usuário. Aqui 75 também é onde o usuário pode inserir novas movimentações 76 tanto de entrada, quanto de saída. 77 Cadastro de tipo de movimentação, para o usuário 78 cadastrar novas formas para se movimentar o estoque. 79 Cadastro de locais de estoque, onde é informado dados 80 referente aos locais reais onde o estoque se encontra. 81 Apenas o nome é informado. 82
83 c. Características do Usuário 84
O sistema será utilizado por funcionários que trabalham no 85 controle de estoque de uma empresa. Espera-se que além de serem 86 alfabetizados e tenham conhecimento de matemática básica, eles tenham 87 conhecimento básico sobre o manuseio de um computador. O funcionário deve 88 ser treinado para saber todas as funcionalidades e o método correto para se 89 completar uma movimentação. 90 d. Limitações e Suposições 91
Suposição Inicial 92
114
o O usuário terá um computador voltado somente para poder 93 realizar o controle de estoque, onde este se encontrará em uma 94 rede de computadores e ira interagir com outras áreas do sistema 95 como o compras e o faturamento. 96
Outras suposições e Limitações 97 o Todos os produtos, locais de estoque e fornecedores estarão 98
cadastrados no sistema com os dados mais atuais possíveis. 99 o O hardware do computador deve manter a data correta. 100 o As movimentações sejam registradas assim que forem 101
executadas. 102 o As quantidades registradas no sistema estarem com o valor 103
exatamente igual ao que se encontra na realidade. 104 105 3. Requisitos Específicos 106
A seguir será apresentada a lista dos requisitos funcionais que 107 o sistema deve satisfazer. Cada requisito é caracterizado através dos seguintes 108 itens: 109
Descrição: breve descrição da funcionalidade do sistema. 110 Entrada: uma descrição das entradas recebidas pelo software. 111 Processamento: uma descrição do que o sistema de software deve 112
realizar com a entrada recebida; 113 Saída: uma descrição da resposta/novo estado do sistema de software. 114
115 3.1 Requisitos Funcionais 116 3.1.1 Requisitos para Acessar o Sistema 117 Requisito Funcional 1 118 Descrição 119
O administrador do sistema deve gerenciar o cadastro de 120 usuários, como incluir, alterar ou excluir os usuários. Além disse deve vincular 121 as permissões de ações dentro do sistema para cada usuário. 122 Entrada 123
Nome do usuário, login, senha e permissões 124 Processamento 125
O sistema verifica se não há outro login e senha iguais. Caso 126 esta regra seja quebrada, o sistema gera uma mensagem de erro. 127 Saída 128
Permissão de acesso às funções vinculadas ao usuário ou 129 mensagem de erro de cadastro. 130 131 Requisito Funcional 2 132 Descrição 133
Após o acesso ao sistema, o seguinte menu principal é exibido. 134 Do menu principal o usuário pode optar por uma das seguintes opções: 135
1. Cadastro 136 2. Estoque 137 3. Relatórios 138
115
4. Sair 139 Entrada 140
Usuário escolhe a opção desejada. 141 Processamento 142
O item selecionado é processado. 143 Saída 144
Exibe no monitor o sub menu para o item selecionado 145 146 Requisito Funcional 3 147 Descrição 148
No Sub menu do item cadastro o usuário pode selecionar uma 149 das seguintes opções: Fornecedor, Produto. 150 Entrada 151
O usuário fornece os campos (atributos) necessários para 152 realizar a operação. 153 Processamento 154
Executa a operação desejada como acessar o cadastro de 155 fornecedores, ou acessar o cadastro de produtos, onde em ambos os casos o 156 usuário pode incluir, alterar, excluir ou consultar. Os dados de ambos os casos 157 serão salvos no banco de dados de acordo com o formato apropriado, caso 158 contrário será enviado uma mensagem ao usuário. Caso o usuário não tenha 159 permissões para executar alguma ação, uma mensagem será exibida. 160 Saída 161
Mostra os dados atualizados de acordo com a operação 162 requerida. 163 164 Requisito Funcional 4 165 Descrição 166
No Sub menu do item Estoque o usuário pode selecionar uma 167 das seguintes opções: Produto, Movimentação, Tipo de Movimentação e Local 168 de Estoque 169 Entrada 170
O usuário fornece os campos (atributos) necessários para 171 realizar a operação. 172 Processamento 173
Executa a operação escolhida, como consultar a quantidade de 174 um determinado produto no estoque, além de consultar seu custo ou pode 175 consultar as movimentações de um determinado período, bem como incluir, 176 alterar ou excluir movimentações no estoque. Além disso, o usuário pode 177 incluir, alterar, excluir ou pesquisar dados referentes a Tipos de Movimentação 178 e Locais de Estoque. Todas as informações são consultadas/ gravadas em um 179 banco de dados no formato correto, caso contrário será exibida uma 180 mensagem. Caso o usuário não tenha permissões para alguma das ações, 181 uma mensagem será exibida. 182 Saída 183
Mostra os dados atualizados de acordo com a operação 184 requerida. 185 186
116
Requisito Funcional 5 187 Descrição 188
No Sub menu do item Relatório o usuário pode selecionar uma 189 das seguintes opções: Movimentações e Inventário 190 Entrada 191
O usuário fornece os campos (atributos) necessários para 192 realizar a operação. 193 Processamento 194
Executa a operação escolhida, como abrir a tela de filtros para 195 escolher quais produtos e qual data o usuário deseja gerar o relatório de 196 movimentações ou abrir o relatório de inventário para saber quanto de cada 197 produto o sistema tem registrado em seu banco de dados. As informações são 198 extraídas do banco de dados, e o relatório pode ser salvo em pdf ou impresso. 199 Saída 200
Dados impressos 201 202 3.1.2 Requisitos para Cadastrar um Novo Fornecedor 203 Requisito Funcional 6 204 Descrição 205
Quando a empresa compra de um fornecedor que não possui o 206 cadastro prévio no sistema, o usuário insere as informações referentes a 207 empresa do fornecedor, gerando um novo código. 208 Entrada 209
Razão Social, Nome Fantasia, CNPJ, IE, CNPJ, e-mail, 210 Logradouro, Número, Bairro, CEP, Cidade, UF, Telefone. 211 Processamento 212
Gera o código do Fornecedor e cria um registro para o mesmo. 213 Será enviado ao usuário uma mensagem dos campos obrigatórios a serem 214 preenchidos. Caso o usuário preencha algum campo com um valor inválido, 215 uma mensagem de erro será gerada ao tentar gravar. 216 Saída 217
Um registro de fornecedor é produzido. Agora é possível 218 realizar movimentações em nome do fornecedor. 219 220 3.1.3 Requisitos para Cadastrar um Novo Produto 221 Requisito Funcional 7 222 Descrição 223
Quando a empresa compra um produto que não possui no 224 cadastro, ou está começando a comercializar um produto novo, o usuário 225 precisa cadastrá-lo no sistema. 226 Entrada 227
Nome, Nome Abreviado, Unidade, Peso líquido, Peso Bruto, 228 Volume, Grupo Pertencente, Grupo de Comissão, código de barras, local de 229 estoque 230 Processamento 231
Gera o código do Produto e cria um registro para o mesmo. 232 Será enviado ao usuário uma mensagem dos campos obrigatórios a serem 233 preenchidos. Caso o usuário preencha algum campo com um valor inválido, 234
117
uma mensagem de erro será gerada ao tentar gravar. Ao inserir as informações 235 principais, o usuário abre a tela de vinculo do produto com locais de estoque e 236 escolhe quais locais e q quantidade mínima em cada local que aquele produto 237 pode chegar. 238 Saída 239
Um registro de Produto é produzido. Agora é possível realizar 240 movimentações com o produto. 241 242 3.1.4 Requisitos para Cadastrar um Local de Estoque 243 Requisito Funcional 8 244 Descrição 245
Quando a empresa não possui todos os locais de estoque 246 registrado, ou adquiri um novo local, o usuário tem que inserir o mesmo no 247 sistema. 248 Entrada 249 Nome. 250 Processamento 251
Gera o código do Local de Estoque. Caso o usuário não 252 escreva nenhum nome, uma mensagem de erro será exibida. 253 Saída 254
Um registro de Local de Estoque é produzido. Agora é possível 255 vincular um produto a este local de estoque e escolher o local ao gerar uma 256 movimentação. 257 258 3.1.5 Requisitos para Cadastrar um Tipo de Movimentação 259 Requisito Funcional 9 260 Descrição 261
Quando a o usuário precisa movimentar o estoque e o tipo de 262 movimento não existe. 263 Entrada 264 Nome, Tipo Básico 265 Processamento 266
Gera o código para o Tipo de Movimentação. O usuário coloca 267 o nome do tipo de movimentação e escolhe se o movimento vai apresentar 268 características de entrada ou saída. 269 Saída 270
Um registro de Tipo de Movimentação é produzido. Agora é 271 possível escolher o tipo cadastrado na tela de movimentação. 272 273 3.1.6 Requisitos para Registrar uma Movimentação no Estoque 274 Requisito Funcional 10 275 Descrição 276
Quando ocorre qualquer mudança no estoque, o usuário 277 precisa registrar esta mudança no sistema. 278 Entrada 279
Tipo de movimento, Data de movimentação, Entidade, 280 Documento Vinculado, data do documento, Observações, Produtos, 281
118
quantidade, valor e local de estoque. 282 Processamento 283
Gera o código da movimentação e abre a tela para cadastrar a 284 movimentação. Todos os campos são obrigatórios, sendo que o usuário 285 primeiro coloca a data de movimentação, e depois escolhe o tipo de 286 movimentação, colocando o código do tipo de movimentação previamente 287 cadastrado no sistema. O campo entidade deverá ser preenchido com o código 288 do Fornecedor para o caso de compras. O campo documento vinculado é para 289 facilitar buscas posteriores. Uma vez a movimentação gravada, o usuário 290 poderá inserir quantos produtos desejar para aquela movimentação, inserindo 291 o código do produto, quantidade e valor, sendo este último não obrigatório. O 292 usuário deve escolher qual local de estoque o produto irá ser afetado na 293 movimentação, colocando o código do local de estoque, previamente 294 cadastrado. 295 Saída 296
Um movimento registrado e uma alteração na quantidade dos 297 produtos movimentados no local de estoque daquele produto. 298 299 3.2 Requisitos de Interface Externa 300 3.2.1 Interfaces do Usuário 301
As telas do sistema Gestão Empresarial B consistem em 302 interfaces visuais e amigáveis com o usuário. As figuras abaixo representam 303 algumas telas do sistema. A Figura 1 representa a tela de acesso ao sistema, 304 onde o usuário insere seu nome (login) e senha. Acessado o sistema, o usuário 305 terá acesso a todas opções liberadas para ele. A Figura 2 representa a tela de 306 menu principal, oferecendo as opções ao qual o usuário tem acesso. A Figura 3 307 apresenta a tela de cadastros de produtos. A Figura 4 apresenta a tela onde o 308 produto é vinculado a um ou mais locais de estoque. A Figura 5 apresenta o 309 cadastro de fornecedores. A Figura 6 representa o cadastro de tipos de 310 movimentação. Nesta figura é possível observar diversas opções que podem 311 ser selecionadas, mas fogem ao escopo deste documento tratar cada opção 312 por elas interferirem em outras áreas do sistema. A Figura 7 apresenta a tela 313 de cadastro de locais de estoque, bem como uma lista do que já está 314 cadastrado. A Figura 8 apresenta uma listagem de todas as movimentações e 315 campos para realizar um filtro mais específico de quais movimentações você 316 deseja ver. A Figura 9 apresenta a tela de detalhamento de movimentações, 317 onde é possível verificar uma listados itens que foram alterados na 318 movimentação, bem como dados como nome do fornecedor e data de 319 movimento. A Figura 10 mostra a tela de cadastro de item na movimentação, 320 onde o usuário escolhe o item a ser movimentado, bem como o local, a 321 quantidade e se for preciso, o valor do movimento. As Figuras 11 e 12 mostram 322 relatórios, sendo o primeiro referente ao Inventário do estoque, e o segundo 323 relatório detalha as movimentações realizadas em um determinado período 324 separadas por produto. 325 326
119
327 Figura 1 Acesso ao Sistema 328
329
330 Figura 2 Menu Principal 331
332
120
333 Figura 3 Cadastro de Produtos 334
335
336 Figura 4 Vínculo do produto com Local de Estoque 337
338
121
339 Figura 5 Cadastro de Fornecedores 340
341
342 Figura 6 Cadastro de Tipo de Movimentação 343
344
345 Figura 7 Cadastro de Local de Estoque 346
347
122
348 Figura 8 Cadastro de Movimentações 349
350 Figura 9 Lista dos itens de uma Movimentação 351
352
353 Figura 10 Cadastro de um Item de uma Movimentação 354
123
355
356 Figura 11 Relatório de Inventário 357
358 Figura 12 Relatório de Movimentações 359
360 3.2.2 Interfaces de Hardware e Software 361
124
O Sistema Gestão Empresarial B será implementado para 362 funcionar em um ambiente PC, e sistema operacional Windows. A 363 implementação do código será realizada utilizando-se a linguagem de 364 programação visual Delphi, versão 7.0. A escolha desta linguagem deve-se ao 365 fato de seu alto grau de desempenho e sua facilidade para a construção de 366 interfaces amigáveis no padrão Windows, tendo como principal objetivo facilitar 367 a utilização do sistema pelo usuário, sabendo-se que este padrão é conhecido 368 internacionalmente. 369
O banco de dados utilizado para a manutenção dos dados será 370 o Firebird versão 1.5. 371
Os relatórios do sistema serão elaborados utilizando as 372 ferramentas Free Report ou Fortes Report, sendo a escolha entre as 373 ferramentas determinada pela necessidade do relatório. 374
Para o usuário o hardware requerido é, no mínimo, Pentium III, 375 300 MHZ, 1.0 Ghz, om 256 MB RAM e de 500 MB de espaço em disco. 376 377 3.3 Requisitos de Performance 378 379 Requisito de Perfomance 1 380
O Sistema de software completo será de fácil utilização. 381 382 Requisito de Perfomance 2 383
Interfaces visuais amigáveis com o usuário, possibilitando a 384 comunicação com pacote Office (Word/Excel). 385 386 Requisito de Perfomance 3 387
O tempo de resposta para as operações com os dados não 388 podem ultrapassar o tempo de alguns segundos. 389 390 3.4 Outros Requisitos 391 392 Requisito 1 393
O sistema poderá funcionar em todos os sistemas 394 operacionais, ou seja, qualquer plataforma empregada na empresa. 395 Requisito 2 396
O sistema poderá sofrer mudanças, ou seja, novas 397 funcionalidades e novos módulos podem ser inseridos facilmente. 398 Requisito 3 399
O sistema deve ter capacidade para recuperar os dados 400 perdidos da última operação que realizou em caso de falha. 401 Requisito 4 402
O sistema deve fornecer facilidades para a realização de 403 backups dos arquivos do sistema. 404
125
Anexo B
Neste anexo encontram-se os seguintes documentos:
Formulário de Detecção de Defeitos da Técnica de Leitura Checklist;
Descrição Textual e Descrição de Casos de Uso
126
Formulário de Detecção de Defeitos da Técnica de Leitura Checklist
Item para inspeção SIM NÃO N/A 1. A descrição de caso de uso é a de um caso de uso representado no
diagrama?
2. O ator que inicia o caso de uso é o mesmo indicado na descrição textual?
3. A descrição de caso de uso contém nome do caso de uso, nome do ator, fluxo básico e alternativo?
4. As frases representam um diálogo entre o ator e sistema, evidenciando a ação do ator e a resposta do sistema?
5. As frases são construídas em voz ativa? (p. ex. “Sistema valida a quantia informada” em vez de “A quantia informada deve ser validada pelo sistema”)
6. As frases utilizam o tempo presente? 7. São evitados termos que indicam a prematura especificação de
interface, tais como “clicar” “botão” etc?
8. São evitados termos que indicam opção, como “possivelmente”, “alternativamente”, “no caso”, “se”, etc, sem especificar um fluxo alternativo?
9. Os termos passíveis de mais de uma interpretação constam em glossário, com clara definição?
10. Uma vez utilizado um termo, ele é mantido para referenciar-se ao mesmo elemento?
11. As funcionalidades se restringem ao quê o sistema deve fazer e não em como, evitando a definição explícita de código na especificação?
12. A descrição evita requisitos de negócio sem ação direta ao sistema?
13. Há presença de breve descrição ou resumo no início da descrição de caso de uso, que especifique de forma clara o seu propósito?
14. O fluxo básico está aparentemente completo, isto é, há inexistência de evidências claras de incompleteza na especificação?
15. O fluxo alternativo está aparentemente completo, isto é, há inexistência de evidências claras de incompleteza na especificação?
16. As frases são numeradas para que possibilitem a rastreabilidade? 17. As frases procuram ser objetivas, evitando redundâncias ou
presença de informações evidentemente desnecessárias?
127
Descrição Textual 1 O MSPaper objetiva gerenciar o processo de submissão e avaliação de artigos 2
em eventos científicos, sob a perspectiva de quatro tipos de usuários: (i) presidente do 3 comitê científico; (ii) revisores; (iii) autores; e, (iv) administrador. As funcionalidades a 4 serem desenvolvidas são: 5 6
Registro do evento - consiste em caracterizar o evento através da definição de 7 questões relacionadas à: temas que os artigos submetidos devem atender, 8 número de revisões por artigo, calendário do processo de seleção, incluindo: 9 prazo de submissão, prazo de devolução das revisões pelos revisores, data de 10 notificação da aceitação ou rejeição, data limite para submissão da versão final 11 dos artigos aceitos e percentual de artigos a serem aceitos. 12
Submissão de artigos - um dos autores submete o arquivo do artigo em formato 13 PDF. Nessa etapa são identificados todos os autores, a área do artigo, as palavras 14 chaves e o resumo. 15
Distribuição dos artigos - o presidente do comitê científico é responsável por 16 constituir o comitê de programa com base nas especialidades de conhecimento. 17 Após isso, deve liberar a distribuição dos artigos para os autores da área 18 relacionada. 19
Revisão dos artigos - os revisores analisam os artigos submetidos segundo os 20 critérios de avaliação, que são: relevância, conteúdo técnico e rigor científico, 21 originalidade, qualidade da escrita e avaliação global. 22
Consolidação dos resultados - o presidente do comitê científico acompanha as 23 revisões, verificando se todos as revisões foram devolvidas e se houveram 24 atrasos. Além disso, resolve os possíveis conflitos de avaliação, define o número 25 de artigos aceitos e encaminha a notificação de aceitação ou rejeição aos autores. 26
Controle de Acesso - consiste em definir os níveis de acesso de acordo com o 27 tipo de usuário. 28
29 O administrador é responsável pelas configurações relacionadas ao controle de 30
acesso dos usuários. 31 O presidente do comitê científico é o responsável pelo registro do evento no 32
MSPaper, distribuição dos artigos entre os revisores e a consolidação dos resultados. 33 Os autores podem realizar a submissão de artigos e os revisores são 34
responsáveis pela avaliação dos artigos que lhes forem atribuídos. 35
128
36 Figura 1 – Diagrama de casos de uso 37
38 Descrição Extendida de Casos de Uso 39
Para cada caso de uso do MSPaper, sua especificação, contendo descrição, 40 fluxo de eventos, pré e pós-condições. 41 42 43 Nome do caso de Uso 44 Gerenciar acesso 45 Autor/Equipe 46 Gislaine Camila/Maringá 47 Data 48 12/03/2010 49 Atores 50 Administrador e Presidente Comitê Científico 51 Descrição 52 Parte do sistema responsável por gerenciar os níveis de acesso dos usuários. 53 Pré-condições 54 Usuário cadastrado no sistema 55 Pós-condições 56 O usuário logado no sistema ou não 57 Fluxo de eventos 58
59 1. O usuário informa os dados de login e senha. 60
61 2. A tela principal do MSPaper é aberta. 62
Tratamento de exceções 63 64
1. Login e /ou senha inválidos 65 66
(a) O sistema emite uma mensagem informando que os dados estão incorretos.67
129
68 Nome do Caso de Uso 69 Gerenciar evento 70 Autor / Equipe 71 Gislaine Camila/Maringá 72 Data 73 12/03/2010 74 Atores 75 Administrador e Presidente Comitê Científico 76 Descrição 77 O ator Administrador cadastra o evento e vincula o usuário Presidente Comitê 78 Científico ao evento. 79 Pré-condições 80 Usuário estar logado no sistema e ter permissão de Administrador ou ter permissão de 81 Presidente Comitê Científico. 82 Pós-condições 83 Evento cadastrado. 84 Fluxo de eventos 85
86 1. O Administrador cadastra o evento e informa o usuário que será o Presidente do 87
Comitê Científico. 88 89
2. O usuário Presidente Comitê Científico insere as demais informações e 90 disponibiliza o evento para que os demais usuários possam visualizar. 91
Tratamento de exceções 92 93
1. Campo número de revisões por artigo está vazio ou com valor menor ou igual a 94 zero. 95 96 (a) O sistema emite uma mensagem solicitando que seja informado um valor 97
maior que zero. 98 99
2. O prazo de submissão é menos que a data atual. 100 101 (a) O sistema emite uma mensagem informando que o prazo de submissão deve 102
ser posterior data atual. 103 104
3. A data de devolução das submissões é menor que a data de submissão. 105 106 (a) O sistema emite uma mensagem informando que a data de devolução das 107
revisões deve ser maior que a data de submissão. 108 109
4. A data de notificação é menor que a data atual ou menor que a data de devolução 110 das revisões. 111 112 (a) O sistema emite uma mensagem informando que a data de notificação deve 113
ser maior que a data de devolução das revisões. 114 115
5. O percentual de artigos aceitos está vazio ou é menor ou igual a zero. 116 117
130
a) O sistema emite uma mensagem solicitando que seja informando um valor 118 maior que zero. 119 120
Nome do Caso de Uso 121 Submeter Artigo 122 Autor/equipe 123 Gislaine Camila/Maringá 124 Data 125 12/03/2010 126 Atores 127 Autor 128 Descrição 129 O autor realizara submissão de um artigo, para isso ele deve informar a qual tema do 130 evento o artigo esta relacionado, os autores, titulo, resumo, palavras-chave e fazer o 131 upload do arquivo com extensão em PDF. 132 Pré-condições 133 O usuário deve estar cadastrado MSPaper e o prazo para submissão de artigos deve estar 134 aberto. 135 Pós-condições 136 A confirmação de submissão é encaminhada para o e-mail dos autores e o status do 137 artigo fica como “Submetido”. 138 Fluxo de eventos 139
140 1. O autor informa os dados do artigo. 141
142 2. São realizadas as validações, se os dados são validos eles são armazenados. 143
Tratamento de exceções 144 1. A área do artigo esta vazia 145
(a) O sistema emite uma mensagem solicitando o preenchimento da área. 146 147
2. O arquivo não esta no formato PDF. 148 (a) O sistema emite uma mensagem informando que a extensão do arquivo 149
esta incorreta.150
131
151 Nome do Caso de Uso 152 Distribuir artigo 153 Autor/Equipe 154 Gislaine Camila/Maringá 155 Data 156 12/03/2010 157 Autores 158 Presidente Comitê Científico 159 Descrição 160 O autor Presidente Comitê Científico encaminha os artigos aos revisores, considerando 161 os temas selecionados. 162 Pré-condições 163 O prazo para submissão de artigos ter encerrado. 164 Pós-condições 165 É encaminhado um e-mail para os revisores e o status do artigo se torna “Em Revisão”. 166 Fluxo de eventos 167 168
1. O Presidente Comitê Científico disponibiliza os arquivos aos revisores para 169 correção. 170 171
O status do artigo é alterado para “Em Revisão”.172
132
Nome do Caso de Uso 173 Revisar artigo 174 Autor/Equipe 175 Gislaine Camila/Maringá 176 Data 177 12/03/2010 178 Autores 179 Revisor 180 Descrição 181 O Revisor avalia o artigo segundo os critérios: relevância, conteúdo técnico e rigor 182 científico, originalidade, qualidade da escrita e avaliação global. 183 Pré-condições 184 O artigo estar com status “Em Revisão” e dentro do prazo estabelecido para revisão. 185 Pós-condições 186 A revisão é cadastrada e status do artigo passa a ser “Aguardando Parecer”. 187 Fluxo de eventos 188 189
1. O revisor realiza a revisão para os artigos que estão disponíveis para ele. 190 191
2. Finaliza a revisão liberando o resultado para o Presidente do Comitê. 192 Tratamento de exceções 193
194 1. O campo Relevância está vazio. 195
196 (a) O sistema emite uma mensagem solicitando o preenchimento da relevância. 197
198 2. O campo Conteúdo Técnico está vazio. 199
200 (a) O sistema emite uma mensagem solicitando o preenchimento do campo. 201
202 3. O campo Rigor Científico está vazio. 203
204 (a) O sistema emite uma mensagem solicitando o preenchimento do campo. 205 206
4. O campo Originalidade está vazio. 207 208 (a) O sistema emite uma mensagem solicitando o preenchimento do campo. 209 210
5. O Campo Qualidade da Escrita está vazio. 211 212 (a) O sistema emite uma mensagem solicitando o preenchimento do campo. 213 214
6. O campo Qualidade Global está vazio. 215 216 (a) O sistema emite uma mensagem solicitando o preenchimento do campo.217
133
218 Nome do Caso de Uso 219 Consolidar revisão 220 Autor/Equipe 221 Gislaine Camila/Maringá 222 Data 223 13/03/2010 224 Atores 225 Presidente Comitê Científico 226 Descrição 227 O Presidente Comitê Científico realiza o acompanhamento das revisões, resolve os 228 conflitos de revisões e encaminha a notificação da revisão aos autores. 229 Pré-condições 230 A data ser posterior a dada limite para envio das revisões. 231 Pós-condições 232 A notificação das revisões é encaminhada aos autores e tem-se a lista de artigos aceitos. 233 Fluxo de eventos 234
235 1. O Presidente Comitê Científico resolve os conflitos relacionados a revisões que 236
não foram encaminhadas e a avaliação. 237 238
2. Encaminha notificação aos autores informando a data de submissão final para os 239 artigos aceitos e os comentários dos revisores. 240
Tratamento de Exceções 241 242
1. Revisões que não foram devolvidas. 243 244 (a) O ator Presidente Comitê Científico solicita as revisões e estabelece um 245
novo prazo ou encaminha para o outro revisor. 246