DIAGNÓSTICO E PROPOSTA DE MELHORIA NO PROCESSO DE SOFTWARE DA PAMPLONA ALIMENTOS S/A BASEADO NA NORMA ABNT NBR ISO/IEC 29110

Transcrição

1 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 Evandro Meurer 1 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 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 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 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 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 can be easily inserted in the software development teams processes with up to 25 people. Keywords: Software quality. Software processes. ABNT NBR ISO/IEC 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.

2 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 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 Trello 1, 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 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

3 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 (ABNT e SEBRAE, 2012). 3. Norma ABNT NBR ISO/IEC 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 é um guia para melhoria da qualidade, desempenho e processos dos produtos de softwares, com foco para organizações de até 25

4 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 (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 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,

5 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. O1 O 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. O2 O progresso do projeto é monitorado de acordo com o 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. 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. O4 Reuniões de revisão com a Equipe de Trabalho e o Cliente são realizadas. Aceitações são registradas e controladas. O5 Riscos são identificados quando surgem e durante o desenvolvimento do Projeto. 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. 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 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: 1 Planejamento de Projeto, 2 Execução do, 3 Avaliação e Controle do Projeto e 4 Encerramento do Projeto (ABNT, 2012b), como demonstra a Figura 2. Nas 4 atividades existem 26 tarefas, sendo que o 1 possui 15, o 2 6, o 3 3 e o 4 possui 2 tarefas (ABNT, 2012b).

6 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 , 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) 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. O1. Tarefas das atividades são realizadas através da execução do Plano do Projeto corrente. O2. Requisitos de software são definidos, analisados quanto ao corretismo e testabilidade, aprovados pelo Cliente, incluídos em baselines e comunicados. O3. O projeto de arquitetura e seu detalhamento são elaborados e incluídos em baseline. Eles descrevem os

7 Componentes de Software e suas interfaces internas e externas. A consistência e rastreabilidade aos requisitos do software são estabelecidas. 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. 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. O6. Uma Configuração de Software, que atende a Especificação de Requisitos como acordado com o Cliente, a qual inclui 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. 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: 1 Iniciação da Implementação de Software, 2 Análise de Requisitos de Software, 3 Projeto de Arquitetura e Detalhamento do Software, 4 Construção de Software, 5 Integração e Testes do Software e 6 Entrega do Produto (ABNT, 2012b). A Figura 3 ilustra essas atividades. Sendo que o 1 contém 2 tarefas, o 2 7, o 3 8, o 4 7, o 5 11 e o 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. 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

8 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 estão envolvidos: Cliente, Analista, Designer, Programador, Gerente, Líder Técnico e Equipe de Trabalho (ABNT, 2012b) 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 estão descritas na ISO/IEC (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;

9 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 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 Metodologia da avaliação Com base na ISO/IEC , 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

10 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 , 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 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 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 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 Resultados da avaliação A norma ABNT NBR ISO/IEC 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 1 Planejamento de Projeto Plano de Execução do Projeto Avalição e Controle de Projeto Encerramento do Projeto Iniciação da Implementação de Software Análise de Requisitos de Software Projeto de Arquitetura e Detalhamento do Software Construção de Software Integração e Testes do Software Entrega do Produto Tabela 2 Soma de atributo de processo por atividade (Acervo do autor) Para melhor análise dos dados, foram convertidos os resultados de 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.

11 Avaliação da Gerenciamento de Projeto 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% 1 Planejamento de Projeto 16% 2 Plano de Execução do Projeto 17% 3 Avalição e Controle de Projeto 0% 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% 1 Iniciação da Implementação de Software 84% 2 Análise de Requisitos de Software 24% 3 Projeto de Arquitetura e Detalhamento do Software 17% 4 Construção de Software 43% 5 Integração e Testes do Software 15% 6 Entrega do Produto 22% % Executado Figura 5 Gráfico de avaliação da Implementação de Software (acervo do autor)

12 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. 40% 35% 30% 25% 20% Média de tarefas executadas Atividade de Implementaçã o de Software; 34% Média Total de Processos; 25% 15% 10% 5% 0% Atividades de Gerenciamento de projeto; 12% 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 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 1 Planejamento de Projeto 16% Parcialmente 2 Plano de Execução do Projeto 17% Parcialmente 3 Avalição e Controle de Projeto 0% 4 Encerramento do Projeto 16% Parcialmente 1 Iniciação da Implementação de Software 84% Largamente 2 Análise de Requisitos de Software 24% Parcialmente 3 Projeto de Arquitetura e Detalhamento do Software 17% Parcialmente 4 Construção de Software 43% Parcialmente 5 Integração e Testes do Software 15% 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.

13 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 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 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 1.2. E quando for um projeto médio ou grande, o GP detalha o escopo e os objetivos, contemplando assim a tarefa 1.12.

14 Após realizadas as tarefas descritas anteriormente, o GP irá identificar os recursos e os riscos para o projeto, previstos nas tarefas 1.5 e 1.9. Todas as melhorias sugeridas até agora servirão como parte do, o qual será gerado pelo GP por meio de uma extração de informações do sistema de chamados, procurando atender a tarefa E com o Plano de Projeto gerado, ele poderá obter a aprovação e a aceitação, assim como requerido nas tarefas 1.13 e Como pode ser visto na Figura 7, para o restante das tarefas de Planejamento de Projeto não foram sugeridas melhorias. A tarefa 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 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, 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 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 1.10 e 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 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 2.4, o GP deverá fazer reuniões com o cliente e documentar em ata as decisões. A 2.3, que trata de reuniões com a equipe, atualmente é contemplada largamente segundo a avaliação. E para a 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 2.5 e 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 3.1 o GP terá que

15 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 3.2. Se houverem mudanças no projeto, o GP deverá fazer modificações em projetos para atender a tarefa 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 4.1, atribuir ao GP a responsabilidade de gerar a 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 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 1.1 obteve uma avaliação de largamente, enquanto 1.2 obteve completamente. Porém, para que o 1.1 atinja a completude da execução, o 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: 2.1, 3.1, 4.1, 5.1 e 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.

16 Figura 11 Fluxograma de Iniciação da Implementação de Software (acervo do autor) Como visto no processo anterior, a tarefa de 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 2.2 e 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 2.4. A Documentação de Usuário de Software, tarefas 2.5 e 2.6, não serão elaboradas neste momento, mas sim nas tarefas 5.9 e A tarefa 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 formal de especificação de requisitos, visando atender completamente a tarefa 3.2, que atualmente foi avaliada como parcialmente atendida. Para atender em partes as tarefas 3.3 e 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 3.5 e 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

17 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 3.7 e 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 gerada pelo analista, espera-se que a tarefa 4.2 seja executada completamente, ao invés de largamente como foi avaliada. Os componentes de software são gerados, por isso a tarefa 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 4.4 e 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 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 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 5.2, 5.3, 5.4 e 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.

18 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 5.7, 5.8, 5.9 e O registro dos passos anteriores no sistema de chamado servirão para a execução da tarefa 5.11, que é a incorporação dos desta atividade na Configuração de Software. Para a tarefa 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 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 6.3 e 6.4. E por fim, o GP entrega a Configuração de Software para o cliente, encerrando o projeto conforme a tarefa 6.6. A única tarefa que não foi contemplada é a 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.

19 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 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 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 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 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 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 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

20 pequenas organizações; Série ABNT NBR ISO/IEC Disponível em: < guia-de-implementacao-desenvolvimento-de-software-para-pequenas-organizacoes > Acesso em: 26 out 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, Disponível em:< sequence=3> Acesso em: 26 out 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, Disponível em: < Acesso em: 06 jul ISO/IEC - International Organization for Standardization / International Electrotechnical Commission, Software engineering - Lifecycle profiles for Very Small Entities (VSEs) - Part 3: Assessment guide. 1ª ed 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, Disponível em: < Acesso em: 06 jul PRESSMAN, Roger. S. Engenharia de software. 6. ed. São Paulo: Bookman, SOMMERVILLE, Ian. Engenharia de software. 8ª ed. São Paulo: Pearson Addison-Wesley, 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, Disponível em: < Acesso em: 26 out