Embed Size (px)
Citation preview
Universidade do Estado de Santa Catarina
Centro de Educação Superior do Alto Vale do Itajaí
Departamento de Engenharia de Software
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.
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
1Universidade do Estado de Santa Catarina UDESC
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.
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
1https://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.
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.
Figura 5 – Gráfico de avaliação da Implementação de Software (acervo do autor)
0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%
PM.1 Planejamento de Projeto
PM.2 Plano de Execução do Projeto
PM.3 Avalição e Controle de Projeto
PM.4 Encerramento do Projeto
16%
17%
0%
16%
Avaliação da Gerenciamento de Projeto
% Executado
0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%
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
SI.6 Entrega do Produto
84%
24%
17%
43%
15%
22%
Avaliação da Implementação de Software
% Executado
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.
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.
Atividades de Gerenciamento
de projeto; 12%
Atividade de Implementação de Software;
34% Média Total de Processos; 25%
0%
5%
10%
15%
20%
25%
30%
35%
40%
Média de tarefas executadas
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
s de
gerencia
mento de
projeto
ID Lista de tarefas Produtos de Entrada Produtos de Saída Papé
is
É implementado Produtos de
Entrada
Produtos de
Saída
Papéis Comentários e Observações
PM.1
Planejam
ento de
Projeto
PM.
1.1
Revisar a declaração de trabalho Declaração de Trabalho Declaração de Trabalho
[Revisada]
PM
TL
Parcialmente Chamados
abertos pelos
usuários no
sistema Primus
Chamados
adicionados no
Trello
ANA
CUS
Parte dos chamados são revisados e passados para a ferramenta Trello.
O propósito e os requisitos gerais geralmente são definidos e revisados.
Porém o escopo, objetivos, e entregáveis não são nem definidos,
impossibilitando a revisão.
PM.
1.2
Definir com o cliente as instruções de Entrega para
cada um dos entregáveis especificados na
Declaração de Trabalho
Declaração de Trabalho
[Revisada]
Plano de Projeto
- Instruções de entrega
PM
CUS
Não Chamados
adicionados no
Trello
Não existem
documentos
ANA
CUS
As datas de liberação algumas vezes são combinadas com os clientes e
adicionadas nos chamados no sistema Primus. O restante das atividades
para levantamento das instruções de entregas não são executadas.
PM.
1.3
Identificar as tarefas específicas a serem realizadas
para produzir os entregáveis e seus componentes
de software identificados na Declaração de
Trabalho. Incluir tarefas do processo de SI,
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.
Declaração de Trabalho
[Revisada]
Plano de Projeto
- Tarefas
PM
TL
Não Não existem
documentos
Não existem
documentos
ANA Algumas tarefas são identificadas e adicionadas no chamado no
sistema Primus, mas apenas no que diz respeito ao desenvolvimento.
Os componentes, as tarefas de SI, a validação, verificação e revisão das
tarefas não são executadas.
PM.
1.4
Estabelecer a Duração Estimada para realizar cada
tarefa.
Plano de Projeto
- Tarefas
Plano de Projeto
- Duração Estimada
PM
TL
Completamente Não existem
documentos
Chamados
com estimativa
na ferramenta
primus
ANA Sempre usado estimativa de horas quando passado as tarefas para o
desenvolvimento. Inserido a quantidade de horas no chamado do
sistema Primus.
PM.
1.5
Identificar e documentar os recursos: humanos,
materiais, equipamentos e ferramentas, normas,
incluindo o treinamento necessário da Equipe de
Trabalho para executar o projeto. Indicar no
calendário quando os recursos e o treinamento são
necessários.
Declaração de Trabalho Plano de Projeto
- recursos
PM
TL
Não Chamados
abertos pelos
usuários no
sistema Primus
Não existem
documentos
Não identificado.
PM.
1.6
Estabelecer a Composição da Equipe de Trabalho,
atribuindo papéis e responsabilidades de acordo
com os Recursos.
Plano de Projeto
- recursos
Plano de Projeto
- Composição do grupo de
trabalho
PM
TL
Largamente Não existem
documentos
Documentação
informal
TL São definido as pessoas e responsabilidades de maneira informal. Ou
seja, a pessoa fica sabendo que irá compor uma equipe de trabalho
através de uma conversa. Porém, não existe documento que comprove
o fato.
PM.
1.7
Atribuir datas de início e conclusão estimadas para
cada uma das tarefas, a fim de criar um
Cronograma das Tarefas do Projeto, tendo em
conta os recursos atribuídos, sequência e
dependência das tarefas.
Plano de Projeto
- Tarefas
- Duração estimada
- Composição do grupo
de trabalho
Plano de Projeto
- Cronograma das tarefas
do projeto
PM
TL
Parcialmente Chamados
abertos pelos
usuários no
sistema Primus
Chamados
com data
prevista de
início e
termino
ANA Os chamados recebem data de início e termino no sistema Primus. Mas
não são levados em conta todos os recursos, apenas os recursos
humanos. A sequência e a dependência das tarefas não são verificadas.
O Cronograma não é gerado.
PM.
1.8
Calcular e documentar a Estimativa de Esforço e o
Custo do projeto
Plano de projeto
- Composição do grupo
de trabalho
- Recursos
Plano de Projeto
- Estimativa de esforço e
custo
PM Não Documentação
informal
Não existem
documentos
Não identificado
PM.
1.9
Identificar e documentar os riscos que podem
afetar o projeto.
Todos os elementos
definidos anteriormente
Tarefas do projeto PM
TL
Não Chamados do
sistema Primus
com todos os
Não existem
documentos
Não identificado
elementos
PM.
1.10
Documentar a Estratégia de Controle de versão
para o projeto.
Plano de Projeto
- Estratégia de controle de
versão
PM
TL
Não Não existem
documentos
Não identificado
PM.
1.11
Gerar o Plano de Projeto integrando os elementos
anteriormente identificados e documentados.
Todos os elementos
definidos anteriormente
Plano de projeto
- Tarefas
- Duração estimada
- Recursos
- 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 Não Chamados
com todos os
elementos
preenchidos
Não existem
documentos
Não identificado
PM.
1.12
Incluir a descrição do produto, escopo, objetivos e
entregáveis no Plano de Projeto.
Declaração de trabalho
- Descrição do Produto
- Escopo
- Objetivos
- Entregas
Plano de projeto
- Descrição do produto
- Escopo
- Objetivos
- Entregas
PM
TL
Não Não existem
documentos
Não existem
documentos
A descrição do produto está no chamado que o usuário abre, porém não
é inserido em um plano de projeto.
PM.
1.13
Verificar e obter aprovação do Plano de Projeto.
Verificar se todos os elementos do Plano de
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.
Plano de projeto Resultado de Verificações
Plano de Projeto
[verificado]
PM
TL
Não Não existem
documentos
Não existem
documentos
Não identificado
PM.
1.14
Revisar e aceitar o Plano de Projeto.
Cliente revê e aceita o Plano de Projeto,
certificando-se que os elementos do Plano de
Projeto correspondem à Declaração de Trabalho.
Plano de Projeto
[cerificado]
Registro de reunião de
projeto [aprovação]
PM
CUS
Não Não existem
documentos
Não existem
documentos
A revisão do projeto não é feita, assim como a aprovação também não
é feita. Não existe documentação de projeto.
PM.
1.15
Estabelecer o repositório do projeto usando a
Estratégia de Controle de Versão.
Estratégia de controle de
versão
Repositório do projeto PM
TL
Não Não existem
documentos
Não existem
documentos
Não existe repositório para documentação de projeto.
PM.2
Plano de
Execução
do
Projeto
PM.
2.1
Monitorar a execução do Plano de Projeto e
registrar o realizado no Registro de Status de
Progresso.
Plano de projeto Relatório de Status do
progresso
PM
TL
WT
Parcialmente Não existem
documentos
Apontamento
de chamados
no sistema
Primus
WT Os desenvolvedores apontam no chamado as atividades que realizaram.
Porém, os projetos não são monitorados.
PM.
2.2
Analisar e avaliar a Solicitação de Mudança para o
custo, cronograma e impacto técnico.
A solicitação de Mudança pode ser iniciada
exatamente pelo Cliente ou internamente pela
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
Solicitação de mudança
[iniciado]
Plano de projeto
Solicitação de mudança
[avaliado]
Plano de projeto
[atualizado]
PM
TL
Não Atualização
dos chamados
Não existem
documentos
As solicitações de mudanças não são analisadas quanto a custo,
cronograma e impacto técnico. Algumas vezes é analisado
superficialmente quanto irá atrasar o projeto, mas sem registrar no
plano de projeto.
partes (ver PM 2.4).
PM.
2.3
Conduzir reuniões de revisão com a Equipe de
Trabalho, identificar problemas, rever o status dos
riscos, registrar as decisões e monitorá-las até sua
conclusão.
Plano de projeto
Relatório de Status do
progresso
Registro de correção
Registro reunião
Registro de Reunião
[atualizado]
PM
TL
WT
Largamente Ata de
reuniões
semanais
Ata de
reuniões
semanais
ANA
TL WT
Em reuniões semanais são revisadas as atividades da equipe,
reportados problemas e registradas em ata todos os itens anteriores
juntamente com as decisões tomadas. O monitoramento é realizado
sobre a ata documentada da semana anterior. Os riscos não são levados
em consideração.
PM.
2.4
Conduzir reuniões de revisão com o Cliente,
registar suas decisões e monitorá-las até sua
conclusão.
Uma Solicitação de Mudança iniciada pelo Cliente
ou iniciada pela Equipe de Trabalho, que afeta o
Cliente, precisa ser negociada para alcançar a
aceitação de ambas as partes.
Se necessário atualizar o Plano de Projeto segundo
o novo acordo com o Cliente.
Plano de Projeto
Registro do Status
do Progresso
Solicitação de
Mudança [avaliada]
Registro de Reunião
Registro de Reunião
[atualizado]
Solicitação de Mudança
[aceita]
Plano de Projeto
[atualizado]
PM
CUS
TL
WT
Não Não existem
documentos
Não existem
documentos
Algumas reuniões são com o cliente, mas em geral é apenas para
definir novos desenvolvimentos ou cobrar pendências.
PM.
2.5
Fazer Backups de acordo com a Estratégia de
Controle de Versão.
Estratégia de controle de
versão
Backup do repositório do
projeto
PM Não Não existem
documentos
Não existem
documentos
Não existe repositório para documentação de projeto.
PM.
2.6
Fazer recuperação do Repositório do Projeto
usando o Backup do Repositório do Projeto, se
necessário.
Backup do repositório do
projeto
Repositório do
projeto[recuperado]
PM Não Não existem
documentos
Não existem
documentos
Não existe repositório para documentação de projeto.
PM.3
Avalição
e
Controle
de Projeto
PM.
3.1
Avaliar o progresso do projeto com respeito ao
Plano de Projeto, comparando:
- tarefas realizadas versus planejadas;
- resultados reais versus objetivos do projeto
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.
Plano de projeto
Registro de status do
progresso
Registro de status do
progresso [avaliado]
PM
TL
WT
Não Não existem
documentos
Não existem
documentos
Nenhuma das avaliações são realizadas.
PM.
3.2
Estabelecer ações para corrigir desvios ou
problemas e riscos identificados, no que tange à
realização do plano, conforme necessário,
documentá-las no Registro de Correção e
monitorá-las até sua conclusão.
Registro de status do
progresso [avaliado]
Registro de correção PM
TL
WT
Não Não existem
documentos
Não existem
documentos
Não são estabelecidas as ações para possíveis problemas ou desvios.
PM.
3.3
Identificar mudanças nos requisitos e/ou no Pano
de Projeto para enfrentar desvios significativos,
riscos potenciais ou problemas relacionados com a
realização do plano, documentá-las em Solicitação
de Mudanças e monitorá-las até sua conclusão.
Registro de status do
progresso [avaliado]
Solicitação de mudança
[iniciada]
PM
TL
WT
Não Não existem
documentos
Não existem
documentos
Não são controladas mudanças no projeto.
PM.4
Encerram
ento do
Projeto
PM.
4.1
Formalizar a conclusão do projeto de acordo com
as instruções de Entrega estabelecida no Plano de
Projeto, fornecendo apoio para aceitação e
recebendo o Registro de Aceitação assinado.
Plano de projeto
- Instruções de entrega
Configuração de
software [entregue]
Registro de Aceitação
Configuração de software
[aceito]
PM
CUS
Parcialmente Não existem
documentos
Reunião com
os usuários e
homologação
dos chamados
ANA
CUS
É pego o aceite de usuários através de conversas e treinando-os. Os
chamados são homologados pelos clientes quando a solicitação foi
atendida. A configuração de software é entregue apenas com a
documentação de usuário e o software.
PM.
4.2
Atualizar o Repositório de Projeto. Configuração de
software [aceita]
Repositório de projeto
Repositório de projeto
[atualizado]
PM Não Reunião com
os usuários e
homologação
dos chamados
Não existem
documentos
Não existe repositório para documentação de projeto.
APÊNDICE B – Avaliação das tarefas de Implementação de Software.
ISO 29110 Perfil Básico TI da Pamplona Alimentos S/A
Atividade
s de
gerencia
mento de
projeto
ID Lista de tarefas Produtos de Entrada Produtos de Saída Papé
is
É implementado Produtos de
Entrada
Produtos de
Saída
Papéis Comentários e Observações
SI.1
Iniciação
da
Implemen
tação de
Software
SI
.1.1
Revisar o Plano de Projeto atual com os membros
da Equipe de Trabalho a fim de alcançar um
entendimento comum e obter seu envolvimento
com o projeto.
Plano de projeto Plano de projeto [revisado] PM
TL
WT
Largamente Não existe
documentação
Não existe
documentação
ANA
WT
São envolvidos todos os membros com uma conversa que tem por
objetivo entender o projeto. Porém o plano de projeto não é
documentado.
SI.
1.2
Estabelecer ou atualizar o ambiente de trabalho. Plano de projeto
[revisado]
TL
WT
Completamente Não existe
documentação
É dado o ambiente de trabalho para o desenvolvedor com tudo
instalado.
SI.2
Análise
de
Requisito
s de
Software
SI.
2.1
Atribuir tarefas aos membros da Equipe de
Trabalho, de acordo com o seu papel, com base no
atual Plano de Projeto.
Plano de projeto
[revisado]
- Tarefas
TL
WT
Completamente Não existe
documentação
TL
ANA
WT
É atribuído a responsabilidade de análise ao analista ou ao
desenvolvedor, dependendo do caso.
SI.
2.2
Documentar ou atualizar a Especificação de
Requisitos.
Identificar e consultar fontes de informação
(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.
Plano de projeto
- Descrição do produto
Especificação de requisitos AN
CUS
Parcialmente Não existe
documentação
Documentação
informal
ANA Quando são mais complexos os desenvolvimentos são feitas
especificações mais detalhadas. A viabilidade técnica é feita.
Informalmente é definido o escopo. Não existem documentos de
requisitos. As fontes de informação são consultadas.
SI.
2.3
Verificar e obter a aprovação da Especificação de
Requisitos.
Verificar a correção e a testabilidade da
Especificação de Requisitos e a sua consistência
com a Descrição do Produto. Adicionalmente,
verificar se os requisitos estão completos, sem
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.
Especificação de
requisitos
Plano de Projeto
- Descrição do produto
Verificação de resultados
Especificação de requisitos
[verificado]
Solicitação de mudança
[iniciada]
AN
TL
Não Documentação
informal
Não existe
documentação
Não existe documentação para especificação de requisitos, por isso não
podem ser aprovados.
SI.
2.4
Validar e obter aprovação da Especificação de
Requisitos.
Validar que a Especificação de Requisitos satisfaz
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).
Especificação de
requisitos [verificada]
Validação de resultados
Especificação de requisitos
[validada]
CUS
AN
Não Documentação
informal
Não existe
documentação
Não existe documentação para especificação de requisitos, por isso não
podem ser aprovados. A usabilidade da interface não é avaliada.
SI.
2.5
Documentar a versão preliminar da Documentação
do Usuário de Software ou atualizar o manual
existente.
Especificação de
requisitos [validada]
*Documentação do usuário
do software [preliminar]
AN Parcialmente Documentação
informal
wiki, manual WT É feita a documentação para o usuário através de wiki e arquivos pdf,
embora não exista especificação de requisitos para servir de base. Na
documentação estão escritos: Procedimentos do usuário para executar
*(se apropriado)
Tarefas
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.
2.6
Verificar e obter a aprovação para a
Documentação do Usuário do Software.
Verificar a consistência da Documentação do
Usuário do Software com a Especificação de
Requisitos. Os resultados encontrados são
documentados em Resultados da Verificação e
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.
*(Se apropriado)
*Documentação do
usuário do software
[preliminar]
Especificação de
requisitos
Resultados da verificação
*Documentação do usuário
do software [preliminar,
verificado]
Solicitação de mudança
[iniciado]
AN Não Wiki, manual Não existe
documentação
A documentação é feita com base no entendimento do desenvolvedor.
É feita apenas uma revisão para identificar erros de formatação e de
ortografia.
SI.
2.7
Incorporar a Especificação de Requisitos e a
Documentação do Usuário do Software em
baseline à Configuração do Software.
*(Se apropriado)
Especificação de
requisitos [validada]
*Documentação do
usuário do software
[preliminar, verificado]
Configuração de software
- Especificação de
requisitos [validada, em
baseline]
- *Documentação do
usuário do software
[preliminar, verificado, em
baseline]
TL Não Não existe
documentação
Não existe
documentação
Não existem especificação de requisito e baselines para serem
inseridos.
SI.3
Projeto de
Arquitetu
ra e
Detalham
ento do
Software
SI.
3.1
Atribuir tarefas aos membros da Equipe de
Trabalho, de acordo com o seu papel, com base no
atual Plano de Projeto.
Plano de Projeto
- Tarefas
TL
AN
DES
Completamente Documentação
informal
ANA
TL
Bem informal, feito pela líder de equipe e pelos analistas.
SI.
3.2
Obter entendimento da Especificação de
Requisitos.
Especificação de
requisitos [validado, em
baseline]
AN
DES
Parcialmente Documentação
informal
ANA
WT
Como a especificação de requisitos não possui documentação o
entendimento é feito através de conversas.
SI.
3.3
Documentar ou atualizar o Projeto de Software.
Analisar a Especificação de Requisitos para gerar
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.
Especificação de
requisitos [validado, em
baseline]
Design de Software
Registro de rastreabilidade
AN
DES
Não Documentação
informal
Não existe
documentação
Não são feitos protótipos, fluxogramas, etc..
SI.
3.4
Verificar e obter aprovação do Projeto de
Software.
Verificar a correção do documento de Projeto de
Software, sua viabilidade e a consistência com a
sua Especificação de Requisitos. Verificar se o
Registro de Rastreabilidade contém as relações
adequadas entre os requisitos e os elementos do
Projeto de 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 AN. Se mudanças significativas
forem necessárias, iniciar uma Solicitação de
mudança.
Design de Software
Registro de
rastreabilidade
Especificação de
requisitos [validada, em
baseline]
Resultados da verificação
Design de Software
[verificado]
Registro de rastreabilidade
[Verificado]
Solicitação de mudança
[iniciado]
AN
DES
Não Não existe
documentação
Não existe
documentação
Não identificado
SI.
3.5
Estabelecer ou atualizar os Casos de Teses e os
Procedimentos de Testes para os testes de
integração com base na Especificação de
Requisitos e no projeto de Software.
Cliente fornece os dados de teste, se necessário.
Especificação de
requisitos [validado, em
baseline]
Design de Software
[Verificado, em baseline]
Caso de teste e
procedimentos de testes
DES Não Não existe
documentação
Não existe
documentação
Não identificado
SI.
3.6
Verificar e obter aprovação para os Casos de Teste
e Procedimentos de Teste.
Verificar a consistência entre a Especificação de
Requisitos, Projeto de Software e Teste de
Software e procedimentos de Teste. Os resultados
encontrados são documentados nos Resultados da
Verificação e correções são feitas até que o
documento seja aprovado pelo AN.
Caso de teste e
procedimentos de testes
Especificação de
requisitos [validado, em
baseline]
Design de Software
[Verificado, em baseline]
Resultados verificados
Caso de teste e
procedimetos de testes
[Verificado]
DES
AN
Não Não existe
documentação
Não existe
documentação
Não identificado
SI.
3.7
Atualizar o registro de rastreabilidade
incorporando os Casos de Teste e Processos de
Teste.
Caso de teste e
procedimentos de testes
[Verificado]
Registro de
rastreabilidade
[atualizado]
Registro de rastreabilidade
[atualizado]
DES Não Não existe
documentação
Não existe
documentação
Não identificado
SI.
3.8
Incorporar o Projeto de Software e o Registro de
Rastreabilidade à Configuração de Software como
parte da baseline.
Incorporar os Casos de Teste e Procedimentos de
Teste ao Repositório de Projeto.
Design de Software
[Verificado]
Caso de teste e
procedimentos de testes
[Verificado]
Registro de
rastreabilidade
[Verificado]
Configuração de software
- Design de Software
[Verificado, em baseline]
- Caso de teste e
procedimentos de testes
[Verificado]
- Registro de
rastreabilidade [Verificado,
em baseline]
TL Não Não existe
documentação
Não existe
documentação
Não identificado
SI.4
Construçã
o de
Software
SI.
4.1
Atribuir tarefas relativas ao seu papel aos
Membros da Equipe de Trabalho, de acordo com o
Atual Plano de Projeto.
Plano de projeto
- Tarefas
TL Completamente Documentação
informal
ANA
TL
As tarefas são distribuídas aos programadores de maneira informal.
SI.
4.2
Obter o entendimento do Projeto de Software. Design de Software
[Verificado, em baseline]
PR Largamente Não existe
documentação
PR Não é feito o plano de projeto de software. Mas o entendimento do
projeto é feito pelo programador através de conversas com os
envolvidos.
SI.
4.3
Construir ou atualizar Componentes de Software
com base na parte detalhada do Projeto de
Software.
Design de Software
[Verificado, em
baseline],
Registro de
rastreabilidade
Componentes de software PR Completamente Não existe
documentação
Software PR Os componentes são gerados.
[Verificado, em baseline]
SI.
4.4
Projetar ou atualizar os casos de testes unitários e
aplicá-los para verificar se os componentes de
software implementam a parte detalhada do
Projeto de Software.
Componentes de
software
Componentes de software
[teste unitário]
PR Não Software Não existe
documentação
Testes unitários não são projetados.
SI.
4.5
Corrigir os defeitos encontrados até obter sucesso
no teste unitário (alcançando o critério de saída).
Componentes de
software [teste unitário]
Componentes de software
[corrigido]
PR Não Não existe
documentação
Não existe
documentação
Testes unitários não são projetados.
SI.
4.6
Atualizar o Registro de Rastreabilidade
incorporando os Componentes de Software
construídos ou modificados.
Componentes de
software [corrigido]
Registro de
rastreabilidade
[Verificado, em baseline]
Registro de rastreabilidade
[atualizado]
PR Parcialmente Software Vincular na
aba de
documentação
do genexus a
alteração com
o chamado do
sistema Primus
PR Os chamados do sistema Primus, onde estão informalmente os
requisitos, são vinculados com os objetos alterados. Quanto aos
elementos do Projeto do Software, Casos de Teste e Procedimentos de
Teste, estes não são vinculados.
SI.
4.7
Incorporar Componentes de Software e Registro
de Rastreabilidade à Configuração de Software
como parte da baseline.
Componentes de
software [corrigido]
Registro de
rastreabilidade
[atualizado]
Configuração de software
- Componentes de software
[corrigido, em baseline]
- Registro de
rastreabilidade [atualizado
em baseline]
TL Não Software e aba
documentation
do Genexus.
Não é gerada a documentação para estes casos.
SI.5
Integraçã
o e Testes
do
Software
SI.
5.1
Atribuir tarefas relativas ao seu papel aos
Membros da Equipe de Trabalho, de acordo com o
Atual Plano de Projeto.
Plano de projeto
- Tarefas
TL Largamente Documentação
informal
ANA
TL
Na maioria das vezes o programador ou o analista fica responsável
pelos testes. Ás vezes a etapa de teste é pulada, por ser muito complexo
de reproduzir o teste ou por pressa.
SI.
5.2
Obter entendimento dos Casos de Teste e
Procedimentos de Teste.
Instalar ou atualizar o ambiente de testes.
Caso de teste e
procedimentos de testes
[Verificado]
PR Parcialmente Documentação
informal
PR Antes de alterar o sistema o analista ou o programador possuem o
entendimento do teste, porém não documenta. O ambiente de teste fica
sempre disponível em uma base chamada protótipo.
SI.
5.3
Integrar o Software usando os Componentes de
Software e atualizar os Casos de Testes e
Procedimento de Teste para testes de integração,
conforme necessário.
Componentes de
software [corrigido, em
baseline]
Caso de teste e
procedimentos de testes
[Verificado]
Registro de
rastreabilidade
[atualizado, em baseline]
Software
Caso de teste e
procedimentos de testes
PR Não Software Software PR Não há teste de integração expressivo que chegue a 15%. Não são
atualizados casos de testes e procedimento de testes, pois eles não
existem.
SI.
5.4
Realizar os testes do software usando Casos de
Teste e Procedimento de Teste para integração do
produto de software e documentar os resultados no
Relatório de Teste.
Software
Caso de teste e
procedimentos de testes
Software [testado]
Relatório de testes
PR
CUS
Parcialmente Software Software
[testado]
PR Não há relatório de testes, porém os testes são realizados pelo
programador.
SI.
5.5
Corrigir os defeitos encontrados e executar o teste
de regressão até alcançar o critério de saída.
Software [testado]
Relatório de testes
Caso de teste e
procedimentos de testes
Registro de
rastreabilidade
[atualizado, em baseline]
Software [corrigido]
Relatório de testes
[Defeitos eliminados]
PR Não Software Software Não é feito teste de integração.
SI.
5.6
Atualizar o registro de Rastreabilidade, se
necessário.
Software [corrigido]
Registro de
rastreabilidade
[atualizado, em baseline]
Registro de rastreabilidade
[atualizado]
PR Não Não existe
documentação
Não existe
documentação
Não é realizado rastreabilidade. Não há requisitos para fazer a
rastreabilidade.
SI.
5.7
Documentar o Guia de Operação do Produto ou
atualizar o existente, se apropriado.
Software [testado] *Guia de operação do
produto
PR Não Não existe
documentação
Não existe
documentação
Não é gerado documentação suficiente. Existe alguns passos de
instalação de software e TS, mas é muito pouco.
SI.
5.8
Verificar e obter aprovação do Guia de Operação
de Produto, se apropriado (ver SI.5.7)
Verificar a consistência do Guia de Operação de
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).
*Guia de operação do
produto
Software [testado]
Resultados verificados
*Guia de operação do
produto [Verificado]
PR
CUS
Não Não é feito, não tem como aprovar.
SI.
5.9
Elaborar a Documentação do Usuário de Software
ou atualizar a existente, se apropriado.
Software [testado]
*Documentação de
usuário do software
[preliminar]
*Documentação de usuário
do software
AN Parcialmente Software Wiki,
documentação,
guia do
usuário WTS
PR É feita a documentação para o usuário através de wiki e arquivos pdf.
Na documentação estão escritos: Procedimentos do usuário para
executar Tarefas
especificadas usando o Software, Breve descrição da utilização para a
qual o
Software foi desenvolvido e Lista explicações dos comandos do
Software
e mensagens providas pelo sistema ao usuário.
SI.
5.10
Verificar e obter a aprovação da Documentação do
Usuário de Software, se apropriado (ver SI.5.7).
Verificar a consistências da Documentação do
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.
*Documentação de
usuário do software
Software [testado]
Resultados verificados
*Documentação de usuário
do software [Verificado]
AN
CUS
Não Wiki,
documentação,
guia do
usuário WTS
Não é aprovado a documentação de software.
SI.
5.11
Incorporar Casos de Teste e Procedimentos de
Teste, registro de Rastreabilidade, Relatório de
Teste, Guia de Operação do Produto e
Documentação de Usuário de Software à
Configuração de Software como parte da baseline.
Caso de teste e
procedimentos de testes
Software [testado]
Relatório de testes
Registro de
rastreabilidade
[atualizado]
*Guia de operação do
produto [Verificado]
*Documentação de
usuário do software
[Verificado]
Configuração de software
- Caso de teste e
procedimentos de testes
[em baseline]
- Software [testado, em
baseline]
- Registro de
rastreabilidade [atualizado,
em baseline]
- Relatório de testes [em
baseline]
- *Guia de operação do
produto [Verificado, em
baseline]
- *Documentação de
usuário do software
[Verificado, em baseline]
TL Não Não existe
documentação
Não existe
documentação
Não é gerado a configuração de software.
SI.6
Entrega
do
Produto
SI.
6.1
Atribuir tarefas relativas ao seu papel aos
Membros da Equipe de Trabalho, de acordo com o
Plano de Projeto atual.
Plano de projeto
- Tarefas
TL
WT
Completamente Documentação
informal
ANA
TL
As tarefas são distribuídas às pessoas de maneira informal.
SI.
6.2
Obter entendimento de Configuração de Software. Configuração de
software
DES Não Não existe
documentação
Não é instalado o software, o ambiente é único e por isso não são feitos
a configuração de software.
SI.
6.3
Elaborar Documentação de Manutenção ou
atualizar a existente.
Configuração de
software
Documentação de
manutenção
DES Não Não existe
documentação
Não existe
documentação
Não é feito o documento de manutenção.
SI.
6.4
Verificar e obter aprovação da Documentação de
Manutenção.
Verificar a consistência da Documentação de
Manutenção com a configuração do 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 Líder de
Projeto (TL).
Documentação de
manutenção
Configuração de
software
Resultados verificados
Documentação de
manutenção [Verificado]
DES Não Não existe
documentação
Não existe
documentação
Não é feito o documento de manutenção.
SI.
6.5
Incorporar a Documentação de Manutenção como
baseline à Configuração de Software.
Configuração de
software
Documentação de
manutenção [Verificado]
Configuração de software
- Documentação de
manutenção [Verificado,
em baseline]
TL Não Não existe
documentação
Não existe
documentação
Não é feito o documento de manutenção.
SI.
6.6
Realizar a entrega de acordo com Instruções de
Entrega.
Plano de projeto
- Instruções de entrega
Configuração de
software
Configuração de software
[entregue]
TL Parcialmente Documentação
informal
Não existe
documentação
A entrega é feita com base no que foi combinado com o cliente. Porém
não existe instruções de entregas documentadas para serem seguidas.
Da configuração de software são entregues o software, a documentação
de usuário e os componentes de software.
![MPS.BR - Melhoria de Processo do Software Brasileiro Guia ... · SW:2012 em Conjunto com o CMMI-DEV v1.3 [Softex, 2012b]; ... (MoProSoft) [NYCE, 2011], além de modelos de excelência](https://img.document.onl/doc/110x75/5e49e84ba1554e071d07765a/mpsbr-melhoria-de-processo-do-software-brasileiro-guia-sw2012-em-conjunto.jpg)
