Universidade do Estado de Santa Catarina

Centro de Educação Superior do Alto Vale do Itajaí

Departamento de Engenharia de Software

DIAGNÓSTICO E PROPOSTA DE MELHORIA NO PROCESSO

DE SOFTWARE DA PAMPLONA ALIMENTOS S/A BASEADO
NA NORMA ABNT NBR ISO/IEC 29110
Evandro Meurer1
1
Universidade do Estado de Santa Catarina UDESC
vandom.evandro@gmail.com

Resumo
Partindo do princípio que processos de software impactam na qualidade do software
desenvolvido, este artigo descreve um estudo de caso baseado na série de normas ABNT NBR
ISO/IEC 29110. Esta norma é específica para pequenas empresas de software e pode auxiliar a
encontrar processos que estão com um nível baixo de execução e, também quais tarefas podem
ser executadas para melhorar o processo. O artigo descreve uma avaliação de processos de
software aplicada em uma empresa com desenvolvimento de software interno, em que durante a
avaliação foram verificadas, identificadas as evidências de execução e atribuída a pontuação de
atributos de processo para cada uma das tarefas requisitadas pela norma. Também foram feitas
sugestões de melhorias dos processos da empresa, através de fluxogramas criados para
mostrarem o processo sugerido, além de vincular as melhorias com as tarefas requisitadas pela
norma. Sendo que com estas sugestões de melhorias a empresa poderá atender 71% das tarefas
requisitadas pela norma ABNT NBR ISO/IEC 29110, diante dos 25% atendidos atualmente. Por
fim foi visto que, com algumas adaptações, a série de normas ABNT NBR ISO/IEC 29110 pode
ser facilmente inserida nos processos de equipes de desenvolvimento de software com até 25
pessoas.

Palavras-chave: Qualidade de software. Processos de software. ABNT NBR ISO/IEC 29110.

Abstract
Assuming that software processes impact the quality of the developed software, this article
describes a case study based on the series of standards ABNT NBR ISO/IEC 29110. This
standard is specific to small business software and can help find processes that are with a low
level of implementation and also which tasks can be performed to improve the process. The
paper describes an evaluation of software processes applied in a company with development of
internal software, in which were found during the evaluation, identified the evidence of
implementation and assigned to process attributes score for each of the tasks required by the
standard. Suggestions were also made improvements of business processes through flowcharts
created to show the suggested process, and link improvements to the tasks required by the
standard. Since with these suggestions for improvements the company can meet 71% of assigned
tasks by the standard ABNT NBR ISO/IEC 29110, before the 25% currently served. Finally it
was seen that, with some adjustments, the number of ABNT NBR ISO/IEC 29110 can be easily
inserted in the software development teams processes with up to 25 people.

Keywords: Software quality. Software processes. ABNT NBR ISO/IEC 29110.

Trabalho apresentado como requisito para obtenção da titulação de especialista no curso de Pós
Graduação lato sensu em Engenharia de Software, sob orientação do Prof. Pablo Schoeffel, em
Novembro de 2014.
1. Introdução

A Pamplona Alimentos S/A teve sua fundação em 1948 no município de Agronômica/SC, mas
hoje sua matriz está situada em Rio do Sul/SC, com filiais comerciais e industriais em diversos
estados do Brasil. A empresa atua principalmente no mercado de carnes suínas gerando
atualmente cerca de 1.700 empregos diretos, divididos em 190 colaboradores nos setores
administrativos, e os demais nos setores produtivos. O departamento de Tecnologia da
Informação existe desde 1986 e conta com um total de onze colaboradores, para manter e prestar
suporte ao ERP usado na empresa denominado Primus. O ERP atende as seguintes áreas:
Contábil, Fiscal, Custos, Estoques, Vendas, Exportação, Suprimentos, Manutenção de Máquinas
e Equipamentos, Logística, PPCP (Planejamento, Programação e Controle de Produção),
Faturamento, Expedição, Financeiro e Agropecuário.
A estrutura atual do processo de software da Pamplona Alimentos S/A está centralizada
em chamados, que são solicitações de usuários para o desenvolvimento de software. Neles além
dos usuários descreverem a sua solicitação, os colaboradores da TI lançam tempos gastos,
transferem responsabilidades e registram datas de início e término. O sistema de chamados é o
principal meio de registro dos processos do setor. O sistema de chamados é mantido pela própria
equipe em um módulo do ERP, o que permite realizar alterações com facilidade. Também é
utilizada outra ferramenta chamada Trello1, na qual são repassadas as tarefas aos
desenvolvedores, os quais assumem e alteram a fase destas tarefas, representadas por cartões em
colunas de um quadro Kanban. São quatro fases configuradas na ferramenta: Pendente,
Desenvolvimento/Teste, Aguardando OK e Finalizado.
Em alguns casos o processo não é documentado como descrito anteriormente, causando
dificuldade no acesso a informações relacionadas à solicitação. Além deste problema, a empresa
está preocupada com a qualidade do software. Frequentemente acontecem casos de liberação de
programas sem os devidos testes, o que acaba demandando mais serviço de suporte e um
deslocamento temporário de um ou mais colaboradores para a correção do problema. Em muitas
vezes esta correção precisa ser realizada de forma rápida, e mais uma vez é liberada sem a
realização dos testes para garantir a qualidade de software, tornando um círculo vicioso. Esta
situação gera um desconforto na equipe, pois é necessário parar o desenvolvimento de um
projeto, para priorizar correções de erros no sistema. O setor de TI enfrenta também problemas
relacionados a cumprimento de prazos e estimativas de projetos e, principalmente, dificuldade
em ter um processo de software definido. Sabendo disso, pretende-se encontrar soluções para
obter mais qualidade nas entregas de software da empresa, estudando metodologias, normas e
boas práticas de engenharia de software.
Para tanto, o artigo está organizado em sete seções. A seção 2 apresenta conceitos de processo
de software. Na sequência, é apresentada a norma ABNT NBR ISO/IEC 29110, enfatizando
processos de Gerência de Projetos e Implementação de Software, juntamente com a avaliação. A
seção 4 apresenta melhorias de processos em pequenas empresas. Os trabalhos correlatos estão
na seção 5. A avaliação e melhorias dos processos de software da Pamplona Alimentos S/A são
apresentadas na seção 6. E por fim, as conclusões do trabalho estão na seção 7.

2. Processo de software

Na definição de Sommerville (2007), o processo de software são as várias tarefas que tem como
objetivo a criação ou manutenção de um software: “Um processo de software é um conjunto de
atividades e resultados associados que produz um produto de software” (SOMMERVILLE,
2007, p.6). E Pressman (2006) define que “processo de software como um arcabouço para as

1
https://trello.com/
tarefas que são necessárias para construir softwares de alta qualidade” (PRESSMAN, 2006,
p.16).
E ainda, segundo Sommerville (2007), os processos de software, assim como os processos
que envolvem criatividade, são complexos e dependem da pessoa que irá executá-lo. Nesse
sentido, Pressman (2006) compara o processo de software com um processo iterativo de
aprendizagem, em que conforme o processo é executado os conhecimentos são coletados,
separados e organizados.
Observa-se que não existe um processo ideal, cada organização adapta o processo conforme a
sua necessidade, pois as necessidades de cada empresa são diferentes, bem como as pessoas
envolvidas são outras (SOMMERVILLE, 2007). Contudo, existem processos mais estruturados
para sistemas mais críticos, e processos mais flexíveis para sistemas em que o modelo de
negócio não é tão crítico (SOMMERVILLE, 2007).
O aprimoramento dos processos é uma prática que pode ser empregada por meio de
padronização de processo, melhorando a comunicação, reduzindo o tempo de treinamento e
diminuindo o valor econômico do processo (SOMMERVILLE, 2007). Modelos de processos de
software “podem ser usados para explicar diferentes abordagens para o desenvolvimento de
software” (SOMMERVILLE, 2007, p.43). Sommerville (2007) destaca três modelos que são
largamente utilizados na atualidade: Modelo em cascata, Desenvolvimento evolucionário e
Engenharia de software baseada em componentes.
“A existência de um processo de software não é garantia de que o software será entregue no
prazo, de que ele satisfaça às necessidades do cliente, ou de que ele exiba as características
técnicas que levarão a características de qualidade no longo prazo” (PRESSMAN, 2006, p.27). O
processo precisa ser avaliado, de modo a atender critérios básicos, para que uma engenharia de
software seja próspera (PRESSMAN, 2006). Segundo Pressman (2006) algumas abordagens têm
sido propostas: SCAMPI (Standard CMMI Assessment Method for Process Improvement), CBA
IPI (CMM – Based Appraisal for Internal Process Improvement), a norma SPICE (ISO/IEC
15504) e a ISO/IEC 9001:2000 para software. E para a avaliação de micro e pequenas
organizações foi criada a ISO/IEC 29110 (ABNT e SEBRAE, 2012).

3. Norma ABNT NBR ISO/IEC 29110

Enquanto a manufatura de um produto palpável permite a verificação da qualidade de forma fácil

e precisa, a criação de softwares não apresenta as mesmas características, de acordo com o
ABNT e SEBRAE (2012). No entanto, a qualidade é essencial para que as empresas se tornem
competitivas no mercado e, portanto, elas precisam estar atentas a qualidade do software que
entregam. Como “a qualidade de um produto de software está fortemente relacionada com a
qualidade do processo de produção seguido por quem o desenvolve” (ABNT e SEBRAE, 2012,
p. 16.), os processos de produção de softwares precisam seguir alguns padrões para obter mais
qualidade no produto final.
Para ABNT e SEBRAE (2012), os processos de software eram geralmente desenvolvidos para
grandes empresas, com possibilidade de investir e contratar pessoas para aplicá-los, o que
dificultava a utilização por parte das empresas de pequeno e médio porte.
Pensando nas pequenas e médias empresas, foi criado em 2005 o WG24, Working Group
nomeado Engenharia de Software – Perfis de Ciclo de Vida para Micro-Organizações. Este
grupo tem o propósito de criar normas ISO de engenharia de software para pequenas
organizações (ABNT e SEBRAE, 2012). Um dos trabalhos do grupo foi a série de normas
ABNT NBR ISO/IEC 29110, onde são descrito padrões de processos para que as pequenas
organizações alcancem a qualidade almejada (ABNT, 2012b).
A série de normas a ABNT NBR ISO/IEC 29110 é um guia para melhoria da qualidade,
desempenho e processos dos produtos de softwares, com foco para organizações de até 25
funcionários (ABNT, 2012b). A Figura 1 mostra a divisão das 5 partes: Visão geral, Estrutura
taxonomia, Guia de avaliação, Especificações de perfis, Guia de engenharia e gestão.

Figura 1 – Série ABNT NBR ISO/IEC 29110 (ABNT, 2012b)

A parte 1 contempla uma visão geral da norma, com os conceitos, características, requisitos,
documentações, conceitos de processo, ciclo de vida e normalização (ABNT e SEBRAE, 2012).
A parte 2 trata de termos comuns utilizados, definição para não haver ambiguidade nos termos e
esclarece as lógicas usadas na norma (ABNT e SEBRAE, 2012). Já a parte 3 detalha as diretrizes
para a avaliação de processos de software (ABNT e SEBRAE, 2012).
A parte 4 trata de Especificações de perfis, que foram documentados em dois grupos: O
Genérico, onde empresas que desenvolvem software genéricos se encaixam, e SE (System
Engineerig), onde empresas que desenvolvem softwares integrados são contempladas (ABNT e
SEBRAE, 2012). Dentro dos grupos de perfis, existem os perfis de Entrada, Básico,
Intermediário e Avançado. Porém, apenas o perfil Básico foi documentado até o momento, que
corresponde a parte 4-1 da norma (ABNT e SEBRAE, 2012).
E por último, a parte 5 é um guia para implantar os perfis dos grupos de perfis, o qual
descreve atividades, produtos gerados nas atividades e papeis relacionados aos processos de
elaboração de softwares (ABNT, 2012b). As atividades descritas nesta parte são divididas em
dois processos: Gerência de projeto e Implementação de software.

3.1. Processo de gerência de projeto

O processo de Gerência de Projeto tem por finalidade supervisionar o processo de

Implementação de Software, visando alcançar os propósitos do projeto, dentro do orçamento,
tempo e custo previsto (ABNT, 2012b). Nesse sentido, alguns objetivos precisam ser alcançados
para que este processo cumpra a sua finalidade. Os objetivos do processo de Gerência de Projeto
são relacionados no Quadro 1.

PM.O1 O Plano de Projeto para a execução do projeto é desenvolvido de acordo com a Declaração de Trabalho e
revisado e aceito pelo Cliente. As Tarefas e os Recursos necessários para completar o trabalho são dimensionados
e estimados.
PM.O2 O progresso do projeto é monitorado de acordo com o Plano de Projeto e registrado no Registro de Status
de Progresso. Ações para remediar problemas e desvios do plano são tomadas quando as metas do projeto não são
alcançadas. O encerramento do projeto é realizado para obter a aceitação do Cliente, documentada no Registro de
Aceitação.
PM.O3 As Solicitações de Mudança são tratadas através de seu recebimento e análise. Mudanças nos requisitos
de software são avaliadas quanto ao impacto do custo, prazo e impacto técnico.
PM.O4 Reuniões de revisão com a Equipe de Trabalho e o Cliente são realizadas. Aceitações são registradas e
controladas.
PM.O5 Riscos são identificados quando surgem e durante o desenvolvimento do Projeto.
PM.O6 Uma estratégia de controle de versão é estabelecida. Itens de configuração de software são identificados,
definidos e colocados em baselines. Modificações e liberações dos itens são controladas e disponibilizadas ao
Cliente e à Equipe de Trabalho. O armazenamento, manuseio e entrega dos itens são controlados.
PM.O7 A garantia de Qualidade de Software é realizada para assegurar que os processos e produtos de trabalho
cumprem o Plano do Projeto e com a Especificação de Requisitos.
Quadro 1 – Objetivos de Gerência de Projetos (ABNT, 2012b)

Algumas atividades são observadas em cada um dos processos detalhados pela norma ABNT
NBR ISO/IEC 29110-5 para atender os objetivos do processo. Cada atividade é um conjunto de
tarefas, que são ações ou recomendações para atingir um ou mais objetivos do processo (ABNT,
2012b). “Uma atividade do processo é o primeiro nível da decomposição do fluxo de trabalho do
processo e o segundo nível é uma tarefa” (ABNT, 2012b, p.3).
O processo de Gerência de Projeto possui as seguintes atividades: PM.1 Planejamento de
Projeto, PM.2 Execução do Plano de Projeto, PM.3 Avaliação e Controle do Projeto e PM.4
Encerramento do Projeto (ABNT, 2012b), como demonstra a Figura 2. Nas 4 atividades existem
26 tarefas, sendo que o PM.1 possui 15, o PM.2 6, o PM.3 3 e o PM.4 possui 2 tarefas (ABNT,
2012b).
 Figura 2 – Diagrama do Processo de Gerência de Projeto (ABNT, 2012b)

Para serem executadas as tarefas dos processos alguns produtos são requeridos, que são
denominados Produtos de Entrada. Da mesma forma, ao final da execução das tarefas são
gerados alguns produtos, que são chamados Produtos de Saída. Além destes, existem produtos
gerados e consumidos dentro do processo, os quais são denominados Produtos Internos (ABNT,
2012b). No processo de Gerência de Projetos os produtos de entrada são: Declaração de
Trabalho, Configuração de Software e Solicitação de Mudanças, enquanto que as saídas são:
Plano do Projeto, Registro de Aceitação, Repositório de Projeto, Registro de Reunião e
Configuração de Software (ABNT, 2012b). Os produtos internos são: Solicitação de Mudanças,
Registro de Correções, Registro de Reuniões, Registro de Verificações, Registro de Status do
Progresso, Registro de Backup do Repositório de Projeto (ABNT, 2012b).
Considerando que as tarefas precisam ser executadas por pessoas, a ABNT (2012b) definiu
alguns papéis para a ABNT NBR ISO/IEC 29110-5, porém deve-se lembrar que são papéis que
podem ser atribuídos a uma ou mais pessoas ou a mesma pessoa pode assumir vários papéis.
Para o processo de Gerência de Projeto os papéis são: Cliente, Gerente de Projetos, Líder
Técnico e Equipe de Trabalho (ABNT, 2012b).

3.2. Implementação de software

O processo de Implementação de Software pretende executar as atividades de análise, design,

construção, integração e testes para software de uma organização (ABNT, 2012b). E para isso
foram definidos os objetivos exibidos no Quadro 2.

SI.O1. Tarefas das atividades são realizadas através da execução do Plano do Projeto corrente.
SI.O2. Requisitos de software são definidos, analisados quanto ao corretismo e testabilidade, aprovados pelo
Cliente, incluídos em baselines e comunicados.
SI.O3. O projeto de arquitetura e seu detalhamento são elaborados e incluídos em baseline. Eles descrevem os
Componentes de Software e suas interfaces internas e externas. A consistência e rastreabilidade aos requisitos do
software são estabelecidas.
SI.O4. Componentes de Software definidos no projeto são desenvolvidos. Testes unitários são definidos e
realizados para verificar consistência com os requisitos e o projeto. A rastreabilidade é estabelecida entre os
requisitos e o projeto.
SI.O5. O software é produzido realizando-se a integração dos Componentes de Software e verificado através de
Casos de Teste e Procedimentos de Teste. Os resultados são armazenados no Relatório de Teste. Defeitos são
corrigidos e consistência e rastreabilidade do Projeto do Software são estabelecidas.
SI.O6. Uma Configuração de Software, que atende a Especificação de Requisitos como acordado com o Cliente,
a qual inclui documentação de usuário, manutenção e operação, é integrada, incluída em baseline e armazenada
no Repositório de Projeto. Necessidades de mudança na Configuração do Software são detectadas e solicitações
de mudanças relacionadas são iniciadas.
SI.O7. Tarefas de Verificação e Validação de todos os produtos de trabalho requeridos são realizadas usando os
critérios definidos para garantir a consistência entre produtos de entrada e saída em cada atividade. Defeitos são
identificados e corrigidos; registros são armazenados nos Resultados de Verificação/Validação.
Quadro 2 – Objetivos de Implementação de Software (ABNT, 2012b)

No processo de Implementação de software têm 6 atividades: SI.1 Iniciação da

Implementação de Software, SI.2 Análise de Requisitos de Software, SI.3 Projeto de Arquitetura
e Detalhamento do Software, SI.4 Construção de Software, SI.5 Integração e Testes do Software
e SI.6 Entrega do Produto (ABNT, 2012b). A Figura 3 ilustra essas atividades. Sendo que o SI.1
contém 2 tarefas, o SI.2 7, o SI.3 8, o SI.4 7, o SI.5 11 e o SI.6 6 tarefas, totalizando 41 tarefas.

Figura 3 – Diagrama do Processo de Implementação de Software (ABNT, 2012b)

Como no processo de Gerência de Projeto, o processo de Implementação de Software também

possui produtos de entrada, saída e internos. Plano de Projeto e Repositório de Projeto são os
produtos de entrada. Já os produtos Solicitações de Mudanças e Configuração de Software com
os itens: Especificação de Requisitos, Projeto de Software, Registro de Rastreabilidade,
Componentes do Software, Software, Casos e Procedimentos de Testes, Relatórios de Teste,
Guia de Operação do Produto, Documento do Usuário e Documento de Manutenção são os
produtos de saída. Os produtos internos são Resultado da Validação e Resultado da Verificação
(ABNT, 2012b).
Neste processo todos os papéis definidos na norma ABNT NBR ISO/IEC 29110-5 estão
envolvidos: Cliente, Analista, Designer, Programador, Gerente, Líder Técnico e Equipe de
Trabalho (ABNT, 2012b).

3.3. Avaliação

A etapa de avaliação de um processo consiste em confrontar a disciplina de processo de uma

empresa contra um processo de avaliação modelo, medindo a capacidade dos processos definidos
no modelo de referência (ISO/IEC, 2011). Ela pode ser executada quando uma empresa quer
avaliar o desempenho atual dos processos implementados ou quando quer encontrar
oportunidade para propor melhorias nos processos implantados (ISO/IEC, 2011).
Os detalhes para a avaliação do grupo de normas ISO/IEC 29110 estão descritas na ISO/IEC
15504-2 (ISO/IEC, 2011). Neste documento estão definidos os requisitos mínimos para garantir
a consistência e pontuação correta. Durante a avaliação são exigidas provas para fundamentar a
pontuação e a conformidade dos requisitos (ISO/IEC, 2011).
A avaliação precisa ser documentada e capaz de atender o objetivo da avaliação. Além disso,
precisa seguir alguns critérios para a condução da avaliação conforme a (ISO/IEC, 2011):
 Definir as entradas: escopo, finalidade, restrições e a identificação do modelo de
avaliação;
 Definir os papéis e responsabilidades fundamentais;
 Fornecer orientações para planejamento, coleta de dados, validação de dados, as
características do processo de classificação, e a comunicação dos resultados da avaliação;
 Registro das realizações da avaliação.

4. Melhoria de processo em pequenas empresas

Os processos de softwares têm a possibilidade de sofrer modificações, pois segundo a ABNT e

SEBRAE (2012), eles são o reflexo das organizações que estão em constante modificação.
Porém, ao fazer o emprego de uma metodologia, precisam ser analisadas as características e os
objetivos da empresa, uma vez que “o uso de um processo de software inadequado pode reduzir
a qualidade ou a utilidade do produto de software a ser desenvolvido e/ou aumentar os custos de
desenvolvimento.” (SOMMERVILLE, 2007, p.6).
Ao serem implantados novos processos, a empresa deve trata-los como um novo projeto
formal, beneficiando-se dos conceitos de gestão de projetos. Ou seja, estas ações devem ser
planejadas e monitoradas desde o início até a conclusão, verificando sempre o custo, o risco e o
comprometimento (ABNT e SEBRAE, 2012). Lembrando sempre de ter objetivos estabelecidos
para averiguar se o projeto está alcançando os resultados esperados (ABNT e SEBRAE, 2012).
Para auxiliar as pequenas organizações a ABNT e SEBRAE (2012) elaboram uma lista de
tópicos importantes a serem considerados na implementação de processos de software:
 Após estabelecer um objetivo, fazer as alterações necessárias nos processos e avaliar
se o resultado é satisfatório;
 Apresentar os benefícios reais na adoção de processos, visando o apoio da alta
gerência e dos envolvidos com o processo;
 Documentar os processos para evitar que existam processos diferentes para cada
projeto, trazendo benefícios na hora de implementar melhorias;
 Ter uma avaliação objetiva para medir o antes e o depois da implementação de uma
melhoria;
  Encontrar o equilíbrio entre formalização e praticidade, provendo que todos tenham o
conhecimento para o uso das documentações, porém mantendo a coerência para não
tornar a formalização como um processo sem sentido.

5. Trabalhos Correlatos

Trabalhos semelhantes foram encontrados durante a elaboração desta monografia. Um deles foi o
de Tavares et al.(2002), que relatou a experiência de melhoria de processos de software com base
no Capability Maturity Model (CMM) nível 2, em que foi aplicado um questionário para avaliar
os processos de uma empresa de desenvolvimento web. Além do questionário, foram elaborados
Diagramas de Fluxo de Dados, documentados os procedimentos e implantados em um projeto
piloto. O resultado deste trabalho foi a melhoria de alguns processos da empresa, visando
qualidade e agilidade.
Damke et al. (2008) elaborou um trabalho parecido com esta monografia, mas aplicado a
Gerência de Requisitos e fundamentado no programa de Melhoria de Processo do Software
Brasileiro (MPS.BR). Foi aplicado um questionário, nos moldes da Goal Question Metric
(GQM), para verificar os detalhes do processo. A aplicação se deu em uma pequena empresa de
softwares embarcados. Com os resultados e o conhecimento empírico dos autores foi gerado um
modelo de processo de engenharia de requisitos para sistemas embarcados.
Paiva e Andrade (2008) também utilizaram o GQM para avaliar os processos de
desenvolvimento de software em um órgão da Justiça. O estudo foi baseado nas normas ABNT
NBR ISO/IEC 12207, ISO/IEC 15504 e no MPS.BR, com a aplicação nos processos de Gerência
de Projeto e Gerência de Requisitos. Embora não tenha apontado sugestões de melhorias, foram
apontados os pontos fortes e pontos fracos de cada processo, com o intuito de servirem como
referência para iniciação de modificações nos processos.
Em outros países a melhoria de processos de software em pequenas e médias empresas
também podem ser observadas. Caldas e Zuluaga (2010), por exemplo, elaboraram um estudo
aprofundado que propôs melhorias de processo de uma pequena empresa colombiana. Eles
utilizaram o CMMI como fundamento da pesquisa, e também para elaborar um projeto de
melhoria e juntamente com um plano de ações detalhado.
Este trabalho, como a maioria dos relacionados nesta seção, sugere melhorias no processo de
software das empresas. No entanto o diferencial é que neste trabalho foi aplicado uma avaliação
baseada na série de normas ABNT NBR ISO/IEC 29110, além de serem elaborado fluxogramas
dos processos para melhor visualizar as sugestões propostas.

6. Avaliação e melhorias dos processos de software da Pamplona Alimentos S/A

Seguindo as orientações dos estudos apresentados até aqui, foi identificada a necessidade de
fazer uma avaliação antes de apontar as melhorias no processo de software da empresa Pamplona
Alimentos S/A. Sabendo que a empresa possui atualmente menos de 25 funcionários no setor de
TI envolvidas com o processo de software, decidiu-se usar a série de normas ABNT NBR
ISO/IEC 29110, ao qual propõe processos de software para pequenas organizações.

6.1. Metodologia da avaliação

Com base na ISO/IEC 29110-3, buscou-se fazer uma auto avaliação que representasse a
realidade do dia-a-dia do setor de TI para o desenvolvimento de software. Foram documentadas
as evidências e averiguados os processos de modo a ter uma avaliação idônea. Para que este
intuito fosse alcançado foi tomado o cuidado de levantar evidências objetivas e questioná-las
quanto a sua real existência. Foram identificados os pontos fracos do processo de software, a fim
de encontrar processos a serem melhorados. Restringiu-se em avaliar apenas o setor de TI para
os processos de Gerência de Projetos e Implementação de Software, excluindo assim, os
processos de Infraestrutura e Governança de TI.
A avaliação foi executada entre os dias 08 e 17 de outubro de 2014, nas dependências da
empresa. Durante as reuniões eram apresentadas as tarefas listadas na norma ABNT NBR
ISO/IEC 29110-5, seus produtos de entrada e saída, e os papéis responsabilizados em executá-
las. Após, todos os participantes opinavam, sendo que ao final tomava-se uma decisão de o
quanto a atividade era implementada, conforme os valores da norma ABNT NBR ISO/IEC
15504-2 que são mostrados na Tabela 1. Após a reunião o avaliador fazia uma verificação nas
evidências e na pontuação atribuída. Três programadores/analistas da equipe e mais o avaliador
faziam parte das reuniões.

Atributo Alcance
Não atingido 0 a 15%
Parcialmente atingido >15% a 50%
Largamente atingido >50% a 85%
Completamente atingido >85% a 100%
Tabela 1 – Valores de pontuação de atributos de processos (Adaptado de ABNT, 2008)

Para ilustrar como foram feitas as avaliações, a tarefa PM.1.1 que trata da revisão da
Declaração de Trabalho vai ser usada como exemplo. Para esta tarefa foi encontrado como
produto de entrada os chamados abertos pelos usuários no sistema Primus, e como produto de
saída os chamados adicionados a ferramenta Trello. Os papéis envolvidos nesta tarefa são o do
analista e do cliente. A implementação da tarefa foi definida como “Parcialmente atingida”, pois
parte dos chamados são revisados e passados para a ferramenta Trello, sendo que são revisados
apenas o propósito e os requisitos gerais, faltando serem revisados o escopo, os objetivos e a lista
de entregáveis. A avaliação das demais tarefas podem ser visualizadas nos apêndices.

6.2. Resultados da avaliação

A norma ABNT NBR ISO/IEC 29110-5 lista 67 tarefas dentro de 10 atividades. Destas 67
tarefas, foram diagnosticadas 7 tarefas executadas completamente, 5 largamente, 12 parcialmente
e 43 não executadas. A Tabela 2 traz mais detalhes dos resultados.

Atividade Completamente Largamente Parcialmente Não

PM.1 Planejamento de Projeto 1 1 2 11
PM.2 Plano de Execução do Projeto 0 1 1 4
PM.3 Avalição e Controle de Projeto 0 0 0 3
PM.4 Encerramento do Projeto 0 0 1 1
SI.1 Iniciação da Implementação de Software 1 1 0 0
SI.2 Análise de Requisitos de Software 1 0 2 4
SI.3 Projeto de Arquitetura e Detalhamento do Software 1 0 1 6
SI.4 Construção de Software 2 1 1 3
SI.5 Integração e Testes do Software 0 1 3 7
SI.6 Entrega do Produto 1 0 1 4
Tabela 2 – Soma de atributo de processo por atividade (Acervo do autor)

Para melhor análise dos dados, foram convertidos os resultados de Não atingido e
Completamente atingido para 0% e 100% respectivamente, e para o Parcialmente atingido e o
Largamente atingido foram usadas as médias entre os dois extremos de alcance, 32,5% e 67,5%
respectivamente. Na Figura 4, pode-se verificar que o Plano de Gerenciamento e o Encerramento
de Projeto têm 16% de suas tarefas executadas e o Plano de Execução de Projeto tem 17%,
enquanto a Avaliação e Controle de Projeto não é executada.
 Avaliação da Gerenciamento de Projeto
0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%

PM.1 Planejamento de Projeto 16%

PM.2 Plano de Execução do Projeto 17%

PM.3 Avalição e Controle de Projeto 0%

PM.4 Encerramento do Projeto 16%

% Executado

Figura 4 – Gráfico de avaliação da Gerenciamento de Projeto (acervo do autor)

A Figura 5 mostra o percentual da execução das atividades de Implementação de Software,

sendo que a Inicialização da Implementação é a atividade mais executada com 84%, a Análise de
Requisitos de Software com 24%, o Projeto de Arquitetura e Detalhamento do Software com
17%, a Construção de Software com 43%, a Atividade de Integração e Testes de Software
apenas com 15% e a Entrega do Produto com 22% de execução.

Avaliação da Implementação de Software

0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%

SI.1 Iniciação da Implementação de Software 84%

SI.2 Análise de Requisitos de Software 24%

SI.3 Projeto de Arquitetura e Detalhamento do Software 17%

SI.4 Construção de Software 43%

SI.5 Integração e Testes do Software 15%

SI.6 Entrega do Produto 22%

% Executado

Figura 5 – Gráfico de avaliação da Implementação de Software (acervo do autor)

 Outro dado interessante, é que em média, 25% das tarefas são executadas para todas as
atividades. Na divisão por processo, o Gerenciamento de Projetos conta com a média de 12% de
execução das atividades, e a Implementação de software conta com 34%. Os dados podem ser
visualizados na Figura 6.

Média de tarefas executadas

40%

35%
Atividade de
30% Implementaçã
o de Software;
25% 34%
Média Total de
20% Processos; 25%

15%

10% Atividades de
Gerenciamento
5% de projeto;
12%
0%
Figura 6 – Média de tarefas executadas (acervo do autor)

Aplicando a pontuação de atributo sobre o percentual executado de cada atividade,

identificamos dois pontos fracos do processo de software da empresa: Avaliação e controle de
Projeto e Integração e Testes do Software. No entanto, outros processos também estão muito
próximo de receberem o atributo de Não atingido, como é o caso do Planejamento de Projeto,
Plano de Execução do Projeto, Encerramento do Projeto e Projeto de Arquitetura e Detalhamento
do Software. Apenas um processos se destaca como Largamente atingido, a Iniciação de
Implementação de Software.

Atividade % Executado É implementado

PM.1 Planejamento de Projeto 16% Parcialmente
PM.2 Plano de Execução do Projeto 17% Parcialmente
PM.3 Avalição e Controle de Projeto 0% Não
PM.4 Encerramento do Projeto 16% Parcialmente
SI.1 Iniciação da Implementação de Software 84% Largamente
SI.2 Análise de Requisitos de Software 24% Parcialmente
SI.3 Projeto de Arquitetura e Detalhamento do Software 17% Parcialmente
SI.4 Construção de Software 43% Parcialmente
SI.5 Integração e Testes do Software 15% Não
SI.6 Entrega do Produto 22% Parcialmente
Tabela 3 – Pontuação de atributo para as atividades (Acervo do autor)

6.3. Sugestão de melhorias

Como visto na análise da avaliação a maioria dos processos da empresa é parcialmente ou não é
executada, por isso esse trabalho propõe melhorias a todos eles, procurando focar mais naqueles
que estão com o menor percentual.
 As melhorias serão apresentadas em fluxogramas, em que todos terão a mesma característica:
um fluxo visando a sequência de trabalhos a serem realizados em uma solicitação do usuário,
tanto para manutenção ou melhoria de software. Os itens em verde indicam alguma melhoria no
processo, em contra partida o restante são itens já executados. Se foram verificadas as
atribuições dos trabalhos nos fluxogramas, pode-se notar que não existem as competências de
Designer e de Líder de Equipe. No entanto, as atividades relativas a estes papéis foram elencadas
para o Analista e o Gerente de Projetos (GP), respectivamente.
Sabendo disso, o fluxograma da Figura 7 mostra a sugestão de ter um papel de GP para
atender a PM.1.1, que pretende revisar a declaração de trabalho. Atualmente essa atividade é
atendida parcialmente, pois não existe uma pessoa que tenha esta responsabilidade. Com o papel
de GP, uma pessoa vai desempenhar este trabalho, e assim pode-se conseguir revisar
completamente as declarações. Além desta tarefa, o GP irá identificar e inserir as tarefas no
chamado, assim como descrito na tarefa PM.1.3. Nesta sugestão será necessário fazer uma
alteração no sistema de chamados, a fim de atribuir a estrutura para armazenar as tarefas.

Figura 7 – Fluxograma de Planejamento de Projeto (acervo do autor)

No próximo passo o GP irá identificar a classificação do chamado. Caso trata-se de um erro,

ele deve definir com o cliente a data de entrega e registrar na ferramenta Trello, passando assim
o chamado para o processo de Implementação de Software. Caso contrário ele terá duas outras
opções: “projeto pequeno”, para solicitações que são brevemente atendidas e não necessitam um
alto nível de gerência; ou “projeto médio ou grande”, que são casos que necessitam de uma
atenção maior. Quando for um “projeto pequeno” o GP negocia com o cliente a data de entrega,
atendendo a tarefa PM.1.2. E quando for um “projeto médio ou grande”, o GP detalha o escopo e
os objetivos, contemplando assim a tarefa PM.1.12.
 Após realizadas as tarefas descritas anteriormente, o GP irá identificar os recursos e os riscos
para o projeto, previstos nas tarefas PM.1.5 e PM.1.9. Todas as melhorias sugeridas até agora
servirão como parte do Plano de Projeto, o qual será gerado pelo GP por meio de uma extração
de informações do sistema de chamados, procurando atender a tarefa PM.1.11. E com o Plano de
Projeto gerado, ele poderá obter a aprovação e a aceitação, assim como requerido nas tarefas
PM.1.13 e PM.1.14.
Como pode ser visto na Figura 7, para o restante das tarefas de Planejamento de Projeto não
foram sugeridas melhorias. A tarefa PM.1.4, que trata de estabelecer a duração estimada das
tarefas, já é atendida completamente, e por isso não necessita de melhoria. A tarefa PM.1.6, que
solicita estabelecer a composição da equipe, atualmente é largamente atendida, e optou-se por
não fazer sugestões. A tarefa que prevê a estimativa de tempo das tarefas, PM.1.7, também não
foi proposta melhoria e está como parcialmente por não levar em conta os recursos, mas como o
GP terá estas informações, ele poderá levar em consideração os recursos para estimar as tarefas e
gerar um cronograma. A tarefa PM.1.8, não se aplica no momento, porque os custos dos projetos
são absorvidos pelo setor de TI, não tendo clientes e não sendo repassados ao setor responsável.
Além disso, entendeu-se que as tarefas PM.1.10 e PM.1.15, que tratam de documentar a
estratégia de controle de versão e estabelecer o repositório de projeto respectivamente,
necessitam que o setor tenha uma maturidade maior na atividade para alcançá-lo.
Para o Plano de Execução de Projeto, melhorias na tarefa PM.2.1 são sugeridas nos passos em
que a equipe marca como executada as tarefas e o GP gera e verifica o status do projeto. Na
PM.2.4, o GP deverá fazer reuniões com o cliente e documentar em ata as decisões. A PM.2.3,
que trata de reuniões com a equipe, atualmente é contemplada largamente segundo a avaliação. E
para a PM.2.2, o GP deve verificar as solicitações de mudanças vindas do cliente ou da equipe, e
alterar o projeto caso necessário. Para as tarefas PM.2.5 e PM.2.6, que abordam sobre fazer
backups conforme a estratégia de controle de versão e recuperar estes backups, acredita-se que a
melhor opção é aguardar a maturidade das tarefas desta atividade antes de implantá-lo. Todas
estas melhorias podem ser vistas na Figura 8.

Figura 8 – Fluxograma de Plano de Execução de Projeto (acervo do autor)

Na atividade de Avaliação e Controle de Projeto a avaliação identificou que nenhum processo

é realizado, então as melhorias são sugeridas para todas as tarefas. Na PM.3.1 o GP terá que
gerar o status do progresso e comparar os dados de tarefas realizadas versus planejadas, tempo
real versus cronograma, riscos reais versus identificados previamente. Se problemas são
identificados durante o projeto, o GP estabelece ações e reúne os envolvidos para comunicar a
decisão e documenta em ata, atendendo a tarefa PM.3.2. Se houverem mudanças no projeto, o
GP deverá fazer modificações em projetos para atender a tarefa PM.3.3. Mais detalhes sobre esta
atividade na Figura 9.

Figura 9 – Fluxograma de Avaliação e Controle de Projeto (acervo do autor)

Para o processo de Encerramento de Projeto foram levantadas melhorias na tarefa PM.4.1,

atribuir ao GP a responsabilidade de gerar a documentação de Configuração de Software e
entregá-la para o cliente, e este deve homologar os chamados caso atendam o combinado, sendo
que esta homologação deve ser através de um formulário. Outra melhoria que não é requisito da
norma mas é interessante no sentido de gerar conhecimento para novos projetos, é a identificação
de lições aprendidas. Contudo, o PM.4.2 não foi proposto, pois para manter um repositório de
projetos entende-se que o setor precisa mais maturidade no processo de Gerenciamento de
Projeto. A Figura 10 demonstra detalhes do processo.

Figura 10 – Fluxograma de Encerramento do Projeto (acervo do autor)

No processo de Iniciação da Implementação de Software não foram encontradas muitas

oportunidades para melhorar, visto que é o único processo que foi avaliado como largamente
atingido, onde o SI.1.1 obteve uma avaliação de largamente, enquanto SI.1.2 obteve
completamente. Porém, para que o SI.1.1 atinja a completude da execução, o Plano de Projeto
deve ser gerado e usado como base para o entendimento dos envolvidos. E, com as mudanças
feitas nos processos anteriores, este documento já é gerado, então basta apenas ser utilizado nesta
fase para melhorar a tarefa. Um detalhe que não pode ser deixado de lado é a distribuição das
atividades dos processos de Implementação de Software: SI.2.1, SI.3.1, SI.4.1, SI.5.1 e SI.6.1.
Eles foram resumidos em apenas uma tarefa na atividade de Iniciação da Implementação de
Software, porque acredita-se que irá agilizar o processo, fazendo de uma única vez com todos os
envolvidos, conforme exibido na Figura 11.
 Figura 11 – Fluxograma de Iniciação da Implementação de Software (acervo do autor)

Como visto no processo anterior, a tarefa de SI.2.1 está sendo atendida naquele processo,
portanto nesta atividade não precisa ser implementada. Mas o restante das tarefas precisam ser
melhoradas. É o caso das SI.2.2 e SI.2.3, em que o Analista precisa especificar, validar e
registrar os requisitos. E ainda, nos casos de “projetos de médio ou grande”, ele terá que validar
com o cliente antes de registrar os requisitos para atender a tarefa SI.2.4. A Documentação de
Usuário de Software, tarefas SI.2.5 e SI.2.6, não serão elaboradas neste momento, mas sim nas
tarefas SI.5.9 e SI.5.10. A tarefa SI.2.7 é parcialmente atendida quando incorporados os
requisitos aos chamados, levando em consideração que o GP irá gerar a Configuração de
Software através de informações do sistema de chamados. O fluxograma da atividade de Análise
de Requisitos de Software é detalhado na Figura 12.

Figura 12 – Fluxograma de Análise de Requisitos de Software (acervo do autor)

Quanto à atividade de Projeto de Arquitetura e Detalhamento de Software pode-se perceber

várias melhorias sugeridas no fluxograma da Figura 13. Uma delas é uso de documentação
formal de especificação de requisitos, visando atender completamente a tarefa SI.3.2, que
atualmente foi avaliada como parcialmente atendida. Para atender em partes as tarefas SI.3.3 e
SI.3.4, sugerimos detalhar tecnicamente o que deve ser feito, além de criar um documento com
padrões de desenvolvimento para ser usado pelos programadores. Porém, tem-se ciência que este
procedimento não gera um projeto de software, mas devido a estratégia da empresa de manter
uma equipe de manutenção de software interna para ter mais agilidade no desenvolvimento,
acredita-se que esta é a melhor alternativa.

Figura 13 – Fluxograma de Projeto de Arquitetura e Detalhamento de Software (acervo do autor)

Para as questões abordadas pelas atividades SI.3.5 e SI.3.6, a sugestão elaborada foi a de que
o analista crie casos de testes e procedimentos de testes, juntamente com a criação de um
documento com padrões de testes, onde deverão ser descritos os testes padrões quando
determinada situação for encontrada como, por exemplo, validações de data. Esta é uma
recomendação que deveria estar implícita nos processos de implementação, porém, em alguns
casos o teste não é feito pelo programador, e por isso optou-se por documentá-la. Os artefatos
gerados pelo analista nesta etapa devem ser validados com outro analista a fim de fazer uma
verificação antes passar para a próxima atividade. Para as tarefas SI.3.7 e SI.3.8 não foram
sugeridas melhorias porque neste momento acredita-se que o setor precisa ter mais maturidade
em outras tarefas para então ter o registro de rastreabilidade e repositório de projeto.
Ao obter o entendimento da especificação técnica com a documentação gerada pelo analista,
espera-se que a tarefa SI.4.2 seja executada completamente, ao invés de largamente como foi
avaliada. Os componentes de software são gerados, por isso a tarefa SI.4.3 é completamente
atendida.
Os testes de unidade não são realizados atualmente e, em um ambiente estruturado, a
realização deste tipo de teste de forma automatizada demandaria muito trabalho, assim
dependeria do programador testar todas as possibilidades de um trecho de código, o que parece
ser inviável para o momento, se considerado que existem rotinas com baixa coesão, ou seja,
possuem diversas responsabilidades. Sabendo da dificuldade e ao mesmo tempo da importância
deste tipo de teste, para as tarefas SI.4.4 e SI.4.5 é recomendado que o programador faça-as
porém, não foi incorporado no fluxo padrão para a atividade de Construção de Software.
Para ter uma execução melhor da atividade SI.4.6, sugere-se que o programador insira o
requisito no componente de software através de comentários, como forma de rastreabilidade.
Para a tarefa SI.4.7 o processo não muda, o desenvolvedor deve vincular os objetos alterados no
chamado. Porém, como o GP irá gerar a Configuração de Software através do sistema de
chamados, a tarefa terá uma pontuação mais positiva em relação a atual por este aspecto. A
Figura 14 detalha melhor as tarefas sugeridas na atividade de Construção de Software.

Figura 14 – Fluxograma de Construção de Software (acervo do autor)

O fluxograma da Figura 15 detalha o processo de Integração e Testes de Software. Esta é uma

das atividades que é pouco executada e que é de fundamental importância para a qualidade do
software. Por isso foram sugeridas melhorias nas tarefas SI.5.2, SI.5.3, SI.5.4 e SI.5.5, em que o
analista obtém entendimento e testa o software com base nos Casos de Testes e Procedimento de
Testes. Se alterações nos Casos de Teste e Procedimento de Testes são necessárias, o analista
deverá fazer. Nesta atividade são previstos os testes de Alto Nível, de Integração e Regressão,
porém apenas o teste de Alto Nível espera-se que será realizado na íntegra, enquanto que o
restante será executado parcialmente, principalmente pelo fato de não ter um especialista para
executá-los. Em um primeiro momento teremos poucos ganhos na qualidade aplicando estas
melhorias, por tanto fica evidente que é necessário ter um profissional dedicado à qualidade de
software para alcançar níveis maiores de qualidade. Uma alternativa pode ser o uso de uma
ferramenta automatizada de software capaz de executar rotinas de testes que este profissional
faria.
 Figura 15 – Integração e Testes de Software (acervo do autor)

Após a fase de testes, o desenvolvedor elabora o Guia de Operação de Produto e a

Documentação de Usuário e o analista verifica e aprova, buscando desta forma atender as tarefas
SI.5.7, SI.5.8, SI.5.9 e SI.5.10. O registro dos passos anteriores no sistema de chamado servirão
para a execução da tarefa SI.5.11, que é a incorporação dos documentos desta atividade na
Configuração de Software. Para a tarefa SI.5.6, que versa sobre a atualização do registro de
rastreabilidade, não é realizada sugestão, por compreender que é preciso amadurecer outras
tarefas antes de executá-la.
As sugestões de mudanças para a Entrega do Produto podem ser verificadas na Figura 16.
Nela podemos ver que o GP tem a responsabilidade de gerar e entender a Configuração de
Software através do sistema de chamados, executando assim a tarefa SI.6.2. Em seguida ele
atualiza e busca aprovação para a Documentação de Manutenção através de normas e padrões de
desenvolvimento empregados, cumprindo as tarefas SI.6.3 e SI.6.4. E por fim, o GP entrega a
Configuração de Software para o cliente, encerrando o projeto conforme a tarefa SI.6.6. A única
tarefa que não foi contemplada é a SI.6.5, que diz respeito a incorporação da Documentação de
Manutenção na Configuração de Software. Neste caso acredita-se que outras tarefas de
Implementação de Software têm importância maior no momento atual do setor.

Figura 16 – Entrega do Produto (acervo do autor)

Com a implementação das sugestões a empresa poderá atingir largamente a maioria das
atividades, sendo que apenas a atividade de Encerramento de Projeto ficará como parcialmente
atingida, e as atividades de Iniciação da Implementação de Software e Integração e Testes de
Software serão completamente atingidas. Numericamente a empresa passaria da média de 25%
das tarefas atualmente implementadas para 71% com as sugestões. A atividade de
Gerenciamento de Projeto terá um aumento de 54% de implementação das tarefas, de 12%
atualmente para 66% com as melhorias sugeridas. Enquanto que a atividade de Implementação
de Software terá 41% de aumento nas tarefas implementadas, passando de 34% para 75%. As
sugestões não atenderam 100% das tarefas das norma, porque algumas delas não condizem com
a realidade da empresa, ou entende-se que é necessário mais maturidade no processo para que
então possam ser inseridas.
7. Considerações Finais

Este trabalho foi importante para avaliar o processo do setor de TI da empresa Pamplona
Alimentos S/A, conhecer em detalhes as suas atividades, e elaborar melhorias que ela possa
implantar para trazer benefícios a qualidade do software desenvolvido. Pôde-se conhecer a
Norma ABNT NBR ISO/IEC 29110 e todas as suas partes, principalmente a parte 3 e 5 que
tratam de Guia de avaliação e Guia de engenharia e gestão: Grupo perfil genérico: Perfil Básico,
respectivamente.
Os resultados da avaliação mostram que em média 25% das tarefas das atividades descritas na
ABNT NBR ISO/IEC 29110 são executadas, o que demonstra que processos podem ser
melhorados para garantir mais qualidade no processo de software da empresa. Também puderam
ser observados que dois processos foram classificados como não implementados, e estes
precisam ter mais atenção quando melhorias forem implementadas. As sugestões de melhorias
mostraram que pode-se ter um aumento médio de 46% nas implementações dos processos de
software da empresa.
Pessoas que participaram da avaliação relatam que viram a necessidade de melhorar os fluxo
dos processos, pois foram identificados muitos pontos falhos. Embora que algumas tarefas já são
incorporadas do processo atual, porém, são informais, dificultando assim o monitoramento. Mas
alguns pontos importantes podem ser facilmente incorporados no processo de software da
empresa com pouco esforço e um resultado significativo, tomando cuidado com o excesso de
burocratização. Perceberam ainda que a equipe necessita de ampliação de 20% a 30% para
atender as demandas atuais juntamente com as melhorias sugeridas. Sobre a norma ABNT NBR
ISO/IEC 29110 estas pessoas pensam que diversos artefatos dela não se enquadram na realidade
da empresa, por aumentar consideravelmente a burocracia. Em relação a avaliação, algumas
verificações se tornaram confusas em relação aos artefatos esperados e o detalhamento desejado
nos mesmos. Também relatam que o tempo dedicado para a avaliação foi curto diante da
complexidade para entendimento de cada tarefa.
Com isso conclui-se que, com algumas adaptações, a norma ABNT NBR ISO/IEC 29110
mostrou-se viável para pequenas organizações que pretendem melhorar a qualidade dos seus
processos de software, principalmente por focar apenas em Planejamento de Projeto e
Implementação de Software, processos principais para equipes de desenvolvimento.
Para trabalhos futuros recomenda-se uma nova avaliação dos processos da empresa após a
implementação das solicitações sugeridas, a fim de validar as sugestões propostas e com um
prazo maior para permitir que os avaliadores possam aprofundar mais nos requisitos da norma
ABNT NBR ISO/IEC 29110.

Referências

ABNT - Associação Brasileira de Normas Técnicas. Tecnologia da Informação – Avaliação de

processo. Parte 2: Realização de uma avaliação. 1ª ed. 2008.

ABNT - Associação Brasileira de Normas Técnicas. Engenharia de Software – Perfis de ciclo

de vida para micro-organizações (VSEs). Parte 4-1: Especificações de perfil: Grupo Perfil
Genérico. 1ª ed. 2012a.

ABNT - Associação Brasileira de Normas Técnicas. Engenharia de Software – Perfis de ciclo

de vida para micro-organizações (VSEs). Parte 5-1-2: Guia de engenharia e gestão: Grupo
Perfil Genérico: Perfil básico. 1ª ed. 2012b.

ABNT - Associação Brasileira de Normas Técnicas, SEBRAE – Serviço Brasileiro de Apoio às

Micro e Pequenas Empresas. Guia de implementação: Desenvolvimento de softwares para
pequenas organizações; Série ABNT NBR ISO/IEC 29110. 2012. Disponível em:
<http://portalmpe.abnt.org.br/index.php/biblioteca-de-arquivos/18-biblioteca-digital/guias/90-
guia-de-implementacao-desenvolvimento-de-software-para-pequenas-organizacoes > Acesso
em: 26 out. 2014.

CALDAS, Héctor Iván Alvares; ZULUAGA, Juan Gonzalo Cárcamo. Propuesta de

mejoramento del proceso software para una empresa de soluciones integrales de ingeníeria
de mantenimiento. Medellín, 2010. Disponível em:<
https://repository.eafit.edu.co/bitstream/handle/10784/407/HectorIvan_AlvarezCaldas_2010.pdf?
sequence=3> Acesso em: 26 out. 2014.

DAMKE, Erica Daniele; MORAES, Patrícia Freitas de; MELO, Claudia de Oliveira. Avaliação
do processo de Gerenciamento e Engenharia de Requisitos em MPEs de Sistemas
Embarcados: um estudo de caso. Rezende, 2008. Disponível em:
<http://www.aedb.br/seget/artigos08/566_566_Artigo_Seget_14-08-2008.pdf.> Acesso em: 06
jul. 2014.

ISO/IEC - International Organization for Standardization / International Electrotechnical

Commission, Software engineering - Lifecycle profiles for Very Small Entities (VSEs) - Part
3: Assessment guide. 1ª ed. 2011.

PAIVA, Igor Takaki; ANDRADE, Edméia Leonor Pereira de. Avaliação do processo de
desenvolvimento de software em um Órgão da Justiça. Rezende, 2008. Disponível em:
<http://www.aedb.br/seget/artigos08/394_Artigo_SEGeT.pdf>. Acesso em: 06 jul. 2014.

PRESSMAN, Roger. S. Engenharia de software. 6. ed. São Paulo: Bookman, 2006.

SOMMERVILLE, Ian. Engenharia de software. 8ª ed. São Paulo: Pearson Addison-Wesley,

2007.

TAVARES, Débora P. Diniz; FABBRI, Sandra C. P. Ferraz; SANCHES, Rosely. Diagnóstico,

Definição e Melhoria do Processo de Software: um Estudo de Caso. Gramado, 2002.
Disponível em: < http://www.lbd.dcc.ufmg.br/colecoes/sbqs/2002/016.pdf> Acesso em: 26 out.
2014.
 APÊNDICES

APÊNDICE A – Avaliação das tarefas de Gerência de Projeto.

ISO 29110 Perfil Básico TI da Pamplona Alimentos S/A

Atividade ID Lista de tarefas Produtos de Entrada Produtos de Saída Papé É implementado Produtos de Produtos de Papéis Comentários e Observações
s de is Entrada Saída
gerencia
mento de
projeto
PM.1 PM. Revisar a declaração de trabalho Declaração de Trabalho Declaração de Trabalho PM Parcialmente Chamados Chamados ANA Parte dos chamados são revisados e passados para a ferramenta Trello.
Planejam 1.1 [Revisada] abertos pelos adicionados no CUS O propósito e os requisitos gerais geralmente são definidos e revisados.
ento de TL usuários no Trello Porém o escopo, objetivos, e entregáveis não são nem definidos,
Projeto sistema Primus impossibilitando a revisão.
PM. Definir com o cliente as instruções de Entrega para Declaração de Trabalho Plano de Projeto PM Não Chamados Não existem ANA As datas de liberação algumas vezes são combinadas com os clientes e
1.2 cada um dos entregáveis especificados na [Revisada] - Instruções de entrega adicionados no documentos CUS adicionadas nos chamados no sistema Primus. O restante das atividades
Declaração de Trabalho CUS Trello para levantamento das instruções de entregas não são executadas.
PM. Identificar as tarefas específicas a serem realizadas Declaração de Trabalho Plano de Projeto PM Não Não existem Não existem ANA Algumas tarefas são identificadas e adicionadas no chamado no
1.3 para produzir os entregáveis e seus componentes [Revisada] - Tarefas documentos documentos sistema Primus, mas apenas no que diz respeito ao desenvolvimento.
de software identificados na Declaração de TL Os componentes, as tarefas de SI, a validação, verificação e revisão das
Trabalho. Incluir tarefas do processo de SI, tarefas não são executadas.
juntamente com a validação, verificação e revisão
das tarefas do cliente e da Equipe de Trabalho,
para garantir a qualidade dos produtos de trabalho.
Identificar as tarefas para realizar as instruções de
Entrega. Documentar as Tarefas.
PM. Estabelecer a Duração Estimada para realizar cada Plano de Projeto Plano de Projeto PM Completamente Não existem Chamados ANA Sempre usado estimativa de horas quando passado as tarefas para o
1.4 tarefa. - Tarefas - Duração Estimada documentos com estimativa desenvolvimento. Inserido a quantidade de horas no chamado do
TL na ferramenta sistema Primus.
primus
PM. Identificar e documentar os recursos: humanos, Declaração de Trabalho Plano de Projeto PM Não Chamados Não existem Não identificado.
1.5 materiais, equipamentos e ferramentas, normas, - recursos abertos pelos documentos
incluindo o treinamento necessário da Equipe de TL usuários no
Trabalho para executar o projeto. Indicar no sistema Primus
calendário quando os recursos e o treinamento são
necessários.
PM. Estabelecer a Composição da Equipe de Trabalho, Plano de Projeto Plano de Projeto PM Largamente Não existem Documentação TL São definido as pessoas e responsabilidades de maneira informal. Ou
1.6 atribuindo papéis e responsabilidades de acordo - recursos - Composição do grupo de documentos informal seja, a pessoa fica sabendo que irá compor uma equipe de trabalho
com os Recursos. trabalho TL através de uma conversa. Porém, não existe documento que comprove
o fato.
PM. Atribuir datas de início e conclusão estimadas para Plano de Projeto Plano de Projeto PM Parcialmente Chamados Chamados ANA Os chamados recebem data de início e termino no sistema Primus. Mas
1.7 cada uma das tarefas, a fim de criar um - Tarefas - Cronograma das tarefas TL abertos pelos com data não são levados em conta todos os recursos, apenas os recursos
Cronograma das Tarefas do Projeto, tendo em - Duração estimada do projeto usuários no prevista de humanos. A sequência e a dependência das tarefas não são verificadas.
conta os recursos atribuídos, sequência e - Composição do grupo sistema Primus início e O Cronograma não é gerado.
dependência das tarefas. de trabalho termino
PM. Calcular e documentar a Estimativa de Esforço e o Plano de projeto Plano de Projeto PM Não Documentação Não existem Não identificado
1.8 Custo do projeto - Composição do grupo - Estimativa de esforço e informal documentos
de trabalho custo
- Recursos
PM. Identificar e documentar os riscos que podem Todos os elementos Tarefas do projeto PM Não Chamados do Não existem Não identificado
1.9 afetar o projeto. definidos anteriormente TL sistema Primus documentos
com todos os
 elementos

PM. Documentar a Estratégia de Controle de versão Plano de Projeto PM Não Não existem Não identificado
1.10 para o projeto. - Estratégia de controle de TL documentos
versão
PM. Gerar o Plano de Projeto integrando os elementos Todos os elementos Plano de projeto PM Não Chamados Não existem Não identificado
1.11 anteriormente identificados e documentados. definidos anteriormente - Tarefas com todos os documentos
- Duração estimada elementos
- Recursos preenchidos
- Composição do grupo de
trabalho
- Cronograma das tarefas
do projeto
- Estimativa de esforço e
custo
- Identificação dos riscos do
projeto
- Estratégia de controle de
versão
- Instruções de entrega
PM. Incluir a descrição do produto, escopo, objetivos e Declaração de trabalho Plano de projeto PM Não Não existem Não existem A descrição do produto está no chamado que o usuário abre, porém não
1.12 entregáveis no Plano de Projeto. - Descrição do Produto - Descrição do produto documentos documentos é inserido em um plano de projeto.
- Escopo - Escopo TL
- Objetivos - Objetivos
- Entregas - Entregas
PM. Verificar e obter aprovação do Plano de Projeto. Plano de projeto Resultado de Verificações PM Não Não existem Não existem Não identificado
1.13 Plano de Projeto documentos documentos
Verificar se todos os elementos do Plano de [verificado] TL
Projeto são viáveis e consistentes. Os resultados
encontrados são documentados em Resultados da
Verificação e correções são feitas até o documento
ser aprovado pelo gerente.
PM. Revisar e aceitar o Plano de Projeto. Plano de Projeto Registro de reunião de PM Não Não existem Não existem A revisão do projeto não é feita, assim como a aprovação também não
1.14 [cerificado] projeto [aprovação] documentos documentos é feita. Não existe documentação de projeto.
Cliente revê e aceita o Plano de Projeto, CUS
certificando-se que os elementos do Plano de
Projeto correspondem à Declaração de Trabalho.
PM. Estabelecer o repositório do projeto usando a Estratégia de controle de Repositório do projeto PM Não Não existem Não existem Não existe repositório para documentação de projeto.
1.15 Estratégia de Controle de Versão. versão documentos documentos
TL
PM.2 PM. Monitorar a execução do Plano de Projeto e Plano de projeto Relatório de Status do PM Parcialmente Não existem Apontamento WT Os desenvolvedores apontam no chamado as atividades que realizaram.
Plano de 2.1 registrar o realizado no Registro de Status de progresso documentos de chamados Porém, os projetos não são monitorados.
Execução Progresso. TL no sistema
do Primus
Projeto WT
PM. Analisar e avaliar a Solicitação de Mudança para o Solicitação de mudança Solicitação de mudança PM Não Atualização Não existem As solicitações de mudanças não são analisadas quanto a custo,
2.2 custo, cronograma e impacto técnico. [iniciado] [avaliado] dos chamados documentos cronograma e impacto técnico. Algumas vezes é analisado
TL superficialmente quanto irá atrasar o projeto, mas sem registrar no
A solicitação de Mudança pode ser iniciada Plano de projeto Plano de projeto plano de projeto.
exatamente pelo Cliente ou internamente pela [atualizado]
Equipe de Trabalho. Atualizar o Plano de Projeto,
se estas mudanças não alterarem o que foi
acordado com o Cliente.

Uma Solicitação de Mudança que altere o que foi

acordado precisa ser negociada por ambas as
 partes (ver PM 2.4).
PM. Conduzir reuniões de revisão com a Equipe de Plano de projeto Registro de Reunião PM Largamente Ata de Ata de ANA Em reuniões semanais são revisadas as atividades da equipe,
2.3 Trabalho, identificar problemas, rever o status dos [atualizado] reuniões reuniões TL WT reportados problemas e registradas em ata todos os itens anteriores
riscos, registrar as decisões e monitorá-las até sua Relatório de Status do TL semanais semanais juntamente com as decisões tomadas. O monitoramento é realizado
conclusão. progresso sobre a ata documentada da semana anterior. Os riscos não são levados
WT em consideração.
Registro de correção
Registro reunião
PM. Conduzir reuniões de revisão com o Cliente, Plano de Projeto Registro de Reunião PM Não Não existem Não existem Algumas reuniões são com o cliente, mas em geral é apenas para
2.4 registar suas decisões e monitorá-las até sua [atualizado] documentos documentos definir novos desenvolvimentos ou cobrar pendências.
conclusão. Registro do Status CUS
do Progresso Solicitação de Mudança
Uma Solicitação de Mudança iniciada pelo Cliente [aceita] TL
ou iniciada pela Equipe de Trabalho, que afeta o Solicitação de
Cliente, precisa ser negociada para alcançar a Mudança [avaliada] Plano de Projeto WT
aceitação de ambas as partes. [atualizado]
Registro de Reunião
Se necessário atualizar o Plano de Projeto segundo
o novo acordo com o Cliente.
PM. Fazer Backups de acordo com a Estratégia de Estratégia de controle de Backup do repositório do PM Não Não existem Não existem Não existe repositório para documentação de projeto.
2.5 Controle de Versão. versão projeto documentos documentos
PM. Fazer recuperação do Repositório do Projeto Backup do repositório do Repositório do PM Não Não existem Não existem Não existe repositório para documentação de projeto.
2.6 usando o Backup do Repositório do Projeto, se projeto projeto[recuperado] documentos documentos
necessário.
PM.3 PM. Avaliar o progresso do projeto com respeito ao Plano de projeto Registro de status do PM Não Não existem Não existem Nenhuma das avaliações são realizadas.
Avalição 3.1 Plano de Projeto, comparando: progresso [avaliado] documentos documentos
e Registro de status do TL
Controle - tarefas realizadas versus planejadas; progresso
de Projeto - resultados reais versus objetivos do projeto WT
estabelecido;
- alocação de recursos realizada versus planejada;
- custo real versus estimativas de orçamento;
- tempo real versus cronograma planejado;
- riscos reais versus identificados previamente.
PM. Estabelecer ações para corrigir desvios ou Registro de status do Registro de correção PM Não Não existem Não existem Não são estabelecidas as ações para possíveis problemas ou desvios.
3.2 problemas e riscos identificados, no que tange à progresso [avaliado] documentos documentos
realização do plano, conforme necessário, TL
documentá-las no Registro de Correção e
monitorá-las até sua conclusão. WT
PM. Identificar mudanças nos requisitos e/ou no Pano Registro de status do Solicitação de mudança PM Não Não existem Não existem Não são controladas mudanças no projeto.
3.3 de Projeto para enfrentar desvios significativos, progresso [avaliado] [iniciada] documentos documentos
riscos potenciais ou problemas relacionados com a TL
realização do plano, documentá-las em Solicitação
de Mudanças e monitorá-las até sua conclusão. WT
PM.4 PM. Formalizar a conclusão do projeto de acordo com Plano de projeto Registro de Aceitação PM Parcialmente Não existem Reunião com ANA É pego o aceite de usuários através de conversas e treinando-os. Os
Encerram 4.1 as instruções de Entrega estabelecida no Plano de - Instruções de entrega documentos os usuários e CUS chamados são homologados pelos clientes quando a solicitação foi
ento do Projeto, fornecendo apoio para aceitação e Configuração de software CUS homologação atendida. A configuração de software é entregue apenas com a
Projeto recebendo o Registro de Aceitação assinado. Configuração de [aceito] dos chamados documentação de usuário e o software.
software [entregue]
PM. Atualizar o Repositório de Projeto. Configuração de Repositório de projeto PM Não Reunião com Não existem Não existe repositório para documentação de projeto.
4.2 software [aceita] [atualizado] os usuários e documentos
homologação
Repositório de projeto dos chamados
APÊNDICE B – Avaliação das tarefas de Implementação de Software.
ISO 29110 Perfil Básico TI da Pamplona Alimentos S/A

Atividade ID Lista de tarefas Produtos de Entrada Produtos de Saída Papé É implementado Produtos de Produtos de Papéis Comentários e Observações
s de is Entrada Saída
gerencia
mento de
projeto
SI.1 SI Revisar o Plano de Projeto atual com os membros Plano de projeto Plano de projeto [revisado] PM Largamente Não existe Não existe ANA São envolvidos todos os membros com uma conversa que tem por
Iniciação .1.1 da Equipe de Trabalho a fim de alcançar um documentação documentação WT objetivo entender o projeto. Porém o plano de projeto não é
da entendimento comum e obter seu envolvimento TL documentado.
Implemen com o projeto.
tação de WT
Software SI. Estabelecer ou atualizar o ambiente de trabalho. Plano de projeto TL Completamente Não existe É dado o ambiente de trabalho para o desenvolvedor com tudo
1.2 [revisado] documentação instalado.
WT
SI.2 SI. Atribuir tarefas aos membros da Equipe de Plano de projeto TL Completamente Não existe TL É atribuído a responsabilidade de análise ao analista ou ao
Análise 2.1 Trabalho, de acordo com o seu papel, com base no [revisado] documentação ANA desenvolvedor, dependendo do caso.
de atual Plano de Projeto. - Tarefas WT WT
Requisito SI. Documentar ou atualizar a Especificação de Plano de projeto Especificação de requisitos AN Parcialmente Não existe Documentação ANA Quando são mais complexos os desenvolvimentos são feitas
s de 2.2 Requisitos. - Descrição do produto documentação informal especificações mais detalhadas. A viabilidade técnica é feita.
Software CUS Informalmente é definido o escopo. Não existem documentos de
Identificar e consultar fontes de informação requisitos. As fontes de informação são consultadas.
(cliente, usuário, sistemas anteriores, documentos,
etc.) de modo a obter novos requisitos.

Analisar os requisitos identificados para

determinar o escopo e a viabilidade.

Gerar ou atualizar a Especificação de Requisitos.

SI. Verificar e obter a aprovação da Especificação de Especificação de Verificação de resultados AN Não Documentação Não existe Não existe documentação para especificação de requisitos, por isso não
2.3 Requisitos. requisitos informal documentação podem ser aprovados.
Especificação de requisitos TL
Verificar a correção e a testabilidade da Plano de Projeto [verificado]
Especificação de Requisitos e a sua consistência - Descrição do produto
com a Descrição do Produto. Adicionalmente, Solicitação de mudança
verificar se os requisitos estão completos, sem [iniciada]
ambiguidades e não contraditórios. Os resultados
encontrados são documentados em Resultados da
Verificação e correções são feitas até que o
documento seja aprovado pelo Analista(AN). Se
mudanças significativas forem necessárias, abrir
uma Solicitação de Mudança.
SI. Validar e obter aprovação da Especificação de Especificação de Validação de resultados CUS Não Documentação Não existe Não existe documentação para especificação de requisitos, por isso não
2.4 Requisitos. requisitos [verificada] informal documentação podem ser aprovados. A usabilidade da interface não é avaliada.
Especificação de requisitos AN
Validar que a Especificação de Requisitos satisfaz [validada]
as necessidades e expectativas combinadas,
incluindo a usabilidade da interface do usuário. Os
resultados encontrados são documentados em
resultados da Validação e as correções são feitas
até que o documento seja aprovado pelo
cliente(CUS).
SI. Documentar a versão preliminar da Documentação Especificação de *Documentação do usuário AN Parcialmente Documentação wiki, manual WT É feita a documentação para o usuário através de wiki e arquivos pdf,
2.5 do Usuário de Software ou atualizar o manual requisitos [validada] do software [preliminar] informal embora não exista especificação de requisitos para servir de base. Na
existente. documentação estão escritos: Procedimentos do usuário para executar
 Tarefas
*(se apropriado) especificadas usando o Software, Breve descrição da utilização para a
qual o Software foi desenvolvido e Lista as explicações dos comandos
do Software
e mensagens providas pelo sistema ao usuário.
SI. Verificar e obter a aprovação para a *Documentação do Resultados da verificação AN Não Wiki, manual Não existe A documentação é feita com base no entendimento do desenvolvedor.
2.6 Documentação do Usuário do Software. usuário do software documentação É feita apenas uma revisão para identificar erros de formatação e de
[preliminar] *Documentação do usuário ortografia.
Verificar a consistência da Documentação do do software [preliminar,
Usuário do Software com a Especificação de Especificação de verificado]
Requisitos. Os resultados encontrados são requisitos
documentados em Resultados da Verificação e Solicitação de mudança
correções são feitas até que o documento seja [iniciado]
aprovado pelo (AN). Se mudanças significativas
forem necessárias, iniciar uma Solicitação de
Mudança.

*(Se apropriado)
SI. Incorporar a Especificação de Requisitos e a Especificação de Configuração de software TL Não Não existe Não existe Não existem especificação de requisito e baselines para serem
2.7 Documentação do Usuário do Software em requisitos [validada] - Especificação de documentação documentação inseridos.
baseline à Configuração do Software. requisitos [validada, em
*Documentação do baseline]
usuário do software - *Documentação do
*(Se apropriado) [preliminar, verificado] usuário do software
[preliminar, verificado, em
baseline]
SI.3 SI. Atribuir tarefas aos membros da Equipe de Plano de Projeto TL Completamente Documentação ANA Bem informal, feito pela líder de equipe e pelos analistas.
Projeto de 3.1 Trabalho, de acordo com o seu papel, com base no - Tarefas informal TL
Arquitetu atual Plano de Projeto. AN
ra e
Detalham DES
ento do SI. Obter entendimento da Especificação de Especificação de AN Parcialmente Documentação ANA Como a especificação de requisitos não possui documentação o
Software 3.2 Requisitos. requisitos [validado, em informal WT entendimento é feito através de conversas.
baseline] DES
SI. Documentar ou atualizar o Projeto de Software. Especificação de Design de Software AN Não Documentação Não existe Não são feitos protótipos, fluxogramas, etc..
3.3 requisitos [validado, em informal documentação
Analisar a Especificação de Requisitos para gerar baseline] Registro de rastreabilidade DES
o projeto de arquitetura, seu arranjo em
subsistemas e componentes de software definindo
as interfaces internas e externas. Descrever em
detalhe a aparência e o comportamento da
interface, com base na Especificação de
Requisitos, de modo que os recursos para sua
implementação possam ser previstos.

Fornecer os detalhes dos componentes de software

e suas interfaces para permitir a construção de uma
forma evidente.

Gerar ou atualizar o Registro de Rastreabilidade.

 SI. Verificar e obter aprovação do Projeto de Design de Software Resultados da verificação AN Não Não existe Não existe Não identificado
3.4 Software. documentação documentação
Registro de Design de Software DES
Verificar a correção do documento de Projeto de rastreabilidade [verificado]
Software, sua viabilidade e a consistência com a
sua Especificação de Requisitos. Verificar se o Especificação de Registro de rastreabilidade
Registro de Rastreabilidade contém as relações requisitos [validada, em [Verificado]
adequadas entre os requisitos e os elementos do baseline]
Projeto de Software. Os resultados encontrados Solicitação de mudança
são documentados em resultados da verificação e [iniciado]
correções são feitas até que o documento seja
aprovado pelo AN. Se mudanças significativas
forem necessárias, iniciar uma Solicitação de
mudança.
SI. Estabelecer ou atualizar os Casos de Teses e os Especificação de Caso de teste e DES Não Não existe Não existe Não identificado
3.5 Procedimentos de Testes para os testes de requisitos [validado, em procedimentos de testes documentação documentação
integração com base na Especificação de baseline]
Requisitos e no projeto de Software.
Design de Software
Cliente fornece os dados de teste, se necessário. [Verificado, em baseline]
SI. Verificar e obter aprovação para os Casos de Teste Caso de teste e Resultados verificados DES Não Não existe Não existe Não identificado
3.6 e Procedimentos de Teste. procedimentos de testes documentação documentação
Caso de teste e AN
Verificar a consistência entre a Especificação de Especificação de procedimetos de testes
Requisitos, Projeto de Software e Teste de requisitos [validado, em [Verificado]
Software e procedimentos de Teste. Os resultados baseline]
encontrados são documentados nos Resultados da
Verificação e correções são feitas até que o Design de Software
documento seja aprovado pelo AN. [Verificado, em baseline]
SI. Atualizar o registro de rastreabilidade Caso de teste e Registro de rastreabilidade DES Não Não existe Não existe Não identificado
3.7 incorporando os Casos de Teste e Processos de procedimentos de testes [atualizado] documentação documentação
Teste. [Verificado]

Registro de
rastreabilidade
[atualizado]
SI. Incorporar o Projeto de Software e o Registro de Design de Software Configuração de software TL Não Não existe Não existe Não identificado
3.8 Rastreabilidade à Configuração de Software como [Verificado] - Design de Software documentação documentação
parte da baseline. [Verificado, em baseline]
Caso de teste e
Incorporar os Casos de Teste e Procedimentos de procedimentos de testes - Caso de teste e
Teste ao Repositório de Projeto. [Verificado] procedimentos de testes
[Verificado]
Registro de - Registro de
rastreabilidade rastreabilidade [Verificado,
[Verificado] em baseline]
SI.4 SI. Atribuir tarefas relativas ao seu papel aos Plano de projeto TL Completamente Documentação ANA As tarefas são distribuídas aos programadores de maneira informal.
Construçã 4.1 Membros da Equipe de Trabalho, de acordo com o - Tarefas informal TL
o de Atual Plano de Projeto.
Software SI. Obter o entendimento do Projeto de Software. Design de Software PR Largamente Não existe PR Não é feito o plano de projeto de software. Mas o entendimento do
4.2 [Verificado, em baseline] documentação projeto é feito pelo programador através de conversas com os
envolvidos.
SI. Construir ou atualizar Componentes de Software Design de Software Componentes de software PR Completamente Não existe Software PR Os componentes são gerados.
4.3 com base na parte detalhada do Projeto de [Verificado, em documentação
Software. baseline],
Registro de
rastreabilidade
 [Verificado, em baseline]

SI. Projetar ou atualizar os casos de testes unitários e Componentes de Componentes de software PR Não Software Não existe Testes unitários não são projetados.
4.4 aplicá-los para verificar se os componentes de software [teste unitário] documentação
software implementam a parte detalhada do
Projeto de Software.
SI. Corrigir os defeitos encontrados até obter sucesso Componentes de Componentes de software PR Não Não existe Não existe Testes unitários não são projetados.
4.5 no teste unitário (alcançando o critério de saída). software [teste unitário] [corrigido] documentação documentação
SI. Atualizar o Registro de Rastreabilidade Componentes de Registro de rastreabilidade PR Parcialmente Software Vincular na PR Os chamados do sistema Primus, onde estão informalmente os
4.6 incorporando os Componentes de Software software [corrigido] [atualizado] aba de requisitos, são vinculados com os objetos alterados. Quanto aos
construídos ou modificados. documentação elementos do Projeto do Software, Casos de Teste e Procedimentos de
Registro de do genexus a Teste, estes não são vinculados.
rastreabilidade alteração com
[Verificado, em baseline] o chamado do
sistema Primus
SI. Incorporar Componentes de Software e Registro Componentes de Configuração de software TL Não Software e aba Não é gerada a documentação para estes casos.
4.7 de Rastreabilidade à Configuração de Software software [corrigido] - Componentes de software documentation
como parte da baseline. [corrigido, em baseline] do Genexus.
Registro de - Registro de
rastreabilidade rastreabilidade [atualizado
[atualizado] em baseline]
SI.5 SI. Atribuir tarefas relativas ao seu papel aos Plano de projeto TL Largamente Documentação ANA Na maioria das vezes o programador ou o analista fica responsável
Integraçã 5.1 Membros da Equipe de Trabalho, de acordo com o - Tarefas informal TL pelos testes. Ás vezes a etapa de teste é pulada, por ser muito complexo
o e Testes Atual Plano de Projeto. de reproduzir o teste ou por pressa.
do SI. Obter entendimento dos Casos de Teste e Caso de teste e PR Parcialmente Documentação PR Antes de alterar o sistema o analista ou o programador possuem o
Software 5.2 Procedimentos de Teste. procedimentos de testes informal entendimento do teste, porém não documenta. O ambiente de teste fica
[Verificado] sempre disponível em uma base chamada protótipo.
Instalar ou atualizar o ambiente de testes.
SI. Integrar o Software usando os Componentes de Componentes de Software PR Não Software Software PR Não há teste de integração expressivo que chegue a 15%. Não são
5.3 Software e atualizar os Casos de Testes e software [corrigido, em atualizados casos de testes e procedimento de testes, pois eles não
Procedimento de Teste para testes de integração, baseline] Caso de teste e existem.
conforme necessário. procedimentos de testes
Caso de teste e
procedimentos de testes
[Verificado]

Registro de
rastreabilidade
[atualizado, em baseline]
SI. Realizar os testes do software usando Casos de Software Software [testado] PR Parcialmente Software Software PR Não há relatório de testes, porém os testes são realizados pelo
5.4 Teste e Procedimento de Teste para integração do [testado] programador.
produto de software e documentar os resultados no Caso de teste e Relatório de testes CUS
Relatório de Teste. procedimentos de testes
SI. Corrigir os defeitos encontrados e executar o teste Software [testado] Software [corrigido] PR Não Software Software Não é feito teste de integração.
5.5 de regressão até alcançar o critério de saída.
Relatório de testes Relatório de testes
[Defeitos eliminados]
Caso de teste e
procedimentos de testes

Registro de
rastreabilidade
[atualizado, em baseline]
 SI. Atualizar o registro de Rastreabilidade, se Software [corrigido] Registro de rastreabilidade PR Não Não existe Não existe Não é realizado rastreabilidade. Não há requisitos para fazer a
5.6 necessário. [atualizado] documentação documentação rastreabilidade.
Registro de
rastreabilidade
[atualizado, em baseline]
SI. Documentar o Guia de Operação do Produto ou Software [testado] *Guia de operação do PR Não Não existe Não existe Não é gerado documentação suficiente. Existe alguns passos de
5.7 atualizar o existente, se apropriado. produto documentação documentação instalação de software e TS, mas é muito pouco.
SI. Verificar e obter aprovação do Guia de Operação *Guia de operação do Resultados verificados PR Não Não é feito, não tem como aprovar.
5.8 de Produto, se apropriado (ver SI.5.7) produto
*Guia de operação do CUS
Verificar a consistência do Guia de Operação de Software [testado] produto [Verificado]
Produto com o Software. Os resultados
encontrados são documentados nos Resultados da
Verificação e correções são feitas até que o
documento seja aprovado pelo Projetista (DES).
SI. Elaborar a Documentação do Usuário de Software Software [testado] *Documentação de usuário AN Parcialmente Software Wiki, PR É feita a documentação para o usuário através de wiki e arquivos pdf.
5.9 ou atualizar a existente, se apropriado. do software documentação, Na documentação estão escritos: Procedimentos do usuário para
*Documentação de guia do executar Tarefas
usuário do software usuário WTS especificadas usando o Software, Breve descrição da utilização para a
[preliminar] qual o
Software foi desenvolvido e Lista explicações dos comandos do
Software
e mensagens providas pelo sistema ao usuário.
SI. Verificar e obter a aprovação da Documentação do *Documentação de Resultados verificados AN Não Wiki, Não é aprovado a documentação de software.
5.10 Usuário de Software, se apropriado (ver SI.5.7). usuário do software documentação,
*Documentação de usuário CUS guia do
Verificar a consistências da Documentação do Software [testado] do software [Verificado] usuário WTS
Usuário de Software com o Software. Os
resultados encontrados são documentados em
Resultados da Verificação e correções são feitas
até que o documento seja aprovado pelo CUS.
SI. Incorporar Casos de Teste e Procedimentos de Caso de teste e Configuração de software TL Não Não existe Não existe Não é gerado a configuração de software.
5.11 Teste, registro de Rastreabilidade, Relatório de procedimentos de testes - Caso de teste e documentação documentação
Teste, Guia de Operação do Produto e procedimentos de testes
Documentação de Usuário de Software à Software [testado] [em baseline]
Configuração de Software como parte da baseline. - Software [testado, em
Relatório de testes baseline]
- Registro de
Registro de rastreabilidade [atualizado,
rastreabilidade em baseline]
[atualizado] - Relatório de testes [em
baseline]
*Guia de operação do - *Guia de operação do
produto [Verificado] produto [Verificado, em
baseline]
*Documentação de - *Documentação de
usuário do software usuário do software
[Verificado] [Verificado, em baseline]

SI.6 SI. Atribuir tarefas relativas ao seu papel aos Plano de projeto TL Completamente Documentação ANA As tarefas são distribuídas às pessoas de maneira informal.
Entrega 6.1 Membros da Equipe de Trabalho, de acordo com o - Tarefas informal TL
do Plano de Projeto atual. WT
Produto SI. Obter entendimento de Configuração de Software. Configuração de DES Não Não existe Não é instalado o software, o ambiente é único e por isso não são feitos
6.2 software documentação a configuração de software.
SI. Elaborar Documentação de Manutenção ou Configuração de Documentação de DES Não Não existe Não existe Não é feito o documento de manutenção.
6.3 atualizar a existente. software manutenção documentação documentação
SI. Verificar e obter aprovação da Documentação de Documentação de Resultados verificados DES Não Não existe Não existe Não é feito o documento de manutenção.
6.4 Manutenção. manutenção documentação documentação
Documentação de
Verificar a consistência da Documentação de Configuração de manutenção [Verificado]
Manutenção com a configuração do Software. Os software
resultados encontrados são documentados em
Resultados da Verificação e correções são feitas
até que o documento seja aprovado pelo Líder de
Projeto (TL).
SI. Incorporar a Documentação de Manutenção como Configuração de Configuração de software TL Não Não existe Não existe Não é feito o documento de manutenção.
6.5 baseline à Configuração de Software. software - Documentação de documentação documentação
manutenção [Verificado,
Documentação de em baseline]
manutenção [Verificado]
SI. Realizar a entrega de acordo com Instruções de Plano de projeto Configuração de software TL Parcialmente Documentação Não existe A entrega é feita com base no que foi combinado com o cliente. Porém
6.6 Entrega. - Instruções de entrega [entregue] informal documentação não existe instruções de entregas documentadas para serem seguidas.
Da configuração de software são entregues o software, a documentação
Configuração de de usuário e os componentes de software.
software