CHAIENE M. DA SILVA MINELLA DIAGNÓSTICO DE PROCESSOS EM ORGANIZAÇÕES INTENSIVAS EM SOFTWARE UTILIZANDO UM SISTEMA ESPECIALISTA

Transcrição

1 CHAIENE M. DA SILVA MINELLA DIAGNÓSTICO DE PROCESSOS EM ORGANIZAÇÕES INTENSIVAS EM SOFTWARE UTILIZANDO UM SISTEMA ESPECIALISTA Itajaí(SC), Dezembro de 2014

2 UNIVERSIDADE DO VALE DO ITAJAÍ CURSO DE MESTRADO ACADÊMICO EM COMPUTAÇÃO APLICADA DIAGNÓSTICO DE PROCESSOS EM ORGANIZAÇÕES INTENSIVAS EM SOFTWARE UTILIZANDO UM SISTEMA ESPECIALISTA por Chaiene M. da Silva Minella Dissertação apresentada como requisito parcial à obtenção do grau de Mestre em Computação Aplicada. Orientador: Marcello Thiry, Dr. Co-Orientadora: Anita Maria da Rocha Fernandes, Dra. Itajaí (SC), Dezembro de 2014 ii

3 Dedico esta pesquisa a minha filha Vitória e ao meu pai Valdemiro e à minha mãe Fátima. iii

4 As páginas da vida são cheias de surpresas. Há capítulos de alegrias, mas também de tristezas, há mistérios e fantasias, sofrimentos e decepções. Por isso, não rasgue páginas e nem solte capítulos. Não se apresse em descobrir os mistérios. Não perca as esperanças, pois muitos são os finais felizes. E nunca se esqueça do principal: No livro da vida, o autor é VOCÊ. (Desconhecido)

5 AGRADECIMENTOS Primeiramente agradeço a Deus, essa luz que me guia dia após dia e me dá forças para enfrentar todos os obstáculos. Aos meus pais Fátima e Valdemiro que sempre me apoiaram e nunca deixaram de acreditar que o estudo é a maior das heranças. A toda minha família, especialmente as minhas irmãs Iassanã e Thayná que me ajudaram a cuidar da Vitória sempre que precisei me ausentar. Ao professor Marcello Thiry que esteve comigo durante toda esta trajetória, me orientando e dando apoio, na conclusão deste trabalho. A professora Anita, que me orientou nos assuntos relacionados a inteligência artificial. A todos os outros professores da Univali, pela excelência na condução do mestrado. Aos meus amigos Rafael, Sidnei e Débora, que me ajudaram nas avaliações. A todos os outros amigos e familiares que sempre me perguntavam do andamento do mestrado e se mostravam interessados na pesquisa. As organizações e especialistas que me apoiaram nas avaliações. À todos vocês, o meu MUITO OBRIGADA, vindo do coração.

6 DIAGNÓSTICO DE PROCESSOS EM ORGANIZAÇÕES INTENSIVAS EM SOFTWARE UTILIZANDO UM SISTEMA ESPECIALISTA Chaiene M. da Silva Minella 12/2014 Orientador: Marcello Thiry, Dr. Co-Orientadora: Anita Maria da Rocha Fernandes, Dra. Área de Concentração: Computação Aplicada Linha de Pesquisa: Engenharia de Software Palavras-chave: Ciclo de Vida de Desenvolvimento, Melhoria de Processos de Software, Avaliação, Diagnóstico. Número de páginas: 163 RESUMO O mercado de desenvolvimento de software busca cada vez mais qualidade de seus produtos desenvolvidos. Muitas organizações têm investido em processos de avaliação e melhoria de software com o intuito de se tornarem cada vez mais competitivas, lançando no mercado produtos com alta qualidade. O presente estudo propõe a construção de uma base de conhecimento explorando características do ciclo de vida e processos adotados pelas organizações como forma de obter o diagnóstico inicial do desenvolvimento de software como um todo, utilizando um sistema especialista, construído com o auxílio de árvores de decisão. Para tanto, a ferramenta de sistema especialista, juntamente com a base de conhecimento e com o apoio de organizações desenvolvedoras de software e especialistas na área de melhoria de processos, foram utilizados para permitir uma visão geral do processo de desenvolvimento de software da organização. O diagnóstico realizado através do sistema especialista traz como resultados pontos fortes, pontos fracos e oportunidades de melhorias nas organizações entrevistadas. A abordagem GQM, foi utilizada a fim de avaliar a contribuição obtida com a utilização do sistema especialista nas organizações, demonstrando resultados, em sua maioria, positivos trazendo confiabilidade e produtividade na condução do processo de melhoria do desenvolvimento de software, especialmente na visão dos especialistas.

7 DIAGNOSTIC PROCESS IN INTENSIVE ORGANIZATIONS IN SOFTWARE USING AN EXPERT SYSTEM Chaiene M. da Silva Minella 12/2014 Advisor: Marcello Thiry, Dr. Co-Advisor: Anita Maria da Rocha Fernandes, Dra. Area of Concentration: Applied Computer Science Research Line: Software Engineering Keywords: Lifecycle Development, Software Process Improvement, Evaluation, Diagnostic. Number of pages: 163 ABSTRACT The software development market is looking increasingly quality of its products developed. Many organizations have invested in processes of evaluation and improvement of software in order to become increasingly competitive, attempting to market products with high quality. This paper proposes the establishment of a knowledge base exploring life cycle characteristics and processes adopted by organizations as a way to get the initial diagnosis of software development as a whole, using an expert system, built with the aid of decision trees. Therefore, the expert system tool, along with the knowledge base and with the support of software developer s organizations and experts in the field of process improvement, were used to allow an overview of the organization's software development process. The diagnosis made by the expert system brings as strengths results, weaknesses and opportunities for improvements in the interviewed organizations. The GQM approach was used to assess the contribution obtained with the use of expert systems in organizations, demonstrating results, mostly positive bringing reliability and productivity in the conduct of the software development process improvement, especially in view of experts.

8 LISTA DE ILUSTRAÇÕES Figura 1. Visão geral do trabalho proposto Figura 2. Modelo Cascata Figura 3. Modelo Evolucionário Figura 4. Modelo Espiral Figura 5. Modelo Incremental Figura 6. Diagrama do ciclo de vida Incremental e Iterativo Figura 7. extreme Programming Figura 8. Visão geral do Scrum Figura 9. Fluxo de atividades do Scrum Figura 10. Dimensões do RUP Figura 11. Grupos de Processos de Ciclo de Vida Figura 12. Modelo conceitual de processo de avaliação Figura 13. Fluxograma de implantação de melhorias Figura 14. Visão geral do processo de avaliação de contextualização Figura 15. Arquitetura do sistema especialista Figura 16. Metodologia Figura 17. Trecho da árvore inicial Figura 18. Trecho da árvore Requisitos Figura 19. Trecho da árvore Projeto Figura 20. Trecho da árvore de solução técnica Figura 21. Trecho da árvore Construção Figura 22. Trecho da árvore Testes Figura 23. Trecho da árvore de documentação Figura 24. Trecho da árvore Manutenção Figura 25. Trecho contendo uma regra de produção Figura 26. Trecho das perguntas feitas pelo Sistema Especialista Figura 27. Trecho dos resultados emitidos pelo Sistema Especialista Figura 28. Visão geral do processo de entrevistas Figura 29. Fluxo de atividades Figura 30. Avaliação GQM Organizações Figura 31. Avalição GQM Especialistas Figura 32. Distribuição das respostas de acordo com a classificação (Especialistas) Figura 33. Distribuição das respostas de acordo com a classificação (Organizações) Figura 34. Total de trabalhos retornados Figura 35. Distribuição por data de publicação Quadro 1. CMMI - Áreas de processo Quadro 2. Processos do MR-MPS-SW Quadro 3. Exemplo de trecho de uma regra de produção Quadro 4. Trabalhos relacionados Quadro 5. PICOC para a primeira pergunta Quadro 6. PICOC para a segunda pergunta Quadro 7. Representação da entrevista relacionada a árvore inicial Quadro 8. Características dos entrevistados Quadro 9. Características das organizações

9 Quadro 10. Regras de Produção Quadro 11. Definição das métricas para o objetivo G1 segundo a abordagem GQM Quadro 12. Definição das métricas para o objetivo G2 segundo a abordagem GQM Quadro 13. Métricas para avaliação da abordagem Quadro 14. Atributos de avaliação do framework Quadro 15. Interpretação da adequação da abordagem* Quadro 16. Interpretação da aderência da abordagem* Quadro 17. Perfil das organizações Quadro 18. Perfil dos entrevistados nas organizações Quadro 19. Perfil dos especialistas Quadro 20. Interpretação da avaliação subjetiva da abordagem Quadro 21. Avaliação dos entrevistados Quadro 22. Avaliação dos dados Quadro 23. Caminho para as árvores

10 LISTA DE TABELAS Tabela 1. Fonte de Dados Tabela 2. Estudos que adotam modelos de ciclo de vida em suas abordagens Tabela 3. Artigos retornados Tabela 4. Trabalhos selecionados Tabela 5. Trabalhos selecionados com base nas strings do trabalho anterior

11 LISTA DE ABREVIATURAS E SIGLAS ABNT ANSI CMMI CMMI-DEV CMMI-ARC CMMI-SVC GQM IA IEC IEEE ISO MA-MPS MCA MPE MPS MPS.BR MPS-SW MPS-SV MR-MPS MR-MPS-SW MR-MPS-SV OWPL PICOC PMBOK QIP RUP SDLC SCAMPI SE SEI SWEBOK TI UNIVALI USA XP Associação Brasileira de Normas Técnicas American National Standards Institute Capability Maturity Model Integration Capability Maturity Model Integration for Development Appraisal Requirements for CMMI Capability Maturity Model Integration for Services Goal Question Metric Inteligência Artificial International Electrotechnical Commission Institute of Electrical and Electronics Engineers International Organization for Standardization Modelo de Avalição para Melhoria de Processo de Software Mestrado em Computação Aplicada Micro e Pequenas Empresas Melhoria de Processo de Software Melhoria de Processo de Software Brasileiro Melhoria de Processo de Software Melhoria de Processo de Software para Serviços Modelo de Referência para Melhoria de Processo de Software Modelo de Referência para Software Modelo de Referência para Serviços Observatoire des Wallon Pratiques Logicielles Population, Intervention, Comparison, Outcames and Context Project Management Body of Knowledge Quality Improvement Paradigm Rational Unified Process Software Development Life Cycle Standard CMMI Appraisal Method for Process Improvement Sistema Especialista Software Engineering Institute Software Engineering Body of Knowledge Tecnologia da Informação Universidade do Vale do Itajaí United States of America extreme Programming

12 SUMÁRIO 1 INTRODUÇÃO PROBLEMA DE PESQUISA Solução Proposta Delimitação de Escopo Justificativa OBJETIVOS Objetivo Geral Objetivos Específicos METODOLOGIA Metodologia da Pesquisa Procedimentos Metodológicos FUNDAMENTAÇÃO TEÓRICA MODELOS DE CICLO DE VIDA DE DESENVOLVIMENTO Modelo Cascata Modelo Evolucionário Modelo Espiral Modelo Incremental Modelo Incremental e Iterativo PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE Extreme Programming (XP) Scrum RUP MODELOS DE REFERÊNCIA DE AVALIAÇÃO DE PROCESSOS CMMI MPS.BR CORPO DE CONHECIMENTO PARA ENGENHARIA DE SOFTWARE (SWEBOK) NORMA ISO/IEC AVALIAÇÃO DE SOFTWARE Avaliação de Processo de Software Automatização de Diagnóstico SISTEMA ESPECIALISTA ESTADO DA ARTE REVISÃO EXPLORATÓRIA Trabalhos Relacionados Análise dos Trabalhos Relacionados MAPEAMENTO SISTEMÁTICO Objetivo Principal... 73

13 3.2.2 Protocolo de Busca Questões de Pesquisa Fontes de Dados Palavras Chave String de Busca Critérios de Inclusão e Exclusão Extração dos Dados Análise dos Trabalhos Selecionados Resultados Considerações Finais MODELO PROPOSTO VISÃO GERAL METODOLOGIA PARA CONSTRUÇÃO E AVALIAÇÃO DA BASE DE CONHECIMENTO Revisão da Literatura Modelagem das Árvores de Decisão Regras de Produção Ferramenta de Sistema Especialista Avaliação da Base de Conhecimento Aplicação do Diagnóstico O SISTEMA ESPECIALISTA DESENVOLVIDO AVALIAÇÃO ENTREVISTAS MODELO DE AVALIAÇÃO Avaliação pelo Método GQM RESULTADOS Perfil dos participantes Resultados das métricas subjetivas Avaliação Síntese dos resultados Considerações CONCLUSÃO PRINCIPAIS CONTRIBUIÇÕES TRABALHOS FUTUROS REFERÊNCIAS APÊNDICE A Mapeamento Sistemático A1 String de Busca A2 Resultado da Extração dos Dados APÊNDICE B Árvores

14 APÊNDICE C Questionário de avaliação para as organizações APÊNDICE D Questionário de avaliação para os especialistas

15 15 1 INTRODUÇÃO Com as mudanças que vem surgindo nos ambientes de negócios, as empresas de software têm buscado mudar suas estruturas organizacionais e processos, para seguir em direção a redes de processos centradas no cliente. Os estabelecimentos de conexões nestas redes criam elos entre as cadeias produtivas. Chegar em um nível elevado de qualidade, para as empresas de software, implica em alcançar a competitividade tanto na melhoria da qualidade dos produtos de software e serviços, como dos processos de produção de distribuição do software (SOFTEX, 2012). O processo de software é um conjunto de atividades que tem por finalidade gerar um produto de software, em que os modelos de processo representam esse processo. A padronização, medição e gerenciamento destes processos pode aperfeiçoa-los, aprimorando a comunicação e redução no tempo de treinamento, fazendo com que o processo automatizado seja mais econômico (SOMMERVILLE, 2007). Pensando nisso, muitas organizações estão investindo em avaliação e melhoria de seus processos, tendo como resultado a melhoria contínua dos mesmos, uma vez que pesquisas mostram que a qualidade do produto de software depende da qualidade de seus processos de desenvolvimento (FUGGETTA, 2000). Os modelos e normas não descrevem os processos a serem seguidos pelas organizações. A definição de um processo de desenvolvimento é responsabilidade da organização avaliada e existem vários fatores que influenciam esta definição como, estrutura, tamanho da organização, incluindo o domínio da aplicação (SEI, 2010a). O objetivo dos modelos é assegurar a visibilidade dos processos relativos aos produtos de software. A maioria dos modelos tem como objetivo a organização como um todo, não se preocupando com cada processo de trabalho, indivíduo, equipe ou características individuais de cada projeto (TONINI, SPINOLA e CARVALHO, 2008). Sendo assim, as organizações têm investindo em projetos de melhoria de processo de software, com o intuito de se tornarem mais competitivas, buscando atender as necessidades dos clientes, que buscam mais qualidade para seus produtos de software (CERDEIRAL, 2008). Segundo Rocha (2009), os responsáveis por manter e evoluir os processos de software, é a melhoria na qualidade de processos.

16 16 Em um processo de desenvolvimento de software, a escolha de um modelo de ciclo de vida, é o início para a arquitetura de um processo (PAULA FILHO, 2005). O processo de desenvolvimento de software também chamado de ciclo de vida do software, descreve a vida do produto de software desde a concepção passando pela implementação, entrega, utilização e manutenção (PFLEEGER, 2004). A definição do ciclo de vida de software permite a visão completa do desenvolvimento do software. Com isto, é possível definir etapas que abrangem desde a análise dos requisitos até a entrega do software para o cliente. O ciclo de vida permite detectar os erros o mais rápido possível e assim manter a qualidade do software, os prazos da sua realização e os custos associados. Para dar início a identificação do ciclo de vida do software é necessário mapear a situação atual do processo. Essa verificação inicial é o diagnóstico do processo. Tipicamente, essa atividade é realizada através de entrevistas que visam a modelagem de processos a partir de reuniões com a participação dos envolvidos, que são os principais atores da organização (THIRY et al., 2006). Nas entrevistas iniciais que tem por objetivo mapear o processo de desenvolvimento e obter um diagnóstico inicial, é possível analisar o desenvolvimento de forma ampla, o que nem sempre é possível aos olhos de gerentes e coordenadores, que no dia a dia não conseguem verificar e analisar possíveis pontos fracos a serem melhorados ou oportunidades de melhorias a serem implementadas. Após a atividade de diagnóstico, é necessário que um especialista na área de processos analise as informações do mesmo e emita um parecer sobre o processo. Esta atividade por ser complexa do ponto de vista da análise das informações, deve ser realizada apenas por um profissional capacitado para poder avaliar o resultado do diagnóstico. Todo este processo implica na contratação de mão de obra especializada, o que gera um custo alto para a organização, principalmente para as de pequeno porte (MOREIRA, 2012). Uma pesquisa iniciada por Moreira (2012) define uma abordagem de autodiagnostico utilizando sistemas especialistas, apoiado por uma ferramenta web, que permite mapear pontos fortes e fracos do processo de uma organização. Nesta pesquisa não há um recurso que possa mapear o ciclo de vida adotado na organização, com entrevistas que pudessem abranger todo o processo de desenvolvimento de software. O trabalho em questão avaliou o gerenciamento de requisitos e gerenciamento de projetos no nível G do MPS.BR, utilizando árvores de decisão para gerar regras de produção que pudessem incrementar uma base de conhecimento para gerar os resultados.

17 17 De acordo com Nunes (2009) uma árvore de decisão é definida como sendo uma representação gráfica de um instrumento de apoio a tomada de decisão, gerada a partir de uma decisão inicial. Uma das vantagens de uma árvore de decisão é a possibilidade de transformar um problema complexo em vários subproblemas mais simples e de uma forma recursiva, os subproblemas identificados voltam a ser decompostos em subproblemas ainda mais simples (NUNES, 2009). Este trabalho visa contribuir com a área de melhoria de processos de software através da proposta, desenvolvimento e avaliação de uma abordagem automatizada que apoie as organizações na qualidade de seus processos. O foco desta abordagem está no mapeamento do processo de desenvolvimento adotado por organizações intensivas em software. Um sistema especialista será construído para permitir executar uma série de questionamentos que terá como resultado final o levantamento de informações relevantes para a melhoria do processo de desenvolvimento da organização. 1.1 PROBLEMA DE PESQUISA O mercado de TI (Tecnologia da Informação) tem exigido maior qualidade nos produtos de software, segundo o estudo produzido por Travassos e Kalinowski (2012), no qual revela que as organizações que investem em qualidade de software são mais competitivas. Para alcançar este resultado de modo consistente, as organizações intensivas em software precisam adotar processos de desenvolvimento de software bem estruturados (ALMEIDA, 2011). Para apoiar a definição destes processos, têm sido utilizados modelos de referência com boas práticas e resultados esperados de processo, como os modelos CMMI-DEV (Capability Maturity Model Integration for Development) e MR-MPS-SW (Modelo de Referência para Melhoria de Processos com foco em Desenvolvimento de Software) (SEI; SOFTEX, 2014). Estes modelos têm por objetivo relacionar as melhores práticas, auxiliando organizações a atingir determinados níveis de maturidade. Entretanto, melhorar os processos necessita de tempo e de investimento financeiro, que pode ser alto, dependendo do porte da organização (MIYASHIRO et al., 2011). Organizações que não possuem um processo de desenvolvimento de software definido são facilmente identificadas; não há formalidade na realização das atividades de desenvolvimento de software; não há definição de papéis nos projetos, dificultando a cobrança do andamento do projeto; não há treinamento para os desenvolvedores; não há avaliação de custos e benefícios dos projetos; os

18 18 ambientes de trabalho são inadequados; não utilizam ferramentas para suporte dos seus processos; seus procedimentos e padrões, quando existem, são burocráticos (MIYASHIRO et al., 2011). Com o mercado cada vez mais competitivo, a velocidade com que as organizações respondem as novas demandas, oportunidades e ameaças do mercado, são aspectos que fazem com que haja uma busca por um nível de competitividade. As organizações buscam cada vez mais agilidade nos seus processos, informações e conhecimentos disponíveis e facilmente acessíveis, mas esse conhecimento deve auxiliar de forma inteligente a gestão da organização, para que a mesma consiga se manter no mercado de forma competitiva (BARBIERI, 2001; KALINOWSKI et al., 2010). Programas de Melhoria de Processo de Software (MPS) são conduzidos visando diminuir o retrabalho e aumentar a produtividade das organizações desenvolvedoras de software (ROCHA et al., 2005). Em busca de uma melhor qualidade de seus produtos, uma organização precisa, tipicamente, investir na contratação de especialistas na área de melhoria de processo para avaliar e adaptar os processos, além de treinar o pessoal envolvido. Em geral os altos custos na contratação de consultoria especializada para definir e prestar suporte na implementação dos processos, inviabilizam os investimentos nesta área principalmente em se tratando de organizações pequenas e médias, visto que nem sempre a organização disponibiliza destes recursos. Além disso, o retorno deste investimento não é imediato (MEGA et al., 2008; MIYASHIRO et al., 2011). Uma das principais características das pequenas empresas é a falta de recursos atribuídos a processos de software, em geral, e para funções de melhoria da qualidade, em particular. Na verdade, as estruturas de software de pequeno porte têm, por definição, as equipes pequenas, e as pessoas são absorvidas por assuntos urgentes relacionados aos prazos apertados que estão geralmente ligadas a tarefas de produção. Modelos comuns, como CMMI e ISO/IEC não são facilmente utilizáveis por essas organizações. Eles são muito complicados e tem um custo elevado para se implementar (HABRA et al., 2008). 1 A ISO/IEC 15504, também conhecida como SPICE, é a norma ISO/IEC que define processo de desenvolvimento de software. Ela é uma evolução da ISO/IEC mas possui níveis de capacidade para cada processo assim como o CMMI.

19 19 Para as pequenas e médias organizações a melhoria de processo de software, tem por objetivo inicial, gerar um diagnóstico para identificar a situação da empresa e com isso mapear um planejamento para o programa de melhoria. Esse diagnóstico permite, por exemplo, fazer o levantamento da situação atual dos processos de software utilizados com o objetivo de identificar pontos de melhoria e pontos fracos. Este diagnóstico pode ser realizado de forma simplificada, mas deve se basear na lógica de avaliação seguida pelos métodos de avaliação existentes, sem o rigor de uma avaliação formal (PRIKLADNICKI; BECKER; YAMAGUTI, 2005). Habra et al. (2008) propõem uma abordagem gradual para a melhoria de processo. Numa primeira etapa, uma micro avaliação é usada para coletar informações sobre as práticas atuais de software em pequenas etapas e sensibilizar as pessoas para a importância da qualidade do software. A informação levantada é então utilizada como um ponto de partida para determinar a ideia principal e o objetivo de uma avaliação mais precisa. As grandes empresas, com um nível médio e alto de maturidade podem, eventualmente, implantar a norma ISO/IEC 15504, ou uma avaliação baseada em CMMI (HABRA et al., 2008). Sendo assim, no trabalho realizado por Moreira (2012), percebeu-se a necessidade de uma sistemática que permitisse a realização de um autodiagnostico, fazendo com que uma empresa tenha condições de avaliar seus processos sem a necessidade de contratar um especialista naquele momento. Uma limitação do trabalho de Moreira (2012) foi a ausência de recursos para realizar um levantamento inicial do ciclo de vida de desenvolvimento da organização. Esta limitação dificulta a identificação da sequência de atividades utilizadas pela organização para o desenvolvimento de software. Moreira (2012) não apresenta um conjunto de diálogos automatizados para abranger todo o fluxo de desenvolvimento, uma vez que o foco foi nos processos de gerência de projetos e gerência de requisitos. A materialização do ciclo de vida adotado por uma organização já pode ser considerada uma melhoria, pois permite que a organização tenha uma visão geral da sequência de trabalho e que identifique seus principais pontos fracos. Neste sentido, o objetivo desta pesquisa é evoluir a proposta de diagnóstico de Moreira (2012), visando a construção de um conjunto de diálogos automatizados que complementem o processo de diagnóstico para permitir que ele gere uma visão geral do ciclo de vida adotado pela organização, incluindo a identificação correlacionada de pontos fracos, fortes e possíveis oportunidades de melhoria.

20 20 O conjunto de diálogos automatizados se dá através das perguntas que são emitidas pelo sistema especialista e das respostas informadas por quem é responsável pela a avaliação. Conforme o sistema especialista for avançando para as próximas perguntas o participante vai respondendo e de acordo com as respostas o sistema especialista segue uma direção, emitindo ao final, os resultados com o mapeamento de pontos a serem considerados dentro do processo de desenvolvimento de software. Dentro da problematização apresentada, este trabalho pretende responder a seguinte questão de pesquisa: Uma abordagem baseada em diálogos automatizados, no contexto de um ambiente de diagnóstico semi automatizado, permite modelagem inicial do ciclo de vida adotado em organizações intensivas em software? Solução Proposta Considerando as necessidades apontadas na problematização, o presente trabalho estende a proposta de diagnóstico realizada por Moreira (2012), na qual foi desenvolvida uma abordagem para autodiagnostico de processos de software utilizando sistemas especialistas e visando a melhoria do processo de desenvolvimento. A ferramenta web desenvolvida por Moreira (2012) permite a coleta de dados por meio da aplicação de diálogos com base no nível G do MPS.BR permitindo verificar práticas existentes em relação a gerência de projetos e gerência de requisitos, além de emitir um relatório que indica pontos fortes, pontos fracos e oportunidades de melhoria. O objetivo desta pesquisa é propor a construção de uma nova base de conhecimento explorando características do ciclo de vida e processo de desenvolvimento adotado em organizações intensivas em software, como forma de obter um diagnóstico da situação atual do desenvolvimento como um todo e não somente sob a área de análise de requisitos e gerenciamento de projeto. Para que o trabalho atual possa complementar a pesquisa de Moreira (2012), foi realizado um mapeamento sistemático, a construção de novas árvores de decisão, a criação de novas regras de produção e por fim a construção de um sistema especialista. Para o mapeamento sistemático, foram analisados os trabalhos que continham metodologias de avaliação, descrição dos processos de avalição e resultados obtidos com a aplicação das metodologias nas organizações. Essas informações serviram de base para a construção do processo de avaliação com as organizações e os especialistas, envolvidos nesta pesquisa.

21 21 O presente trabalho propõe a construção de árvores de decisão, com a aplicação de uma avaliação em 3 organizações de desenvolvimento de software, após essa avaliação, as árvores são revisadas, a partir dessa revisão, entrevistas com especialistas são conduzidas com intuito de avaliar os diagnósticos obtidos com a avaliação das árvores junto as organizações. Essas árvores, por sua vez, geram as regras de produção, necessárias para a construção do sistema especialista. O mesmo é avaliado por especialistas em MPS e por organizações de desenvolvimento de software. Após essas avaliações, é então realizada uma revisão no sistema especialista que, por fim, é novamente avaliado por 2 especialistas em MPS. Através do conjunto de diagnósticos, profissionais da área de MPS analisam a base de conhecimento e emitem uma avaliação sob o ponto de vista da aderência do conteúdo da base em relação ao conteúdo utilizado em avaliações de melhoria de processo de software. O conjunto de diagnósticos, também é avaliado pelos responsáveis das organizações sob o ponto de vista da adequação dos resultados à realidade do processo de desenvolvimento de software das mesmas. Em relação ao trabalho de Moreira (2012), a contribuição do mesmo para o trabalho atual se dá através da utilização das 23 árvores de decisão, sendo 7 voltadas para a gerência de requisitos e 16 voltadas para a gerência de projetos, que foram construídas para contemplar o nível G do MPS.BR. Para o trabalho atual foram construídas 33 árvores abrangendo a fundamentação teórica (ver Seção 2). A Figura 1 apresenta uma visão geral do trabalho realizado.

22 22 Figura 1. Visão geral do trabalho proposto Fonte: Próprio autor. Diante do problema apresentado na Seção 1.1 e da solução proposta, foram estabelecidas as seguintes hipóteses: O ciclo de vida de desenvolvimento de software de uma organização pode ser mapeado através de uma abordagem baseada em diálogos automatizados realizados através de um sistema especialista, trazendo resultados similares aos resultados obtidos por um especialista da área de melhoria de processo. A abordagem baseada em diálogos automatizados pode ser avaliada sob o ponto de vista da adequação como sob o ponto de vista da aderência, em relação aos resultados obtidos com o sistema especialista. As avaliações destas hipóteses podem ser obtidas com o resultado do diagnóstico apresentado pela avaliação de especialistas da área de melhoria de processos e organizações de desenvolvimento de software Delimitação de Escopo

23 23 Este trabalho teve enfoque no desenvolvimento de uma abordagem para autodiagnostico do ciclo de vida e processo de desenvolvimento de organizações intensivas em software, utilizando um Sistema Especialista (SE). O foco principal é identificar como estas organizações desenvolvem software, mapeando seu ciclo de vida de desenvolvimento. Este trabalho não pretende realizar uma verificação da aderência dos processos de uma organização ao modelo de referência MR-MPS-SW. Entretanto, foram considerados àqueles resultados que estiveram mais relacionados ao processo de desenvolvimento. Da mesma forma, o modelo de referência CMMI-DEV e a norma ISO/IEC também foram considerados, bem como o corpo de conhecimento para engenharia de software, o SWEBOK. Também foram considerados os processos como XP, RUP e Scrum. Embora o Scrum seja um framework de processo para gerenciamento de projetos, ele será considerado por ter sido criado inicialmente para gerenciar projetos de software. Além disso, as práticas do Scrum têm sido amplamente adotadas por organizações intensivas em software. Não faz parte do escopo deste trabalho modelos e normas que não sejam voltados ao desenvolvimento de software. Portanto modelos de referência como MR-MPS-SV e CMMI-SVC não foram considerados. Para o desenvolvimento desta abordagem foram entrevistadas organizações intensivas em software que trabalhem com projetos, ou seja, que possuam características de fábrica ou desenvolvimento de produtos de software. A avaliação teve como base organizações das regiões de Blumenau e Joinville. Também foram considerados um conjunto de implementadores e avaliadores MPS.BR de várias regiões do país. As avaliações foram realizadas basicamente por compartilhamento do sistema especialista, para facilitar a logística e a utilização do SE. Este estudo limitou-se a fontes de pesquisa na área de melhoria de processos de software. Quaisquer outras áreas ou campos de pesquisa que possam beneficiar-se da abordagem deverão ser tratados em trabalhos futuros. A abrangência da abordagem automatizada está limitada ao conhecimento dos profissionais de MPS e ao conhecimento dos recursos 2 das organizações. 2 Entende-se por funcionários.

24 Justificativa Nos últimos anos as organizações de software estão cada vez mais em uma busca contínua para se obter um melhor serviço e funcionalidade de produto de software. Entretanto, os produtos de software continuam a ter custos elevados, atrasos na entrega e baixa qualidade (GARCÍA, 2010). Os resultados da pesquisa sobre a implementação do programa MPS.BR apresentados por Travassos e Kalinowski (2012) evidenciam a importância da busca por altos níveis de maturidade para uma melhoria da produtividade, qualidade e precisão de estimativa. Em relação à produtividade e o número de projetos, a pesquisa apresentou evidência de que empresas de alto nível de maturidade se mostram mais capazes de lidar com um número maior de projetos sem sacrificar a produtividade individual de cada projeto (TRAVASSOS; KALINOWSKI, 2012). Em relação ao processo, têm-se os modelos de referência bem definidos que são largamente adotados pela indústria e estudos recentes indicam a satisfação das organizações em aplicar estes modelos em seus processos (TRAVASSOS; KALINOWSKI, 2010). No início de um programa de melhoria de processos é fundamental fazer um levantamento da situação atual e mapear pontos fortes e fracos visando ações de melhoria às características e necessidades reais de uma empresa. Geralmente, são feitas avaliações no início do programa de melhoria. Essa avaliação é uma análise dos processos utilizados pela organização, e pode ser feita contra um modelo de referência para determinar a capacidade destes processos na sua execução de acordo com as metas de qualidade, cronograma e custos estabelecidos (ANACLETO; WANGENHEIM; SALVIANO, 2005). Para organizações que não dispõem de recursos financeiros que possibilitem a implantação de um programa de melhoria de processo de software, o diagnóstico inicial por meio de uma auto avaliação, disponibilizada por um sistema especialista, permite o mapeamento do processo buscando pontos fracos e possíveis melhorias, facilitando a busca por uma melhor qualidade no processo da organização e consequentemente na qualidade do produto final. Sendo assim surge à necessidade de uma abordagem de diálogos automatizados, apoiada por uma ferramenta computacional, que permita que as organizações se auto avaliem, reduzindo os custos e a complexidade desta atividade (MOREIRA, 2012). As limitações no trabalho de Moreira (2012), como a falta de um levantamento do ciclo de vida de desenvolvimento, podem resultar na falta de identificação das características do processo da organização.

25 OBJETIVOS Esta seção formaliza os objetivos do trabalho, conforme descrito a seguir Objetivo Geral Desenvolver uma abordagem de autodiagnostico para apoiar o mapeamento do ciclo de vida e processo de desenvolvimento de software adotado para organizações intensivas em software Objetivos Específicos 1) Mapear os diferentes processos de desenvolvimento de software, adotado por organizações, a partir das características das mesmas; 2) Desenvolver um sistema especialista que possa trazer como resultados pontos fracos, pontos fortes e oportunidades de melhoria no processo de desenvolvimento de software adotado por uma organização; 3) Desenvolver uma base de conhecimento que apoie o sistema especialista integrando as árvores de decisão com o conhecimento das árvores de decisão desenvolvidas em Moreira (2012) e 4) Avaliar o sistema especialista por especialistas e a partir de sua aplicação em empresas reais de desenvolvimento de software. 1.3 METODOLOGIA Nesta seção, apresenta-se a metodologia de pesquisa e os procedimentos metodológicos adotados neste trabalho Metodologia da Pesquisa O método científico é importante em computação porque como Ciência ela não pode se limitar apenas da coleta de dados. A explicação dos dados é mais importante (WAZLAWICK, 2010). Neste trabalho utilizou-se o método hipotético dedutivo, e foram utilizados experimentos com empresas de software e especialistas em melhoria de processo, visando como resultado o mapeamento do ciclo de vida e processo de desenvolvimento das organizações.

26 26 O presente trabalho, do ponto de vista de sua natureza, caracteriza-se como uma pesquisa aplicada. Dentro deste contexto, o resultado final visa uma abordagem para mapear o processo adotado pela organização a partir de informações coletadas da ferramenta de autodiagnostico, ou seja, o sistema especialista. Com relação ao ponto de vista da abordagem do problema, este trabalho enquadra-se como uma pesquisa qualitativa. Neste caso a avaliação da abordagem será dada de forma subjetiva. Do ponto de vista dos seus objetivos, considera-se essa pesquisa como exploratória. Utilizou-se a pesquisa bibliográfica baseada em livros, teses e dissertações, artigos de periódicos disponibilizados na internet, para realizar uma fundamentação teórica e guiar o desenvolvimento. Por se tratar de uma pesquisa exploratória, permite-se propor uma visão mais ampla do aspecto da abordagem aplicada para a implantação da melhoria de processo de software Procedimentos Metodológicos O presente trabalho engloba várias etapas, descritas a seguir: 1) Fundamentação Teórica: A fim de criar um embasamento sólido para a fundamentação teórica deste estudo, utiliza-se dos métodos de pesquisa bibliográfica além do conteúdo relacionado aos modelos de ciclo de vida, processos de desenvolvimento de software, modelos de referência e normas, avaliação de software, sistemas especialistas e diagnósticos. 2) Estado da Arte: Nesta etapa, realizou-se uma pesquisa sobre trabalhos correlatos existentes na literatura que fazem o diagnóstico de forma automatizada, bem como as metodologias existentes para o mapeamento de ciclos de vida e processos de desenvolvimento de software, documentando o resultado da pesquisa. Por meio de uma revisão sistemática da literatura identificou-se o grau de originalidade do trabalho e diferenças entre o trabalho proposto frente aos trabalhos similares. 3) Modelo Proposto: Analisando as documentações geradas anteriormente, foram identificados os requisitos necessários para implementar o sistema especialista que apoie o

27 27 mapeamento do ciclo de vida de desenvolvimento de software de uma organização intensiva em software. O modelo foi construído utilizando o conteúdo do mapeamento sistemático e da fundamentação teórica, árvores de decisão, regras de produção, entrevistas com organizações e especialistas em MPS. Os resultados desta etapa foram analisados e documentados, para serem utilizados na etapa seguinte. 4) Avaliação: Utilizou-se a abordagem GQM (Goal/Question/Metrics), proposto por Basili et al. (1994). Foram duas avaliações, uma sob o ponto de vista de profissionais da área de MPS e uma sob o ponto de vista das organizações. Na primeira, foi avaliada a adequação do conteúdo da abordagem em relação ao conteúdo da área de melhoria de processos de software (modelos estudados e a partir das informações coletadas na revisão da literatura). Na segunda, foi avaliada a aderência da abordagem em relação ao resultado emitido pelo sistema especialista. 5) Resultados: O resultado da avaliação foi analisado por especialistas em MPS. Com a abordagem desenvolvida, foram realizados experimentos reais em organizações intensivas em software. O diagnóstico pode ser realizado por meio da ferramenta de sistema especialista e o resultado avaliado por especialistas da área de Melhoria de Processos de Software. Por fim, os resultados obtidos com a avaliação do sistema especialista (experimento real) foram registrados e analisados, dando origem a pelo menos um artigo científico, para submissão em congressos ou periódicos da área de engenharia de software.

28 28 2 FUNDAMENTAÇÃO TEÓRICA Este capítulo tem como objetivo apresentar os principais conceitos teóricos necessários ao desenvolvimento deste trabalho, como: modelos de ciclos de vida de desenvolvimento, processos de desenvolvimento, modelos de referência e normas, avaliação de software e por fim, sistemas especialistas. 2.1 MODELOS DE CICLO DE VIDA DE DESENVOLVIMENTO Os modelos podem ser usados para representar toda a vida desde a concepção até o descarte ou para representar a parte da vida correspondente ao projeto atual. O modelo de ciclo de vida é composto por uma sequência de fases que podem se sobrepor e/ou iterar, conforme apropriado para o escopo do projeto, magnitude, complexidade e necessidades de mudanças e oportunidades. Cada fase é descrita com uma declaração de propósito e resultados. Os processos e as atividades do ciclo de vida são selecionados e empregados em uma fase para cumprir o propósito e os resultados da mesma (ISO/IEC 12207, 2008). Um ciclo de vida de desenvolvimento de Software é a forma de construção do desenvolvimento de um produto de software. Geralmente as atividades relacionadas a cada fase são consideradas um subconjunto de ciclo de vida de desenvolvimento de sistemas. Existem modelos para tais processos, cada um descrevendo abordagens para uma variedade de tarefas ou atividades que ocorrem durante o processo (BHUVANESWARI; PRABAHARAN, 2013). Modelos de ciclo de vida de desenvolvimento de software (SDLC 3 ) descrevem as fases e a ordem em que essas fases são executadas de modo a desenvolver um produto de software. As fases comuns são levantamento de requisitos, especificação, projeto, codificação, testes e manutenção (RAGUNATH, 2010; KHURANA, 2012; CLARA, 2013). Cada fase produz resultados finais exigidos pela próxima fase do ciclo de vida. Existe grande variedade de modelos de desenvolvimento de cada um com os seus procedimentos e passos específicos. (GUPTA; AGGARWAL, 2012). 3 Software Development Life Cycle (Ciclo de vida de desenvolvimento de software)

29 29 Modelos de ciclo de vida de desenvolvimento de software são mecanismos que garantem que o software atenda aos requisitos estabelecidos. Estes modelos impõem vários graus de disciplina para o processo de desenvolvimento de software com o objetivo de tornar o processo mais eficiente e previsível. Nos dias de hoje, as empresas têm diversas opções de modelos a adotar para o desenvolvimento de software. Cada modelo satisfaz a necessidade específica de cada cliente (KHURANA; GUPTA, 2012). O modelo de ciclo de vida de desenvolvimento de software refere-se às fases do processo de desenvolvimento. Na produção de um software há um ciclo de vida ou uma série de fases que, naturalmente, estão interligadas. O modelo de ciclo de vida descreve as fases envolvidas no desenvolvimento de software, a partir de um estudo de viabilidade (CLARA, 2013). Dentre os modelos de ciclos de vida de desenvolvimento de software existentes na literatura, pode-se destacar os modelos cascata, evolucionário, espiral, incremental e incremental iterativo (PAULA FILHO, 2009; PRESSMAN, 2010; SOMMERVILLE, 2007). As fases são, por vezes, decompostas em partes menores, descritas como atividades. Uma atividade pode ser considerada simplesmente como um conjunto de tarefas (ISO/IEC 12207, 2008) Modelo Cascata O modelo cascata é o modelo clássico da engenharia de software. Este modelo é um dos mais antigos e é muito utilizado em projetos de grandes empresas (VERMA et al., 2013). Ainda, segundo Verma et al. (2013), o modelo enfatiza o planejamento nas fases iniciais, pois evita falhas de projeto antes mesmo que elas se desenvolvam. O modelo cascata contém várias fases não sobrepostas, como apresentado na Figura 2. O modelo começa com o estabelecimento de requisitos de sistema e requisitos de software e continua com o projeto arquitetônico, projeto detalhado, codificação, testes e manutenção. O modelo cascata serve como base para vários outros modelos de ciclo de vida (VERMA et al., 2013). De acordo com Ragunath et al. (2010), o modelo cascata possui as seguintes características: Fases de especificação e desenvolvimento separadas e distintas; Todas as atividades de forma linear e

30 30 A próxima fase só começa quando a primeira está completa. A Figura 2, representa o modelo cascata de acordo com Verma et al. (2013). Figura 2. Modelo Cascata Fonte: Adaptado de Verma et al. (2013). A lista a seguir detalha as etapas utilizadas no modelo Cascata, de acordo com a Figura 2: 1) Requisitos de Sistema: Estabelecem os componentes para a construção do sistema, incluindo os requisitos de hardware, ferramentas de software e outros componentes necessários. Exemplos incluem decisões sobre hardware, como placas e as decisões sobre peças externas de software, tais como bancos de dados ou bibliotecas. 2) Requisitos de Software: Estabelecem as expectativas para a funcionalidade do software e identifica quais os requisitos do sistema afetam o software. Análise de requisitos inclui determinar a interação necessária com outras aplicações e bancos de dados, requisitos de desempenho e requisitos de interface do usuário. 3) Projeto Arquitetônico: Determina o framework do sistema, necessário para atender os requisitos específicos de software. Esta fase define os componentes principais e a interação dos mesmos. As interfaces externas e ferramentas utilizadas no projeto podem ser determinadas nesta fase. 4) Projeto Detalhado: Examina os componentes de software definidos na fase anterior e produz uma especificação de como cada componente é implementado. 5) Codificação: Implementa a especificação detalhada do projeto. 6) Testes: Determina se o software atende aos requisitos especificados e encontra erros presentes no código.

31 31 7) Manutenção: Aborda os problemas e pedidos de melhorias após os lançamentos de software. Em algumas organizações, o controle de mudanças mantém a qualidade do produto, revendo cada alteração feita na fase de manutenção Modelo Evolucionário O objetivo deste modelo é descrever um processo no qual o software pode ser desenvolvido a partir da evolução de protótipos iniciais. Este modelo é baseado na prototipação (ou prototipagem), que sugere uma abordagem baseada numa visão evolutiva do desenvolvimento de software. Esta abordagem produz versões iniciais (protótipos) com a qual podem ser realizadas verificações e experimentações, a fim de avaliar os requisitos antes que o software venha a ser desenvolvido por completo (BARROS, 2011). Um protótipo tem por objetivo permitir que os usuários do software possam avaliar propostas dos desenvolvedores através de um desenho do produto final, ao invés da interpretação e avaliação do projeto somente com base em descrições. A prototipação também pode ser usada por usuários finais para descrever e comprovar os requisitos que os desenvolvedores não consideraram, e que pode ser um fator chave na relação comercial entre os desenvolvedores e seus clientes. A prototipação envolve as seguintes etapas (GUPTA; AGGARWAL, 2012): 1) Identificar os requisitos básicos, através de análise dos itens a serem implementados; 2) Desenvolver protótipo inicial, como forma de fazer uma apresentação gráfica do que será desenvolvido; 3) Os clientes, incluindo usuários finais, examinam o protótipo e fornecem um feedback sobre aditamentos ou alterações e 4) Usando o feedback tanto as especificações quanto o protótipo podem ser melhorados (GUPTA; AGGARWAL, 2012). Na Figura 3, segue uma representação de como é o ciclo de desenvolvimento para o modelo evolucionário.

32 32 Figura 3. Modelo Evolucionário Fonte: Sommerville (2007). O modelo evolucionário ou prototipação, segundo Carvalho e Chiossi (2001) pode ser de dois tipos: desenvolvimento exploratório, em que o objetivo do processo é trabalhar junto com o usuário para descobrir seus requisitos, de maneira incremental até alcançar o produto final; e o protótipo descartável que objetiva entender os requisitos do usuário para obter uma melhor definição dos requisitos do sistema. O objetivo desta seção foi apresentar o modelo exploratório, uma vez que o foco do trabalho está no ciclo de desenvolvimento Modelo Espiral O modelo em espiral é semelhante ao modelo incremental, com mais ênfase colocada na análise de risco. O modelo espiral tem quatro fases: Planejamento, Análise de Risco, Engenharia e Avaliação. Um projeto de software passa repetidamente através dessas fases através de iterações (neste modelo, chamadas de espirais). A espiral da linha de base, a partir da fase de planejamento, os requisitos estão reunidos e o risco é avaliado. Cada espiral subsequente baseia-se na linha de base da espiral. Os requisitos são recolhidos durante a fase de planejamento. Na fase de análise de risco, um processo é realizado para identificar soluções de risco e alternativas. Um protótipo é produzido no final da fase de análise de risco. O software é produzido na fase de engenharia, juntamente com o teste no final da fase. A fase de avaliação permite o cliente avaliar a saída do projeto antes que o projeto continue para a próxima espiral. No modelo de espiral, o componente angular representa progredir, e o raio da espiral representa custo (MUNASSAR; GOVARDHAN, 2010). A Figura 4 representa o modelo espiral.

33 33 Figura 4. Modelo Espiral Fonte: Sommerville (2007) Modelo Incremental No modelo incremental, tem-se como primeiro incremento o núcleo do produto, onde apenas os requisitos básicos são definidos. Esse núcleo do produto é enviado para o cliente e um próximo incremento é desenvolvido (PRESSMAN, 2010). O modelo incremental combina elementos do modelo em cascata aplicado de maneira incremental, conforme ilustrado na Figura 5. Cada sequência linear produz incrementos do software passíveis de serem entregues. Em cada incremento é realizado todo o ciclo do desenvolvimento de software, do planejamento aos testes do sistema já em funcionamento. Cada etapa produz um sistema totalmente funcional, apesar de ainda não cobrir todos os requisitos.

34 34 Figura 5. Modelo Incremental Fonte: Pressman (2010). Pode-se notar pela Figura 5 que o modelo incremental aplica sequências lineares (como no modelo cascata) de forma escalonada, à medida que o tempo do projeto for avançando. Cada uma das sequencias lineares gera um incremento do software. Esses incrementos são entregáveis e estão prontos para o cliente Modelo Incremental e Iterativo O modelo incremental corresponde à ideia de aumentar pouco-a-pouco o sistema em sucessivos incrementos. Por sua vez, o modelo iterativo corresponde à ideia de refinar o sistema pouco-a-pouco. A essência do sistema não é alterada, mas o seu detalhe vai aumentando em iterações sucessivas (SILVA; VIDEIRA, 2001). O desenvolvimento iterativo é uma abordagem para a construção de software, em que o ciclo de vida total é composto de várias iterações em sequência. Cada iteração é um mini projeto independente composto por atividades como análise de requisitos, design, programação e teste (LARMAN, 2004) O modelo Incremental e Iterativo, é a união destes dois modelos, onde para cada requisito é definido o que é mais importante e o que é menos importante, assim um número de incrementos para

35 35 entrega é definido, com cada incremento fornecendo um subconjunto das funcionalidades do sistema. Após a priorização dos incrementos, os requisitos são detalhados. Em seguida, iterações são criadas e um processo mini cascata é iniciado. Depois de desenvolvidas as iterações, as mesmas são entregues. A medida que novos incrementos são construídos eles vão sendo agregados aos já existentes (LARMAN, 2004; SOMMERVILLE, 2007). Iterações são passos em fluxo de trabalho e incrementos são crescimentos do produto, conforme a Figura 6. Figura 6. Diagrama do ciclo de vida Incremental e Iterativo Fonte: Larman (2004). No modelo Incremental e Iterativo, mesmo que todas as fases tenham uma única iteração, o modelo ainda é diferente do Cascata, pois permite que cada iteração passe por todas as atividades. Tipicamente, este modelo de ciclo de vida consegue compreender tanto o desenvolvimento (ciclo inicial) de um produto quanto a sua manutenção (ciclos evolutivos). 2.2 PROCESSOS DE DESENVOLVIMENTO DE SOFTWARE Atualmente, as organizações buscam cada vez mais, uma forma de alcançar a melhoria no processo de desenvolvimento do software, por meio da formalização de seus processos. Os processos de desenvolvimento de software possibilitam a melhoria na qualidade dos produtos desenvolvidos.

36 36 Na literatura existem muitos conceitos em relação a processos de software. Para Fugetta (2000) Um processo de software pode ser definido como um conjunto coerente de políticas, estruturas organizacionais, tecnologias, procedimentos e artefatos que são necessários para conceber, desenvolver, implantar e manter um produto de software. Pressman (2006) define Processo de software como um arcabouço para as tarefas que são necessárias para construir software de alta qualidade. Já para, Sommerville (2007) Um processo de software é um conjunto de atividades, métodos e práticas utilizados para produzir um software. Contudo processo de software nada mais é que uma sequência de atividades, a serem aplicadas sistematicamente por pessoas que desenvolvem e mantém um produto de software e os artefatos associados como projeto, documentação de projeto, planos de teste, códigos, protótipos, casos de teste e manuais. Essas atividades podem ser agrupadas em fases que possuem entradas e produzem saídas. A fim de especificar quais atividades devem ser executadas e em qual ordem, têm-se os modelos de processo de software. O modelo de processo de software consiste de um conjunto de atividades realizadas para criar, desenvolver e manter sistemas de software. Uma variedade de modelos de processos de software foi concebida para estruturar, descrever e prescrever o processo de desenvolvimento de software. Os modelos de processo de software desempenham um papel muito importante no desenvolvimento de software, de modo que forma o núcleo do produto de software (KAUR, 2011). Dentre os processos de desenvolvimento de software da literatura estão o XP, Scrum e RUP. O presente trabalho irá utilizar em seus estudos esses três processos por se tratarem de serem os mais citados na literatura, apesar de não ter sido encontrada uma métrica que determine que os três são os mais citados. O XP é projetado principalmente para equipes menores com dois a dez membros (FOJTIK, 2011). O RUP se encaixa tanto para pequenas equipes, como para grandes organizações de desenvolvimento (IBM, 2001). O Scrum é um framework voltado para gerenciamento de projetos (SCHWABER, 2004). A utilização do Scrum e do XP nesta pesquisa é importante devido ao seu grau de utilização nas organizações, ultimamente e o RUP por envolver os modelos mais clássicos. Processos ágeis são aplicados em projetos em que há muitas mudanças, em que os requisitos são passíveis de alterações, onde refazer partes do código não é uma atividade que apresenta alto custo, as equipes são pequenas, as datas de entrega são curtas e o desenvolvimento rápido é fundamental. Enquanto no ciclo de vida

37 37 tradicional as equipes de desenvolvimento costumam realizar uma reunião com os stakeholders para obter todos os requisitos detalhados em fases precoces do processo de desenvolvimento. Em seguida, as equipes de desenvolvimento iniciam a fase de construção. A fase de testes, só terá início quando todo o processo de codificação for concluído (LEAU et al., 2012). É importante que a equipe de desenvolvimento selecione o processo que melhor se adapte ao projeto. Existem alguns critérios que a equipe de desenvolvimento pode usar para identificar o processo desejado, estes incluem o tamanho da equipe, situação geográfica, o tamanho e a complexidade do software, tipo de projeto, estratégia de negócios, capacidade de engenharia, entre outros. Também se faz necessário estudar as diferenças, vantagens e desvantagens de cada um dos tipos de processo. Além disso, a equipe deve analisar o contexto de negócios, as exigências da indústria e estratégia de negócios para ser capaz de avaliar o processo de desenvolvimento (LEAU et al., 2012) Extreme Programming (XP) O processo de desenvolvimento de software ágil como Extreme Programming tenta diminuir o custo da mudança e com isso reduzir os custos globais de desenvolvimento. O elemento principal do ciclo de vida do XP é a "iteração". A iteração é um evento recorrente na qual uma versão atual é editada, por exemplo, adicionando uma funcionalidade, corrigindo erros ou removendo uma funcionalidade desnecessária. O resultado de cada iteração é validado através de um teste de aceitação. No XP a duração de cada iteração é muito curta (1-4 semanas) em comparação com o desenvolvimento de software tradicional. Assim, a fase de planejamento, também é muito curta e realizada principalmente pela definição de tarefas (DUMKE et al., 2008). O XP possui 5 valores (BECK, 2004): 1) Comunicação: Muitos problemas de desenvolvimento se encontram na comunicação incorreta entre membros da equipe de desenvolvimento e até mesmo com o cliente. Para resolver isso, o XP pratica a comunicação frequente. Grandes equipes de desenvolvimento atribuem um papel especial, chamado de treinadores, onde os mesmos detectam falhas de comunicação e praticam a comunicação correta entre todos os envolvidos;

38 38 2) Simplicidade: O processo XP, diz que não deve-se criar uma arquitetura mais robusta do que o necessário para o momento, o processo procura desenvolver software tão fácil quanto possível, para lidar com todas as funcionalidades que não são importantes atualmente e que podem ser trabalhadas no futuro; 3) Feedback: É muito importante para o desenvolvimento correto. Está em vários níveis. Um deles é o teste, que deve ser realizado em todas as fases de desenvolvimento e não após a fase de implementação; 4) Coragem: Um valor muito importante do XP é a coragem de corrigir e remover os erros a todo custo. Ele ainda significa remover uma grande parte do código ou a parte fundamental e tão logo refazer o projeto de arquitetura. De acordo com a experiência com o uso prático de XP nas empresas, parece que este requisito é difícil de ser aplicado. Os desenvolvedores acham que a remoção de uma grande parte do código assina seu fracasso e eles são menos propensos a tentar mais; 5) Respeito: Os membros da equipe devem estar interessados no trabalho de seus colegas. No caso de indivíduos que trabalham sozinhos, sem relações estreitas com os outros o XP será inútil. O XP possui doze práticas que consistem no núcleo principal do processo e que foram criadas com base nos ideais pregados pelos valores. Segundo Beck (2004), um dos criadores do XP, estas práticas não são novidades, mas sim práticas que já vêm sendo utilizadas a muitos anos, com eficiência, em projetos de software. As doze práticas do XP são (BECK, 2004): 1) Jogo de Planejamento (Planning Game): Determina o escopo das próximas versões combinando a prioridades do negócio e estimativas técnicas. Como prática, estrutura e atualização do plano. 2) Fases pequenas (Small Releases): Rapidamente um sistema simples consegue ir para produção, e o atualiza frequentemente em ciclos curtos. 3) Metáfora (Metaphor): A intenção da metáfora é oferecer uma visão geral do sistema, em um formato simples, que possa ser compartilhada por clientes e programadores.

39 39 4) Projeto Simples (Simple Design): O sistema precisa ser projetado o mais simples possível satisfazendo os requisitos atuais. 5) Testes constantes: Os testes em XP são feitos antes da programação. Existem dois tipos de teste: teste de unidade e teste funcional. 6) Refactoring: Os times procuram aperfeiçoar o projeto do sistema durante todo o desenvolvimento, mantendo a clareza do software: sem ambiguidade, com alta comunicação, simples, porém completo. 7) Programação em pares (Pair Programming): Todo o código produzido em XP é escrito por um par de programadores, que possuem papéis distintos, sentados lado-a-lado e trabalhando no mesmo computador. 8) Padronização do Código (Coding Standards): A equipe de desenvolvimento precisa estabelecer regras para programar e todos devem seguir estas regras. Desta forma parecerá que todo o código fonte foi editado pela mesma pessoa, mesmo quando a equipe possui 10 ou 100 membros. 9) Propriedade coletiva (Colletive ownership): Todo o código pertence a todo o time. Então, qualquer um pode alterar qualquer código em qualquer tempo. 10) Integração Contínua (Continuous Integration): Sempre que produzir uma nova funcionalidade, nunca esperar uma semana para integrar à versão atual do sistema. Isto só aumenta a possibilidade de conflitos e a possibilidade de erros no código fonte. Integrar de forma contínua permite saber o status real da programação. 11) Semana de 40-horas (40-hour week): Como regra, não se deve trabalhar mais que 40 (quarenta) horas na semana. Programadores exaustos cometem mais erros. 12) Cliente no local (On-site customer): Deve ser incluído na equipe uma pessoa da parte do cliente, que irá usar o sistema, para trabalhar junto com os outros e responder as perguntas e dúvidas. As características gerais do ciclo de vida XP são mostradas na Figura 7.

40 40 Figura 7. extreme Programming Fonte: Adaptado de Wells (2000). O processo de desenvolvimento de software XP foi projetado para uso iterativo com um breve planejamento (3 meses para releases e iterações de 1-2 semanas). No XP, uma liberação corresponde a uma versão, entregue para o cliente que poderá utilizá-la. Iterações são mais curtas que os incrementos de desenvolvimento onde as tarefas individuais são atribuídas aos desenvolvedores e um protótipo funcional do sistema é desenvolvido e periodicamente avaliados pelos participantes do projeto. As práticas do XP não incluem uma extensa preparação de requisitos ou documentos de projeto antes de iniciar o desenvolvimento. Consequentemente, o XP é fortemente dependente da contínua comunicação entre as partes interessadas (LAYMAN, 2006) Scrum Scrum é um framework que está sendo usado para gerenciar o desenvolvimento de produtos complexos desde o início de Scrum não é um processo ou uma técnica para construir produtos, em vez disso, é um framework dentro do qual você pode empregar vários processos ou técnicas (SCHWABER, 2011). Baseia-se, em princípios como: equipes pequenas; com requisitos que são pouco estáveis ou desconhecidos; com pequenos ciclos que divide o desenvolvimento em intervalos de tempos de no máximo 30 dias, também chamados de sprints (SCHWABER, 2004).

41 41 O Scrum implementa modelo iterativo e incremental cujas atividades são assumidas por três papéis principais (SCHWABER, 2004): Product Owner: é o dono do produto; define os fundamentos do projeto como os requisitos iniciais e gerais (Product Backlog), retorno de investimento, objetivos e formas de entregas; priorização para o Product Backlog a cada sprint, garantindo que as funcionalidades de maior valor sejam desenvolvidas prioritariamente; ScrumMaster: gerencia o processo do Scrum, ensina e implementa o Scrum de modo que esteja adequado à cultura da organização; deve garantir que todos sigam as regras e práticas do Scrum; e também é responsável por remover os impedimentos do projeto e Time: desenvolve o produto; define como transformar o Product Backlog em incremento de funcionalidades numa sprint. O time é responsável pelo sucesso da sprint e consequentemente pelo projeto como um todo. Todo o trabalho no Scrum é realizado em iterações chamadas de sprints. Schwaber (2004) explica que: O coração do Scrum é a Sprint, um time-box de um mês ou menos, durante o qual um Pronto, versão incremental potencialmente utilizável do produto, é criado. Sprints tem durações coerentes em todo o esforço de desenvolvimento. Uma nova Sprint inicia imediatamente após a conclusão da Sprint anterior. As Sprints são compostas por uma reunião de planejamento da Sprint, reuniões diárias, o trabalho de desenvolvimento, uma revisão da Sprint e a retrospectiva da Sprint. A Figura 8 representada abaixo apresenta uma visão geral do Scrum.

42 42 Figura 8. Visão geral do Scrum Fonte: Marçal (2009). De acordo com Schwaber (2004), o Scrum introduz os seguintes artefatos principais usados ao longo do seu fluxo de desenvolvimento: Product Backlog, Sprint Backlog e incremento de funcionalidade do produto. O Product Backlog contém uma lista de itens priorizados que incluem os requisitos funcionais e não funcionais do sistema/produto que está sendo desenvolvido no projeto. O Sprint Backlog corresponde à lista de tarefas que o time do projeto define para implementar na sprint os requisitos selecionados do Product Backlog. Os incrementos de funcionalidade consistem de códigos testados, bem estruturados e bem escritos, que são executáveis acompanhados da documentação necessária para a sua operação (MARÇAL, 2009). A Figura 9 apresenta uma visão geral do processo do Scrum.

43 43 Figura 9. Fluxo de atividades do Scrum Fonte: Simões (2011) RUP O RUP é um framework de processo de engenharia de software que pode ser adaptado para uma grande variedade de projetos ou organizações. Ele fornece uma abordagem disciplinada para delegar tarefas e responsabilidades em uma organização de desenvolvimento de software (KRUCHTEN, 2000; IBM, 2001). Segundo Tamaki (2007), as melhores práticas referentes ao RUP são: Desenvolvimento de software iterativo; Gerenciamento de requisitos; Arquitetura baseada em componentes; Modelagem visual;

44 44 Verificação contínua da qualidade e Gerenciamento de mudanças. A Figura 10 apresenta as duas dimensões do RUP. O eixo horizontal representa o aspecto dinâmico do processo enquanto o eixo vertical representa o aspecto estático do processo. A dimensão dinâmica representa o tempo e os aspectos do ciclo de vida do software à medida que se desenvolve. A dimensão estática apresenta as disciplinas do RUP que agrupam as atividades do processo pela sua natureza. Figura 10. Dimensões do RUP Fonte: IBM (2007). Embora o nome dos fluxos possa caracterizar fases sequenciais de desenvolvimento em um modelo de ciclo de vida cascata, deve-se ter em mente que as fases de um fluxo iterativo são diferentes e os mesmos são revisitados várias vezes ao logo do ciclo de vida (IBM, 2007). A abordagem iterativa tem impacto positivo no controle de execução do projeto, pois através das iterações os gerentes de projeto controlam melhor as atividades. As atividades realizadas durante as fases de iniciação e elaboração aumentam a previsibilidade da execução do projeto, abordando os

45 45 riscos do negócio. O RUP permite uma entrega mais rápida e mais frequente, devido o desenvolvimento iterativo. Essa abordagem também permite que se tenha uma quantidade maior de feedback, do cliente com a equipe de desenvolvimento, permitindo o auxílio à equipe a ajustar o software para melhor adequação às expectativas dos clientes (OSORIO; CHAUDRON; HEIJSTEK, 2011). 2.3 MODELOS DE REFERÊNCIA DE AVALIAÇÃO DE PROCESSOS Modelo de referência de avaliação de processos ou modelo de avaliação de processos é um modelo que descreve os processos do ciclo de vida do software, baseado em uma boa engenharia e nos princípios de gerência de processos e é adaptável ao propósito de avaliar a capacidade do processo (ISO/IEC 15504, 2004). O objetivo desta pesquisa é utilizar como apoio para as avaliações do ciclo de vida de desenvolvimento das organizações intensivas em software, as metodologias utilizadas nos modelos de referência, CMMI, MPS.BR e ISO/IEC Os modelos de referência possuem estágios de maturidade e capacidade que envolvem todo o ciclo de vida de desenvolvimento e que através de avaliações atingem uma estratégia confiável para um processo de melhoria de desenvolvimento de software dentro das organizações. Dentro deste contexto o trabalho atual faz menção à estes modelos, como base para construir e organizar as avaliações para identificação do ciclo de vida de desenvolvimento de software CMMI O Capability Maturity Model Integrated é um modelo de qualidade para processos de desenvolvimento de software. Idealizado pelo Instituto de Engenharia de Software (SEI) da Universidade Carnegie Mellon USA, teve sua primeira versão lançada em 1991, com limitação somente voltada as práticas de engenharia de software. O CMMI oferece a oportunidade de acabar com barreiras e possíveis problemas por meio de modelos. O CMMI para desenvolvimento (CMMI-DEV), consiste das melhores práticas relacionadas as atividades de desenvolvimento e manutenção de produtos e serviços. Ele abrange práticas que cobrem todo o ciclo de vida do produto desde a concepção até a entrega e manutenção e se concentra no trabalho de construção e manutenção do produto (SEI, 2010a).

46 46 O CMMI-DEV contém 22 áreas de processos que são um conjunto de práticas interrelacionadas, que, quando implementadas coletivamente, satisfazem os objetivos considerados importantes para obter melhoramentos numa determinada área. Essas práticas abrangem, gestão de projetos, gestão de processos, engenharia de sistemas, engenharia de hardware, engenharia de software, e outros processos de apoio utilizados no desenvolvimento e manutenção (SEI, 2010a). (SEI, 2010a). De acordo com Quadro 1, pode-se visualizar os níveis e as áreas de processos equivalentes Quadro 1. CMMI - Áreas de processo Nível Foco Área de processo 5 - Otimizado Melhoramento Contínuo do Processo Inovação Organizacional Análise de causas e resoluções 4 Gerenciado Quatitativamente Gerenciamento Quantitativo Performance organizacional do processo Gerenciamento quantitativo de projetos 3 Definido Padronização do Processo Requisitos de desenvolvimento Soluções técnicas Integração de produtos Verificação Validação Foco no processo organizacional Definição do processo organizacional Treinamento organizacional Gerenciamento de projeto integrado Gerenciamento de riscos Integração da equipe de trabalho Gerenciamento integrado de suprimentos Análise de decisões Ambiente organizacional para integração 2 Gerenciado Gerenciamento Básico de Projetos 1 Inicial - - Gerenciamento de requisitos Planejamento do projeto Controle e monitoração do projeto Gerenciamento de suprimentos Avaliação e análise Garantia da qualidade do processo e produto Configuração do gerenciamento Mesmo não sendo criado por uma instituição normativa como ISO, ANSI ou ABNT, a aceitação do CMMI na indústria de software mundial é tão relevante que ele é o principal modelo de referência para iniciativas de melhoria de processo de software, inclusive no Brasil (SANTANA, 2007; SEI, 2014).

47 47 Em diversos países as organizações intensivas em software têm adotado, com sucesso, o modelo CMMI. Há evidências de que as organizações que implementaram esse modelo obtiveram melhorias significativas no desempenho dos seus processos, como o aumento da produtividade e da qualidade dos produtos e dos processos, bem como a diminuição de custos, entre outras (GIBSON et al., 2006). No entanto, esses resultados, geralmente, são observados em organizações de grande porte com disponibilidade adequada de recursos para investir em melhorias de processos. Um dos fatores limitantes deste modelo é que ele requer um grupo de especialistas em cada empresa, voltado única e exclusivamente para a melhoria de processos. Considerando que em grande parte das empresas, especialmente em grupos menores, a existência de um grupo especialista não é uma prática comum, o próprio SEI tem recomendado o estabelecimento de modelos voltados para cada desenvolvedor em particular e para os pequenos grupos (HUMPHREY, 1989) MPS.BR O programa MPS.BR é uma iniciativa de melhoria na capacidade de desenvolvimento de software das empresas brasileiras. Seu objetivo principal é desenvolver e disseminar modelos de melhoria de processos que atendam às necessidades da Indústria Brasileira de Software e Serviços de TI (atualmente a família de modelos é composta pelos modelos de referência MPS-SW para Software e MPS-SV para Serviços de TI), visando auxiliar economicamente as organizações, incluindo as pequenas e médias empresas, para que alcancem os benefícios da melhoria de processos e da utilização de boas práticas da engenharia de software e da prestação de serviços de TI em um curto intervalo de tempo (TRAVASSOS; KALINOWSKI, 2012). O MPS.BR é composto de um modelo de referência para processos de software MR-MPS-SW, que contém os requisitos que os processos das unidades organizacionais devem atender para estar em conformidade com o modelo MPS. Também faz parte do modelo um método de avaliação de processos, o MA-MPS, que assegura a coerência na aplicação do MR-MPS-SW e suas definições (SOFTEX, 2012). O Modelo de Referência MR-MPS-SW descreve os processos em termos de propósito e resultados. O propósito descreve o objetivo geral a ser atingido durante a execução do processo. Os resultados esperados do processo estabelecem os resultados a serem obtidos com a efetiva

48 48 implementação do processo. Estes resultados podem ser evidenciados por um produto de trabalho produzido ou uma mudança significativa de estado ao se executar o processo (SOFTEX, 2012). O Quadro 2 apresenta os processos descritos pelo MR-MPS-SW. Quadro 2. Processos do MR-MPS-SW Processos Gerência de Projetos GPR (evolução) Gerência de Riscos GRI Desenvolvimento para Reutilização DRU Gerência de Decisões GDE Verificação VER Validação VAL Projeto e Construção do Produto PCP Integração do Produto ITP Desenvolvimento de Requisitos DRE Gerência de Projetos GPR (evolução) Gerência de Reutilização GRU Gerência de Recursos Humanos GRH Definição do Processo Organizacional DFP Avaliação e Melhoria do Processo Organizacional AMP Medição MED Garantia da Qualidade GQA Gerência de Portfólio de Projetos GPP Gerência de Configuração GCO Aquisição AQU Gerência de Requisitos GRE Gerência de Projetos GPR Fonte: Softex (2012). Segundo Kalinowski et al. (2010), o conjunto de processos e os atributos de processos indicam onde a organização tem que investir esforço para melhoria, de forma a atender seus objetivos de

49 49 negócio e ao MR-MPS-SW. Contudo, pode-se destacar que no modelo MR-MPS-SW, as boas práticas são exigidas através de resultados de processos e de atributos de processo e cada vez mais a indústria brasileira vem adotando-o como modelo para as boas práticas da engenharia de software nele previstas (TRAVASSOS; KALINOWSKI, 2012). 2.4 CORPO DE CONHECIMENTO PARA ENGENHARIA DE SOFTWARE (SWEBOK) A área da Engenharia de Software passou por um estudo de uma comissão internacional de especialistas, visando a uma definição das fronteiras que a delimitam. Esse estudo foi conduzido no âmbito da IEEE e chama-se SWEBOK (Software Engineering Body of Knowledge, ou Corpo de Conhecimento de Engenharia de Software) (IEEE, 2004). O SWEBOK é dividido em um total de onze áreas de conhecimento (KOSCIANSKI; SOARES, 2007; IEEE, 2014), sendo elas: 1) Requisitos de Software: A área de conhecimento de Requisitos de Software se preocupa com a licitação, análise, especificação e validação de requisitos de software, bem como o gerenciamento de requisitos durante todo o ciclo de vida do produto de software. Os Requisitos de Software expressam as necessidades e restrições colocadas em um produto de software que contribui para a solução de algum problema do mundo real. 2) Design de Software: Visto como um processo, projeto de software é a atividade do ciclo de vida em que os requisitos de software são analisados a fim de produzir uma descrição da estrutura interna do software que servirá como base para a sua construção. Um projeto de software (o resultado), descreve a arquitetura de software, isto é, como o software é decomposto e organizado em componentes, e as interfaces entre os componentes. Deve também descrever os componentes em um nível de detalhe que permite a sua construção. 3) Construção de Software: O termo construção de software refere-se à criação detalhada de software através de uma combinação de codificação, verificação, testes unitários, testes de integração e depuração. A área de conhecimento de Construção de Software está ligada a todas as outras, mas é mais fortemente ligada ao Design de Software e Teste de Software, porque o processo de construção de software envolve design de

50 50 software e testes, significativamente. O processo utiliza a saída de projeto e fornece uma entrada para testar ("design" e "teste" neste caso referindo-se às atividades, e não as áreas de conhecimento). Limites entre projeto, construção e testes (se houver) irão variar de acordo com os processos de ciclo de vida de software que são usados em um projeto. Embora alguns detalhes de projetos possam ser realizados antes da construção, o trabalho de design é realizado durante as atividades de construção. 4) Teste de Software: O teste de software consiste na verificação dinâmica de comportamentos esperados, que um programa fornece em conjunto com um finito de casos de teste. 5) Manutenção de Software: Esforços de desenvolvimento de software resultarão na entrega de um produto de software que satisfaça as necessidades dos utilizadores. Assim, o produto de software deve mudar ou evoluir. Uma vez em operação, os defeitos são descobertos, ambientes operacionais mudam, e surgem novas necessidades dos utilizadores. A fase de manutenção do ciclo de vida começa após um período de garantia de atividades ou pós implementação de entrega. 6) Gerenciamento de Configuração de Software: O gerenciamento de configuração, é a disciplina de identificar a configuração de um sistema em pontos distintos com a finalidade de controlar sistematicamente as alterações da configuração e manutenção, da integridade e rastreabilidade da configuração ao longo do ciclo de vida do sistema. 7) Gestão de Engenharia de Software: Gestão de engenharia de software pode ser definida como a aplicação de atividades de planejamento, coordenação, medição, monitoramento, controle e emissão de relatórios, para garantir que os produtos de software e serviços de engenharia de software sejam entregues de forma eficiente, eficaz e em benefício das partes interessadas. 8) Software Engenharia de Processos: Um processo de engenharia consiste em um conjunto de atividades inter-relacionadas que transformam uma ou mais entradas em saídas ao consumir recursos para realizar essa transformação. 9) Modelos e Métodos de Engenharia de Software: Modelos e métodos de engenharia de software impõe uma estrutura de engenharia de software que tem como objetivo fazer

51 51 com que as atividades sistemáticas e repetíveis estejam orientadas para o sucesso. Modelos fornecem uma abordagem para a resolução de problemas, através de procedimentos para análise e construção do modelo. Métodos fornecem uma abordagem sistemática para a especificação, projeto, construção, teste e verificação de software. 10) Qualidade de Software: A qualidade do software também é considerada em muitas das áreas do SWEBOK porque é um parâmetro fundamental de um esforço de engenharia de software. Para todos os produtos de engenharia, o principal objetivo é entregar o valor máximo das partes interessadas, enquanto equilibra as restrições do custo de desenvolvimento e cronograma. Essa área de conhecimento aborda definições e fornece uma visão geral de práticas, ferramentas e técnicas para a definição de qualidade de software e para avaliar o estado da qualidade do software durante o desenvolvimento, manutenção e implantação. 11) Prática de Engenharia de Software Profissional: Esta área de conhecimento está preocupada com o conhecimento, habilidades e atitudes que os engenheiros de software devem possuir para a prática de engenharia de software de uma forma profissional, responsável e ética. Por causa das aplicações generalizadas de produtos de software na vida pessoal e social, a qualidade de produtos de software pode ter um impacto profundo em nossa vida pessoal, bem-estar e harmonia social. 12) Economia em Engenharia de Software: Esta área trata sobre a tomada de decisões relacionadas com a engenharia de software em um contexto de negócios. O sucesso de um produto de software, serviços e solução depende de uma boa gestão empresarial. No entanto, em muitas empresas e organizações, as relações comerciais para desenvolvimento de software e engenharia de software podem permanecer vagas. Esta área do conhecimento fornece uma visão geral sobre a economia da engenharia de software. 13) Fundamentos Computacionais: O escopo desta área de conhecimento, engloba o ambiente de desenvolvimento e operacional em que o software evolui e executa. Porque nenhum software pode existir em um vácuo, o núcleo de tal ambiente é o computador e seus diversos componentes. O conhecimento sobre o computador e seus princípios

52 52 subjacentes de hardware e software serve como um quadro para a engenharia de software. 14) Fundamentos Matemáticos: A área de conhecimento Fundamentos Matemáticos ajuda os engenheiros de software compreender a lógica, que por sua vez é traduzida em código de linguagem de programação. A matemática que é o foco principal da área de conhecimento é bastante diferente da aritmética típica, em que os números são tratados e discutidos. Lógica e raciocínio são a essência da matemática que um engenheiro de software deve conhecer. 15) Fundamentos da Engenharia: Como a teoria e prática da engenharia de software amadurece, é cada vez mais evidente que a engenharia de software é uma disciplina da engenharia que se baseia em conhecimentos e habilidades comuns a todas as disciplinas de engenharia. Esta área de conhecimento está preocupada com os fundamentos de engenharia que se aplicam a engenharia de software e outras disciplinas de engenharia. 2.5 NORMA ISO/IEC A norma ISO/IEC provê um conjunto de processos, atividades e tarefas para ciclos de vida de produtos e serviços de software. O objetivo desta norma é fornecer um conjunto definido de processos para facilitar a comunicação entre compradores, fornecedores e outras partes interessadas no ciclo de vida de um produto de software (ISO/IEC 12207, 2008). Segundo a norma ISO/IEC (2008), a mesma possui um grupo de atividades que podem ser realizadas durante o ciclo de vida de um sistema de software e está dividida em sete grupos de processo. Cada um dos processos do ciclo de vida dentro desses grupos é descrito em termos de seu propósito e resultados desejados e atividades de listas e tarefas que precisam ser executadas para atingir esses resultados. Para esta pesquisa, apenas o conteúdo relacionado ao processo de implementação de software, é demonstrado na Figura 11, por ser o objetivo principal do trabalho em relação a norma. A Figura 11, representa a organização da norma em termos de processos.

53 53 Figura 11. Grupos de Processos de Ciclo de Vida Fonte: ISO/IEC (2008). Processo de Implementação de Software: A finalidade do processo de implementação de software é produzir um elemento específico do sistema, implementado como um produto ou serviço de software. Este processo transforma um comportamento específico, interfaces e restrições de implementação em ações que criam um elemento do sistema como um produto ou serviço de software, também conhecido como um "item de software." Este processo resulta em um item de software que

54 54 satisfaça os requisitos de projeto de arquitetura através de requisitos de verificação e de interessados através de validação. Processo de Análise de Requisitos de Software: O objetivo deste processo é estabelecer os elementos de requisitos do sistema de software. Processo de Projeto de Arquitetura de Software: O objetivo deste processo é fornecer um projeto de implementação de software que possa ser verificado em relação aos requisitos. Processo de Projeto Detalhado de Software: O objetivo deste processo é fornecer um projeto de implementação de software que possa ser verificado em relação aos requisitos e à arquitetura de software, e é suficientemente detalhado para permitir a codificação e os testes. Processo de Construção de Software: O objetivo do processo de construção de software é produzir unidades de software executáveis que refletem adequadamente o projeto de software. Processo de Integração de Software: O propósito deste processo é combinar as unidades de software e componentes de software, produzindo itens de software integrados, de acordo com o projeto de software e que demonstram que os requisitos de software funcionais e não-funcionais são satisfeitos em uma plataforma operacional. Processo de Teste e Qualidade de Software: O propósito deste processo é confirmar que o produto de software integrado atende os seus requisitos definidos. 2.6 AVALIAÇÃO DE SOFTWARE Processo de avaliação é uma avaliação disciplinada de processos de uma unidade organizacional contra um Modelo de Processo de Avaliação, que é um modelo adequado para a finalidade de avaliar a capacidade do processo. Um modelo de avaliação baseia-se em um ou mais modelos de processos de referência, que compreendem as definições de processos em um ciclo de vida, em conjunto com uma arquitetura que descreve as relações entre os processos (ISO/IEC , 2004). Para Mäkinen, Varkoi e Soini, (2007) um processo de avaliação estuda a capacidade do processo com base em atributos de processo definidos no modelo de avaliação. Modelagem de processos compreende a análise de atividades, artefatos, funções e ferramentas.

55 55 Dentro do contexto de avaliação de processo, Gray, Sampaio e Benediktsson (2005), destacam que a mesma é a primeira fase de um programa de melhoria e por isso é importante que esta fase seja feita de forma correta e através de técnicas de avaliação conforme Figura 12. Essas técnicas de avaliação são baseadas em: Listas de verificação enumeram as práticas da organização, mas não fornecem informações suficientes para serem usadas sozinhas com uma técnica de avaliação; Questionários permitem reunir informações mais completas, geralmente são utilizados modelos como o questionário de maturidade do Software Engineering Institute (SEI); Nos workshops, é possível ouvir grupos de funcionários em diferentes sessões, cada uma conduzida por um facilitador e Pro-formas, são pastas de trabalho, onde são organizados os resultados de uma avaliação. Figura 12. Modelo conceitual de processo de avaliação Fonte: Adaptado de GRAY (2005). Segundo Prikladnicki, Becker e Yamaguti (2005), devido ao alto grau de rigor e custos associados a uma avaliação formal, além da necessidade de haver avaliações intermediárias, métodos

56 56 de mini avaliação e de diagnóstico foram sendo desenvolvidos por empresas de consultoria e implementadores de modelos de qualidade Avaliação de Processo de Software Ao iniciar um programa de melhoria de processos de software é necessário obter um levantamento da situação atual, para isto, geralmente, são feitas avaliações no início do programa de melhoria. Uma avaliação é uma análise dos processos utilizados por uma organização, que pode ser feita contra um modelo de referência para determinar a capacidade destes processos na sua execução de acordo com as metas de qualidade, cronograma e custo estabelecidos (ANACLETO; WANGENHEIM; SALVIANO, 2005). A motivação para a realização da avaliação de processos e atividades de melhoria é coletar informações sobre o que precisa ser mudado e para estabelecer como buscar as melhorias, a fim de minimizar o custo de desenvolvimento e maximizar a qualidade dos produtos produzidos (PETTERSSON et al., 2008). A partir da avaliação inicial são determinados pontos de maior prioridade a serem melhorados considerando, principalmente, as metas de melhoria da organização e os benefícios que cada melhoria pode trazer (ANACLETO; WANGENHEIM; SALVIANO, 2005). Ao definir uma avaliação para melhoria de processo é necessário que seja construído um modelo que o represente. Essa representação suporta o entendimento e a visualização do processo, facilita sua disseminação e comunicação, auxilia na gerência de projetos, e é importante na avaliação, evolução e melhoria contínua do processo (THIRY et al., 2006). No trabalho de Mendes, Almeida e Arruda Jr., (2011), um modelo de avaliação para melhoria de processo é ilustrado através da Figura 13.

57 57 Figura 13. Fluxograma de implantação de melhorias Fonte: Mendes; Almeida; Arruda Jr., (2011). No que se refere a processos de software, a importância da avaliação e melhoria é reconhecida pelos vários modelos de qualidade. O CMMI (SEI, 2010a), por exemplo, define a área de processo com foco no Processo Organizacional, cujo objetivo é planejar, implementar e implantar melhorias nos processos organizacionais tomando por base um levantamento macro dos pontos fortes e fracos dos processos da organização. Já o MPS.BR (SOFTEX, 2012) define o processo com foco na Avaliação e Melhoria do Processo Organizacional, cujo propósito é determinar o quanto os processos padrão da organização contribuem para alcançar os objetivos de negócio da organização e para apoiar a organização a planejar, realizar e implantar melhorias contínuas nos processos com base no levantamento de seus pontos fortes e fracos. O MPS.BR possui o método de avaliação MA-MPS, cujo o propósito é verificar a maturidade da organização na execução de seus processos de software e de serviços. O processo de avaliação descreve o conjunto de atividades e tarefas a serem realizadas para atingir este propósito. Ele tem início com a seleção de uma Instituição Avaliadora (IA) e encerra com o registro dessa avaliação na base de dados confidencial da SOFTEX (SOFTEX, 2013). O CMMI possui o Método Padrão para Melhoria de Processos (SCAMPI), que é projetado para fornecer avaliações de qualidade de referência em relação ao modelo CMMI. O SCAMPI satisfaz todas as Exigências de Avaliação para CMMI ARC sendo por isso, um método de avaliação Classe A que pode ser utilizado para avaliações do modelo ISO/IEC (SEI, 2011).

58 Diagnósticos Quando uma empresa decide investir na melhoria de seus processos de software, surgem uma série de questionamentos e debates envolvendo dúvidas em relação aos possíveis benefícios a serem obtidos com a mudança. Porém, um fato é imprescindível: deve-se conhecer a situação atual dos processos de software da empresa antes de iniciar um projeto de melhoria, através do diagnóstico. Diagnóstico de processos em uma pequena empresa requer práticas de avaliação de processos que dão resultados qualitativos e quantitativos, os quais devem oferecer uma visão geral da capacidade do processo. O objetivo é a obtenção de informações relevantes sobre o funcionamento dos processos, para uso em seu controle e melhoria. No entanto, as pequenas empresas têm alguns problemas na execução da avaliação do processo, em razão das suas características e limitações específicas (PINO et al., 2010). Um exemplo destes problemas, é o custo e o esforço relacionado a utilização da avaliação de processo de software padronizada (WANGENHEIM; VARKOI; SALVIANO, 2006). Diagnóstico de processos trata-se de um grupo de atividades a serem realizadas com a finalidade de se obter um entendimento mais detalhado do programa de melhoria. Para isso, deve ser realizada uma caracterização do estado atual e desejado da organização, através de atividades de avaliação. Com base nessas avaliações, deve ser proposto um conjunto de recomendações para que o estado desejado seja atingido. O resultado é um relatório detalhado e objetivo dos processos de software da organização diagnosticada, servindo como referência e base para o planejamento e decisões a respeito de melhoria de processos (PAULA FILHO et al., 2003). Dentro do diagnóstico dos processos de software, pode-se citar as avaliações de contextualização que identificam fatores organizacionais importantes e avaliam brevemente o processo de software como um todo (JÄRVINEN, 2000). Os resultados da avaliação caracterizam a organização numa visão alto nível do processo de software identificando processos importantes e críticos em relação as metas de negócio. Perfis alvo de processos são definidos identificando processos mais relevantes e os níveis de capacidade que devem ser atingidos para alcançar as metas de melhoria e contribuir para as metas de negócio da organização (WANGENHEIM et al., 2005). O processo de avaliação de contextualização é composto por 4 fases principais: Planejamento, Coleta de dados, Análise de dados, Validação, Apresentação de resultados e Documentação, sendo complementado pelo Controle e Finalização.

59 59 A Figura 14 ilustra o processo de avaliação de contextualização. Figura 14. Visão geral do processo de avaliação de contextualização Fonte: Wangenhein et al. (2005). A pesquisa de Wangenhein et al. (2005), destaca as seguintes características para a avaliação de contextualização: O planejamento da avaliação envolve o contato com a organização a ser avaliada e a criação de um planejamento de atividades que identificam o escopo da avaliação e são selecionados o método e o modelo de avaliação a serem utilizados. Ainda nesta fase é definido o plano de avaliação que inclui requisitos, método e modelo(s) a serem utilizados, estimativas, riscos e considerações práticas. Na coleta de dados, são levantadas informações sobre a organização avaliada referentes aos fatores organizacionais e ao processo de desenvolvimento do software. Faz parte da coleta de dados, obter as informações através de questionários, conduzir uma reunião de abertura, identificar os fatores de negócio com o propósito de mapear oportunidades e ameaças de negócio e metas de melhoria. E ainda obter uma visão geral do processo de desenvolvimento do software, de forma ampla e alto nível, por meio de entrevistas. Na análise de dados, todas as informações coletadas na fase anterior são analisadas, identificando informações gerais da organização, características, metas, principais produtos e/ou serviços, informações sobre o processo de desenvolvimento do software identificando os principais pontos fortes e fracos e identifica oportunidades de melhoria de forma geral.

60 60 Seguindo para a fase de validação e apresentação, todos os resultados são validados e apresentados. Esses resultados são documentados em um relatório que é entregue aos responsáveis pela avaliação na organização. Esta fase inclui o relatório preliminar com base no plano de avaliação e nos resultados da análise da avaliação. Uma revisão preliminar em relação à consistência, completude, corretude, não-ambiguidades e omissões. Por fim na fase de controle e finalização, toda a avaliação é monitorada e controlada, principalmente em termos de esforço e duração/prazos. Com foco na melhoria da avaliação, ao término da mesma, as experiências adquiridas são avaliadas por meio de discussões com os avaliadores e por questionários de satisfação obtendo um feedback do patrocinador. No presente trabalho, parte das etapas descritas por Wangenhein et al. (2005), para avaliação de contextualização, foram seguidas, como coleta dos dados, análise, validação e apresentação. A coleta se dá através do sistema especialista, a análise é a etapa onde os resultados são exibidos com os pontos fortes, pontos fracos e oportunidades de melhoria, a validação e apresentação se dão através das avaliações feitas pelos gestores das organizações e especialistas em MPS Automatização de Diagnóstico Recentemente, muitos esforços estão sendo feitos para a implementação da Melhoria de Processo de Software em pequenas empresas e uma vez que se compromete a iniciar este processo, o próximo passo é avaliar a capacidade atual da empresa para desenvolver e manter a melhoria do software. Após isso, deve-se definir planos de ação relacionados a implementação dos processos de melhoria. Existem uma série de estudos de casos que demonstram a aplicabilidade destas propostas em um ambiente de pequena empresa, mas, infelizmente, há uma falta de informação sobre ferramentas de software que, na verdade, sejam dirigidas as pequenas empresas na implementação de um programa de MPS (GARCÍA; ANDREA, 2010). Segundo Young, Fang e Hu (2006), são necessárias abordagens mais viáveis para implementar, medir e melhorar os processos de software em pequenas empresas. Ou seja, para realizar avaliações é necessário um processo automatizado de software como uma questão de interesse primário para as melhorias. Com base na experiência de Young, Fang e Hu (2006), as ferramentas não são apenas importantes, mas essencial para a perfeita integração de processos e também na produção de diferentes produtos de trabalho.

61 61 Em 2008, Thiry et al. (2008) desenvolveu uma ferramenta de suporte a avaliação, alinhada ao MPS.BR e a outro modelo de referência simultaneamente, onde é permitida a realização de avaliações integradas, em que os artefatos coletados na fase preparatória de uma avaliação poderão ser reutilizados para evidenciar a execução de práticas de um segundo e terceiro modelo de referência, sem a necessidade de serem coletados novamente. Isto oferecerá maior flexibilidade e abrangência para a equipe de avaliação. Outras ferramentas têm sido desenvolvidas para apoiar a execução da melhoria de processo nas organizações. Uma delas é o desenvolvimento da ferramenta de software livre SPIDER-PE proposto por Silva et al. (2012), que tem o intuito de apoiar a execução flexível e semi automatizada de processos de software a partir das boas práticas definidas pelos modelos de qualidade e melhoria do processo. No projeto de Mendes e Oliveira (2006), é proposto um método de diagnóstico de processos através de uma ferramenta, com o intuito de eliminar tarefas mecânicas como a consolidação de questionários. O projeto possibilitou, a identificação de boas práticas que, se adotadas, poderão trazer ainda mais qualidade aos diagnósticos que utilizam o método proposto. A principal delas foi a necessidade de uma melhor definição dos papéis nas entrevistas. 2.7 SISTEMA ESPECIALISTA As organizações têm o paradigma de redução de custos adotado frequentemente em suas operações. Para apoiar as organizações nesse objetivo, pode-se contar com um recurso computacional denominado sistema especialista, que é descrito por Munárriz (1994) como um programa de computador, cujo comportamento seria de uma pessoa, especialista, ao resolver um problema, em um domínio especifico para o qual foi designado. Desta forma, observa-se que o uso de sistemas especialistas pode, em muitas situações, reduzir os custos operacionais oferecendo maior agilidade na resolução de problemas específicos que pessoas, em sua grande maioria, demorariam mais tempo para resolver. Segundo Haykin (2008), um sistema de Inteligência Artificial (IA) deve ser capaz de armazenar conhecimento e aplicá-lo para resolver problemas e adquirir novo conhecimento através da experiência. Os sistemas especialistas (SE) são ferramentas computacionais cujo objetivo é simular as decisões que seriam tomadas por uma pessoa especializada na área que pretende-se explorar, tentando

62 62 reproduzir boa parte do conhecimento do especialista (COWELL et al., 1999). No contexto de um SE, um especialista é alguém com conhecimentos e habilidades em determinada área capaz de resolver problemas específicos. Os SE podem atuar na forma de sistemas interativos, respondendo questões, solicitando ou fornecendo esclarecimentos e recomendações, podendo também auxiliar o usuário na tomada de decisões. De modo geral, podem simular o raciocínio humano ao fazer inferências, julgamentos ou projetar resultados (LINARES, 1997). São utilizados quando um problema ou sua solução conduza a um processamento muito demorado. Dentre seus objetivos, está o de preservar e transmitir o conhecimento de algum especialista em determinada área (ROSSO, 2002). Um Sistema Especialista, também pode ser definido como um sistema de computador, que contém um corpo de conhecimento que imita a capacidade de um especialista em resolver problemas. Por outro lado, um SE baseado em regras é um programa de computador que é capaz de usar informações de uma base de conhecimento, através de um conjunto de procedimentos de inferência, para resolver problemas que são difíceis o suficiente para exigir experiência humana significativa para a sua solução (HARMON; KING, 1985). Segundo Keller (1991) um SE pode ser definido como sendo uma parte da Inteligência Artificial que utiliza regras de condição-ação. Um Sistema Especialista é aquele que através de informações reunidas em um banco de dados, por um especialista humano no assunto, ajuda a resolver determinado problema. Na área de Sistemas Especialistas tem-se os sistemas baseados em regras, no qual o conhecimento é representado na forma de regras de produção. O raciocínio é modelado através de encadeamento de regras. A associação empírica entre premissas e conclusões na base de conhecimento é a sua principal característica. Sistemas baseados em regra não necessitam de um modelo de processo, no entanto, eles exigem uma multiplicidade de regras para cobrir todas as falhas possíveis em um sistema técnico e têm dificuldades com operações inesperadas ou novos equipamentos. Além disso, a abordagem baseada em regras tem uma série de deficiências, como a falta de generalidade e manipulação incorreta das situações novas, mas também oferece eficiência e eficácia na detecção de falhas. Entre as principais limitações dos sistemas especialistas de diagnóstico precoce são

63 63 considerados a incapacidade de representar com precisão e variando espacialmente fenômenos variando em tempo, a incapacidade do programa de aprender com os erros, bem como as dificuldades para os engenheiros de conhecimento para adquirir o conhecimento de especialistas de forma confiável (ANGELI, 2008). O Quadro 3 mostra um exemplo de regras de produção. Quadro 3. Exemplo de trecho de uma regra de produção Regra 1 SE Trab_proj = Sim E Utiliza_mod = Sim E ModeloCV = Casc E Todos_Cada = Todos os projetos E Organizados = Fases/etapas E Fases = Fase_01 ENTÃO Diag_01 = Result_Diag_01 A regra representada no Quadro 3 possui a seguinte estrutura de perguntas e respostas: Pergunta: A organização trabalha por projeto? Resposta: Sim Pergunta: Utiliza algum modelo de ciclo de vida? Resposta: Sim Pergunta: Qual modelo é utilizado? Resposta: Cascata Pergunta: Todos os projetos utilizam o modelo? Resposta: Todos os projetos Pergunta: Como os projetos são organizados? Resposta: Fases e etapas Quais são as fases do projeto? Resposta: (descrição das fases) A arquitetura típica de um SE consiste de três componentes principais, que incluem a base de conhecimento, o motor de inferência e a interface do usuário.

64 64 A base de conhecimento contém o conhecimento necessário para resolver um problema específico. O conhecimento pode ser representado utilizando uma variedade de técnicas de representações do conhecimento (por exemplo, redes semânticas, frames, lógica de predicados), mas a técnica mais utilizada são as regras if - then, também conhecidas como regras de produção. Mecanismo de inferências determina a ordem em que as inferências são feitas e, finalmente, a interface de usuário que permite parte da comunicação entre o sistema e o usuário (METAXIOTIS; PARRAS, 2003). O motor de inferência é um elemento essencial para a existência de um SE. Ele é considerado o núcleo do sistema, uma vez que é por intermédio dele que os fatos, heurísticas e relações compõem a base de conhecimento que são aplicados no processo de resolução do problema (IGNIZIO, 1991). O motor de inferência aplica o conhecimento na solução de problemas reais, sendo um interpretador para a base de conhecimento (MOREIRA, 2012). O motor de inferência representa a forma de manipular o conhecimento já representado na base de conhecimento, a fim de resolver o problema. Ele determina a ordem com que serão processadas as informações, manipulando os dados a fim de inferir novos fatos, chegar a conclusões ou recomendar ações (FIGUEIRA FILHO, 2000). Portanto, motor de inferência representa o cérebro do sistema especialista, nele são realizadas as operações necessárias para transformar os dados em informações relevantes. Para tal, utiliza-se do conteúdo existente na base de conhecimento. O motor de inferência é quem define o método de encadeamento das regras, ou seja, como elas serão processadas. Segundo Oliveira (2001) o conjunto de várias inferências que ligam o problema com a sua solução dá-se o nome de chaining ou encadeamento. O encadeamento que é percorrido tendo como ponto de partida o problema e como alvo a solução é denominado de forward chaining ou encadeamento progressivo. Ao contrário do encadeamento progressivo, quando um conjunto de inferências que ligam o problema com a solução é percorrido a partir da hipótese até os fatos que a suportam, este processo é denominado de backward chaining ou encadeamento regressivo (o processo é o inverso do encadeamento progressivo). A interface do usuário é responsável pela iteração do usuário com o sistema. Normalmente ela é composta de interfaces de visualização e diagnóstico e pode também prover interfaces de comunicação para ferramentas externas, como bancos de dados (SOUZA, 2013).

65 65 A Figura 15, representa a arquitetura do sistema especialista desenvolvida para este trabalho. Figura 15. Arquitetura do sistema especialista Fonte: Adaptado de Luger (2004). Ferramentas de validação e verificação são softwares que combinam fatos e regras de modos diversos, embutem uma máquina de inferência específica, assim como uma representação própria de conhecimento, e permite a construção de sistemas especialistas que utilizem a sua representação de conhecimento e máquina de inferência (MOURA; CRUZ, 2001).

66 66 3 ESTADO DA ARTE Tendo como objetivo a proposta de uma abordagem de autodiagnostico para o levantamento inicial do ciclo de vida e processos de desenvolvimento em organizações intensivas em software, esta seção descreve abordagens encontradas através de pesquisas e estudos de caso. Deste modo, duas revisões distintas foram realizadas: a primeira, um estudo para identificar abordagens de autodiagnostico para o levantamento inicial do ciclo de vida através de uma busca informal e a segunda, realizada de modo sistemático, que tem por enfoque a identificação destas abordagens em fontes de pesquisa acadêmicas reconhecidas. 3.1 REVISÃO EXPLORATÓRIA Considerando a dificuldade em encontrar trabalhos científicos que avaliam o ciclo de vida de desenvolvimento, optou-se pela realização de um estudo de pesquisa informal com o objetivo de identificar trabalhos que relatam a condução de avaliações do ciclo de vida de desenvolvimento de software em organizações intensivas em software, como forma de melhoria de processo. A pesquisa retornou resultados que ajudaram a construir uma base para o mapeamento sistemático descrito na Seção 3.2, tipicamente, mais específico para responder as perguntas de pesquisa. Para o processo de revisão informal foi determinado o período de 2008 a 2014, para que retornassem pesquisas atuais sobre o assunto e foram utilizadas as strings em inglês e português: Software Process Improvement / Melhoria de Processo de Software Assessment or Appraisal or Evaluation / Avaliação Lifecycle or Life cycle / Ciclo de Vida Tool / Ferramenta A revisão informal foi realizada na ferramenta de busca Google Scholar ( A seleção dos estudos analisou os primeiros 100 (cem) resultados encontrados, considerando que o buscador prioriza os resultados mais relevantes. Desta forma, alguns estudos isolados podem ter sido desconsiderados nesta revisão informal, mas espera-se que sejam identificados num mapeamento sistemático posterior.

67 Trabalhos Relacionados Os resultados da revisão informal forneceram parâmetros para fundamentar a abordagem proposta neste trabalho. O Quadro 4 apresenta os trabalhos selecionados com a revisão informal. Quadro 4. Trabalhos relacionados Ano Título Referências 2010 A Web-based Tool for Automatizing the Software Process García, I.; Pacheco, C. Improvement Initiatives in Small Software Enterprises 2011 SPIALS: A Light-Weight Software Process Improvement Self- Assessment Tool Homchuenchom, D.; Piyabunditkul, C.; Lichter, H.; Anwar, T Autodiagnostico de Processo de Software Baseado em Sistema Especialista 2012 ReMo: A Recommendation Model For Software Process Improvement Moreira, D.; Fernandes, A. M. R.; Castro, F. S.; Thiry, M. Sujin Choi; Dae-Kyoo Kim; Sooyong Park A WEB-BASED TOOL FOR AUTOMATIZING THE SOFTWARE PROCESS IMPROVEMENT INITIATIVES IN SMALL SOFTWARE ENTERPRISES Este artigo apresenta uma investigação sobre uma proposta que estabelece que uma pequena organização pode usar uma ferramenta de software para avaliar e melhorar o seu processo de software, identificação e implementação de um conjunto de práticas de gerenciamento de projetos ágeis, que podem ser reforçadas usando o modelo CMMI-DEV como referência. Metodologia de avaliação utilizada: Utiliza a ferramenta web para avaliação SysProVal que tem como base o modelo IDEAL. Descrição do processo de avaliação: SysProVal consiste de um mecanismo que gerencia a melhoria de processo de software, pois compara as práticas atuais com as práticas do CMMI-DEV adaptado para pequenas empresas, além de determinar os processos selecionados, gerando um plano de melhoria apropriado e iterativo. Tipo de organização/produto avaliados: Pequenas empresas de software. Resultado obtido com a metodologia utilizada (diagnóstico/avaliação): A pesquisa mostrou que a ferramenta SysProVal facilita a implementação do CMMI-DEV através

68 68 das três fases iniciais do modelo IDEAL. O SysProVal apresenta boa cobertura dessas fases a nível de projeto. O mecanismo de avaliação SysProVal provou ser uma ferramenta de diagnóstico conveniente e útil para pequenos ambientes. O SysProVal apresentou boa cobertura no nível "pesquisa e aperfeiçoamento". Ciclo de vida: A proposta desta pesquisa não está em mapear o ciclo de vida da organização, mas sim, apresentar uma ferramenta web para avaliação de processos que gera um plano de melhorias SPIALS: A LIGHT-WEIGHT SOFTWARE PROCESS IMPROVEMENT SELF- ASSESSMENT TOOL Este trabalho, propõe uma abordagem baseada na ferramenta chamada CMMIbySCRUM para melhorar os processos baseados no CMMI. Para apoiar as organizações no seu caminho para melhores processos, é apresentado o projeto de uma ferramenta genérica (SPIALS: Software Process Improvement Adaptive Learning System) aplicável para medir o status de capacidade de processo das organizações. Microempresas podem utilizar a ferramenta para realizar uma auto avaliação, reduzindo assim o processo de avaliação complexo. A estratégia de avaliação da ferramenta apresentada é baseada no SCAMPI, que é reconhecido para avaliação CMMI. Metodologia de avaliação utilizada: A metodologia SPIALS de auto avaliação, propõe uma abordagem baseada na ferramenta CMMIbySCRUM. A SPIALS utiliza questionários que devem ser preenchidos pelos representantes da organização. Estes questionários são gerados com base em informações da organização. Todos os questionários em conformidade com um modelo subjacente comum. É necessário introduzir a entrada de dados por um representante da organização que define evidências para processos de desenvolvimento de software. O resultado é apresentado automaticamente indicando aceitação nas áreas dos processos selecionados. Descrição do processo de avaliação: SPIALS auxilia pequenas e médias empresas a realizar auto avaliações. Seu procedimento é consistente com os princípios do SCAMPI incluindo as três fases; Planejar e preparar para Avaliação, Conduta de Avaliação e relatório de resultados.

69 69 Tipo de organização/produto avaliados: A metodologia SPIALS é útil para pequenas e médias empresas. Resultado obtido com a metodologia utilizada (diagnóstico/avaliação): Não houve a realização de diagnóstico. Ciclo de vida: O ciclo de vida não é analisado nesta pesquisa, o propósito dela é contribuir com uma abordagem para a realização de auto avaliação através de questionários. Compõe a abordagem fases de avaliação que são sugeridas na melhoria de processo de software.

70 AUTODIAGNOSTICO DE PROCESSO DE SOFTWARE BASEADO EM SISTEMA ESPECIALISTA Este trabalho propõe o desenvolvimento de uma abordagem de autodiagnostico utilizando Sistemas Especialistas, apoiado por uma ferramenta computacional para web. Os resultados apresentados na avaliação desta abordagem indicam que a utilização do SE permite mapear os pontos fortes e fracos do processo de uma organização, contribuindo como uma nova sistemática de avaliação na área de melhoria de processos de software. Metodologia de avaliação utilizada: Abordagem de autodiagnostico utilizando Sistemas Especialistas (SE) apoiado por uma ferramenta computacional para web. A avaliação é realizada com base no nível G do MPS.BR. Descrição do processo de avaliação: Entrada dos dados vem através de um questionário de fatores organizacionais, questionário de caracterização da empresa e entrevistas. A análise é feita através da análise dos questionários e das respostas das entrevistas realizada com especialistas em melhoria de processo. A saída é o diagnóstico do processo de software apresentando pontos fortes e pontos fracos. Tipo de organização/produto avaliados: Foram avaliadas quatro (4) organizações. Das quais duas (2) são do setor privado e duas (2) são do setor do público. Resultado obtido com a metodologia utilizada (diagnóstico/avaliação): 45, 75% das avaliações foram consideradas totalmente de acordo com o diagnóstico apresentado pela ferramenta e 25% delas parcialmente de acordo. O percentual de respostas do especialista em relação aos critérios avaliados na abordagem é de 82% das respostas do especialista estão de acordo com a abordagem proposta. Ciclo de vida: O propósito não foi analisar o ciclo de vida da organização e sim modelar o conhecimento referente aos resultados esperados do nível G do MPS.BR em organizações desenvolvedoras de software, através de entrevistas.

71 REMO: A RECOMMENDATION MODEL FOR SOFTWARE PROCESS IMPROVEMENT Este trabalho apresenta um método sistemático para o desenvolvimento de recomendações baseadas em um modelo de referência, como CMMI. O método apresentado é avaliado utilizando dados de avaliações reais da indústria e os resultados mostram o potencial do método. Metodologia de avaliação utilizada: A avaliação do modelo é realizada por um consultor de processo com 17 anos de experiência no setor e engenheiros de processo com uma experiência de 2 anos na indústria, ambos envolvidos na avaliação de processos e consultoria de empresas. Descrição do processo de avaliação: A análise dos resultados tem como foco a avaliação do processo e a visão de 4 correlações: Visão do modelo de avaliação, Visão com foco nos negócios, visão organizacional e visão do ciclo de vida do software. Tipo de organização/produto avaliados: Avaliou-se o modelo apresentado, utilizando dados reais de avaliação recolhidos de três empresas, incluindo uma grande empresa de desenvolvimento de aplicativos corporativos e duas pequenas e médias empresas o desenvolvimento de aplicações multimídia. Resultado obtido com a metodologia utilizada (diagnóstico/avaliação): O modelo considera vários aspectos de recomendações de profundidade. As recomendações resultantes do modelo são eficazes no planejamento de ações de melhoria em comparação com a prática tradicional. Este modelo pode ser utilizado como um modelo de referência para a análise de planos de ação. A análise de resultados é não-trivial, devido à subjetividade em estabelecer correlações e pode ser difícil para os engenheiros novatos pôr em prática. Ciclo de vida: O presente trabalho não mapeou o ciclo de vida das organizações avaliadas, mas contribuiu para a pesquisa com informações sobre o modelo de processo para desenvolvimento de recomendações para melhoria de processo de software REMO.

72 Análise dos Trabalhos Relacionados Os resultados retornados com a revisão informal trouxeram trabalhos que contribuíram para esta pesquisa, descrevendo abordagens para avaliação de melhoria de processo de software, ferramenta para auto avaliação e material sobre métodos de diagnósticos. Apesar dos trabalhos não relatarem alguma pesquisa relacionada ao ciclo de vida das organizações avaliadas/entrevistadas, o método de avaliação ou diagnóstico realizado nas mesmas, foi analisado com o objetivo de contribuir na composição da metodologia de entrevistas utilizada nesta pesquisa. O trabalho de Moreira (2012) teve sua importância no que diz respeito as informações contidas nas árvores de decisão, que serviram para complementar as questões desenvolvidas para as árvores de decisão do presente estudo. Considerou-se também, a proposta de autodiagnostico idealizada por Moreira (2012), como contribuição para a construção da abordagem desta pesquisa. Por fim, pode-se dizer que o retorno dos trabalhos da revisão informal, teve sua importância para o desenvolvimento da abordagem deste trabalho, que considerou as avaliações, ferramentas e metodologias, encontradas nesta revisão. 3.2 MAPEAMENTO SISTEMÁTICO Tendo como objetivo a proposta de uma abordagem para um modelo de autodiagnostico para o levantamento inicial do ciclo de vida e processo de desenvolvimento em organizações intensivas em software, esta seção descreve trabalhos encontrados através do mapeamento sistemático. Deste modo, o mesmo foi realizado com foco na identificação de formas de avaliação de melhoria de processo de software e no levantamento de trabalhos que utilizam métodos de diagnóstico de processos. Sendo assim, o mapeamento apresenta estudos sobre os temas abordados. Um mapeamento sistemático provê uma visão geral sobre a área de interesse identificando a quantidade de pesquisas, seus diferentes tipos e respectivos resultados, diferenciando-se da revisão sistemática em questão de profundidade e abrangência da pesquisa (PETERSEN et al., 2008). Petersen et al. (2008), com fundamentos em Kitchenham e Charters (2007), compara o mapeamento sistemático com a revisão sistemática, mostrando que os dois possuem objetivos diferentes e que em parte podem se contradizer. Petersen et al. (2008) diz que o mapeamento sistemático deveria ser utilizado como uma primeira etapa para a revisão sistemática, entretanto, ele

73 73 afirma que sozinho o mapeamento já tem o seu valor, ajudando a identificar possíveis lacunas de pesquisas de uma determinada área e fornecer potenciais carências em avaliações e validações em áreas com pouco estudo Objetivo Principal Este mapeamento sistemático tem por objetivo principal mapear pesquisas focadas no mapeamento inicial do ciclo de vida adotado por organizações intensivas em software através de diagnósticos de processos Protocolo de Busca O protocolo de busca foi elaborado com base na estrutura proposta por Kitchenham e Charters (2007), uma vez que esta abordagem foi adaptada para estudos em Engenharia de Software Questões de Pesquisa Um dos objetivos deste mapeamento sistemático foi mapear técnicas ou métodos de diagnósticos que identificam ciclos de vida de desenvolvimento adotados por organizações intensivas em software. Outro objetivo foi mapear modelos de avaliação utilizados para a identificação de ciclos de vida adotados por estas organizações desenvolvedoras de software. Para a elaboração das perguntas de pesquisa, foi adotada a estrutura PICOC 4 com a definição dos seguintes elementos: população, intervenção, comparação, resultados e contexto. Os Quadros 5 e 6 apresentam as duas questões de pesquisa relacionadas com a estrutura PICOC. Quadro 5. PICOC para a primeira pergunta. 1. O ciclo de vida mapeado através do diagnóstico é realmente aquele adotado pela organização desenvolvedora de software? População Organizações desenvolvedoras de software; Intervenção Reunir informações das organizações desenvolvedoras de software e aplicar um método de levantamento do ciclo de vida da mesma; 4 Em inglês: Population, Intervention, Comparison, Outcames and Context.

74 74 Comparação Comparar os diferentes tipos de ciclos de vida que são adotados pelos diferentes tipos de organizações com aqueles ciclos de vida identificados pela literatura; Resultados Mapeamento do ciclo de vida da organização com foco no levantamento do tipo de ciclo de vida e suas características, características da organização, dos projetos, dos produtos, dos clientes; Contexto No contexto deste trabalho está o levantamento das organizações, características, o porte e população. Quadro 6. PICOC para a segunda pergunta. 2. Quais os principais trabalhos que envolvem a identificação dos diferentes tipos de ciclo de vida adotados pelas diferentes organizações desenvolvedoras de software, comparados àqueles identificados na literatura? População Organizações desenvolvedoras de software; Intervenção Reunir informações de trabalhos que mapeiam um ciclo de vida; Comparação Aplicar um método de mapeamento do ciclo de vida da organização e comparar o resultado aos ciclos de vida identificados na literatura; Resultados Verificação do tipo de ciclo de vida que a organização está utilizando; Contexto No contexto deste trabalho está o levantamento dos tipos de ciclo de vida Fontes de Dados Esta seção descreve onde e como foram realizadas as buscas, bem como as palavras-chave que geraram a String de busca para os resultados selecionados. O fato dessas fontes de dados oferecerem acesso a publicações significativas na área de engenharia de software contribuiu para suas escolhas. Na Tabela 1 podem ser visualizadas as fontes escolhidas. Tabela 1. Fonte de Dados Nome da fonte IEEExplore ScienceDirect ACM Digital library SpringerLink Google Scholar Link de acesso

75 Palavras Chave As palavras chave foram definidas levando em consideração que todas elas fazem combinações que podem listar trabalhos relacionados ao ciclo de vida de desenvolvimento de software. Lifecycle Software development Method, Methodology, Methodologies Diagnostic, Diagnosis Assessment Appraisal Evaluation Process Modeling Modeling

76 String de Busca A string definida foi adotada como referência para a busca em todas as fontes de dados planejadas. Entretanto, como existem diferenças nos motores de busca de cada fonte de dados, houve a necessidade de realizar adaptações na estrutura da string de busca para cada fonte. O objetivo desta adaptação foi garantir que o objetivo da pesquisa fosse alcançado, evitando a perda de documento/artigos científicos relevantes. As strings definidas em cada fonte de dados, são apresentadas no Apêndice A. A seguir tem-se a string de busca definida: (lifecycle OR life cycle OR life-cycle) AND (software development) AND (method OR methodology OR methodologies OR diagnostic OR diagnosis OR Assessment OR Appraisal OR Evaluation OR Process OR Modeling) Critérios de Inclusão e Exclusão Nos critérios de inclusão os termos utilizados tiveram como objetivo identificar estudos sobre o processo de desenvolvimento de software, de forma a identificar os tipos de ciclos de vida de diferentes tipos de organizações, bem como analisar formas de diagnósticos para a identificação desses ciclos de vida. Para que o processo de seleção pudesse ter sucesso, foi de grande importância o uso dos critérios de inclusão e exclusão. Os critérios de inclusão são os seguintes: Pesquisas que apontem tipos de ciclos de vida do processo de desenvolvimento do software analisado; Pesquisas que apresentem formas de diagnóstico ou autodiagnostico de processos de desenvolvimento de software; Pesquisas que apresentem as características das organizações, dos produtos, dos projetos, dos clientes e dos ciclos de vida;

77 77 Pesquisas que comparam os ciclos de vida de desenvolvimento identificados no diagnóstico com os ciclos de vida que são tratados na literatura; Artigos científicos, publicados em fontes de dados que sejam bem conceituadas na comunidade científicas; Os artigos devem possuir em seu resumo ou título pelo menos uma das palavras usadas na string de busca; Artigos escritos na língua inglesa, preferencialmente; Artigos no formato.pdf; Artigos científicos publicados a partir de 01/2008 e Somente os 100 primeiros títulos retornados de cada base de dados. Os critérios de exclusão são os seguintes: Artigos publicados antes de 01/2008; Artigos que não estiverem entre os primeiros 100 títulos retornados de cada base de dados; Artigos que não possuam em seu título ou resumo, pelo menos uma das palavras da string de busca; Artigos que não contenham informações sobre ciclo de vida de desenvolvimento de software ou informações sobre avaliação do ciclo de vida e Artigos que contenham informações sobre gerenciamento de projetos Extração dos Dados extraídos: Para cada uma das publicações aprovadas no processo de seleção, os seguintes dados devem ser Título e Autor(es), o título será o primeiro a ser analisado, levando em conta que nele deve haver pelo menos uma referência ligada a ciclo de vida ou diagnóstico, avaliação ou

78 78 processo de desenvolvimento de software. Juntamente ao título o nome dos autores se faz necessário para obter a origem/nacionalidade da pesquisa em questão; Data de publicação, a data da publicação deve ser maior ou igual a 01/2008, quanto mais recente a publicação melhores informações se terá em relação a pesquisa dos ciclos de vida de desenvolvimento; Referências, são relevantes pelo fato delas mencionarem outras pesquisas relacionadas ao tema em questão; Resumo da publicação, nele deve conter informações pertinentes ao processo de desenvolvimento de software, bem como avaliações e diagnóstico do processo, organizações pesquisadas e características das mesmas; Descrição da abordagem, técnica e/ou processo proposto, com essas informações pode-se fazer uma análise comparativa entre pesquisa e o estudo que será realizado; Levantamento da metodologia utilizada para desenvolvimento de software, a extração dessa informação também servirá de análise comparativa para o estudo que será realizado; Tipos de ciclo de vida e as características dos mesmos, estas informações servirão de base para a elaboração do o questionário para o diagnóstico de processos e Perfil dos clientes e/ou organizações estudadas, essa informação indicará os tipos de organizações que estão utilizando diagnóstico para melhoria de processos. O critério para a seleção dos estudos é apresentar no mínimo uma seção sobre a metodologia utilizada para diagnóstico do processo. Os resultados da extração dos dados encontram-se no Apêndice A desta dissertação Análise dos Trabalhos Selecionados Este capítulo apresenta algumas considerações a respeito da sistematização do mapeamento realizado, assim como as evidências que respondem a cada uma das questões de pesquisa que guiaram o estudo.

79 79 Como resultado deste estudo, foram analisadas as strings de buscas utilizadas no trabalho de Moreira (2012) e dos artigos retornados através de uma string de busca definida para esta pesquisa. Estes artigos abordam ferramentas para avaliação do processo, descrição de etapas evolutivas para desenvolvimento de sistema de avaliação, micro avaliação utilizando questionários, avaliações em organizações de pequeno e médio porte e questionários de avaliação. O quadro com os trabalhos selecionados e suas referências encontram-se no Apêndice A. A seguir são apresentadas as considerações de cada trabalho utilizado para esta pesquisa INITIATING SOFTWARE PROCESS IMPROVEMENT IN SMALL ENTERPRISES: EXPERIMENT WITH MICRO-EVALUATION FRAMEWORK. Metodologia de avaliação utilizada: A abordagem é gradual, e com base numa estrutura de três fases de melhoria do processo de software. Na primeira fase, um questionário simplificado, chamado de Micro Avaliação é usado para coletar informações sobre as práticas atuais de software. A segunda Micro Avaliação poderia ser realizada alguns meses mais tarde para avaliar os progressos realizados. As informações coletadas e as conclusões retiradas, como resultado da análise também pode ajudar a determinar o escopo e os objetivos de uma avaliação mais precisa, que será realizada de acordo com o modelo OWPL (Observatoire des Wallon Pratiques Logicielles 5 ). Na segunda etapa, o componente central da metodologia, o modelo OWPL, é aplicado. O modelo OWPL permite microempresas realizarem uma avaliação proporcionando uma visão ampla e completa de seus processos de software. Ele foi desenvolvido com base no conhecimento do público-alvo através da realização de um grande número de micro avaliações e com foco nas metas da abordagem. Como micro avaliação, a avaliação OWPL pode ser realizada várias vezes para medir a melhoria, e poder servir como um ponto de entrada para o passo seguinte e final do método, a fase 3. Eventualmente, quando o tamanho ou no contexto de uma empresa justifica a necessidade de marcação padrão e quando a empresa atinge um nível de qualidade suficientemente elevada, uma avaliação SPICE ou CMM pode ser realizada. 5 Valónia Observatório de Práticas de Software

80 80 Descrição do processo de avaliação: A micro avaliação usa uma entrevista com base em um questionário que abrange seis eixos como os mais pertinentes e mais importantes para as organizações. Estes eixos são: Gestão da qualidade, Gestão de clientes, Gestão subcontratado, Desenvolvimento e gerenciamento de projetos, Gestão de produtos e Formação e Gestão de recursos humanos. Os entrevistados devem ter conhecimento suficiente sobre as atividades de TI da organização. O questionário cobre os 6 eixos listados acima. As perguntas são abertas, e cada um deles está associado a uma ou mais sub-perguntas, permitindo que o entrevistador possa ajustar e refinar a informação como for necessário. Existem dois tipos de questões: as que abordam práticas essenciais relacionadas com a organização e que são classificados numa escala linear de acordo com a qualidade da prática avaliada e as práticas que são de acordo com a qualidade da prática e de sua efetiva implementação na organização, isto é, algumas práticas podem estar presentes, mas usadas apenas em alguns projetos e não sistematicamente para todos os projetos. Tipo de organização/produto avaliados: 1ª amostra com 20 organizações, entre empresas de TI e empresas prestadoras de serviços de TI. 2ª amostra com 7 organizações, dentre os tipos citados. Resultado obtido com a metodologia utilizada (diagnóstico/avaliação): A experiência mostrou que a micro avaliação é muito atraente como uma ferramenta inicial, principalmente por causa de sua simplicidade, e também porque ajuda a chamar a atenção das pessoas para o problema da qualidade no campo da engenharia de software. Além disso, ela pode ajudar na elaboração de uma lista de recomendações para orientar as empresas de pequeno porte nos primeiros passos de melhoria. Para as pequenas empresas que procuram um modelo mais exaustivo, o modelo OWPL deve ser a resposta adequada, uma vez que foi desenvolvido tendo o CMM e o SPICE como referências, por um lado e especificidades das pequenas empresas, que são destacadas graças a micro avaliação. Ciclo de vida: O propósito da pesquisa não está em avaliar ou identificar um ciclo de vida. O objetivo desta pesquisa foi sugerir uma abordagem para avaliações com base em

81 81 entrevistas que permita pequenas empresas obterem uma visão completa de seus processos de desenvolvimento de software ASSESSING LEARNING IMPROVING AN INTEGRATED APPROACH FOR SELF ASSESSMENT AND PROCESS IMPROVEMENT SYSTEMS Metodologia de avaliação utilizada: Um ambiente que fornece serviços de status de avaliação, de aprendizagem e de melhoria contínua com base em diferentes padrões e abordagens. Esta abordagem já está sendo implementada para a área de gerenciamento de projetos. Descrição do processo de avaliação: No período de 2004 a 2010, o trabalho realizado e planejado pode ser dividido em 5 etapas evolutivas: (1) Desenvolver um sistema de avaliação; (2) Assegurar a melhoria do conhecimento por wikis 6 ; (3) Estruturar o conhecimento em ontologias; (4) Definir estruturas de informação e (5) Construir um sistema de conhecimento do usuário focado em informações sobre a avaliação. Tipo de organização/produto avaliados: Organizações de desenvolvimento de software. Resultado obtido com a metodologia utilizada (diagnóstico/avaliação): Estudos no campo do gerenciamento de projetos em relação à redução do esforço usando este sistema mostrou: 24% de redução do esforço através da realização da avaliação CMMI e em paralelo a ISO 15504, 39% de redução do esforço através da realização de uma avaliação CMMI em uma organização já certificada ISO 9001:2000, 45% de redução do esforço através da realização da ISO 15504, avaliação CMMI e avaliação ISO em paralelo, em uma organização já certificada na ISO 9001:2000. Ciclo de vida: A pesquisa propõe uma abordagem que combine ferramentas de avaliação, plataformas de conhecimento baseados em wiki e sistemas especialistas de auto aprendizagem. Não tem por foco o mapeamento ou avaliação do ciclo de vida de 6 A ideia central do sistema Wiki é que qualquer texto original possa ser alterado, de modo que novos conhecimentos sejam incorporados aos já existentes.

82 82 organizações desenvolvedoras de software. Seu foco está em gerir conhecimento para reduzir o esforço em iniciativas de avaliações MPS A QUESTIONNAIRE BASED METHOD FOR CMMI LEVEL 2 MATURITY ASSESSMENT Metodologia de avaliação utilizada: Um conjunto de questões foram desenvolvidas com o propósito relativamente fácil e de uma forma mais ou menos confiável de se indicar se uma empresa atende aos requisitos do CMMI nível de maturidade 2. Descrição do processo de avaliação: O questionário foi aplicado em cinco empresas de software. Uma pessoa responsável foi identificada para responder as questões colocadas. As entrevistas geralmente levavam cerca de 1 hora e meia. Estas empresas alegaram terem adotado uma abordagem de processo para obtenção de qualidade, alguns muito recentemente, alguns por mais tempo. As respostas de cada empresa para as perguntas em uma área de processo foram calculados. Tipo de organização/produto avaliados: 5 organizações de software da Turquia. Resultado obtido com a metodologia utilizada (diagnóstico/avaliação): Os resultados mostram que o método pode ser utilizado para os fins declarados. Um limite pode ser colocado em uma pontuação de cerca de 80% para indicar êxito. O método não se preocupa em absoluto com níveis mais elevados. No entanto, uma pontuação de 80 ou mais, indica ter alcançado o nível de maturidade 2. Os resultados também reforçaram a crença de que o tamanho de uma empresa de software é um fator importante na sua capacidade de alcançar níveis mais elevados na escada de maturidade do CMMI. Ciclo de vida: O propósito desta pesquisa foi desenvolver um questionário para verificar se organizações de desenvolvimento de software atendem aos requisitos do CMMI nível 2.

83 USING SCRUM TO GUIDE THE EXECUTION OF SOFTWARE PROCESS IMPROVEMENT IN SMALL ORGANIZATIONS Metodologia de avaliação utilizada: O objetivo deste artigo é apresentar o processo PfemCOMPETISOFT, que utiliza o framework de melhoria COMPETISOFT. O PfemCOMPETISOFT é usado para orientar a incorporação em seus processos e das oportunidades de melhoria que possam ser descobertas na atividade de diagnóstico. Descrição do processo de avaliação: O processo utiliza o Scrum. Tipo de organização/produto avaliados: 2 organizações de pequeno porte. Empresa 1: Desenvolvimento de portais organizacionais, soluções de e-commerce, sistemas de informação geográfica e software de suporte para os centros de educação. Empresa 2: Organização acadêmica que combina atividades de pesquisa e desenvolvimento com projetos de desenvolvimento de software para outras organizações. Resultado obtido com a metodologia utilizada (diagnóstico/avaliação): Empresa 1: Ficou satisfeita com o resultado do ciclo de melhoria, já que ter um processo visível e explicitamente definido para o desenvolvimento de software e gerenciamento de projetos permitiu a empresa atender a demanda de mais clientes, e para aumentar a equipe. A Empresa 1 particularmente apreciou a abordagem de trabalhar com pequenos passos de melhoria com uma recompensa tangível de curto prazo. O programa estabeleceu a base para a melhoria do processo, e a Empresa 1 está melhorando seus processos para ser compatível ao CMMI nível 2. Quanto a Empresa 2, o ciclo de melhoria permitiu a esta organização ter uma melhor percepção e controle sobre o desenvolvimento de software e processos de gerenciamento de projeto. Tal como no caso da Empresa 1, a organização apreciou a abordagem de trabalhar com pequenos passos de melhoria. Ciclo de vida: A pesquisa não tem por objetivo identificar o ciclo de vida de uma organização desenvolvedora de software. O principal objetivo desta pesquisa está em propor às organizações uma abordagem que possa orientar oportunidades de melhorias através de relatórios de diagnóstico.

84 ASSESSMENT METHODOLOGY FOR SOFTWARE PROCESS IMPROVEMENT IN SMALL ORGANIZATION Metodologia de avaliação utilizada: Metodologia de avaliação METvalCOMPETISOFT Descrição do processo de avaliação: Esta metodologia: (i) incorpora a estratégia de avaliações internas conhecidas como avaliação rápida, o que significa que estas avaliações não ocupam muito tempo ou utilizam uma quantidade excessiva de recursos, nem são muito rigorosas e (ii) atende a todos os requisitos descritos na literatura para uma proposta de avaliação que é personalizada para as características típicas de pequenas empresas. Esta metodologia inclui: (i) Um processo para avaliação de processos de software, PvalCOMPETISOFT, para ajudar a diagnosticar o processo de software passo a passo. (ii) Um modelo de avaliação para a determinar da capacidade de processos de uma organização de software pequena e (iii) Uma ferramenta de apoio ao processo de avaliação. Tipo de organização/produto avaliados: 8 Organizações (Desenvolvimento Web, Desenvolvimento customizado, Desenvolvimento para organizações públicas, Sistemas integrados de gestão de serviços, Software para gerenciar e controlar o sistema de gestão da qualidade ISO , Software para telefonia móvel e dispositivos portáteis, Software para apoiar os processos de gestão do conhecimento organizacional, Software para gestão financeira, sistemas de automação e logística). Resultado obtido com a metodologia utilizada (diagnóstico/avaliação): Os resultados obtidos a partir dos estudos de caso mostram que esta metodologia é aplicável a pequenas organizações. A metodologia de avaliação proposta estabelece os elementos necessários para ajudar a diagnosticar o processo em pequenas organizações, enquanto procuram fazer a sua aplicação economicamente viável em termos de recursos e tempo. A partir da aplicação inicial nas oito organizações e tendo em conta o esforço envolvido, o conhecimento de processos, a melhoria do processo realizado com base neste conhecimento e os benefícios descritos pelas empresas, pode ser visto que o método de avaliação proposto é útil, prático e apropriado para diagnóstico de processos em pequenas empresas. Além disso, os resultados de sua aplicação em EThree mostram

85 85 que a metodologia de avaliação proposta também pode ser adequada a organizações de médio porte. Com a informação gerada pela metodologia de avaliação e com o plano de avaliação preliminar, seis ciclos de melhoria foram realizados e concluídos em seis organizações, que lhes permitiu aumentar o nível de capacidade dos processos avaliados. Ciclo de vida: O levantamento do ciclo de vida, foi mapeado através da metodologia METvalCOMPETISOFT, a mesma buscou apresentar uma metodologia de avaliação para organizações de desenvolvimento de software, de forma rápida e simples SURVEYING AND EVALUATING TOOLS FOR MANAGING PROCESSES FOR SOFTWARE-INTENSIVE SYSTEMS Metodologia de avaliação utilizada: Para capturar o processo existente, uma série de entrevistas foram realizadas com as equipes de desenvolvimento e integradores do processo. Um critério de avaliação, com base nos quadros de requisitos de Kellner, foi considerado para avaliar aspectos de modelagem de processos das ferramentas. Todas as entrevistas foram realizadas utilizando o mesmo questionário. O questionário foi dividido em sete seções relacionadas com a organização, planejamento do projeto, projeto de arquitetura e design, transferência do desenvolvimento para a integração, integração, testes e também algumas questões gerais. Descrição do processo de avaliação: Com os dados coletados nas entrevistas, foram identificados elementos de processo básicos, tais como papéis, atividades e produtos de trabalho. Tipo de organização/produto avaliados: Organização de desenvolvimento de software. Software aplicativo de automação de processos. Resultado obtido com a metodologia utilizada (diagnóstico/avaliação): Não demonstra um quadro de resultados de avaliação. Ciclo de vida: O resultado da organização avaliada demonstrou que a mesma usa uma combinação de modelo cascata e metodologias de processos ágeis para o desenvolvimento de seus produtos.

86 USING THE SOFTWARE PROCESS IMPROVEMENT APPROACH FOR DEFINING A METHODOLOGY FOR EMBEDDED SYSTEMS DEVELOPMENT USING Metodologia de avaliação utilizada: Metodologia SPIES. Descrição do processo de avaliação: SPIES é organizado por fases que são compostas por atividades mais específicas. A abordagem iterativa de SPIES assegura que o processo de desenvolvimento deve ser testado, em cada fase, e não no fim do projeto. Essa metodologia utiliza um repositório de artefatos (ou repositório de ativos) para introduzir a melhoria de processos em cada fase. Este repositório contém modelos para cada atividade (produtos), diretrizes para executar atividades e atribuições de papéis. Da mesma forma que o CMMI-DEV v1.2, SPIES recomenda para cada atividade (quanto possível) o uso de uma ferramenta específica para o planejamento do projeto, estimativa e processo de trabalho, a modelagem de requisitos, validação do sistema, entre outros. Tipo de organização/produto avaliados: Organização desenvolvedora de sistemas embarcados. Resultado obtido com o diagnóstico/avaliação: Para testar a metodologia SPIES e avaliar a aplicabilidade, foi implementado com sucesso um protótipo de sistema de semáforos, em uma universidade. Uma das desvantagens observadas, na SPIES, está relacionada com o conhecimento anterior. Um repositório de conhecimento pode resolver este problema, através do feedback dos usuários. Ciclo de vida: O ciclo de vida de desenvolvimento do sistema de semáforos não foi mapeado mas a metodologia SPIES possui as seguintes fases do processo: Planejamento de projeto, Especificação de requisitos, Design de produto, Desenvolvimento de produto, Integração do produto, Validação do produto, Entrega e manutenção do produto e Melhoria contínua do produto. - Características do ciclo de vida/processo da organização: O sistema de semáforo foi projetado para ser usado dentro do campus da universidade e inclui três componentes: o componente de sensor para detecção de veículos e pedestres, um visor do painel frontal (FPD) para configurar automaticamente o sistema e o componente interno para gerenciar o tráfego. É importante dizer que, trata-se de um ambiente universitário, não

87 87 há o tipo de tráfego, como uma rua comum. O componente de gestão do tráfego inclui cinco modos: modo seguro, interseção noite modo de baixo volume, modo de ciclo de resposta, o modo de tempo de ciclo fixo e modo adaptativo. O sensor pode detectar veículos (prioridade de veículos e de veículos de emergência) e pedestres. - Ciclo de vida comparado a literatura: O ciclo de vida do SPIES pode ser comparado ao modelo iterativo SOFTWARE PROCESS IMPROVEMENT THROUGH THE LEAN MEASUREMENT (SPI-LEAM) METHOD Metodologia de avaliação utilizada: Método Lean. O método permite a avaliação do desempenho do processo de desenvolvimento e toma ações contínuas para se chegar a um processo de software mais enxuto ao longo do tempo. O método combina o paradigma de melhoria da qualidade com método Lean. O método baseia-se na medição de inventários que representam diferentes dimensões do desenvolvimento de software (desenvolvimento normal, trabalho, trabalho extra e qualidade de software). Descrição do processo de avaliação: O método se baseia no fundamentos do QIP (Quality Improvement Paradigm). E consiste nas etapas: (1) caracterizar o projeto atual, (2) definir metas quantificáveis e medições, (3) escolher modelos e métodos de processo, (4) executar processos e coletar e validar os dados coletados, (5) analisar os dados coletados e recomendar melhorias, e (6) do pacote e armazenar experiências feitas. Tipo de organização/produto avaliados: Não houve uma organização para ser avaliada. O método foi avaliado sob o ponto de vista de 2 representantes da Ericsson AB, na Suécia, responsáveis pela melhoria de processos de software na empresa. Resultado obtido com a metodologia utilizada (diagnóstico/avaliação): O Lean é flexível, pois permite que as empresas escolham os inventários e métodos de análise ajustando as suas necessidades da melhor forma. Assim, o método poderá ser aplicável em vários contextos. Os praticantes que refletiram sobre o método e concordaram em relação a como há proximidade do problema. Eles, por exemplo, observaram que os inventários estavam abaixo do nível de capacidade. Além disso, eles concordaram com

88 88 a necessidade de realizar uma análise combinada de inventários para ter uma visão completa da situação atual. Ou seja, o risco de medidas de otimização é drasticamente reduzido. Ciclo de vida: A pesquisa propõe um método que permite a avaliação do desempenho do processo de desenvolvimento de organizações desenvolvedoras de software e a partir desta avaliação é possível tomar ações de melhoria para se atingir um processo de desenvolvimento mais enxuto AN APPLICATION TOOL TO SUPPORT THE IMPLEMENTATION OF INTEGRATED SOFTWARE PROCESS IMPROVEMENT FOR MALAYSIA'S SME Metodologia de avaliação utilizada: A pesquisa propõe uma ferramenta de auxílio as implementações de melhoria de processo de software em organizações de pequeno porte na Malásia. A proposta ferramental contém os módulos de coleta de dados para o processo/projeto, Gap Analisys 7, Avaliação de capacidades, Plano de melhorias e um Gerador de relatórios. Descrição do processo de avaliação: A ferramenta possui uma camada de dados que está relacionada com a base de conhecimento (Estudos de caso e Normas) e o usuário fornece uma entrada de dados através de auto avaliação. Tipo de organização/produto avaliados: Ferramenta desenvolvida para auxiliar a melhoria de processo em pequenas organizações da Malásia. Resultado obtido com a metodologia utilizada (diagnóstico/avaliação): Não apresenta resultados da ferramenta aplicada em organizações. Ciclo de vida: A proposta desta pesquisa não está em avaliar ou identificar um ciclo de vida, mas sim em propor uma ferramenta que gere relatórios que possam ser utilizados como plano de melhoria em processos. 7 Comparativo de desempenho operacional atual com o melhor desempenho possível.

89 SOFTWARE PROCESS IMPROVEMENT SUCCESS FACTORS FOR SMALL AND MEDIUM WEB COMPANIES: A QUALITATIVE STUDY Metodologia de avaliação utilizada: Pesquisa qualitativa, através dos princípios da grounded theory (teoria fundamentada). Descrição do processo de avaliação: A pesquisa foi realizada através de entrevista com 21 profissionais paquistaneses de 11 pequenas e médias empresas de desenvolvimento web. Tipo de organização/produto avaliados: Organizações desenvolvedoras de aplicações web. Resultado obtido com a metodologia utilizada (diagnóstico/avaliação): As quatro principais contribuições deste estudo foram: (1) Criação de um quadro exploratório dos fatores de sucesso da melhoria de processo de software para pequenas e médias empresas de aplicativos web; (2) Apresenta o ponto de vista da melhoria de processo para pequenas e médias empresas de aplicativos web a partir da perspectiva dos praticantes; (3) Faz uma contribuição metodológica, demonstrando como técnicas de teoria fundamentada podem ser aproveitado na disciplina de engenharia de software e de aplicativos web, para dar maiores retornos sobre o estado atual da prática de MPS e (4) Ajuda na obtenção de uma perspectiva dos profissionais para identificar as características das pequenas e médias empresas de aplicativos web. Ciclo de vida: A pesquisa não teve como propósito mapear o ciclo de vida de organizações de software, o objetivo foi elaborar uma pesquisa que pudesse demonstrar fatores de sucesso de MPS aplicados em organizações desenvolvedoras de aplicativos web Resultados Questão de pesquisa 1 Q1. O ciclo de vida mapeado através do diagnóstico é realmente aquele adotado pela organização desenvolvedora de software?

90 90 O objetivo desta questão de pesquisa foi analisar os estudos que identificam o ciclo de vida da organização desenvolvedora de software, por meio de técnicas de diagnóstico ou outro tipo de avaliação. A maioria dos trabalhos avalia os ciclos de vida das organizações pesquisadas, mas a principal contribuição dos mesmos, está em relação as metodologias de avaliações desenvolvidas para a implementação de iniciativas de melhoria de processo de software. Embora haja entre os trabalhos, àqueles que de certa forma contribuem com metodologias que mapeiam o ciclo de vida e processo de desenvolvimento de software. Os trabalhos que se aproximam da resposta para esta pergunta foram sintetizados na Tabela 2. Tabela 2. Estudos que adotam modelos de ciclo de vida em suas abordagens Estudos Using the software process improvement approach for defining a methodology for embedded systems development using Surveying and evaluating tools for managing processes for software-intensive systems Assessment methodology for software process improvement in small organization Using Scrum to guide the execution of software process improvement in small organizations Questão de pesquisa 2 Q2. Quais os principais trabalhos que envolvem a identificação dos diferentes tipos de ciclo de vida adotados pelas diferentes organizações desenvolvedoras de software, comparados àqueles identificados na literatura? O objetivo desta questão de pesquisa foi analisar estudos que identificam os diferentes ciclos de vida adotados por organizações desenvolvedoras de software e compará-los aos ciclos de vida descritos na literatura. Os trabalhos levantados identificam ou avaliam ciclo de vida, a contribuição dos mesmos em relação a esta pergunta foi no sentido de proporem metodologias que possam ajudar a esta pesquisa, desenvolver uma abordagem que consiga atingir um resultado na qual possa ser mapeado o ciclo de vida de uma organização desenvolvedora de software e verificar se o mesmo poder comparado a algum ciclo de vida existente na literatura. Para aqueles que de certa forma contribuem para o levantamento inicial do ciclo de vida, a metodologia apresentada pelos mesmos, serviu de base para a abordagem desenvolvida para o trabalho atual.

91 Considerações Finais Este mapeamento sistemático mostrou que mapear ciclos de vida de desenvolvimento de software, não é um tema muito fácil de se encontrar. A maioria dos trabalhos pesquisados, trata do assunto como metodologia, incorporando isso nos conceitos dos desenvolvimentos ágeis como Scrum e de modelos como cascata, iterativo e incremental, espiral e ágil. Embora os trabalhos focados em analisar o ciclo de vida do desenvolvimento do software tenham sido poucos, há entre eles àqueles que de certa forma contribuíram com metodologias para uma avaliação inicial do ciclo de vida e processo de desenvolvimento da organização. Apesar de haver poucos resultados com relação ao levantamento inicial de ciclos de vida, a pesquisa trouxe materiais importantes a respeito de avaliações/diagnóstico, bem como a forma como as avaliações foram tratadas. Estes trabalhos contribuíram na elaboração do experimento utilizado no trabalho final. Pode-se dizer que esta pesquisa vem consideravelmente contribuir para a área da melhoria de processos, por ser um tema pouco explorado, mostrando que apesar dos avanços na qualidade do software desenvolvido, ainda há um déficit em trabalhos que relatem tal importância para o mercado. A contribuição deste trabalho, visa atender em parte, as organizações que desejam iniciar um processo de melhoria de desenvolvimento. Os trabalhos analisados, apontam que as organizações, estão cada vez mais em busca de qualidade para o produto final e buscam constantemente maneiras de se produzir um software com qualidade e baixo custo. Por fim, a conclusão extraída desse mapeamento, é que o ciclo de vida de desenvolvimento de software embora pouco explorado, traz soluções eficientes ao desenvolvimento do software, levantando pontos forte, fracos e oportunidades de melhoria através de metodologias e abordagens que atendam as expectativas das organizações na busca de melhoria de processo de software.

92 92 4 MODELO PROPOSTO Tendo sido levantadas as fases presentes no processo de identificação do ciclo de vida de desenvolvimento de uma organização intensiva em software que foram detalhadas na fundamentação teórica (Capítulo 2) e no estado da arte (Capítulo 3) é possível identificar as necessidades e propor uma abordagem de apoio à identificação do ciclo de vida de desenvolvimento de software a partir de uma metodologia organizada em 6 etapas. Cada uma das etapas é detalhada nas próximas seções. Este capítulo é organizado da seguinte forma: a Seção 4.1 apresenta uma visão geral da abordagem proposta; em seguida a Seção 4.2 com a metodologia para construção e avaliação da base de conhecimento e dentro dela tem-se as subseções que descreve a revisão da literatura, a Subseção descreve a modelagem das árvores de decisão, na apresenta as regras de produção, a aborda a ferramenta de sistema especialista, a descreve a avaliação da base de conhecimento, e por fim a aborda a aplicação do diagnóstico. 4.1 VISÃO GERAL A abordagem para autodiagnostico proposta neste trabalho é uma continuação da proposta de diagnóstico realizada por Moreira (2012), na qual foi proposto o mapeamento do processo de desenvolvimento de software, levando em consideração a análise de requisitos e a gerência de projetos de acordo com o nível G do MPS.BR. Visando a construção de um sistema especialista para mapear o ciclo de vida e processo de desenvolvimento adotado pela organização, foi construída uma nova base de conhecimento. A base de conhecimento é composta pelo material analisado na revisão da literatura para a construção das árvores de decisão, na qual essas árvores foram avaliadas por especialistas de três organizações e a mesma foi realizada presencialmente e através de vídeo conferência. Após essa avaliação, uma revisão com correções e alterações nas árvores foi realizada com o objetivo de refinar o conteúdo. A partir desta revisão, profissionais da área de MPS avaliaram as árvores como parte da aquisição do conhecimento, para a base de conhecimento. Foi então realizada mais uma revisão dessas árvores. A partir desta última revisão nas árvores, regras de produção foram construídas para o desenvolvimento do sistema especialista. Em seguida, o sistema especialista foi construído com base

93 93 nessas regras de produção e avaliado inicialmente por um especialista e um gerente de projetos, para então passar por uma revisão. Avaliações em organizações de software e com especialistas MPS foram realizadas. Com os resultados obtidos destas avaliações, uma nova revisão do sistema especialista foi realizada, por fim foi aplicada mais uma avaliação com 2 especialistas MPS. Junto as avaliações foi aplicado o método GQM. A Figura 16, representa a metodologia que foi adotada para o modelo proposto incluindo a avaliação GQM. Revisão da literatura Modelagem das árvores de decisão 1) Construção 2) Avaliação com 3 organizações 3) Revisão 4) Entrevista ccom 3 especialistas MPS 5) Revisão 1) Construção Sistema Especialista 2) Entrevista com especialista e gerente de projetos Avaliação do Sistema Especialista e Avaliação GQM 1) Especialistas 2) Organizações Figura 16. Metodologia Fonte: Próprio autor. Revisão dos resultados com 2 especialistas

94 METODOLOGIA PARA CONSTRUÇÃO E AVALIAÇÃO DA BASE DE CONHECIMENTO Uma base de conhecimento é um conjunto de sentenças, que expressam uma linguagem que representa alguma asserção sobre o mundo, ou seja, o conhecimento está contido em agentes sob a forma de sentenças em uma linguagem de representação do conhecimento que estão armazenadas em uma base de conhecimento. O conhecimento que será adquirido pelo sistema é a fonte de raciocínio do mesmo (RUSSELL; NORVIG, 2004). A base de conhecimento é considerada a parte principal de um sistema especialista pois contem conhecimento sob a forma de regras de produção, quadros, redes semânticas, ou seja, de várias formas. Uma das mais comuns é por sentenças do tipo: SE ENTÃO. Neste trabalho, para a construção da base de conhecimento foram utilizadas várias técnicas de aquisição de conhecimento, que foram implementadas da seguinte forma: uma revisão da literatura foi realizada com objetivo de se obter conteúdo suficiente para em seguida construir as árvores de decisão, após uma validação, foram realizadas entrevistas com especialistas de 3 organizações de software, para então ser realizado um refinamento dessas árvores, seguido de uma revisão e a partir deste contexto foram estabelecidas as variáveis que deram início a construção das regras de produção. A metodologia para construção e avaliação do sistema especialista proposta neste trabalho possui as seguintes etapas: Revisão da literatura, Modelagem das árvores de decisão, Regras de produção, Validação da base de conhecimento e Aplicação da base de conhecimento Revisão da Literatura No mapeamento sistemático realizado foram levantados através de pesquisas em sites de artigos científicos internacionais, trabalhos relacionados a abordagens desenvolvidas para identificação do ciclo de vida de desenvolvimento visando a melhoria no processo de software. Através do mapeamento sistemático realizado foram identificados métodos de diagnóstico, conceitos de avaliação do SCAMPI e MA-MPS, modelos de referência com CMMI e MPS.BR, entre outros conceitos já estudados anteriormente no presente trabalho. Estas pesquisas estão melhor descritas na Seção 3 e no Apêndices A. Todo conteúdo pesquisado faz parte do material que contribuiu para o desenvolvimento de uma metodologia que atenda o sistema especialista apresentado neste trabalho.

95 95 Realizou-se uma busca e seleção de pesquisas relacionadas a autodiagnostico, diagnóstico e avaliação, a fim de levantar um escopo maior de informações acerca da maneira como os diagnósticos, ferramentas de diagnóstico, avaliações do ciclo de vida de desenvolvimento e avaliações de melhoria de processo de desenvolvimento vêm sendo conduzidas pelas pesquisas. Esta busca e seleção retornou um conjunto de estudos que foram avaliados pelo pesquisador quanto às ferramentas de diagnóstico utilizadas e maneira de conduzir uma avaliação para melhoria de processos de software. Neste ponto da pesquisa, não se faz evidente a existência de estudos, com a utilização de ferramentas para diagnóstico, envolvendo a identificação do ciclo de vida de uma organização. As pesquisas abordam metodologias para avaliação de processos de software, ferramentas para diagnóstico, abordagens para realização de diagnóstico, tipos de organizações, metodologia adequada a cada tipo e métodos para aplicação de avaliação com foco na melhoria de processo. As pesquisas ainda mostraram que a utilização de metodologias para avaliação tem apresentado relevante aceitação em organizações de pequeno e médio porte. Embora trabalhos relacionados a ciclos de vida de desenvolvimento tenham sido poucos, o retorno das pesquisas trouxe materiais importantes para a construção de uma abordagem para avaliação e diagnóstico do processo de desenvolvimento de software, contribuindo para a elaboração da metodologia de avaliação deste estudo. A fundamentação teórica e o mapeamento sistemático contribuíram para estruturar a abordagem proposta e levantar informações a respeito de: Metodologias de Avaliação, Diagnóstico, Abordagens para Avaliação, Organizações Desenvolvedoras, Porte/Características das organizações, Modelos de Ciclo de Vida, Processos de desenvolvimento Modelagem das Árvores de Decisão Uma árvore de decisão toma como entrada um objeto ou situação descritos por um conjunto de atributos e retorna uma decisão o valor de saída previsto, de acordo com a entrada (RUSSELL; NORVIG, 2004). A fim de modelar o conhecimento envolvendo as fases de um ciclo de vida de desenvolvimento de software, foi criado um conjunto de árvores de decisão. Estas árvores permitiram a definição das regras de produção que serão utilizadas pelo sistema especialista.

96 96 Para criar essas árvores foi necessário basear-se nos modelos de referência como o MPS.BR e o CMMI-DEV, nos relatórios com resultados de avaliações realizadas por uma empresa de consultoria em melhoria de processo de software, em um experimento inicial realizado com gerentes de projetos de 3 organizações de desenvolvimento de software da região de Blumenau e Joinville, e em entrevistas realizadas com especialistas em MPS. As perguntas e respostas utilizadas para compor a estrutura de cada árvore baseiam-se nos modelos de referência: CMMI-DEV (Capability Maturity Model Integration for Development) (SEI, 2010a); Neste modelo contribuíram para a construção das árvores de decisão os conceitos das áreas de processo (Gestão de Requisitos, Planejamento de Projeto, Monitoramento e Controle de Projeto, Garantia da Qualidade e Gestão de Configuração) e por fim foram utilizados os conceitos relacionados as métricas e práticas das áreas de processo. Para construir as árvores foram mapeadas as áreas de processo e a partir das metas e práticas de cada processo, os nós e as ramificações das árvores foram sendo definidos. MR-MPS-SW (Modelo de Referência para Melhoria de Processo de Software) (SOFTEX, 2012). Para o MR-MPS-SW, foi utilizada a Guia Geral de Software do MPS, onde há uma descrição detalhada dos processos. Para compor as árvores foi utilizado os processos do Nível G do MPS.BR, que já haviam sido utilizados no trabalho de Moreira (2012) e os processos de Gerência de Configuração e Garantia da Qualidade do Nível F do MPS.BR. Para construir as árvores foram mapeadas as áreas de processo e a partir dos resultados esperados, foram definidos os nós e ramificações das árvores. Nos processos de ciclo de vida: RUP (Rational Unified Process) (IBM, 2007); O RUP possui duas dimensões, as fases e as disciplinas, que juntamente aos conceitos do CMMI-DEV e do MR-MPS-SW foram utilizadas para definir algumas árvores. Os conceitos das disciplinas (Modelagem de Negócio, Requisitos, Análise e Projeto, Implementação, Teste, Implantação e Gerenciamento de Projeto) foram traduzidos em perguntas e respostas para que

97 97 pudessem compor os nós das árvores de decisão. As fases do RUP (Iniciação, Elaboração, Construção e Transição) foram necessárias para organizar a sequência de perguntas e respostas em cada árvore. XP (Extreme Programming); Do modelo XP, foram extraídas informações a respeito das práticas utilizadas no modelo. Esses conceitos foram mapeados e utilizados na forma de perguntas e respostas (nós das árvores). Scrum, como um framework para suportar o desenvolvimento e manutenção de produtos complexos (SCHWABER; SUTHERLAND, 2011). O Scrum possui termos específicos do processo, os mesmos foram utilizados nas árvores como forma de identificar se a organização trabalha ou não com esses conceitos. No corpo de conhecimento: SWEBOK (Software Engineering Body of Knowledge) (IEEE, 2014); Em relação ao guia SWEBOK, para auxiliar na construção das árvores, as áreas da engenharia de software que foram utilizadas são: Requisitos de Software, Construção de Software, Qualidade de Software, Teste de Software e Manutenção de Software. Para compor a estrutura das árvores, os conceitos das áreas relacionadas acima, foram traduzidas em perguntas e respostas. E na norma: ISO/IEC (Systems and software engineering - Software life cycle processes) (ISO/IEC 12207, 2008); A contribuição da ISO/IEC foi em relação a estrutura de cada árvore. Por se tratar de uma norma voltada para processos de ciclo de vida, ela auxiliou na nomeação, distribuição das fases de um ciclo de vida em árvores e parte do conteúdo foi utilizado para compor as perguntas e respostas de cada árvore. Foram elaboradas árvores de decisão, que se referem as fases do ciclo de vida de desenvolvimento de software. São elas: Inicial, Requisitos, Gerência de Projeto, Construção, Testes, Documentação e Manutenção.

98 Descrição das árvores Após o estudo dos modelos de referência (CMMI-DEV e MPS.BR), da norma ISO/IEC 12207, do corpo de conhecimento SWEBOK, dos processos de desenvolvimento e modelos de ciclo de vida citados anteriormente (Seção 2), foram construídas árvores de decisão, onde os ramos de cada árvore contem perguntas e respostas que abrangem informações pertinentes as informações citadas anteriormente. As árvores são focadas nas etapas: 1) Inicial: Possui informações iniciais a respeito de como o desenvolvimento é conduzido. Esta etapa é conduzida com o objetivo de fazer um levantamento inicial do processo de desenvolvimento da organização. Identificando se a organização trabalha com algum modelo de ciclo de vida e como este modelo é trabalhado. 2) Requisitos: Possui informações pertinentes a fase de levantamento e análise de requisitos. Esta etapa busca levantar a forma como são tratados os requisitos do software, desde seu levantamento até a sua entrada na fase de desenvolvimento. 3) Gerenciamento/Acompanhamento de Projeto: Possui informações sobre como é feito o gerenciamento do projeto de desenvolvimento. Nesta etapa o objetivo é identificar como o responsável pelo projeto conduz o mesmo. 4) Solução Técnica: Possui informações a respeito dos diagramas utilizados para modelar o sistema. O objetivo principal é levantar se a organização trabalha com diagramas e quem os desenvolve. 5) Construção: Possui informações sobre a etapa de desenvolvimento/implementação dos requisitos. O objetivo desta fase é identificar as etapas de construção do requisito. 6) Testes: Possui informações sobre a fase de planejamento e elaboração dos testes. Na etapa de testes, o objetivo é identificar se a organização trabalha com um planejamento de testes e se possui casos de testes, bem como a condução dos mesmos.

99 99 7) Documentação: Possui informações sobre a fase de documentação dos requisitos do sistema. Nesta etapa, geralmente, são elaborados os manuais que são disponibilizados para os clientes/usuários, a fim de facilitar o entendimento e a usabilidade do produto. 8) Manutenção: Possui informações a respeito das correções que ocorrem após uma versão/release liberada para o cliente, que devido a ocorrência de erros, retornam a equipe de desenvolvimento; A árvore Inicial (ver Apêndice B) busca desenhar um perfil da organização, verificando se ela trabalha por projeto, qual metodologia de desenvolvimento que ela adota, como os projetos são organizados, fases ou etapas e atividades. O objetivo destas informações é possibilitar distinguir o processo da organização, como sendo voltado a projeto ou por demanda. A Figura 17 apresenta um trecho da árvore Inicial. Figura 17. Trecho da árvore inicial Fonte: Próprio autor.

100 100 Para a entrevista utilizando o sistema especialista, o trecho da árvore ilustrado na Figura 17, foi representado no Quadro 7. Quadro 7. Representação da entrevista relacionada a árvore inicial Entrevistador: A sua organização costuma trabalhar por projeto? Organização: Sim Entrevistador: Ela utiliza alguma metodologia em seus projetos? OU Entrevistador: A sua organização costuma trabalhar por projeto? Organização: Não Entrevistador: A organização trabalha por demanda? Organização: Sim As demais entrevistas seguem o mesmo padrão da entrevista relacionada a árvore inicial, representada no Quadro 7, sendo cada uma voltada para suas características. A árvore Requisitos (ver Apêndice B) levanta informações a respeito da análise de requisitos, como quem avalia, como é registrado, quem são os responsáveis pela aprovação, prioridade do requisito entre outros aspectos. O objetivo desta árvore é mapear a forma como o requisito chega ao desenvolvimento, isto é, o entendimento dos requisitos junto ao fornecedor de requisitos e como ele é tratado, quem avalia, quem aprova, a prioridade e principalmente como ele é documentado. A Figura 18 mostra um exemplo da árvore de requisitos. Figura 18. Trecho da árvore Requisitos Fonte: Próprio autor.

101 101 A árvore Projeto (ver Apêndice B) levanta informações a respeito do projeto de desenvolvimento do software, como responsáveis pela aprovação, documentos utilizados, medição, cronograma, orçamento, escopo e ferramentas de gerenciamento. O objetivo desta árvore é utilizar os conceitos de gerência de projeto e mapear se a organização utiliza esses conceitos ou parte deles. A Figura 19 mostra um exemplo da árvore de projetos. Figura 19. Trecho da árvore Projeto Fonte: Próprio autor. A árvore Solução Técnica (ver Apêndice B) levanta informações a respeito da fase de elaboração de diagramas, como o de atividades, casos de uso e classes. Verifica quem é o responsável pela construção e manutenção dos mesmos. O objetivo desta árvore é mapear o processo antes de iniciar a construção e verificar se a organização possui esse nível de detalhamento de requisitos. A Figura 20 mostra um exemplo da árvore de solução técnica.

102 102 Figura 20. Trecho da árvore de solução técnica Fonte: Próprio autor A árvore Construção (ver Apêndice B) levanta informações a respeito do desenvolvimento do software, tais como, prioridade de execução de tarefas, quem participa, quem é o responsável, como as informações são documentadas, quem faz a análise, quem implementa, se há teste unitário. O objetivo desta árvore é mapear o processo de desenvolvimento da organização, identificando o escopo do trabalho para o projeto e contribuindo para o mapeamento do ciclo de vida. A Figura 21 mostra um exemplo da árvore de construção.

103 103 Figura 21. Trecho da árvore Construção Fonte: Próprio autor. A árvore Testes (ver Apêndice B) levanta informações a respeito da etapa de testes, como quem elabora o plano de testes, quem participa, quem acompanha, quem testa as rotinas entre outros. O objetivo desta árvore é identificar a estratégia de validação da organização mapeando as atividades de teste e contribuindo para identificação do ciclo de vida. A Figura 22 mostra um exemplo da árvore de testes.

104 104 Figura 22. Trecho da árvore Testes Fonte: Próprio autor. A árvore Documentação (ver Apêndice B) levanta informações a respeito da documentação dos requisitos para envio ao usuário/cliente, para que o mesmo possa através de um documento, como um manual, trabalhar com o requisito implementado. O objetivo desta árvore é mapear como o requisito chega nesta fase, quem é o responsável e como é liberada essa documentação. A Figura 23 mostra a árvore de documentação.

105 105 Figura 23. Trecho da árvore de documentação Fonte: Próprio autor A árvore Manutenção (ver Apêndice B) levanta informações a respeito das correções que ocorrem no software depois que uma versão/release é liberada para o cliente, como é priorizada a correção, se existe uma equipe destinada a realização apenas das correções, quem é o responsável, como é feita a liberação. O objetivo desta árvore é identificar a estratégia de gerenciamento de projeto para quando ocorrer um erro no software depois de liberado para o cliente. Identificar como desenvolvimento conduz a correção destes erros. Esta árvore também levanta informações a respeito das alterações de requisito e como elas são tratadas. Questões como, reaprovação do requisito, quem faz, quem avalia a alteração do requisito, como é feito o mapeamento das partes alteradas (rastreamento) e como é feita a atualização. Levantar as tomadas de decisão do responsável, quando as alterações ocorrerem, sem prejudicar a entrega final deste requisito. A Figura 24 mostra a árvore de manutenção.

106 106 Figura 24. Trecho da árvore Manutenção Fonte: Próprio autor Avaliação inicial das árvores Uma avaliação inicial foi realizada para que se pudesse fazer um primeiro refinamento das árvores, buscando atingir um nível de informação semelhante às informações utilizadas por especialistas em consultorias de melhoria de processos, na qual os mesmos buscam inicialmente mapear o ciclo de vida de desenvolvimento das organizações. As entrevistas iniciais foram realizadas com três pessoas ligadas a área de engenharia de software de três diferentes empresas, cada uma de um ramo de atividade diferente da outra. O Quadro 8 apresenta algumas características de cada pessoa entrevistada. Quadro 8. Características dos entrevistados Avaliação Conhecimentos em: Função atual Tempo na organização A CMMI, Scrum, RUP Gerente de Projetos 1 ano e 3 meses B CMMI, Scrum Gerente de Projetos 3 anos e 8 meses C CMMI, MPS.BR, Scrum, RUP Coordenador de Projetos 1 ano e 1 mês

107 107 inicial. O Quadro 9 apresenta algumas características das organizações entrevistadas para a avaliação Quadro 9. Características das organizações Avaliação Porte Principal atividade A Média Software padrão com customizações para clientes. B Média Software padrão com customizações para clientes. C Média Software por encomenda (fábrica) Possui processo formal? Tipo de produto de software Não. Ainda em fase de - Software voltado para implantação web - Software voltado para Processo desenvolvido pela empresa com base nos conceitos do CMMI Sim. A base é o modelo cascata (desenvolvimento) e PMBOK (gerenciamento de projetos) desktop - Software voltado para desktop - Software voltado para web - Prestação de serviços A primeira entrevista foi realizada presencialmente, nomeou-se de Avaliação A, que serviu de alinhamento possibilitando uma melhor qualidade de material para as outras duas entrevistas. As demais entrevistas foram realizadas por , na qual o material foi enviado e respondido. O primeiro material utilizado foram as árvores de decisão, de acordo com o resultado foi mapeado o processo e o mesmo desenhado em forma de fluxo, em seguida esse material foi avaliado pelo entrevistado para verificar se o texto e fluxo formulado estavam de acordo com a realidade da organização. Por último, questões relacionadas ao perfil da empresa, perfil do entrevistado e algumas questões sobre o experimento foram respondidas. A Avaliação A teve pontos de discussão relevantes, como por exemplo, o fluxo das árvores de decisão, muitos pontos tiveram que ser redesenhados para que pudesse facilitar o entendimento do entrevistado em relação ao conteúdo. Outro ponto chave da avaliação presencial foi em relação a alguns termos, que para o entrevistado teve um sentido e para o entrevistador teve outro sentido, resultando numa dupla interpretação. Em relação ao texto o mesmo foi ajustado em alguns pontos e o fluxo também. Esse ajuste foi devido a ordem em que as perguntas das árvores foram formuladas, a ordem das mesmas não

108 108 garante a ordem das atividades do processo, ocasionando em um erro de fluxo na etapa de requisitos, mais precisamente entre a validação do requisito e o início do projeto. A segunda entrevista, nomeou-se de Avaliação B, feita por , o entrevistado não relatou dificuldades. O texto formulado não sofreu mudanças, assim como o fluxo. O entrevistado não relatou sentir falta de nenhuma etapa. A terceira entrevista, nomeou-se de Avaliação C, feita por , o entrevistado teve dúvidas em relação ao objetivo do experimento o que dificultou um pouco as respostas, o mesmo também sentiu falta de abordar alguns temas da área de engenharia de software, como as fases Projeto Arquitetural e Documentação. Em relação ao texto formulado de acordo com as respostas o mesmo foi ajustado em alguns pontos. O fluxo sofreu uma pequena mudança em relação a etapa de testes e na etapa de construção teve que ser inserido a atividade de documentação. Em resumo, com as árvores de decisão desenvolvidas para essa avaliação inicial com o objetivo de desenhar o ciclo de vida da organização, foi importante, pois com os resultados obtidos, melhorias no fluxo das árvores foram feitas, assim como a inclusão de mais perguntas e novas árvores que irão atender melhor as etapas do ciclo de desenvolvimento de software de uma organização. Conclusões As avaliações realizadas puderam mostrar parte do processo de desenvolvimento de cada organização, sendo que alguns pontos no que diz respeito ao desenho das árvores sofreram melhorias, visando como resultado a modelagem do fluxo de atividades de forma mais ordenada. Foram desenvolvidas mais algumas árvores de decisão visando atender outras fases do processo. Em geral os resultados das avaliações realizadas mostraram-se adequados, apresentando relatórios com uma modelagem do fluxo de atividades satisfatórios e alinhados com o ciclo de vida de desenvolvimento das organizações Revisão das árvores de decisão Após a avaliação realizada nas 3 organizações, foi realizada uma revisão nas árvores de decisão, para que pontos onde houve discussão, solicitações de mudança e correções pudessem ser ajustados, visando a melhora na qualidade das informações contidas nas árvores.

109 Entrevista com especialistas Segundo Rezende (2003), uma entrevista estruturada é uma abordagem correlata embora significativamente mais produtiva, referindo-se à identificação dos elementos e relações do domínio, essas podem ser feitas na fase de identificação e conceituação, na qual é formulada a descrição do domínio. Essa abordagem é baseada em um processo sistemático orientado a um objetivo que leva a uma comunicação organizada entre o especialista e o entrevistador, ajudando a evitar distorções decorrentes da subjetividade. Nesta etapa da metodologia, foi realizada entrevistas com especialistas da área de melhoria de processos de software, a fim de, verificar e validar as informações contidas nas árvores de decisão e como forma de aquisição de conhecimento. Para estas entrevistas foram entrevistados 3 avaliadores e implementadores MPS. As entrevistas foram realizadas através de videoconferência. No momento da entrevista foram realizados apontamentos que geraram informações necessárias para mais um refinamento nas árvores. O objetivo desta nova revisão nas árvores de decisão, foi agregar o conhecimento levantado com as entrevistas. Com essa revisão, as árvores de decisão sofreram alterações como forma de se atingir um maior nível de conhecimento, para que o mesmo possa chegar o mais próximo ao nível de conhecimento de um especialista Regras de Produção Para modelar as informações necessárias para serem utilizadas nas organizações de desenvolvimento de software, regras de produção foram criadas com o intuito de mapear o maior número de informações em relação ao ciclo de vida de desenvolvimento de software de uma organização intensiva em software e um mecanismo de inferência foi construído a fim de definir a ordem com que serão processadas as informações das árvores de decisão para chegar a conclusões ou recomendações de ações. Antes de definir as regras de produção foi necessário modelar o conhecimento envolvendo conteúdo relacionado aos modelos de referência, processos de ciclo de vida e corpo de conhecimento. Para as regras de produção que foram utilizadas no SE do presente trabalho foram criadas árvores de decisão (Subseção 4.2.2), que compõem as fases do ciclo de vida de desenvolvimento, as

110 110 mesmas têm como finalidade fazer com que o SE adquira conhecimento suficiente para demonstrar resultados de forma confiável e o mais próximo possível do conhecimento de um especialista em melhoria de processos de software. Com base nas regras de produção o sistema especialista foi desenvolvido com as definições apresentadas neste trabalho, considerando o método de avaliação MA-MPS, os requisitos estabelecidos no CMMI-ARC e na ISO/IEC Desta forma, a avaliação suporta os modelos MPS.BR, CMMI e norma ISO/IEC 12207, respectivamente. O uso do modelo CMMI e da norma ISO/IEC foram considerados devido seu reconhecimento internacional. O modelo MPS.BR foi também considerado porque além de ter sido desenvolvido de forma compatível ao modelo e norma supracitados é nacionalmente reconhecido e está também alinhado à realidade das MPEs (Micro e Pequenas Empresas) de software brasileiras. A Figura 25 apresenta uma regra de produção da árvore inicial, utilizadas para compor a metodologia do SE. Figura 25. Trecho contendo uma regra de produção Fonte: Próprio autor. Para esta pesquisa, o encadeamento progressivo será utilizado em todas as árvores de decisão, visto que o ponto de partida de cada uma é o problema inicial ( Quais são as atividades de cada fase do ciclo de vida? ) e o alvo é a solução ( Atividades que caracterizam as fases do ciclo de vida ). O nó inicial começa com a fase do ciclo e então vários outros nós são percorridos buscando uma solução, que seria a relação de atividades executadas para cada fase do ciclo de vida. No trabalho realizado por Moreira (2012), foram construídas 23 árvores de decisão que geraram 236 regras de produção. Para o trabalho atual, foram construídas 33 árvores de decisão que geraram aproximadamente 572 regras de produção, evoluindo o trabalho iniciado em 2012, para uma

111 111 base de conhecimento mais robusta, que gera resultados mais sólidos para as organizações de desenvolvimento de software. A justificativa que se dá para a quantidade de regras de produção do trabalho atual em relação ao anterior é devido ao tamanho das árvores de decisão, que possuem mais nós do que as árvores construídas anteriormente Ferramenta de Sistema Especialista A ferramenta construída para o trabalho de Moreira (2012), não foi utilizada, devido sua limitação em fazer um levantamento de todas as fases de um ciclo de vida. A ferramenta apenas considerou o nível G do MPS.BR, que trata o gerenciamento de projetos e de requisitos. No presente trabalho foram construídas novas regras de produção geradas a partir de árvores de decisão e que contemplam todas as fases de um ciclo de vida. Para a construção do sistema especialista, foi utilizada a ferramenta CLIPSJNI. Uma ferramenta para construção de sistemas especialistas, de domínio público, desenvolvida pela NASA. A linguagem CLIPS foi escrita na linguagem C, que permite portabilidade e rapidez nas execuções e tem sido instalada em diversos tipos de plataformas. Além de possuir vários manuais, incluindo o manual de referência e o manual do usuário Avaliação da Base de Conhecimento A avaliação da base de conhecimento junto a ferramenta de SE, se deu através de um piloto que realizado em uma organização de Joinville e com um especialista em MPS. Para essa avaliação, foi entrevistado um gerente de projetos responsável pelo processo na organização com 10 anos de experiência em gerência de projetos e um especialista MPS com 20 anos de experiência entre coordenação, gerência de projetos e melhoria de processos, em seguida uma revisão do SE foi realizada com as informações coletadas através desta primeira avaliação. Após esta primeira avaliação foram corrigidas algumas perguntas para que as mesmas pudessem ser mais legíveis aos entrevistados. Algumas respostas receberam mais opções de escolha, em outros casos as opções foram alteradas. Foi incluído um espaço ao final dos questionamentos para que os entrevistados pudessem deixar registrados alguns pontos que não foram tratados pelo SE.

112 112 O resultado desta primeira avaliação gerou um diagnóstico com o ciclo de vida da organização, detalhando pontos fortes, pontos fracos e oportunidade de melhorias para a organização avaliada. O especialista simulou uma organização e obteve um diagnóstico semelhante ao diagnóstico já realizado por sua empresa de consultoria. Por fim a base de conhecimento foi revisada com o intuito de melhorar o conteúdo para que os resultados possam chegar o mais próximo ao resultado emitido por um especialista MPS Aplicação do Diagnóstico Após a revisão da base de conhecimento, foram realizadas 2 avaliações de diagnóstico, por 2 especialistas em MPS. O principal objetivo desta avaliação foi fazer um refinamento final, antes do SE ser aplicado em organizações de desenvolvimento e com especialistas MPS. Essas 2 avaliações mapearam alguns pontos de melhoria para o SE, como o reforço de perguntas mais elaboradas para o acompanhamento de projetos, tratamento de problemas, desvios e alterações de requisitos durante o desenvolvimento e ainda foram incluídas perguntas relacionadas a rastreabilidade do requisito. Após a revisão da base de conhecimento e refinamento do SE, foram realizadas avaliações de diagnóstico em organizações de desenvolvimento de software, seguindo a metodologia de entrevistas descrita na Seção 5.1. Para tal, foi utilizada a ferramenta de SE, na qual os responsáveis pelo processo de desenvolvimento avaliaram o ciclo de vida de desenvolvimento que a organização utiliza e a partir disso, foram mapeados pontos positivos e negativos do desenvolvimento, bem como a possibilidade de realizar um levantamento de melhorias. Além das organizações, foram realizadas avaliações com o SE com especialistas MPS, seguindo a metodologia de entrevistas descrita na Seção 5.1. Foi utilizada a ferramenta de SE, na qual os especialistas simularam o processo de uma organização, já avaliada por eles e seus trabalhos de consultoria.

113 O SISTEMA ESPECIALISTA DESENVOLVIDO A partir destas regras de produção um sistema especialista foi desenvolvido, utilizando a ferramenta CLIPSJNI. O motor de inferência utilizado foi o forward chaining por se tratar de uma lógica que parte do problema para a solução, que neste caso, temos como problema identificar partes do processo de desenvolvimento de software que possuem pontos fracos ou que precisam de melhorias e a partir deste levantamento obter um diagnóstico para a solução. O forward chaining foi utilizado devido ao fato de ser o motor que melhor se adequa a realidade da estrutura do sistema especialista desenvolvido para este trabalho. O sistema especialista conta com aproximadamente 132 perguntas, distribuídas entre a fase de requisitos até a fase de manutenção. Após responder às perguntas do sistema, o mesmo emite vários resultados considerando alguns pontos fracos, pontos fortes e oportunidades de melhoria. Para validação inicial do SE, foram entrevistados 1 gerente de projeto e 2 especialistas. Os resultados destas 3 validações, permitiram corrigir falhas no SE, bem como inserir mais perguntas e excluir outras. Foi possível também, melhorar a descrição dos resultados emitidos pelo SE. Após a revisão do SE com base nesta primeira validação inicial, foi possível fazer avaliações do SE junto a especialistas e organizações de desenvolvimento. Ao todo foram 6 organizações entrevistadas e 7 especialistas em MPS. As Figuras 26 e 27, demonstram parte das perguntas e resultados.

114 114 Figura 26. Trecho das perguntas feitas pelo Sistema Especialista Na Figura 26, é possível verificar um trecho das perguntas feitas pelo sistema especialista. No início o sistema procura fazer perguntas que abranjam todo o processo de desenvolvimento. Em seguida, ele segue fazendo perguntas mais específicas à cada fase do ciclo de vida de desenvolvimento. No caso do exemplo exposto pela Figura 26, as regras de produção disparadas podem ser identificadas no Quadro 10. Quadro 10. Regras de Produção. (defrule arv_ini_1 (pergunta (pergunta regra_org_trab_proj) (resposta SIM)) (pergunta (pergunta regra_utiliza_metod) (resposta SIM)) (pergunta (pergunta utiliza_fases) (resposta SIM)) (pergunta (pergunta fases_sequenciais1) (resposta SIM)) => (assert (regra_arv_ini_1 "RP005")) ) (defrule arv_ini_2 (pergunta (pergunta regra_metodologia) (resposta A)) (pergunta (pergunta regra_possui_levantamento1) (resposta SIM)) => (assert (regra_arv_ini_2 "RP_001")) ) (defrule arv_ini_3 (pergunta (pergunta regra_possui_construcao) (resposta SIM)) (pergunta (pergunta regra_possui_testes1) (resposta SIM))

115 115 ) (pergunta (pergunta regra_possui_implantacao1) (resposta NAO)) (pergunta (pergunta regra_possui_manutencao1) (resposta NAO)) => (assert (regra_arv_ini_3 "RP_004")) ) (defrule arv_ini_4 (pergunta (pergunta regra_analise_riscos) (resposta NAO)) (pergunta (pergunta regra_prototipo2) (resposta SIM)) (pergunta (pergunta regra_prot_con_desenv2) (resposta SIM)) (pergunta (pergunta regra_valida_cliente2) (resposta SIM)) (pergunta (pergunta regra_refina_prot2) (resposta SIM)) (pergunta (pergunta regra_valida_novamente2) (resposta SIM)) => (assert (regra_arv_ini_4 "RP_011")) O motor de inferência, no caso da Figura 26, age sempre fazendo uma pergunta e ao receber a resposta dispara a pergunta seguinte de acordo com a resposta informada pelo usuário. Pode-se observar que a primeira pergunta A organização trabalha por projeto? recebe a resposta S (Sim), prosseguindo para a próxima pergunta A organização utiliza alguma metodologia em seus projetos? que também recebe como resposta S (Sim). Através deste raciocínio o sistema especialista vai chegando a conclusões que são detalhadas ao final, no detalhamento dos resultados, demonstrado pela Figura 27. O Quadro 10, demonstra como o raciocínio é feito para o sistema especialista chegar as conclusões de quais regras utilizar para disparar, ao final, os resultados. Cada regra é resultado de um conjunto de perguntas e respostas. Na Figura 27, é possível verificar um trecho dos resultados emitidos pelo sistema especialista. Os resultados são descritos, por árvore de decisão, indicando por onde o SE passou.

116 116 Figura 27. Trecho dos resultados emitidos pelo Sistema Especialista O diagnóstico dos resultados considera os pontos fortes, pontos fracos e oportunidades de melhorias listados pelo SE. A organização pode, com esta informação, aplicar medidas de melhoria, correções, adaptações e mudanças no seu processo de desenvolvimento de software. Para os especialistas, verificar os resultados emitidos pelo sistema especialista, de uma organização avaliada, pode servir como forma de mapear as informações colhidas nas entrevistas e verificar se as mesmas estão de acordo com a realidade da organização sob seu ponto de vista. Embora a interface do sistema especialista precise de melhorias, isto não impede que a avaliação seja realizada. A melhoria na interface pode vir a facilitar as avaliações para quem as realiza. Após a avaliação do SE realizada junto aos especialistas em MPS e organizações de desenvolvimento foi possível fazer uma avaliação GQM sob dois pontos de vista, dos especialistas e das organizações.

117 117 5 AVALIAÇÃO Avaliação de processo de software é um processo de medição subjetivo que envolve o julgamento de pessoas qualificadas para identificação quantitativa de pontos fortes e fracos nos processos (EL-EMAM et al., 1998). O trabalho foi avaliado considerando dois pontos de vista diferentes, utilizando a abordagem GQM (Goal/Question/Metric) proposto por Basili et al. (1994). Uma sob o ponto de vista dos especialistas, a fim de avaliar a adequação do conteúdo da abordagem em relação ao conhecimento em melhoria de processos destes profissionais, o que traz maior confiabilidade dos resultados para as organizações. O segundo ponto de vista, sob a perspectiva das organizações, tem o propósito de verificar a aderência ao resultado, isto é, possibilitar a organização confrontar os dados analisados resultantes da abordagem apresentada neste estudo, com a realidade da mesma. Foram entrevistados 6 especialistas em melhoria de processo de software e 6 organizações intensivas em software situadas em Joinville e Blumenau. Este capítulo apresenta a seguinte organização: a Seção 5.1 detalha a metodologia das entrevistas prevista para a avaliação semi automatizada e a Seção 5.2 aborda as considerações para a aplicação da avaliação e resultados esperados. 5.1 ENTREVISTAS Um processo de entrevista foi desenvolvido visando contemplar a avaliação do sistema especialista. Para tal foi enviado um convite por ao entrevistado, descrevendo o processo de avaliação do SE, após o aceite, foi realizada uma reunião presencial (no caso das organizações) e a pesquisa foi apresentada de forma mais detalhada, por fim, durante a reunião, iniciou-se o processo de execução do sistema especialista. Os resultados do sistema especialista foram apresentados ao entrevistado, que após a entrevista, recebeu o documento gerado com os resultados e um documento de avaliação do SE. Com os resultados em mãos o entrevistado então respondeu ao documento de avaliação e o enviou ao entrevistador. Em posse deste documento de avaliação o entrevistador pode então documentar a avaliação utilizando a abordagem GQM, descrita na Seção

118 118 No caso dos especialistas, a entrevista de avaliação do SE, se deu enviando um com um convite à participação do mesmo na pesquisa. Após o aceite, o ambiente de execução do sistema especialista foi compartilhado. Para os especialistas a metodologia foi adotada desta forma para que os mesmos, de posse do sistema especialista, possam simular diversos processos de desenvolvimento, permitindo uma avaliação de forma mais completa do seu ponto de vista. Em seguida, os especialistas respondem a um documento de avaliação e o enviam ao entrevistador, que sob posse desse documento pode então documentar a avaliação utilizando a abordagem GQM, descrita na Seção A Figura 28, apresenta o processo de entrevistas realizado com as organizações e especialistas. Organização 1ª fase - Apresentação da pesquisa 2ª fase - Reunião e Entrevista - Execução do SE - Apresentação dos resultados 3ª fase - Envio dos resultados - Envio do documento de avaliação Especialistas 1ª fase - Apresentação da pesquisa 2ª fase - Compartilhamento do ambiente para execução do SE - Envio do documento de avaliação Entrevistador - Análise dos documentos de avaliação enviados pelos especialistas e organizações Figura 28. Visão geral do processo de entrevistas Fonte: Próprio autor A Figura 29, apresenta um fluxo de atividades proposto para o processo.

119 119 Convite Feito por , para organizações e especialistas, descrevendo a pesquisa. Execução do SE Nas organizações a execução do SE foi realizada presencialmente. Para os especialistas, o ambiente de execução do SE foi compartilhado. Avaliação (GQM) Tanto para as organizações quanto para os especialistas, um documento com um questionário foi enviado. Figura 29. Fluxo de atividades Fonte: Próprio autor A partir da metodologia apresentada, sem um tratamento estatístico amplo, podemos considerar que o trabalho pode contribuir para o processo de melhoria na organização, uma vez que é permitido que as organizações e empresas implementadoras, realizem a execução do sistema especialista de forma semi automatizada, trazendo maior agilidade, flexibilidade ao processo e reduzindo custos. Tendo em vista, que a organização poderá realizar um autodiagnostico do seu processo a qualquer momento, sem a necessidade da presença de uma empresa implementadora. 5.2 MODELO DE AVALIAÇÃO A avaliação do estudo proposto foi realizada através da abordagem GQM, que representa uma abordagem sistemática para a adaptação e integração de objetivos para os modelos dos processos de software, produtos e perspectivas de interesse de qualidade, com base nas necessidades específicas do projeto e da organização. A abordagem é composta por uma estrutura hierárquica que inicia com a definição, em um nível conceitual, dos objetivos a serem medidos (goals), que são então refinados em várias questões, a fim de decompor o problema em seus componentes principais. Estas perguntas constituem o nível operacional do modelo, que é finalmente refinado em métricas objetivas ou subjetivas (por exemplo, a quantidade de estudos selecionados, e a percepção do pesquisador a respeito

120 120 da produtividade obtida, respectivamente). Uma única métrica pode ser utilizada para responder diferentes perguntas sob o mesmo objetivo (BASILI; CALDEIRA; ROMBACH, 1994). De acordo com a abordagem GQM, foi realizada uma avaliação descrita como pré-execução, específica do questionário que será utilizado para mapear o perfil de desenvolvimento da organização, bem como as questões descritas nas árvores de decisão. Esta avaliação foi realizada por profissionais da área de melhoria de processos. A avaliação descrita como pós-execução, será em relação à condução da abordagem nas organizações, avaliando os resultados esperados do processo de autodiagnostico do ciclo de vida de desenvolvimento, através de diálogos automatizados. Esta avaliação foi realizada pelos responsáveis pelo processo de desenvolvimento das organizações. Conforme descrito na problematização (Seção 1.1), este trabalho avaliou, através da abordagem GQM, um sistema especialista que possui uma estrutura de diálogos automatizados para apoiar o mapeamento do ciclo de vida e processo de desenvolvimento de organizações intensivas em software baseado em árvores de decisão, que tem por objetivo contribuir com a redução do custo final de implementações na área de MPS, na adequação e na aderência aos resultados esperados com o uso do sistema especialista Avaliação pelo Método GQM O principal objetivo deste estudo quantitativo é efetuar uma avaliação os resultados produzidos pelo sistema especialista em organizações intensivas em software e por especialistas em MPS. Portanto, visando um melhor direcionamento desta pesquisa e as hipóteses relacionadas a esta questão, os objetivos (goals) da abordagem GQM foram elaborados para avaliação quantitativa. Seguindo a definição proposta pela abordagem GQM, nos Quadros 11 e 12 são detalhadas as questões relacionadas a adequação e aderência para a avaliação dos resultados emitidos pelo sistema especialista, relacionadas a cada objetivo proposto. Adequação

121 121 Quadro 11. Definição das métricas para o objetivo G1 segundo a abordagem GQM Objetivo 1) Propósito: Adequar Questão: Base de Conhecimento Objetivo: Abranger grande parte do conteúdo da melhoria de processo de software Ponto de vista: Analisado pelo ponto de vista dos especialistas Questão 1.1: A quantidade de perguntas é adequada à quantidade estimada de fases de um ciclo de vida de desenvolvimento de software? Questão 1.2: O conteúdo do sistema especialista é adequado às situações praticadas nas organizações? Questão 1.3: As perguntas descritas no sistema especialista estão adequadas a realidade de cada fase do ciclo de desenvolvimento de software? Questão 1.4: As perguntas descritas no sistema especialista estão adequadas com a realidade de um especialista, ao entrevistar uma organização? Questão 1.5: A execução da avaliação do ciclo de vida de desenvolvimento de software através de diálogos automatizados (SE) está de acordo com a primeira etapa de avaliação de um processo de melhoria de desenvolvimento de software? Questão 1.6: O resultado do diálogo automatizado (SE) é tão confiável quanto o resultado de um diálogo verbal feito por um especialista na área de melhoria de processo de software? Aderência Quadro 12. Definição das métricas para o objetivo G2 segundo a abordagem GQM Objetivo 2) Propósito: Aderir Questão: Abordagem proposta Objetivo: Confrontar os resultados da abordagem com a realizada das organizações Ponto de vista: Gerentes e Diretores das organizações entrevistadas

122 122 Questão 2.1: Os resultados obtidos com a execução do sistema especialista estão aderentes com a realidade da organização? Questão 2.2: O ciclo de vida identificado pelo sistema especialista corresponde ao ciclo de vida de desenvolvimento da organização? Questão 2.3: As fases do ciclo de vida da organização estão aderentes ao resultado do sistema especialista? Questão 2.4: Os resultados são aderentes ao ciclo de vida da organização? Questão 2.5: As perguntas realizadas no sistema especialista permitem entender a estrutura da abordagem para a identificação do processo de desenvolvimento da organização? Questão 2.6: O sistema especialista e seus resultados contribuem positivamente para a área de MPS da organização? Hipótese: a avaliação foi planejada para testar a seguinte hipótese (nula e alternativa) a respeito dos indicadores de adequação e aderência: H1: O ciclo de vida e processo de desenvolvimento de software de uma organização pode ser mapeado através de uma abordagem baseada em diálogos automatizados realizados com base em árvores de decisão, trazendo resultados confiáveis aos resultados obtidos por um especialista da área de melhoria de processo. Por se tratar de avaliações subjetivas, os procedimentos para obtenção de métricas subjetivas fundamentam-se na realização de entrevistas com avaliadores que possuam experiência com melhoria de processos e entrevistas com as organizações desenvolvedoras de software. Cada uma das questões possui um conjunto de resultados possíveis classificados por importância conforme o Quadro 13. A distribuição de métricas para avaliação subjetiva estão ilustradas no Quadro 14. Quadro 13. Métricas para avaliação da abordagem. Métrica M1 Descrição Quantidade de pessoas que responderam Concordo totalmente

123 123 M2 M3 M4 M5 Quantidade de pessoas que responderam Concordo parcialmente Quantidade de pessoas que responderam Discordo parcialmente Quantidade de pessoas que responderam Discordo totalmente Quantidade de pessoas que responderam Indiferente Cada uma das métricas subjetivas é obtida através da soma das respostas obtidas para a questão específica. Para possibilitar avaliações subjetivas pelo questionário a ser realizado, adota-se um conjunto de atributos classificados por importância, conforme apresentado no Quadro 14. Para computar o valor atribuído a cada métrica em cada questão específica, um somatório de respostas é realizado para cada atributo, obtidas nos questionários aplicados na comunidade. Quadro 14. Atributos de avaliação do framework Atributos Classificação Subjetiva Correspondência Numérica A1 Concordo Totalmente > 75% A2 Concordo Parcialmente 51~75% A3 Discordo Parcialmente 26~50% A4 Discordo Totalmente < 26% Indiferente - Sem opinião definida* - * não contribui para a avaliação, atuando como uma possibilidade ao respondente em isentar-se daquela questão. Assim para que cada uma das questões tenha um valor computado, realiza-se a interpretação da contribuição da abordagem proposta através de configurações descritas no Quadro 15 para os fatores de adequação da abordagem, alinhados ao objetivo G1 e no Quadro 16 para a aderência aos resultados da abordagem, alinhados ao objetivo G2. Cada uma das métricas descritas anteriormente conduz a um atributo de comparação que subtraído a média dos atributos, permite a interpretação daquela questão específica dentro do contexto avaliado. Quadro 15. Interpretação da adequação da abordagem* Expressão Interpretação A1 > MÉDIA (A2, A3, A4) A abordagem proposta está totalmente adequada a área de melhoria de processos de software. A2 > MÉDIA (A1, A3, A4) A abordagem proposta está parcialmente de modo positivo adequada a área de melhoria de processos de software. A3 > MÉDIA (A1, A2, A4) A abordagem proposta está parcialmente de modo negativo adequada a área de melhoria de processos de software. A4 > MÉDIA (A1, A2, A3) A abordagem proposta impede ou restringe a adequação a área de melhoria de processos de software. * lido da seguinte forma: Se Expressão então Interpretação.

124 124 Quadro 16. Interpretação da aderência da abordagem* Expressão Interpretação A1 > MÉDIA (A2, A3, A4) A abordagem proposta está totalmente aderente a realidade da organização. A2 > MÉDIA (A1, A3, A4) A abordagem proposta está parcialmente de modo positivo aderente a realidade da organização. A3 > MÉDIA (A1, A2, A4) A abordagem proposta está parcialmente de modo negativo aderente a realidade da organização. A4 > MÉDIA (A1, A2, A3) A abordagem proposta impede ou restringe a aderência a realidade da organização. * lido da seguinte forma: Se Expressão então Interpretação. 5.3 RESULTADOS Através dos questionários de avaliação apresentados nos Apêndices C e D, os participantes relataram suas impressões a respeito das contribuições obtidas em termos de adequação e aderência com a adoção do sistema especialista com forma de diálogo automatizado para mapear o ciclo de vida e processo de desenvolvimento de software de organizações intensivas em software Perfil dos participantes O Quadro 17, informa o perfil das organizações participantes no processo de avaliação do sistema especialista. Cada organização recebeu um código, denominado O1, O2 até O6, o que mantém a confidencialidade das organizações. Quadro 17. Perfil das organizações Porte Principal atividade Possui processo formal? Tipo de produto de software O1 Médio Desenvolver software Ainda não possui um processo Software voltado para padrão com customizações formal, pois o mesmo está em web e desktop para clientes fase de implantação O2 Médio Desenvolver software Possui processo definido pela Desenvolve software padrão com customizações empresa com base nos voltado para desktop para clientes conceitos do CMMI. O3 Médio Software por encomenda (fábrica) Não, mas pretende implantar em Software voltado para web O4 Médio Desenvolver software padrão com customizações para clientes O5 Médio Software por encomenda (fábrica) Não - Prestação de serviços - Software voltado para web Sim. Nível G MPS.BR Desenvolve software voltado para desktop

125 125 O6 Médio Software por encomenda (fábrica) Sim. A base é cascata (desenvolvimento de software) e PMBOK (gerenciamento de projetos) - Software voltado para web - Prestação de serviços O Quadro 18, apresenta o perfil dos entrevistados nas organizações que participaram da avaliação do sistema especialista. A organização O5 teve a presença de 2 profissionais participando da entrevista e execução ao sistema especialista. Quadro 18. Perfil dos entrevistados nas organizações Cargo Tempo na organização Conhecimento em MPS Conhecimento de MPS.BR Conhecimento de CMMI O1 Coordenador de 1 ano e 10 meses Sim Não Sim desenvolvimento O2 Gerente de 5 anos Sim Não Sim projeto O3 Gerente de 7 anos Sim Sim Sim operações O4 Scrum Master 6 meses Sim Não Sim O5 Gerente de 10 anos Sim Sim Sim desenvolvimento O5 Coordenador de 6 anos Sim Sim Sim desenvolvimento O6 Gerente de 1 ano e 8 meses Sim Sim Sim projeto O Quadro 19 apresenta o perfil dos especialistas em melhoria de processo de software, que participaram da avaliação do sistema especialista. Quadro 19. Perfil dos especialistas Tempo de Empresas avaliadas Qtdade. de Empresas Qtdade. de experiência em (Modelo MPS.BR) implantações avaliadas implantações MPS (Modelo MPS.BR) (Modelo CMMI) (Modelo CMMI) E1 20 anos E2 5 anos E3 8 anos E4 13 anos E5 11 anos E6 2 anos 0 Acompanhou implantações E7 10 anos

126 16,66% 16,66% 16,66% 16,66% 50% 50% 50% 50% 50% 50% 50% 50% 66,66% 83,34% 83,33% Resultados das métricas subjetivas Após a execução das entrevistas com os recursos da organização, o sistema especialista gerava um relatório com pontos fortes, pontos fracos e possíveis melhorias do processo da organização. Em seguida, através de um documento de avaliação o SE era avaliado conforme descrito na Seção Para avaliar cada objetivo, foi definido um conjunto de questões (Quadros 11 e 12). Para cada questão, as respostas possíveis são: CT Concordo Totalmente; CP Concordo Parcialmente; IN Indiferente; DP Discordo Parcialmente e DT Discordo Totalmente. A Figura 30, apresenta os resultados da avaliação das organizações desenvolvedoras de software, em relação a cada atributo. Avaliação das organizações 100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0% Organização 1 Organização 2 Organização 3 Organização 4 Organização 5A Organização 5B Organização 6 CT CP DP DT I Figura 30. Avaliação GQM Organizações Fonte: Próprio autor Na avaliação dos resultados do sistema especialista, sob o ponto de vista das organizações, pode-se verificar uma forte tendência de respostas positivas (concordo totalmente e concordo parcialmente). Pelo resultado parcial, há uma indicação inicial que o objetivo de aderência dos resultados do diagnóstico realizado pelo sistema especialista está sendo alcançado. As organizações se identificaram com as argumentações geradas e acreditam que estas informações podem ajuda-las a

127 14,28% 14,28% 14,28% 14,28% 28,57% 28,57% 28,57% 28,57% 42,86% 42,86% 42,86% 57,14% 57,15% 57,14% 71,43% 71,43% 85,72% 127 encontrar possíveis melhorias no processo. Vale ressaltar que as organizações não responderam com discordo totalmente. Os especialistas também avaliaram os resultados do sistema especialista, conforme descrito na Seção Esses especialistas, executaram o SE simulando uma organização de desenvolvimento de software. Eles puderam trabalhar no SE por diversas vezes, podendo avaliar de forma mais ampla os resultados que o SE emite. A Figura 31, apresenta os resultados da avaliação dos especialistas em melhoria de processo de software em relação a cada atributo. Avaliação dos especialistas 100,00% 90,00% 80,00% 70,00% 60,00% 50,00% 40,00% 30,00% 20,00% 10,00% 0,00% Especialista 1 Especialista 2 Especialista 3 Especialista 4 Especialista 5 Especialista 6 Especialista 7 CT CP DP DT I Figura 31. Avalição GQM Especialistas Fonte: Próprio autor Na avaliação realizada com os especialistas também é possível verificar a tendência de respostas positivas em relação à adequação dos resultados obtidos com o sistema especialista. As respostas estão mais centradas em uma concordância parcial, demonstrando que o sistema especialista precisa ainda ser evoluído. Um dos pontos identificados de melhoria está na fase de gerenciamento/acompanhamento de projetos, na qual foram adicionadas perguntas e outras sofreram

128 4,08% 14,29% 28,57% 53,06% 128 um melhor detalhamento. Outra melhoria identificada está na adição de mais pontos fracos e fortes. Os especialistas apontaram para algumas conclusões que podem ser incluídas nos resultados do SE. Com relação a obtenção da métrica de adequação dos resultados do sistema especialista, os especialistas demonstraram uma tendência em considerar os atributos A1 - Concordo totalmente e A2 - Concordo parcialmente, em aproximadamente 28,57% e 53,06% das questões, respectivamente, conforme detalhado na Figura 31. Os atributos A3 - Discordo parcialmente e A4 - Discordo totalmente obtiveram respectivamente 14,29% e 4,08% de respostas. Nenhuma resposta foi obtida para o atributo A5 - Indiferente, conforme ilustra o gráfico. Avaliação dos especialistas - por atributo 100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0% Concordo totalmente Concordo parcialmente Discordo parcialmente Discordo totalmente Indiferente Figura 32. Distribuição das respostas de acordo com a classificação (Especialistas) Fonte: Próprio autor Com relação a obtenção da métrica de aderência aos resultados do sistema especialista, as organizações demonstraram uma tendência em considerar os atributos A1 - Concordo totalmente e A2 - Concordo parcialmente, em aproximadamente 54,76% e 35,71% das questões, respectivamente, conforme detalhado na Figura 32. Os atributos A3 - Discordo parcialmente e A5 - Indiferente obtiveram respectivamente 7,14% e 2,38% de respostas. Nenhuma resposta foi obtida para o atributo A4 - Discordo totalmente, conforme ilustra o gráfico.

129 7,14% 2,38% 35,71% 54,76% 129 Avaliação das organizações - por atributo 100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0% Concordo totalmente Concordo parcialmente Discordo parcialmente Discordo totalmente Indiferente Figura 33. Distribuição das respostas de acordo com a classificação (Organizações) Fonte: Próprio autor O Quadro 20 apresenta, para cada questão, o atributo (conforme orientação do Quadro 14) relacionado à opção de resposta mais indicada pelos participantes. Juntamente com o atributo, nesta coluna é apresentada a informação do percentual que esta opção de resposta mais indicada obteve em relação ao total de participantes. Com base nisso as médias e interpretações descritas nos Quadros 14, 15 e 16 foram realizadas, resultando na coluna MÉDIA. O percentual apresentado na coluna média é obtido da seguinte maneira: primeiramente verifica-se qual atributo a opção de resposta mais indicada representa (conforme parâmetros do Quadro 13). Com base nisso e de acordo com o objetivo que está sendo avaliado, aplica-se uma das interpretações indicadas (Quadro 15 e 16). Por exemplo, para o objetivo da adequação na questão 1.1, obteve-se 1 resposta indicando Concordo totalmente, 5 respostas indicando Concordo parcialmente e 1 resposta indicando Discordo parcialmente. Observando o Quadro 14, a opção mais indicada (71,43%) encontra-se dento do conjunto de valores do atributo A2 (conforme Quadro 14). Dessa forma, a média foi realizada entre os atributos A1, A3 e A4 (14,29% + 14,29% + 0%)/3) tendo em vista que A2 > MEDIA (A1, A2 e A4).

130 130 Quadro 20. Interpretação da avaliação subjetiva da abordagem. Questão Atributo Valor Média Questão 1.1 A2 71,43% 9,52% Questão 1.2 A2 71,43% 9,52% Questão 1.3 A2 71,43% 9,52% Questão 1.4 A2 57,14% 14,29% Questão 1.5 A3 42,86% 28,57% Questão 1.6 A3 42,86% 19,05% Questão 1.7 A2 71,43% 23,81% Adequação 61,23% 17,46% Questão 2.1 A2 57,14% 14,28% Questão 2.2 A2 57,14% 19,04% Questão 2.3 A2 71,43% 23,81% Questão 2.4 A2 57,14% 14,28% Questão 2.5 A2 71,43% 28,57% Questão 2.6 A2 57,14% 23,81% Aderência 61,90% 20,63% Avaliação Uma análise adicional realizada a partir das respostas fornecidas pelos participantes consiste em organizar os principais comentários e críticas realizadas e efetuar possíveis correções no sistema especialista. O Quadro 21 expõe os comentários realizados por dois participantes, relacionando o questionário aplicado com o SE, para contribuição na melhoria de processo de desenvolvimento de software. São apresentadas as avaliações ao sistema especialista, por um especialista e por um entrevistado de uma das organizações participantes. Os mesmos foram selecionados levando em consideração que as suas justificativas foram as que melhor justificaram suas respostas contribuindo assim para a melhoria do SE. De maneira geral, os comentários acerca do sistema especialista direcionam a uma melhoria contínua em relação ao conteúdo apresentado. As sugestões propostas pelo especialista 4 se apresentaram realmente interessantes e instigaram numa melhoria em incrementar o sistema especialista com mais perguntas e melhorar o direcionamento das respostas. No caso do especialista 4, nem todas as questões foram justificadas pelo entrevistado. As justificativas apresentadas pelo entrevistado da organização 5, demonstram que o sistema especialista atinge o objetivo de mapear o processo de uma organização de desenvolvimento de software.

131 131 Quadro 21. Avaliação dos entrevistados Especialista 4 Questão 1.2 Justificativa Questão 1.4 Justificativa Questão 1.6 Justificativa Possui 13 anos de experiência em melhoria de processo de software, 14 empresas avaliadas no modelo MPS.BR, 14 implantações do modelo MPS.BR e 3 implantações no modelo CMMI. O conteúdo do sistema especialista é adequado às situações praticadas nas organizações? Resposta: Concordo parcialmente Algumas atividades são executadas pelo mesmo papel, principalmente em empresas pequenas. Por exemplo, mesmo havendo uma fase e atividades de testes na empresa que utilizei como exemplo, ela é realizada pelo analista de sistemas, não existindo figura ou papel de testador ou analista de testes. O analista de sistemas também executa o papel de documentador, por exemplo, o que não pôde ser explicado no sistema. As perguntas descritas no sistema especialista estão adequadas com a realidade de um especialista, ao entrevistar uma organização? Resposta: Concordo parcialmente Nas fases iniciais de planejamento e levantamento de requisitos até podemos dizer que sim. Somente acho que as perguntas que falam a respeito do acompanhamento de projetos são muito superficiais, assim como alguns detalhes do planejamento que são explorados. Não percebi perguntas de como tratar problemas e desvios, assim como alterações de requisitos durante o desenvolvimento. Não percebi pergunta específica para a rastreabilidade de requisitos, por exemplo. O resultado do diálogo automatizado (SE) é tão confiável quanto o resultado de um diálogo verbal feito por um especialista na área de melhoria de processo de software? Resposta: Discordo parcialmente Não é tão confiável pois algumas questões precisariam ser mais detalhadas. No caso da empresa exemplo o resultado apresenta: Ele estima o projeto em unidade de tempo, não utiliza pontos de função, utiliza um cronograma para o escopo do projeto e faz revisão do mesmo. Não há como explicar qual o método de estimativas utilizado o que normalmente seria questionado, que neste exemplo seria com base na complexidade de cada requisito e valores específicos para as etapas de planejamento. Organização 5 O entrevistado, responsável pelo setor de desenvolvimento possui 6 anos de trabalho na organização, é coordenador de desenvolvimento e tem conhecimentos em MPS, nos modelos MPS.BR e CMMI Questão 2.1 Os resultados obtidos com a execução do sistema especialista estão aderentes com a realidade da organização?

132 132 Resposta: Concordo parcialmente Justificativa Questão 2.2 Justificativa Questão 2.3 Justificativa Questão 2.4 Justificativa Questão 2.5 Justificativa Questão 2.6 Justificativa Em parte são aderentes, porém como temos uma metodologia de gestão dos projetos diferenciada, alguns itens não se enquadram adequadamente. O ciclo de vida identificado pelo sistema especialista corresponde ao ciclo de vida de desenvolvimento da organização? Resposta: Concordo totalmente Sim! Possuem nomenclaturas um pouco diferentes, mais são abordados todos os ciclos da organização. As fases do ciclo de vida da organização estão aderentes ao resultado do sistema especialista? Resposta: Concordo parcialmente Alguns pontos do projeto, possuem um tratamento distinto do sugerido pelo sistema especialista, principalmente pelo fato de possuirmos uma metodologia própria para gestão do projeto. Os resultados são aderentes ao ciclo de vida da organização? Resposta: Concordo parcialmente São parcialmente, pois alguns pontos possuem tratamentos distintos em nossa organização. As perguntas realizadas no sistema especialista permitem entender a estrutura da abordagem para a identificação do processo de desenvolvimento da organização? Resposta: Concordo totalmente Avaliando as perguntas e as respostas, é possível compreender o processo da organização. O sistema especialista e seus resultados contribuem positivamente para a área de MPS da organização? Resposta: Concordo totalmente Sim! Como os questionamentos são relacionados a gestão dos projetos, contribuem com as boas práticas de gestão, auxiliando no cumprimento dos requisitos da MPS Síntese dos resultados Tendo finalizados os procedimentos de avaliação para coleta das métricas subjetivas, é possível sintetizar o resultado obtido no Quadro 22. Nela são apresentados os objetivos da avaliação

133 133 (G1 adequação e G2 aderência), suas questões relacionadas e as métricas que as compõe. São demonstradas também as medições obtidas através do questionário (na forma de uma expressão matemática de comparação) e nos procedimentos de avaliação (na forma de um coeficiente percentual) que representa o atendimento de um determinado atributo de resposta que aponta, por sua vez, a síntese obtida para aquela questão e objetivo. Quadro 22. Avaliação dos dados Objetivo Questão Métrica(s) Medição Resposta Síntese G1 1.1 M1, M2, M3, M4 71,43% > 9,52% A2 A abordagem proposta está parcialmente de modo positivo adequada a área de melhoria de processos de software. G1 1.2 M1, M2, M3, M4 71,43% > 9,52% A2 A abordagem proposta está parcialmente de modo positivo adequada a área de melhoria de processos de software. G1 1.3 M1, M2, M3, M4 71,43% > 9,52% A2 A abordagem proposta está parcialmente de modo positivo adequada a área de melhoria de processos de software. G1 1.4 M1, M2, M3, M4 57,14% > 14,29% A2 A abordagem proposta está parcialmente de modo positivo adequada a área de melhoria de processos de software. G1 1.5 M1, M2, M3, M4 42,86% > 28,57% A3 A abordagem proposta está parcialmente de modo negativo adequada a área de melhoria de processos de software. G1 1.6 M1, M2, M3, M4 42,86% > 19,05% A3 A abordagem proposta está parcialmente de modo negativo adequada a área de melhoria de processos de software. G1 1.7 M1, M2, M3, M4 71,43% > 23,81% A2 A abordagem proposta está parcialmente de modo positivo adequada a área de melhoria de processos de software. G2 2.1 M1, M2, M3, M4 57,14% > 14,28% A2 A abordagem proposta está parcialmente de modo positivo aderente a realidade da organização.

134 134 G2 2.2 M1, M2, M3, M4 57,14% > 19,04% A2 A abordagem proposta está parcialmente de modo positivo aderente a realidade da organização. G2 2.3 M1, M2, M3, M4 71,43% > 23,81% A2 A abordagem proposta está parcialmente de modo positivo aderente a realidade da organização. G2 2.4 M1, M2, M3, M4 57,14% > 14,28% A2 A abordagem proposta está parcialmente de modo positivo aderente a realidade da organização. G2 2.5 M1, M2, M3, M4 71,43% > 28,57% A2 A abordagem proposta está parcialmente de modo positivo aderente a realidade da organização. G2 2.6 M1, M2, M3, M4 57,14% > 23,81% A2 A abordagem proposta está parcialmente de modo positivo aderente a realidade da organização. Considerando a síntese exposta, é possível listar os resultados obtidos com relação a cada uma das questões de avaliação, realizar uma interpretação da medição obtida, do procedimento de avaliação e lacunas evidenciadas durante o processo: Questão 1.1: O sistema especialista proposto pode contribuir com a melhoria de processo pois possui uma quantidade de perguntas adequadas à quantidade estimada de fases de um ciclo de vida de desenvolvimento de software, visto que 71,43% dos especialistas concordaram parcialmente com esta afirmação. Apesar disso, uma das justificativas dentre os especialistas, ressalta a necessidade de agrupar as perguntas para que o questionário do SE se torne menor. Questão 1.2: O sistema especialista proposto pode contribuir com a melhoria de processo pois está adequado às situações praticadas nas organizações, visto que 71,43% dos especialistas concordaram parcialmente com esta afirmação. Apesar disso, uma das justificativas dentre os especialistas, ressalta que o SE não trata a execução de várias funções para o mesmo papel, na qual, como solução foi inserir mais opções de cargos para perguntas que tratam as diversas funções dentro de um setor de desenvolvimento.

135 135 Outra solução foi inserir pontos fracos para que a organização avaliada possa tratar a questão de possuir um recurso executando diversas funções. Questão 1.3: O sistema especialista proposto pode contribuir com a melhoria de processo pois está adequado com perguntas que descrevem a realidade de cada fase do ciclo de vida de desenvolvimento do software, visto que 71,43% dos especialistas concordaram parcialmente com esta afirmação. Apesar disso, uma das justificativas dentre os especialistas, ressalta que as questões do SE não abordam de forma completa o processo de software e em outros casos as questões ficaram descontextualizadas. Como solução foram inseridas mais questões e em outros casos, as mesmas foram alteradas, para que pudessem se encaixar melhor no contexto da fase do ciclo de vida que se encontram. Questão 1.4: O sistema especialista proposto pode contribuir com a melhoria de processo pois está adequado com perguntas que descrevem a realidade de um especialista, ao entrevistar uma organização, visto que 57,14% dos especialistas concordaram parcialmente com esta afirmação. Uma das justificativas dentre os especialistas sugere incluir mais perguntas em relação ao acompanhamento de projetos e rastreabilidade de requisitos. Em outra justificativa, um dos especialistas relata que os questionamentos não são apresentados de uma só vez, mas sim, tratados de forma mais genérica, num primeiro momento, e num segundo momento os assuntos se especializam e se aprofundam conforme a entrevista vai sendo conduzida. Questão 1.5: O sistema especialista proposto pode contribuir com a melhoria de processo pois está adequado com perguntas que estão de acordo com a primeira etapa de avaliação de um processo de melhoria, visto que 42,86% dos especialistas concordaram parcialmente de modo negativo com esta afirmação. Uma das justificativas, dentre os especialistas, concorda que num primeiro momento, esta avaliação, feita pelo SE, é executada, mas falta a cobertura mais ampla de algumas fases. Questão 1.6: O sistema especialista proposto pode contribuir com a melhoria de processo pois está adequado com perguntas que geram um resultado tão confiável quanto o resultado de um diálogo verbal feito por um especialista, visto que 42,86% dos

136 136 especialistas concordaram parcialmente de modo negativo com esta afirmação. Uma das justificativas, dentre os especialistas, é em relação a falta de interação entre o entrevistado e o entrevistador, caracterizando um ponto frágil, segundo o especialista. Outra justificativa seria em relação a necessidade de um detalhamento maior das questões. Questão 1.7: O sistema especialista proposto pode contribuir com a melhoria de processo pois está adequado com a possibilidade de levantar pontos fortes, pontos fracos e oportunidades de melhorias com os resultados gerados, visto que 71,43% dos especialistas concordaram parcialmente com esta afirmação. Uma das justificativas, dentre os especialistas, é que ainda falta uma melhor cobertura das fases do ciclo de vida de desenvolvimento do software. Questão 2.1: O sistema especialista proposto pode contribuir com a melhoria de processo pois está aderente com a realidade da organização em relação aos resultados gerados, visto que 57,14% dos entrevistados concordaram parcialmente com esta afirmação. Uma das justificativas entre os entrevistados, é em relação a dificuldade em encaixar os termos e as fases ao processo de desenvolvimento da organização. Outra justificativa, é que em relação a metodologia de gestão de projetos da organização, ser diferenciada, na qual algumas questões não se enquadraram adequadamente. Questão 2.2: O sistema especialista proposto pode contribuir com a melhoria de processo pois está aderente com a realidade da organização identificando o seu ciclo de vida de desenvolvimento, visto que 57,14% dos entrevistados concordaram parcialmente com esta afirmação. Uma das justificativas entre os entrevistados, é em relação a nomenclatura que não ficou de acordo com a adotada pela organização. Em outra justificativa o entrevistado relata a falta de perguntas abordando o tratamento de erros antes da entrega oficial para o mercado. Como resposta a esta última justificativa é possível incrementar a fase de testes, incluindo questões de tratamento de erros antes da entrega oficial. Questão 2.3: O sistema especialista proposto pode contribuir com a melhoria de processo pois está aderente às fases do ciclo de vida da organização com o resultado gerado pelo SE, visto que 71,43% dos entrevistados concordaram parcialmente com

137 137 esta afirmação. Uma das justificativas entre os entrevistados, é que em algumas atividades do projeto, há um tratamento distinto do sugerido pelo sistema especialista. Questão 2.4: O sistema especialista proposto pode contribuir com a melhoria de processo pois está aderente com o ciclo de vida da organização em relação ao resultado gerado pelo SE, visto que 57,14% dos entrevistados concordaram parcialmente com esta afirmação. Uma das justificativas entre os entrevistados, é que a organização possui tratamentos distintos em algumas fases do ciclo de vida. Questão 2.5: O sistema especialista proposto pode contribuir com a melhoria de processo pois está aderente com perguntas que permitem entender a estrutura do processo da organização, visto que 71,43% dos entrevistados concordaram parcialmente com esta afirmação. Uma das justificativas entre os entrevistados, é que o sistema especialista tratar de forma mais ampla algumas fases com perguntas mais específicas. Questão 2.6: O sistema especialista proposto pode contribuir com a melhoria de processo pois está aderente com os resultados gerados, visto que 57,14% dos entrevistados concordaram parcialmente com esta afirmação. Uma das justificativas entre os entrevistados, é que o resultado trouxe uma situação que para ele não se encaixa com a organização. Em uma das perguntas foi respondido que não fazem análise de risco do projeto. Entretanto, a conclusão do sistema especialista foi que é preciso fazer análise de risco criando protótipos de tela, validando com o cliente e fazendo refinamentos. Segundo o entrevistado, esse processo é executado pelo designer de iteração e é fundamental para definir os requisitos. Não entende-se isso como uma análise de riscos. A solução foi melhorar as perguntas relacionadas aos riscos do projeto. De um modo geral, a interpretação dos resultados da avaliação responde à questão de pesquisa apontada na problematização deste trabalho (Seção 1.1.1) ao afirmar que uma abordagem baseada em diálogos automatizados, no contexto de um ambiente de diagnóstico semi automatizado, permite modelagem inicial do ciclo de vida adotado em organizações intensivas em software, possibilitando o mapeamento do processo de desenvolvimento de software, através de um sistema especialista.

138 Considerações Levando em consideração a participação de 6 organizações e 7 especialistas, há uma tendência em considerar o sistema especialista, um recurso positivo, em relação aos seus resultados, pode-se considerar também, que esta pesquisa contribui efetivamente para a realização de um autodiagnostico com resultados próximos ao de um especialista em MPS. Também há uma tendência positiva na utilização do sistema especialista como um meio de obtenção de melhoria no processo de desenvolvimento de software das organizações. Embora o número de especialistas MPS envolvidos na avaliação do SE seja pequeno (6 profissionais), a qualidade da avaliação pode-se considerar positiva, visto que no perfil dos mesmos, há uma média de aproximadamente 10 anos em experiência com melhoria de processos e uma média de aproximadamente 19 implantações e 10 avaliações, aos modelos MPS.BR e CMMI, uma média considerável para a avaliação exigida nesta pesquisa. Não pode-se descartar também, os riscos que uma avaliação pode ter com 14 profissionais, entre organizações e especialistas MPS, participando. Riscos esses que podem acarretar na inviabilidade de se ter um sistema especialista mapeando o desenvolvimento de organizações de grande porte. Inviabilidade essa, que caracteriza uma dispersão dos resultados que pode ser alvo de aprimoramentos futuros. Para esses riscos, o trabalho buscou com as avaliações dos especialistas e organizações, corrigir alguns pontos dentro do sistema especialista que pudessem gerar um mapeamento de processo incompleto, do ponto de vista de uma possível discordância de resultados, caso o sistema seja executado em grandes organizações. Após as avaliações, buscou-se também, executar o sistema novamente, com 2 especialistas MPS mais experientes e que pudessem apontar possíveis causas de insucesso, nos resultados emitidos pelo SE. Apesar dos riscos apresentados, pode-se considerar que o fato de haver um sistema especialista, com tendências positivas aos resultados, já demonstra uma contribuição na melhoria no processo de desenvolvimento de organizações intensivas em software. Em relação as avaliações GQM, as mesmas precisam de refinamento e adaptação constante, portanto as métricas definidas devem auxiliar não só na avaliação do objeto de estudo, mas também na confiabilidade do modelo utilizado para avaliação (BASILI; CALDIERA; ROMBACH, 1994). Deste

139 139 modo, pretende-se ainda a utilização dos resultados obtidos como modelo para avaliações futuras realizadas sobre o sistema especialista, a fim de obter dados mais abrangentes sobre as contribuições possíveis da ferramenta a processos de melhoria de software. Os resultados obtidos com a avaliação da abordagem, alinhados aos objetivos deste trabalho (Seção 1.2) serve ainda, para apontar evidências das contribuições obtidas, verificar as hipóteses supostas, além de identificar lacunas e oportunidades de pesquisa ou manutenção da abordagem em situações futuras.

140 140 6 CONCLUSÃO Este trabalho propôs um estudo de continuação da proposta desenvolvida por Moreira (2012) na qual foi desenvolvida uma abordagem para diagnóstico semi automatizado. Entretanto a pesquisa de Moreira (2012) ficou limitada aos processos de análise de requisitos e gerência de projetos, do nível G do MPS.BR. Sendo assim, foi realizado um estudo de planejamento, elaboração e avaliação de uma abordagem automatizada, ou seja, um sistema especialista, que apoie organizações desenvolvedoras de software no diagnóstico inicial do seu processo de desenvolvimento, mapeando seu ciclo de vida. Para tanto, foram necessários estudos específicos sobre a área, envolvendo pesquisas em melhoria de processo, avaliação de processos, diagnósticos, levantamento de ciclo de vida e ferramentas que dão suporte a condução de um processo de melhoria de software. O presente estudo inclui uma análise mais abrangente do processo de desenvolvimento de organizações intensivas em software utilizando referências em modelos de capacidade e maturidade (MPS.BR e CMMI) na norma ISO/IEC e em processos conhecidos de desenvolvimento de software (XP, Scrum e RUP). A fim de alcançar o objetivo geral, foi desenvolvida uma abordagem de autodiagnostico para apoiar o mapeamento do ciclo de vida e processo de desenvolvimento de software. Para tal, foram analisadas metodologias de avaliação de ciclos de vida de desenvolvimento e ferramentas de autodiagnostico, por meio de mapeamento sistemático, árvores de decisão, regras de produção, sistema especialista, entrevistas com especialistas e organizações de desenvolvimento de software. Ainda dentro dos objetivos deste trabalho é possível analisar cada objetivo específico conforme descrito abaixo: 1) Mapear os diferentes processos de desenvolvimento de software, adotado por organizações, a partir das características das mesmas. Este objetivo foi alcançado baseado na construção das árvores de decisão, que através de perguntas e respostas conseguem, descrever o processo de desenvolvimento de uma organização;

141 141 2) Desenvolver um sistema especialista que possa trazer como resultados pontos fracos, pontos fortes e oportunidades de melhoria no processo de desenvolvimento de software adotado por uma organização. Este objetivo foi alcançado com o desenvolvimento de um sistema especialista que apresenta resultados relevantes ao processo de desenvolvimento, facilitando para os responsáveis da organização, observar possíveis pontos de melhoria; 3) Desenvolver uma base de conhecimento que apoie o sistema especialista. A primeira etapa do desenvolvimento da mesma foi o mapeamento sistemático e com base nele, árvores de decisão foram construídas. Também foram realizadas entrevistas com gerentes de projetos e especialistas em MPS que contribuíram na modelagem das árvores. Por fim, foi possível criar regras de decisão que serviram de base para o desenvolvimento do sistema especialista; 4) Integrar as árvores de decisão deste trabalho com o conhecimento das árvores de decisão desenvolvidas em Moreira (2012). Perguntas relacionadas à análise de requisitos e gerência de projetos presentes nas árvores de decisão do trabalho de Moreira (2012) foram integradas nas árvores de decisão construídas para o presente estudo; e 5) Avaliar o sistema especialista com especialistas e a partir de sua aplicação em empresas reais de desenvolvimento de software. Este objetivo foi obtido na forma de avaliações realizadas tanto por organizações da região de Joinville e Blumenau, como por especialistas de diversas partes do país. Os resultados descritos na Seção 5.3 evidenciam que a adoção de uma ferramenta de sistema especialista pode contribuir positivamente para a melhoria no processo de software. A execução da abordagem proposta na forma de uma ferramenta especialista pretende apresentar para as organizações um mapeamento detalhado de como funciona o seu processo de desenvolvimento de software. Para tanto optou-se pela obtenção de resultados através da aplicação da abordagem GQM que avaliou a adequação dos resultados emitidos pelo SE na visão de especialistas em MPS e a aderência dos resultados sob a visão dos responsáveis.

142 142 Considerando as hipóteses (Seção 1.1.1) e tendo por fundamento as contribuições da ferramenta de sistema especialista, tornou-se possível a elaboração desta avaliação, tratando dos impactos destas em fatores de adequação e aderência do processo. Neste contexto, a adequação é obtida com as avaliações realizadas pelos especialistas em MPS, que garantem a confiabilidade das informações do SE, e a aderência mediante a execução do SE pelas organizações que avaliaram os resultados e asseguram a qualidade dos mesmos. Para tal avaliação, optou-se pela obtenção de métricas, com adoção da abordagem GQM, através de um questionário direcionado a especialistas em MPS e organizações de software. Sendo assim é possível afirmar, com base nos resultados da abordagem GQM, que um diálogo automatizado traz resultados que podem ser similares aos resultados propostos por um especialista em MPS. Por fim, pode-se afirmar que os objetivos propostos para este trabalho foram alcançados, embora seja importante destacar que os resultados apresentados não são definitivos, sendo passíveis de aprimoramentos e revisões, conforme identificados na Seção 6.2, trabalhos futuros. 6.1 PRINCIPAIS CONTRIBUIÇÕES As principais contribuições apresentadas para este trabalho são: Uma revisão informal que identificou trabalhos que apresentam abordagens para o uso de ferramentas que auxiliam na melhoria de processos de software em organizações de desenvolvimento. Uma revisão formal, na forma de um mapeamento sistemático, que evidenciou por meio de publicações acadêmicas, o atual estado da arte de metodologias que apoiam o estudo aos processos de melhoria de software. O mapeamento sistemático, constatou a falta de ferramentas que possam mapear o processo de desenvolvimento de software de uma organização, trazendo como resultados pontos fortes, fracos e oportunidades de melhoria. O mapeamento, em sua maioria, retornou trabalhos que apresentam metodologias de avaliação inicial aderentes aos processos de melhoria baseados em modelos de referência como CMMI e MPS.BR.

143 143 A construção de árvores de decisão que apoiaram o desenvolvimento do sistema especialista, que traz como resultados pontos fortes, pontos fracos e oportunidades de melhoria. Desenvolvimento de uma ferramenta computacional que atendesse ao modelo de abordagem proposto, considerando a estrutura de desenvolvimento definidas, e disponível para organizações e especialistas em MPS; e Avaliação da abordagem automatizada através de um questionário de avaliação com organizações e especialistas MPS, objetivando demonstrar as melhorias obtidas em fatores de adequação e aderência aos resultados da ferramenta SE, que podem ser utilizados por outros profissionais para o mapeamento de seus processos de desenvolvimento. 6.2 TRABALHOS FUTUROS Ao término da pesquisa que resultou neste trabalho, foram identificadas as seguintes oportunidades de trabalhos futuros: Melhorar a interface do sistema especialista, possibilitando inserir dicas autoexplicativas para cada pergunta. Essa medida facilita o entendimento a cada questão, possibilitando que o usuário tenha uma melhor interpretação e responda corretamente cada questão. Permitir que o sistema especialista seja uma versão voltada para web, sendo possível que os usuários acessem o sistema de qualquer lugar; Inserir perguntas no sistema especialista que explorem as descrições organizacionais. Através destas perguntas seria possível mapear o porte da organização, quantidade de funcionários, papéis exercidos pelos principais responsáveis pelo processo de desenvolvimento, entre outras informações pertinentes a organização e que contribuem para um resultado mais amplo; e Por fim, a possibilidade de incrementar o sistema especialista com análises de tomada de decisão para os pontos fracos levantados nos resultados.

144 144 REFERÊNCIAS ALMEIDA, C. D. A. Continuidade da Execução de Processos de Software em Empresas Avaliadas no MPS.BR f. Dissertação (Mestrado em Informática Aplicada), Universidade de Fortaleza (UNIFOR), Fortaleza ANACLETO, A.; WANGENHEIM, C. G.; SALVIANO, C. Um método de avaliação de processos de software em micro e pequenas empresas. In: SIMPÓSIO BRASILEIRO DE QUALIDADE DE SOFTWARE SBQS, IV, Porto Alegre. Anais... Porto Alegre: SBQS, ANGELI, Chrissanthi. Online Expert Systems for Fault Diagnosis in Technical Processes. Expert Systems. Wiley Online Library, May p BARBIERI, C. BI Business Intelligence: Modelagem e Tecnologia, Axcel Books, BARROS, Renata P. Evolução, Avaliação e Validação do Software RoboEduc f. Dissertação (Mestrado em Engenharia Elétrica da UFRN (área de concentração: Engenharia da computação)). Universidade Federal do Rio Grande do Norte (UFRN), Natal, BASILI, V.R.; CALDEIRA, G.; ROMBACH, D.; The Goal Goal Question Metric Approach. In: MARCINIAK, J.J. (editor). Encyclopedia of Software Engineering, v.2, New York, NY: John Wiley & Sons, BECK, K. Extreme Programming Explained: Embrace Change. 2. ed. Reading, Massachusetts: Addison-Wesley, BEZERRA, E. Princípios de Análise e Projeto de Sistemas com UML. Editora CAMPUS, BHUVANESWARI, T.; PRABAHARAN, S. A Survey on Software Development Life Cycle Models. International Journal of Computer Science and Mobile Computing - IJCSMC. v.2, n.5, p , May CARVALHO, A. M. B. R.; CHIOSSI, T. C. S. Introdução a engenharia de software. Campinas: Unicamp, CERDEIRAL, C. Uma Abordagem para Gerência e Avaliação de Projetos de Melhoria de Processos de Software do Ponto de Vista da Instituição de Consultoria. Dissertação (Mestrado em Ciências em Engenharia de Sistemas e Computação) Programa de Pós-Graduação em Engenharia de Sistemas e Computação, UFRJ, Rio de Janeiro, CLARA, V. T. SDLC and Model Selection: A Study. International Journal of Application or Innovation in Engineering & Management - IJAIEM. v.2, n.1, p , January COLETTA, Antonio. An Industrial Experience in Assessing the Capability of Non-software Processes Using ISO/IEC Software Process: Improvement and Practice. Wiley InterScience, Mar p

145 145 COWELL, R.G.; DAWID, P.; LAURITZEN, S.L.; SPIEGELHALTER, D.J. Probabilistic Networks and Expert Systems. 11ª ed. New York: Springer, DUMKE, R. R.; SCHMIETENDORF, A.; KUNZ, M.; GORGIEVA, K. Software Metrics for Agile Software Development. In: AUSTRALIAN SOFTWARE ENGINEERING CONFERENCE (ASWEC). 19 th, Perth, WA. Proceedings IEEE Computer Society, 2008, p ERICSSON, E.; GUSTAFSSON P.; HÖÖK, D.; MARCKS, V. W. L.; ROCHA, F. W. Process Improvement Framework Evaluation. In: INTERNATIONAL CONFERENCE ON MANAGEMENT SCIENCE & ENGINEERING, 17., Melbourne, Australia. Proceedings IEEE Computer Society, 2010, p EL-EMAM, K.; SIMON, J.-M. ; ROUSSEAU, S.; JACQUET, E. Cost Implication of Interrater Agreement for Software Process Assessments. In: SOFTWARE METRICS SYMPOSIUM, 50., Bethesda, MD. Proceedings Fifth International Software Metrics Symposium. Metrics, 1998, p EL-EMAM, K.; GOLDENSON, D. R. An Empirical Review of Software Process Assessment Disponível em: < Acesso em: Jan ENTINEX, Inc. How much does it cost? - CMMIFAQ. Disponível em: Acesso em: Dezembro de FELIZ, Tom. Lightweight Software Process Assessment and Improvement. In: PACIFIC NORTHWEST SOFTWARE QUALITY CONFERENCE PNSQC, 30., 2012, Portlan, Oregon. Proceedings... PNSQC, 2012, p FIGUEIRA FILHO, C. S. JEOPS Integração entre Objetos e Regras de Produção em Java Dissertação de Mestrado. Universidade Federal de Pernambuco (UFPE), Recife FOJTIK, R. Extreme Programming in development of specific software. In: WORLD CONFERENCE ON INFORMATION TECHNOLOGY WCIT, 2., 2011, Antalya, TR. Proceedings Computer Science. Elsevier, 2011, p FUGGETTA, A. Software Process: A Roadmap. In: INTERNATIONAL CONFERENCE ON SOFTWARE ENGINEERING ICSE, 22., 2000, Limerick, Ireland. Proceedings of the Future of Software Engineering. ACM Press, 2000, p GARCIA, I.; ANDREA, I. Using the Software Process Improvement approach for defining a Methodology for Embedded Systems Development using the CMMI-DEV v th IEEE International Conference on Computer and Information Technology (CIT 2010) GIBSON, D.L.; GOLDENSON, D.R.; KOST, K. Performance Results of CMMI-Based Process Improvement, Technical Research CMU/SEI-2006-TR-004, Software Engineering Institute, Pittsburgh, Disponível em: < Acesso em: Oct Software Engineering Institute. Carnegie Mellon GRAY, E.; SAMPAIO, A.; BENEDIKTSSON, O. An Incremental Approach to Software Process Assessment and Improvement. Software Quality Journal. v. 13, n.1, Disponível em: < Acesso em: Nov

146 146 GREEN, G. C.; HEVNERB, A. R.; COLLINS, R.W. The impacts of quality and productivity perceptions on the use of software process improvement innovations. Proceedings Information and Software Technology. Elsevier, v. 47, n. 8, p , Jun GUPTA, S.; AGGARWAL, A. Study of Software Development Process and Development Models. International Journal of Research in Engineering & Applied Sciences - IJREAS. v.2, n.2, p , February HABRA, N.; ALEXANDRE, S.; DESHANAIRS, J.; LAPORTE, C. Y.; RENAULT, A. Initiating software process improvement in very small enterprises - Experience with a light assessment tool. Information and Software Technology. v.50, n. 7-8, p , Jun HARMON, P.; KING, D. Artificial Intelligence In Business Expert Systems. Wiley, New York HAYKIN, S. Introdução. Redes neurais: princípios e práticas. 2. ed. São Paulo-SP: Artmed Editora. p HEIKKILÄ, M. Learning and Organizational Change in SPI Initiatives. Springer-Verlag Berlin Heidelberg. p HUMPHREY, W. S. Managing the software process. Reading, Addison-Wesley (SEI series in software engineering), IBM. Rational Unified Process Disponível em: < Acesso em: Junho de IBM. Rational Unified Process Best Practices for Software Development Teams. Rational Software White Paper TP026B, Rev 11/ IEEE Computer Society. SWEBOK. Guide to the Software Engineering Body of Knowledge. Version IGNIZIO, J. P. Introduction to Expert Systems The Development and Implementation of Rule- Based Expert Systems. New York: McGraw-Hill, INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO/IEC : Information Technology Process Assessment, INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO/IEC 12207: Systems and software engineering - Software life cycle processes JÄRVINEN, J. Measurement Based Continuous Assessment of Software Engineering Process. Technical Research Centre of Finland, Oulu, Disponível em < Acesso em: Dezembro de KALINOWSKI, M.; SANTOS, G.; REINEHR, S.; MONTONI, M.; ROCHA, A.R.; WEBER, K.C.; TRAVASSOS, G.H. MPS.BR: A Tale of Software Process Improvement and Performance Results in the Brazilian Software Industry. In: QUALITY OF INFORMATION AND COMMUNICATIONS

147 147 TECHNOLOGY - QUATIC, 70th, 2010, Porto. Proceedings IEEE Computer Society, 2010, p KAUR, R; SENGUPTA, J. Software Process Models and Analysis on Failure of Software Development Projects. International Journal of Scientific & Engineering Research IJSE. v. 2, n.2, p. 1 4, February 2011 KELLER, R. Tecnologias do Sistema Especialista. São Paulo (SP); Mcgraw- Hill; KOSCIANSKI, A.; SOARES, M. S. Qualidade de Software. 2ª edição. São Paulo (SP); Novatec; KHURANA, G.; GUPTA, S. Study & Comparison of Software Development Life Cycle Models. International Journal of Research in Engineering & Applied Sciences - IJREAS. v.2, n.2, p , February KITCHENHAM, B.; CHARTERS, S. Guidelines for performing Systematic Literature reviews in Software Engineering. EBSE Technical Report , Keele University and University of Durha, Disponível em: < doi= &rep=rep1&type=pdf>. Acesso em: jan KRUCHTEN, P. Introduction to the Rational Unified Process, Addison-Wesley, LARMAN, C. Software Development: Iterative & Evolutionary Disponível em: < Acessado em: 05/04/2014 LAYMAN, L.; WILLIAMS, L.; DAMIAN, D.; BURES, H. Essential communication practices for Extreme Programming in a global software development team. Information and Software Technology. Science Direct. Elsevier. v. 48, p , LEAU, Yu Beng; LOO, Wooi Khong; THAM, Wai Yip; TAN Soo Fun. Software Development Life Cycle Agile vs Traditional Approaches. In: INTERNATIONAL CONFERENCE ON INFORMATION AND NETWORK TECHNOLOGY ICINT, 2012, Singapore. Proceedings... IPCSIT Press, 2012, p LINARES, K. S. C. Sistema Especialista Nebuloso para Diagnóstico Médico, 116f. Dissertação (Mestrado em Engenharia Elétrica) Universidade Federal de Santa Catarina, Florianópolis-SC. LUGER, G. Inteligência Artificial Estruturas e Estratégias para Resolução de Problemas Complexos. 4. ed. Porto Alegre: Bookman, MÄKINEN, T.; VARKOI, T.; SOINI, J. Integration of Software Process Assessment and Modeling. In: PROTLAND INTERNATIONAL CENTER FOR MANAGEMENT OF ENGINEERING AND TECHNOLOGY PICMET, 2007, Portland. Proceedings... Portland : PICMET, 2007, p MARÇAL, A. S. C. SCRUMMI: Um processo de gestão ágil baseado no Scrum e aderente ao CMMI f. Dissertação (Mestrado em Informática Aplicada), Universidade de Fortaleza (UNIFOR), Fortaleza

148 148 MEGA, B.; FONSECA, K.; BOESSIO, R.; MASSA, P.; MONTONI, M.; VASCONCELOS, J.; KATSURAYAMA, A. E.; ROCHA, A. R. Melhoria de Processos de Software na Drive Disponível em: < Acesso em: Outubro de MENDES, F. F.; ALMEIDA, J. N.; ARRUDA JR., E. A. Experiência de Implantação de Melhoria de Processos de Software em um Laboratório de Pesquisa. In. WORKSHOP ANUAL DO MPS WAMPS, VII, 2011, Campinas, SP. Proceedings Softex, 2011, p MENDES, F. F., OLIVEIRA, J. L. Validação de um método de Diagnóstico de processos Software. In: CONGRESSO DE PESQUISA, ENSINO E EXTENSÃO DA UFG CONPEEX, , Goiânia. Anais eletrônicos do XIV Seminário de Iniciação Científica [CD ROM], Goiânia: UFG, n.p METAXIOTIS, K.; PARRAS, J.; Expert System in Business: Applications and Future Directions for Operations Research. Industrial Management & Data Systems. v. 103, n. 5, p , MIYASHIRO, M.A.S.; FERREIRA, M.G.V.; SANT ANNA, N.; SILVA, J.D.S. Uma Aplicação para Auxiliar nas Atividades de Pré-Auto-Avaliação da Maturidade dos Processos de uma Organização Utilizando os Modelos CMMI v 1.3 e MPSR. In: WORKSHOP EM ENGENHARIA E TECNOLOGIA ESPACIAIS, 2 ed., 2011, São José dos Campos. Proceedings... São José dos Campos: WETE, MOREIRA, D. S. Abordagem para realização de autodiagnostico de processos de software f. Dissertação (Mestrado em Computação Aplicada), Universidade do Vale do Itajaí (UNIVALI), Itajaí MOURA, M. F.; CRUZ, S. A. B. Estudo de Expert System Shells para o Ambiente de Diagnose Remota, Relatório Técnico, Embrapa, Campinas, 22 p MUNÁRRIZ, A. L. Fundamentos de Inteligência Artificial. Murcia, Espanha: Selegráfica, MUNASSAR, N. M. A.; GOVARDHAN, A. A Comparison Between Five Models Of Software Engineering. International Journal of Computer Science - IJCS. v. 7, n. 5, p , Sep NUNES, Paulo. Conceito de árvore de decisão Disponível em: < Acessado em: Julho de OLDONI, A; FERNANDES, A. M. R; DETERS, J. I. Desenvolvimento de uma Arquitetura da Comunicação de um Agente Pedagógico Inteligente em JAVA. Revista Eletrônica de Sistemas de Informação - RESI, ed. 10, v. 12, n. 2, OLIVEIRA, Ricardo F. Conceitos que compõem um Expert System. Disponível em: < Acessado em: Março de OSORIO, Jorge A.; CHAUDRON, Michel R. V.; HEIJSTEK, Werner. Moving FromWaterfall to Iterative Development An Empirical Evaluation of Advantages, Disadvantages and Risks of RUP. In: CONFERENCE ON SOFTWARE ENGINEERING AND ADVANCED APPLICATIONS EUROMICRO, 37 th, 2011, Oulu. Proceedings IEEE Computer Society, 2011, p

149 149 PAULA FILHO, Wilson P.; MACHADO, F. T.; DRUMOND, F. P.; NOGUEIRA, M. M.; FERREIRA, G. R. M. Aplicação da fase de Diagnóstico de um processo para melhoria de organizações técnicas. In: SIMPÓSIO INTERNACIONAL DE MELHORIA DE PROCESSO DE SOFTWARE, 5 th, 2003, Recife. Anais do SIMPROS PAULA FILHO, Wilson de Pádua. Engenharia de Software: Fundamentos, Métodos e Padrões. 2ª edição. Rio de Janeiro: LTC, PAULA FILHO, Wilson de Pádua. Engenharia de Software: Fundamentos, Métodos e Padrões. 3ª edição. Rio de Janeiro: LTC, PETERSEN, K.; FELDT, R.; MUTJABA, S.; MATTSON, M.. Systematic Mapping Studies in Software Engineering. In: INTERNATIONAL CONFERENCE ON EVALUATION EVALUATION AND ASSESSMENT IN SOFTWARE ENGINEERING EASE, 12., 2008, Bari. Proceedings... BCS ewic, p PETTERSSON, F.; IVARSSON, M.; GORSCHEK, T.; OHMAN, P. A practitioner s guide to light weight software process assessment and improvement planning. The Journal of Systems and Software. v. 81, p , PFLEEGER, Shari Lawrence. Engenharia de software: teoria e prática. [Traduzido do original: Software engineering - theory an practice]. Tradução de Dino Franklin. 2. ed. São Paulo: Prentice Hall, PINO, F. J.; PARDO, C.; GARCÍA, F.; PIATTINI, M. Assessment methodology for software process improvement in small organizations. Information and Software Technology. v. 52, p , PRESSMAN, Roger S. Engenharia de Software, Sexta Edição. Editora MCGrawHill: Porto Alegre, PRICOPE, S.; LICHTER, H. Towards a Systematic Metric Based Approach to Evaluate SCAMPI Appraisals. In: INTERNATIONAL CONFERENCE ON PRODUCT-FOCUSED SOFTWARE PROCESS IMPROVEMENT PROFES, 10th, 2009, Oulu - Finland. Proceedings Lecture Notes in Business Information Processing LNBIP. Berlin: Springer-Verlag, p PRIKLADNICKI, R.; BECKER, C. A.; YAMAGUTI, M. H. Uma Abordagem para a Realização de Diagnóstico Inicial em Empresas que Implementam o MPS.BR Disponível em: < Acessado em: Abril de RAGUNATH, P.K.; VELMOUROUGAN, S.; DAVACHELVAN, P.; KAYALVIZHI, S.; RAVIMOHAN, R. Evolving a New Model (SDLC Model-2010) for Software Development Life Cycle (SDLC). International Journal of Computer Science and Network Security - IJCSNS, v.10, n.1, p , January REZENDE, S. O. Sistemas Inteligentes: Fundamentos e Aplicações; Editora Manole; Barueri, SP

150 150 ROCHA, V. C. Metodologia para implementação do MPS.BR utilizando o ambiente Webapsee. Dissertação (Mestre em Engenharia Elétrica) Programa de Pós-Graduação em Engenharia Elétrica, UFPA, Belém, ROCHA, A. R. C.; MALDONADO, J. C.; WEBER, K. C. Qualidade de Software: Teoria e Prática, São Paulo: Prentice Hall, Cap. 12 (Automatização da Definição de Processos de Software). ROCHA, A.R.; MONTONI, M.; SANTOS, G.; OLIVEIRA, K.; NATALI, A. C.; MIAN, P.; CONTE, T.; MAFRA, S.; BARRETO, A.; ALBUQUERQUE, A.; FIGUEIREDO, F.; SOARES, A.; BIANCHI, F.; CABRAL, R.; DIAS, A. Dificuldades e Fatores de Sucesso na Implementação de Processos de Software Utilizando o MR-MPS e o CMMI Disponível em: < Acesso em: Novembro de ROSSO, M. Sistema Especialista de Apoio à Decisão em Ventilação Mecânica. In: VIII CONGRESSO BRASILEIRO DE INFORMÁTICA EM SAÚDE, Natal. Anais eletrônicos do VIII Congresso Brasileiro de Informática em Saúde. SBIS, RUPARELIA, N. B. Software Development Lifecycle Models. ACM SIGSOFT Software Engineering Notes. V. 35, N. 3, p. 8 13, May RUSSELL, S., NORVIG, P. Inteligência Artificial, Editora Campus, SALO, O.; ABRAHAMSSON, P. Agile methods in European embedded software development organisations: a survey on the actual use and usefulness of Extreme Programming and Scrum. The Institution of Engineering and Technology - IET. v.2, n.1, p , February SANTANA, André Felipe Lemos. Problemas em Iniciativas de Melhoria de Processos de Software sob a Ótica de uma Teoria de Intervenção f. Dissertação (Mestrado em Ciência da Computação), Universidade Federal de Pernambuco (UFPE), Recife, SCHWABER, K. Agile Project Management with Scrum. Microsoft Press, 2004 SCHWABER, K.; SUTHERLAND, J. Guia do Scrum Um guia definitivo para o Scrum : As regras do jogo SEI - Software Engineering Institute. CMMI-DEV: CMMI for Development. Technical Report CMU/SEI-2010-TR-033, ESC-TR Software Engineering Institute, 2010a. Disponível em: < Acesso em: Abril SEI - Software Engineering Institute. Process Maturity Profile. 2010b. Disponível em: < >. Acesso em: Abril SEI - Software Engineering Institute. Standard CMMI Appraisal Method for Process Improvement (SCAMPISM) A, Version 1.3: Method Definition Document Disponível em: < Acesso em: Abril 2013 SEI - Software Engineering Institute. CMMI Institute Maturity Profile Report Disponível em: < Acesso em: Maio 2014.

151 151 SILVA, A.A.C.; SILVA, E.J.F.; PORTELA, C. S.; VASCONCELOS, A. M. L.; OLIVEIRA, S. R. B. Spider-PE: Uma Ferramenta de Apoio à Execução de Processos de Software aderente ao CMMI-DEV e MR-MPS. In: VIII WORKSHOP ANUAL DO MPS WAMPS. 2012, Itupeva SP. Anais... Itupeva p SILVA, A. M. R.; VIDEIRA, C. A. E. UML, Metodologias e Ferramentas Case. Lisboa: Centro Atlântico, SIMOES, R. Expandindo a Aplicação e os Benefícios do Scrum Disponível em: < Acesso em: Maio de SOFTEX - Associação para a Promoção da Excelência do Software Brasileiro. Guia Geral MPS de Software Disponível em: < Acesso em: Março SOFTEX Associação para a Promoção da Excelência do Software Brasileiro. Guia de Avaliação Disponível em: < Acesso em Março SOFTEX Associação para a Promoção da Excelência do Software Brasileiro. Avaliações no Brasil Disponível em: < Acesso em Maio SOMMERVILLE, I. Engenharia de Software, 8ª edição. São Paulo: Pearson Addison Wesley, STALLINGER, F.; PLOSCH, R.; POMBERGER, G.; VOLLMAR, J. Integrating ISO/IEC Conformant Process Assessment and Organizational Reuse Enhancement. Journal of Software Maintenance and Evolution: Research and Practice. v.22, n.4, p , September STELL, A. C.; TOLEMAN, M.; ROUT, T. Process improvement for small firms: An evaluation of the RAPID assessment-based method. Information and Software Technology. v.48, p , TAMAKI, P. A. O. Uma extensão do RUP com ênfase no gerenciamento de projetos do PMBoK baseada em Process Patterns f. Dissertação de mestrado em engenharia. Escola Politécnica da Universidade de São Paulo. São Paulo, THIRY, M.; WANGENHEIM, C.G.V.; ZOUCAS, A.; PICKLER, K. Uma Abordagem para a Modelagem Colaborativa de Processos de Software em Micro e Pequenas Empresas. In: V SIMPÓSIO BRASILEIRO DE QUALIDADE DE SOFTWARE Vila Velha - ES. Anais... Vila Velha, 2006, p THIRY, M.; WANGENHEIM, C.G.V.; ZOUCAS, A.; TRISTÃO, L. FAPS: Ferramenta para apoiar Avaliações Integradas de Processos de Software Disponível em: < df>. Acesso em Abril TONINI, A.C.; SPINOLA, M. M.; CARVALHO, M. M. Contribuição dos modelos de qualidade e maturidade na melhoria dos processos de software. Revista Produção (EPUSP). v. 18, n. 2, p

152 152 TRAVASSOS, G. H.; KALINOWSKI, M. imps 2010: desempenho das empresas que adotaram o modelo MPS de 2008 a 2010, Relatório Técnico, Softex, Campinas SP, p. Disponível em: < Adotaram-o-Modelo-MPS-de-2008-a-2010.pdf>. TRAVASSOS, G. H.; KALINOWSKI, M. imps 2012: Evidências sobre o desempenho das empresas que adotaram o MPS-SW desde 2008, Relatório Técnico, Softex, Campinas SP, p. Disponível em: < VERMA, K.; KUMAR, P.; KUMAR, M.; TIWARI, G. An Assessment between Software Development Life Cycle Models of Software Engineering. International Journal of Electronics and Computer Science Engineering. v.2, n.2, p , WANGENHEIM, C. G. V.; PICKLER, K.K.; THIRY, M.; ZOUCAS, A. C.; SALVIANO, C. F. Aplicando Avaliações de Contextualização em Processos de Software Alinhados ao CMMI-SE/SW. In: VII SIMPÓSIO INTERNACIONAL DE MELHORIA DE PROCESSOS DE SOFTWARE São Paulo, SP Brasil. Anais... São Paulo, WANGENHEIM, C. G. V.; VARKOI, T.; SALVIANO, C. F. Standard Based Software Process Assessments in Small Companies. Software Process Improvement and Practice. v. 11, pg , WAZLAWICK, Raul Sidnei. Uma Reflexão sobre a Pesquisa em Ciência da Computação à Luz da Classificação das Ciências e do Método Científico. Revista de Sistemas da Informação da FSMA, n.6, p. 3 10, WEBER, K. C.; ARAUJO, E.; MACHADO, C. A. F.; SCALET, D.; SALVIANO, C. F.; ROCHA, A. R. C. Modelo de Referência e Método de Avaliação para Melhoria de Processo de Software versão 1.0 (MR-MPS e MA-MPS). In: IV SIMPÓSIO BRASILEIRO DE QUALIDADE DE SOFTWARE (SBQS), 2005, Porto alegre - RS. Anais... Porto Alegre, WELLS, J. Donovan. Extreme Programming: A gentle introduction Disponível em: < Acessado em: Abril 2014 YOUNG, H.; FANG, T.; HU, C. A Successful Practice of Applying Software Tools to CMMI Process Improvement. CMMI practices and experiences. Journal of Software Engineering Studies, Vol. 1, No. 2, p , December 2006.

153 153 APÊNDICE A Mapeamento Sistemático A1 String de Busca IEEE: (("Document Title":"Software Process Improvement") AND (p_abstract:assessment OR "Abstract":"Self-Assessment" OR "Abstract":"Self Assessment" OR "Abstract":appraisal OR "Abstract":evaluation OR "Abstract":Tool OR p_abstract:lifecycle OR "Abstract":"life cycle" OR p_abstract:method OR "Abstract":methodology OR "Abstract":methodologies OR "Abstract":diagnostic OR "Abstract":diagnosis)) ScienceDirect: pub-date > 2007 AND Title("Software Process Improvement") AND Abstract (assessment OR "Self-Assessment" OR "Self Assessment" OR appraisal OR evaluation OR Tool OR lifecycle OR "life cycle" OR method OR methodology OR methodologies OR diagnostic OR diagnosis) [Journals(Computer Science)] ACM: ((Title: "Software Process Improvement") AND (Abstract: assessment OR abstract: "Self-Assessment" OR abstract: "Self Assessment" OR abstract: appraisal OR abstract: evaluation OR abstract: Tool OR abstract: lifecycle OR abstract: "life cycle" OR abstract: method OR abstract: methodology OR abstract: methodologies OR abstract: diagnostic OR abstract: diagnosis)) and (PublishedAs:journal OR PublishedAs:proceeding) AND (PublishedAs:journal OR PublishedAs:proceeding) SpringerLink: '(ti:("software process improvement")) AND (ab: assessment OR "Self- Assessment" OR "Self OR Assessment" OR appraisal OR evaluation OR Tool OR lifecycle OR "life OR cycle" OR method OR methodology OR methodologies OR diagnostic OR diagnosis)' Google Scholar: tudonotítulo: "Software Process Improvement" A2 Resultado da Extração dos Dados Nesta seção são apresentados os resultados das seleções e análise dos resultados do mapeamento sistemático. A Tabela 3 mostra a quantidade de artigos retornados para cada base de dados.

154 154 Tabela 3. Artigos retornados Nome da fonte Qtdade. retornada Selecionados IEEExplore 42 2 ScienceDirect 8 5 ACM Digital library 0 0 SpringerLink 0 0 Google Scholar Total A Figura 32 é uma representação gráfica da quantidade de artigos retornados IEEExplore ScienceDirect ACM Digital library SpringerLink Google Scholar Figura 34. Total de trabalhos retornados Após efetuar as buscas nas bases de dados, foram obtidos um total de 551 estudos. A base que apresentou maior número de resultados foi a Google Scholar com 501 estudos, dos quais, 12 foram selecionados. A seleção realizada no Google Scholar consiste em ordenar os artigos por relevância, realizando a análise do título seguido pelo resumo, introdução e artigos em inglês. Em um total de 551 estudos retornados, foram selecionados 19 estudos baseados nos critérios de inclusão e exclusão definidos, totalizando 3,45% do total retornado. Sendo que desses 19 resultados, 4 deles aparecem em duas bases de dados. Portanto apenas 15 trabalhos são relevantes para a pesquisa. Na Tabela 4 são apresentados os 15 trabalhos selecionados. Tabela 4. Trabalhos selecionados Ano Título do trabalho Bases de dados 2008 Software Process Improvement Google Methodologies for Small and Medium Enterprises 2008 Framework to Evaluate Software Process Improvement in Small Organizations Scholar Google Scholar Autores Deepti Mishra, Alok Mishra Pedro E. Colla, Jorge Marcelo Montagna