UNIJUI UNIVERSIDADE REGIONAL DO NOROESTE DO ESTADO DO RIO GRANDE DO SUL DETEC DEPARTAMENTO DE TECNOLOGIA

Transcrição

1 UNIJUI UNIVERSIDADE REGIONAL DO NOROESTE DO ESTADO DO RIO GRANDE DO SUL DETEC DEPARTAMENTO DE TECNOLOGIA ALINE MARIA MENEGOL KRONBAUER PLANEJAMENTO DE APLICAÇÃO DA MELHORIA DE PROCESSOS DE SOFTWARE BRASILEIRO (MPS.BR) EM INSTITUIÇÕES DO TIPO FÁBRICA DE SOFTWARE. Ijuí 2010

2 ALINE MARIA MENEGOL KRONBAUER PLANEJAMENTO DE APLICAÇÃO DA MELHORIA DE PROCESSOS DE SOFTWARE BRASILEIRO (MPS.BR) ) EM INSTITUIÇÕES DO TIPO FÁBRICA DE SOFTWARE. Trabalho de Conclusão de Curso para a obtenção do título de Bacharel em Sistemas de Informação pela Universidade Regional do Noroeste do Estado do Rio Grande do Sul. Coordenador: Msc. Marcos Ronaldo Cavalheiro Orientador: Ms. Romário Lopes Alcântara Ijuí 2010

3 2 ALINE MARIA MENEGOL KRONBAUER PLANEJAMENTO DE APLICAÇÃO DA MELHORIA DE PROCESSOS DE SOFTWARE BRASILEIRO (MPS.BR) ) EM INSTITUIÇÕES DO TIPO FÁBRICA DE SOFTWARE. Trabalho de Conclusão de Curso para a obtenção do título de Bacharel em Sistemas de Informação pela Universidade Regional do Noroeste do Estado do Rio Grande do Sul. Banca Examinadora: Prof. MSc. Romário Lopes Alcântara Prof. MSc. Marcos R. M. Cavalheiro Ijuí, Dezembro de 2010.

4 3 AGRADECIMENTOS Agradeço a ajuda de meu orientador, Romário, pelo carinho, pela cobrança e principalmente pela paciência com que sempre me auxiliou; Agradeço a meus professores que sempre souberam sanar minhas dúvidas e me dedicaram seu tempo para as explicações extras; Agradeço a meus colegas pelo apoio, estímulo e amizade.

5 4 Seu tempo é limitado, então não percam tempo vivendo a vida de outro. Não sejam aprisionados pelo dogma que é viver com os resultados do pensamento de outras pessoas. Não deixe o barulho da opinião dos outros abafar sua voz interior. E mais importante, tenha a coragem de seguir seu coração e sua intuição. Eles de alguma forma já sabem o que você realmente quer se tornar. Tudo o mais é secundário. Steve Jobs.

6 LISTA DE FIGURAS. Figura 1: Evolução Tecnológica do Software Figura 2: Sobre a Engenharia de Software Figura 3: Modelo por Prototipação Figura 4: Modelo em Espiral Figura 5: Fases do Processo Unificado Figura 6: Qualidade Interna e Externa ISO/IEC 9126: NBR Figura 7: Componentes Figura 8: Gerenciamento de Custos do Projeto Figura 9: Modelos de Padronização... 67

7 6 LISTA DE TABELAS. TABELA 1: Leis da Evolução de Software de Lehman TABELA 2: Níveis de Maturidade do MR-MPS TABELA 3: MPS e CMMI TABELA 4: Custo em R$ da Implementação e Avaliação do Projeto de Melhoria de Software MPS.Br... 68

8 7 LISTA DE SIBLAS E ABREVIATURAS. AP: Atributo de Processo CMMI: Capability Maturity Model Integration EAP: Estrutura Analítica de Projeto ETM: Equipe Técnica do Modelo FCC: Fórum de Credenciamento e Controle FINEP: Financiadora de Estudos e Projetos IA: Instituição Avaliadora IEC: International Electrotechnical Commission II: Instituição Implementadora IOGE: Instituição Organizadora de Grupo de Empresas ISO: International Organization for Standardization MA-MPS: Método de Avaliação para Melhoria de Processo de Software MN-MPS: Modelo de Negócio para Melhoria de Processo de Software MPS.BR: Melhoria de Processo do Software Brasileiro MR-MPS: Modelo de Referência para Melhoria de Processo de Software PMBOK: Guia do Conjunto de Conhecimentos em Gerenciamento de Projetos PMI: Project Management Institute

9 8 PU: Processo Unificado RAP: Resultado do Atributo de Processo RUP: Rational Unified Process SOFTEX: Associação para Promoção da Excelência do Software Brasileiro TI: Tecnologia da Informação UML: Unified Modeling Language

10 SUMÁRIO. RESUMO INTRODUÇÃO UM POUCO SOBRE SOFTWARE Aplicações de Software Software de Sistemas Software de Tempo Real Software Comercial Software Científico Software Embutido Software de Computador Pessoal Software de Inteligência Artificial Evolução do Software ENGENHARIA DE SOFTWARE CONCEITOS E ASPECTOS Paradigmas da Engenharia de Software Principais Paradigmas da Engenharia de Software O Modelo em Cascata O Modelo Prototipação O Modelo em Espiral O Modelo RUP QUALIDADE DE SOFTWARE Melhoria da Qualidade de Software Alguns Modelos de Qualidade de Software O Modelo CMMI O Modelo ISO O Modelo MPS PROJETO MPS.BR Normas Envolvidas Estruturas de Apoio Descrição do Modelo MPS... 36

11 O Modelo de Referência O Método de Avaliação O Modelo de Negócio Níveis de Maturidade Nível G Parcialmente Gerenciado Nível F Gerenciado Nível E Parcialmente Definido Nível D Largamente Definido Nível C Definido Nível B Gerenciado Quantitativamente Nível A Em Otimização PLANEJAMENTO DE APLICAÇÃO DA MELHORIA DE PROCESSOS DE SOFTWARE BRASILEIRO (MPS.BR) EM INSTITUIÇÕES DO TIPO FÁBRICA DE SOFTWARE Análise da Situação Atual Aspectos Referentes à Empresa Os Profissionais e suas Características Conscientização e Treinamento Análise dos Processos da Empresa Gerenciamento de Processos Resultados Esperados para o Gerenciamento de Processos Abordados pelo Nível G Gerenciamento de Requisitos Levantamento de Requisitos Resultados Esperados para o Gerenciamento de Requisitos Abordados pelo Nível G Custos Comprometimento e Controle Benefícios Comparativos Comparativo em Relação aos Custos CONSIDERAÇÕES FINAIS REFERÊNCIAS BIBLIOGRÁFICAS ANEXOS... 75

12 11 ANEXO A: Exemplo de aplicação de um modelo de placar para avaliação de projetos (Viabilidade) ANEXO B: Modelo de questionário para reconhecimento da empresa

13 12 RESUMO. O setor tecnológico está sendo utilizado cada vez mais em uma ampla variedade de áreas de aplicação, freqüentemente produzindo sistemas de informações maiores e mais complexos. Em função de participar amplamente no cotidiano das pessoas e organizações, as atividades de produção e controle da qualidade de software tornam-se vitais para a difusão e permanência desta tecnologia no mercado. Neste contexto, a abordagem aqui proposta visa fornecer um meio de visualização genérica da qualidade de software inserida nas organizações, além de resgatar previamente um pouco do ciclo de evolução dos softwares e de aspectos da história da engenharia desse produto. A melhoria de processos de software se torna indispensável para as organizações frente à tamanha concorrência. Pensando nisso é que, nesta pesquisa, far-se-á um estudo detalhado de como se dá o processo do projeto MPS.Br (Melhoria de Processos de Software Brasileiro), quais as etapas existentes, qual a importância desse projeto e, por último como se dá a implementação do Nível G de aplicação do Projeto MPS.Br em empresas do tipo fábrica de software. Palavras-chave: Software - Engenharia de Software - Qualidade de Software MPS.Br.

14 INTRODUÇÃO. O mundo real está em constante mudança, e sistemas são feitos para refletir comportamentos do mundo real (Gall, 1997). Isto nos remete a questão de que, além de somente evoluir, o software deve acompanhar a evolução do usuário e de seus interesses, bem como da organização, e, a questão da padronização é importante para estabelecer um norte a ser seguido. O projeto MPS.Br surgiu em dezembro de 2003 com o objetivo de ser uma alternativa para micro, pequenas e médias empresas em relação a melhoria de processos de software. Esta pesquisa tem como meta iniciar uma abordagem teórica na área de melhoria de processos de software, expor os métodos usados e a estrutura do projeto MPS.Br (Melhoria de Processos de Software Brasileiro). Também é objetivo desta pesquisa, a conscientização das empresas de que devem fazer parte de processos de melhoria de software, alertar as organizações e profissionais para a padronização e chamar a atenção para o crescimento da indústria de software de qualidade em nosso país. Portanto, o trabalho a seguir, contará com um histórico da evolução e também aspectos referentes à Engenharia de Software, trazendo conceitos e abordando alguns paradigmas e modelos de processos de software. Este, também contará com uma breve explanação dos conceitos de qualidade e melhoria de software, passando por questões de padronização e abordando alguns modelos existentes. Posteriormente, contará com uma demonstração da estrutura do projeto MPS.Br, de seus componentes e de como é feito o acompanhamento de projetos de melhoria de software. O Modelo de Referência será um pouco melhor detalhado, pois este é a base para toda a aplicabilidade das melhorias, observando que o

15 14 mesmo contém a explanação de quais os requisitos necessários para se iniciar com a implementação do projeto. A fase mais específica fica por conta da abordagem da implementação do Nível G ou Nível Parcialmente Gerenciado do Modelo MPS.Br, trazendo aspectos pertinentes a esse nível de maturidade e sugestões de como planejar a implementação e dar continuidade às tarefas propostas no cronograma e planejamento do projeto de desenvolvimento de softwares. Esta pesquisa possibilita uma visão global e genérica de como implementar o primeiro nível do Modelo MPS, iniciando pela análise de aspectos e processos já praticados no dia-a-dia organizacional, passando pelo planejamento de ações, custo e tempo de projeto levando em consideração o que a empresa já tem instituído em seu dia-a-dia e o que pode mudar a partir da aplicação do nível G de maturidade. Todos esses aspectos serão devidamente ponderados ao longo deste estudo, trazendo soluções para melhor atender aos Guias propostos pelo Modelo MPS e comparações entre o modelo proposto e o CMMI e ainda explanando os possíveis benefícios que o Projeto MPS.Br poderá trazer ao meio organizacional e ao que se propõe o nível de maturidade G ou Parcialmente Gerenciado do Projeto de Melhoria de Processos de Software Brasileiro.

16 1. UM POUCO SOBRE SOFTWARE O Software é um mecanismo que torna possível o aproveitamento e a vazão do potencial da microeletrônica. É um produto que evoluiu de uma ferramenta de análise de informações e de resolução de problemas especializados para uma grande indústria da programação. Ninguém na década de 1950 poderia ter previsto que o software fosse se tornar uma tecnologia indispensável para negócios, ciência e engenharia; que o software fosse permitir a criação de novas tecnologias (por exemplo, engenharia genética), a extensão de tecnologias existentes (por exemplo, telecomunicações), e o declínio de antigas tecnologias (por exemplo, a indústria tipográfica); que o software se tornaria a força motriz por trás da revolução do computador pessoal; que produtos de software em pequenas embalagens seriam comprados pelos consumidores em centros comerciais da vizinhança; que uma empresa de software fosse se tornar maior e mais influente que a maioria das empresas da era industrial; que uma vasta rede guiada por softwares, chamada internet, evoluiria e modificaria tudo, desde a pesquisa em bibliotecas até a maneira de os consumidores comprarem e, até mesmo, os hábitos de marcas encontro dos adultos jovens (e não tão jovens). (PRESSMANN, 2008) O produto de software não é feito através de um processo mecânico, mas sim projetado e desenvolvido por engenharia. Geralmente são criados por meio de um conjunto de convenções que mapeiam as exigências dos clientes para só então transformá-las em um código executável em máquina, ou seja, a linguagem de programação. O que chama a atenção para o software e o que fez com que esse produto fosse tão difundido foi a variedade ilimitada de usos a que se dispõe, além da alta velocidade e da incrível capacidade de armazenamento de informações.

17 Aplicações de software Software de sistemas Segundo Pressmann (2008) é uma coleção de programas escritos para servir a outros programas. Tem a característica de manter uma relação de interação com o hardware bastante acentuada, múltiplos usuários, operações concorrentes, recursos compartilhados, gestão de processos, estruturas de dados complexas e múltiplas interfaces externas. Como exemplo Pressman cita compiladores, editores, acionadores, softwares de rede, entre outros Software de tempo real Um sistema de tempo real é um sistema cujo funcionamento correto depende dos resultados produzidos por ele e do tempo em que esses resultados são produzidos. (NOGUEIRA, 2010). Não esquecendo que um sistema de tempo real deve responder dentro de um determinado tempo pré-estipulado Software comercial É o software desenvolvido por uma empresa com o objetivo de lucrar com sua utilização. (WIKIPEDIA, 2010) Geralmente esse tipo específico de software é usado nas operações comerciais e nas tomadas de decisões administrativas.

18 Software científico números. Esses são sistemas que tem como característica o processamento de Software embutido Reside dentro de um produto ou sistema e é usado para implementar e controlar características e funções para o usuário final e para o próprio sistemas. O software embutido pode realizar funções muito limitadas e particulares (por exemplo, o controle de teclado para um forno de microondas) ou fornecer função significativa e capacidade de controle (por exemplo, funções digitais em um automóvel tais como controle de combustível, mostradores do painel e sistemas de frenagem etc.). (PRESSMANN, 2008) Software de computador pessoal Para Pressmann (2008), são os softwares que entraram em efervescência na última década, tais como processamento de textos, planilhas eletrônicas, computação gráfica, diversões, gerenciamento de dados, aplicações financeiras pessoais e comerciais, redes externas ou acesso a banco de dados, são apenas algumas das centenas de aplicações Software de inteligência artificial O software para inteligência artificial faz uso de algoritmos não-numéricos para resolver problemas complexos que não são passíveis de computação

19 18 ou análise direta. Aplicações nessa área incluem robótica, sistemas especialistas, reconhecimento de padrões (de imagem e de voz), redes neurais artificiais, prova de teoremas e jogos. (PRESSMAN, 2008) 1.2. Evolução do Software Indubitavelmente, a tecnologia de software está sendo utilizada cada vez mais em uma ampla variedade de áreas de aplicação. Desta forma, seu correto funcionamento torna-se essencial para o sucesso do negócio envolvido e para a segurança do ser humano (ISO, 2005). O termo evolução reflete um processo de mudança progressivo nos atributos ou características da entidade que está evoluindo. (LEHMAN e RAMIL, 2002) Uma entidade ou uma coleção de entidades podem ser ditas a evoluir, se o seu valor ou capacidade se altera ao longo do tempo. Isto significa que individualmente ou coletivamente, as entidades se vão adaptando em função de um ambiente em mudança. (FONTE, Nelson Baptista, 2010) Lehman (2002) cita os softwares do tipo E que são programas ou sistemas de software que ajudam a resolver um problema ou realizam atividades do mundo real. Estes tipos de sistemas são propícios a mudança e atualização, logo, a uma evolução. A Tabela 1 traz elencadas as leis de evolução de softwares do tipo E criadas por Lehman (2002). TABELA 1: Leis da Evolução de Software de Lehman. Nº / ANO NOME LEI I (1974) II (1974) III (1974) IV (1978) Mudança Contínua Aumento da Complexidade Auto-regulação Conservação da estabilidade organizacional Um sistema do tipo E tem de ser continuadamente adaptado, caso contrário, tornar-se-á progressivamente menos satisfatório de usar. Caso um sistema do tipo E evolua, a sua complexidade tende a aumentar, a não ser que exista trabalho com o intuito de manter ou reduzir a complexidade atual. Todos os processos evolutivos dos sistemas do tipo E são auto-regulados. O ritmo da atividade média nos processos do tipo E, tende a se manter constante durante a vida operacional do sistema ou fases dessa vida.

20 19 V (1978) VI (1991) VII (1996) Conservação da familiaridade Crescimento Contínuo Declínio da Qualidade Sistemas de Resposta VIII (1996) (reconhecida em 1971, formulada em 1996) Fonte: (LEHMAN, 2002). Em geral, a média do crescimento incremental dos sistemas do tipo E tende a diminuir. A capacidade funcional dos sistemas do tipo E tem de ser aumentada continuamente, para manter a satisfação do utilizador durante a vida útil do sistema. Embora sejam tomadas rigorosas medidas que visam a adaptação perante a mudança, a qualidade dos sistemas de tipo E tende a diminuir conforme vai evoluindo. Processos evolutivos do tipo E são sistemas de respostas multi-nível, multi-ciclo e multi-agente. A Figura 1 traz um breve histórico do software nos últimos anos. Figura 1: Evolução Tecnológica do Software Fonte: (SANTOS, Priscila Cunha, 2010).

21 20 2. ENGENHARIA DE SOFTWARE CONCEITOS E ASPECTOS Na engenharia de software há soluções melhores e soluções piores, não há soluções certas e soluções erradas, não há medidas objetivas de sucesso. (Ian Sommerville, 2006, apud Anders Lyhne Christensen, 2009/2010, apud Manuel Menezes de Sequeira, 2009/2010). Abaixo uma gravura interessante que mostra a engenharia de software em vários aspectos, abordando o assunto do ponto de vista de diversos cargos ocupados por profissionais da área. Figura 2: Sobre a Engenharia de Software Fonte: (WORDPRESS.COM, 2008). A Figura 2 objetiva mostrar, de uma forma humorística, a falta de comunicação, de normas e de padronização dentre as diferentes etapas existentes na elaboração de um produto. Interpretando o que é mostrado, pode-se perceber a falta ou a má aplicação da engenharia, trazendo gastos desnecessários e projetos insatisfatórios.

22 21 A engenharia de software visa englobar todos os aspectos a cerca da produção de software, tem como objetivo principal e fundamental a construção de sistemas que serão usados por outras pessoas e empresas em seu cotidiano e que esses sistemas sejam extremamente confiáveis e manuteníveis Paradigmas da Engenharia de Software São estratégias definidas e utilizadas para o desenvolvimento de software, abrangem métodos, ferramentas e procedimentos. Funcionam com um tipo de roteiro para nortear desenvolvedores no sentido de padronização e organização de software Principais Paradigmas da Engenharia de Software No dicionário da língua portuguesa, paradigma significa modelo, padrão, protótipo. Conjunto de unidades suscetíveis de aparecerem num mesmo contexto, sendo, portanto, comutáveis e mutuamente exclusivas. No paradigma, as unidades têm, pelo menos, um traço em comum (a forma, o valor ou ambos) que as relaciona, formando conjuntos abertos ou fechados, segundo a natureza das unidades. Pode-se dizer que paradigma de engenharia de software é um modelo padrão a ser seguido para o desenvolvimento do software em si. Este modelo deve ser de certa forma, escolhido, levando em consideração os aspectos positivos e negativos e a realidade do produto a ser criado.

23 O Modelo em Cascata Também chamado de clico de vida clássico, prega um desenvolvimento linear e seqüencial. O projeto passa por etapas, na quais só poderá passar para a próxima fase quando a anterior tiver sido totalmente concluída, não é permitido retornar e é justamente esse o seu ponto fraco, pois dessa forma não permite a revisão no processo e conseqüente alteração. A vantagem do desenvolvimento cascata é que ele permite controle departamental e gerencial. Um planejamento pode ser atribuído com prazo final para cada estágio de desenvolvimento e um produto pode prosseguir no processo de desenvolvimento, teoricamente ser entregue no prazo. O desenvolvimento move do conceito, através do projeto (design), implementação, teste, instalação, descoberta de defeitos e termina com a operação e manutenção. Cada fase de desenvolvimento prossegue em uma ordem estrita, sem qualquer sobreposição ou passos iterativos. (PRESSMAN, 2006) O Modelo por Prototipação Idealmente, o protótipo serve como um mecanismo para identificação dos requisitos do software. Se um protótipo executável é elaborado, o desenvolvedor tenta usar partes de programas existentes ou aplicar ferramentas (por exemplo, geradores de relatório, gestores de janelas etc.) que possibilitem programas executáveis serem gerados rapidamente. (PRESSMAN, 2006) O modelo de prototipagem inicia a partir de uma solicitação de proposta enviada pelo cliente aos desenvolvedores do software e é construído em período curto de tempo com a explanação de todos os requisitos para que os mesmos sejam examinados e questões pertinentes sejam esclarecidas. Os clientes podem fazer experimentações com o modelo e decidir se satisfaz as suas necessidades ou se serão necessárias alterações.

24 23 FIGURA 3: Modelo por Prototipação Fonte: (PRASS, S/D) A Figura três (3) ilustra o modelo por prototipação, o cliente é o primeiro a ser questionado e ouvido, somente após as suas sugestões e exigências o modelo passa para a fase de desenho e construção e para finalizar a etapa, o cliente faz a avaliação do modelo proposto e pode optar por aprovar o projeto ou então por realizar modificações. Pressman (2006) também afirma que: Apesar de a prototipagem poder ser usada como um modelo de processo independente, ela é mais comumente usada como uma técnica que pode ser implementada dentro do contexto de qualquer um dos modelos de processo existentes. Independentemente da maneira como é aplicado, o paradigma de prototipagem auxilia o engenheiro de software e o cliente a entenderem melhor o que deve ser construído quando os requisitos estão confusos O Modelo em Espiral De certa forma é uma seleção de características do modelo por prototipação e também do modelo em cascata, com o acréscimo de um elemento: a análise de riscos. Segundo Pressman (2006), usando o modelo espiral, o software é desenvolvido numa série de versões evolucionárias. Durante as primeiras iterações,

25 24 as versões podem ser um modelo de papel ou protótipo. Durante as últimas iterações, são produzidas versões cada vez mais completas do sistema submetido à engenharia. FIGURA 4: Modelo em Espiral FONTE: (BOEHM, S/D) A Figura 4 traz o modelo em espiral através da ótica de Boehm (S/D). A primeira etapa é a comunicação com o cliente, o levantamento de requisitos com o mesmo, suas sugestões e exigências. A fase seguinte é a de planejamento do projeto em si e a terceira etapa aborda o levantamento e análise de riscos. A engenharia, ou seja, a estrutura do projeto é feita na etapa quatro (4). A avaliação do cliente é a penúltima etapa e, após tudo ter sido devidamente aprovado, passa-se para a fase final onde é realizada a construção e entrega do mesmo. Ao mesmo tempo em que as etapas vão sendo alcançadas, Boehm emprega que cada uma delas apresenta uma divisão de processos, que seriam o desenvolvimento dos conceitos, desenvolvimento do novo produto, melhora do produto e, manutenção do produto.

26 O Modelo RUP. De certo modo, o processo unificado (PU) é uma tentativa de apoiar-se nos melhores recursos e características dos modelos convencionais de processo de software, mas caracterizá-los de um modo que implemente muitos dos melhores princípios de desenvolvimento ágil de softwares. (PRESSMAN, 2006). O processo unificado racional, ou simplesmente modelo RUP é considerado incremental, pois versões vão sendo criadas e nelas, feitas melhorias e iterativo, é um modelo orientado a objetos e que adequado à UML. O RUP prega que o processo seja adaptável, que haja um balanceamento nas prioridades dos interessados, que o grau de colaboração entre as equipes seja elevado e que haja agregação continuada de valor entre outros princípios chaves. (MORIYA, 2007). O modelo é formado por dois vetores, que são o dinâmico e o estático. O vetor estático (eixo y), chamado de Method Content, descreve como o software é desenvolvido. Esse vetor lista as nove (9) disciplinas do RUP e abrange todo o modo como as coisas são desenvolvidas. O eixo x por sua vez, captura tudo isso e distribui no tempo através de fases, iterações, atividades e sub-atividades, gerando processos. (MORIYA, 2007) As fases do modelo RUP são cinco (5). A fase inicial é a de concepção do projeto, nela a interação com o cliente é fundamental, pois é feito o levantamento de requisitos e o planejamento do projeto com um todo. Depois do planejamento vem a fase de elaboração onde a comunicação com o cliente continua e se inicia a modelagem. Na fase de construção, os componentes de software são desenvolvidos e finalizados. A próxima fase é a de transição onde são dados os ajustes finais e se inicia a implantação do software, também é nessa fase que são feitas as avaliações por parte dos usuários. A última fase do modelo RUP é a produção, a implantação é continuada e finalizada e também é feito um acompanhamento para controle das funcionalidades do software. Essas cinco (5) fases estão ilustradas na Figura 5.

27 26 FIGURA 5: Fases do Processo Unificado. FONTE: (PRESSMAN, 2006) É provável que, ao mesmo tempo em que as fases de construção, transição e produção estejam sendo conduzidas, o trabalho já tenha sido iniciado no incremento de software seguinte. Isso significa que as cinco fases do Processo Unificado não ocorrem em sequência, mas em titubeante concorrência. (PRESSMANN, 2006)

28 27 3. QUALIDADE DE SOFTWARE SOMMERVILLE (2004), diz que: Processo de software é um conjunto de atividades e resultados associados que levam à produção de um produto de software. Esse processo pode envolver o desenvolvimento de software desde o início, embora, cada vez mais, ocorra o caso de um software novo ser desenvolvido mediante a expansão e a modificação de sistemas já existentes. Qualidade é fator crítico de sucesso para a indústria de software. Para que se tenha um setor de software competitivo, nacional e internacionalmente, é essencial que os empreendedores do setor coloquem a eficiência e a eficácia dos seus processos em foco nas empresas, visando à oferta de produtos de software e serviços correlatos conforme padrões internacionais de qualidade. (GUIA DE AVALIAÇÃO, 2009) Alcançar competitividade pela qualidade, para as empresas de software, implica tanto na melhoria da qualidade dos produtos de software e serviços correlatos, como dos processos de produção e distribuição de software. (GUIA GERAL, A engenharia de software, entre outros assuntos priva pelo desenvolvimento de produtos de software de qualidade. A qualidade de software é uma área de conhecimento da engenharia de software que objetiva garantir a qualidade do software através da definição e normatização de processos de desenvolvimento. Apesar dos modelos aplicados na garantia da qualidade de software atuarem principalmente no processo, o principal objetivo é garantir um produto final que satisfaça às expectativas do cliente, dentro daquilo que foi acordado inicialmente. (WIKIPEDIA, 2010) A aplicação de qualidade de software surgiu devido a vários aspectos relacionados à organização, planejamento e padronização em seu desenvolvimento.

29 28 A tarefa de elaborar um sistema eficiente ficava antes somente por conta dos desenvolvedores, que a faziam de acordo com seus princípios de organização, entretanto, com a rotatividade de profissionais, isso causava danos as organizações pois a manutenção dos sistemas se tornava demasiadamente complexa uma vez que um programador pensa totalmente diferente de outro. A conseqüência desse turbilhão de problemas foi a criação e desenvolvimento de padrões voltados para a melhoria da qualidade para os produtos de software Melhoria da Qualidade de Software A melhoria da qualidade de software pode ser dividida em melhoria de qualidade de processo de software e melhoria de qualidade de produto de software. As normas para qualidade de produto de software possuem características que um produto com qualidade deve ter, modo de medir essas características de qualidade e descrições para se fazer a avaliação do produto. As normas para obtenção de qualidade de processo de software fazem um estudo dos requisitos necessários ao cliente, criam um ciclo de vida para os processos e, por final, realizam a instalação e manutenção do mesmo. É através da melhoria nos processos de software que se visa chegar a um desenvolvimento de qualidade e a um produto final que satisfaça o mercado em geral, pois ela envolve diferentes aspectos, dentre eles temos os técnicos, os gerenciais e até mesmo, os culturais: I) Alinhamento das ações de melhoria ao contexto; II) Montar uma estratégia e estabelecer quais os objetivos de negócio da organização; III) Escolha de um modelo de processo para ter como referência, por exemplo, CMM, ISO/IEC (SPICE e CMMI);

30 29 IV) Escolha de um método para a melhoria de produtos (por exemplo, IDEAL e Guia 15504); V) Conhecimento do estado atual das práticas da organização; VI) Planejamento; VII) Implantação de ações de melhoria; VIII) Acompanhamento, medição e institucionalização da melhoria. Além desses aspectos, ainda existe a definição, utilização e melhoria contínua dos processos envolvidos na aquisição, fornecimento, desenvolvimento, operação, manutenção e suporte de sistemas de software Alguns Modelos de Qualidade de Software O MODELO CMMI O CMMI é um modelo reconhecido internacionalmente e considerado muito importante na padronização de regras que unem várias disciplinas para atingir um conjunto de melhores práticas de programação. Porém, existem problemas de custo nesse modelo, pois ele se torna inviável para empresas de pequeno e médio porte. O modelo SW-CMM (Software Capability Maturity Model) foi definido pelo SEI (Software Engineering Institute) a pedido do Departamento de Defesa dos Estados Unidos. A partir de 1991, foram desenvolvidos CMMs para várias disciplinas (Engenharia de Sistemas, Engenharia de Software, Aquisição de Software, Gerência e Desenvolvimento da Força de Trabalho, Desenvolvimento Integrado do Processo e do Produto). Embora estes modelos tenham mostrado sua utilidade, o uso de múltiplos modelos se mostrou problemático. O CMMI surgiu para resolver o problema de utilização de vários modelos e é o resultado da evolução do SW- CMM, SECM (System Engineering Capability Model) e IPD-CMM (Integrated

31 30 Product Development Capability Maturity Model). É, portanto, o sucessor destes modelos. Além disso, o framework CMMISM foi desenvolvido para ser consistente e compatível com a ISO/IEC Em 2006 foi publicada a versão 1.2 do CMMI, o CMMI-DEV (CMMI for Development). O modelo CMMI foi baseado e tem seus objetivos voltados para a qualidade total e também prioriza o amadurecimento gradativo do processo de desenvolvimento de softwares dentro das organizações. Ele possui 5 (cinco) níveis de maturidade. Organizações que alcançarem o nível inicial do CMMI, ou seja o nível 1, estão aptos a obter softwares de alta qualidade, mas isto depende do desempenho dos desenvolvedores da equipe. Para alcançar o nível 2 (dois), as organizações devem acompanhar e documentar os métodos voltados ao gerenciamento de vários aspectos do desenvolvimento de software para assegurar o cumprimento de prazos e custos. O nível 3 (três) trata da documentação, integração e padronização dos processos padrão para as organizações, todos os projetos terão de usar uma versão aprovada e adaptada para o seu desenvolvimento e manutenção. As avaliações do software são tratadas no nível 4 (quatro), o processo e o produto de software são avaliados e, a partir daí, o gerente pode tomar decisões a cerca de como atuar no próprio processo. No último nível, a questão tratada é a continuidade na melhoria dos processos. À medida que uma organização cresce em termos de maturidade, ela institucionaliza seu processo de desenvolvimento de software através de políticas, normas e estruturas organizacionais, as quais geram uma infra-estrutura e uma cultura de suporte aos métodos e procedimentos de desenvolvimento.

32 O MODELO ISO 9126 Esta norma foi publicada em 1991, contendo características que definem um produto de qualidade. A ISO/IEC 9126 é uma norma ISO para qualidade de produto de software, que se enquadra no modelo de qualidade das normas da família Em 1996 foi lançada a norma brasileira correspondente, a NBR Após a publicação, foram lançadas diversas revisões e melhorias e foram então criadas divisões para esta norma: I) ISO/IEC : Modelo de Qualidade; II) ISO/IEC : Métricas Externas; III) ISO/IEC : Métricas Internas; IV) ISO/IEC : Métricas de Qualidade em Uso. A norma ISO/IEC 9126 está focada principalmente na qualidade de software e propõe atributos para o mesmo. FIGURA 6: Qualidade interna e externa ISO/IEC 9126: NBR13596 Fonte: (WIKIPEDIA, 2010) A Figura 5 demonstra os seis (6) atributos pertencentes a qualidade interna e externa de software e também as suas sub-características.

33 O MODELO MPS Busca-se que o modelo MPS seja adequado ao perfil de empresas com diferentes tamanhos e características, públicas e privadas, embora com especial atenção às micro, pequenas e médias empresas. Também se espera que o modelo MPS seja compatível com os padrões de qualidade aceitos internacionalmente e que tenha como pressuposto o aproveitamento de toda a competência existente nos padrões e modelos de melhoria de processo já disponíveis. Dessa forma, ele tem como base os requisitos de processos definidos nos modelos de melhoria de processo e atende a necessidade de implantar os princípios de engenharia de software de forma adequada ao contexto das empresas, estando em consonância com as principais abordagens internacionais para definição, avaliação e melhoria de processos de software. (GUIA DE AVALIAÇÃO, 2009)

34 33 4. Projeto MPS.BR Surgiu em dezembro de 2003 através de uma parceria entre a Softex (Associação para Promoção da Excelência do Software Brasileiro), Governo representado pelo Ministério da Ciência e Tecnologia (MCT), Financiadora de Estudos e Projetos (FINEP), do Serviço Brasileiro de Apoio às Micro e Pequenas Empresas (SEBRAE) e do Banco Interamericano de Desenvolvimento (BID), além de contar com o apoio de universidades. As entidades citadas entraram em acordo e iniciaram o desenvolvimento de um projeto que beneficiasse empresas de todos os portes uma vez que as normas ISO/IEC (regulamentam a produção de softwares) se tornam inviáveis para algumas empresas de micro, pequeno e médio porte por serem demasiadamente onerosos os gastos para alcançar este tipo de certificação. Segundo o Guia Geral (2009), o objetivo do projeto MPS.Br é a Melhoria de Processo do Software Brasileiro, com duas metas a alcançar a médio e longo prazos: I) Uma meta técnica, que visa basicamente a criação e aprimoramento do modelo MPS. Essa primeira meta, conta com os seguintes resultados: guias do modelo MPS; Instituições Implementadoras credenciadas que terão a incumbência de prestar serviços de consultoria para a implementação do modelo de referência; Instituições Avaliadoras credenciadas que deverão prestar serviços de avaliação seguindo o método de avaliação MA-MPS; Consultores de Aquisição certificados para posteriores serviços de consultoria de aquisição de software e serviços relacionados; II) Uma meta de mercado, visando à disseminação e adoção do modelo MPS, em todas as regiões do país, em um intervalo de tempo justo, a um custo razoável, tanto em PME (foco principal) quanto em grandes organizações públicas e privadas, com resultados esperados tais como: criação e aprimoramento do modelo de negócio MN-MPS; cursos, provas e workshops; organizações que implementaram o modelo MPS; organizações com avaliação MPS publicada (prazo de validade de três anos).

35 34 Portanto nota-se que o objetivo do projeto não é inovar, mas sim, tornar o que já existe compatível com a realidade das empresas brasileiras Normas envolvidas Existe uma base técnica para a construção e aprimoramento do modelo de melhoria e avaliação de processo de software, essa base é composta pelas normas: I) ISO/IEC 12207:2008 [ISO/IEC, 2008a]: Processos do Ciclo de Vida do Software. Foi criada pela ISO International Organization for Standardization e o IEC - International Electrotechnical Commission. Em 1988, foi proposto o desenvolvimento da norma e em agosto de 1995 ela foi publicada como Norma Internacional. Em 1998, foi publicada a sua versão brasileira que tem o mesmo nome que a internacional, somente acrescida das iniciais NBR. Em outubro de 2002 e 2004, foram feitas atualizações na Norma Internacional ISO/IEC 12207, chamadas de emendas 1 e 2 respectivamente, onde foram inseridas melhorias que criaram novos ou expandiram o escopo de alguns processos, inseriram para cada processo o seu propósito e resultados e para os novos processos definiram suas atividades e tarefas. Essas modificações tiveram o objetivo de representar a evolução da Engenharia de Software, as necessidades vivenciadas pelos usuários da norma e a harmonização com a série ISO/IEC Em 2008, a Norma Internacional ISO/IEC foi reformulada, incorporando as melhorias que já apareciam nas emendas 1 e 2 e harmonizando sua estrutura à Norma Internacional ISO/IEC A norma ISO/IEC 12207:2008 foi publicada também como padrão IEEE (IEEE Std 12207:2008) e estabelece uma arquitetura comum para o ciclo de vida de processos de software com uma terminologia bem definida. Contém processos, atividades e tarefas a serem aplicadas durante o fornecimento, aquisição, desenvolvimento, operação, manutenção e descarte de produtos de software, bem como partes de software de um sistema. A norma também

36 35 se aplica à aquisição de sistemas, produtos de software e serviços relacionados à área. II) ISO/IEC [ISO/IEC, 2003]: Avaliação de Processo. Em setembro de 1992, a ISO realizou um estudo chamado Necessidades e Exigências para uma Norma de Avaliação de Processos de Software. O trabalho concluiu que era pertinente a elaboração de uma norma que fosse aplicável à melhoria de processos e à determinação da capacidade. Este padrão deveria considerar os métodos e normas já existentes (como por exemplo, o SW-CMM e a ISO 9001), abranger todos os processos de software e ser construído pelos especialistas que já desenvolviam e trabalhavam com os métodos e normas existentes à época. Como resultado desse primeiro trabalho, a ISO iniciou em janeiro de 1993 o projeto SPICE (Software Process Improvement and Capability determination) com o objetivo de produzir inicialmente um relatório técnico que fosse, ao mesmo tempo, mais geral e abrangente que os modelos existentes e mais específico que a norma ISO 9001 originando, assim, a série de normas ISO/IEC 15504: Parte 1 [ISO/IEC, 2004a], Parte 2 [ISO/IEC, 2003], Parte 3 [ISO/IEC, 2004b], Parte 4 [ISO/IEC, 2004c] e Parte 5 [ISO/IEC, 2006]. Posteriormente, em 2008, mais duas partes foram desenvolvidas: Parte 6 [ISO/IEC, 2008b] e Parte 7[ISO/IEC, 2008c]. A ISO/IEC presta-se à realização de avaliações de processos de software com dois objetivos: a melhoria de processos e a determinação da capacidade de processos de uma unidade organizacional. Se o objetivo for a melhoria de processos, a unidade organizacional pode realizar uma avaliação com o objetivo de gerar um perfil dos processos que será usado para a elaboração de um plano de melhorias. A análise dos resultados identifica os pontos fortes, os pontos fracos e os riscos inerentes aos processos. No segundo caso, a organização tem o objetivo de avaliar um fornecedor em potencial, obtendo o seu perfil de capacidade. O perfil de capacidade permite ao contratante estimar o risco associado à contratação daquele fornecedor em potencial para auxiliar na tomada de decisão de contratá-lo ou não. Esta última é compatível com CMMI (Capability Maturity Model Integration).

37 Estruturas de Apoio FCC (Fórum de Credenciamento e Controle) que tem como função a emissão de pareceres que subsidiem decisão da SOFTEX sobre o credenciamento de Instituições Implementadoras e Instituições Avaliadoras; monitorar os resultados das Instituições Implementadoras e Instituições Avaliadoras, emitindo pareceres propondo à SOFTEX o seu descredenciamento no caso de comprometimento da credibilidade do modelo MPS. A ETM (Equipe Técnica do Modelo) segundo o Guia Geral (2009), é a equipe técnica responsável pela definição e aprimoramento do MR-MPS, MA-MPS e guias específicos. Tem a função de apoiar a SOFTEX sobre os aspectos técnicos relacionados ao Modelo de Referência e Método de Avaliação, para a criação e aprimoramento contínuo dos dois modelos citados e de seus guias, além de ter como responsabilidade a capacitação de pessoas por meio de cursos, provas e workshops. Ainda falando sobre a ETM, é de função dela também, a elaboração de guias que falem e especifiquem como deve ser feita a aquisição, a implementação e a avaliação dos softwares, bem como do Guia Geral do Modelo MPS.Br. Por meio das estruturas citadas acima, o MPS.BR obtém a participação de representantes de universidades, instituições governamentais, centros de pesquisa e de organizações privadas, os quais contribuem com suas visões complementares que agregam qualidade ao empreendimento. (GUIA GERAL, 2009) 4.3. Descrição do Modelo MPS O MPS.Br conta com um modelo de referência, o MR-MPS e também com um método de avaliação, que é o MA-MPS, além de ter um modelo de negócio que é o (MN-MPS), o segundo foi criado porque existem empresas que terão de fazer a

38 37 analise e avaliação de como as empresas que estão fazendo parte do MPS.Br estão agindo, ou seja, o projeto não está voltado somente para a produção de bons softwares, mas sim pela continuidade do projeto e de como as empresas que entrarem no projeto continuarão a fazer parte do mesmo entre outros aspectos. Essa estrutura de modelos foi criada para que a melhoria de produtos de software seja estabelecida e a padronização garantida. Cada um destes componentes é apresentado e especificado em guias que juntos formam a documentação do modelo MPS. FIGURA 7: Componentes. Fonte: (GUIA GERAL, 2009). Na Figura 6, observa-se uma demonstração dos modelos ISO, CMMI e MPS. Nela estão elencados todos os métodos e modelos que participam do desenvolvimento dos projetos. Observa-se ainda que alguns modelos pertencem a mais de um projeto, como é o caso do modelo de referência que tanto é parte do CMMI, do ISO e também do modelo MPS. I) Guia Geral: contém a descrição geral do modelo MPS e detalha o Modelo de Referência (MR-MPS), seus componentes e as definições comuns necessárias para seu entendimento e aplicação; II) Guia de Aquisição: descreve um processo de aquisição de software e serviços correlatos. É descrito como forma de apoiar as

39 38 instituições que queiram adquirir produtos de software e serviços correlatos apoiando-se no MR-MPS. (SOFTEX, 2009) III) IV) Guia de Avaliação: descreve o processo e o método de avaliação MA-MPS, os requisitos para avaliadores líderes, avaliadores adjuntos e Instituições Avaliadoras (IA). (SOFTEX, 2009). Guia de Implementação: série de dez documentos que fornecem orientações para implementar nas organizações os níveis de maturidade descritos no Modelo de Referência MR-MPS. (SOFTEX, 2009) Modelo de Referência Para que determinada organização esteja em conformidade com o modelo MPS a mesma deve alcançar determinados requisitos, é o modelo de referência o responsável por especificar esses requisitos básicos. Através de uma combinação entre processos e suas respectivas capacidades, o MR-MPS define níveis de maturidade para o software. Segundo o Guia Geral (2009), nível de maturidade é o grau de melhoria de processo para um predeterminado conjunto de processos no qual todos os resultados esperados do processo e dos atributos dos processos são atendidos. Os níveis de maturidade demonstram a evolução de processos, caracterizando estágios de melhoria da implementação de processos na organização, ou seja, o nível de maturidade serve como um termômetro que mede como está se dando a evolução da organização. Tendo consciência de qual o nível no qual se encontra determinada organização, é possível prever o seu desempenho futuro ao executar um ou mais processos. Existem sete níveis de maturidade estabelecidos pelo MR-MPS. Esta escala de maturidade se inicia no nível G e progride até o nível A. Para cada um destes sete níveis de maturidade é atribuído

40 39 um perfil de processos que indicam onde a organização deve colocar o esforço de melhoria. O alcance de um determinado nível e o avanço para outro, se obtêm quando são atendidos os propósitos estabelecidos para determinado nível. Os resultados esperados dos respectivos processos e os resultados esperados dos atributos de processo também devem ser alcançados para só então dar por concluído o nível em questão Método de Avaliação O modelo de avaliação basicamente consiste em definir uma instituição avaliadora e verificar a maturidade com que a organização está conduzindo a execução dos processos. O método de avaliação tem início a partir do momento em que o patrocinador da avaliação define uma instituição que será a avaliadora. O encerramento do modelo de avaliação se dá no momento em que os dados produzidos e analisados são registrados em uma base de dados confidencial da SOFTEX. O patrocinador da avaliação pode ser alguém da gerência da organização que está implementando o modelo, ou também pode ser alguém da entidade que esteja propondo a avaliação. O comprometimento do patrocinador é essencial para assegurar que os objetivos da avaliação sejam atingidos. A atitude da gerência da unidade organizacional tem forte impacto nos resultados de uma avaliação. O responsável pela unidade organizacional deve motivar os participantes de forma aberta e construtiva. Deve, também, deixar claro a todos que a avaliação tem como foco principal, o processo em si, e não o desempenho dos indivíduos que participam do processo. O fornecimento de feedback e o estabelecimento de uma atmosfera que encoraje a discussão aberta sobre os resultados preliminares, durante a avaliação, ajudam a assegurar que a avaliação seja significativa para a unidade organizacional.

41 40 O respeito à confidencialidade das fontes de informação e documentação recolhidas durante a avaliação é essencial para que se obtenham informações consistentes. É de suma importância que os colaboradores e servidores da organização se sintam em uma atmosfera agradável e que tenham a percepção de que a avaliação resultará em benefícios que os ajudarão direta ou indiretamente a realizar o seu trabalho. É importante que todas as partes confiem que os avaliadores têm a experiência necessária para realizar a avaliação, são imparciais e têm um entendimento adequado da unidade organizacional. A avaliação depois de concluída tem validade de três (3) anos a contar da data da avaliação final feita na organização, ou seja, não é vitalícia. O processo de avaliação é composto por quatro (4) subprocessos que iniciam com a contratação da avaliação, em sequência a preparação da realização da avaliação, após a realização da avaliação final e por último, a documentação dos resultados da avaliação. Resultam do método de avaliação a obtenção de dados e informações que caracterizam os processos de software da organização, a determinação do grau em que os resultados esperados são alcançados e os processos atingem o seu propósito e por fim a atribuição de um nível de maturidade do MR-MPS à organização Modelo de Negócio O modelo MPS estabelece um modelo de negócio para apoiar a sua adoção pelas empresas brasileiras desenvolvedoras de software. (GUIA GERAL, 2009) O modelo de negócio contém descrição de regras de negócio para implementação do MR-MPS pelas Instituições Implementadoras, avaliação seguindo o MA-MPS pelas Instituições Avaliadoras, organização de grupos de empresas pelas

42 41 Instituições Organizadoras de Grupos de Empresas (IOGE) para implementação do MR-MPS e avaliação MA-MPS, certificação de Consultores de Aquisição (CA) e programas anuais de treinamento do MPS.BR por meio de cursos, provas e workshops Níveis de Maturidade O modelo MPS baseia-se nos conceitos de maturidade e capacidade de processo para a avaliação e melhoria da qualidade e produtividade de produtos de software e serviços correlatos. (GUIA GERAL, 2009) A maturidade em processos de software é quem define os meios pelos quais o software é definido, gerenciado, medido, controlado e efetivo, isto implica na evolução das capacidades dos processos. Em uma empresa com o grau de maturidade elevado, o desenvolvimento de software é muito bem entendido por toda a equipe técnica, isto se dá graças à existência da documentação adequada e de políticas de treinamento de pessoal continuadas. Na passagem para um nível de maturidade superior, os processos anteriormente implementados no nível anterior, passam a ser executados no nível de capacidade atual. Algumas denominações presentes no modelo MPS e que contribuem para o avanço dos níveis de maturidade pela instituição devem ser conhecidos: I) Processo: deve ser proposto e deve principalmente, se destinar aquilo que se propõe, não fugindo de seus objetivos. O propósito descreve o objetivo geral a ser atingido durante a execução do processo. Os resultados esperados do processo estabelecem os resultados a serem obtidos com a efetiva implementação do processo. Estes resultados podem ser evidenciados por um produto de trabalho produzido ou uma mudança significativa de estado ao se executar o processo.

43 42 II) III) IV) Capacidade do processo: expressa o grau de refinamento e institucionalização com que o processo é executado na organização/unidade organizacional. À medida que a organização/unidade organizacional evolui nos níveis de maturidade, um maior nível de capacidade para desempenhar o processo deve ser atingido. (GUIA GERAL, 2009). A capacidade do processo avalia os resultados obtidos e identifica com que grau de refinamento e institucionalização o processo foi executado na organização. A partir daí é que vai ser definido em qual grau de maturidade a empresa se encontra e se pode evoluir. A medida que a organização/unidade organizacional evolui nos níveis de maturidade, um maior nível de capacidade para desempenhar o processo deve ser atingido. Atributos do processo: segundo o GUIA GERAL (2009), os atributos do processo são nove (9) e são eles que descrevem o nível de capacidade do processo. O atendimento aos atributos do processo (AP), pelo atendimento aos resultados esperados dos atributos do processo (RAP), é requerido para todos os processos no nível correspondente ao nível de maturidade, embora eles não sejam detalhados dentro de cada processo. Esses níveis são acumulativos, ou seja, se a organização está no nível F, esta possui o nível de capacidade do nível F que inclui os atributos de processo dos níveis G e F para todos os processos relacionados no nível de maturidade F (que também inclui os processos de nível G). Isto significa que, ao passar do nível G para o nível F, os processos do nível de maturidade G passam a ser executados no nível de capacidade correspondente ao nível F. Em outras palavras, na passagem para um nível de maturidade superior, os processos anteriormente implementados devem passar a ser executados no nível de capacidade exigido neste nível superior. Resultados Esperados por Processo: No MPS.BR cada processo tem um propósito e seus resultados esperados. Resultado esperado do processo é resultado observável do sucesso do alcance do propósito do processo. (ISO, 2002)

44 43 Na tabela 2, estão descritos os níveis de maturidade, os processos de cada um deles e ainda os atributos correspondentes. TABELA 2: Níveis de maturidade do MR-MPS. Nível Processos Atributos de Processo A B C D E F G Gerência de Projetos GPR (evolução) Gerência de Riscos GRI Desenvolvimento para Reutilização DRU Gerência de Decisões GDE Verificação VER Validação VAL Projeto e Construção do Produto PCP Integração do Produto ITP Desenvolvimento de Requisitos DRE Gerência de Projetos GPR (evolução) Gerência de Reutilização GRU Gerência de Recursos Humanos GRH Definição do Processo Organizacional DFP Avaliação e Melhoria do Processo Organizacional AMP Medição MED Garantia da Qualidade GQA Gerência de Portfólio de Projetos GPP Gerência de Configuração GCO Aquisição AQU Gerência de Requisitos GRE Gerência de Projetos GPR Fonte: Guia Geral MPS.BR (SOFTEX, 2009) AP 1.1, AP 2.1, AP 2.2, AP 3.1, AP 3.2, AP 4.1, AP 4.2, AP 5.1 e AP 5.2 AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2, AP 4.1 e AP 4.2 AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2 AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2 AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2 AP 1.1, AP 2.1 e AP 2.2 AP 1.1 e AP 2.1 Atributo de processo é uma característica mensurável da capacidade do processo aplicável a qualquer processo [ISO/IEC , 2004]. Quando determinado atributo de processo for atingido, uma avaliação é realizada com base nos resultados alcançados.

45 Nível de Maturidade G ou Parcialmente Gerenciado. O nível de maturidade G ou parcialmente gerenciado, é composto pelos processos gerência de projetos e gerência de requisitos. I) Gerência de Projetos (GPR): esse processo tem como propósito fundamental estabelecer e manter planos que definam as atividades, recursos e responsabilidades do projeto, bem como prover informações sobre o andamento do projeto que permitam a realização de correções quando houver desvios significativos no desempenho do projeto. Este propósito evolui à medida que a organização avança os níveis de maturidade. Assim, a partir do nível E, alguns resultados evoluem e outros são incorporados, de forma que a gerência de projetos passe a ser realizada com base no processo definido para o projeto e nos planos integrados. No nível B, a gerência de projetos passa a ter um enfoque quantitativo, refletindo a alta maturidade que se espera da organização. Novamente, alguns resultados evoluem e outros são incorporados. II) Gerência de Requisitos (GRE): é o responsável por gerenciar os requisitos do produto e dos componentes de projeto e identificar inconsistências entre os requisitos, os planos do projeto e os produtos de trabalho do projeto. Dois pontos são desafiadores na implantação do nível G. O primeiro ponto se refere à mudança de cultura organizacional, orientando a definição e melhoria dos processos de desenvolvimento de software e o segundo aspecto é pertinente à definição do conceito acerca do que é projeto para a organização.

46 Nível F Gerenciado. Fazem parte deste nível de maturidade os processos de aquisição (AQU), gerência de configuração (GCO), garantia da qualidade (GQA), gerência de portfólio de projetos (GPP) e o processo de medição (MED). I) Aquisição (AQU): é responsável por gerenciar a aquisição de produtos que satisfaçam às necessidades exigidas pelo cliente. II) III) IV) Gerência de Configuração (GCO): tem como objetivo estabelecer e manter a integridade de todos os produtos de trabalho de um processo ou projeto e disponibilizá-los a todos os envolvidos. Garantia da Qualidade (GQA): tem como propósito fundamental, assegurar que os produtos de trabalho e a execução dos processos estejam em conformidade com os planos, procedimentos e padrões estabelecidos. Gerência de Portfólio de Projetos (GPP): inicia e mantém projetos que sejam necessários, suficientes e sustentáveis, de forma a atender os objetivos estratégicos da organização. Este processo compromete o investimento e os recursos organizacionais adequados e estabelece a autoridade necessária para executar os projetos selecionados. Ele executa a qualificação contínua de projetos para confirmar que eles justificam a continuidade dos investimentos, ou podem ser redirecionados para justificar. V) Medição (MED): tem como propósito coletar, armazenar, analisar e relatar os dados relativos aos produtos desenvolvidos e aos processos implementados na organização e em seus projetos, de forma a apoiar os objetivos organizacionais.

47 Nível E Parcialmente Definido. Este nível de maturidade é composto pelos processos dos níveis de maturidade anteriores (G e F), acrescidos dos processos avaliação e melhoria do processo organizacional, definição do processo organizacional, gerência de recursos humanos e gerência de reutilização. O processo gerência de projetos sofre sua primeira evolução, retratando seu novo propósito: gerenciar o projeto com base no processo definido para o projeto e nos planos integrados. Fazem parte do nível de maturidade E, quatro (4) processos: o processo de avaliação e melhoria do processo organizacional (AMP), o processo gerência de recursos humanos (GRH), o processo organizacional (DFP) e o processo de reutilização (GRU). I) Avaliação e Melhoria do Processo Organizacional (AMP): têm como propósito determinar o quanto os processos padrão da organização contribuem para alcançar os objetivos de negócio da organização e para apoiar a organização a planejar, realizar e implantar melhorias contínuas nos processos com base no entendimento de seus pontos fortes e fracos. II) III) IV) Gerência de Recursos Humanos (GRH): tem a responsabilidade de prover a organização e os projetos com os recursos humanos necessários e manter suas competências adequadas às necessidades do negócio. Definição do Processo Organizacional (DFP): tem como propósito estabelecer e manter um conjunto de ativos de processo organizacional e padrões do ambiente de trabalhos usáveis e aplicáveis às necessidades de negócio da organização. Reutilização (GRU): tem como propósito fundamental o gerenciamento do ciclo de vida dos ativos reutilizáveis.

48 Nível D Largamente Definido. O nível de maturidade D é composto pelos processos dos níveis de maturidade anteriores (G ao E), acrescidos dos processos desenvolvimento de requisitos, integração do produto, projeto e construção do produto, validação, e verificação. I) Desenvolvimento de Requisitos (DRE): define os requisitos do cliente, do produto e também dos componentes do produto. II) III) IV) Integração do Produto (ITP): tem como propósito elencar os componentes do produto, objetivando a produção integrada e consistente com o projeto. Projeto e Construção do Produto (PCP): o objetivo deste processo é a projeção, desenvolvimento e implementação de soluções para atender aos requisitos impostos pelo planejamento. Validação (VAL): o propósito desse processo é verificar e confirmar que o produto final está apto para o mercado e que atenderá ao objetivo a que se propõe. V) Verificação (VER): é o responsável por confirmar que cada serviço ou produto atende apropriadamente os requisitos exigidos no planejamento Nível C Definido. O nível de maturidade C é composto pelos processos dos níveis de maturidade anteriores (G ao D), acrescidos dos processos desenvolvimento para reutilização, gerência de decisões e gerência de riscos.

49 48 I) Desenvolvimento para Reutilização (DRU): o propósito deste processo é identificar oportunidades de reutilização e, se possível, estabelecer um programa de reutilização, verificando a potencialidade de determinado produto ou bem de ser ou não reutilizado. II) III) Gerência de Decisões (GDE): analisa possíveis decisões críticas usando processos formais, com critérios estabelecidos, para avaliação das alternativas identificadas. Gerência de Riscos (GRI): é responsável por identificar, analisar, tratar, monitorar e reduzir continuamente os riscos em nível organizacional e de projeto Nível B Gerenciado Quantitativamente. Este nível de maturidade é composto pelos processos dos níveis de maturidade anteriores (G ao C). Neste nível o processo de Gerência de Projetos sofre sua segunda evolução, sendo acrescentados novos resultados para atender aos objetivos de gerenciamento quantitativo. Este nível não possui processos específicos Nível A Em Otimização. Este nível de maturidade é composto pelos processos dos níveis de maturidade anteriores (G ao B). Este nível não possui processos específicos.

50 49 5. PLANEJAMENTO DE APLICAÇÃO DA MELHORIA DE PROCESSOS DE SOFTWARE BRASILEIRO (MPS.BR) EM INSTITUIÇÕES DO TIPO FÁBRICA DE SOFTWARE. O principal ponto pretendido com a aplicação deste nível de maturidade é que a organização em questão, quando alcançar a maturidade de nível G, seja capaz de, gerenciar parcialmente seus projetos de desenvolvimento de software. Uma vez que, as empresas, em sua grande maioria, muitas vezes tem um esquema de processos, mas cada vez que algum imprevisto ocorre, por alguma dificuldade encontrada pelos servidores e colaboradores, este curso é abandonado e se dá continuidade para o andamento das atividades de forma desregrada e fora dos padrões. Esse método de organização informal é um dos principais motivos da falta de planejamento e padronização das instituições. A aplicação de normas, processos bem definidos e métodos de melhoria de software tem tudo para fazer com que a empresa alcance diversos benefícios, além de chegar ao ponto em que erros poderão ser evitados e gastos reduzidos. O nível G de maturidade é o primeiro passo para o início de todo esse processo de melhorias e desmistificação de normas e regras. Segundo o Guia de Implementação parte 1 (2009), dois (2) pontos são desafiadores na implantação do nível G. O primeiro diz respeito à mudança de cultura dentro da própria organização, orientando a definição e melhoria dos processos de desenvolvimento de software. E o segundo, seria a definição do conceito acerca do que é projeto para a organização.

51 Análise da Situação Atual. Para iniciar com a implementação de qualquer projeto, para se obter sucesso e alcançar os objetivos, deve-se antes de começar o planejamento e consequente aplicação, fazer uma análise de como é a situação atual da organização qualquer que seja ela. Para tanto, se faz necessária uma diagnosticação do processo de software existente na empresa, mesmo que esse processo seja totalmente informal, levando inclusive, em consideração que o mesmo pode, muitas vezes, ser falho. Esta análise torna-se ainda mais relevante em se tratando de aplicação do projeto MPS.Br, isto porque, segundo o Guia de Implementação Parte I (2009), busca-se que o mesmo seja adequado ao perfil de empresas com diferentes tamanhos e características, públicas e privadas, embora com especial atenção às micro, pequenas e médias empresas. O reconhecimento da empresa, sua estrutura, instalações, quadro de funcionários, ou seja, todos os aspectos gerais da mesma são de suma importância para o sucesso da implementação do nível G de maturidade. Neste reconhecimento, devem ser analisados também, outros aspectos, que mais interessam para a aplicação da melhoria, que seriam: o setor de informática propriamente dito, os profissionais que atuam neste e demais setores da organização, os softwares utilizados, a estrutura em geral. Os softwares desenvolvidos na empresa também fazem parte dessa análise, sobre eles, será feito um levantamento na questão de linguagens utilizadas, banco de dados adotado, se já existe alguma forma de padronização de processos e métodos, de que forma é realizado o levantamento de requisitos e se existe a prática de documentação de tudo isso.

52 Aspectos Referentes à Empresa. No início dos trabalhos, um questionamento com os supervisores, gerentes e cargos de chefia deve ser feito para verificar dados da empresa em geral. Esse questionário deverá conter questões de cunho básico, como o razão social da empresa, nome fantasia, endereço, telefone, quando foi fundada, qual o ramo de atuação, à quantos anos vem atuando no ramo, número de funcionários, qual o seu nível de graduação e conhecimento. Outro aspecto que deve ser abordado logo nessa fase, é o estudo do mercado no qual a empresa está inserida. Quais os produtos oferecidos, como eles estão sendo aceitos pelos consumidores, como a empresa está conseguindo suprir as necessidades de seus clientes e se está conseguindo alcançar os objetivos a que se propõe. A partir desse estudo, serão identificados quais os problemas apresentados pela empresa e quais são seus pontos fortes, onde é preciso mudar e quais aspectos necessitam de maior atenção. Após essas etapas, inicia-se a preocupação mais específica com o foco da melhoria, ou seja, os softwares. O objetivo do projeto de melhoria são os produtos de software que a empresa desenvolve, é sobe eles que vai ser aplicado o processo de melhoria de software. Após ter sido definido pelos responsáveis que o processo será aplicado na empresa, inicia-se a parte prática.

53 Os Profissionais e suas Características. Os profissionais da área também devem ser estudados, quais suas tarefas, suas atribuições, o nível de conhecimento e o que aplicam no dia-a-dia de trabalho. Nessa estava deve-se definir, observando estrutura, mercado de atuação, porte, um grupo de profissionais que serão responsáveis por encaminhar e gerenciar o processo de melhoria dentro da organização. Este grupo será responsável por definir quais as estratégias a serem adotadas e qual rumo tomar, observando as necessidades da empresa e também os custos em que estas medidas acarretarão. As decisões também serão tomadas por este grupo e o mesmo deve passar relatório para o restante da equipe. Nesse relatório deve constar o que está sendo feito, como o processo de melhorias está sendo implementado na empresa e a que ponto a empresa e a equipe estão se adequando as novas imposições e regras. Existirão profissionais que não estarão diretamente ligados com o processo de melhoria de software, estes, devem estar a par do que está sendo feito e da importância dessa melhoria e devem também estar cientes de que sua colaboração é fundamental para que os processos de melhoria sejam implementados e que obtenham sucesso em seus objetivos. Ainda nessa fase de análise, será necessária também uma estratégia de convencimento dos integrantes da gerência da empresa e/ou donos, caso os mesmos se mostrem apreensivos ou contrários às condições impostas para que os processos de melhoria sejam alcançados. Este convencimento é fundamental para que estes percebam a importância da aplicação de processos de melhoria, quais os benefícios que isso trará para o negócio deles e quais os aspectos que gerarão maiores problemas, ou seja, onde é q ele vão ter aumento de custos com a aplicação dos processos.

54 Conscientização e Treinamento. Uma das primeiras atividades que deverá ser adotada na empresa será o treinamento de toda a equipe de servidores. É importante ressaltar que não se trata de somente treinar os profissionais de informática, mas sim da equipe em geral. Esse treinamento se dará primeiramente de forma teórica e deverá ser elaborado e realizado pelos implementadores do nível G. Os implementadores poderão ser tanto de uma empresa contratada especificamente para esse fim, como também poderá ser feita por membros da própria equipe de trabalho. O treinamento deve abordar todos os aspectos da implementação de processos de melhoria de softwares. O mesmo deverá conter temas que expliquem qual o funcionamento de uma empresa com sistema informal de andamento dos processos, quais os problemas que esse tipo de abordagem traz para a própria organização e equipe de profissionais, quais as vantagens de aplicação do projeto de melhorias, quem tomou a decisão e o porquê de a empresa decidir por aplicar essas melhorias, quais as vantagens e benefícios que o novo projeto trará para o dia-a-dia organizacional, em quais setores essas melhorias irão influenciar, além de conter explicações sobre o que é o projeto MPS, o que significa alcançar a maturidade G, quais os próximos passos para a organização e qual a importância de todo o plantel de funcionários estar cientes e prestes a colaborar com a equipe de implementadores. Este treinamento deve ter como objetivo principal a conscientização da importância de se ter um processo de desenvolvimento de software padronizado e parcialmente gerenciado. Além de sanar dúvidas e ouvir sugestões dos próprios colaboradores.

55 Análise dos processos da empresa. As práticas da empresa deverão ser analisadas, geralmente já existem processos definidos dentro de todas as organizações, o que falta são métodos padronizados. Mas mesmo os processos realizados de forma informal devem ser registrados detalhadamente e analisados de forma a encontrar uma maneira de melhor gerenciá-los. Na fase de implementação do nível G de maturidade, os processos da empresa continuarão sendo os mesmos, não haverão mudanças em relação ao que já vem sendo realizado. O que vai ser feito nessa fase é a verificação dos processos existentes no dia-a-dia organizacional e caso haja alguma alteração a ser realizada, a mesma deverá ser explanada durante a fase de planejamento do projeto. Para esta análise das práticas realizadas faz-se necessário o uso dos passos descritos no Guia de Implementação do MPS.Br, especificamente da parte de gerência de processos Gerenciamento de Processos. O propósito do processo Gerência de Projetos é estabelecer e manter planos que definam as atividades, recursos e responsabilidades do projeto, bem como prover informações sobre o andamento do projeto que permitam a realização de correções quando houver desvios significativos no desempenho do projeto. (GUIA DE IMPLEMENTAÇÃO, 2009). Após a finalização das análises, é necessário um planejamento levando em conta os aspectos encontrados, os pontos a serem modificados e também a explanação daquilo que não era feito na organização e que deverá ser implantado a partir de agora. Os processos existentes e também aqueles que apresentam

56 55 problemas devem ser detalhados e as soluções devem ser apontadas. Esse planejamento deverá abranger de forma geral o controle do projeto. Neste mesmo planejamento, deve ser abordado o assunto viabilidade, ou seja, deverá ser realizada uma análise de viabilidade do projeto de aplicação do nível G de maturidade. A viabilidade é analisada buscando dados quantitativos e qualitativos em relação ao projeto a ser aplicado na empresa. Para tomar a decisão de implementar o nível G em determinada instituição, o tomador de decisões deve estar respaldado por meio de ferramentas que digam quais os custos e os benefícios que o projeto trará para a empresa. Os dados colhidos nas análises da empresa, dos profissionais, do mercado de trabalho, serão incluídos no planejamento e, além disso, ainda terão diversos outros pontos a serem abordados, como: o levantamento de riscos, a análise dos mesmos, qual o impacto que os mesmos poderão trazer para a organização, o agendamento de compromissos, o que deve ser feito e quando, a elaboração de um cronograma de execução das atividades. O cronograma deverá ser seguido rigorosamente, o ciclo de vida do projeto deve estar definido e com início e fim previstos. Toda a equipe deve estar comprometida em cumprir com o cronograma. É a partir do cronograma que a execução do projeto vai ser acompanhada, pois é nele que estão definidos as datas ou pontos chave para verificação do andamento das tarefas. Quando se chegar à determinada data ou quando atingido determinado objetivo, um estudo deverá ser feito, levando em consideração o que foi planejado para aquele tópico e se os esforços necessários para o alcance do objetivo foram feitos. Esse estudo deve verificar se os profissionais cumpriram com o combinado, se os recursos foram utilizados da forma estabelecida, se os objetivos para aquela etapa foram alcançados, ou seja, deve-se observar até que ponto o planejamento foi cumprido e o porquê de determinado ponto não ter obtido sucesso. Assim que determinada etapa for determinada como cumprida, será necessária também uma revisão final da mesma e também uma revisão de início da

57 56 nova etapa. Esta revisão deverá verificar se todos os requisitos e atributos préestabelecidos anteriormente estão sendo atendidos para que não aconteçam problemas com pré-requisitos, ou seja, não será possível iniciar em determinada atividade porque na etapa anterior faltou algo que implica no trancamento desta. No Guia de Implementação (2009), as etapas descritas acima, são estabelecidas através de marcos, ou seja, pontos relevantes do projeto. Um marco é um ponto de revisão, por exemplo, o início ou o final de cada fase do projeto ou algumas atividades de fundamental importância para o seu sucesso. No caso de algum objetivo não ter sido atingido, alguma meta não ter sido alcançada, e isso acarretar no comprometimento significativo do projeto, deverão ser feitas outras revisões, e um replanejamento far-se-á necessário. Nesse caso, o plano original deve ser analisado, e se preciso for, o mesmo deve ser refeito, alterações podem ser acrescentadas e novos acréscimos poderão fazer parte deste replanejamento Resultados Esperados para o Gerenciamento de Processos Abordados pelo Nível G. Dentro do gerenciamento de processos, alguns resultados são esperados, esses resultados são os seguintes: GPR1: Definição do escopo do projeto; o escopo define a maneira como o projeto será abordado e quais os limites do mesmo, os objetivos e as características do projeto. A EAP é utilizada para medir o tamanho do projeto como um todo. A complexidade do trabalho também é avaliada e o número de requisitos levantados. GPR2: as tarefas e os produtos de trabalho do projeto são dimensionados utilizando métodos apropriados; a estrutura analítica de projetos (EAP) deve ser estabelecida.

58 57 GPR3: o modelo e o ciclo de vida do projeto são definidos; também as revisões do projeto e as devidas alterações. Os custos também podem ser reavaliados e realizada uma nova análise para tomada de novas diretrizes. GPR 4: este resultado é estendido até o nível F. São medidos o esforço e o custo para a execução das tarefas; os produtos de trabalho são estimados com base em dados, pesquisas ou referências técnicas; Projetos anteriores e dados históricos podem ser utilizados para a construção desse resultado. A complexidade do projeto é medida e a capacidade dos profissionais também, e, baseado no escopo do projeto, são delegadas as funções de cada integrante da equipe. GPR5: o orçamento e o cronograma do projeto, incluindo a definição de marcos e pontos de controle, são estabelecidos e mantidos; avaliação de quais os gargalos existentes e levar em consideração os pré-requisitos para as futuras tarefas a serem executadas. Deve-se seguir o cronograma pré-estabelecido e manter a compatibilidade com o modelo de projeto escolhido. GPR6: leva em consideração os riscos, eles são identificados, o impacto em determinado processo é estudado e a probabilidade de ocorrência e prioridade de tratamento são determinados e documentados; O ponto principal é a identificação dos riscos, pois é a partir dela que medidas deverão ser tomadas, deve-se avaliar a opção de realizar mudanças para que a ameaça de risco não exista ou optar por manter as diretrizes estabelecidas caso o mesmo não apresente comprometimento do projeto. GPR7: os recursos humanos para o projeto são planejados considerando o perfil e o conhecimento necessários para executá-lo;

59 58 Basicamente o rol de profissionais é analisado e são delegadas as tarefas compatíveis com seu nível de conhecimento e prática. Este profissional vai executar a tarefa levando em consideração o cronograma, os recursos e também deverá obter o treinamento necessário àquela tarefa. GPR 8: os recursos e o ambiente de trabalho necessários para executar o projeto são planejados; Todos os recursos necessários para as tarefas são elencados. Em algumas situações, ocorrerá que, a aquisição de recursos não será liberada pelos responsáveis, mesmo nesses casos, o planejamento é necessário e no mesmo deve constar todo o elenco de requisitos e os recursos necessários para a execução de determinada tarefa. GPR9: os dados relevantes do projeto são identificados e planejados quanto à forma de coleta, armazenamento e distribuição. Um mecanismo é estabelecido para acessá-los, incluindo, se pertinente, questões de privacidade e segurança; a partir disto, uma base de dados é criada e fará parte dos dados históricos da empresa, esta base de dados deve ser documentada e anexada ao projeto. GPR10: um plano geral para a execução do projeto é estabelecido com a integração de planos específicos; Com base em todas as análises feitas, o plano geral será criado e contará com uma coleção constando da base de dados histórica, dos cronogramas e planejamentos realizados. Além do que já foi realizado, esse plano geral, deve conter a projeção para os próximos passos do projeto e também deve constar um planejamento para o acompanhamento das futuras tarefas. GPR11: todos os setores da instituição devem ser analisados; a viabilidade de atingir as metas do projeto é analisada e, considerando as restrições e os recursos disponíveis, é avaliada. Questões do setor financeiro, técnico, recursos humanos, manutenção e complexidade do trabalho devem ser relacionadas e analisadas levando em

60 59 consideração a viabilidade do projeto. Caso sejam necessárias alterações, estas devem constar de planejamento e devem ser devidamente documentadas. GPR12: o plano do projeto é revisado com todos os interessados e o compromisso com ele é obtido; Todos os integrantes da equipe e também os interessados de uma forma ou de outra no projeto, são colocados à par de como vai o andamento do projeto, quais os objetivos foram alcançados, quais as fases que apresentam certas dificuldades e quais as expectativas. GPR13: o projeto é gerenciado utilizando-se do Plano de Projeto e também outros planejamentos que afetam de alguma forma o projeto e seus resultados. Todo o acompanhamento do projeto é documentado. GPR14: o envolvimento das partes interessadas no projeto é gerenciado; Todas as partes interessadas devem estar de acordo com o planejamento, com possíveis modificações e com as práticas adotadas pelos implementadores do projeto. Pode-se fazer um comunicado para todas as partes interessadas constando de relatório do projeto de forma geral e simplificada, para que todos fiquem à par do que está sendo feito e quando se deu, ou dará a implementação de determinada tarefa. GPR15: Revisões são realizadas em marcos do projeto e conforme estabelecido no planejamento; Os marcos para as revisões devem estar previamente planejados. GPR 16: registros de problemas identificados e o resultado da análise de questões pertinentes, incluindo dependências críticas, são estabelecidos e tratados com as partes interessadas; Basicamente se dá o armazenamento e a documentação de todos os problemas identificados e das possíveis modificações planejadas para que os

61 60 mesmos não ocorram ou ao menos para que tenham menor impacto possível no projeto. GPR 17: ações para corrigir desvios em relação ao planejado e para prevenir a repetição dos problemas identificados são estabelecidas, implementadas e acompanhadas até a sua conclusão; Essas ações visam o tratamento e gerenciamento dos desvios, falhas e dos problemas encontrados no projeto. Pode-se utilizar para ajudar na resolução dessas questões, ferramentas específicas para a gestão dos defeitos Gerenciamento de Requisitos. O propósito do processo Gerência de Requisitos é gerenciar os requisitos do produto e dos componentes do produto do projeto e identificar inconsistências entre os requisitos, os planos do projeto e os produtos de trabalho do projeto. (Guia de Implementação, 2009). Pode-se dizer que o conjunto de requisitos de um projeto é parte fundamental para o sucesso da implementação. São os requisitos que irão estabelecer um vínculo entre os implementadores e a empresa a ser analisada e feita a implementação do nível G. A opinião dos superiores e gerência é muito importante na decisão de quais requisitos serão abordados. Mas é muito importante ressaltar que eles não podem ser os únicos a estabelecer os requisitos, pois quem vai ter o conhecimento de o que acontece é o profissional que atua diretamente nos diversos setores da empresa, portanto, a opinião e participação ativa desses profissionais é indiscutível.

62 Levantamento de Requisitos. O levantamento de requisitos pode se dar de diversas formas, poderá ser em forma de entrevistas, de reuniões com um grupo determinado pelos implementadores, entretanto, a abordagem que será tratada aqui se dará de duas formas, a primeira será através de questionários dirigidos aos profissionais que ocupam os mais variados cargos dentro da empresa, incluindo os cargos de gerência e supervisão, e a segunda pelo método de Brainstorming, que é uma maneira de gerar um turbilhão de ideias de forma rápida e eficiente. I) Questionário: é voltado aos diversos profissionais da organização deve conter pontos que englobem o dia-a-dia da organização, quais as dificuldades, quais as facilidades e deve abranger de forma geral todo o funcionamento organizacional. Questões como O que o software deve fazer, Quais relatórios irão ser produzidos, Quem terá acesso e qual tipo de acesso, Qual plataforma e arquitetura serão usadas, essas são algumas das questões que podem ser feitas para levantamento de requisitos. II) Brainstorming: faz-se uma dinâmica com o grupo em geral. Para esta atividade deverá ser escolhido um líder, um secretário para realizar anotações e registrar todas as ideias que surgirem. Ao marcar a reunião, deve-se encaminhar uma pauta com o assunto a ser tratado para que todos os participantes já tenham noção e possam pensar sobre o assunto antes mesmo da abordagem. Críticas ao projeto ou a qualquer outro aspecto, não fazem parte do propósito desta reunião, mas sim ideias em grande quantidade. Os integrantes deverão ser encorajados a exporem todas as suas sugestões, mesmo que pareçam absurdas. Outro ponto importante que esta técnica objetiva é o aperfeiçoamento de sugestões, ou seja, um integrante produz uma ideia e outro acrescenta em determinado aspecto ou realiza alguma alteração na sugestão inicial. Uma lista com todas as ideias sugeridas

63 62 deve ser encaminhada a cada um dos participantes e uma avaliação da dinâmica pode ser marcada. É importante salientar que, independente do tipo de abordagem escolhida pela equipe, os requisitos devem abordar de forma abrangente o software, ou seja, suas características, quem vai operá-lo, para quem é destinado, quais compatibilidades deverá apresentar, se deve ser compatível com determinada arquitetura, programa específico ou até mesmo determinado sistema operacional. Uma boa comunicação com os fornecedores de requisitos é fundamental para assegurar um bom entendimento das necessidades do cliente e dos requisitos do projeto e, consequentemente, aumentar as chances de sucesso do projeto. (Guia de Implementação, 2009) Resultados Esperados para o Gerenciamento de Requisitos Abordados pelo Nível G. GRE1: os requisitos são entendidos, avaliados e aceitos junto aos fornecedores de requisitos, utilizando critérios objetivos; GRE2: O comprometimento da equipe técnica com os requisitos aprovados é obtido; GRE3: A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho é estabelecida e mantida; GRE4: Revisões em planos e produtos de trabalho do projeto são realizadas visando identificar e corrigir inconsistências em relação aos requisitos; GRE5: Mudanças nos requisitos são gerenciadas ao longo do projeto.

64 Custos. O gerenciamento de custos visa trazer benefícios para a empresa, não só na questão de diminuir gastos com o projeto que será implantado, mas também e, principalmente, para obter retorno sobre o investimento feito e também sobe o capital investido. Os custos devem ser calculados levando em consideração vários aspectos, como por exemplo, tecnologias adquiridas, Em alguns casos, opta-se por realizar o gerenciamento de custos fora do projeto, antes de inicia-lo ou até mesmo não é realizado. Um integrante do grupo formado na fase de análise deverá ser o responsável por realizar o levantamento de custos. Este profissional deverá estimar os custos, fazer a orçamentação e o controle de custos e no cronograma deve estar descrito qual o profissional a fazer este trabalho e qual o prazo de início e término para a entrega do relatório. A Figura oito (8) sugere um formato a ser utilizado pelo profissional para fazer essa análise de custos.

65 64 FIGURA 8: Gerenciamento de Custos do Projeto Fonte: (GUIA PMBOK, 2004). A estimativa de custos deverá trazer como resultado uma aproximação de gastos abordando todos os recursos que serão necessários para a implementação do início ao término do projeto. A orçamentação deverá resultar em um relatório que aborde os custos de uma forma geral para que os implementadores, tomadores de decisão e equipe possam medir o desempenho, ou seja, chegar a conclusão de que o valor é alto para o projeto especificado ou se os custos condizem com a realidade da empresa e trará maiores benefícios. No mundo da tecnologia da informação, a padronização contribui para a redução de custos em todas as principais atividades da área: na infra-estrutura, já que os equipamentos têm rápida obsolescência; nos sistemas, e nas versões dos mesmos, pois reduz o número de interfaces e tamanho da equipe.

66 Comprometimento e Controle Assim que as partes interessadas entrarem em acordo sobre a implementação no modelo MPS, o grupo implementador deve expor a necessidade de comprometimento por parte de supervisores, gerentes e equipe em geral para a continuidade do projeto. O compromisso pode ser firmado em reunião logo no início das atividades do projeto. A pauta dessa reunião deve ser clara e objetiva, deve abordar as divergências sobre aspectos do projeto e de sua implementação e deve, acima de tudo, chegar a um consenso entre os integrantes firmando assim os objetivos e o comprometimento da equipe como um todo. Essa questão reflete a necessidade de ações de controle do que foi planejado e instaurado, e acompanhamento do projeto mesmo após o mesmo ser dado como findado. Métodos de controle como... podem ser combinados e devem ter profissionais individuais ou em grupos, responsáveis pelo envio de relatórios para o grupo implementador. É importante ressaltar que o projeto MPS.Br é confiável e muito bem elaborada, com documentações e regras bem estabelecidos e, caso a empresa não cumpra com o combinado, a mesma pode vir a ser descredenciada do projeto. As instituições avaliadoras remetem relatórios periódicos para a SOFTEX e em caso de descumprimento de algum ponto ou processo, a mesma irá tomar medidas para o desvinculamento do projeto Benefícios Na realidade, o modelo MPS, nada mais é do que uma espécie de gerenciador do dia-a-dia organizacional e representa um padrão, ou seja, as empresas que optarem por implementá-lo terão diversos benefícios, isto é claro

67 66 dentro de uma margem de erro que pode ocorrer caso o projeto não esteja bem elaborado, os profissionais qualificados e o controle pós implementação não seja feito. A princípio, as vantagens da implementação do nível G serão totalmente práticas, como por exemplo, o melhor desempenho possível de cada processo dentro da organização. Um processo que já havia sendo realizado antes mesmo da implementação, mas que fez parte da análise, recebeu alterações, pode trazer maiores benefícios em relação a menores gastos, ou simplesmente ter seu tempo de processo diminuído e com a mesma praticidade de antes e até melhor. Com o aumento de desempenho de processos individuais, a médio, longo ou até mesmo curto prazo, desencadeará um aumento da produtividade e competitividade da empresa no mercado de atuação. Um dos benefícios mais desejados por um grupo de supervisores, gerentes e acionistas de empresa, é a ideia de economia, ou seja, a redução nos custos. Ao optar pelo caminho da padronização de processos pode-se chegar a esse almejo e tornar esse desejo uma realidade. Com a aplicação do nível G, pode-se até ir aquém do esperado, chegando a ganhos com produtividade e claro, qualidade no desenvolvimento de softwares. A implantação do nível G de maturidade é apenas o começo de um caminho para a empresa que optar pelo modelo MPS. Mesmo sendo apenas o início dos trabalhos, o nível G poderá contribuir muito com a redução de custos. A padronização de processos trará benefícios nas áreas de desenvolvimento, operação, atendimento a clientes, treinamento da equipe, capacitação de profissionais. Computadores de vários modelos, fabricantes, com sistemas operacionais diferentes e com programas instalados por funcionários da instituição sem a permissão, outros que já vieram na configuração original, é essa a realidade da maioria das organizações. Isto pode e deve mudar, pois com várias máquinas configuradas exatamente iguais, de mesmo modelo e fabricante, considerando uma empresa de porte médio, com diversos equipamentos de informática ficam claras as vantagens que a implementação do nível G trará, pois a padronização não se dará

68 67 apenas em nível de processos e atividades, mas também pode atingir os equipamentos. Não só a área de informática propriamente dita e o setor de TI serão beneficiados por essa padronização, mas também o setor financeiro, jurídico e o setor de compras, pois se encontram totalmente envolvidos nas atividades e serão atingidos pela padronização e gerenciamento de processos Comparativos Como visto, não existe um único modelo de padronização de processos no desenvolvimento de software, portanto, segue uma pequena análise comparativa do modelo MPS com o modelo CMMI e ISO. O projeto MPS.BR é compatível com o modelo CMMI como um todo, ou seja, tudo o que o CMMI implementa, o modelo MPS também, o contrário não ocorre porque o projeto MPS.BR inclui implementações que não são abordadas no CMMI. Tanto o CMMI quanto o modelo MPS apresentam suas estruturas baseada em níveis de maturidade para o empreendimento. Objetivos são estabelecidos e conforme vão sendo alcançados, o nível de maturidade aumenta e também aumentam as responsabilidades da organização e dos profissionais envolvidos. FIGURA 9: Modelos de Padronização FONTE: (AUTOR DESCONHECIDO, S/D)

69 68 No modelo MPS, a empresa que se destinar a implementar o nível G que é o primeiro nível de maturidade, deve ter alguns processos já definidos, o que não acontece no CMMI, este modelo não pede definição de processos antes do início dos trabalhos. A Tabela 3 mostra a equivalência entre os níveis do CMMI e do MPS.Br. TABELA 3: MPS e CMMI Comparação dos Níveis de Maturidade CMMI MPS.Br 1 Não Definido - G 2 F - E - D 3 C 4 B 5 A FONTE: (PONTO DA TECNOLOGIA, 2006) Comparativo Relativo aos Custos A realidade da grande maioria das empresas brasileiras ainda é o orçamento reduzido e os custos relativamente altos por conta da demasiada burocracia e dos impostos exorbitantes cobrados pelo governo. Por ser uma opção para empresas de micro, pequeno e médio porte, o projeto MPS.BR apresenta uma redução relativamente grande de custos se comparado às normas internacionais de melhoria de software. Segundo o site WIKIPÉDIA (2010), o custo de uma certificação para uma empresa pode ser de até US$ (quatrocentos e cinquenta mil dólares). JAMORI E ZABEU (2007) afirmam que a implementação do CMMI fica em torno de USS$ ,00 (oitossentos e cinquenta mil dólares). Tanto na primeira quanto na segunda estimativa, os valores são totalmente inviáveis para empresas em fase de aceitação e até mesmo para aquelas que já conquistaram o seu espaço no mercado de atuação.

70 69 TABELA 4: Custo em R$ da Implementação e Avaliação do Projeto de Melhoria de Software MPS.Br. NÍVEL CUSTO DE IMPLANTAÇÃO TAXA DE CUSTO DE AVALIAÇÃO AVALIAÇÃO Nível G Nível F com o G antes direto no F Nível E com G antes Nível D com G antes com F antes Nível C com G antes com E antes Nível B com C antes Nível A com B antes Fonte: (SOFTEX, 2009). Observando a Tabela 4, observa-se que os valores relativos ao modelo MPS são relativamente menores se relacionados aos valores apresentados pelo modelo CMMI, mas ainda se torna necessário que a empresa interessada possua recursos e esteja em um patamar significativamente elevado de atuação e mercado.

71 70 CONSIDERAÇÕES FINAIS. Baseando-se na fundamentação teórica que integra a presente pesquisa, observou-se que se inicia uma nova era para micro, pequenas e médias empresas, pois o modelo MPS apresenta a solução teórica para a melhoria de processos de desenvolvimento de software de forma organizada e com menores custos que prometem não ultrapassar os recursos disponíveis para a maioria das empresas brasileiras e também de países em expansão. O projeto apresenta uma estrutura em níveis de maturidade, na qual as organizações deverão seguir guias, passos, normas e processos definidos para só então fazer o devido enquadramento do ambiente organizacional no projeto de implementação e, mediante resultados e comprometimento receber a certificação MPS.Br. Além de precisar se enquadrar nos requisitos constantes no modelo de referência que forem planejados e estabelecidos pelos implementadores em conjunto com a equipe em geral, existirá ainda um acompanhamento posterior, que implicará na permanência ou não da empresa no projeto e que demonstrará se a mesma está em conformidade e se está dando continuidade aos requisitos e objetivos acordados para o projeto em si. Este controle e acompanhamento serão necessários para que a organização permaneça com a certificação e também para que possa avançar os níveis de maturidade conforme a evolução de seus processos. O projeto MPS.Br conta com um extenso número de guias disponíveis para leitura, pesquisa e implementação. A instituição que decidir por implementar o modelo MPS, desde o primeiro nível que é o nível G, deverá estar em conformidade com a documentação condizente com o seu nível de maturidade e deverá estar em constante avaliação e aprimoramento em seu dia-a-dia principalmente do que se refere a processos.

72 71 Enfim, conclui-se que os processos de software se tornam mais importantes com o passar do tempo e com a exigência cada vez mais refinada por parte dos usuários, que primam pela obtenção de um produto final acessível e de qualidade. Conclui-se também que todos os processos organizacionais devem passar por certa análise, planejamento e avaliação para se chegar efetivamente a um nível de melhoria de processo de software. E que essa melhoria não atinja somente a questão do desenvolvimento de software em si, mas o setor de TI como um todo no ambiente empresarial e também os demais setores constantes nas empresas.

73 72 REFERÊNCIAS BIBLIOGRAFICAS. ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. Tecnologia de Informação Avaliação de Produto de Software Características de Qualidade e Diretrizes para o Seu Uso, NBR Rio de Janeiro, p. ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO - SOFTEX. MPS.BR FAQ: Diversos. Disponível em: Acesso em 28 de agosto de 2009., MPS.BR - Estrutura Organizacional do Programa. Disponível em: Acesso em 28 de agosto de 2009., MPS.BR Guia de Avaliação. Versão 1.2, Disponível em: < Acesso em 25 de setembro de 2010., MPS.BR Guia Geral. Versão 1.2, Disponível em: < Acesso em 25 de setembro de 2010., MPS.BR Guia de Implementação: Parte 1: Nível G. Versão 1.2, Disponível em: < Acesso em 12 de agosto de FILHO, Wilson de Pádua Paula. Engenharia de Software: fundamentos, métodos e padrões. 3. Ed. Rio de Janeiro: LTC, p. FONTE, Nelson Baptista. Análise da Evolução de Software com Séries Temporais. Disponível em: < Acesso em 25 de Novembro de 2010.

74 73 FURASTÉ, Pedro Augusto. Normas Técnicas para o Trabalho Científico. 15. ed. Porto Alegre: Dáctilo Plus, p. M. M. Lehman and J. F. Ramil. Software evolution and software evolution processes. Ann. Softw. Eng., 14(1-4): , MORIYA, Robson Koji. RUP - Environment discipline: RUP Metodologia. Disponível em: < Acesso em 24 de Novembro de NOGUEIRA, Marcelo. Projeto de Software de Tempo Real. Disponível em: < Acesso em 05 de novembro de PROJECT MANAGEMENT INSTITUTE. PMBOK Guia do Conjunto de Conhecimentos em Gerenciamento de Projetos. 3ª edição, Disponível em: < Acesso em 25 de setembro de PRASS, Fernando. Engenharia de Software: Modelo por Prototipação. Disponível em: < Acesso em 14 de novembro de PRESSMAN, Roger S. Engenharia de Software. 6ª edição. São Paulo: Makron Books, SANTOS, Priscila Cunha. Evolução Tecnológica na Área de Informática: Evolução Tecnológica do Software. Disponível em: < Acesso em 20 de Outubro de SOMMERVILLE, Ian. Engenharia de Software. 6ª Edição. Ed. Addison Wesley, Disponível em: vfinal11.pdf. Acesso em 12 de Junho de 2009;

75 74 Spiral model of Boehm. Disponível em: Acesso em 14 de novembro de WIKIPÉDIA. Melhoria de Processos do Software Brasileiro. Disponível em < Acesso em 18 de Maio de CMMI. Disponível em < Acesso em 19 de Maio de ISO Disponível em < Acesso em 13 de Novembro de WORDPRESS. Qualidade de Software. Disponível em < Acesso em 13 de Novembro de 2010.

76 75 ANEXOS. ANEXO A: Exemplo de aplicação de um modelo de placar para avaliação de projetos (Viabilidade) FONTE: (Chalos, 1992)