RELATÓRIO FINAL DESENVOLVIMENTO DE UM AMBIENTE DE ENGENHARIA DE SOFTWARE BASEADO EM PROCESSOS UTILIZANDO WORKFLOW

Tamanho: px
Começar a partir da página:

Download "RELATÓRIO FINAL DESENVOLVIMENTO DE UM AMBIENTE DE ENGENHARIA DE SOFTWARE BASEADO EM PROCESSOS UTILIZANDO WORKFLOW"

Transcrição

1 DESENVOLVIMENTO DE UM AMBIENTE DE ENGENHARIA DE SOFTWARE BASEADO EM PROCESSOS UTILIZANDO WORKFLOW Pablo Schoeffel 1 Janaína Schwarzrock 2, Geraldo Menegazzo Varela 3, Osmar de Oliveira Braz Junior 3 Palavras-chave: Desenvolvimento de Software, Processos, BPMN. Resumo: A melhoria de processo é algo cada vez mais buscado pelas empresas de desenvolvimento de software, objetivando melhorar a qualidade de seus produtos e atividades internas. Para isso, é importante que os processos sejam definidos e que seja garantida a sua execução. Apesar de existirem notações específicas para a modelagem de processo de desenvolvimento de software, como a SPEM (Software Process Engineering Metamodel), alguns trabalhos têm questionado a utilização dessas notações frente à utilização de BPMN (Business Process Modeling Notation), que permite a integração com demais processos da empresa, entendimento por pessoas alheias à área de software e possui suporte para linguagens de execução do processo. Além disso, percebe-se uma dificuldade grande de micro e pequenas empresas de desenvolvimento de software possuírem e seguirem um processo definido ou ainda atenderem a modelos e normas de qualidade de processo. Esse projeto buscou avaliar ferramentas BPMS (Business Process Management Systems) e utilizá-la para mapear um processo de desenvolvimento de software, baseado na norma ABNT ISO/IEC , que é voltada especificamente para empresas de desenvolvimento de software com até 25 funcionários. Para o melhor entendimento da norma e da realidade das empresas da região, foi realizada uma pesquisa (survey) com 23 empresas, resultando numa visão geral sobre a adequação das empresas ao processo solicitado pela norma ABNT ISO/IEC A partir dessas informações, foi realizado o mapeamento de um processo modelo baseado na norma supracitada na ferramenta BonitaSoft, os quais foram disponibilizados para utilização das empresas participantes da pesquisa. 1. Introdução A gerência do processo de desenvolvimento de software é um assunto que vem ganhando destaque em virtude da relação da qualidade do processo de software com a qualidade do produto final. Modelos de qualidade que trabalham com maturidade de processos, como o CMMI-DEV e MR-MPS, estabelecem que a gerência do processo é fundamental para se atingir a qualidade. Sendo assim, o processo deve ser definido, avaliado e melhorado continuamente. O gerenciamento de processos de desenvolvimento de software está relacionado ao BPM (Business Process Management), disciplina que visa a gerenciar os processos de negócio de uma organização. Ao se definir um processo de negócio, o mesmo deve ser modelado de forma legível a todos os interessados no processo. O BPMN (Business Process Modeling Notation) é uma notação padrão para modelagem de processo de negócio. Questiona-se a utilização desta notação para a modelagem de processos de desenvolvimento de software, sendo que existem notações específicas para esse objetivo. A notação BPMN tem suas vantagens quanto à padronização e possibilita a automatização do processo, pois provê suporte às linguagens de execução. 1 Orientador, Professor do Departamento de Sistemas de Informação do CEAVI-UDESC 2 Acadêmica do Curso de Sistemas de informação CEAVI-UDESC, bolsista de iniciação científica PROIP/UDESC. 3 Professor do CEAVI-UDESC.

2 Para apoiar a área de BPM, existem os chamados BPMS (Business Process Management System), que são um tipo especial de sistema que permite automatizar e gerenciar um processo de negócio. Os softwares ProcessMaker, BizAgi, BonitaSoft e jbpm são exemplos destes sistemas. Um BPMS pode ser utilizado para a definição, execução e gerenciamento dos processos de desenvolvimento de software, proporcionando melhoria no processo e consequentemente no produto final. Apesar disso, estes sistemas podem não proporcionar todo suporte necessário ao processo de desenvolvimento de software, sendo que este é complexo e sofre constantes mudanças. Com o intuito de apoiar o processo de desenvolvimento de software existem os chamados PSEE (Process-Centered Software Engineering Environments), que também pode ser classificados como BPMS, mas que possuem maior flexibilidade e integração com outras ferramentas utilizadas nesses processos. As ferramentas WebAPSEE e SPIDER-PE, são exemplos destes ambientes. Em 2012 foi lançada a norma de qualidade em processos de software ABNT ISO/IEC Esta norma ao contrário do CMMI-DEV e MR-MPS é voltada para micro e pequenas organizações. Como o lançamento desta norma e o estudo realizado sobre as ferramentas de BPMS, surgiu a ideia da utilização de uma destas ferramentas disponíveis no mercado para a modelagem e execução dos processos sugeridos pela Norma ABNT ISO/IEC O processo baseado na Norma foi modelado em BPMN na ferramenta BonitaSoft. Esta ferramenta de BPM possui versão gratuita que permite a modelagem e execução do processo. Juntamente com o processo foram pesquisados e elaborados modelos para os artefatos requeridos pela Norma. Estes modelos foram anexados os processos. Para suprir particularidades do processo de desenvolvimento de software, foi necessário a implementação de algumas classes Java por meio de conectores (funcionalidade fornecida pela ferramenta BonitaSoft). Em paralelo a modelagem do processo na ferramenta, foi realizada uma pesquisa com as micro e pequenas empresas desenvolvedoras de software do Alto Vale do Itajaí. O objetivo desta pesquisa foi levantar uma panorama geral da situação das empresas em relação a Norma de qualidade em processos de software ABNT ISO/IEC O resultado desta pesquisa e processo desenvolvido em BPMN foram disponibilizados as empresas participantes da pesquisa, juntamente com um manual de instalação e utilização do processo e da ferramenta proposta. 2. Gerenciamento do Processo de Desenvolvimento de Software A procura por produtos de software vem aumentando, além da exigência de qualidade por parte dos clientes (CARVALHO ET AL, 2011). Segundo Bertollo e Falbo (2003, p. 1), o desenvolvimento de produtos de software de qualidade, dentro do cronograma e considerando os custos planejados sempre foi um desafio para as organizações de desenvolvimento de software. De acordo com Oliveira et al (2011), a qualidade do software está diretamente relacionada a qualidade do seu processo de desenvolvimento. Um processo de desenvolvimento de software pode ser visto como um conjunto de atividades, padrões, métodos, ferramentas e práticas que são utilizadas para construir um produto de software (DONADEL ET AL, 2009, p. 6). Segundo Bertollo e Falbo (2003, p. 1), a principal causa dos problemas no desenvolvimento de software é a falta de um processo de desenvolvimento de software claramente definido e efetivo. Na busca pela qualidade no processo de desenvolvimento de software, as empresas procuram atender aos modelos de qualidade de software, que se baseiam na maturidade dos processos organizacionais (LIMA et al, 2006). Esta busca pela qualidade no processo deu forças à área de gerenciamento do processo no contexto do desenvolvimento de software.

3 O BPM (Business Process Management) é uma disciplina voltada para a gerência dos processos de negócio, visando identificar, desenhar, medir, controlar e melhorar os processos da organização (BPM CONGRESS, 2012). Os conceitos de BPMN e BPMS, explicados a seguir, estão relacionados a esta área. 3. Business Process Modeling Notation BPMN é uma linguagem de notação gráfica para modelagem de processos de negócio que atualmente está na versão 2.0 (OMG, 2011). Esta notação foi criada pela BPMI (Business Process Management Initiative) com o intuito do promover um padrão para a notação gráfica de processos de negócio, o qual fosse de fácil entendimento para todos os interessados no processo (WHITE, 2005; OWEN; RAJ, 2003). Desde 2005, a linguagem BPMN é mantida pelo OMG (Object Management Group) devido a sua fusão com o BPMI (NOMURA, 2008). White (2004) conta que, historicamente, os modelos dos processos de negócio eram separados das representações utilizadas nos sistemas que executavam os processos. A autora explica que, primeiramente os analistas desenvolviam o modelo de processo do negócio para, posteriormente, este modelo ser manualmente traduzido para um modelo de execução. O BPMN facilitou este processo de modelagem, pois possui suporte apropriado para geração de executável em BPEL (Business Process Execution Language), ou seja, linguagem de execução de processos de negócio. Segundo White (2005, p. 1), o BPMN cria uma ponte padronizada para o espaço entre o desenho de processos de negócio e processo de execução. Segundo Owen e Raj (2003, p. 4), uma meta do BPMN 2.0 é garantir que as linguagens XML destinadas à execução dos processos de negócio, tais como BPEL4WS (Business Process Execution Language for Web Services) e BPML (Business Process Modeling Language), possam ser visualmente expressas com uma notação comum. Por ser definido como padrão, o BPMN contribuiu para a redução da divisão existente devido a diversas ferramentas de modelagem e notação gráfica de processos (WHITE, 2004) Utilização do BPMN Para White (2004), a modelagem de processo de negócio pode ser utilizada para comunicar uma grande variedade de informações para diferentes públicos. A autora salienta que o BPMN foi modelado de forma a prover estrutura para diversos tipos de modelagem, desta forma, permite modelar tanto segmentos (pedaços) de processos, como processo de negócio do início ao fim, em diferentes níveis de detalhes ou abstração. Conforme White (2004), existem dois tipos básicos de modelagem de processos, onde a autora os define como: Colaborativo e Interno. Os processos Internos, também ditos como Privados, são os processos referentes aos procedimentos internos da empresa, enquanto os processos Colaborativos, ou Públicos, tratam das interações entre duas ou mais entidades de negócio. Segundo Owen e Raj (2003, p. 5) notações especiais foram adicionadas ao diagrama para descrever eventos baseados em mensagens e transmissão de mensagens entre as organizações. Os autores esclarecem que as linguagens de execução de processos de negócio e serviços web foram consideradas na criação do BPMN Modelagem do processo de software em BPMN Existem diversas abordagens para modelagem de processo de software, e segundo Portela (2011, p. 18), as mais utilizadas são: a tradicional, que utiliza tecnologias especificamente desenvolvidas com o

4 intuito de representar processos de software; e a abordagem que trata o processo de software como um processo de negócio, como os demais processos encontrados em uma organização. Um processo de desenvolvimento de software não deixa de ser um processo de negócio, no qual contém atividades que são realizadas numa sequência determinada e ao final produzem um resultado esperado. Segundo Silva, Soares e Braga (2006, p. 2) informalmente, o processo de software pode ser compreendido como o conjunto de todas as atividades necessárias para transformar os requisitos do usuário em software. Sendo que um processo de software é um processo de negócio pode-se modelálo em BPMN. Esta abordagem tem suas vantagens e desvantagens, assim como a abordagem tradicional. Portela (2011) realizou um estudo comparativo entre dois padrões de modelagem de processos com o intuito de prover informações úteis à comunidade de Engenharia de Software, de forma que estas possam ser utilizadas pelas empresas na escolha da adoção de uma abordagem/padrão de modelagem. O BPMN e SPEM (Software Process Engineering Metamodel) foram os padrões escolhidos pelo autor para o estudo, por serem bem aceitos pela indústria no âmbito da modelagem de processos. O SPEM também é mantido pelo OMG, mas ao contrário do BPMN, foi desenvolvido especialmente para definir processos de software e seus componentes. Sendo assim, o estudo feito por Portela (2011), apresenta um comparativo entre as duas abordagens: a tradicional e a abordagem do processo de software como um processo de negócio. A análise foi feita através de um estudo de caso, onde considerou-se as melhores práticas dos modelos de qualidade CMMI-DEV (Capability Maturity Model Integration for Development) e MR-MPS (Reference Model for Software Process Improvement), tendo por objetivo identificar qual das duas normas BPMN ou SPEM seria mais adequada para a modelagem do processo de software (PORTELA ET AL, 2012). Ao final do estudo, Portela (2011) não determina qual o melhor padrão a ser utilizado para modelagem de processos de desenvolvimento de software, pois isto parte dos princípios, do contexto organizacional, da cultura e necessidades de cada empresa. Desta forma, Portela (2011) apenas provê informações para que esta escolha possa ser feita com base em informações coerentes e baseadas em normas de qualidade. Dentre os resultados pode-se destacar que o SPEM possui maior expressividade na representação do processo de desenvolvimento de software em relação ao BPMN, pois o SPEM foi desenvolvido especialmente para este propósito (PORTELA, 2011). Em contra partida, o BPMN é mais facilmente compreendido e pode ser integrado aos demais processos da empresa. Outro ponto importante, destacado pelo autor, é o suporte que o BPMN oferece à execução do processo, devido ao suporte a linguagem de execução de processo BPEL4WS, permitindo assim a sua avaliação e possível evolução. 4. Business Process Management System Os BPMS, ou sistemas de gerenciamento de processos de negócios, são softwares que permitem a execução, o controle e a monitoração dos processos de negócio. Estes sistemas podem ser considerados sistemas de gerenciamento de workflow. Um workflow é definido como a automação de um processo de negócio, no todo ou em parte, durante o qual documentos, informações e tarefas são passadas de um participante para outro através de ações, conforme com um conjunto de regras do processo (WORKFLOW MANAGEMENT COALITION, 1999). Segundo Silva, Soares e Braga (2006 p. 5) os chamados Sistemas de Gerência de Workflow (Workflow Management System - WFMS) provêem um conjunto de ferramentas de software de apoio para a definição e execução de workflows. Um sistema de gerenciamento de workflow (SGW) é definido pela Workflow Management Coalition (1999) como um sistema que permite definir, criar e gerenciar a execução de workflow através do uso de software que é capaz de interpretar a definição do

5 processo, interagir com os participantes do workflow e, quando necessário, invoca o uso de ferramentas e aplicações de TI. A seguir são relatados quatro sistemas que permitem o gerenciamento de processos de negócio, apresentando algumas de suas características. Estas ferramentas foram selecionadas para comparação por serem acessíveis a pequenas e médias empresas, pois possuem versão gratuita funcional ou são software livre, além de serem open source. A ferramenta BizAgi é paga, mas possui módulo free para modelagem de processos em BPMN e também oferece versão comercial para empresas de pequeno à médio porte ProcessMaker ProcessMaker é um Sistema de Gerenciamento de Processos de Negócio (BPM) e Fluxo de trabalho em código aberto desenhado para otimizar operações de negócio e gerir fluxos de trabalho para pequenas e médias empresas e organizações. (PROCESSMAKER, 2011, p.1). Segue as principais características deste software (PROCESSMAKER, 2011; 2013): Editor do fluxo de trabalho baseado em web, sendo necessário apenas arrastar e soltar os componentes para modelagem do processo; Possui editor de formulários dinâmicos baseado em XML, com opção de edição em HTML e JavaScript, para criar as interfaces das tarefas humanas; Permite criação de documentos de saída personalizados em formato PDF ou DOC, criados no editor de páginas "WYSIWYG"; Permite criação de gatilhos, com código em PHP, para executar cálculos complexos e funções avançadas; Gerenciamento de usuário e grupos de usuários; Permite determinar o usuário ou o grupo de usuário responsável por cada tarefa do processo; Possui depurador de processo, permitindo verificar a execução das regras de negócio e o comportamento dos gatilhos antes de lançar o processo; Permite conexão com bancos de dados externos incluindo MySQL, PostgreSQL, Oracle e SQL Server; Possui Serviços Web para conectar-se com fontes de informação de terceiros; Possui integração com o software KnowledgeTree para adicionar a funcionalidade de gerenciamento de documentos; Possui integração com o software Zimbra para facilitar o correio e colaboração; Possui integração com o software OpenBravo para planejamento de recursos empresariais; Gerenciamento de tarefas pendentes e interface com o usuário final intuitiva tipo Caixa de entrada. O ProcessMaker possui uma versão gratuita que suporta todas as características mencionadas acima mas, não dá direito a suporte e garantias. A versão comercial fornece pacote com suporte técnico, além de outras funcionalidades como relatórios em tempo real e Dashboards BizAgi BizAgi é um software BPM (Business Process Management) [...] que permite automatizar os processos de negócio de forma ágil e simples em um ambiente gráfico intuitivo (NEXT, 2013, p. 1). Segue algumas das características deste software (BIZAGI, 2010): Utiliza notação padrão BPMN para modelagem dos processos de negócio;

6 Definição de forma gráfica do modelo de dados que o processo necessita para execução; Permite compartilhamento e reutilização dos modelos de dados entre vários processos; Criação de interfaces web, para atividades humanas, através de recursos que possibilitam desenhar os formulários arrastando e soltando objetos sem a necessidade de programação; Permite definir validações complexas; Fornece ambiente gráfico para definição de regras de negócio que serão seguidas durante a execução do processo; Permite alterar as regras de negócio em tempo real, diretamente no ambiente de produção; Permite definição de regras de atribuição das atividades aos participantes de acordo com cargos, conhecimentos, papéis entre outras, permitindo a alocação correta do trabalho; Integração dos processos de negócio com aplicações já existentes como, por exemplo, ERP e CRM; É uma solução baseada em SOA, por isso pode-se conectar-se ao processo, sem necessidade de programação, utilizando Web Services; Fornece portal de trabalho que permite aos usuários participantes dos processos visualizarem o trabalho pendente; Permite o acompanhamento de cada passo do processo, além de fornecer relatórios para monitoramento do negócio em tempo real. O BizAgi é uma ferramenta paga, mas possui módulo gratuito para modelagem do processo. Este módulo gratuito não é um BPMS, pois não automatiza o processo, apenas permite sua definição através da linguagem de modelagem BPMN (BIZAGI, 2013) BonitaSoft O BonitaSoft oferece recursos para criar, desenvolver, executar e monitorar os processos de negócios. Segue algumas das características deste software (BONITASOFT, 2013a): A modelagem do processo é feita em BPMN2; Permite atualização dos processos em execução, pois faz uma transição dos processos antigos para o novo modelo; Importação de modelos de processos definidos em BPMN2, JBPM3 e XPDL; Permite salvar e organizar todos os arquivos dos processos em um repositório central; Faz validação dos diagramas dos processos; Possui ferramentas e filtros integrados para permitir atribuição de tarefas a uma ou mais pessoas dinamicamente; Permite simular a execução do processo; Permite salvar e gerenciar versões dos processos; Permite gerar aplicativos de BPM autônomos (aplicativos baseados em processos totalmente operacionais); Configuração de múltiplos ambientes de execução, como desenvolvimento, teste, préprodução e produção; Definição de regras empresariais para fluxos de trabalho em tabelas de decisão, sem necessidade de codificação ou regras empresariais externas;

7 Personalização avançada de formulários da web com dependências de campos, preenchimento dinâmico de campos, paginação, regras de validação predefinidas, entre outros; Interface de usuário final intuitiva tipo "caixa de entrada"; Gerenciamento das instâncias dos processos em tempo real: suspender, retomar, entre outras; BAM e BI: estatísticas e relatórios; Monitoramento de atividades em tempo real; Gerenciamento de usuários e grupos internamente ou através de diretórios existentes (LDAP, AD, entre outros); Definição de privilégios detalhados para grupos de usuários; É um aplicativo leve, pronto para integração rápida em portais, internet, intranet e extranet existentes. O BonitaSoft possui uma versão gratuita, mas a aquisição de pacotes pagos agregam mais funcionalidade ao software (BONITASOFT, 2013b) jbpm O jbpm é um Business Process Management (BPM) Suite desenvolvido pela empresa JBoss. Seu motor de workflow é todo desenvolvido em Java. As principais características da última versão (5.4) são (JBOSS COMMUNITY, 2013c): Utiliza linguagem BPMN2 para modelagem dos processos de negócio; Possui editor baseado na ferramenta Eclipse e na Web para a criação gráfica do processo de negócio; As persistências e as transações são baseadas em JPA/JTA; O serviço de tarefas humanas é baseado em WS-HumanTask para incluir as tarefas que precisam ser realizadas por atores humanos; Possui console de gerenciamento das listas das tarefas humanas para apoiar a gestão do processo; Repositório de processos opcional para implantar os processos, através do Drools Guvnor; Controle de versão dos processos; Registro dos históricos dos processos para consulta, acompanhamento e análise; Permite integração com Seam, Spring, OSGi, entre outros; Definição e gerenciamento de regras de negócio, por meio do Drools. O jbpm 5.4 é integrado com outros projetos da jboss, assim como o Drools e o Drools Guvnor. Drools é uma plataforma integrada para regras de fluxos de trabalho e processamento de eventos (JBOSS COMMUNITY, 2013a). E o Drools Guvnor é um repositório para bases de conhecimento que possui editores e ferramentas para auxiliar na gestão das regras e processos de negócio (JBOSS COMMUNITY, 2013b). O jbpm, o Drools e o Drools Guvnor são ferramentas gratuitas Comparativo das ferramentas apresentadas A seguir faz-se um comparativo entre os BPMS apresentados (Quadro 1) com o objetivo de expor as diferenças entre elas e entre suas próprias versões (paga e gratuita). Os critérios estabelecidos para a comparação se originaram das características que, segundo Dávalos (2011), são consideradas padrões, ou seja, são características esperadas de um BPMS. Além destas características padrões, foram

8 incluídas outras características que facilitam a criação, o gerenciamento e a exceção dos processos ( Definição de usuário e grupo de usuário, Interface com usuário final (participantes do processo) e Editor de formulário dinâmico para interface de tarefas humanas ). Outro critério adicionado foi o Controle das versões dos processos, devido a sua relação com a melhoria no processo, pois permite que mesmo possa ser modificado. Segundo Xu e Ramesh (2008), construir um processo a partir do zero, sem adaptar os processos já existentes, é arriscado e envolve muito trabalho. A versão gratuita do BizAgi atende apenas as duas primeiras características do quadro comparativo: Utilização do padrão BPMN e Modelagem de processos de negócio. Esta versão não fora incluída no quadro comparativo, pois apenas permite a modelagem do processo, e por isto não considera-se esta versão um BPMS. Características/Software - Versão ProcessMaker BizAgi BonitaSoft jbpm 5.4 Paga Free Paga Paga Free Free Utiliza os padrões BPMN/BPEL X X X X Modelagem do processo de negócio X X X X X X Execução do processo X X X X X X Simulação do processo de negócio X X X X X X Integração com sistemas X X X X X X Monitoração em tempo real dos indicadores do processo X X X X Definição de regras de negócio X X X X X X Definição de usuário e grupo de usuário Interface com usuário final (participantes do processo) Editor de formulário dinâmico para interface de tarefas humanas X X X X X X X X X X X X X X X X X X Controle das versões dos processos?? X X X Quadro 1 Comparativos dos BPMS apresentados A primeira característica comparada é a adequação aos padrões de linguagens de modelagem e execução dos processos de negócio. Apenas o software ProcessMaker não atende esta característica, pois utiliza linguagem própria. Todos os softwares comparados permitem a modelagem, simulação e execução dos processos. É necessário que um BPMS contenha componentes que permitam a integração com outros sistemas como, por exemplo, os ERP s. Esta integração pode ser feita por meio de Web Services, JMS Java Message Servic, entre outras formas (DÁVALOS, 2011). Como observado, todos os softwares comparados permitem esta integração. A monitoração em tempo real dos indicadores dos processos é uma característica importante para o gerenciamento dos processos, por isso os BPMS devem possuir componentes de BAM (Business Activity Monitoring) ou integrar-se nativamente a um software deste tipo (DÁVALOS, 2011). Apenas as versões pagas dos softwares ProcessMaker, BizAgi e BonitaSoft proporcionam esta funcionalidade. Pode-se adicionar ao jbpm componentes de BAM e relatórios, por meio da instalação do JBoss BRMS 5.3 (SCHABELL, 2012), também gratuito.

9 Outro componente relevante, e atendido por todos os softwares comparados, é o BRM (Business Rules Management), no qual pode-se separar as regras do negócio, permitindo a definição das mesmas de forma separada do código da aplicação (DÁVALOS, 2011). As funcionalidades de Definição de usuário e grupos de usuários e Interface com o usuário final (participantes dos processos) também são atendidas por todos, conforme apresentado, bem como a criação de formulário para tarefas humanas de forma gráfica (arrastar e soltar). A funcionalidade de controle das versões dos processos, também conhecida como gerencia de configuração dos modelos de processos, refere-se ao fato da ferramenta permitir que haja várias versões de um mesmo modelo de processo de negócio. Ou seja, é possível alterar o modelo do processo sem interferir nos processos já instanciados anteriormente (executados ou em execução). Desta forma, mantém-se o histórico dos modelos dos processos, bem como, o de suas instâncias. O controle de versão possibilita a alteração do modelo do processo visando a sua melhoria, sem a necessidade de modelar o processo do início. O software jbpm gerencia as versões dos processos de forma automática. O BonitaSoft também permite a gerência de configuração dos processos, tanto na versão paga como na gratuita. Não fora possível verificar como este controle funciona na versão paga, mas na gratuita o controle das versões dos processos fica de responsabilidade do usuário, tendo este que alterar o número da versão manualmente antes de gerar o arquivo do processo para posteriormente importar no portal de trabalho. A versão gratuita do software ProcessMaker não controla as versões dos modelos dos processos. Podese incluir novas tarefas no processo, mas esta inclusão alterará os processos já executados ou em execução (a tarefa é incluída com o status de não executada ). Alterações que não possam ser modificadas nos processos executados/em execução não são permitidas, como, por exemplo, exclusão de tarefas. Quanto à versão paga do ProcessMaker e do BizAgi, não foram encontradas informações na documentação que evidenciassem a existência de mecanismos de controle de versões dos processos BPMS no contexto do desenvolvimento de software Os sistemas apresentados na seção anterior permitem definir, executar, controlar e monitorar um processo de negócio. Esta gerência, segundo Silva, Soares e Braga (2006, p. 1), ajuda os projetos de software a alcançar disciplina, controle e entendimento claro dos seus processos e atividades. A definição e gerenciamento dos processos possibilitam às empresas um melhor entendimento quanto aos seus processos, podendo assim, identificar problemas e buscar soluções para que os mesmos sejam mais produtivos e agreguem valor ao produto final. Segundo Mourão (2006, p.1), [...] o fato de podermos garantir que o passo a passo de cada processo aconteça da forma prevista na elaboração do processo e que esse acontecimento seja registrado na mesma granularidade em que o processo foi definido deve ser de grande impacto positivo na qualidade do software que está sendo construído pela sua influência em pelo menos três áreas críticas: monitoramento do processo, automatização de integrações e geração de medições. Os sistemas de gerenciamento de processos de negócio podem ser utilizados no âmbito do desenvolvimento de software, mas podem não proporcionar todo o auxílio necessário. O processo de desenvolvimento de software é complexo e suscetível a mudanças, sendo necessária grande flexibilidade por parte destes sistemas, além da necessidade de integração com diversas ferramentas relacionadas ao desenvolvimento. Neste contexto, existem os chamados PSEE, ambientes de engenharia de software centrados em processos. 5. Process-Centered Software Engineering Environments Com o objetivo de apoiar o processo de desenvolvimento de software, surgiu o conceito de SEE Software Engineering Enviroment, ambientes de engenharia de software (GIMENES; WEISS; HUZITA, 1998). Estes ambientes possuem propriedade importantes para integração de ferramentas e

10 suporte ao desenvolvimento das atividades de produções de software (GIMENES; WEISS; HUZITA, 1998, p. 26), desta forma, proporcionam apoio de forma integrada ao processo de desenvolvimento. A necessidade de se definir e controlar o processo de software ocasionou uma nova visão dos ambientes de engenharia de software (GIMENES; WEISS; HUZITA, 1998, p. 27). Visando apoiar também a gerência do processo de desenvolvimento, surgiram os PSEE - Process-Centered Software Engineering Environments, ambientes de engenharia de software centrados em processos. Estes ambientes além de proporcionarem as mesmas funcionalidades de um SEE, também auxiliam na gerência dos processos. Os PSEEs, segundo Silva, Soares e Braga (2006, p. 2), constituem um tipo especial de ambiente de desenvolvimento de software apoiando a definição rigorosa de processos de software e objetivando a automação da gerência do desenvolvimento. Estes ambientes contribuem para melhoria no desenvolvimento, e consequentemente no software. Pode-se dizer que estes ambientes permitem a gestão de processo, pois, proporcionam serviços para análise, simulação, execução e reutilização das definições de processos, que cooperam no aperfeiçoamento contínuo dos processos (SILVA; SOARES; BRAGA, 2006). Sendo assim, estes ambientes, apesar de serem desenvolvidos especialmente para apoiar o processo de desenvolvimento de software, podem ser classificados como BPMS. O processo de desenvolvimento de software possui suas particularidades que devem ser consideradas na criação de um software ou ambiente para apoiar este processo. Segundo LIMA (2006, p. 1), As soluções desenvolvidas nesta área devem levar em consideração elementos específicos do contexto de processos de software, tais como: o caráter criativo do processo, a grande tendência a mudanças, a impossibilidade de se reutilizar imediatamente processos executados e a falta de visibilidade do produto resultante. Com base nos elementos citados pelo autor, pode-se verificar a complexidade de um processo de desenvolvimento de software e a necessidade de flexibilidade para criação e execução dos processos. A seguir são relatados dois ambientes de engenharia de software centrados em processos: WebAPSSE e SPIDER-PE. Estes ambientes foram escolhidos por serem desenvolvidos a partir de iniciativas acadêmicas e estarem em constante evolução WebAPSEE O WebAPSEE é um Ambiente de Desenvolvimento de Software Centrado em Processo (PSEE) desenvolvido como software livre pelo Laboratório de Engenharia de Software da Universidade Federal do Pará (LABES-UFPA, 2013). Seu desenvolvimento iniciou no ano de 2004, e vem sendo aprimorado através de pesquisas e trabalhos acadêmicos. Segue algumas das funcionalidades deste ambiente (SALES ET AL, 2010b): Manutenção de habilidades, papéis, recursos humanos (agentes), materiais, grupos, ferramentas, artefatos, sistemas, organizações (a própria empresa e os clientes) e hierarquia de tipos, de forma a possibilitar a gerência da organização; Modelagem de processos de forma gráfica, por meio de linguagem própria chamada WebAPSEE-PML (REIS, 2003); Permite executar processos parcialmente definidos (REIS, 2003), mesmo que alguns componentes estejam faltando, como atividades, conexões e detalhes de alocação (COUTINHO, 2011, p. 18). Esta funcionalidade possibilita ao gerente iniciar a execução de um processo enquanto decide como uma atividade futura será realizada (SALES ET AL, 2010b, p. 2);

11 Definição, implantação e execução de processo; Oferece flexibilidade durante a execução do processo. Segundo Coutinho (2011, p. 18), O ambiente permite que o processo seja modificado em tempo de execução, adicionando e removendo atividades, conexões, pessoas, recursos e artefatos, por exemplo. ; Controle e monitoração de projetos através de editor gráfico, onde são exibidas as atividades do processo e seus status; Possibilita o acompanhamento em tempo real dos projetos, além de permitir e controlar modificações na estrutura do processo dinamicamente; Possui integração com as ferramentas CVS e SubVersion, para permitir a gerência de configuração dos artefatos (controle de versões) gerados durante as execuções dos processos; Permite medir e analisar um projeto a partir de definições de métricas e de coletas de estimativas e medidas associadas a alguns componentes gerenciados pelo ambiente (Agentes, Artefatos, Atividades, Grupos,, Projetos e Recursos) (SALES ET AL, 2010b, p. 5); Possui agenda de tarefas para os participantes dos processos, onde o participante pode: iniciar, pausar, finalizar ou delegar uma atividade a outro participante. Esta agenda de tarefas possibilita a gerência integrada dos projetos; Possui módulo de apoio ao Gerenciamento de Requisitos (GRE) totalmente integrado, chamado WebAPSEE Requirement Manager (WARM). Este módulo possibilita gerenciar: requisitos, casos de uso, rastreabilidade, mudanças de requisitos (registro de mudanças e gerenciamento de versões dos mesmos), Baselines de requisitos, além de permitir visualizar árvore de impacto e emitir relatórios; Apoia a gerência de conhecimento por meio da ferramenta WebAPSEE Knowledge Manager (WKM), de forma flexível e integrada (LIMA, 2010). A versão 2.0 deste ambiente está em desenvolvimento, a qual poderá ser acessada através da internet. A versão 1.8 (desktop) já possui módulo web para agenda de tarefas do desenvolvedor (COUTINHO, 2011). Mas, apenas a versão 1.5 está disponível para download no site do LABES-UFPA SPIDER-PE A ferramenta SPIDER-PE (Process Enactment) é uma solução para apoiar a execução dos processos de desenvolvimento de software de forma flexível e semi-automatizada (SILVA ET AL, 2012). Esta ferramenta faz parte do projeto SPIDER (SoftwareProcess Improvement: DEvelopment and Research), desenvolvido na Universidade Federal do Pará (SPIDER, 2009). Esta ferramenta visa atender aos modelos de qualidade CMMI-DEV e MR-MPS (SILVA ET AL, 2012). O SPIDER-PE em conjunto com outras ferramentas livres, algumas dessas também desenvolvidas no projeto SPIDER, proporcionam um ambiente de apoio ao processo de desenvolvimento de software, buscando sempre atender aos modelos de qualidade CMMI-DEV e MR-MPS. Segue algumas das características fornecidas por este suite de ferramentas (SILVA ET AL, 2012): Estabelece cinco fases para o ciclo de vida do processo: Definição, Simulação, Execução, Avaliação e Melhoria do processo; A definição e modelagem do processo é realizada por meio da ferramenta Spider-PM, utilizando linguagem de modelagem própria, denominada de SPIDER_ML, que caracteriza-se como um perfil da linguagem de modelagem padrão SPEM; Simulação do processo, permitindo que sejam encontrados problemas antes do mesmo ser executado;

12 A execução do processo é realizado por meio da linguagem xspider_ml (executable SPIDER_ML), também própria do projeto SPIDER; O modelo do processo é representado graficamente; Apoia a gestão de mudanças, por meio da utilização da ferramenta SVN (Subversion); Provê apoio às atividades de planejamento e monitoramento do processo; Permite definir o usuário que será o gerente do processo a ser executado; Permite definir e publicar uma política organizacional, estabelecendo diretrizes e responsabilidades; Realização de estimativa de esforço para a execução das atividades do processo, por meio das ferramentas: Spider-UCP, Spider-APF e Spider-CoCoMo; Definição do cronograma de tarefas e do processo como um todo, baseado na estimativa de esforço; Apoio a gerência de riscos; Proporciona apoio para identificação de necessidades de capacitação e treinamentos; Gerenciamento de recursos e responsabilidades: definição e alocação no projeto; Permite definir um plano de comunicação; Permite identificar, registrar e monitorar (através da ferramenta Redmine) os possíveis problemas que venham a surgir durante a execução do projeto (SILVA ET AL, 2012, p. 9); Permite a avaliação dos produtos de trabalho e dos processos. Esta avaliação é realizada pela ferramenta Spider-CL, com base em critérios objetivos, descritos em checlists; Possibilita definir métodos de monitoramento e controle. É possível definir, coletar, analisar e acompanhar medidas, proporcionando apoio ao processo de medição através da ferramenta Spider-MPlan; Apoia a gerência de requisitos por meio da integração com a ferramenta OSRMT (Open Source Requeriments Management Tool) (BRITO; BENTES, 2009). Segundo Silva et al (2012), a funcionalidade de execução do processo ainda está em desenvolvimento no laboratório do Projeto SPIDER. O Spider-PE é um software livre (sob licença GPL General Public License) desenvolvido em ambiente desktop (SILVA ET AL, 2012) Comparativo As duas ferramentas apresentadas possuem o mesmo objetivo: provê auxilio ao processo de desenvolvimento de software, de modo que o mesmo possa ser gerenciado de forma flexível através da definição, simulação, execução, acompanhamento, monitoração, avaliação e implementação de melhorias no processo. A ferramenta SPIDER-PE foi desenvolvida para apoiar a execução do processo de software e integrada a outras ferramentas do projeto SPIDER e outros softwares livres forma um suite de ferramentas para proporcionar o ambiente necessário para o auxílio ao processo de desenvolvimento de software. A ferramenta WebAPSEE já é um PSEE por si só, e outras ferramentas como o WebAPSEE Requirement Manager e WebAPSEE Knowledge Manager são módulos que agregam mais funcionalidade a este ambiente.

13 Os dois ambientes trabalham com linguagens de modelagem de processos própria. Segundo Silva et al (2012), a linguagem SPIDER_ML utilizada pelas ferramentas do projeto SPIDER é uma adaptação da linguagem SPEM, considerada um padrão de modelagem de processos de software. Já a linguagem WebAPSEE-PML, utilizada no WebAPSEE não segue nenhum padrão e não expõem de forma explícita a aderência a modelos de qualidade (SILVA ET AL, 2012). As duas ferramentas permitem flexibilidade na definição e execução do processo, além de apoiarem a gestão de mudanças dos mesmos, gerenciando as versões dos processos e permitindo a melhoria contínua. As duas também fornecem um módulo de agenda de tarefas, permitindo que os participantes do processo interajam com o mesmo. Cadastros de pessoas com associação a papéis, responsabilidades e habilidades, relacionamento de pessoas e recursos às atividades dos processos, delegação de funções/tarefas e estimativa de duração/esforço por atividade do processo também são contempladas pelos dois ambientes. O gerenciamento de requisitos de forma integrada também é atendido pelos dois ambientes, mas o ambiente do projeto SPIDER atende a mais áreas do gerenciamento de projetos do que o WebAPSEE, pois fornece maior apoio as atividades de planejamento, como a definição de políticas e diretrizes, realização de estimativas de esforço com base em técnicas como UCP, FPA e CoCoMo, definição de cronograma de atividades e plano de comunicação, além de apoiar a gestão de riscos. A ferramenta SPIDER-PE define cinco fases distintas para o ciclo de vida do processo: definição, simulação, execução, avaliação e melhoria do processo. As mesmas devem ser seguidas, desta forma todo processo passa por uma avaliação, para depois aplicar-se as melhorias necessárias. Assim, pode-se relatar que o ambiente SPIDER é mais completo, abrangendo mais áreas de gerenciamento de projetos e atendendo a níveis mais elevados de maturidade de processos. O ambiente WebAPSEE é mais simples e atende ao nível G do modelo de maturidade de processos do MR-MPS (SALES ET AL, 2010a). Vale ressaltar que a execução dos processos no SPIDER-PE ainda está em desenvolvimento. 6. Considerações sobre BPMS e PSEE A notação BPMN pode ser utilizada para modelagem do processo de desenvolvimento de software quando trata-se o mesmo como um processo de negócio fugindo da abordagem tradicional e permitindo sua integração com os demais processos da organização. A escolha quanto a qual notação utilizar, depende da necessidade de cada empresa. A utilização de sistemas de gerenciamento de processos de negócio pode contribuir para a melhoria do processo de software, sendo que estes sistemas permitem a definição, acompanhamento e monitoração dos processos. Além de garantir que o processo seja executado como o previsto, pode-se através dos históricos dos processos fazer uma análise e encontrar melhorias para o mesmo. Por meio da apresentação de alguns BPMS pôde-se constatar as semelhanças existentes entre estes sistemas, ou seja, eles atendem a maioria das funcionalidades consideradas padrões destes sistemas. Algumas características variam de acordo com a ferramenta e versão (comercial ou gratuita), desta forma cada empresa deve fazer um balanço entre os critérios que considera mais relevantes para o seu negócio. Ainda com base no comparativo, foi possível verificar que nem todas as ferramentas permitem que o processo possa ser alterado, sendo necessário criá-lo do início caso haja uma melhoria/alteração no mesmo. Isto torna-se uma atividade trabalhosa e muito arriscada quando trata-se de processos de desenvolvimento de software, pois o mesmo é um processo complexo e sofre constantes mudanças. As necessidades de flexibilidade e maior auxílio relacionado ao processo de desenvolvimento de software são supridas nos ambientes de engenharia de software centrados em processos (PSEE). Estes por sua vez, são desenvolvidos com esse intuito, o que os tornam mais adequados para a automação e gerenciamento do processo de software, mas não abrangem os demais processos da empresa, não permitindo uma integração entre os processos existentes.

14 7. Norma ABNT ISO/IEC A maioria das normas de qualidade em processos de software, como o CMMI e MPS.BR, não estão de acordo com as necessidade das micro organizações, sendo difícil, senão impossível, para estas empresas se adequarem. Visando atender as necessidades das micro e pequenas empresas desenvolvedoras de software, foi criada a série ISO/IEC Esta norma foi publicada no Brasil pela ABNT, em A norma ABNT ISO/IEC foi desenvolvida com objetivo de proporcionar melhoria na qualidade do produto e/ou serviço de software, além do desempenho do processo de empresas com até 25 funcionários (ABNT, 2012a). A série ISO/IEC é um instrumento que pode propiciar às micro e pequenas empresas (MPE) desenvolvedoras de produtos e serviços de software ter um processo produtivo de maior qualidade e, com isso, aumentar a satisfação dos seus clientes, sua competitividade e sua capacidade de acessar novos mercados (ABNT; SEBRAE, 2012, p. 7). A série de normas contém elementos mínimos que são necessários para que as micro e pequenas empresas desenvolvedoras de software construam produtos e/ou serviços de software mais confiáveis, previamente definidos, com um menor número de erros, no menor prazo possível e dentro dos custos planejados (ABNT; SEBRAE, 2012, p. 9). Esta série de normas deve contemplar dois grupos de perfis: o Genérico, referente às empresas de desenvolvimento de software genérico, e o SE (System Engineering), referente às empresas desenvolvedoras de softwares e sistemas integrados. Cada grupo terá quatro perfis: entrada, básico, intermediário e avançado. Atualmente, apenas o perfil básico do grupo genérico foi elaborado. O perfil básico do grupo genérico se resume a dois processos: gerência de projetos e implementação de software, que interagem entre si e abrangem as principais atividades executadas por uma empresa durante o ciclo de vida de desenvolvimento de software (ABNT; SEBRAE, 2012, p. 24). Cada processo possui um conjunto de atividades que precisam ser realizadas e objetivos que devem ser alcançados. Ao final dos processos, um conjunto de artefatos deve ter sido gerado. O processo de Gerência de Projetos tem por propósito estabelecer e realizar de forma sistemática as tarefas do projeto de implementação de software, que permitem cumprir os objetivos do projeto na qualidade, tempo e custo esperados (ABNT, 2012b, p. 4). Este processo é composto pelas atividades de Planejamento do Projeto, Execução do Plano de Projeto, Avaliação e Controle do Projeto e Encerramento do Projeto. O processo de Implementação de Software visa a execução sistemática das atividades de análise, design, construção, integração e testes para produtos de software novos ou modificados de acordo com os requisitos especificados (ABNT, 2012b, p. 4). As atividades de Início da Implementação do Software, Análise de Requisitos do Software, Projeto de Arquitetura e Detalhamento do Software, Construção do Software, Integração e Testes de Software e Entrega do Produto compõem este processo. Vinte e dois artefatos são considerados necessários pelo perfil básico do grupo genérico da norma ABNT ISO/IEC , para que haja uma qualidade no processo: - Declaração de trabalho; - Plano de projeto; - Repositório do projeto; - Registro de reunião;

15 - Backup do repositório do projeto; - Registro de status de progresso; - Registro de correção; - Solicitação de mudança; - Resultados da verificação; - Resultados da validação; - Especificação de requisitos; - Projeto (design) de software; - Casos de testes e procedimentos de testes; - Registro de rastreabilidade; - Relatório de testes; - Componente de software; - Software; - Configuração de software; - Guia de operação do produto; - Documentação de manutenção; - Documentação de usuário de software; - Registro de aceitação. Com base nesta norma foi elaborada uma pesquisa com as micro e pequenas empresas da região do Alto Vale do Itajaí, com o objetivo de verificar a situação destas em relação ao perfil básico do grupo genérico da norma ABNT ISO/IEC Outro trabalho realizado em paralelo com a pesquisa foi a elaboração do processo da Norma em BPMN, com o objetivo de auxiliar as empresas em sua adequação. Foram pesquisados e elaborados templates dos artefatos exigidos pela Norma e anexados aos processos Pesquisa realizada com as empresas da região do Alto Vale do Itajaí Nesta seção é abordada a pesquisa realizada com as micro e pequenas empresas da região do Alto Vale do Itajaí. São apresentados os objetivos, metodologia de pesquisa, bem como os resultados desta Objetivo Realizar um levantamento da situação atual das micro e pequenas empresas da região do Alto Vale do Itajaí - SC em relação ao perfil básico do grupo genérico da norma ABNT ISO/IEC 29110, verificando se as mesmas executam os processos definidos pela norma, alcançam os objetivos, realizam todas as atividades dos processos e produzem os artefatos obrigatórios Metodologia de pesquisa Como escopo geográfico definiu-se os municípios participantes das SDRs (Secretarias de Desenvolvimento Regional) de Ibirama, Rio do Sul e Timbó, totalizando 39 municípios. Das empresas localizadas nesta região foram selecionadas apenas as empresas de desenvolvimento de software que se encaixam no perfil de micro e pequenas organizações, ou seja, com até 25 funcionários.

16 As empresas desta região já haviam sido catalogadas na pesquisa realizada no período de 01/08/2011 a 30/03/2012 do projeto de pesquisa Mapeamento de empresas de desenvolvimento de software da região do Alto Vale do Itajaí (SC) em relação à melhoria de processo 4 feita pelo Grupo de Pesquisa Engenharia e Desenvolvimento de Tecnologia da Informação do Centro de Educação Superior do Alto Vale do Itajaí (CEAVI) da Universidade do Estado de Santa Catarina (UDESC). Com o escopo definido, obteve-se um público alvo de 36 empresas. O questionário foi enviado para o público alvo, durante o período de 12/04/2013 a 06/06/2013, e foram obtidas respostas de 23 empresas. Foi utilizado o método de pesquisa survey, o qual caracteriza-se pela obtenção de dados ou informações sobre características, ações ou opiniões de determinado grupo de pessoas, indicando como representante de uma população-alvo, por meio de um instrumento de pesquisa, normalmente um questionário (FREITAS ET AL, 2000, p. 105). Kasunic (2005) define esta abordagem de pesquisa como um processo de sete etapas: Identificar os objetivos da pesquisa; Identificar e caracterizar o público-alvo; Estabelecer o plano de amostragem; Definir o questionário; Realizar teste-piloto do questionário; Distribuir o questionário; Analisar os resultados e escrever um relatório. O questionário foi elaborado com base na Norma ISO/IEC (processos, objetivos, atividades e artefatos) e enviado às empresas da região por meio do software LimeSurvey 5, ferramenta que permite automatizar pesquisas do tipo survey possibilitando o gerenciamento online de respondentes, questionários e repostas Resultados Os resultados obtidos com a pesquisa estão organizados nos seguintes grupos: - Visão geral; - Planejamento do Projeto; - Execução do Projeto; - Avaliação e Controle do Projeto; - Início da Implementação do Software; - Análise de Requisitos do Software; - Projeto de Arquitetura e Detalhamento do Software; - Construção do Software; - Integração e Testes de Software; - Registros de Rastreabilidade; 4 Ferrari; Schoeffel; Sevegnani (2012). 5 Maiores informações sobre o LimeSurvey, bem como o próprio sistema podem ser obtidos em:

17 - Baseline; - Elaboração de Manuais e Guias; - Entrega do Produto e Encerramento do Projeto. Os grupos foram definidos desta forma para obter-se uma melhor comparação com a Norma ABNT ISO/IEC Visão geral Inicialmente, foram realizadas perguntas de âmbito geral, com o objetivo de proporcionar um panorama inicial sobre as empresas participantes e seus processos de desenvolvimento de software Conhecimento e aplicação da Norma ABNT ISO/IEC Esta questão teve por objetivo saber como anda o conhecimento e aplicação da norma ABNT ISO/IEC nas micro e pequenas organizações da região. Por meio desta pode-se verificar que a maioria das empresas (74%) nem possuem conhecimento sobre a Norma, enquanto uma minoria de 4% além de conhecer busca adequar-se à norma, conforme apresentado na Tabela 1 e no gráfico da Figura 1. Quantidade Percentual Não conheço % Sim, conheço, mas não aplicamos % Sim, conheço e buscamos nos adequar % Outros* % Total % Tabela 1 Conhecimento e/ou aplicação das diretrizes da Norma ABNT ISO/IEC * Outros: Não conheço plenamente, apenas a li uma vez e estou adquirindo a norma via SEBRAE, e deve chegar nesta semana. 4.35% 4.35% 17.39% Não conheço. Sim, conheço, mas não aplicamos. Sim, conheço e buscamos nos adequar. Outros 73.91% Figura 1 Gráfico relacionado ao conhecimento e aplicação de norma ABNT ISO/IEC funcionários Outra questão levantada foi a quantidade de funcionários da organização, para fins de adequação ao perfil da norma. Lembrando que a série ISO/IEC se destina às micro e pequenas organizações, sendo estas definidas por possuírem até 25 funcionários. Como apresentado na Tabela 2 e no gráfico da Figura 2, a maioria das empresas (43%) possui um quadro de até 5 colaboradores.

18 Quantidade Percentual Até 5 funcionários % De 6 a % De 11 a % De 16 a % De 21 a % Total % Tabela 2 funcionários da organização 4% 13% 17% 43% Até 5 funcionários De 6 a 10 De 11 a 15 De 16 a 20 De 21 a 25 22% Figura 2 Gráfico de quantidade de funcionários na organização Fluxo de trabalho: definição de escopo e prazo dos projetos Quanto ao fluxo de trabalho das empresas, buscou-se entender como as mesmas trabalham em relação aos esforços realizados para produção de um produto ou serviço, questionando a organização em relação os trabalhos realizados, se estes são tratados como projeto, sendo estipulado no início o seu escopo e prazo. Sendo que um projeto é um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo (PMI, 2004, p. 5), pode-se dizer que para os esforços da empresa serem considerados projetos, estes devem ter datas de início e fim. O escopo delimita o que será desenvolvido no projeto, ajudando a definir o fim do projeto, ou seja, quando ele será considerado realmente concluído. Observando a Tabela 3 e a Figura 3, é possível verificar que apenas 39% das empresas definem escopo e prazo para os projetos realizados e 22% não buscam gerenciar seus esforços como projetos. Percentual Não existe conceito de projeto, as atividades são desenvolvidas conforme a demanda. 5 22% O escopo e o prazo são bem definidos no início de cada projeto. 9 39% Somente é definido o escopo no início de cada projeto. 6 26% Somente são definidos os prazos no início de cada projeto. 3 13% Total % Tabela 3 Fluxo de trabalho na organização

19 13% 22% Não existe conceito de projeto, as atividades são desenvolvidas conforme a demanda. 26% O escopo e o prazo são bem definidos no início de cada projeto. Somente é definido o escopo no início de cada projeto. 39% Somente são definidos os prazos no início de cada projeto. Figura 3 Gráfico do fluxo de trabalho na organização Ciclo de vida do desenvolvimento de software Apesar da norma ABNT ISO/IEC não destinar-se a um ciclo de vida de desenvolvimento específico, podendo ser utilizada em qualquer abordagem ou metodologia de desenvolvimento, como cascata, iterativo e incremental, evolutivo, ágil, entre outros (ABNT, 2012a; ABNT, 2012b), é importante que se tenha um ciclo definido, gerando assim organização ao processo de desenvolvimento. Esta questão buscou identificar os ciclos de vida utilizados nas empresas pesquisadas. A Tabela 4 e a Figura 4 apresentam os resultados desta questão, podendo-se verificar que o ciclo de vida de desenvolvimento mais utilizado é o Iterativo e Incremental, com 57% das empresas, e uma minoria de 9% não sabe o que é um ciclo de vida de desenvolvimento de software. Percentual Modelo em Cascata. 6 26% Iterativo e incremental % Não sei do que se trata. 2 9% Outros*. 2 9% Total % Tabela 4 Ciclo de vida do desenvolvimento de software *Outros: Depende do projeto, geralmente iterativo e incremental e Nós não desenvolvemos sistema só implantamos e adequamos. 9% 9% 26% Modelo em Cascata. Iterativo e incremental. Não sei do que se trata. Outros. 57% Figura 4 Gráfico do ciclo de vida do desenvolvimento na região

20 Principal atividade Esta questão busca identificar quais são as principais atividades de desenvolvimento de software realizadas pelas micro e pequenas organizações da região. Como observado na Tabela 5, grande parte das empresas (52%) desenvolvem software padrão com customização. A atividade de desenvolvimento de software sob encomenda e a distribuição e edição de softwares de terceiros estão juntas, em segundo lugar, com 13% das empresas. A Figura 5 apresenta o gráfico deste resultado, proporcionando uma melhor visualização. Percentual A empresa desenvolve serviços para serem incorporados/integrados com outros serviços/produtos. 1 4% A empresa desenvolve pacote de software sem customização. 2 9% Desenvolve softwares padrão com customização para clientes % Desenvolve softwares sob encomenda. 3 13% A empresa distribui e edita softwares de terceiros. 3 13% Outros. 2 9% Total % Tabela 5 Principal atividade no desenvolvimento de software Outros: Websites e e-commerce e em branco. 13% 9% 4% 9% A empresa desenvolve serviços para serem incorporados/integrados com outros serviços/produtos. A empresa desenvolve pacote de software sem customização. Desenvolve software padrão com customização para clientes. 13% Desenvolve software sob encomenda. A empresa distribui e edita softwares de terceiros. 52% Outros. Figura 5 Gráfico das principais atividades no desenvolvimento de software Documento de Declaração de trabalho A norma ABNT ISO/IEC define como artefato obrigatório a Declaração de Trabalho. Este documento caracteriza um pedido de trabalho solicitado à empresa pelo Cliente. Uma Declaração de Trabalho descreve o trabalho a ser realizado relacionado ao desenvolvimento de software, podendo estar incluso a descrição do produto com objetivos e requisitos gerais, definição de escopo e lista de entregáveis (partes do software) a serem liberados ao cliente (ABNT, 2012b). O contrato apenas

21 formaliza o aceite e compromisso assumido pelo cliente e pela empresa. Diante disto, questionou-se a utilização destes documentos (Declaração de Trabalho e contrato ou acordo) nas empresas. A resposta inserida em outros relata que na empresa Existe um contrato, assinado pelo cliente com uma descrição sucinta do trabalho, deste modo, pode-se dizer que mais da metade das empresas (65%) possuem Declaração de Trabalho, mesmo que superficial. E, 61% das empresas formalizam o negócio com o cliente por meio de um contrato ou acordo assinado. Este resultado pode ser visualizado na Tabela 6 e no gráfico apresentado na Figura 6. Percentual Existe um contrato ou acordo com Declaração de Trabalho (detalhada) assinado pelo Cliente % Existe Declaração de Trabalho, mas o acordo não é formalizado, ou seja, não é assinado pelo cliente (apenas acordo verbal). 2 9% Existe Declaração de Trabalho, mas é incompleta ou superficial (não possui detalhes do escopo do projeto). 1 4% Existe um contrato ou acordo, mas sem uma Declaração de Trabalho. 2 9% Não existe contrato ou acordo, nem Declaração de Trabalho. 6 26% Outros. 1 4% Total % Tabela 6 Utilização de Declaração de Trabalho e Contrato ou acordo 4% 26% 48% 9% Figura 6 Gráfico de utilização da Declaração de Trabalho Planejamento do Projeto 4% 9% Existe um contrato ou acordo com Declaração de Trabalho assinado pelo Cliente. Existe Declaração de Trabalho, mas o acordo não é formalizado. Existe Declaração de Trabalho, mas é incompleta ou superficial. Existe um contrato ou acordo, mas sem uma Declaração de Trabalho. Não existe contrato ou acordo, nem Declaração de Trabalho. Outros. No planejamento de um projeto, podendo este ser o desenvolvimento de um novo software, uma manutenção, uma customização, etc., são identificadas as tarefas que serão executadas durante o projeto, calculadas estimativas de custo, identificados riscos que podem afetar o projeto, dentre outras

22 atividades. Este grupo de questões objetivou conhecer se é realizado e como é realizado o planejamento, mesmo que de modo informal, pelas empresas da região. A realização da atividade Planejamento de Projeto, pertencente ao processo Gerência de Projeto e é considerada obrigatória pela norma Práticas realizadas durante o planejamento do Projeto As tarefas de revisão da Declaração de trabalho, definição da equipe do projeto, atribuições de papéis e responsabilidades, além de realizações de reuniões com o cliente, e registro destas reuniões, devem ser realizadas durante o Planejamento do Projeto. A Tabela 7 traz os resultados da questão levantada sobre a realização destas tarefas. A revisão da Declaração de trabalho é realizada por 43% das empresas. Sendo que apenas 65% possuem Declaração de trabalho, 67% destas empresas revisam a Declaração de trabalho junto com o cliente. Conforme a norma, as reuniões realizadas devem ser registradas gerando um registro de reunião. Este documento é artefato requerido e considerado obrigatório pela norma. Observou-se que 30% das empresas elaboram este documento em reuniões realizadas com o cliente. Percentual É realizada uma revisão da Declaração de Trabalho junto com o cliente para planejar a execução do projeto % Reuniões realizadas com o Cliente são registradas. 7 30% A equipe do projeto é definida antes da execução do projeto. 9 39% Atribui-se papéis e responsabilidades para cada integrante da Equipe do Projeto % Não são realizadas nenhumas das atividades citadas. 3 13% Tabela 7 Práticas realizadas durante o planejamento do Projeto A definição prévia dos integrantes que participarão do projeto é realizada por 39% das empresas. Apesar de algumas empresas não definirem a equipe do projeto no planejamento, 57% atribuem papéis e responsabilidades aos integrantes e 13% das empresas não realizam nenhumas destas atividades. Na Figura 7 é apresentado o gráfico dos resultados desta questão.

23 13% 57% 39% 30% 43% 0% 10% 20% 30% 40% 50% 60% Não são realizadas nenhuma das atividades citadas. Atribui-se papéis e responsabilidades para cada integrante da Equipe do Projeto. A equipe do projeto é definida antes da execução do projeto. Reuniões realizadas com o Cliente são registradas. É realizada uma revisão da Declaração de Trabalho junto com o cliente para planejar a execução do projeto. Figura 7 Gráfico de práticas realizadas durante o planejamento do Projeto Identificação de tarefas a serem realizadas No planejamento do projeto é necessário identificar todas as tarefas necessárias para produzir os Entregáveis identificados na Declaração de Trabalho. Deve-se identificar não apenas as tarefas de implementação, mas também as tarefas verificação e validação (para garantia de qualidade dos produtos e/ou serviços), tarefas que envolvam o Cliente e/ou Equipe do projeto como, por exemplo, reuniões, além das tarefas para realizar as entregas (ABNT, 2012b). Uma minoria de 4% das empresas não identifica nenhuma tarefa, não podendo fazer nenhum outro tipo de planejamento concreto. As demais empresas identificam ao menos um ou mais tipos de tarefas, que devem ser realizadas, para depois poder planejar a sua execução (duração, recursos necessários, etc.). O resultado detalhado das tarefas identificadas pelas empresas está relatado na Tabela 8, e graficamente apresentado na Figura 8. Percentual Atividades de gestão do projeto. 9 39% Atividades de análise e especificação do projeto % Atividades de implementação do software % Atividades de verificação. 6 26% Atividades de validação. 9 39% Atividades que envolvam o Cliente % Atividades de revisões das atividades da Equipe do projeto. 4 17% Atividades para realizar a(s) entrega(s) % Não são identificadas previamente as tarefas que deverão ser executadas. 1 4% Tabela 8 Identificação de tarefas a serem realizadas

24 70% 60% 65% 61% 65% 50% 40% 39% 39% 43% 30% 20% 26% 17% 10% 0% 4% Atividades de gestão do projeto. Atividades de análise e especificação do projeto. Atividades de implementação do software. Atividades de verificação. Atividades de validação. Atividades que envolvam o Cliente. Atividades de revisões das atividades da Equipe do projeto. Atividades para realizar a(s) entrega(s). Não são identificadas previamente as tarefas que deverão ser executadas. Figura 8 Gráfico das tarefas identificadas pelas empresas Com relação ao registro das tarefas identificadas, 43% das empresas registram apenas algumas das tarefas identificadas, e 13% registram todas as tarefas identificadas. A Tabela 9 apresenta estes resultados e a Figura 9 o representa graficamente. Percentual Todas as atividades identificadas são registradas % Algumas das atividades identificadas são registradas % Tabela 9 Registro das tarefas identificadas 43,48% 13,04% 43,48% Todas as atividades identificadas são registradas. Algumas das atividades identificadas são registradas. Não registram ou não identificam as tarefas. Figura 9 Gráfico do registro das tarefas identificadas

25 Estimativas de esforço e duração do projeto e/ou das tarefas do projeto Com relação à estimativa de esforço e duração do projeto e/ou das tarefas a serem realizadas, apenas 13% das empresas não calcula nenhuma estimativa de esforço e/ou duração. As demais (87%) realizam algum tipo de cálculo de estimativa (esforço e/ou duração), sendo por técnicas formais como UCP, FPA, COCOMO, Wideband Delphi, Planning Poker, entre outras, ou baseado na opinião de um ou mais especialistas sem o uso de processo ou técnica formal. A Tabela 10 traz em detalhes os resultados desta questão, e a Figura 10 apresenta o gráfico correspondente. O percentual total desta questão passa de 100%, pois 22% das empresas realizam tanto estimativa formal, quanto baseada em especialistas. É calculada estimativa de esforço e duração baseada em algum processo ou técnica formal (UCP, FPA, COCOMO, Wideband Delphi, Planning Poker, etc.). É calculada estimativa de esforço e duração baseado na opinião de um ou mais especialistas sem o uso de processo ou técnica formal. Percentual 2 9% 13 57% É calculada somente duração e não o esforço em homem/hora % Não são calculadas. 3 13% Tabela 10 Cálculo de estimativa de esforço e duração do projeto e/ou das atividades do projeto 60% 57% 43% 30% 0% 9% Figura 10 Gráfico da realização de cálculo de estimativa de esforço e duração Estimativa de custo As Tabelas 11 e 12 apresentam os resultados da questão relacionada à estimativa de custo do Projeto. 9% das empresas não faz estimativa de custo para o projeto, 61% apenas faz uma suposição dos custos baseado no tempo/escopo/equipe do projeto e 39% calcula o custo com base nas atividades e esforço/duração (Tabela 11). A Figura 11 ilustra os valores da Tabela 11. Percentual Os custos do projeto são calculados baseados nas atividades e esforço/duração. 9 39% Apenas é feito uma suposição dos custos baseado no tempo/escopo/equipe do projeto % Não é calculada. 2 9% Total % Tabela 11 Estimativa de custo 13% É calculada estimativa de esforço e duração baseada em algum processo ou técnica formal. É calculada estimativa de esforço e duração baseado na opinião de um ou mais especialistas sem o uso de processo ou técnica formal. É calculada somente duração e não o esforço em homem/hora. Não são calculadas.

26 9% 61% 39% 0% 10% 20% 30% 40% 50% 60% 70% Não é calculada. Apenas é feito uma suposição dos custos baseado no tempo/escopo/equipe do projeto. Os custos do projeto são calculados baseados nas atividades e esforço/duração. Figura 11 Gráfico da realização de estimativa de custo O registro da estimativa de custo é realizado por 30% das empresas e uma minoria de 4%, além de fazer um cálculo de estimativa de custo, também cria um cronograma de desembolso do projeto (Tabela 12). Uma das empresas que atualmente faz apenas uma suposição do custo informou que já está iniciando com as estimativas, para posterior comparação com o real, para obtermos um parâmetro para futuras medições. A Figura 12 apresenta o gráfico destes resultados. Percentual A estimativa é registrada. 7 30% É gerado um cronograma de desembolso. 1 4% Outros. 1 4% Tabela 12 Outras práticas relacionadas à estimativa de custo Outros: Estamos iniciando com as estimativas, para posterior comparação com o real, para obtermos um parâmetro para futuras medições. 4% 4% 30% 0% 5% 10% 15% 20% 25% 30% 35% Outros. É gerado um cronograma de desembolso. A estimativa é registrada. Figura 12 Gráfico de outras práticas relacionadas à estimativa de custo

27 Identificação de necessidade e planejamento de treinamentos Nas Tabelas 13 e 14 são apresentados os resultados da questão relacionada à identificação e planejamento de treinamentos necessário para a equipe do projeto. Como observado na Tabela 13, mais da metade das empresas (70%) verifica a necessidade de treinamento ainda no planejamento e 26% das empresas, além de verificar a necessidade de treinamento, realizam o seu planejamento criando um calendário dos treinamentos com definições das datas e pessoas participantes (Tabela 14). Percentual Verifica-se se existe a necessidade de treinamento % A necessidade de treinamento não é verificada no planejamento. 7 30% Total % Tabela 13 Identificação de necessidade de treinamentos 30% 70% Verifica-se se existe a necessidade de treinamento. A necessidade de treinamento não é verificada no planejamento. Figura 13 Gráfico de identificação de necessidade de treinamento Percentual Os treinamentos identificados são registrados. 4 17% É criado um calendário dos treinamentos com definição das datas e pessoas participantes. 6 26% Tabela 14 Registro e planejamento dos treinamentos 17% 26% 0% 5% 10% 15% 20% 25% 30% É criado um calendário dos treinamentos com definição das datas e pessoas participantes. Os treinamentos identificados são registrados. Figura 14 Gráfico de registro e planejamento de treinamentos identificados

28 Identificação de riscos Riscos são eventos ou condições incertas que, se ocorrerem, impactarão positivamente ou negativamente sobre ao menos um dos objetivos do projeto (PMI, 2004). Os riscos devem ser identificados ainda no planejamento do projeto. Quase metade das empresas (48%) não identifica os riscos do projeto, enquanto 13% das empresas, além de identificar os riscos, planejam atividades de prevenção e/ou mitigação dos riscos identificados. Nenhuma das empresas identifica probabilidade e impacto para os riscos identificados. Na Tabela 15 são apresentados os resultados desta questão, e na Figura 15 o gráfico. Percentual Os riscos são identificados no início do projeto % Os riscos identificados no início do projeto são registrados. 3 13% Durante a condução do projeto são identificados os novos riscos % Os riscos identificados durante a condução do projeto são registrados. 1 4% São planejadas atividades de prevenção e/ou mitigação dos riscos identificados. 3 13% Os riscos não são identificados % Tabela 15 Identificação dos riscos do projeto 60% 45% 43% 43% 48% 30% 15% 0% 13% Os riscos são identificados no início do projeto. 4% 13% Os riscos identificados no início do projeto são registrados. Durante a condução do projeto são identificados os novos riscos. Os riscos identificados durante a condução do projeto são registrados. São planejadas atividades de prevenção e/ou mitigação dos riscos identificados. Os riscos não são identificados. Figura 15 Identificação dos riscos do projeto Estratégia de controle de versão A forma como devem ser controladas as versões dos artefatos do projeto (planejamento, especificação, modelagens, código-fonte, etc.) devem ser definidas no planejamento. Observou-se que 17% das empresas não possuem uma estratégia de controle de versão para os artefatos do projeto, mas 74% definem estratégia de controle de versão para os códigos-fontes do software e apenas 26% das empresas também definem uma estratégia para os demais artefatos e documentos do projeto (planejamento, especificação, modelagens, etc.). As Tabelas 16 e 17 apresentam os resultados desta questão e nas Figuras 16 e 17 estão os gráficos correspondentes.

29 Duas empresas informaram que registram as formas de controle definidas, mas não informaram o que controlam, sendo atribuías suas respostas ao item Não informaram. Percentual Existe uma forma definida para controlar as versões dos códigos fontes % Existe uma forma definida para controlar as versões dos códigos fontes e dos documentos do projeto. 6 26% Não existe uma forma de controle de versão. 4 17% Não informaram. 2 9% Total % Tabela 16 Definição de controle de versão dos artefatos do projeto 17% 9% 48% Existe uma forma definida para controlar as versões dos códigos fontes. Existe uma forma definida para controlar as versões dos códigos fontes e dos documentos do projeto. Não existe uma forma de controle de versão. 26% Não informaram Figura 16 Gráfico de definição de controle de versão dos artefatos do projeto Na Tabela 17 e no gráfico da Figura 17 pode-se verificar que 35% das empresas registram formalmente as formas de controle de versão definidas. Percentual São registradas. 8 35% Não são registradas % Não são definidas. 4 17% Total % Tabela 17 Registro das definições de estratégia de controle de versão

30 17% 35% São registradas. Não são registradas. Não são definidas. 48% Figura 17 Gráfico do registro das definições de estratégia de controle de versão Repositório do Projeto Repositório do Projeto é um recipiente eletrônico para armazenar produtos de trabalho e liberações do projeto (ABNT, 2012b). O estabelecimento deste local eletrônico é considerando um requisito para o cumprimento completo da atividade de Planejamento de Projeto do processo de Gerência de Projeto, além de ser considerado artefato obrigatório. Apenas 9% das empresas não possuem um repositório para o projeto. Grande parte das empresas possui seus códigos-fonte no repositório (87%), os documentos do planejamento em 35% das empresas, e documentos do projeto do software (especificação, análise, modelagens, protótipos) em apenas 26% das empresas. Os resultados desta questão estão apresentados na Tabela 18. O percentual total fica acima de 100% pois as empresas poderiam assinalar mais de uma opção. O gráfico dos resultados é apresentado na Figura 18. Percentual Documentos do planejamento do projeto. 8 35% Documentos do projeto. 6 26% Códigos-fonte % Não existe um Repositório do Projeto. 2 9% Tabela 18 Artefatos armazenados no Repositório do Projeto

31 9% 26% 35% 87% 0% 20% 40% 60% 80% 100% Figura 18 Gráfico dos artefatos armazenados no Repositório do Projeto Planejamento das entregas Não existe um Repositório do Projeto. Códigos-fonte. Documentos do projeto. Documentos do planejamento do projeto. O planejamento das entregas deve ser realizado com base na Declaração de Trabalho, para haver consistência com o que deve ser desenvolvido e o que foi acordo. Observou-se que 35% das empresas respondentes realiza o planejamento das entregas de acordo com a declaração de trabalho, mas apenas 65% das empresas possuem uma Declaração de Trabalho, sendo possível verificar que 47% das empresas que confeccionam uma Declaração de trabalho não a utilizam para realizar o planejamento dos entregáveis. Ainda 22% das empresas não planejam as entregas e 48% das empresas registram o que foi planejado. O resultado detalhado pode ser observado na Tabela 19 e no gráfico apresentado na Figura 19. Percentual* Quando existem entregas parciais, estas são definidas e planejadas % O planejamento da(s) entrega(s) é realizado de acordo com a declaração de trabalho. 8 35% O planejamento da(s) entrega(s) é registrado % A(s) entrega(s) não são planejada(s). 5 22% Outros**. 2 9% Tabela 19 Planejamento das entregas * Percentual acima de 100%, pois uma empresa poderia assinalar mais de uma opção. ** Outros: As entregas são planejadas parcialmente e As entregas são planejadas, mas geralmente são alteradas no decorrer do projeto, pois na maioria dos projetos são abordadas novas situações que não haviam sido citadas pelo cliente e só as identificamos durante o desenvolvimento do projeto.

32 60% 40% 20% 48% 35% 48% 22% 9% 0% Quando existem entregas parciais, estas são definidas e planejadas. O planejamento da(s) entrega(s) é realizado de acordo com a declaração de trabalho. O planejamento da(s) entrega(s) é registrado. A(s) entrega(s) não são planejada(s). Outros. Figura 19 Gráfico do planejamento das entregas Como verificado na Tabela 19, 78% das empresas fazem um planejamento das entregas e 22% não as planeja. Para as empresas que realizam este planejamento solicitou-se como o realizavam. Os resultados constam na Tabela 20, e são apresentados graficamente na Figura 20. Percentual* É realizado junto com o Cliente % É realizado junto com a Equipe do projeto. 9 50% É comunicado a todos os envolvidos no projeto, incluindo o Cliente % É aprovado pelo Cliente % Tabela 20 Quem participa do planejamento das entregas e a quem este é comunicado * Percentual calculado com base nas dezoito empresas que realizam o planejamento das entregas. Percentual total fica acima de 100% pois cada empresa poderia assinalar mais de uma opção. 61% 67% 50% 56% 0% 10% 20% 30% 40% 50% 60% 70% É aprovado pelo Cliente. É comunicado a todos os envolvidos no projeto, incluindo o Cliente. É realizado junto com a Equipe do projeto. É realizado junto com o Cliente. Figura 20 Gráfico dos participantes do planejamento das entregas Cronograma Um cronograma define uma ordem cronológica para a realização das tarefas, sendo que estas devem ser organizadas em uma sequência que considera as dependências existentes entre as tarefas. Apenas 13% das empresas não criam um cronograma e 30% trabalham com definição de prazo para as

33 iterações, não havendo a necessidade de definir datas de início e conclusão para cada uma das atividades. O resultado desta questão é mais bem detalhado na Tabela 21. O gráfico dos resultados é apresentado na Figura 21. Percentual* São definidas datas de início e conclusão para cada uma das tarefas % São atribuídos materiais e pessoas necessárias para cada uma das tarefas. 7 30% Identifica-se a sequência da realização das tarefas e dependência entre elas % São identificados somente os prazos das iterações, sem a necessidade de definir data para cada atividade. 7 30% Não é criado um cronograma. 3 13% Tabela 21 Cronograma do projeto 13% 30% 30% 43% 48% 0% 10% 20% 30% 40% 50% 60% Não é criado um cronograma. São identificados somente os prazos das iterações. Identifica-se a sequência da realização das tarefas e dependência entre elas. São atribuídos materiais e pessoas necessárias para cada uma das tarefas. São definidas datas de início e conclusão para cada uma das tarefas. Figura 21 Gráfico de elaboração do cronograma do projeto Plano de Projeto Um Plano de Projeto é um documento que descreve como os processos e atividades do projeto serão executados para assegurar a conclusão bem-sucedida do projeto e a qualidade dos produtos entregues (ABNT, 2012b). Pode-se dizer que o Plano de Projeto é a junção de todas as informações do planejamento do projeto em um único documento. O Plano de projeto é artefato considerado obrigatório pela norma. Mais da metade das empresas (61%) não cria um Plano de Projeto. Apenas 4%, ou seja, uma das empresas, cria o Plano de Projeto integrando todos os documentos do planejamento e 35% das empresas cria um Plano de Projeto, o qual integra apenas alguns documentos do planejamento. A Tabela 22 apresenta estes resultados, que podem ser mais bem observados no gráfico da Figura 22.

34 Percentual É criado um Plano de Projeto (completo*) 1 4% É criado um Plano de Projeto (parcial**) 8 35% Não é desenvolvido um Plano de Projeto % Total % Tabela 22 Plano de Projeto * Integra todos os documentos referentes ao planejamento do projeto ** Integra apenas alguns dos documentos do planejamento 4% 35% 61% É criado um Plano de Projeto (completo*) É criado um Plano de Projeto (parcial**) Não é desenvolvido um Plano de Projeto. Figura 22 Gráfico da elaboração de um Plano de Projeto Verificação e validação do Plano de Projeto Para assegurar a qualidade do projeto é necessário realizar tarefas de verificação e validação dos produtos de trabalho. Sendo assim, o Plano de Projeto deve passar por um processo de análise interna, onde são verificados se todos os elementos do Plano de Projeto são viáveis e consistentes. Os resultados desta verificação devem ser registrados criando assim, outro documento requerido pela Norma: documento de Resultados de Verificação. O aceite do cliente relativo ao Plano de Projeto é fundamental para manter o projeto direcionado às necessidades e expectativas do cliente. Para não haver divergências durante e ao final do projeto, é importante que sejam realizadas alterações no Planejamento até obter-se o aceite do cliente. Esta validação com o cliente deve ser registrada, obtendo-se outro artefato solicitado pela Norma: documento de Resultados de Validação. Dentre as nove empresas (39%) que criam um Plano de Projeto, 44% realizam um processo de verificação neste documento, enquanto 50% das empresas que realizam a verificação registram os resultados obtidos. A Validação do Plano de Projeto é realizada por 67% das empresas, sendo que 11% não realiza nenhum tipo de revisão no Plano de Projeto. Os resultados desta questão constam na Tabela 23, e são apresentados graficamente na Figura 23.

35 O Plano de Projeto é revisado internamente, e correções são realizadas até obter-se a aprovação do Gerente do Projeto. Os resultados da revisão interna do Plano de Projeto são registrados. O Plano de Projeto é revisado pelo Cliente, e correções são realizadas até obter-se a sua aprovação. Percentual* 4 44% 2 22% 6 67% Não são realizadas revisões no Plano de Projeto. 1 11% Tabela 23 Verificação e validação do Plano de projeto * Percentual calculado com base nas nove empresas que criam um Plano de Projeto. 11% 67% 22% 44% 0% 10% 20% 30% 40% 50% 60% 70% Não são realizadas revisões no Plano de Projeto. O Plano de Projeto é revisado pelo Cliente, e correções são realizadas até obter-se a sua aprovação. Os resultados da revisão interna do Plano de Projeto são registrados. O Plano de Projeto é revisado internamente, e correções são realizadas até obter-se a aprovação do Gerente do Projeto. Figura 23 Gráfico de verificação e validação do Plano de Projeto Execução do Projeto Este grupo de questões aborda a atividade de execução do projeto, definida pela norma como Execução do Plano de Projeto. Esta atividade pertence ao processo de Gerência de Projeto e é obrigatória para o atendimento à norma Práticas realizadas durante a Execução do Projeto Durante a execução do projeto as tarefas identificadas no planejamento são realizadas, e devem ser registradas para compor o Registro de Status do projeto. O Registro de Status do projeto é um artefato obrigatório e registra o status do projeto frente ao que foi planejado. Observou-se que 57% das empresas registram as atividades realizadas, o que torna possível uma futura comparação entre o planejado e o realizado. A realização de reuniões com a Equipe do projeto e com o Cliente é uma prática importante que também deve ser realizada durante a execução do projeto. Todas as empresas respondentes realizam reuniões com a Equipe do projeto e 83% também realizam reuniões com o Cliente. Reuniões realizadas com o cliente durante a execução do projeto garantem que o cliente esteja sempre envolvido, o que aumenta as chances de atender as suas necessidades e expectativas, gerando sucesso

36 ao projeto (no que se refere à satisfação do cliente). Foi observado que 30% das empresas registram as reuniões realizadas e 43% (apesar de algumas não registrarem as reuniões formalmente) registram e monitoram as decisões tomadas durante sua realização. Os resultados desta questão são apresentados na Tabela 24 e no gráfico da Figura 24. Tabela 24 Práticas adotadas durante a execução do projeto Percentual As tarefas realizadas são registradas % São realizadas reuniões com a Equipe do Projeto % São realizadas reuniões com o Cliente % As reuniões realizadas são registradas. 7 30% Decisões tomadas nas reuniões são registradas e monitoradas % 150% 100% 50% 57% 100% 83% 30% 43% 0% As tarefas realizadas são registradas. São realizadas reuniões com a Equipe do Projeto. São realizadas reuniões com o Cliente. As reuniões realizadas são registradas. Decisões tomadas nas reuniões são registradas e monitoradas. Figura 24 Gráfico de práticas adotadas durante a execução do projeto Solicitações de mudança Mudanças são comuns em todo projeto de software e estas devem ser gerenciadas como tal. Mudanças que alteram o que foi acordado com o cliente (por exemplo, uma mudança que altera o custo do projeto e consequentemente o preço de venda do software) devem ser renegociadas para obter o seu aceite. Uma solicitação de mudança pode ser originada tanto pelo Cliente, como pela Equipe do Projeto. Entre as empresas respondentes, 83% registram as mudanças solicitadas pelo Cliente e 57% registram as solicitadas pela Equipe do projeto. A grande maioria (70%) faz renegociações com o Cliente quando uma mudança solicitada afeta o que havia sido acordado. Mudanças podem gerar, e geram em sua grande maioria, impacto em um ou mais objetivos do projeto. Por este motivo, a necessidade de mudança levantada deve ser analisada quanto ao seu impacto no projeto. Podem ser analisados itens como custo, cronograma, impacto técnico, entre outros. Menos da metade das empresas (48%) analisa o impacto de uma mudança antes de aceitar a sua realização. Apenas 22% atualizam o seu Plano de Projeto caso seja aceita a realização da mudança. Tendo em vista que apenas 39% das empresas tem um Plano para o Projeto, 56% destas empresas atualizam o Plano de Projeto que possui. A Tabela 25 e a Figura 25 apresentam o resultado desta questão.

37 Percentual Solicitações de mudanças feitas pelo Cliente são registradas % Solicitações de mudanças feitas pela Equipe de Trabalho são registradas % Mudanças que alteram o que foi acordado com o Cliente são renegociadas para alcançar a aceitação de ambas às partes % Antes de aceitar que a uma mudança seja feita, é realizada uma análise de impacto % Mudanças que serão realizadas são atualizadas no Plano de Projeto. 5 22% Nenhuma das alternativas. 1 4% Outros*. 1 4% Tabela 25 Solicitações de mudança *Outros: Cronograma é atualizado, mas não temos Plano de Projeto. 100% 50% 0% Figura 25 Gráfico de tratamento de solicitações de mudanças Backups 83% 57% 70% 48% Durante a execução do projeto devem ser feitos backups do repositório do projeto (ou dos documentos e artefatos caso não haja um repositório). A confecção de backups é um item para atendimento à atividade de Execução do Plano de Projeto, além de ser um artefato obrigatório ( Backup de Repositório do Projeto ). Observou-se que 91% das empresas fazem backup de algum documento ou artefato do projeto. Mais da metade (57%) das empresas fazem backups de todos os artefatos do projeto, incluindo código fonte, documentação do projeto e documentos da gerência. Apenas 4% realizam backups dos códigos-fonte do software e dos documentos do projeto (requisitos, modelagem, etc.) e 30% apenas fazem backups dos códigos-fonte, e 9% não realizam backup de nenhum documento/artefato. A Tabela 26 e Figura 26 apresentam estes resultados. 22% Solicitações de mudanças feitas pelo Cliente são registradas. Solicitações de mudanças feitas pela Equipe de Trabalho são registradas. 4% 4% Solicitações de mudanças que alteram o que foi acordado com o Cliente são renegociadas. Antes de aceitar que a uma mudança seja feita, é realizada uma análise de impacto. Mudanças que serão realizadas são atualizadas no Plano de Projeto. Nenhuma das alternativas. Outros.

38 Percentual Geral de todos os artefatos % Apenas códigos-fonte 7 30% Códigos-fonte e documentos de especificação e projeto do software 1 4% Não são feitos backups. 2 9% Total % Tabela 26 Backups do projeto 4% 9% 30% 57% Geral de todos os artefatos. Apenas códigos-fonte Códigos-fonte e documentos de especificação e projeto do software Não são feitos backups. Figura 26 Gráfico da confecção de backups dos artefatos do projeto Dentre as 21 empresas que utilizam a prática de realização de backups, 57% planeja a realização dos backups e 43% apenas os realizam esporadicamente. A Tabela 27 e Figura 27 apresentam estes resultados. Percentual* A confecção dos backups é planejada e realizada conforme este planejamento % Os backups são feitos esporadicamente e sem planejamento. 9 43% Tabela 27 Política de backups * Percentual calculado de acordo com as vinte e uma empresas que realizam backups.

39 43% 57% A confecção dos backups é planejada e realizada conforme este planejamento. Os backups são feito esporadicamente e sem planejamento. Figura 27 Gráfico da política de confecção de backups Como é possível observar, a tarefa de Execução do Plano de Projeto apenas aborda as tarefas de gerenciamento que devem ser realizadas durante a execução do projeto, não são consideradas nesta atividade tarefas relacionadas ao processo de Implementação do Software, que também ocorrem durante a execução do projeto. As questões relacionadas ao processo de Implementação do Software são abordadas mais adiante Avaliação e Controle do Projeto A atividade de Avaliação e Controle do Projeto, também pertencente ao processo de Gerência de Projeto, tem como objetivo avaliar e controlar o desempenho do projeto em relação aos compromissos documentados no planejamento Avaliação e controle da execução do projeto A execução do projeto é acompanhada e avaliada por 87% das empresas para garantir que sua execução esteja de acordo com o planejado. Porém, 70% das empresas não registram este acompanhamento e avaliação, e 13% nem realizam este controle. Estes resultados podem ser observados na Tabela 28 e Figura 28. Percentual Realiza e registra o acompanhamento. 4 17% Acompanha mas não registra % Não faz o acompanhamento. 3 13% Total % Tabela 28 Acompanhamento e avaliação da execução do projeto

40 13% 17% 70% Realiza e registra o acompanhamento. Acompanha mas não registra. Não faz o acompanhamento. Figura 28 Gráfico de acompanhamento e avaliação da execução do projeto Itens que são avaliados e controlados A grande maioria (70%) das empresas que realiza a avaliação e controle da execução do projeto compara as tarefas que foram realizadas até o momento com as tarefas planejadas para serem realizadas até o momento, verificando se o projeto está em dia, adiantado ou atrasado. A avaliação do custo real versus estimativas de custos, para verificar se o projeto está dentro do custo planejado, é realizada por 25% das empresas. O cronograma é acompanhado por 50% das empresas. A Tabela 29 apresenta todos os resultados desta questão, que também são apresentados no gráfico da Figura 29. Percentual* Tarefas realizadas versos tarefas planejadas % Alocação de recursos realizada versus planejada % Custo real versus estimativas de custo iniciais % Cronograma real versus cronograma planejado % Riscos reais versus riscos identificados previamente % Não informaram % Tabela 29 Itens que são controlados e avaliados * Percentual calculado com base nas vinte empresas que acompanham a execução do projeto.

41 80,00% 70,00% 60,00% 50,00% 40,00% 20,00% 20,00% 25,00% 15,00% 10,00% 0,00% Tarefas realizadas versos tarefas planejadas. Alocação de recursos realizada versus planejada. Custo real versus estimativas de custo iniciais. Cronograma real versus cronograma planejado. Riscos reais versus riscos identificados previamente. Não informaram Figura 29 Gráfico dos itens acompanhados e avaliados Ações para correções de desvios ou problemas encontrados Quando identificado desvios do que havia sido planejado (ou problemas ou riscos), 87% das empresas estabelecem ações para corrigi-los e 9% nada fazem à respeito, enquanto 4% não responderam. Os resultados são apresentados na Tabela 30 e no gráfico da Figura 30. Percentual São estabelecidas ações para corrigi-los % Nada é feito a respeito. 2 9% Não responderam 1 4% Total % Tabela 30 Definição de ações corretivas para desvios e problemas 9% 4% 87% São estabelecidas ações para corrigi-los. Nada é feito a respeito. Não responderam Figura 30 Gráfico de definição de ações corretivas

42 Entre as vinte empresas que definem ações de correção para desvios e problemas identificados durante a execução do projeto, 25% fazem o registro destas ações e 50% monitora as ações até sua conclusão (mesmo que algumas não registram o que foi definido). Este resultado é apresentado na Tabela 31 e no gráfico da Figura 31. Percentual* As ações definidas são registradas. 5 25% Monitora-se as ações definidas até a sua conclusão % Tabela 31 Registro e controle das ações corretivas * Percentual calculado com base nas vinte empresas que definem ações corretivas. 25% 50% 0% 10% 20% 30% 40% 50% 60% Monitora-se as ações definidas até a sua conclusão. As ações definidas são registradas. Figura 31 Gráfico do registro e controle das ações corretivas O Registro de Correção é um artefato originado do registro das ações estabelecidas para corrigir desvios significativos e problemas ocorridos durante a execução do projeto. Este documento também é requerido pela norma e observou-se que 22% das empresas geram este artefato, pois definem e registram as ações para correção e desvios e problemas Início da Implementação do Software A atividade de Início da Implementação do Software faz parte do processo de Implementação de Software. Esta atividade objetiva garantir que haja um comprometimento da Equipe do projeto com o Plano de Projeto estabelecido na atividade de Planejamento do Projeto Realização de reunião com a equipe do projeto no início da implementação A grande maioria das empresas (96%) se preocupa em realizar uma reunião com a Equipe do projeto, antes do início da implementação, seja para discutir e revisar o Plano do Projeto ou para deixar todos a par do que é o projeto e o que será desenvolvido. Com isto, as empresas objetivam alcançar um entendimento comum e comprometimento de todos. Na Tabela 32 os resultados são apresentados em detalhes. A Figura 32 apresenta o gráfico desta questão. Percentual É realizada para discutir e revisar o Plano do Projeto. 8 35% É realizada para deixar todos a par do que é o projeto e o que será desenvolvido 14 61% Não é realizada uma reunião com a equipe de trabalho no início da implementação. 1 4% Total % Tabela 32 Reunião com a equipe do projeto no início da implementação

43 4% 35% 61% É realizada para discutir e revisar o Plano do Projeto. É realizada para deixar todos a par do que é o projeto e o que será desenvolvido Não é realizada uma reunião com a equipe de trabalho no início da implementação. Figura 32 Gráfico de reunião com a equipe do projeto no início da implementação Estabelecimento ou atualização do ambiente de implementação O ambiente de implementação deve ser estabelecido ou atualizado (em termos de local, equipamentos, software, ferramentas, arquivos, senhas, acessos, autorizações etc.) no início da implementação. A maioria das empresas (70%) atualiza e organiza o ambiente conforme a demanda ao longo da etapa de implementação. Foi observado que 17% das empresas já organiza o ambiente de trabalho antes de iniciar a implementação, e 13% não responderam a questão. Percentual Antes de iniciar a implementação é organizado (estabelecido ou atualizado) o ambiente de trabalho. 4 17% O ambiente vai sendo atualizado e organizado conforme a demanda ao longo da etapa de implementação % Não responderam. 3 13% Total % Tabela 33 Ambiente de implementação 13% 17% 70% Antes de iniciar a implementação é organizado (estabelecido ou atualizado) o ambiente de trabalho. O ambiente vai sendo atualizado e organizado conforme a demanda ao longo da etapa de implementação. Não responderam. Figura 33 Gráfico da organização do ambiente de implementação Análise de Requisitos do Software Nesta seção são abordadas as questões referentes a atividade de Análise de Requisitos do Software. Esta atividade pertence ao processo de Implementação de Software, e é nesta atividade que são

44 analisados os requisitos acordados com o Cliente e estabelecido os requisitos validados do projeto (ABNT,2012b) Levantamento dos requisitos Com relação ao levantamento dos requistos, em somente uma empresa (4%) o cliente fornece os requisitos já definidos, e não há um detalhamento realizado pela empresa. A maioria (65%) das empresas realiza uma entrevista com o cliente, porém geralmente limitada a um ou dois responsáveis do cliente. Em contrapartida, 31% das empresas consultam várias fontes de informações para o levantamento dos requisitos, dentre elas: cliente, sistemas anteriores, usuários, documentos, análise do processo atual. Percentual O cliente fornece os requisitos já definidos, e não há um detalhamento realizado pela empresa. 1 4% É realizada entrevista com o cliente, porém geralmente limitada a um ou dois responsáveis do cliente % São consultadas várias fontes de informações para o levantamento dos requisitos. 7 31% Total % Tabela 34 Levantamento de requisitos 30,43% 4,35% Figura 34 Gráfico da forma de levantamento de requisitos 65,22% O cliente fornece os requisitos já definidos, e não há um detalhamento realizado pela empresa. É realizada entrevista com o cliente, porém geralmente limitada a um ou dois responsáveis do cliente. São consultadas várias fontes de informações para o levantamento dos requisitos Registro e atualização da especificação de requisitos Todas as empresas registram de alguma forma os requisitos levantados, e 43% os registram formalmente. A Especificação de Requisitos é um artefato requerido pela Norma. As Tabelas 35 e Figura 35 apresentam em detalhes os resultados desta questão.

45 Percentual São registrados de maneira informal % São registrados formalmente (Especificação de Requisitos) % Não informaram como registram os requisitos. 2 9% Os requisitos não são registrados. 0 0% Total % Tabela 35 Registro dos Requisitos levantados 9% 0% 43% 48% São registrados de maneira informal. São registrados formalmente (Especificação de Requisitos). Não informaram como registram os requisitos. Os requisitos não são registrados. Figura 35 Gráfico do registro dos requisitos levantados Apesar de todas as empresas registrarem os requisitos, mesmo que de maneira informal ( , papel de rascunho, etc.), apenas 39% delas os atualizam essa especificação quando necessário, como por exemplo em caso de mais iterações no desenvolvimento ou solicitações de mudanças (Tabela 36 e Figura 36). Percentual Quando necessário a especificação de requisitos é atualizada. 9 39% Não são realizadas atualizações % Total % Tabela 36 Atualização da Especificação de Requisitos 39% 61% Quando necessário a especificação de requisitos é atualizada. Não são realizadas atualizações. Figura 36 Gráfico da atualização dos requisitos

46 Verificação dos requisitos Os requisitos devem passar por um processo de verificação, e a maioria das empresas faz essa verificação considerando pelo menos um aspecto (escopo, completude, viabilidade). Porém, 18% não realizam verificação alguma nos requisitos levantados. A Tabela 37 apresenta os resultados desta questão, e a Figura 37 apresenta o gráfico correspondente. Percentual Analisa-se os requisitos quanto ao escopo % Analisa-se os requisitos quanto a sua completude. 9 39% Analisa-se os requisitos quanto a sua viabilidade % Os resultados da análise dos requisitos e as correções feitas são registrados. 6 26% Os requisitos são definidos por toda a equipe ou em pares. 2 9% Não são realizadas verificações nos requisitos. 4 18% Tabela 37 Verificação dos Requisitos 80% 60% 40% 20% 61% 39% 57% 0% Analisa-se os requisitos quanto ao escopo. Figura 37 Gráfico da verificação dos requisitos 26% Analisa-se os requisitos quanto a sua completude. Analisa-se os requisitos quanto a sua viabilidade. 9% 17% Os resultados da análise dos requisitos e as correções feitas são registradas. Os requisitos são definidos por toda a equipe ou em pares. Não são realizadas verificações nos requisitos. A Tabela 38 apresenta de forma detalhada os fatores analisados pelas empresas durante a verificação dos requisitos. Por meio desta tabela pode-se verificar que apenas 26% das empresas analisam os requisitos quando aos três fatores necessários (escopo, completude e viabilidade).

47 Percentual Escopo, completude e viabilidade. 6 26% Escopo e completude. 1 4% Escopo e viabilidade. 4 18% Completude e viabilidade. 1 4% Apenas escopo. 3 13% Apenas viabilidade. 2 9% Definição em pares. 1 4% Definição em pares e análise de completude. 1 4% Não são realizadas verificações nos requisitos. 4 18% Total % Tabela 38 Detalhamento das análises realizadas na verificação dos Requisitos 18% Escopo, completude e viabilidade. 26% Escopo e completude. 4% 4% 9% 4% Escopo e viabilidade. Completude e viabilidade. Apenas escopo. Apenas viabilidade. Definição em pares. 13% 4% 18% Definição em pares e análise de completude. Não são realizadas verificações nos requisitos. Figura 38 Gráfico dos itens verificados nos requisitos Validação dos requisitos Além da verificação dos requisitos, outra tarefa importante é a validação dos requisitos junto ao Cliente para obter sua aprovação (validar se satisfazem as suas necessidades e expectativas combinadas, incluindo usabilidade da interface do usuário). Foi observado que 78.26% das empresas realizam uma validação dos requisitos com o cliente, enquanto 13.04% não realizam a validação dos requisitos e 8.70% não informaram se realizam ou não a validação com o cliente. A Tabela 39 e o gráfico da Figura 39 apresentam estes resultados.

48 Percentual Obtêm-se a aprovação do Cliente quanto aos requisitos levantados % Os requisitos não são validados junto ao Cliente % Outros* % Não informaram % Total % Tabela 39 Validação dos requisitos * Outros: Os requisitos são levantados junto ao cliente, mas de forma sucinta e depois conforme o desenvolvimento vão sendo validados pelo cliente. 8,70% 4,35% 13,04% Figura 39 Gráfico da validação dos requisitos 73,91% Obtêm-se a aprovação do Cliente quanto aos requisitos levantados. Os requisitos não são validados junto ao Cliente. Outros. Não informaram. A Tabela 40 apresenta os demais resultados desta questão, sendo que 26% das empresas registram os Resultados da Validação dos Requisitos e 57% das empresas realizam correções nos requisitos até que seja obtida a aprovação do Cliente, realizando diversas validações até que a especificação de requisitos esteja completamente aprovada. Estes resultados também são apresentados graficamente na Figura 40. Os resultados da validação dos requisitos realizada com o Cliente são registrados. São realizadas correções nos requisitos até que se obtenha a aprovação do Cliente. Tabela 40 Registro dos resultados e correções nos requisitos Percentual 6 26% 13 57%

49 57% 26% 0% 10% 20% 30% 40% 50% 60% São realizadas correções nos requisitos até que se obtenha a aprovação do Cliente. Os resultados da validação dos requisitos realizada com o Cliente são registrados. Figura 40 Gráfico do registro dos resultados e correções nos requisitos Projeto de Arquitetura e Detalhamento do Software Este grupo de questão trata da atividade de Projeto de Arquitetura e Detalhamento do Software. Esta atividade pertence ao processo de Implementação de Software e é responsável por transformar os requisitos na arquitetura do sistema de software e no projeto detalhado do software (ABNT, 2012b, p. 24), ou seja, são elaboradas as modelagens de dados, classes, protótipos de interface, dentre outras, conforme a necessidade de cada projeto Elaboração do Projeto de arquitetura e detalhamento do software Observou-se que 65% das empresas elabora o Projeto de arquitetura e detalhamento do software, seja de alto ou baixo nível. Lembrando que o Projeto do Software pode ser elaborado parcialmente de acordo com a necessidade dos entregáveis (da iteração). Em contrapartida, 35% das empresas não elabora o Projeto do Software. A Tabela 41 e o gráfico da Figura 41 apresentam estes resultados. Percentual É elaborado % Não é elaborado. 8 35% Total % Tabela 41 Elaboração do Projeto do Software 35% É elaborado. Não é elaborado. 65% Figura 41 Gráfico da elaboração do Projeto do Software Foi identificado que 80% das empresas que elaboram o Projeto do Software, o fazem com base nos requisitos levantados. E, 47% delas, atualizam projeto quando necessário, como em caso de mais

50 iterações no desenvolvimento ou solicitações de mudanças. Estes resultados são apresentados na Tabela 42 e no gráfico da Figura 42. Percentual* A elaboração é feita com base nos requisitos levantados % Quando necessário o Projeto do Software é atualizado. 7 47% Tabela 42 Elaboração e atualização do Projeto do Software * Percentual calculado com base nas quinze empresas que elaboram o Projeto do Software. 47% 80% 0% 20% 40% 60% 80% 100% Quando necessário o Projeto do Software é atualizado. A elaboração é feita com base nos requisitos levantados. Figura 42 Gráfico da elaboração e atualização do Projeto do Software Projeto de Alto e Baixo nível Dentre as empresas que elaboram um Projeto do Software, 27% cria o projeto em alto nível (definição dos componentes de software e seus relacionamentos), 53% cria o projeto de baixo nível (detalhamento dos componentes de software: especificação de dados, design detalhado que pode ser representado por um protótipo, fluxograma, diagrama de relacionamento de entidades, entre outras), 13% fazem o projeto de alto e baixo nível e 7% não responderam. Os resultados são apresentados na Tabela 43 e no gráfico da Figura 43. Percentual* Projeto de alto e baixo nível. 2 13% Projeto de alto nível. 4 27% Projeto de baixo nível. 8 53% Não responderam. 1 7% Total % Tabela 43 Projeto do Software de baixo e alto nível * Percentual calculado com base nas 15 empresas que elaboram o Projeto do Software

51 7% 13% 27% 53% Projeto de alto e baixo nível. Projeto de alto nível. Projeto de baixo nível. Não responderam Figura 43 Gráfico da elaboração do Projeto de baixo e alto nível Verificação do Projeto do Software Dentre as quinze empresas que elaboram o Projeto de Software, apenas 7% delas não fazem verificações. As demais empresas realizam algum tipo de verificação (viabilidade e/ou consistência com os requisitos) ou definem o Projeto do Software com toda a equipe ou em pares. Em 33% das empresas, além de verificar o Projeto de Software, são registrados os resultados e correções realizadas. A Tabela 44 e o gráfico da Figura 44 apresentam em detalhes os resultados desta questão. Percentual* Analisa-se Projeto de Software quando a sua viabilidade % Analisa-se o Projeto de Software quanto a sua consistência em relação aos requisitos. 5 33% Os resultados da análise do Projeto de Software e as correções realizadas são registrados. 5 33% O Projeto do Software é definido por toda a equipe ou em pares, por isto não existe a necessidade de verificação. 3 20% Não são feitas verificações no Projeto de Software. 1 7% Tabela 44 Verificação do Projeto do Software e registro dos resultados * Percentual calculado com base nas quinze empresas que elaboram o Projeto do Software

52 90% 73% 60% 30% 0% 33% 33% Analisa-se Projeto de Software quando a sua viabilidade. Figura 44 Gráfico da verificação do Projeto do Software e registro dos resultados A Tabela 45 lista os itens verificados no Projeto do Software, e a Figura 45 apresenta o gráfico correspondente. Percentual* Viabilidade. 5 33% Viabilidade e consistência com os requisitos. 5 33% Definição em pares. 2 13% Definição em pares e verificação de viabilidade. 1 7% Não informou qual item verifica. 1 7% Não são feitas verificações. 1 7% Total % Tabela 45 Item verificados no Projeto do Software * Percentual calculado com base nas quinze empresas que elaboram o Projeto do Software 20% Analisa-se o Projeto de Software quanto a sua consistência em relação aos requisitos. Os resultados da análise do Projeto de Software e as correções realizadas são registradas. O Projeto do Software é definido por toda a equipe ou em pares. Não são feitas verificações no Projeto de Software. 7% 7% 7% 7% 33% 13% 33% Viabilidade. Viabilidade e consistência com os requisitos. Definição em pares. Definição em pares e verificação de viabilidade. Não informou qual item verifica. Não são feitas verificações. Figura 45 Gráfico dos itens verificados no Projeto de Software

53 Elaboração de Casos de Testes e Procedimentos de Testes Os Casos de Testes e Procedimentos de Testes devem ser elaborados para utilização na fase de Integração e Testes de software, e são considerados artefatos obrigatórios pela Norma. Conforme observado na Tabela 46, menos da metade das empresas (48%) estabelecem os Casos e Procedimentos de Testes a serem utilizados para testar o software. E uma minoria de 4%, não sabe do que se trata os Casos e Procedimentos de Testes. Percentual São estabelecidos % Não são estabelecidos 11 48% Não sei do que se trata. 1 4% Total % Tabela 46 Elaboração de Casos de Teste e Procedimentos de Testes 4% 48% 48% São estabelecidos. Não são estabelecidos. Não sei do que se trata. Figura 46 Gráfico de elaboração de Casos de Teste e Procedimentos de Testes A verificação dos Casos de Teste e procedimentos de Teste, para garantir a sua consistência em relação aos requisitos e ao projeto de software, é realizada por 30% das empresas. E, 13% das empresas fazem o registro desta verificação. A Tabela 47 e a Figura 47 apresentam os resultados. É realizada uma verificação nos Casos de Teste e Procedimentos de Testes elaborados. Os resultados da verificação dos Casos de Teste e Procedimentos de Testes são registrados. Tabela 47 Verificação e registro da verificação de casos de teste Percentual 7 30% 3 13%

54 13% 30% 0% 5% 10% 15% 20% 25% 30% 35% Os resultados da verificação são registrados. É realizada uma verificação nos Casos de Teste e Procedimentos de Testes elaborados. Figura 47 Gráfico de verificação e registro da verificação de casos de teste Construção do Software Neste grupo são abordadas as questões relativas à atividade de Construção do Software, que pertence ao processo de Implementação de Software. Nesta atividade é realizado o desenvolvimento do código e dos dados do software a partir do Projeto do Software Estratégia de versão dos produtos gerados Identificou-se que 39% das empresas geram versões internas (Build) para os produtos criados. 61% geram versões de liberação, conhecida como Release, 17% das empresas não criam nenhum tipo de versão do seu produto gerado e 22%, além de controlar as versões dos códigos gerados, vinculam a versão aos demais documentos do projeto correspondentes. Estes resultados são apresentados na Tabela 48 e no gráfico na Figura 48. Percentual * São geradas versões internas (Build). 9 39% São geradas versões de liberação (Release) % Não informaram o tipo de versão utilizada. 3 13% A versão do código-fonte é vinculada a uma versão dos demais documentos do projeto. 5 22% Não são criadas versões dos produtos. 4 17% Tabela 48 Estratégia de versão dos produtos gerados * Percentual total acima de 100%, pois as empresas poderiam informar mais de uma alternativa.

55 80% 60% 40% 20% 39% 61% 13% 22% 17% 0% São geradas versões internas (Build). São geradas versões de liberação (Release). Não informaram o tipo de versão utilizada. A versão do código-fonte é vinculada a uma versão dos demais documentos do projeto. Não são criadas versões dos produtos. Figura 48 Gráfico da estratégia de versão dos produtos gerados Testes Unitários Testes unitários são os testes que têm o objetivo de garantir que os retornos dos métodos estejam de acordo com as expectativas. Estes testes são aplicados por 65.21% das empresas, mesmo que eventualmente, enquanto 30.43% informaram que não os realizam, e uma minoria de 4.35% informou que não sabe do que se trata. Os resultados são mais bem detalhados na Tabela 47 e no gráfico da Figura 47. Percentual Sempre % Comumente % Eventualmente % Não são realizados % Não sei do que se trata % Total % Tabela 49 Aplicação de Testes Unitários 4,35% 30,43% 30,43% Sempre. Comumente. Eventualmente. Não são realizados. Não sei do que se trata. 13,04% 21,74% Figura 49 Gráfico da aplicação de Testes Unitários

56 Integração e Testes de Software Este grupo de questões está relacionado ao atendimento à execução da atividade de Integração e Testes de Software, definido pela norma no processo de Implementação de Software. Esta atividade objetiva unir os componentes de software desenvolvidos, bem como realizar testes de integração, ou seja, garantir que o software como um todo funcione corretamente, e atenda as expectativas e necessidades do cliente Realização de testes de Integração Para a realização dos testes de integração devem ser utilizados os Casos de Teste e Procedimento de Testes elaborados e verificados durante a atividade de elaboração do Projeto de Arquitetura de Detalhamento do Software (ABNT, 2012b). Observou-se que 39% das empresas realizam os testes de integração por meio da execução dos Casos de Testes e Procedimentos de Testes, enquanto 22% das empresas não realizam nenhum teste de integração e 48% realizam os testes sem planejamento prévio. Algumas empresas realizam os dois tipos de testes (informais e por meio de casos de testes), por este motivo o percentual total fica acima de 100%. Estes resultados são apresentados na Tabela 50 e no gráfico da Figura 50. Percentual* A integração é verificada por meio de alguns testes informais % A integração é verificada por meio da execução dos Casos de Teste e Procedimentos de Teste. 9 39% Não informou como são realizados os testes de integração. 1 4% Não são realizados testes de integração. 5 22% Tabela 50 Testes de Integração * Percentual acima de 100%, pois existem empresas que fazem testes formais (utilizando os casos de testes), além de outros testes informais. 60% 40% 48% 39% 20% 0% 4% 22% A integração é verificada por meio de alguns testes informais. A integração é verificada por meio da execução dos Casos de Teste e Procedimentos de Teste. Não informou como são realizados os testes de integração. Não são realizados testes de integração. Figura 50 Gráfico de testes de integração Dentre as empresas que realizam testes de integração, apenas 17% registram os resultados obtidos durantes a execução dos testes. O Relatório de Testes também é um artefato requerido pela Norma ABNT ISO/IEC Sendo assim, em geral, apenas 13% das empresas atende à elaboração deste artefato. Em contrapartida, 89% das empresas fazem correções no software até que seja obtido sucesso

57 (nenhum defeito) na execução dos testes. Estes resultados são tabelados na Tabela 51, e apresentados graficamente na Figura 51. Percentual* Os resultados obtidos na execução dos testes são registrados. 3 17% Defeitos encontrados são corrigidos até alcançar-se sucesso na execução dos testes % Tabela 51 Registro dos resultados e correção de defeitos encontrados * Percentual calculado com base nas dezoito empresas que realizam testes de integração. 17% 89% 0% 20% 40% 60% 80% 100% Defeitos encontrados são corrigidos até alcançar-se sucesso na execução dos testes. Os resultados obtidos na execução dos teste são registrados. Figura 51 Gráfico do registro dos resultados e correção de defeitos encontrados Realização de Testes de Sistemas Os testes de sistema não são abordados pela Norma, mas influenciam na qualidade do produto final. Por este motivo, também levantamos uma questão sobre a realização destes testes. Sendo que a questão não era obrigatória, 9% empresas não a responderam, 78% das empresas informaram que realizam testes de sistema e 13% não os realizam. Os resultados desta questão são apresentados na Tabela 52 e no gráfico da Figura 52. Percentual Sim, são realizados Testes de Sistema % Não são realizados Testes de Sistemas. 3 13% Não responderam 2 9% Total % Tabela 52 Realização de Testes de Sistema 9% 13% Sim, são realizados Testes de Sistema. Não são realizados Testes de Sistemas. Não responderam 78% Figura 52 Gráfico da realização de Testes de Sistema

58 De 78% das empresas que realizam Testes de Sistema, 33% planejam e elaboram previamente as rotinas a serem testadas, e 28% registram os resultados obtidos na realização destes testes. Estes resultados podem ser observados na Tabela 53 e no gráfico da Figura 53. Percentual* Os testes de sistema são planejados previamente, e o testador segue uma rotina de teste. 6 33% Os resultados obtidos durante os Testes de Sistemas são registrados. 5 28% Tabela 53 Planejamento dos testes de sistema e registro dos resultados * Percentual calculado com base nas dezoito empresas que realizam testes de sistema. 28% 33% 25% 26% 27% 28% 29% 30% 31% 32% 33% 34% Figura 53 Gráfico de planejamento dos testes de sistema e registro dos resultados Registros de Rastreabilidade Este grupo de questão aborda as questões relacionadas à geração dos registros de rastreabilidade. Os registros de rastreabilidade são artefatos considerados obrigatórios pela norma, e devem ser gerados para manter o rastreamento entre: Os resultados obtidos durante os Testes de Sistemas são registrados. Os testes de sistema são planejados previamente, e o testador segue uma rotina de teste. Requisitos do software, Projeto do Software e Casos de Teste e Procedimentos de Teste (na atividade de Projeto de Arquitetura e Detalhamento do Software); Componentes do Software e do Projeto do Software (na atividade de Construção do Software); Requisitos e do projeto ao produto de software integrado (na atividade de Integração e Testes de Software); Geração dos registros de rastreabilidade Os registros de rastreabilidade são feitos por apenas 13% das empresas, como pode ser observado na Tabela 54 e no gráfico da Figura 54. Percentual Não são criados registros de rastreabilidade 20 87% Sim, são criados registros de rastreabilidade 3 13% Total % Tabela 54 Registro de rastreabilidade

59 13% Figura 54 Gráfico do registro de rastreabilidade Entre as três empresas que fazem algum registro de rastreabilidade, são apresentados na Tabela 55 e no gráfico da Figura 55 os tipos de rastreabilidade utilizados. 87% Não são criados registros de rastreabilidade Sim, são criados registros de rastreabilidade Percentual* Rastreabilidade entre os requisitos e os elementos da modelagem e detalhamento do software. 2 67% Rastreabilidade entre os "Casos de Teste e Procedimentos de Testes" e os requisitos. 2 67% Rastreabilidade entre os Componentes do software e os elementos da modelagem e detalhamento do software. 1 33% Tabela 55 Item registrados no registro de rastreabilidade * Percentual calculado com base nas três empresas que fazem algum tipo de registro de rastreabilidade. A soma dos percentuais fica acima de 100%, pois cada empresa pode registrar mais de um tipo de rastreabilidade. 33% 67% 67% 0% 10% 20% 30% 40% 50% 60% 70% Rastreabilidade entre os Componentes do software e os elementos da modelagem e detalhamento do software. Rastreabilidade entre os "Casos de Teste e Procedimentos de Testes" e os requisitos. Rastreabilidade entre os requisitos e os elementos da modelagem e detalhamento do software. Figura 55 Gráfico dos itens rastreados

60 Mesmo que seja gerada rastreabilidade, nem sempre é verificada, registrada ou mantida a atualização dessa informação em casos de mudança, conforme pode ser visto na Tabela 56 e na Figura 56. Percentual* Quando necessário os registros de rastreabilidade são atualizados. 2 67% O Registro de rastreabilidade passa por um processo de verificação. 1 33% Os resultados da verificação do Registro de rastreabilidade são registrados. 1 33% Tabela 56 Atualização e verificação dos registros de rastreabilidade * Percentual calculado com base nas três empresas que fazem algum tipo de registro de rastreabilidade. 33% 33% 67% 0% 10% 20% 30% 40% 50% 60% 70% Quando necessário os registros de rastreabilidade são atualizados. O Registro de rastreabilidade passa por um processo de verificação. Os resultados da verificação do Registro de rastreabilidade são registrados. Figura 56 Gráfico de atualização e verificação dos registros de rastreabilidade Baseline A prática de baseline caracteriza-se por congelar um conjunto de documentos e produtos que se tornam a versão de referência para consultas e uso nas atividades subsequentes e pelos profissionais que as utilizam. A Norma ABNT ISO/IEC requer que seja gerada uma baseline ao menos ao final do planejamento do projeto e ao final da fase de integração e testes de software Geração de baseline A geração de baseline é realizada por apenas 22%, como apresentado na Tabela 57 e no gráfico da Figura 57. Percentual Não são geradas baselines % Sim, gera-se ao menos uma baseline em algum momento do projeto. 5 22% Total % Tabela 57 Geração de baseline

61 22% 78% Não são geradas baselines. Sim, gera-se ao menos uma baseline em algum momento do projeto. Figura 57 Gráfico da geração de baseline Dentre as cinco empresas que utilizam a prática de baseline, a maioria (80%) gera uma baseline após a elaboração da Especificação de Requisitos. Estes resultados são apresentados na Tabela 58 e no gráfico da Figura 58. Percentual* Gera-se uma baseline após a especificação dos requisitos. 4 80% Gera-se uma baseline após a elaboração do Projeto do software. 1 20% Gera-se uma baseline após o desenvolvimento dos componentes do software. 1 20% Gera-se uma baseline após o desenvolvimento dos componentes do software das entregas parciais, quando estas existem. 1 20% Gera-se uma baseline após a integração de todos os componentes desenvolvidos do software. 1 20% Quando existem, gera-se uma baseline após as entregas parciais. 1 20% Tabela 58 Momentos em que é gerada uma baseline * Percentual calculado com base nas cinco empresas que utilizam a prática de baseline. Cada empresa poderia informar mais de uma opção, por isso o percentual total fica acima de 100%. 100% 80% 50% 20% 20% 20% 20% 20% 0% Após a especificação dos requisitos. Após a elaboração do Projeto do software. Após o desenvolvimento dos componentes do software. Após o desenvolvimento dos componentes do software das entregas parciais. Após a integração de todos os componentes de software. Após as entregas parciais, quando estas existem. Figura 58 Gráfico dos momentos em que é gerada uma baseline

62 Outras informações levantadas nesta questão são apresentadas na Tabela 59, onde pode-se verificar que 20% das empresas que utilizam a prática de baseline, as geram apenas quando já obteve-se o aceite do Cliente em relação ao que foi planejado, definido ou desenvolvido. O momento no qual será gerada uma baseline é definido ainda no planejamento do projeto por 20% das empresas. Estes resultados podem ser vistos no gráfico da Figura 59. Percentual* Uma baseline é gerada apenas quando já se obteve o aceite do cliente em relação ao que foi planejado, definido ou 1 20% desenvolvido. No planejamento do projeto já são definidos os momentos nos quais será gerada uma baseline. 1 20% Tabela 59 Informações referentes à geração de baseline * Percentual calculado com base nas cinco empresas que utilizam a prática de baseline. 20% 20% 0% 5% 10% 15% 20% 25% No planejamento do projeto já são definidos os momentos nos quais será gerada uma baseline. Uma baseline é gerada apenas quando já se obteve o aceite do cliente em relação ao que foi planejado, definido ou desenvolvido. Figura 59 Gráfico das informações referentes à geração de baseline Documentos inclusos em baseline Dentre os documentos e produtos inclusos em baseline pelas empresas o principal e único contemplado pela maioria das empresas é a especificação de requisitos (60%). Estes resultados são apresentados na Tabela 60 e no gráfico da Figura 60. Percentual* Especificação de Requisitos. 3 60% Registros de rastreabilidade. 2 40% Projeto e modelagem do software. 1 20% Produtos intermediários da construção do software. 2 40% Relatório de testes do software. 2 40% Versão do software, ou das entregas parciais, pronto para uso. 2 40% Documentação do usuário. 1 20% Outros**. 1 20% Tabela 60 Itens inclusos em baseline * Percentual calculado com base nas cinco empresas que utilizam a prática de baseline. Cada empresa poderia informar mais de uma opção, por isso o percentual total fica acima de 100%. ** Outros: Cronograma.

63 100% 80% 60% 40% 20% 60% 40% 20% 40% 40% 40% 20% 20% 0% Especificação de Requisitos. Registros de rastreabilidade. Projeto e modelagem do software. Produtos intermediários da construção do software. Relatório de testes do software. Versão do software ou das entregas parciais pronto para uso. Documentação do usuário. Outros. Figura 60 Gráfico dos itens inclusos em baseline Elaboração de Manuais e Guias Nesta seção, são abordadas as questões relacionadas à elaboração de manuais e guias do software requeridos pela Norma ABNT ISO/IEC Documentação do usuário A Documentação do usuário é um manual que descreve o modo para utilizar o software baseado na interface do usuário (ABNT 2012b, p. 39). Foi identificado que 39% das empresas elaboram este documento. Uma das empresas que não confecciona a Documentação do Usuário informou, na opção outros, que este manual não é elaborado, pois é realizado treinamento e acompanhamento pelo suporte além do software possuir uma interface amigável ( é dado treinamento e acompanhado pelo suporte, fácil interface ). A Tabela 61 apresenta os resultados referentes à elaboração ou não deste manual, e a Figura 61 traz o gráfico correspondente. Percentual Não é elaborado um manual para o usuário. 14* 61% É elaborado um Manual do usuário. 9 39% Total % Tabela 61 Elaboração da Documentação do Usuário * Duas empresas não informaram se confeccionam ou não o manual, mas como informaram que o atualizam quando necessário, subentendeu-se que confeccionam a Documentação do Usuário.

64 39% 61% Figura 61 Gráfico da elaboração da Documentação do Usuário Dentre as empresas que elaboram a Documentação do Usuário, pouco mais da metade atualiza quando necessário e a minoria faz processos de verificação e validação do documento. Estes resultados são apresentados na Tabela 62 e no gráfico da Figura 62. Percentual* Quando necessário atualiza-se o Manual do usuário existente. 5 56% O Manual do usuário passa por um processo de verificação. 3 33% Os resultados obtidos no processo de verificação são registrados. 1 11% Correções são feitas no Manual do usuário até que este seja aprovado pelo Cliente. 1 11% Tabela 62 Atualização, verificações e correções na Documentação do Usuário * Percentual calculado com base nas nove empresas que elaboram a documentação do usuário. 100% 80% 60% 40% 20% 0% Não é elaborado um manual para o usuário. É elaborado um Manual do usuário. 56% 33% 11% 11% Quando necessário atualiza-se o Manual do usuário existente. O Manual do usuário passa por um processo de verificação. Os resultados obtidos no processo de verificação são registrados. Correções são feitas no Manual do usuário até que este seja aprovado pelo Cliente. Figura 62 Gráfico de Atualização, verificações e correções na Documentação do Usuário

65 Guia de Operação do produto O Guia de Operação do Produto é um documento que contém as informações necessárias para instalar e gerenciar o Software. A grande maioria das empresas (87%) não elabora este guia, e apenas 13% o confeccionam, ou reutilizam o guia já existente, em casos de novas iterações ou novas versões do software. A Tabela 63 apresenta estes resultados, e a Figura 63 o gráfico correspondente. Percentual Não é elaborado o Guia de Operação do Produto % É elaborado o Guia de Operação do Produto. 3 13% Total % Tabela 63 Elaboração do Guia de Operação do Produto 13% Figura 63 Gráfico da elaboração do Guia de Operação do Produto Dentre as empresas que elaboram o Guia de Operação do Produto, apenas uma atualiza este guia quando necessário. Nenhuma das empresas que realiza um processo de verificação sobre o Guia de Operação do Produto registra os resultados obtidos. Estes resultados podem ser observados na Tabela 64 e no gráfico da Figura 64. Percentual* Quando já existente e necessário, é atualizado o Guia de Operação do Produto. 1 33% Quando elaborado ou atualizado o Guia, este passa por um processo de verificação. 2 67% Tabela 64 Informações sobre a garantia de consistência do Guia de Operação do Produto * Percentual calculado com base as três empresas que elaboram o Guia de Operação do Produto. 87% Não é elaborado o Guia de Operação do Produto. É elaborado o Guia de Operação do Produto, ou é reutilizado um Guia já existente.

66 67% 33% 0% 20% 40% 60% 80% 100% Quando elaborado ou atualizado o Guia, este passa por um processo de verificação. Quando já existente e necessário, é atualizado o Guia de Operação do Produto. Figura 64 Gráfico a garantia de consistência do Guia de Operação do Produto Documentação de manutenção A Documentação de Manutenção descreve a versão do software, incluindo todos os elementos desenvolvidos durante a implementação desta versão, e o ambiente usado para desenvolvimento e testes (ABNT, 2012b). A Tabela 65 apresenta os resultados da questão referente à elaboração ou não da Documentação de Manutenção. Por meio desta Tabela e do gráfico da Figura 65, pode-se verificar que a grande maioria das empresas não elabora esta documentação. Percentual Não é elaborada uma Documentação de Manutenção % Elabora-se uma Documentação de Manutenção. 3 13% Total % Tabela 65 Elaboração da Documentação de Manutenção 13% 87% Não é elaborada uma Documentação de Manutenção. Elabora-se uma Documentação de Manutenção. Figura 65 Gráfico da elaboração da Documentação de Manutenção Foi identificado também que apenas uma das três empresas que elaboram a Documentação de Manutenção realiza uma verificação neste documento (após a elaboração ou atualização), para garantir sua consistência em relação à versão do software a que esta se refere, e registram os resultados encontrados durante a verificação. Estes resultados são apresentados na Tabela 66 e no gráfico da Figura 66.

67 Percentual* Quando elaborada ou atualizada a Documentação de Manutenção, esta passa por um processo de Verificação para garantir sua consistência em relação à versão do software a que 1 33% esta se refere. Quando realizado o processo de verificação na Documentação de Manutenção, os resultados desta verificação são registrados. 1 33% São feitas correções na Documentação de Manutenção até que este documento seja aprovado pelo Gerente do Projeto. 1 33% Tabela 66 Informações sobre a garantia de consistência da Documentação de Manutenção * Percentual calculado com base nas três empresas que confeccionam a Documentação de Manutenção. 33% 33% 33% 0% 20% 40% 60% 80% 100% A Documentação de Manutenção passa por um processo de verificação. Os resultados da verificação são registrados. São feitas correções nesta documentação até obter-se a aprovação do Gerente do Projeto. Figura 66 Gráfico sobre a garantia de consistência da Documentação de Manutenção Entrega do Produto e Encerramento do Projeto Esta questão aborda duas atividades determinadas pela norma: a atividade de Entrega do Produto, pertencente ao processo de Implementação de Software, e a atividade de Encerramento do Projeto do processo de Gerência de Projeto Práticas adotadas ao término de um projeto e entrega final do produto Foi identificado que em pouco mais da metade das empresas a conclusão do projeto é formalizada, sendo ainda menor o número de empresas que documente o aceite do cliente. Este aceite formalizado e assinado pelo cliente atende ao artefato Registro de aceitação requerido pela Norma. Além disso, uma minoria tem um processo para garantir que todos os artefatos do projeto serão atualizados no repositório ao seu final. O resultado desta questão é apresentado na Tabela 67 e no gráfico da Figura 67. Percentual A conclusão do projeto é formalizada % O aceite do cliente é documento e assinado pelo mesmo % Há algum processo que garanta que todos os artefatos do projeto estejam atualizados no Repositório de Projeto após a sua 4 17% conclusão. Nenhuma das práticas citadas. 6 26% Tabela 67 Práticas adotadas ao término de um projeto e entrega final do produto

68 100% 50% 61% 48% 17% 26% 0% A conclusão do projeto é formalizada. O aceite do cliente é documento e assinado pelo mesmo. Ao final do projeto, todos os artefatos estão atualizados no Repositório do Projeto. Nenhuma das práticas citadas. Figura 67 Gráfico de práticas adotadas ao término de um projeto e entrega final do produto Realizando uma compilação dos vinte e dois artefatos solicitados pela norma, a Tabela 68 mostra um panorama da quantidade de empresas que atualmente produzem tais artefatos e estariam propensas a adequação à norma, nesse questionário. Artefato Adoção Observação Declaração de trabalho 61% Plano de Projeto 39% Repositório do projeto 91% Somente 35% com documentos do projeto Registro de reunião 30% Backup do repositório do projeto 91% Somente 57% de todo o projeto Registro de status de progresso 57% Registro de correção 22% Solicitação de mudança 83% Resultados da verificação 10% Resultados da validação 26% Especificação de requisitos 43% Projeto (design) de software; 65% Casos de testes e procedimentos de testes; 48% Registro de rastreabilidade; 13% Relatório de testes; 17% Componente de software; 100% Software; 100% Configuração de software; 100% Guia de operação do produto; 13% Documentação de manutenção; 13% Documentação de usuário de software; 39% Registro de aceitação; 48% Tabela 68 Adequação aos artefatos requisitados pela ISO/IEC 29110

69 Conclusões da pesquisa realizada com as micro e pequenas empresas do Alto Vale do Itajaí Essa pesquisa foi realizada através de um survey com 23 empresas da região do Alto Vale do Itajaí, estado de Santa Catarina, a fim de mapear a adesão dos processos atuais dessas empresas com os requisitos da norma ABNT ISO/IEC 29110, lançada no Brasil em 2012 e voltada especificamente para pequenas empresas de desenvolvimento de software. Através dos resultados obtidos, é possível observar que o perfil das empresas pesquisadas é de micro empresa, tendo a maioria até 10 funcionários e que desenvolvem software padrão com customização. Também se observa que existe um grande desconhecimento da norma em questão (quase 75%). Quanto ao processo, percebe-se que mesmo a norma sendo focada para pequenas empresas, grande parte das atividades e artefatos requeridos não é contemplada pela maioria das empresas. Isso sugere que as empresas teriam um esforço muito grande para aderirem aos requisitos da norma ABNT ISO/IEC 29110, devido às já conhecidas limitações de recursos humanos e financeiros de empresas de pequeno porte, e ao grande número de alterações no processo que seriam necessárias. Espera-se que essa pesquisa seja útil para o desenvolvimento do mercado de software da região, permitindo que as empresas e instituições da área conheçam a realidade e as principais necessidades de melhoria das empresas, podendo promover ações para supri-las. Da mesma forma, espera-se que cada empresa possa fazer uma auto avaliação e comparação com demais empresas da região, podendo promover ações internas de melhoria Processos em BPMN Nesta seção serão apresentados os processos elaborados em BPMN com base na Norma ABNT ISO/IEC Para definição e execução do processos foi escolhida a ferramenta de BPM BonitaSoft (Versão 5.9.1). A escolha deu-se pelo fato desta ferramenta possuir versão gratuita (funcional e não trial) que permite definir e executar um processo de negócio. O BonitaSoft utiliza a notação BPMN para modelagem do processo e sua interface é amigável de fácil utilização. A documentação é vasta e está disponível para livre acesso na Internet. O BonitaSoft oferece integração com vários softwares como, por exemplo, o Alfresco, SugarCRM, Salesforce, suporte a Web Services, além de conexão com bancos de dados como PostgreSQL, MySql, Oracle, entre outros. Outra funcionalidade interessante é a possibilidade de criação de conectores em código Java. Os processos foram organizados nos seguintes diagramas: 29110_Processo Norma 29110_Planejamento Inicial 29110_Análise de requisitos do software 29110_Projeto de Software 29110_Construção do Software 29110_Integração e Testes e software 29110_Elaboração de manuais e guias Cada diagrama contém um ou mais processos. Os processo de Gerência de Projetos e Processo de Implementação de Software foram estruturados em vários sub processos, para uma melhor visualização e compreensão do processo, bem como, para facilitar a sua manutenção.

70 Todos os processos são executáveis e cada tarefa possui uma interface para interagir com o participante do processo. Nas tarefas que requerem a adição de artefato requerido pela Norma ABNT ISO/IEC , foi anexado um modelo para a confecção deste artefato. O processo de desenvolvimento de software é complexo, por isto em algumas tarefas as funcionalidades básica não atendiam as necessidades da tarefa/processo. Por este motivo foi necessário o desenvolvimento de algumas classes de código Java, as quais permitiram ao processo atender as necessidade de um processo de desenvolvimento de software. O Bonita Soft oferece esta possibilidade através da implementação de Conectores Interação entre os processos Os processo Gerência de Projetos e Implementação de Software definidos pela Norma ABNT ISO/IEC foram destrinchados em vários processos. Cada processo compõe ou é composto por outros processos. A Figura 68 apresenta uma visão geral da interação entre os processos elaborados. Figura 68 Visão geral da interação entre os processos dos processos Nesta seção apresenta-se cada diagrama, explicado brevemente cada um de seus processos. Junto com esta breve explicação é apresentado a imagem de cada processo Diagrama 29110_Processo Norma O diagrama 29110_Processo Norma contém os processos: Projeto de desenvolvimento, Avaliação e Controle, Correção de Desvios, Processo de Implementação e Solicitação de mudança. Projeto de desenvolvimento (Figura 69) Este é o processo principal, pois é responsável por iniciar um processo de desenvolvimento de software, chamar os demais processos necessário e finalizar o projeto.

Desenvolvimento de um Ambiente de Engenharia de Software Baseado em Processos utilizando Workflow

Desenvolvimento de um Ambiente de Engenharia de Software Baseado em Processos utilizando Workflow Projeto de Pesquisa: Desenvolvimento de um Ambiente de Engenharia de Software Baseado em Processos utilizando Workflow Janaína Schwarzrock Coordenador: Pablo Schoeffel Membros: Geraldo Menegazzo Varela

Leia mais

Definição do Framework de Execução de Processos Spider-PE

Definição do Framework de Execução de Processos Spider-PE Definição do Framework de Execução de Processos Spider-PE 1. INTRODUÇÃO 1.1 Finalidade Este documento define um framework de execução de processos de software, denominado Spider-PE (Process Enactment),

Leia mais

MODELAGEM DE PROCESSOS

MODELAGEM DE PROCESSOS MODELAGEM DE PROCESSOS a a a PRODUZIDO POR CARLOS PORTELA csp3@cin.ufpe.br AGENDA Definição Objetivos e Vantagens Linguagens de Modelagem BPMN SPEM Ferramentas Considerações Finais Referências 2 DEFINIÇÃO:

Leia mais

Desenvolvimento de Sistemas BPMS. Jhonatas Vicente de Jesus

Desenvolvimento de Sistemas BPMS. Jhonatas Vicente de Jesus Desenvolvimento de Sistemas BPMS Jhonatas Vicente de Jesus Roteiro de apresentação FastBPM TCC Recapitulando alguns Conceitos Sistemas BPMS Um Processo na prática Conclusão TCC - 2011 Desenvolvimento de

Leia mais

O desafio de uma visão mais ampla

O desafio de uma visão mais ampla com SAP NetWeaver BPM Descrição de Solução A competição acirrada tem levado as organizações a adotar novas disciplinas de gestão e empregar recursos tecnológicos avançados, a fim de atingir melhores índices

Leia mais

BPMN (Business Process. George Valença gavs@cin.ufpe.br

BPMN (Business Process. George Valença gavs@cin.ufpe.br BPMN (Business Process Modeling Notation) George Valença gavs@cin.ufpe.br 31/10/2012 Introdução Modelagem de processos No ciclo de vida BPM, a etapa de modelagem de processos consiste em um conjunto de

Leia mais

PROJELER. Solução de código aberto para gerenciamento de processos de negócio

PROJELER. Solução de código aberto para gerenciamento de processos de negócio Otimização e Automação de Processos de Negócio Abril/2008 Solução de código aberto para gerenciamento de processos de negócio Maurício Bitencourt, PMP Diretor Executivo mauricio.bitencourt@projeler.com.br

Leia mais

Apresentação do Portfólio da ITWV Soluções Inteligentes em Tecnologia

Apresentação do Portfólio da ITWV Soluções Inteligentes em Tecnologia P ORTFÓ FÓLIO Apresentação do Portfólio da ITWV Soluções Inteligentes em Tecnologia versão 1.1 ÍNDICE 1. A EMPRESA... 3 2. BI (BUSINESS INTELLIGENCE)... 5 3. DESENVOLVIMENTO DE SISTEMAS... 6 3.1. PRODUTOS

Leia mais

Fase 1: Engenharia de Produto

Fase 1: Engenharia de Produto Fase 1: Engenharia de Produto Disciplina: Análise de Requisitos DURAÇÃO: 44 h O objetivo principal da disciplina é realizar uma análise das necessidades e produzir um escopo do produto. Representará os

Leia mais

Business Process Management [BPM] Get Control. Empower People.

Business Process Management [BPM] Get Control. Empower People. Business Process Management [BPM] Get Control. Empower People. O SoftExpert BPM Suite é uma suíte abrangente de módulos e componentes perfeitamente integrados, projetados para gerenciar todo o ciclo de

Leia mais

Spider-PE: Uma Ferramenta de Apoio à Execução de Processos de Software aderente ao CMMI-DEV e MR-MPS

Spider-PE: Uma Ferramenta de Apoio à Execução de Processos de Software aderente ao CMMI-DEV e MR-MPS Spider-PE: Uma Ferramenta de Apoio à Execução de Processos de Software aderente ao CMMI-DEV e MR-MPS Antônio A. C. Silva 1, Elder J. F. Silva 1, Carlos S. Portela 2, Alexandre M. L. Vasconcelos 2, Sandro

Leia mais

Spider-PM: Uma Ferramenta de Apoio à Modelagem de Processos de Software

Spider-PM: Uma Ferramenta de Apoio à Modelagem de Processos de Software Spider-PM: Uma Ferramenta de Apoio à Modelagem de Processos de Software Renan Sales Barros 1, Sandro Ronaldo Bezerra Oliveira 1 1 Faculdade de Computação Instituto de Ciências Exatas e Naturais (ICEN)

Leia mais

3 Estudo de Ferramentas

3 Estudo de Ferramentas 3 Estudo de Ferramentas Existem diferentes abordagens para automatizar um processo de desenvolvimento. Um conjunto de ferramentas pode ser utilizado para aperfeiçoar o trabalho, mantendo os desenvolvedores

Leia mais

Treinamento BPM e BPMN Apresentação Executiva

Treinamento BPM e BPMN Apresentação Executiva Apresentação Executiva 1 O treinamento de BPM e BPMN tem como premissa capacitar o aluno a captar as atividades relativas a determinado processo da empresa, organizá-las, gerando um fluxograma de atividades/processos,

Leia mais

Processo de Software

Processo de Software Processo de Software Uma importante contribuição da área de pesquisa de processo de software tem sido a conscientização de que o desenvolvimento de software é um processo complexo. Pesquisadores e profissionais

Leia mais

Professor: Rômulo César romulodandrade@gmail.com www.romulocesar.com.br BPMN

Professor: Rômulo César romulodandrade@gmail.com www.romulocesar.com.br BPMN Professor: Rômulo César romulodandrade@gmail.com www.romulocesar.com.br BPMN Benefícios da modelagem Em uma organização orientada a processos, modelos de processos são o principal meio para medir o desempenho

Leia mais

The Open Source Business Process Platform Company. Proposta Comercial. Plataforma Intalio BPP

The Open Source Business Process Platform Company. Proposta Comercial. Plataforma Intalio BPP Proposta Comercial Plataforma Intalio BPP 2 É com grande prazer que apresentamos nossa Proposta Comercial, com o objetivo de fornecer total visibilidade da plataforma Intalio BPP (Business Process Platform),

Leia mais

Conceitos de Processos & BPM

Conceitos de Processos & BPM http://rogerioaraujo.wordpress.com Série Rações Semanais Conceitos de Processos & BPM Parte I Rogério Araújo http://rogerioaraujo.wordpress.com Série Rações Semanais Conceitos de Processos & BPM Parte

Leia mais

UTILIZAÇÃO DA TECNOLOGIA BPMS PARA IMPLEMENTAÇÃO DE PROCESSOS ADERENTES AO MODELO DO MPS.BR

UTILIZAÇÃO DA TECNOLOGIA BPMS PARA IMPLEMENTAÇÃO DE PROCESSOS ADERENTES AO MODELO DO MPS.BR UTILIZAÇÃO DA TECNOLOGIA BPMS PARA IMPLEMENTAÇÃO DE PROCESSOS ADERENTES AO MODELO DO MPS.BR Karin Maria Sohnlein (UNISC) karin.sohnlein@gmail.com Rafael Bortolini (UNISC) rfbortolini@gmail.com Vinicius

Leia mais

FAPS: Ferramenta para apoiar Avaliações Integradas de Processos de Software

FAPS: Ferramenta para apoiar Avaliações Integradas de Processos de Software FAPS: Ferramenta para apoiar Avaliações Integradas de Processos de Software Marcello Thiry 1 2, Christiane Gresse von Wangenheim 1 2, Alessandra Zoucas 12, Leonardo Reis Tristão 1 1 (II-MPS.BR) Incremental

Leia mais

Estudo de Caso da Implantação do Nível G do MPS.BR em Uma Empresa

Estudo de Caso da Implantação do Nível G do MPS.BR em Uma Empresa Estudo de Caso da Implantação do Nível G do MPS.BR em Uma Empresa Dayana Henriques Fonseca 1, Frederico Miranda Coelho 1 1 Departamento de Ciência da Computação Universidade Presidente Antônio Carlos (UNIPAC)

Leia mais

BPM X Workflow. Business Process Management BPM ou Modelagem de Processos de negócio

BPM X Workflow. Business Process Management BPM ou Modelagem de Processos de negócio Business Process Management BPM ou Modelagem de Processos de negócio Metodologia Conjunto de práticas Controle, gerenciamento e integração dos processos Permite a análise, definição, execução, monitoramento

Leia mais

SISTEMA DE WORKFLOW PARA MODELAGEM E EXECUÇÃO DE PROCESSOS DE SOFTWARE. Aluno: Roberto Reinert Orientador: Everaldo A. Grahl

SISTEMA DE WORKFLOW PARA MODELAGEM E EXECUÇÃO DE PROCESSOS DE SOFTWARE. Aluno: Roberto Reinert Orientador: Everaldo A. Grahl SISTEMA DE WORKFLOW PARA MODELAGEM E EXECUÇÃO DE PROCESSOS DE SOFTWARE Aluno: Roberto Reinert Orientador: Everaldo A. Grahl Roteiro de apresentação Introdução Objetivos Fundamentação Teórica Workflow Processo

Leia mais

UNIVERSIDADE ESTADUAL DE MARINGÁ CENTRO DE TECNOLOGIA DEPARTAMENTO DE INFORMÁTICA ENGENHARIA DE SOFTWARE III

UNIVERSIDADE ESTADUAL DE MARINGÁ CENTRO DE TECNOLOGIA DEPARTAMENTO DE INFORMÁTICA ENGENHARIA DE SOFTWARE III UNIVERSIDADE ESTADUAL DE MARINGÁ CENTRO DE TECNOLOGIA DEPARTAMENTO DE INFORMÁTICA ENGENHARIA DE SOFTWARE III FERRAMENTAS DE GERENCIAMENTO DE PROJETOS TRAC E DOTPROJECT ORIETADOS AO RUP ACADÊMICOS: GUSTAVO

Leia mais

Processos de Software

Processos de Software Processos de Software Prof. Sandro Bezerra (srbo@ufpa.br) Adaptado a partir de slides produzidos pelo Prof. Dr. Alexandre Vasconcelos 1/27 Processo Ação regular e contínua (ou sucessão de ações) realizada

Leia mais

BEM-VINDO!!! Apresentação Inicial. Por favor, descreva o seu atual conhecimento sobre Mapeamento de Processos

BEM-VINDO!!! Apresentação Inicial. Por favor, descreva o seu atual conhecimento sobre Mapeamento de Processos Apresentação Inicial BEM-VINDO!!! Por favor, descreva o seu atual conhecimento sobre Mapeamento de Processos 1 Mapeamento de Processos Mapeamento de Processos e Negócios com BPM 2 Ementa Introdução Definição

Leia mais

PDS - DATASUS. Processo de Desenvolvimento de Software do DATASUS

PDS - DATASUS. Processo de Desenvolvimento de Software do DATASUS PDS - DATASUS Processo de Desenvolvimento de Software do DATASUS Coordenação Geral de Arquitetura e Engenharia Tecnológica Coordenação de Padronização e Qualidade de Software Gerência de Padrões e Software

Leia mais

Avaliação do uso de ferramentas de workflow em processos típicos de engenharia de software

Avaliação do uso de ferramentas de workflow em processos típicos de engenharia de software Avaliação do uso de ferramentas de workflow em processos típicos de engenharia de software Walter Itamar Mourão Arcadian Tecnologia S/A. Av. do Contorno 3505, sala 802 Belo Horizonte MG CEP: 30110-090

Leia mais

Business Process Management [BPM] Get Control. Empower People.

Business Process Management [BPM] Get Control. Empower People. Business Process Management [BPM] Get Control. Empower People. O SoftExpert BPM Suite é uma suíte abrangente de módulos e componentes perfeitamente integrados, projetados para gerenciar todo o ciclo de

Leia mais

Uma Implementação do Processo de Garantia da Qualidade usando a Spider-QA, a Spider-CL e o Mantis

Uma Implementação do Processo de Garantia da Qualidade usando a Spider-QA, a Spider-CL e o Mantis Uma Implementação do Processo de Garantia da Qualidade usando a Spider-QA, a Spider-CL e o Mantis Rodrigo Araujo Barbalho 1, Marília Paulo Teles 2, Sandro Ronaldo Bezerra Oliveira 1,2 1 Faculdade de Computação

Leia mais

Engenharia de Software I

Engenharia de Software I Engenharia de Software I Rogério Eduardo Garcia (rogerio@fct.unesp.br) Bacharelado em Ciência da Computação Aula 05 Material preparado por Fernanda Madeiral Delfim Tópicos Aula 5 Contextualização UML Astah

Leia mais

WebAPSEE: Um Ambiente Livre e Flexível Para Gerência de Processos de Software 1

WebAPSEE: Um Ambiente Livre e Flexível Para Gerência de Processos de Software 1 WebAPSEE: Um Ambiente Livre e Flexível Para Gerência de Processos de Software 1 Adailton Lima #, Breno França #, Heribert Schlebbe * Marcelo Silva #, Rodrigo Quites Reis #, Carla Lima Reis # # Laboratório

Leia mais

Workflow como Proposta de. Workflow. O Gerenciamento de Processos. Prof. Roquemar Baldam roquemar@pep.ufrj.br

Workflow como Proposta de. Workflow. O Gerenciamento de Processos. Prof. Roquemar Baldam roquemar@pep.ufrj.br Workflow como Proposta de Automação Flexível O Gerenciamento de Processos Planejamento do BPM Diretrizes e Especificações Seleção de processo críticos Alinhamento de processos à estratégia www.iconenet.com.br

Leia mais

ESPECIFICAÇÃO DO AMBIENTE EXPSEE SEGUNDO O MÉTODO CATALYSIS

ESPECIFICAÇÃO DO AMBIENTE EXPSEE SEGUNDO O MÉTODO CATALYSIS ESPECIFICAÇÃO DO AMBIENTE EXPSEE SEGUNDO O MÉTODO CATALYSIS RESUMO Este artigo apresenta a especificação de um sistema gerenciador de workflow, o ExPSEE, de acordo com a abordagem de desenvolvimento baseado

Leia mais

Implantando um Programa de Melhoria de Processo: Uma Experiência Prática

Implantando um Programa de Melhoria de Processo: Uma Experiência Prática Implantando um Programa de Melhoria de Processo: Uma Experiência Prática Evandro Polese Alves Ricardo de Almeida Falbo Departamento de Informática - UFES Av. Fernando Ferrari, s/n, Vitória - ES - Brasil

Leia mais

PROJETO DE COOPERAÇÃO TÉCNICA INTERNACIONAL. Diretrizes e Estratégias para Ciência, Tecnologia e Inovação no Brasil

PROJETO DE COOPERAÇÃO TÉCNICA INTERNACIONAL. Diretrizes e Estratégias para Ciência, Tecnologia e Inovação no Brasil PROJETO DE COOPERAÇÃO TÉCNICA INTERNACIONAL Diretrizes e Estratégias para Ciência, Tecnologia e Inovação no Brasil Projeto 914 BRA5065 - PRODOC-MTC/UNESCO DOCUMENTO TÉCNICO Nº 02 IMPLANTAÇÃO DE 1 (UM)

Leia mais

BPM E SOA MODELO PARA O DESENVOLVIMENTO CORPORATIVO

BPM E SOA MODELO PARA O DESENVOLVIMENTO CORPORATIVO BPM E SOA MODELO PARA O DESENVOLVIMENTO CORPORATIVO João Felipe D Assenção Faria Arquiteto JEE Especialista SOA/BPM JOÃO FELIPE D ASSENÇÃO FARIA Arquiteto JEE (12 anos) Especialista SOA/BPM (aprox. 4 anos)

Leia mais

Um Processo para Desenvolvimento de Aplicações Web Baseado em Serviços. Autores: Fábio Zaupa, Itana Gimenes, Don Cowan, Paulo Alencar e Carlos Lucena

Um Processo para Desenvolvimento de Aplicações Web Baseado em Serviços. Autores: Fábio Zaupa, Itana Gimenes, Don Cowan, Paulo Alencar e Carlos Lucena Um Processo para Desenvolvimento de Aplicações Web Baseado em Serviços Autores: Fábio Zaupa, Itana Gimenes, Don Cowan, Paulo Alencar e Carlos Lucena Tópicos Motivação e Objetivos LP e SOA Processo ADESE

Leia mais

PROJELER. Componentes da Solução Intalio BPMS 5.2. Maurício Bitencourt 51 21171872 / 51 84087798 mauricio.bitencourt@projeler.com.

PROJELER. Componentes da Solução Intalio BPMS 5.2. Maurício Bitencourt 51 21171872 / 51 84087798 mauricio.bitencourt@projeler.com. Componentes da Solução Intalio BPMS 5.2 Maurício Bitencourt 51 21171872 / 51 84087798 mauricio.bitencourt@projeler.com.br Platinum Implementation Partner 1 Enterprise Edition Software de Código Aberto

Leia mais

INOVANDO UM PROCESSO DE SERVIÇOS DE TI COM AS BOAS PRÁTICAS DO ITIL E USO DE BPMS

INOVANDO UM PROCESSO DE SERVIÇOS DE TI COM AS BOAS PRÁTICAS DO ITIL E USO DE BPMS INOVANDO UM PROCESSO DE SERVIÇOS DE TI COM AS BOAS PRÁTICAS DO ITIL E USO DE BPMS Cilene Loisa Assmann (UNISC) cilenea@unisc.br Este estudo de caso tem como objetivo trazer a experiência de implantação

Leia mais

Integração de Sistemas Corporativos DAS5316. BPM e BPMN. Prof. Ricardo J. Rabelo (rabelo@das.ufsc.br) Alexandre Perin (perin@das.ufsc.

Integração de Sistemas Corporativos DAS5316. BPM e BPMN. Prof. Ricardo J. Rabelo (rabelo@das.ufsc.br) Alexandre Perin (perin@das.ufsc. DAS5316 BPM e BPMN Prof. Ricardo J. Rabelo (rabelo@das.ufsc.br) Alexandre Perin (perin@das.ufsc.br) Florianópolis (SC), 2010. Roteiro BPM Introdução Definição Características Ciclo de vida Integração com

Leia mais

Rastreabilidade e Análise de Impacto: Um caso de aplicação utilizando a ferramenta Visual Studio Team System

Rastreabilidade e Análise de Impacto: Um caso de aplicação utilizando a ferramenta Visual Studio Team System Rastreabilidade e Análise de Impacto: Um caso de aplicação utilizando a ferramenta Visual Studio Team System Tiago Domenici Griffo 1, Gothardo Francisco de Magalhães Santos 1, Rodrigo Becke Cabral 1 1

Leia mais

INTRODUÇÃO A MODELAGEM DE PROCESSOS UTILIZANDO BPMN 1 FÁBIO RODRIGUES CRUZ 2 2.1 CONCEITO DE MODELAGEM DE PROCESSOS UTILIZANDO BPMN

INTRODUÇÃO A MODELAGEM DE PROCESSOS UTILIZANDO BPMN 1 FÁBIO RODRIGUES CRUZ 2 2.1 CONCEITO DE MODELAGEM DE PROCESSOS UTILIZANDO BPMN INTRODUÇÃO A MODELAGEM DE PROCESSOS UTILIZANDO BPMN 1 FÁBIO RODRIGUES CRUZ 2 1 INTRODUÇÃO A Business Process Modeling Notation (BPMN), ou Notação de Modelagem de Processos de Negócio, é um conjunto de

Leia mais

Ciclo BPM: da Estratégia à Medição

Ciclo BPM: da Estratégia à Medição Treinamentos em Gestão por Processos Ciclo BPM: da Estratégia à Medição Da modelagem e análise ao monitoramento da execução de processos automatizados: tudo o que você precisa saber para fazer a Gestão

Leia mais

Definição do Framework

Definição do Framework Definição do Framework 1. Introdução 1.1. Finalidade Este documento tem por finalidade apresentar o mapeamento dos processos de Definição de Processo Organizacional e Avaliação e Melhoria do Processo dos

Leia mais

UTILIZANDO ICONIX NO DESENVOLVIMENTO DE APLICAÇÕES DELPHI

UTILIZANDO ICONIX NO DESENVOLVIMENTO DE APLICAÇÕES DELPHI UTILIZANDO ICONIX NO DESENVOLVIMENTO DE APLICAÇÕES DELPHI Dr. George SILVA; Dr. Gilbert SILVA; Gabriel GUIMARÃES; Rodrigo MEDEIROS; Tiago ROSSINI; Centro Federal de Educação Tecnológica do Rio Grande do

Leia mais

Definições. BPM - Business Process Management. BPMN Business Process Modeling Notation. BPMS Business Process Management System

Definições. BPM - Business Process Management. BPMN Business Process Modeling Notation. BPMS Business Process Management System Definições BPM - Business Process Management BPMN Business Process Modeling Notation BPMS Business Process Management System Erros da Gestão de Processos / BPM 1. Fazer a Gestão sem Automação Desenho,

Leia mais

Processo de garantia da qualidade baseado no modelo MPS.BR. Acadêmico: Anildo Loos Orientador: Everaldo Artur Grahl

Processo de garantia da qualidade baseado no modelo MPS.BR. Acadêmico: Anildo Loos Orientador: Everaldo Artur Grahl Processo de garantia da qualidade baseado no modelo MPS.BR Acadêmico: Anildo Loos Orientador: Everaldo Artur Grahl Roteiro introdução objetivos do trabalho fundamentação teórica desenvolvimento da ferramenta

Leia mais

Professor: Disciplina:

Professor: Disciplina: Professor: Curso: Disciplina: Marcos Morais de Sousa marcosmoraisdesousa@gmail.com marcosmoraisdesousa.blogspot.com Sistemas de informação Engenharia de Software II Gerenciamento de Qualidade CMMI e MPS.BR

Leia mais

- - flow é uma suíte de ferramentas de workflow que permite desenhar e automatizar os processos de negócio das organizações.

- - flow é uma suíte de ferramentas de workflow que permite desenhar e automatizar os processos de negócio das organizações. - - flow é uma suíte de ferramentas de workflow que permite desenhar e automatizar os processos de negócio das organizações. Com Q-flow, uma organização pode tornar mais eficientes os processos que permitem

Leia mais

Alfresco Content Management

Alfresco Content Management Alfresco Content Management Alfresco é um sistema ECM (Enterprise Content Management) também conhecido como GED (Gestão Eletrônica de Documentos) em nosso mercado de porte corporativo para atender a empresas

Leia mais

1 UML (UNIFIED MODELING LANGUAGE)

1 UML (UNIFIED MODELING LANGUAGE) 1 UML (UNIFIED MODELING LANGUAGE) Segundo Tonsig (2003), para conseguir desenvolver um software capaz de satisfazer as necessidades de seus usuários, com qualidade, por intermédio de uma arquitetura sólida

Leia mais

2.0. Uma Nova Geração de Ferramentas para Gestão de Processos de Software. Coordenação Carla Alessandra Lima Reis Rodrigo Quites Reis

2.0. Uma Nova Geração de Ferramentas para Gestão de Processos de Software. Coordenação Carla Alessandra Lima Reis Rodrigo Quites Reis 2.0 Uma Nova Geração de Ferramentas para Gestão de Processos de Software Coordenação Carla Alessandra Lima Reis Rodrigo Quites Reis U n iv e r s id a d e F e d e r a l d o P a r á Q R C o n s u lto r ia

Leia mais

Metodologias de Desenvolvimento de Sistemas. Analise de Sistemas I UNIPAC Rodrigo Videschi

Metodologias de Desenvolvimento de Sistemas. Analise de Sistemas I UNIPAC Rodrigo Videschi Metodologias de Desenvolvimento de Sistemas Analise de Sistemas I UNIPAC Rodrigo Videschi Histórico Uso de Metodologias Histórico Uso de Metodologias Era da Pré-Metodologia 1960-1970 Era da Metodologia

Leia mais

BPMN. Business Process Modeling Notation. Leandro C. López Agosto - 2015

BPMN. Business Process Modeling Notation. Leandro C. López Agosto - 2015 BPMN Business Process Modeling Notation Leandro C. López Agosto - 2015 Objetivos Conceitos Boas práticas de modelagem Elementos do BPMN Tipos de processos Apresentar os conceitos e elementos da notação

Leia mais

RELATÓRIO DE FINALIZAÇÃO DO GRUPO DE TRABALHO SOFTWARE DE CONTROLE DE FLUXO DE PROCESSOS

RELATÓRIO DE FINALIZAÇÃO DO GRUPO DE TRABALHO SOFTWARE DE CONTROLE DE FLUXO DE PROCESSOS MINISTÉRIO DA EDUCAÇÃO SECRETARIA DE EDUCAÇÃO PROFISSIONAL E TECNOLÓGICA INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DE SANTA CATARINA RELATÓRIO DE FINALIZAÇÃO DO GRUPO DE TRABALHO SOFTWARE DE

Leia mais

Ferramenta de apoio a gerência de configuração de software. Aluno: Rodrigo Furlaneto Orientador: Everaldo Artur Grahl

Ferramenta de apoio a gerência de configuração de software. Aluno: Rodrigo Furlaneto Orientador: Everaldo Artur Grahl Ferramenta de apoio a gerência de configuração de software Aluno: Rodrigo Furlaneto Orientador: Everaldo Artur Grahl Roteiro de apresentação Introdução Objetivos Fundamentação Teórica Gerência de Configuração

Leia mais

Reutilização no MPS.BR e no projeto Cooperativa MPS.BR SOFTSUL. Porto Alegre, Agosto de 2008. Sumário

Reutilização no MPS.BR e no projeto Cooperativa MPS.BR SOFTSUL. Porto Alegre, Agosto de 2008. Sumário Reutilização no MPS.BR e no projeto Cooperativa MPS.BR SOFTSUL Porto Alegre, Agosto de 2008. Sumário Apresentação Programa MPS.BR Reutilização no MPS.BR Gerência de reutilização Desenvolvimento para reutilização

Leia mais

MDMS-ANAC. Metodologia de Desenvolvimento e Manutenção de Sistemas da ANAC. Superintendência de Tecnologia da Informação - STI

MDMS-ANAC. Metodologia de Desenvolvimento e Manutenção de Sistemas da ANAC. Superintendência de Tecnologia da Informação - STI MDMS-ANAC Metodologia de Desenvolvimento e Manutenção de Sistemas da ANAC Superintendência de Tecnologia da Informação - STI Histórico de Alterações Versão Data Responsável Descrição 1.0 23/08/2010 Rodrigo

Leia mais

Qualidade de Ferramentas BPM (BPMS) e Avaliação da Abordagem Business

Qualidade de Ferramentas BPM (BPMS) e Avaliação da Abordagem Business 1 de 6 Qualidade de Ferramentas BPM (BPMS) e Avaliação da Abordagem Business Process Management (BPM) em Processos de Software João Leonardo Silveira Neto, Luana Pires Ramos, Adriana Herden, Adriano Bessa

Leia mais

MARATONA CBOK UNICORREIOS

MARATONA CBOK UNICORREIOS MARATONA CBOK UNICORREIOS Capítulo 10 Tecnologia de BPM Bruno Lima, CBPP Analista de sistemas/processos Agenda Porque tecnologia é importante; O que está envolvido na tecnologia de BPM? Modelagem, análise

Leia mais

ANÁLISE COMPARATIVA DAS PRINCIPAIS FERRAMENTAS GRATUITAS DE BUSINESS PROCESS MANAGEMENT (BPM)

ANÁLISE COMPARATIVA DAS PRINCIPAIS FERRAMENTAS GRATUITAS DE BUSINESS PROCESS MANAGEMENT (BPM) 0 UNIJUÍ UNIVERSIDADE REGIONAL DO NOROESTE DO ESTADO DO RIO GRANDE DO SUL DCEEng DEPARTAMENTO DE CIÊNCIAS EXATAS E ENGENHARIAS CURSO DE CIÊNCIA DA COMPUTAÇÃO ANÁLISE COMPARATIVA DAS PRINCIPAIS FERRAMENTAS

Leia mais

WORKFLOW. Mapeamento de Processos de Negócio 26/11/2009. Tadeu Cruz, Prof. M.Sc. TODOS OS DIREITOS RESERVADOS

WORKFLOW. Mapeamento de Processos de Negócio 26/11/2009. Tadeu Cruz, Prof. M.Sc. TODOS OS DIREITOS RESERVADOS WORKFLOW Mapeamento de Processos de Negócio Tadeu Cruz, Prof. M.Sc. TODOS OS DIREITOS RESERVADOS É proibido a reprodução total ou parcial de qualquer forma ou por qualquer meio sem a expressa autorização

Leia mais

Etapas e Desafios. plataforma de BPM corporativa. BPMS Showcase 2014. Kelly Sganderla Consultora de Processos, CBPP Kelly.sganderla@iprocess.com.

Etapas e Desafios. plataforma de BPM corporativa. BPMS Showcase 2014. Kelly Sganderla Consultora de Processos, CBPP Kelly.sganderla@iprocess.com. BPMS Showcase 2014 Etapas e Desafios na seleção de uma plataforma de BPM corporativa Apresentado por: Kelly Sganderla Consultora de Processos, CBPP Kelly.sganderla@iprocess.com.br Apresentando a iprocess

Leia mais

Renata Alves Campos (CoInfo) Sandra Maria Peron de Lima (DP) Março/2012

Renata Alves Campos (CoInfo) Sandra Maria Peron de Lima (DP) Março/2012 Renata Alves Campos (CoInfo) Sandra Maria Peron de Lima (DP) Março/2012 O que é um processo? Um processo é um grupo de atividades realizadas numa seqüência lógica com o objetivo de produzir um bem ou um

Leia mais

Gestão de Processos de Negócio em Curso de Sistemas de Informação:

Gestão de Processos de Negócio em Curso de Sistemas de Informação: Gestão de Processos de Negócio em Curso de Sistemas de Informação: Relato de Experiência Utilizando Software Livre Jessica Lasch de Moura¹, Gabriel Machado Lunardi¹, Andrea Schwertner Charão¹, Patrícia

Leia mais

PRD Tecnologia de Gestão Ltda. Julho/2008

PRD Tecnologia de Gestão Ltda. Julho/2008 O Processo de Desenvolvimento Telescope Julho/2008 Página 1 Sumário Introdução...3 O desenvolvimento de software tradicional...3 O problema da produtividade...3 O problema da portabilidade...6 O problema

Leia mais

Modelagem do Processo de Gerenciamento da Configuração de Software para um Ambiente Integrado

Modelagem do Processo de Gerenciamento da Configuração de Software para um Ambiente Integrado Modelagem do Processo de Gerenciamento da Configuração de Software para um Ambiente Integrado Martha A. D. Abdala Centro Técnico Aeroespacial (CTA) martha@iae.cta.br Resumo Os processos utilizados na engenharia

Leia mais

O Modelo Processo de Software Brasileiro MPS-Br

O Modelo Processo de Software Brasileiro MPS-Br O Modelo Processo de Software Brasileiro MPS-Br Prof. Pasteur Ottoni de Miranda Junior Disponível em www.pasteurjr.blogspot.com 1-Estrutura do MPS-Br ( Softex, 2009) O MPS.BR1 é um programa mobilizador,

Leia mais

Resultados alcançados com a Ferramenta Channel em implementação de sucesso da Gerência de Projetos no nível G de maturidade do MR-MPS

Resultados alcançados com a Ferramenta Channel em implementação de sucesso da Gerência de Projetos no nível G de maturidade do MR-MPS Resultados alcançados com a Ferramenta Channel em implementação de sucesso da Gerência de Projetos no nível G de maturidade do MR-MPS Mauricio Fiorese 1, Alessandra Zoucas 2 e Marcello Thiry 2 1 JExperts

Leia mais

SIGECO07 Sistema Integrado de Gestão de Contas Universidade Federal de Lavras PLANO DE PROJETO 23/09/2007 SIGECO07/GERENCIA/PROJETOS/

SIGECO07 Sistema Integrado de Gestão de Contas Universidade Federal de Lavras PLANO DE PROJETO 23/09/2007 SIGECO07/GERENCIA/PROJETOS/ SIGECO07 Sistema Integrado de Gestão de Contas Universidade Federal de Lavras PLANO DE PROJETO 23/09/2007 SIGECO07/GERENCIA/PROJETOS/ ModeloPlanoProjeto_2007_04_24 SIGECO07_PlanoProjeto_2007_09_23 Página

Leia mais

Prof.: Gilberto Onodera

Prof.: Gilberto Onodera Automação de Sistemas Prof.: Gilberto Onodera Aula 21-maio maio-2007 Revisão Conceitos de Macro-economia: Globalização Objetivo: Entender os principais drivers de mercado Economia de escala Paradigma da

Leia mais

Um Novo Paradigma para Sistemas de Informação

Um Novo Paradigma para Sistemas de Informação Por Antonio Plais Antonio Plais é proprietário da Centus Consultoria, e parceiro da Knowledge Partners International, LLC (KPI) para o mercado brasileiro, possuindo mais de trinta anos de experiência no

Leia mais

Adm. Vinicius Braga admviniciusbraga@gmail.com. Prof. Msc. Wilane Carlos da Silva Massarani wilane@cercomp.ufg.br

Adm. Vinicius Braga admviniciusbraga@gmail.com. Prof. Msc. Wilane Carlos da Silva Massarani wilane@cercomp.ufg.br Adm. Vinicius Braga admviniciusbraga@gmail.com Prof. Msc. Wilane Carlos da Silva Massarani wilane@cercomp.ufg.br Objetivos Contextualização Conceitos Boas práticas de modelagem Elementos do BPMN Tipos

Leia mais

Gestão de Processos de Negócios

Gestão de Processos de Negócios Gestão Operacional da TI Gestão de Processos de Negócios Business Process Management (BPM) Professor: Rômulo César romulodandrade@gmail.com www.romulocesar.com.br Professor NOME: RÔMULO CÉSAR DIAS DE ANDRADE

Leia mais

Padrões de Contagem de Pontos de Função

Padrões de Contagem de Pontos de Função Padrões de Contagem de Pontos de Função Contexto Versão: 1.0.0 Objetivo O propósito deste documento é apresentar os padrões estabelecidos para utilização da técnica de Análise de Pontos de Função no ambiente

Leia mais

Engenharia de Software

Engenharia de Software Engenharia de Software Introdução à Melhoria de Processos de Software baseado no MPS.BR Prof. Maxwell Anderson www.maxwellanderson.com.br Agenda Introdução MPS.BR MR-MPS Detalhando o MPS.BR nível G Introdução

Leia mais

Apresentação 3. Sobre a Módulo Risk Manager Academy 3. Portfólio 4

Apresentação 3. Sobre a Módulo Risk Manager Academy 3. Portfólio 4 2 Apresentação 3 Sobre a Módulo Risk Manager Academy 3 Portfólio 4 RM-01 Conheça o Módulo Risk Manager 4 RM-02 Meu Espaço e Navegação Básica 6 RM-03 Modelando a Organização 8 RM-05 Conhecimentos para Gestão

Leia mais

Manual BizAgi Sistema de Gestão da Qualidade

Manual BizAgi Sistema de Gestão da Qualidade Página 1 de 6 1. INTRODUÇÃO Este manual apresenta alguns elementos básicos da Notação BPMN (Business Process Modeling Notation Notação para Modelagem de Processos de Negócio) que é a representação gráfica

Leia mais

CMMI Conceitos básicos. CMMI Representações contínua e por estágios. Professor Gledson Pompeu (gledson.pompeu@gmail.com)

CMMI Conceitos básicos. CMMI Representações contínua e por estágios. Professor Gledson Pompeu (gledson.pompeu@gmail.com) CMMI Conceitos básicos 113 CMMI integra as disciplinas de engenharia de sistemas e de engenharia de software em um único framework de melhoria de processos. 114 No tocante às disciplinas de engenharia

Leia mais

Políticas de Qualidade em TI

Políticas de Qualidade em TI Políticas de Qualidade em TI Aula 05 MPS.BR (ago/12) Melhoria de Processo do Software Brasileiro Prof. www.edilms.eti.br edilms@yahoo.com Agenda Descrição sumária do MPS.BR - Melhoria de Processo do Software

Leia mais

PROPOSTA DE SOFTWARE DE INSTALAÇÃO PARA UM AMBIENTE INTEGRADO DE GERÊNCIA DE PROJETOS E DE PROCESSOS DE NEGÓCIOS

PROPOSTA DE SOFTWARE DE INSTALAÇÃO PARA UM AMBIENTE INTEGRADO DE GERÊNCIA DE PROJETOS E DE PROCESSOS DE NEGÓCIOS PROPOSTA DE SOFTWARE DE INSTALAÇÃO PARA UM AMBIENTE INTEGRADO DE GERÊNCIA DE PROJETOS E DE PROCESSOS DE NEGÓCIOS Élysson Mendes Rezende Bacharelando em Sistemas de Informação Bolsista de Iniciação Científica

Leia mais

Modelos de processos de desenvolvimento de software

Modelos de processos de desenvolvimento de software Definição Um modelo de processo de software é uma representação abstrata de um processo. Os modelos de processo podem ser desenvolvidos a partir de várias perspectivas e podem mostrar as atividades envolvidas

Leia mais

ARCO - Associação Recreativa dos Correios. Sistema para Gerenciamento de Associações Recreativas Plano de Desenvolvimento de Software Versão <1.

ARCO - Associação Recreativa dos Correios. Sistema para Gerenciamento de Associações Recreativas Plano de Desenvolvimento de Software Versão <1. ARCO - Associação Recreativa dos Correios Sistema para Gerenciamento de Associações Recreativas Versão Histórico da Revisão Data Versão Descrição Autor Página

Leia mais

Metodologia e Gerenciamento do Projeto na Fábrica de Software v.2

Metodologia e Gerenciamento do Projeto na Fábrica de Software v.2 .:: Universidade Estadual de Maringá Bacharelado em Informática Eng. de Software III :. Sistema de Gerenciamento de Eventos - Equipe 09 EPSI Event Programming System Interface Metodologia e Gerenciamento

Leia mais

Como Configurar Tabelas Básicas do OASIS (Informações Básicas)

Como Configurar Tabelas Básicas do OASIS (Informações Básicas) Como Configurar Tabelas Básicas do OASIS (Informações Básicas) O OASIS foi desenvolvido de forma parametrizada para poder atender às diversas particularidades de cada usuário. No OASIS também, foi estabelecido

Leia mais

Módulo 6. Todos os direitos de cópia reservados. Não é permitida a distribuição física ou eletrônica deste material sem a permissão expressa do autor.

Módulo 6. Todos os direitos de cópia reservados. Não é permitida a distribuição física ou eletrônica deste material sem a permissão expressa do autor. Módulo 6 Módulo 6 Desenvolvimento do projeto com foco no negócio BPM, Análise e desenvolvimento, Benefícios, Detalhamento da metodologia de modelagem do fluxo de trabalho EPMA. Todos os direitos de cópia

Leia mais

Engenharia de Software. Apostila I >>> Introdução à ES - HEngholmJr

Engenharia de Software. Apostila I >>> Introdução à ES - HEngholmJr Engenharia de Software Apostila I >>> Introdução à ES - HEngholmJr Histórico de Revisões Data Versão Descrição Autor 12/08/2014 1.0 Criação da primeira versão HEngholmJr Agenda Introdução à Engenharia

Leia mais

Avaliação e Melhorias no Processo de Construção de Software

Avaliação e Melhorias no Processo de Construção de Software Avaliação e Melhorias no Processo de Construção de Software Martim Chitto Sisson Centro Tecnológico Universidade Federal de Santa Catarina (UFSC) Florianópolis SC Brasil martim@inf.ufsc.br Abstract. This

Leia mais

Automação do Processo de Instalação de Softwares

Automação do Processo de Instalação de Softwares Automação do Processo de Instalação de Softwares Aislan Nogueira Diogo Avelino João Rafael Azevedo Milene Moreira Companhia Siderúrgica Nacional - CSN RESUMO Este artigo tem como finalidade apresentar

Leia mais

Apresentação do produto Versão Premium 9.0 (GMPE)

Apresentação do produto Versão Premium 9.0 (GMPE) Apresentação do produto Versão Premium 9.0 (GMPE) Qual a importância que o relacionamento com os clientes tem para a sua empresa? Goldmine CRM é para as empresas que atribuem importância máxima à manutenção

Leia mais

PROCESSOS PODEROSOS DE NEGÓCIO. ideiaconsultoria.com.br 43 3322 2110 comercial@ideiaconsultoria.com.br

PROCESSOS PODEROSOS DE NEGÓCIO. ideiaconsultoria.com.br 43 3322 2110 comercial@ideiaconsultoria.com.br PROCESSOS PODEROSOS DE NEGÓCIO ideiaconsultoria.com.br 43 3322 2110 comercial@ideiaconsultoria.com.br POR QUE ESCREVEMOS ESTE E-BOOK? Nosso objetivo com este e-book é mostrar como a Gestão de Processos

Leia mais

Processo de Desenvolvimento de Software

Processo de Desenvolvimento de Software Unidade IV Introdução aos Padrões de PDS Luiz Leão luizleao@gmail.com http://www.luizleao.com Conteúdo da Unidade 1. CMM / CMMI 2. SPICE 3. ISO 12207 4. MPS/BR CMM - Capability Maturity Model CMM Capability

Leia mais

Nome do Projeto: Revisão do processo de Homologação de Modelo de Dados Tema: Tecnologia da Informação Responsável: SEAD

Nome do Projeto: Revisão do processo de Homologação de Modelo de Dados Tema: Tecnologia da Informação Responsável: SEAD Apresentação TRIBUNAL SUPERIOR ELEITORAL SECRETARIA DE TECNOLOGIA DA INFORMAÇÃO COORDENADORIA DE LOGÍSTICA SEÇÃO DE ADMINISTRAÇÃO DE DADOS E-mail: sead@tse.jus.br Nome do Projeto: Revisão do processo de

Leia mais

Spider-Appraisal: Uma Ferramenta de Apoio à Avaliação Integrada do MPS.BR e CMMI

Spider-Appraisal: Uma Ferramenta de Apoio à Avaliação Integrada do MPS.BR e CMMI Spider-Appraisal: Uma Ferramenta de Apoio à Avaliação Integrada do MPS.BR e CMMI Jñane Neiva Sampaio de Souza 1, Pedro Afonso Aviz 2, Sandro Ronaldo Bezerra Oliveira 1,2 1 Programa de Pós-Graduação em

Leia mais

Documento de Arquitetura

Documento de Arquitetura Documento de Arquitetura A2MEPonto - SISTEMA DE PONTO ELETRÔNICO A2MEPonto - SISTEMA DE PONTO ELETRÔNICO #1 Pág. 1 de 11 HISTÓRICO DE REVISÕES Data Versão Descrição Autor 28/10/2010 1 Elaboração do documento

Leia mais

INTEGRE Diversas fontes de informações em uma interface intuitiva que exibe exatamente o que você precisa

INTEGRE Diversas fontes de informações em uma interface intuitiva que exibe exatamente o que você precisa INTEGRE Diversas fontes de informações em uma interface intuitiva que exibe exatamente o que você precisa ACESSE Informações corporativas a partir de qualquer ponto de Internet baseado na configuração

Leia mais

Metodologia de Gestão e Desenvolvimento de Software. Coordenação Geral de Tecnologia da Informação

Metodologia de Gestão e Desenvolvimento de Software. Coordenação Geral de Tecnologia da Informação Metodologia de Gestão e Desenvolvimento de Software Coordenação Geral de Tecnologia da Informação 2 Índice 1. Processos Organizacionais... 7 1.1. A gestão da demanda... 7 1.2. e Responsabilidades... 7

Leia mais

PREGÃO ELETRÔNICO SRP Nº 26/2011 ANEXO I ESPECIFICAÇÃO DO OBJETO E CONDIÇÕES DE EXECUÇÃO

PREGÃO ELETRÔNICO SRP Nº 26/2011 ANEXO I ESPECIFICAÇÃO DO OBJETO E CONDIÇÕES DE EXECUÇÃO TELECOMUNICAÇÕES BRASILEIRAS S/A TELEBRÁS Vinculada ao Ministério das Comunicações PREGÃO ELETRÔNICO SRP Nº 26/2011 ANEXO I ESPECIFICAÇÃO DO OBJETO E CONDIÇÕES DE EXECUÇÃO 1 ESPECIFICAÇÃO DO OBJETO O objeto

Leia mais

EXPSEE: UM AMBIENTE EXPERIMENTAL DE ENGENHARIA DE SOFTWARE ORIENTADO A PROCESSOS

EXPSEE: UM AMBIENTE EXPERIMENTAL DE ENGENHARIA DE SOFTWARE ORIENTADO A PROCESSOS EXPSEE: UM AMBIENTE EXPERIMENTAL DE ENGENHARIA DE SOFTWARE ORIENTADO A PROCESSOS Edson Alves de Oliveira Junior (1) Igor Fábio Steinmacher (2) eaojunio@bol.com.br ifsteinm@din.uem.br Edna Tomie Takano

Leia mais