UMA PROPOSTA BASEADA NA GESTÃO DE PROJETOS PARA AQUISIÇÃO DE SOFTWARE PELA ADMINISTRAÇÃO PÚBLICA

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

Download "UMA PROPOSTA BASEADA NA GESTÃO DE PROJETOS PARA AQUISIÇÃO DE SOFTWARE PELA ADMINISTRAÇÃO PÚBLICA"

Transcrição

1 XXIX ENCONTRO NACIONAL DE ENGENHARIA DE PRODUÇÃO. UMA PROPOSTA BASEADA NA GESTÃO DE PROJETOS PARA AQUISIÇÃO DE SOFTWARE PELA ADMINISTRAÇÃO PÚBLICA Ana Elisabete Cavalcanti de Albuquerque (GIRO/UFPE) Marcos André Mendes Primo (PROPAD/UFPE) Felipe Augusto Pereira (GIRO/UFPE) A aquisição de produtos de software no setor público brasileiro costuma ser executada como um mero processo de compra com apenas controles falhos de custos e prazos. Em consultas realizadas em outros órgãos públicos estaduais, que adquiriraam produtos desta natureza, constatou-se a deficiência de informações relativas a requisitos do software, critérios para seleção e avaliação do desempenho dos fornecedores, critérios para mensuração da qualidade e testes no produto, dentre outras. O presente estudo propõe a aplicação das boas práticas da gestão de projetos para tornar a aquisição de software do tipo parametrizável mais efetiva no que concerne à otimização de recursos, diminuição de incertezas e controles mais eficazes. Partindo de uma pesquisa sobre qualidade de software, contratos e reivindicações na administração pública, riscos e problemas na aquisição de produtos de software, e análise das entrevistas com gestores de TIC (Tecnologia da Informação e Comunicação), pertencentes a órgãos públicos no Estado de Pernambuco, é apresentado um plano de projeto para aquisição de software. O plano apresentado, elaborado com base na literatura pesquisada e nos processos de aquisição atuais, visa fornecer aos gestores de TIC orientações importantes quanto ao planejamento, execução e controles nesse tipo de aquisição, ressaltando a importância de adaptá-lo às necessidades específicas do órgão, ou empresa, para que possa contribuir sobremaneira para o alcance dos objetivos planejados. Palavras-chaves: Aquisição de software, gestão pública

2 1. Introdução Desde o seu surgimento comercial até sua popularização, a tecnologia da informação (TI) evoluiu de um papel tradicional de suporte administrativo a uma posição estratégica nas organizações (LAURINDO et al., 2001). Essa importância, aliada a um número cada vez maior de fornecedores de soluções, exige que os contratantes tenham cada vez mais atenção na aquisição. Na administração pública, em particular, a contratação de software é uma questão bastante complexa, por diversos fatores (GUERRA; ALVES, 2004): Por não necessitar realizar lucros, o serviço público tem dificuldade de calcular rigorosamente os custos internos; Há necessidade de especialistas em tecnologia, em gestão de projetos especificamente e evasão destes profissionais para o setor privado; Alguns órgãos públicos tomam para si a responsabilidade pela gestão dos projetos, enquanto consultores externos são responsáveis pela condução de partes bem definidas dos projetos. Projetos numa organização são demandados, segundo Menezes (2001), por fatores como melhoria e inovação em produto ou serviço, melhoria interna, mudança organizacional, gestão estratégica da empresa, trabalho com prazos e recursos limitados e compartilhamento de recursos escassos. A Reforma do Estado trouxe consigo preocupações por parte da administração pública, em implementar soluções que priorizem as necessidades do cidadão, promovam a abertura das informações, possibilitem a competitividade de fornecedores e primem pela qualidade dos produtos e serviços adquiridos e prestados (SAUR, 1997). Isto não só com o objetivo de preservar e gerir de forma responsável os recursos públicos, como também de prestar um serviço mais efetivo ao cidadão. Tais mudanças levam à ocorrência, senão de todos, de alguns dos supracitados fatores que demandam projetos. Em geral, empresas de desenvolvimento de software são voltadas a projetos (PEREIRA, 2008). Utilizando a abordagem de Menezes (2001) que os caracteriza como sendo um composto de atividades inovadoras, verifica-se que o processo de aquisição de produtos de software também possui características de projeto, tais como: conclusão quando todas as exigências contratadas são atendidas pelo fornecedor, horizonte temporal limitado, recursos alocados pelo período de sua vigência, envolvimento de várias áreas do conhecimento, gastos variáveis, controle de qualidade conforme as especificações e prazos que devem ser rigorosamente seguidos. Assim, conceber a aquisição de produtos de software como um projeto, com um plano adaptado às necessidades da empresa, permite facilitar o trabalho em grupo tornando-o produtivo e efetivo, adotar procedimentos para riscos e restrições conhecidos, possibilitar comunicação eficiente, disseminar conhecimento, identificar de forma clara as responsabilidades e possibilitar o uso dos erros e acertos no aperfeiçoamento do processo. Diante do exposto, essa pesquisa visa propor um modelo de plano de projeto para aquisição de software, com o objetivo de minimizar os riscos, otimizar recursos e eliminar problemas de extrapolação de prazos e custos, através de um estudo multicaso com dois órgãos da administração pública do estado de Pernambuco. 2. Referencial teórico 2

3 Para alcançar seus objetivos, a pesquisa teve um arcabouço teórico baseado em qualidade, contratos e reivindicações em projetos, e problemas na aquisição de produtos de software Qualidade em software A qualidade de software, importante elemento tanto para a empresa que o desenvolve quanto para a compradora, é composta por três componentes: qualidade de produto, de projeto e de processo (ROCHA, 2004), conforme detalhado abaixo: Qualidade de produto: A qualidade de produto é definida por um conjunto de características que devem ser alcançadas em um determinado grau para que o produto atenda às necessidades de seus usuários. É através deste conjunto de características que a qualidade de um produto pode ser descrita e avaliada (ROCHA, 2004, p. 111). Qualidade de projeto - para que a gestão do projeto gere resultados positivos no processo de desenvolvimento de software, é necessário: identificar e definir indicadores para o projeto a ser executado; realizar as medidas durante sua execução (coletar estas informações); analisar suas tendências para verificar se o que foi planejado metas, cronograma, custos, etc. está sendo cumprido; e realizar os ajustes necessários. A aplicação destes conceitos na gestão de projeto contribui para que os conflitos entre qualidade, custo e prazo sejam minimizados, e para a garantia da satisfação do cliente. Qualidade do processo - é determinada pelo grau de flexibilidade para incorporar características implícitas de qualidade de produto e novos métodos, técnicas e ferramentas, ao processo. O processo de software é a sequência de passos para construção de um produto de software. A qualidade desse processo pode ser determinante, no longo prazo, para a qualidade de produto e de projeto. Com a intensificação da concorrência internacional na área de comercialização de produtos de software, normas para alcance de níveis de qualidade aceitáveis passaram a ser condição obrigatória para a realização de negócios internacionais. Para atender a essas exigências, muitas empresas desenvolvedoras implantaram algumas normas ISO (International Organization for Standardization) aplicadas ao software, não de forma rígida e inflexível, mas adaptadas ao tipo de negócio, às regras e características dessas empresas. Empresas desenvolvedoras de software costumam certificar-se na ISO 9000, com discriminação no escopo da área ou processo de software para a qual a certificação for concedida (XAVIER, 2001). Contudo, necessitam não apenas adotar/adaptar as diretrizes dessa norma, mas aplicar outras, próprias para produtos e serviços de software. Assim, podem-se citar as normas ISO/IEC (qualidade de pacotes de software), ISO/IEC (processos de ciclo de vida do software), ISO/IEC (guias para avaliação de produtos de software) e ISO/IEC 9126 (norma para qualidade dos produtos de software). Essa última, segundo Antonioni e Rosa (1995), apresenta seis características básicas, através das quais podem ser estabelecidas métricas para a qualidade do software. As características fornecem base para posterior detalhamento ou subcaracterísticas, conforme quadro a seguir. Característica Descrição Subcaracterísticas Mede as capacidades do software, ou seja, o Padrões funcionais, adequação, Funcionalidade conjunto de funções oferecidas ao usuário, que segurança de acesso, precisão e satisfaça suas necessidades. interoperabilidade. Usabilidade Avalia o esforço necessário ao uso do software e Operabilidade, inteligibilidade, 3

4 Confiabilidade Desempenho Eficiência ou Manutenibilidade Portabilidade ao seu aprendizado (treinamento). Determinada por fatores como interface, ease-to-use, documentação clara e material de treinamento adequado. É determinada por fatores como segurança, ausência de falhas e resultados corretos. Refere-se ao desempenho, tempo de resposta e uso eficaz dos recursos do sistema. É medido pela relação nível de desempenho do software versus quantidade de recursos usados. Está relacionada ao esforço necessário para fazer modificações específicas ou correções no software. A análise pode ser feita considerando facilidade/ rapidez de manutenção, custo das manutenções, tempo médio das falhas e dos reparos. Avalia basicamente a habilidade do software de ser transferido de um ambiente para outro. Fonte: adaptado de Antonioni e Rosa (1995) apreensibilidade, atratividade. Maturidade, tolerância a falhas e ao mau uso por parte do usuário, recuperabilidade. Comportamento em relação ao tempo e aos recursos, e quantidade de recursos de sistema alocados. Analisabilidade, modificabilidade, estabilidade, testabilidade. Adaptabilidade, esforço para instalação, coexistência, capacidade para substituir e conformidade. Quadro 1 - Características e subcaracterísticas básicas para medir a qualidade de software Para facilitar a mensuração prática, as subcaracterísticas apresentadas no quadro 1 podem ser desdobradas pelos usuários da norma. Uma vez determinados quais atributos serão avaliados no software, o passo seguinte é a definição das métricas, ou seja, como cada atributo poderá ser medido de maneira a indicar sua proximidade ou distância em relação ao que se pretende do software. Instruções sobre a determinação dessas métricas podem ser encontradas em Antonioni e Rosa (1995) e Rocha (2004) Contratos em projetos Carneiro (2006) detectou quatro tipos de contratos passíveis de serem utilizados em projetos: por administração, por preço unitário, por preço global e chave na mão, conforme pode ser visualizado no quadro 2. Tipo Indicação Vantagens Desvantagens Flexibilidade; baixo risco Situações em que o objeto, prazo Por para a contratada; possibilita e escopo não estão ainda bem administração o início de serviços definidos, mas o início dos (Cost Plus) prioritários, mesmo com serviços é prioritário. pendências. Por preço unitário (Unit Price) Situações nas quais o fornecimento é bem definido em termos qualitativos (objeto), mas ainda não totalmente definido em termos de quantidades (escopo) e de prazos. Possibilita a contratação antes da conclusão da especificação; permite antecipar o início dos serviços; pode ser uma solução temporária. Grande responsabilidade da contratante na direção dos serviços exigindo grande coordenação e fiscalização; e imprevisibilidade de custos. Necessita de definição clara dos itens de fornecimento; necessita de grande estrutura de coordenação e fiscalização; e demanda aprovações prévias de quantidades. Por preço global / preço fechado / Situações com fornecimento bem definido em termos de objeto, escopo e prazo. A especificação As responsabilidades em sua maioria são transferidas para a contratada; menor necessidade de controle de Necessita de projeto mais avançado, com quantidades definidas; maior risco da contratada (custo geralmente preço fixo do projeto é de responsabilidade quantidades; e maior elevado); menor número de (Lump Sum) da contratante, ficando a disponibilidade para concorrentes; desgastes execução a cargo da contratada. monitorar qualidade e quanto à abrangência do prazos. escopo. Chave na mão O fornecedor é responsável pela Estrutura reduzida de Menor número de 4

5 (Turn Key) oferta de uma instalação completa (projeto), que proporcione o resultado desejado (funcionalidade do produto), a custo e prazos determinados. Fonte: adaptado de Carneiro (2006) coordenação e fiscalização por parte do contratante; responsabilidade total do fornecimento pela contratada. Quadro 2 Tipos de contratos que podem ser utilizados em projetos concorrentes capacitados; e custo elevado (risco, coordenação, subcontratação). Tais tipos contratos podem ser utilizados para aquisição de produtos de software conforme o tipo/classificação do software a ser adquirido, setor (privado ou público) e necessidades da empresa Reivindicações Reivindicação, segundo Wille (2005), é um pedido legítimo de compensação adicional de custo ou prazo ao cliente. Este pedido é uma forma de compensar os prejuízos que possam ter ocorrido durante a execução de um projeto. Segundo o autor, pode ser causada por quatro situações principais: Situações modificadas alterações das situações previamente acordadas no contrato. Trabalhos extras serviços executados sob condições de preços e prazos não acordados previamente. Atrasos podem ser de responsabilidade tanto do contratante como do contratado. Prazo no contrato - divergências na requisição de tempo extra para o contrato em função de mudanças ocorridas. O processo de reivindicação costuma fazer parte de projetos cujo escopo inicial não pôde ser definido com grande detalhamento, denominado por Carneiro (2006) de contrato por administração (Cost Plus). O guia PMBoK (PMI, 2004) dispõe sobre os cuidados que devem ser tomados na preparação e manipulação dos contratos de maneira a prevenir situações de conflito advindos das reivindicações. Neste guia, o processo de gerenciamento de reivindicações está dividido em quatro partes: identificação, quantificação, prevenção e resolução. Para evitar reivindicações, o contratante precisa antever situações nas quais possam ocorrer e fazer com que já constem em contrato, além de elaborar um contrato claro, objetivo e completo no tocante a tudo que espera que o contratado execute e não realizar qualquer mudança sem que seja documentada e acordada entre as partes (WILLE, 2005) Problemas na aquisição de produtos de software Na aquisição de produtos e serviços de software, podem surgir algumas situações negativas como a recusa do contratado em colocar à disposição do cliente, para uso, as primeiras versões do sistema, como teste beta, preferindo entregar uma versão final, sua proibição quanto a participantes externos nas revisões do sistema ou o não fornecimento de informações necessárias para a execução dos testes (GUERRA; ALVES 2004). Tais ações anteriores por parte do contratado conduzem a uma série de mal-entendidos e erros nas fases iniciais do desenvolvimento, que somente serão descobertos no final do projeto. Além desses, há elementos que envolvem tanto clientes quanto fornecedores, como: estimativa não realista de custo; estimativa não realista de recursos humanos; planejamento insuficiente para os testes do software e de integração do sistema; codificação do produto 5

6 iniciada pelo fornecedor antes que os requisitos estejam devidamente estabilizados e a engenharia do produto, completa; incompetência do cliente e fornecedor para a realização do trabalho; atritos internos à organização, os quais ocasionam o não-uso do produto adquirido (GUERRA; ALVES 2004). Segundo as autoras, tais aspectos levam a problemas clássicos referentes à aquisição de produtos de software, como: custo maior que o previsto, alto custo de manutenção, descumprimento de cronograma, relação pobre entre cliente e fornecedor, produtos não exequíveis, não-atendimento das necessidades do usuário, não-atendimento das expectativas do usuário, não-atendimento dos requisitos especificados, dificuldades de personalização do produto de software, perda de controle e falta de acompanhamento do projeto, falta de visibilidade dos processos do subcontratado, ciclo de desenvolvimento muito longo, excesso de retrabalho, falta de habilidade de prever problemas, dificuldade na prevenção de defeitos, baixa disponibilidade de recursos humanos e alto turnover de pessoal. 3. Metodologia A pesquisa teve como objetivo geral criar um modelo de plano de projeto para aquisição de software pela gestão pública, com o objetivo de minimizar os riscos, otimizar recursos e eliminar problemas de extrapolação de prazos e custos. Para tanto, foi realizado um estudo de caso instrumental (STAKE, 1995), com dois órgãos da administração pública do estado de Pernambuco. O estudo teve natureza qualitativa, que permite obter detalhes do fenômeno em análise e compreender processos (MERRIAM, 1998), a partir da coleta de informações compreensivas, sistemáticas e profundas sobre os casos em estudo (PATTON, 2002). O órgão 1 tem 60 anos e sua atividade-fim é a pavimentação e conservação das rodovias estaduais. Com o objetivo de automatizar processos inerentes à sua atividade-fim foram adquiridos, no período de 2000 a 2006, softwares parametrizáveis tais como Medições e Acompanhamento de Obras, Custos e Orçamentos de Obras, Sistema de Cálculo e Quantitativo de Medições; e outros inerentes à atividade-meio como: Controle de Protocolo, Gerencial Financeiro, Sistema Integrado de Compras e Sistema de Contratos de Consultoria. O órgão 2, criado em 1976, tem como atividade fim a gestão ambiental no estado. Automatizou nos últimos anos autos para as infrações ambientais e realizou manutenções corretivas em alguns sistemas, dentre eles o Sistema de Protocolo. Inicialmente, foi realizada uma pesquisa bibliográfica, de modo a conhecer a literatura acerca das temáticas relacionadas ao fenômeno pesquisado, já apresentadas no capítulo 2. Posteriormente, foi elaborado o roteiro de entrevistas, com 20 (vinte) questões semiestruturadas, o que permitiu flexibilidade na coleta de dados. As questões foram definidas a partir da pesquisa bibliográfica e da experiência dos pesquisadores. A coleta de dados foi realizada através de observações, análise documental e entrevistas. As observações foram registradas e as entrevistas foram transcritas, conforme recomendação de Merriam (1998). Os registros das observações, documentos e transcrição das entrevistas foram analisados iterativamente (MERRIAM, 1998), de modo a identificar aspectos relevantes para o estudo. Com base nos dados coletados, foram identificados os processos existentes para a aquisição de software, identificadas as principais dificuldades e proposto um modelo a ser seguido, de modo a tentar resolver os problemas. 4. Processos de aquisição de software nos órgãos pesquisados 6

7 Nesta seção estão descritos os processos de aquisição de software nos dois órgãos pesquisados, em função da iniciação, análise de custo x benefício, levantamento de requisitos, identificação de riscos, elaboração do termo de referência, cronograma da aquisição, contratação, seleção e avaliação de fornecedores e encerramento do contrato. Inicialmente, o setor ou área de TI toma conhecimento da necessidade de aquisição de um produto de software através de pronunciamento do usuário ou através da detecção de um problema pela área de TI. É realizada uma análise sobre a real necessidade de aquisição do produto, seus benefícios, vantagens e desvantagens, mas de modo empírico, conforme declarações dos dois gestores, sem a utilização de qualquer metodologia apropriada. Sobre análise de custo versus benefício, o gestor de TI do órgão 1 afirma que é realizada uma análise superficial, ou seja, o chefe do setor e os usuários são arguidos sobre a utilização do software, nada mais. Segundo o gestor do órgão 2: Mesmo sem ter uma metodologia para análise de custo x benefício, isto é feito de modo empírico. Quando há demanda para desenvolvimento de softwares estes aspectos também são analisados (Coordenadora de TI do órgão 2). Em ambos os órgãos, as equipes formadas para trabalhar na implantação dos softwares junto com o fornecedor são, geralmente, multifuncionais, envolvendo a área que utilizará o software, a informática, o setor jurídico e a direção, na figura do ordenador de despesas. Em geral, os requisitos levantados são: funcionais, relativos às funcionalidades próprias do software; não funcionais como atratividade e apreensibilidade; operacionais - manuais, treinamento, operacionalidade; e de integração com o ambiente existente. Os procedimentos para levantamento dos requisitos no órgão 2 abrangem a formação de uma equipe, constituída de profissionais de TI e da área usuária, e utilização de uma metodologia própria para levantamento de requisitos, resultando em um levantamento mais elaborado (diagramas de caso de uso, fluxos de execução, alternativos e de exceção, etc.). No órgão 1, o levantamento refere-se apenas à determinação das funcionalidades obrigatórias para o software a ser adquirido, assim como requisitos de segurança e de integração com o ambiente de TI. Nenhuma metodologia própria para levantamento de requisitos é utilizada. No órgão 2, existe um controle mais efetivo relacionado a prazo e custo, no sentido de minimizar os riscos de extrapolação. No entanto, outros riscos como desinteresse da equipe ao longo do projeto e o software não atender às expectativas do usuário, não são considerados, apesar de, segundo depoimento abaixo transcrito, já ter acontecido. Quando há o envolvimento dos usuários não há grande risco de desinteresse da equipe. Isto já ocorreu quando da mudança de governo, em relação a um software de planilha há bastante tempo atrás. Mas ainda deve haver, casos como este no Estado. (Coordenadora de TI do órgão 2). O gestor do órgão 1 declarou não realizar análise de riscos e pesquisa documental revelou a descontinuidade de um grupo de sistemas integrados por falta de manutenção e não envolvimento dos usuários que operariam os sistemas. O orçamento básico é preparado com base em pesquisa de mercado quando se trata de um software já existente. Em caso de desenvolvimento, ambos costumam levantar os requisitos e contratar os serviços de uma empresa (por meio de licitação) com profissionais qualificados. Desta forma, os riscos relacionados ao tempo, experiência da equipe e infra-estrutura de desenvolvimento fica por conta da empresa contratada. 7

8 Existe, em ambos os órgãos, uma sequência empírica de atividades para aquisição de software: o usuário solicita, realiza-se um levantamento dos requisitos, prepara-se o termo de referência, submete-se ao ordenador de despesas (diretor executivo), elabora-se o edital com seus anexos (minuta do contrato, termo de referência, critérios de pontuação, orçamento básico e planilha de licitação), realiza-se a licitação e, por fim, a contratação. No órgão 1, o termo de referência é um anexo do edital e contém exclusivamente requisitos do produto. No órgão 2, o termo de referência é elaborado tal qual um edital, com objetivo, justificativa, gerente do projeto, equipe envolvida, requisitos do produto, restrições, orçamento básico, critérios de avaliação do software, qualificações exigidas e penalidades, entre outros itens. Isso ocorre porque o órgão frequentemente faz uso de recursos de convênios que exigem tal formato para a aprovação pelo ministério apropriado, antes dos procedimentos para a licitação. A elaboração deste documento fica a cargo da área de TI em parceria com a área usuária. Todas as áreas porventura interessadas têm acesso a ele através de consulta ao processo. Para facilitar o entendimento deste ponto em diante, edital será sinônimo de termo de referência e de documento de aquisição. Não existe cronograma para execução das atividades relativas à aquisição de software. Em ambos os casos, o fornecedor deve elaborar cronograma com base no número de dias especificado no edital para implantação ou desenvolvimento do software. Este cronograma deve ser submetido à aprovação do usuário que, na prática, apenas o ratifica. O contrato em ambos os casos é administrado pela área de TI, apoiada pelo setor interessado. No órgão 1 são utilizadas as modalidades por preço global ou preço fixo. O órgão 2 utiliza por preço unitário, por preço global e chave na mão. Em ambos os órgãos, a área jurídica é encarregada de elaborar a minuta do contrato, utilizando modelos prédeterminados. A minuta é parte integrante do edital. No órgão 2 existe uma base de dados com fornecedores que, conforme o tipo de aplicação que desenvolvem, podem ser consultados para a elaboração de uma proposta preliminar para revisão de preços e composição de custos, conforme afirmação da coordenadora de TI do órgão 2: Características conhecidas dos fornecedores podem definir os que vão participar da proposta preliminar para revisão de preços/composição de custos. Nos dois casos, os fornecedores tomam conhecimento do edital através de publicação nos websites das instituições, no Diário Oficial do Estado e em um jornal local de grande circulação. O edital é passivo de mudanças no período de publicação, tanto em razão de questionamentos por parte dos fornecedores, como por parte do Tribunal de Contas do Estado. A alteração quase sempre resulta em adiamento da data de apresentação e abertura das propostas de preços. Os critérios utilizados para selecionar o fornecedor são: regularidade jurídica, regularidade fiscal, qualificação técnica (comprovação de fornecimento de sistemas similares, quadro de funcionários com profissionais capacitados para a prestação do serviço, currículos resumidos dos profissionais que irão compor a equipe para execução das atividades), e qualificação econômico-financeira (balanço patrimonial e cronograma físico-financeiro). Certificações de qualidade são exigidas apenas para pontuação e não apresentá-las não constitui critério de desclassificação. Em nenhum dos órgãos são utilizadas métricas formais para avaliar o desempenho do fornecedor, conforme pode ser visualizado nos seguintes trechos das entrevistas: 8

9 (A avaliação dos fornecedores é feita) através do TR (termo de referência) pelos marcos constantes do Edital/TR. Tenho conhecimento de que alguns órgãos (RJ/Farmanguinhos) utilizam pontuação para indicar o desempenho de fornecedores. Mas não sei se colou. (Coordenadora de TI do órgão 2). O fornecedor submete seu cronograma, marcos e produtos de cada fase aos usuários do setor. São os usuários que acompanham estes marcos. (...) Quanto a monitoramento do fornecedor, fica geralmente a cargo da equipe de usuários do setor interessado monitorar a entrega dos produtos de cada fase. Não havendo o cumprimento das obrigações, o setor junto com a Gerência de Informática elabora um relatório que é encaminhado à direção para a aplicação das penalidades cabíveis. (Gestor de TI do órgão 1). Como procedimentos de encerramento do contrato foram identificados: no órgão 1, os usuários devem confirmar a entrega de todos os produtos e atestar que o software está em conformidade com as necessidades especificadas; no órgão 2, o encerramento acontece segundo o que está descrito no procedimento de homologação do produto, constante no edital, geralmente após a entrega dos manuais e atesto da equipe confirmando se a aplicação faz aquilo a que se propõe. 5. Análise dos resultados A análise a seguir baseia-se nos processos de aquisição de software acima descritos, relacionada aos pontos básicos da aquisição de software no setor público pernambucano Formação das equipes Observou-se que a rigidez da estrutura organizacional na Administração Pública não impacta o trabalho em equipes multifuncionais, necessário para o sucesso na utilização do software. Devido à contribuição imprescindível destas equipes, os dois órgãos observados adaptaram formas de designar pessoas para comporem grupos de trabalho, com usuários dos setores aos quais o software se destina, assessores jurídicos e financeiros, profissionais de informática, sendo estes responsáveis por todas as atividades relativas ao levantamento de requisitos, formulação do documento de aquisição, controles, testes, implantação e homologação Qualidade de software Foi observado o uso de características básicas para medir a qualidade do software propostas por Antonioni e Rosa (1995), tais como: 1) funcionalidade requisitos que satisfarão as necessidades dos usuários; 2) usabilidade basicamente treinamento e documentação do software; e 3) portabilidade do software em relação ao ambiente existente no órgão. Quanto às subcaracterísticas, foram observadas apenas para a característica funcionalidade, padrões funcionais, segurança de acesso, log, exportação e importação de dados. A falta de pessoal qualificado para determinar os atributos, indicadores e métricas para avaliação da qualidade do software pode ser uma explicação para a não utilização desta prática segundo o disposto na literatura pesquisada Análise de riscos Existe um controle mais efetivo por parte do órgão 2 na minimização dos riscos de extrapolação de prazos e custos. No entanto, outros riscos, como baixa qualidade do produto, cancelamento do projeto, produto que não atende às necessidades do usuário e retrabalho na codificação, não são considerados. Associado a esse fato, foi verificado que os tipos de contratos utilizados nesses órgãos, segundo categorização de Carneiro (2006), são por preço unitário, por preço global e, em 9

10 raras ocasiões, chave na mão. Os riscos por parte da contratante, nestes tipos de contrato, são geralmente mínimos, levando a supor que a ausência de análise de riscos faz com que estes órgãos a repasse para as empresas contratadas, por meio das formas de contratação Reivindicações As reivindicações são mínimas. Quando acontecem, as negociações ocorrem no nível de gerência e diretoria, o fornecedor deve documentar a reivindicação, e sua aprovação é publicada no boletim do órgão, na forma de um termo aditivo ao contrato. Das situações típicas em reivindicações mencionadas por Wille (2005), foram observadas alterações das situações previamente acordadas no contrato, atrasos de responsabilidade tanto do contratante como do contratado e divergências na requisição de tempo extra para o contrato em função de mudanças ocorridas. O fato das reivindicações serem mínimas pode se dar em vista dos contratos nos órgãos pesquisados não serem por administração, ou seja, são geralmente formas nas quais os riscos são contratualmente repassados para as contratadas, não existindo muitas situações que justifiquem negociações Capacitação de gestores de projeto As observações não constataram a presença de gestores de projetos capacitados nos quadros funcionais dos dois órgãos. Mesmo aos profissionais de TI, faltam conhecimentos próprios da área de gestão de projetos que possibilitem seu posicionamento frente aos fornecedores com a expertise necessária à realização das atividades. No órgão 1, segundo declaração do gestor de TI, são os usuários, membros do grupo de trabalho, quem monitora a entrega dos produtos de cada fase, segundo um cronograma submetido a eles pelo fornecedor. Percebe-se nesta declaração a ausência da figura do gestor de projetos. Isto evidencia um claro problema de capacitação de profissionais em empresas públicas, que neste caso pode ser uma das explicações para os problemas identificados no processo de aquisição Relação com fornecedores Os dois profissionais de TI entrevistados afirmaram não utilizar análise de desempenho do fornecedor. Apenas o órgão 2 afirmou manter uma base de dados na qual consulta fornecedores de produtos para auxiliar na composição do orçamento básico. É interessante para o órgão manter base de dados onde registre comportamentos do fornecedor como: datas das entregas dos produtos de cada fase, nível de qualidade destes produtos, relacionamento com a equipe de trabalho e com a direção, presteza nos demais compromissos, dentre outros. Isso permite reduzir a ocorrência de comportamentos inadequados e que incorram em prejuízos de qualquer espécie para a administração, através de novas cláusulas no contrato de prestação de serviços, se necessário. A seleção dos fornecedores envolve critérios como regularidade jurídica, regularidade fiscal, qualificação técnica e qualificação econômico-financeira. Muitas vezes, o melhor fornecedor para a administração pública (segundo preço e qualidade) deixa de enquadrar-se como tal por não atender a um daqueles critérios. Então até que ponto isto traz ganhos reais para a administração? Não trariam maiores benefícios se critérios mais específicos fossem adotados? 5.7. Problemas relativos à aquisição de produtos de software 10

11 Quanto aos problemas mencionados por Guerra e Alves (2004), foram identificados atraso no prazo de entrega, custo final maior que o custo previsto, repetição dos mesmos erros em várias compras, fornecedores que entregam apenas uma versão final, contratante sem competência para gerir projetos, falta de acompanhamento do projeto, alto custo de manutenção e não atendimento dos requisitos especificados. Isso indica que há necessidade de um processo mais bem definido para a aquisição de software, de modo que tais problemas sejam resolvidos e as organizações públicas sejam capazes de fazer melhor uso de seus recursos. 6. Proposta para a aquisição de software Com base nas que foi exposto nos capítulos anteriores, será proposto a seguir um plano sugerindo fases, atividades e respectivos produtos para um projeto de aquisição de produto de software por órgãos públicos. Espera-se que, com a aplicação de tal plano, diversos dos problemas identificados por Guerra e Alves (2004) sejam solucionados. O plano é composto por quatro grandes fases: Iniciação, Planejamento, Execução e Encerramento. Cada fase é formada por diversas atividades, responsáveis por diversos produtos no processo. No quadro 3, essas atividades estão definidas, em função de sua fase, detalhamento e artefatos gerados/obtidos. Fase/Atividade Discriminação Produto Iniciação Determinação da equipe Determinação da equipe de trabalho: gerente do projeto, especialistas das áreas de informática, financeira, jurídica, usuários, patrocinadores, etc. Equipe do projeto Análise da necessidade Análise da necessidade em adquirir o produto, incluindo um estudo das vantagens e desvantagens, dos custos envolvidos e disponibilidade dos recursos necessários. Documento de viabilidade do projeto Fase/Atividade Discriminação Produto Iniciação Decisão sobre realizar o levantamento ou contratar empresa que o faça (VILLAS-BOAS, 2004) e, em qualquer caso, levantamento dos requisitos do produto, tais como: processos a serem automatizados e necessidades dos Levantamento usuários a serem atendidas; compatibilidade do produto com a infraestrutura de TI existente; critérios de segurança do produto; pesquisa de de requisitos mercado para identificar a existência de produto com as características levantadas e os possíveis fornecedores. Planejamento Definição de critérios de avaliação e testes Análise de riscos Elaboração de orçamento básico Levantamento das atividades Elaboração de documento com escopo do Determinação dos atributos, indicadores e métricas para avaliar a qualidade do software (ANTONIONI e ROSA, 1995); Definição dos procedimentos de testes (WEBER e ROCHA, 2001). Identificação dos riscos e as formas de minimizá-los ou evitá-los (TORRES et al, 2005). Elaboração de orçamento básico para aquisição do produto com base em pesquisas de mercado. Discriminação das atividades com suas durações e datas de início e término; do inter-relacionamento entre as atividades; dos marcos versus produtos a serem entregues na ocasião; e das autoridades e responsáveis pelas atividades. Elaboração de artefato contendo: responsabilidades e autoridades do gerente, objetivo do projeto, justificativa, documento de viabilidade do projeto, relação da equipe do projeto, documento de requisitos do produto, plano Documento de requisitos do produto Plano para avaliação/teste do produto Plano de gerenciamento de riscos Orçamento básico Estrutura analítica e Cronograma do projeto Documento de escopo do projeto 11

12 projeto Escolha do tipo de contrato Elaboração de cronograma do fornecedor Preparação do contrato Elaboração do documento de aquisição (termo de referência e/ou edital) Execução Anúncio do documento de aquisição/edital Ajuste do documento de aquisição para avaliação e teste do produto, plano de gerenciamento de riscos, orçamento básico e cronograma do projeto. Análise das necessidades do projeto e definição do tipo de contrato mais adequado ao mesmo (CARNEIRO, 2006). Elaboração do cronograma, que deverá conter todas as atividades a serem realizadas pelo fornecedor e pelo contratante, com durações, responsáveis (contratante e contratado), datas de início e término, marcos versus produtos a serem entregues. Verificação do que deve ser observado em contratação (GUERRA e ALVES, 2004), planejamento das contratações (PMI, 2004), reivindicações (WILLE, 2005) e preparação e atualização do contrato, segundo a norma ISO/IEC (VILLAS-BOAS, 2004). Classificação da aquisição em modalidade e tipo de licitação adequados ao valor e natureza do produto de informática (PE/TCE, 2002). Observação de sanções no caso de inadimplemento (BITTENCOURT, 2003). Observação de como deve ser preparado o pedido de proposta (VILLAS- BOAS, 2004) e planejadas as compras e aquisições (PMI, 2004). O setor público deverá também observar os fatores técnicos para julgamento da proposta técnica (BITTENCOURT, 2003 e PE/TCE, 2002). O documento de aquisição deverá conter: condições de entregas proposta de preço (data, hora e local), objetivo do projeto, justificativa, relação da equipe do projeto, documento de requisitos do produto, plano para avaliação e teste do produto, orçamento básico, cronograma das atividades para o fornecedor, critérios de seleção e avaliação do fornecedor, critérios de avaliação das propostas (fatores e ponderação), condições de pagamento e de entrega. Comunicação aos interessados a intenção de adquirir produto de software com as características e condições de pagamento contidas no documento de aquisição ou edital de licitação através de publicações em jornais, disponibilização em site da empresa, revistas profissionais, etc. Disponibilização dos ajustes com documentação completa das mudanças e dos questionamentos que as provocaram, quando necessário, para todos os interessados. Tipo de contrato Cronograma do fornecedor Minuta do contrato Documento de aquisição (termo de referência e/ou edital) Publicação Documento de aquisição ajustado Fase/Atividade Discriminação Produto Execução Recebimento das propostas de preços Recebimento das propostas de preços e documentos dos fornecedores necessários para proceder à seleção, conforme condições constantes no documento de aquisição. Seleção de fornecedor Contratação de fornecedor Administração de contrato Monitoramento e avaliação de fornecedor Avaliação do produto e testes Encerramento Revisão e testes de aceitação Verificação de pendências Seleção do fornecedor de acordo com os critérios especificados (PMI, 2004). Assinatura de contrato, elaborado com base na minuta, anexa ao documento de aquisição, firmando o acordo entre contratante e contratado. Administração de contrato (PMI, 2004), com o registro das ocorrências na base de dados do projeto. Análise e avaliação do desempenho do fornecedor e administração reclamações (MALDONADO, 2004). Avaliação e testes nos módulos entregues, conforme plano para avaliação e teste do produto. Avaliação de acordo com o plano para avaliação e teste do produto. Havendo ajustes a serem realizados, o fornecedor fica obrigado a efetuá-los para só então ser executada a etapa seguinte. Encerramento do contrato (PMI, 2004). Deverá ser verificada a existência ou não de produtos a serem entregues pelo fornecedor (marcos versus produtos a serem entregues) e o cumprimento de todas as condições estabelecidas no contrato. Propostas e documentos de fornecedores Fornecedor selecionado Contrato assinado Registro das ocorrências Avaliação do fornecedor Módulos testados Produto avaliado e testado Contrato encerrado 12

13 Arquivamento das informações Registro das informações relativas ao projeto para posterior consulta e auxílio na elaboração de análises de riscos, orçamentos e cronogramas de projetos futuros, bem como em futuras seleções de fornecedores. Quadro 3 Plano proposto para aquisição de software pela administração pública Base de dados de projetos atualizada 7. Considerações finais Muitos dos riscos aos quais os projetos estão sujeitos se devem a indefinições ou definições falhas de custos, prazos, atividades, responsabilidades e escopo. Desta forma, a adoção de práticas oriundas da gestão de projetos, na forma de um plano de projeto, contribuiria para a minimização de incertezas e riscos afins. Ademais, controles relativos aos critérios de avaliação e testes, marcos versus produtos a serem entregues e monitoração do desempenho do fornecedor contribuiriam para a aquisição de produtos com maior qualidade e redução da extrapolação dos custos e prazos. Outrossim, permitiria um controle eficiente do desempenho do fornecedor durante a prestação do serviço, auxiliando na formação/atualização de uma base de dados com os respectivos desempenhos para consultas posteriores. A clara definição das atividades, bem como dos responsáveis pela execução e das autoridades envolvidas, concorreria para a otimização dos recursos e consequente eliminação do retrabalho. A implantação de um plano (modelo) tal qual foi concebido pode acarretar problemas na assimilação e aceitação do mesmo. As empresas, mesmo de ramos de negócio semelhantes, costumam ter características próprias (cultura organizacional, processo produtivo, competências) de forma que um plano pode ser implantado em uma com sucesso, e em outra, não atingir o mesmo resultado. Assim, é de extrema importância um trabalho de adaptação do plano elaborado às peculiaridades da empresa, para que o mesmo contribua sobremaneira para o alcance dos objetivos planejados. Entre as limitações dessa pesquisa, podem ser ressaltados vieses dos pesquisadores a que ela está sujeita, especialmente pelo seu caráter qualitativo, além do segmento empírico ter sido realizado com duas empresas e com um indivíduo de cada. Apesar disso, acredita-se que isso não inviabiliza o modelo, dado o caráter exploratório do estudo. Sugerem-se como trabalhos futuros a discussão de como implantar uma metodologia como essa nos órgãos públicos, uma análise de quais características específicas cada órgão poderia apresentar, de modo a já prever tais contingências no próprio modelo, além de uma avaliação de seus resultados após a implantação. Referências ANTONIONI, J. A.; ROSA, N. B. Qualidade em software. São Paulo: Makron Books, BITTENCOURT, S. Licitação de informática. Rio de Janeiro: Temas & Idéias, CARNEIRO, W. Análise comparativa de modelos de contratos propostos pelo PMBOK e pelo Código Civil Brasileiro. Revista MundoPM, n. 8, p. 6-12, GUERRA, A. C.; ALVES, A. M. Aquisição de produtos e serviços de software. Rio de Janeiro: Elsevier, LAURINDO, F. J. B.; SHIMIZU, T.; CARVALHO, M. M.; RABECHINI JR, R. O papel da tecnologia da informação (TI) na estratégia das organizações. Gestão & Produção, v. 8, n. 2, MALDONADO, J. C.; SANCHES, R.; FABBRI, S. C. P. F. Processo de software in ROCHA, A. R. C.; MALDONADO, J. C. & WEBER, K. C. Qualidade de software: teoria e prática. São Paulo: Prentice Hall, MENEZES, L. C. M. Gestão de projetos. São Paulo: Atlas,

14 MERRIAM, S. Qualitative research and case study applications in education. San Francisco: Jossey-Bass, PATTON, M. Qualitative research and evaluation methods, 3ª ed. Thousand Oaks: Sage, PE/TCE, PERNAMBUCO/TRIBUNAL DE CONTAS DO ESTADO. Licitações de bens e serviços de informática: guia prático para a elaboração de editais / Tribunal de Contas do Estado de Pernambuco. Recife: TCE/PE, Núcleo de Informática, PEREIRA, F. A. L Relação entre as Características Pessoais do Gerente de Projetos e o Desempenho de Projetos de Desenvolvimento de Software: Proposição de um Modelo. Dissertação (Mestrado em Administração). Recife: Universidade Federal de Pernambuco, PMI. PMBoK - guia do conjunto de conhecimentos em gerenciamento de projetos. 3. ed. New York: Project Management Institute (PMI), ROCHA, A. R. C.; MALDONADO, J. C. & WEBER, K. C. Qualidade de software: teoria e prática. São Paulo: Prentice Hall, SAUR, R. A. C. A tecnologia da informação na reforma do Estado: considerações sobre a prestação de serviços de informática na área pública. Ciência da Informação. Vol. 26, n. 1, p , STAKE, R. The art of case study research. Thousand Oaks: Sage, TORRES; J. BOESSO JR.; R. SANT ANNA, M. Gerenciamento de riscos planejamento ou futorologia? Revista MundoPM, n. 4, p , VILLAS-BOAS, A. Processos do ciclo de vida: processos fundamentais aquisição de software in Qualidade de software: teoria e prática. São Paulo: Prentice Hall, WEBER, K. C.; ROCHA, A. R. C. Qualidade e produtividade em software. 4. ed. São Paulo: Makron Books, WILLE, S. A. C. Reivindicações como gerenciar em projetos. Revista MundoPM, n. 3, p , XAVIER, J. H. F. ISO 9000 aplicada ao software in WEBER, K. C.; ROCHA, A. R. C. Qualidade e produtividade em software. 4. ed. São Paulo: Makron Books,

Prof. Dr. Ivanir Costa. Unidade III QUALIDADE DE SOFTWARE

Prof. Dr. Ivanir Costa. Unidade III QUALIDADE DE SOFTWARE Prof. Dr. Ivanir Costa Unidade III QUALIDADE DE SOFTWARE Normas de qualidade de software - introdução Encontra-se no site da ABNT (Associação Brasileira de Normas Técnicas) as seguintes definições: Normalização

Leia mais

FINANÇAS EM PROJETOS DE TI

FINANÇAS EM PROJETOS DE TI FINANÇAS EM PROJETOS DE TI 2012 Material 1 Prof. Luiz Carlos Valeretto Jr. 1 E-mail valeretto@yahoo.com.br Objetivo Objetivos desta disciplina são: reconhecer as bases da administração financeira das empresas,

Leia mais

MASTER IN PROJECT MANAGEMENT

MASTER IN PROJECT MANAGEMENT MASTER IN PROJECT MANAGEMENT PROJETOS E COMUNICAÇÃO PROF. RICARDO SCHWACH MBA, PMP, COBIT, ITIL Atividade 1 Que modelos em gestão de projetos estão sendo adotados como referência nas organizações? Como

Leia mais

Qualidade de. Software. Definições. Qualidade do Produto ISO 9126. Processo de. Software. Modelo de Processo de. Software CMM SPICE ISO 12207

Qualidade de. Software. Definições. Qualidade do Produto ISO 9126. Processo de. Software. Modelo de Processo de. Software CMM SPICE ISO 12207 Qualidade de : Visão Geral ISO 12207: Estrutura s Fundamentais Aquisição Fornecimento s de Apoio Documentação Garantia de Qualidade Operação Desenvolvimento Manutenção Verificação Validação Revisão Conjunta

Leia mais

TERMO DE REFERÊNCIA. 1. Objeto. 2. Antecedentes. 3. Objeto da Licitação

TERMO DE REFERÊNCIA. 1. Objeto. 2. Antecedentes. 3. Objeto da Licitação TERMO DE REFERÊNCIA 1. Objeto 1.1. Contratação de empresa especializada em auditoria de tecnologia da informação e comunicações, com foco em segurança da informação na análise de quatro domínios: Processos

Leia mais

Políticas de Segurança da Informação. Aécio Costa

Políticas de Segurança da Informação. Aécio Costa Aécio Costa A segurança da informação é obtida a partir da implementação de um conjunto de controles adequados, incluindo políticas, processos, procedimentos, estruturas organizacionais e funções de software

Leia mais

Qualidade de Processo de Software Normas ISO 12207 e 15504

Qualidade de Processo de Software Normas ISO 12207 e 15504 Especialização em Gerência de Projetos de Software Qualidade de Processo de Software Normas ISO 12207 e 15504 Prof. Dr. Sandro Ronaldo Bezerra Oliveira srbo@ufpa.br Qualidade de Software 2009 Instituto

Leia mais

Gestão da Tecnologia da Informação

Gestão da Tecnologia da Informação TLCne-051027-P0 Gestão da Tecnologia da Informação Disciplina: Governança de TI São Paulo, Outubro de 2012 0 Sumário TLCne-051027-P1 Conteúdo desta Aula Abordar o domínio Adquirir e Implementar e todos

Leia mais

14 Os principais documentos de um projeto são: o termo de. 15 Elemento integrante do gerenciamento do escopo do projeto,

14 Os principais documentos de um projeto são: o termo de. 15 Elemento integrante do gerenciamento do escopo do projeto, De acordo com o comando a que cada um dos itens de 1 a 70 se refira, marque, na folha de respostas, para cada item: o campo designado com o código C, caso julgue o item CERTO; ou o campo designado com

Leia mais

No que se refere a conceitos básicos do gerenciamento de projetos, segundo o PMBoK, julgue os itens a seguir.

No que se refere a conceitos básicos do gerenciamento de projetos, segundo o PMBoK, julgue os itens a seguir. De acordo com o comando a que cada um dos itens de 1 a 70 se refira, marque, na folha de respostas, para cada item: o campo designado com o código C, caso julgue o item CERTO; ou o campo designado com

Leia mais

Importância do GED. Implantação de um Sistema de GED

Importância do GED. Implantação de um Sistema de GED Implantação de um Sistema de GED Gerenciamento Eletrônico de Documentos Importância do GED O GED tem uma importante contribuição na tarefa da gestão eficiente da informação; É a chave para a melhoria da

Leia mais

F.1 Gerenciamento da integração do projeto

F.1 Gerenciamento da integração do projeto Transcrição do Anexo F do PMBOK 4ª Edição Resumo das Áreas de Conhecimento em Gerenciamento de Projetos F.1 Gerenciamento da integração do projeto O gerenciamento da integração do projeto inclui os processos

Leia mais

Qualidade de Software: Visão Geral

Qualidade de Software: Visão Geral Qualidade de Software: Visão Geral Engenharia de Software 1 Aula 05 Qualidade de Software Existem muitas definições de qualidade de software propostas na literatura, sob diferentes pontos de vista Qualidade

Leia mais

SUPERVISÃO COOPERATIVA Acompanhamento Indireto, acompanhamento dos planos, auditoria e comunicação

SUPERVISÃO COOPERATIVA Acompanhamento Indireto, acompanhamento dos planos, auditoria e comunicação SUPERVISÃO COOPERATIVA Acompanhamento Indireto, acompanhamento dos planos, auditoria e comunicação 1 Acompanhamento Indireto Tratamento das informações Análise intrínseca, evolutiva e comparativa Processos

Leia mais

Auditoria e Qualidade de Software ISO/IEC 9126 Engenharia de Software Qualidade de Produto

Auditoria e Qualidade de Software ISO/IEC 9126 Engenharia de Software Qualidade de Produto Auditoria e Qualidade de Software ISO/IEC 9126 Engenharia de Software Qualidade de Produto Prof. Elias Batista Ferreira Material cedido por: Prof. Edison A M Morais Objetivo Descrever os processos da norma

Leia mais

NORMAS ISO E SUA IMPORTÂNCIA NA PRODUÇÃO DE SOFTWARE

NORMAS ISO E SUA IMPORTÂNCIA NA PRODUÇÃO DE SOFTWARE NORMAS ISO E SUA IMPORTÂNCIA NA PRODUÇÃO DE SOFTWARE Marina Benedetti Preto¹ RESUMO Muito se fala sobre a qualidade de software, mas sem sempre se tem uma verdadeira noção deste conceito. A qualidade possui

Leia mais

21. Qualidade de Produto ou Qualidade de Processo de Software?

21. Qualidade de Produto ou Qualidade de Processo de Software? 21. Qualidade de Produto ou Qualidade de Processo de Software? Qualidade de software é uma preocupação real e esforços têm sido realizados na busca pela qualidade dos processos envolvidos em seu desenvolvimento

Leia mais

Qualidade na gestão de projeto de desenvolvimento de software

Qualidade na gestão de projeto de desenvolvimento de software Qualidade na gestão de projeto de desenvolvimento de software [...] O que é a Qualidade? A qualidade é uma característica intrínseca e multifacetada de um produto (BASILI, et al, 1991; TAUSWORTHE, 1995).

Leia mais

QUALIDADE DE SOFTWARE

QUALIDADE DE SOFTWARE QUALIDADE DE SOFTWARE Luiz Leão luizleao@gmail.com http://www.luizleao.com Questão 1 A ISO 9000-3 é um guia para a aplicação da ISO 9001 para o desenvolvimento, fornecimento e manutenção de software. As

Leia mais

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

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

Leia mais

C O B I T. Gerenciamento dos Riscos Mitigação. Aceitação. Transferência. Evitar/Eliminar.

C O B I T. Gerenciamento dos Riscos Mitigação. Aceitação. Transferência. Evitar/Eliminar. C O B I T Evolução Estratégica A) Provedor de Tecnologia Gerenciamento de Infra-estrutura de TI (ITIM) B) Provedor de Serviços Gerenciamento de Serviços de TI (ITSM) C) Parceiro Estratégico Governança

Leia mais

AVALIAÇÃO QUALITATIVA E QUANTITATIVA DO QUADRO DE SERVIDORES DA COTEC

AVALIAÇÃO QUALITATIVA E QUANTITATIVA DO QUADRO DE SERVIDORES DA COTEC MINISTÉRIO DO MEIO AMBIENTE INSTITUTO CHICO MENDES DE CONSERVAÇÃO DA BIODIVERSIDADE DIRETORIA DE PLANEJAMENTO, ADMINISTRAÇÃO E LOGÍSTICA Coordenação-Geral de Administração e Tecnologia da Informação Coordenação

Leia mais

Gerenciamento do escopo

Gerenciamento do escopo Gerenciamento do escopo Gerenciamento do escopo Escopo pode ser definido como a soma dos produtos de um projeto, bem como a descrição de seus requisitos. O momento de definir o escopo é a hora em que o

Leia mais

fagury.com.br. PMBoK 2004

fagury.com.br. PMBoK 2004 Este material é distribuído por Thiago Fagury através de uma licença Creative Commons 2.5. É permitido o uso e atribuição para fim nãocomercial. É vedada a criação de obras derivadas sem comunicação prévia

Leia mais

Ref: Edital da Concorrência nº. 01/2009. termos do edital, pelas razões a seguir: 1º PEDIDO DE ESCLARECIMENTO:

Ref: Edital da Concorrência nº. 01/2009. termos do edital, pelas razões a seguir: 1º PEDIDO DE ESCLARECIMENTO: Ref: Edital da Concorrência nº. 01/2009 Empresa interessada no certame solicitou PEDIDO DE ESCLLARECI IMENTTO,, aos termos do edital, pelas razões a seguir: 1º PEDIDO DE ESCLARECIMENTO: 1) Com relação

Leia mais

Universidade Paulista

Universidade Paulista Universidade Paulista Ciência da Computação Sistemas de Informação Gestão da Qualidade Principais pontos da NBR ISO/IEC 12207 - Tecnologia da Informação Processos de ciclo de vida de software Sergio Petersen

Leia mais

Módulo 4: Gerenciamento dos Riscos, das Aquisições, das Partes Interessadas e da Integração

Módulo 4: Gerenciamento dos Riscos, das Aquisições, das Partes Interessadas e da Integração Diretoria de Desenvolvimento Gerencial Coordenação Geral de Educação a Distância Gerência de Projetos - Teoria e Prática Conteúdo para impressão Módulo 4: Gerenciamento dos Riscos, das Aquisições, das

Leia mais

ANEXO I A Estratégia de TIC do Poder Judiciário

ANEXO I A Estratégia de TIC do Poder Judiciário RESOLUÇÃO Nº 99, DE 24 DE NOVEMBRO DE 2009 Dispõe sobre o Planejamento Estratégico de TIC no âmbito do Poder Judiciário e dá outras providências. ANEXO I A Estratégia de TIC do Poder Judiciário Planejamento

Leia mais

Qualidade de Software. Prof.: Ivon Rodrigues Canedo. PUC Goiás

Qualidade de Software. Prof.: Ivon Rodrigues Canedo. PUC Goiás Prof.: Ivon Rodrigues Canedo PUC Goiás Qualidade Subjetiva Não sei o que é mas reconheço quando a vejo Qualidade Baseada no Produto O produto possui algo que produtos similares não têm Qualidade Baseada

Leia mais

GERENCIAMENTO DE PROJETOS EM UM ESCRITÓRIO DE ARQUITETURA: VISÃO TRADICIONAL X NEGÓCIOS BASEADOS EM PROJETOS

GERENCIAMENTO DE PROJETOS EM UM ESCRITÓRIO DE ARQUITETURA: VISÃO TRADICIONAL X NEGÓCIOS BASEADOS EM PROJETOS GERENCIAMENTO DE PROJETOS EM UM ESCRITÓRIO DE ARQUITETURA: VISÃO TRADICIONAL X NEGÓCIOS BASEADOS EM PROJETOS Ana Carolina Freitas Teixeira¹ RESUMO O gerenciamento de projetos continua crescendo e cada

Leia mais

Gerenciamento de Projetos

Gerenciamento de Projetos Gerenciamento de Projetos PMI, PMP e PMBOK PMI (Project Management Institute) Estabelecido em 1969 e sediado na Filadélfia, Pensilvânia EUA, o PMI é a principal associação mundial, sem fins lucrativos,

Leia mais

Teoria e Prática. Totalmente de acordo com a 4 a Edição/2009. Rosaldo de Jesus Nocêra, PMP, PMI-SP, MCTS. do PMBOK do PMI. Acompanha o livro:

Teoria e Prática. Totalmente de acordo com a 4 a Edição/2009. Rosaldo de Jesus Nocêra, PMP, PMI-SP, MCTS. do PMBOK do PMI. Acompanha o livro: Gerenciamento de Projetos Teoria e Prática Totalmente de acordo com a 4 a Edição/2009 do PMBOK do PMI Acompanha o livro: l CD com mais de 70 formulários exemplos indicados pelo PMI e outros desenvolvidos

Leia mais

Visão Geral das Áreas de Conhecimento e dos Processos da Gerência de Projetos

Visão Geral das Áreas de Conhecimento e dos Processos da Gerência de Projetos Visão Geral das Áreas de Conhecimento e dos Processos da Gerência de Projetos GERÊNCIA DE INTEGRAÇÃO GERÊNCIA DO ESCOPO GERÊNCIA DO TEMPO GERÊNCIA DE CUSTO GERÊNCIA DA QUALIDADE Desenvolvimento do Plano

Leia mais

Universidade Federal Rural do Rio de Janeiro Práticas Necessárias para Contratação de Bens e Serviços de Tecnologia da Informação

Universidade Federal Rural do Rio de Janeiro Práticas Necessárias para Contratação de Bens e Serviços de Tecnologia da Informação Universidade Federal Rural do Rio de Janeiro Práticas Necessárias para Contratação de Bens e Serviços de Tecnologia da Informação Renata Alves Campos - Analista de T. I. (CoInfo) André de Oliveira Eskenazi

Leia mais

Implementação utilizando as melhores práticas em Gestão de Projetos

Implementação utilizando as melhores práticas em Gestão de Projetos Implementação utilizando as melhores práticas em Gestão de Projetos Objetivo dessa aula é mostrar a importância em utilizar uma metodologia de implantação de sistemas baseada nas melhores práticas de mercado

Leia mais

UM RELATO DE EXPERIÊNCIA SOBRE O USO DO SOFTWARE DE GESTÃO DE PROJETOS DOTPROJECT NA PRODUÇÃO DE MATERIAIS MULTIMÍDIA PARA EDUCAÇÃO A DISTÂNCIA EAD

UM RELATO DE EXPERIÊNCIA SOBRE O USO DO SOFTWARE DE GESTÃO DE PROJETOS DOTPROJECT NA PRODUÇÃO DE MATERIAIS MULTIMÍDIA PARA EDUCAÇÃO A DISTÂNCIA EAD 1 UM RELATO DE EXPERIÊNCIA SOBRE O USO DO SOFTWARE DE GESTÃO DE PROJETOS DOTPROJECT NA PRODUÇÃO DE MATERIAIS MULTIMÍDIA PARA EDUCAÇÃO A DISTÂNCIA EAD Serra, 05/2009 Saymon Castro de Souza Ifes saymon@ifes.edu.br

Leia mais

Qualidade de software

Qualidade de software Faculdade de Ciências Sociais e Aplicadas de Petrolina - FACAPE Curso: Ciência da Computação Disciplina:Projeto de Sistemas Qualidade de software cynaracarvalho@yahoo.com.br Qualidade de software Qualidade

Leia mais

Gerenciamento de Serviços de TI com base na ITIL

Gerenciamento de Serviços de TI com base na ITIL Gerenciamento de Serviços de TI com base na ITIL Information Technology Infrastructure Library ou Biblioteca de Infraestrutura da Tecnologia da Informação A TI de antes (ou simplesmente informática ),

Leia mais

Políticas de Qualidade em TI

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

Leia mais

METODOLOGIA DE GERENCIAMENTO DE PROJETO DE SOFTWARE ORIENTADO A OBJETO COM PMBOK

METODOLOGIA DE GERENCIAMENTO DE PROJETO DE SOFTWARE ORIENTADO A OBJETO COM PMBOK V EPCC Encontro Internacional de Produção Científica Cesumar 23 a 26 de outubro de 2007 METODOLOGIA DE GERENCIAMENTO DE PROJETO DE SOFTWARE ORIENTADO A OBJETO COM PMBOK Cleber Lecheta Franchini 1 Resumo:

Leia mais

Gerenciamento de Projetos

Gerenciamento de Projetos Gerenciamento de Projetos Grupo de Consultores em Governança de TI do SISP 20/02/2013 1 Agenda 1. PMI e MGP/SISP 2. Conceitos Básicos - Operações e Projetos - Gerenciamento de Projetos - Escritório de

Leia mais

Qualidade de Processo de Desenvolvimento de Software

Qualidade de Processo de Desenvolvimento de Software Qualidade de Processo de Desenvolvimento de Software DAS 5316 Integração de Sistemas Corporativos DAS 5316 Integração de Sistemas Corporativos Prof. Ricardo J. Rabelo Conteúdo Introdução & Problemática

Leia mais

4. PMBOK - Project Management Body Of Knowledge

4. PMBOK - Project Management Body Of Knowledge 58 4. PMBOK - Project Management Body Of Knowledge No Brasil, as metodologias mais difundidas são, além do QL, o método Zopp, o Marco Lógico do Banco Interamericano de Desenvolvimento (BID) e o Mapp da

Leia mais

IC-UNICAMP IC-UNICAMP

IC-UNICAMP IC-UNICAMP Capítulo 3: Qualidade de Produto e a ISO 9126 Capítulo 1: Introdução Capítulo 2: Conceitos Básicos Capítulo 3: Qualidade de Produto (ISO9126) Capítulo 4: ISO9001 e ISO9000-3 Capítulo 5: CMM Capítulo 6:

Leia mais

A Disciplina Gerência de Projetos

A Disciplina Gerência de Projetos A Disciplina Gerência de Projetos Atividades, Artefatos e Responsabilidades hermano@cin.ufpe.br Objetivos Apresentar atividades da disciplina Gerência de Projetos Discutir os artefatos e responsáveis envolvidos

Leia mais

Gerenciamento de Projetos. Prática essencial para gerar negócios sustentáveis

Gerenciamento de Projetos. Prática essencial para gerar negócios sustentáveis MBA em Gestão de Projetos Gerenciamento de Projetos Prática essencial para gerar negócios sustentáveis Prof: Ângelo Braga, PMP, MBA angelo.braga@fgv.br eu@angelobraga.com.br 2/154 Contatos Prof. Ângelo

Leia mais

METODOLOGIA HSM Centrada nos participantes com professores com experiência executiva, materiais especialmente desenvolvidos e infraestrutura tecnológica privilegiada. O conteúdo exclusivo dos especialistas

Leia mais

Planejamento Estratégico de TIC. da Justiça Militar do Estado. do Rio Grande do Sul

Planejamento Estratégico de TIC. da Justiça Militar do Estado. do Rio Grande do Sul Planejamento Estratégico de TIC da Justiça Militar do Estado do Rio Grande do Sul MAPA ESTRATÉGICO DE TIC DA JUSTIÇA MILITAR DO ESTADO (RS) MISSÃO: Gerar, manter e atualizar soluções tecnológicas eficazes,

Leia mais

PEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: PEDROHOLI@GMAIL.COM

PEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: PEDROHOLI@GMAIL.COM PEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: PEDROHOLI@GMAIL.COM M P S. B R : M E L H O R I A D E P R O C E S S O D O S O F T W A R E B R A S I L E I R O A

Leia mais

Qualidade de Produto de Software

Qualidade de Produto de Software Qualidade de Produto de Software Centro de Tecnologia da Informação Renato Archer-CTI Rodovia Dom Pedro I km 143,6 Campinas SP Brasil Divisão de Qualificação em Software - DQS Ana Cervigni Guerra ana.guerra@cti.gov.br

Leia mais

A ESCOLHA DE SISTEMA PARA AUTOMAÇÃO DE BIBLIOTECAS. A decisão de automatizar

A ESCOLHA DE SISTEMA PARA AUTOMAÇÃO DE BIBLIOTECAS. A decisão de automatizar A ESCOLHA DE SISTEMA PARA AUTOMAÇÃO DE BIBLIOTECAS A decisão de automatizar 1 A decisão de automatizar Deve identificar os seguintes aspectos: Cultura, missão, objetivos da instituição; Características

Leia mais

Atendimento aos requisitos de Projeto e Desenvolvimento da ISO9001:2008 em Empreendimentos. Nasario de S. F. Duarte Jr.

Atendimento aos requisitos de Projeto e Desenvolvimento da ISO9001:2008 em Empreendimentos. Nasario de S. F. Duarte Jr. Atendimento aos requisitos de Projeto e Desenvolvimento da ISO9001:2008 em Empreendimentos Nasario de S. F. Duarte Jr. Resumo Embora organizações projetizadas (empresas que trabalham sob projetos) existam

Leia mais

ISO - 9126. Aécio Costa

ISO - 9126. Aécio Costa ISO - 9126 Aécio Costa A evolução da Qualidade do Produto Qualidade = funcionalidade Confiabilidade Realização de funções críticas Produto de qualidade = sem bugs Controle de qualidade Teste do produto

Leia mais

CONCORRÊNCIA AA Nº 05/2009 BNDES ANEXO X PROJETO BÁSICO: DESCRIÇÃO DOS PROCESSOS DE TI

CONCORRÊNCIA AA Nº 05/2009 BNDES ANEXO X PROJETO BÁSICO: DESCRIÇÃO DOS PROCESSOS DE TI CONCORRÊNCIA AA Nº 05/2009 BNDES ANEXO X PROJETO BÁSICO: DESCRIÇÃO DOS PROCESSOS DE TI 1. PI06 TI 1.1. Processos a serem Atendidos pelos APLICATIVOS DESENVOLVIDOS Os seguintes processos do MACROPROCESSO

Leia mais

A visão do modelo MPS.BR para Gerência de Projeto - Nível G. por Adriana Silveira de Souza

A visão do modelo MPS.BR para Gerência de Projeto - Nível G. por Adriana Silveira de Souza A visão do modelo MPS.BR para Gerência de Projeto - Nível G por Adriana Silveira de Souza Agenda Visão Geral do MPS.BR Processos e Capacidade de Processo Níveis de Maturidade Atributos de Processo Processo

Leia mais

Sistema de Gestão da Qualidade

Sistema de Gestão da Qualidade Sistema de Gestão da Qualidade Coordenadora Responsável Mara Luck Mendes, Jaguariúna, SP, mara@cnpma.embrapa.br RESUMO Em abril de 2003 foi lançado oficialmente pela Chefia da Embrapa Meio Ambiente o Cronograma

Leia mais

TERMO DE REFERÊNCIA. Contratação de empresa para prestação de serviços de treinamento em Information Technology Infrastructure Library (ITIL)V3.

TERMO DE REFERÊNCIA. Contratação de empresa para prestação de serviços de treinamento em Information Technology Infrastructure Library (ITIL)V3. TERMO DE REFERÊNCIA Contratação de empresa para prestação de serviços de treinamento em 1. OBJETO Contratação de empresa para prestação de serviços de treinamento em conceitos da biblioteca ITIL V3 - Infrastructure

Leia mais

Termo de Referência. Prestação de Serviços de Treinamento na área de Gerenciamento de Projetos

Termo de Referência. Prestação de Serviços de Treinamento na área de Gerenciamento de Projetos Termo de Referência Prestação de Serviços de Treinamento na área de Gerenciamento de Projetos Maio/2012 Índice 1. OBJETO... 3 2. ESCOPO... 3 3. PRAZO... 7 4. LOCAL DE TREINAMENTO... 7 5. HORÁRIO DE TREINAMENTO...

Leia mais

GUIA DE CURSO. Tecnologia em Sistemas de Informação. Tecnologia em Desenvolvimento Web. Tecnologia em Análise e Desenvolvimento de Sistemas

GUIA DE CURSO. Tecnologia em Sistemas de Informação. Tecnologia em Desenvolvimento Web. Tecnologia em Análise e Desenvolvimento de Sistemas PIM PROGRAMA DE INTEGRAÇÃO COM O MERCADO GUIA DE CURSO Tecnologia em Sistemas de Informação Tecnologia em Desenvolvimento Web Tecnologia em Análise e Desenvolvimento de Sistemas Tecnologia em Sistemas

Leia mais

Declaração de Escopo

Declaração de Escopo 1/9 Elaborado por: Adriano Marra, Bruno Mota, Bruno Leite, Janaina Versão: 1.4 Lima, Joao Augusto, Paulo Takagi, Ricardo Reis. Aprovado por: Porfírio Carlos Roberto Junior 24/08/2010 Time da Equipe de

Leia mais

Gerenciamento de Projetos

Gerenciamento de Projetos Gerenciamento de Projetos (ref. capítulos 1 a 3 PMBOK) TC045 Gerenciamento de Projetos Sergio Scheer - scheer@ufpr.br O que é Gerenciamento de Projetos? Aplicação de conhecimentos, habilidades, ferramentas

Leia mais

CONCURSO PÚBLICO ANALISTA DE SISTEMA ÊNFASE GOVERNANÇA DE TI ANALISTA DE GESTÃO RESPOSTAS ESPERADAS PRELIMINARES

CONCURSO PÚBLICO ANALISTA DE SISTEMA ÊNFASE GOVERNANÇA DE TI ANALISTA DE GESTÃO RESPOSTAS ESPERADAS PRELIMINARES CELG DISTRIBUIÇÃO S.A EDITAL N. 1/2014 CONCURSO PÚBLICO ANALISTA DE GESTÃO ANALISTA DE SISTEMA ÊNFASE GOVERNANÇA DE TI RESPOSTAS ESPERADAS PRELIMINARES O Centro de Seleção da Universidade Federal de Goiás

Leia mais

PORTARIA Nº 7.965, DE 23 DE NOVEMBRO DE 2015.

PORTARIA Nº 7.965, DE 23 DE NOVEMBRO DE 2015. PORTARIA Nº 7.965, DE 23 DE NOVEMBRO DE 2015. Atualiza o macroprocesso da fase de Gestão de Contratos de Tecnologia da Informação e Comunicações, instituído no âmbito do Tribunal Regional do Trabalho da

Leia mais

Contrato de Serviço (SLA) para [Cliente] por [Provedor]

Contrato de Serviço (SLA) para [Cliente] por [Provedor] Contrato de Serviço (SLA) para [Cliente] por [Provedor] Data Gerador do documento: Gerente de Negociação: Versões Versão Data Revisão Autor Aprovação (Ao assinar abaixo, o cliente concorda com todos os

Leia mais

ESTUDO COMPARATIVO NBR ISO 13485:2004 RDC 59:2000 PORTARIA 686:1998 ITENS DE VERIFICAÇÃO PARA AUDITORIA

ESTUDO COMPARATIVO NBR ISO 13485:2004 RDC 59:2000 PORTARIA 686:1998 ITENS DE VERIFICAÇÃO PARA AUDITORIA ESTUDOCOMPARATIVO NBRISO13485:2004 RDC59:2000 PORTARIA686:1998 ITENSDEVERIFICAÇÃOPARAAUDITORIA 1. OBJETIVO 1.2. 1. Há algum requisito da Clausula 7 da NBR ISO 13485:2004 que foi excluída do escopo de aplicação

Leia mais

Modelos de Qualidade de Produto de Software

Modelos de Qualidade de Produto de Software CBCC Bacharelado em Ciência da Computação CBSI Bacharelado em Sistemas de Informação Modelos de Qualidade de Produto de Software Prof. Dr. Sandro Ronaldo Bezerra Oliveira srbo@ufpa.br www.ufpa.br/srbo

Leia mais

Qualidade de Software. Profa. Cátia dos Reis Machado catia@ifc-camboriu.edu.br

Qualidade de Software. Profa. Cátia dos Reis Machado catia@ifc-camboriu.edu.br Qualidade de Software Profa. Cátia dos Reis Machado catia@ifc-camboriu.edu.br Qualidade Garantia de Qualidade Qualidade do processo Qualidade do produto Testes Estáticos Testes Dinâmicos Qualidade do produto

Leia mais

Engenharia de Software

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

Leia mais

Demais Áreas de Conhecimento do PMBOK

Demais Áreas de Conhecimento do PMBOK Residência em Arquitetura de Software Demais Áreas de Conhecimento do PMBOK Prof. Dr. Sandro Ronaldo Bezerra Oliveira srbo@ufpa.br www.ufpa.br/srbo Gerência de Desenvolvimento 2008.2 Faculdade de Computação

Leia mais

AGNALDO IZIDORO DE SOUZA UNIPAR agnaldo@unipar.br JAIR OTT UNIPAR jairott@gmail.com PABLO A. MICHEL UNIPAR pamichel@unipar.br

AGNALDO IZIDORO DE SOUZA UNIPAR agnaldo@unipar.br JAIR OTT UNIPAR jairott@gmail.com PABLO A. MICHEL UNIPAR pamichel@unipar.br A importância da aplicação de técnicas de gerenciamento de riscos em projetos de desenvolvimento de software: estudo de caso do sistema de controle de veículos AGNALDO IZIDORO DE SOUZA UNIPAR agnaldo@unipar.br

Leia mais

Qualidade de Software

Qualidade de Software Qualidade de Software Introdução Qualidade é um dos principais objetivos da Engenharia de Software. Muitos métodos, técnicas e ferramentas são desenvolvidas para apoiar a produção com qualidade. Tem-se

Leia mais

A IMPORTÂNCIA DO TESTE DE SOFTWARE PARA A QUALIDADE DO PROJETO

A IMPORTÂNCIA DO TESTE DE SOFTWARE PARA A QUALIDADE DO PROJETO A IMPORTÂNCIA DO TESTE DE SOFTWARE PARA A QUALIDADE DO PROJETO Autora: LUCIANA DE BARROS ARAÚJO 1 Professor Orientador: LUIZ CLAUDIO DE F. PIMENTA 2 RESUMO O mercado atual está cada vez mais exigente com

Leia mais

CMMI. B) descrições das atividades consideradas importantes para o atendimento de suas respectivas metas específicas. Governo do ES (CESPE 2009)

CMMI. B) descrições das atividades consideradas importantes para o atendimento de suas respectivas metas específicas. Governo do ES (CESPE 2009) CMMI Governo do ES (CESPE 2009) Na versão 1.2 do CMMI, 111 os níveis de capacidade são definidos na abordagem de estágios. 112 os níveis de maturidade são definidos na abordagem contínua. 113 existem seis

Leia mais

Título do Case: Departamento Comercial com foco nas expectativas do cliente Categoria: Projeto Interno

Título do Case: Departamento Comercial com foco nas expectativas do cliente Categoria: Projeto Interno Título do Case: Departamento Comercial com foco nas expectativas do cliente Categoria: Projeto Interno Resumo O presente case mostra como ocorreu o processo de implantação do Departamento Comercial em

Leia mais

Gerenciamento de Projetos Project Management Institute. Prof. Miguel Torres miguel.torres@terra.com.br

Gerenciamento de Projetos Project Management Institute. Prof. Miguel Torres miguel.torres@terra.com.br Gerenciamento de Projetos Project Management Institute Prof. Miguel Torres miguel.torres@terra.com.br Objetivo do Curso Criar condições e proporcionar métodos para o desenvolvimento da capacidade gestora,

Leia mais

Módulo 3: Gerenciamento da Qualidade, dos Recursos Humanos e das Comunicações

Módulo 3: Gerenciamento da Qualidade, dos Recursos Humanos e das Comunicações ENAP Diretoria de Desenvolvimento Gerencial Coordenação Geral de Educação a Distância Gerência de Projetos - Teoria e Prática Conteúdo para impressão Módulo 3: Gerenciamento da Qualidade, dos Recursos

Leia mais

PROJETO NOVAS FRONTEIRAS

PROJETO NOVAS FRONTEIRAS PROJETO NOVAS FRONTEIRAS DECLARAÇÃO DE TRABALHO TREINAMENTO STATEMENT OF WORK Preparado por Nelson Azevedo Membro do Time Versão 1 Aprovado por Rodrigo Mendes Lemos Gerente do Projeto 28/11/2010 Propósito

Leia mais

CHECK - LIST - ISO 9001:2000

CHECK - LIST - ISO 9001:2000 REQUISITOS ISO 9001: 2000 SIM NÃO 1.2 APLICAÇÃO A organização identificou as exclusões de itens da norma no seu manual da qualidade? As exclusões são relacionadas somente aos requisitos da sessão 7 da

Leia mais

FACULDADE DE SAÚDE, CIÊNCIAS HUMANAS E TECNOLÓGICAS DO PIAUÍ - NOVAFAPI COORDENAÇÃO DE PESQUISA E PÓS-GRADUAÇÃO

FACULDADE DE SAÚDE, CIÊNCIAS HUMANAS E TECNOLÓGICAS DO PIAUÍ - NOVAFAPI COORDENAÇÃO DE PESQUISA E PÓS-GRADUAÇÃO R FACULDADE DE SAÚDE, CIÊNCIAS HUMANAS E TECNOLÓGICAS DO PIAUÍ - NOVAFAPI COORDENAÇÃO DE PESQUISA E PÓS-GRADUAÇÃO EDITAL DE PESQUISA CPPG/NOVAFAPI Nº 001/2008 Seleção de projetos de pesquisa e desenvolvimento

Leia mais

VISÃO SISTÊMICA EM GERENCIAMENTO DE PROJETOS PARA WEB

VISÃO SISTÊMICA EM GERENCIAMENTO DE PROJETOS PARA WEB VISÃO SISTÊMICA EM GERENCIAMENTO DE PROJETOS PARA WEB Rogério Fernandes da Costa Professor especialista Faculdade Sumaré rogerio.fernandes@sumare.edu.br Resumo: O presente estudo tem como objetivo abordar

Leia mais

APRESENTAÇÃO DE PORTFOLIO DE SERVIÇOS

APRESENTAÇÃO DE PORTFOLIO DE SERVIÇOS APRESENTAÇÃO DE PORTFOLIO DE SERVIÇOS Versão 1 2010 A SIX SIGMA BRASIL apresenta a seguir seu portfolio de capacitação e consultoria de serviços de gerenciamento de projetos, processos (lean e seis sigma)

Leia mais

ANÁLISE DOS REQUISITOS NORMATIVOS PARA A GESTÃO DE MEDIÇÃO EM ORGANIZAÇÕES

ANÁLISE DOS REQUISITOS NORMATIVOS PARA A GESTÃO DE MEDIÇÃO EM ORGANIZAÇÕES V CONGRESSO BRASILEIRO DE METROLOGIA Metrologia para a competitividade em áreas estratégicas 9 a 13 de novembro de 2009. Salvador, Bahia Brasil. ANÁLISE DOS REQUISITOS NORMATIVOS PARA A GESTÃO DE MEDIÇÃO

Leia mais

TERMO DE REFERÊNCIA (TR) nº 001/2009

TERMO DE REFERÊNCIA (TR) nº 001/2009 TERMO DE REFERÊNCIA (TR) nº 001/2009 1 IDENTIFICAÇÃO DA CONSULTORIA Consultor (a) para desenvolver, treinar e implantar o Sistema de Gestão de Projetos do IBAMA. 2 JUSTIFICATIVA 2.1 Contextualização: O

Leia mais

2. Gerenciamento de projetos

2. Gerenciamento de projetos 2. Gerenciamento de projetos Este capítulo contém conceitos e definições gerais sobre gerenciamento de projetos, assim como as principais características e funções relevantes reconhecidas como úteis em

Leia mais

Ciência da Computação ENGENHARIA DE SOFTWARE. Planejamento e Gerenciamento

Ciência da Computação ENGENHARIA DE SOFTWARE. Planejamento e Gerenciamento Ciência da Computação ENGENHARIA DE SOFTWARE Planejamento e Gerenciamento Prof. Claudinei Dias email: prof.claudinei.dias@gmail.com Roteiro Introdução; Pessoas, Produto, Processo e Projeto; Gerência de

Leia mais

A pesquisa de campo foi realizada com questões para os núcleos administrativo, pessoal e acadêmico e procura explorar duas situações distintas:

A pesquisa de campo foi realizada com questões para os núcleos administrativo, pessoal e acadêmico e procura explorar duas situações distintas: 4 Pesquisa de campo Neste capitulo será apresentado o resultado dos questionários da pesquisa de campo que serviu para o estudo de caso. A coleta de dados será dividida em: Núcleo administrativo Núcleo

Leia mais

Artigo 1º - Aprovar revisão da Política de Segurança da PRODEB, que com esta se publica.

Artigo 1º - Aprovar revisão da Política de Segurança da PRODEB, que com esta se publica. Classificação: RESOLUÇÃO Código: RP.2007.077 Data de Emissão: 01/08/2007 O DIRETOR PRESIDENTE da Companhia de Processamento de Dados do Estado da Bahia - PRODEB, no uso de suas atribuições e considerando

Leia mais

Padrões de Qualidade de Software e Métricas de Software

Padrões de Qualidade de Software e Métricas de Software Universidade Federal do Vale do São Francisco Padrões de Qualidade de Software e Métricas de Software Engenharia de Software I Aula 3 e 4 Ricardo Argenton Ramos Agenda da Aula Introdução (Qualidade de

Leia mais

Plano de Gerenciamento das Aquisições Exemplo 1

Plano de Gerenciamento das Aquisições Exemplo 1 Plano de Gerenciamento das Aquisições Exemplo 1 Este plano descreve como serão administrados os processos de aquisição de bens e serviços neste projeto. As perguntas a serem respondidas no plano são: o

Leia mais

TERMO DE REFERÊNCIA Prestação de Serviços de suporte técnico para a Ferramenta de Scanner de Vulnerabilidades de Aplicações Web Acunetix

TERMO DE REFERÊNCIA Prestação de Serviços de suporte técnico para a Ferramenta de Scanner de Vulnerabilidades de Aplicações Web Acunetix TERMO DE REFERÊNCIA Prestação de Serviços de suporte técnico para a Ferramenta de Scanner de Vulnerabilidades de Aplicações Web Acunetix, e, atualização de novas versões e das vulnerabilidades detectáveis.

Leia mais

Termo de Referência. Aquisição de Solução de Gerenciamento de Impressão para plataforma baixa.

Termo de Referência. Aquisição de Solução de Gerenciamento de Impressão para plataforma baixa. Termo de Referência Aquisição de Solução de Gerenciamento de Impressão para plataforma baixa. CGAD/COAR - Gerenciamento de Impressão Plataforma Baixa / RQ DSAO nº xxx/2009 1/8 Termo de Referência Aquisição

Leia mais

Pode Judiciário Justiça do Trabalho Tribunal Regional do Trabalho da 11ª Região ATRIBUIÇÕES DOS CARGOS DE DIREÇÃO E CHEFIAS DA SETIC

Pode Judiciário Justiça do Trabalho Tribunal Regional do Trabalho da 11ª Região ATRIBUIÇÕES DOS CARGOS DE DIREÇÃO E CHEFIAS DA SETIC Pode Judiciário Justiça do Trabalho Tribunal Regional do Trabalho da 11ª Região ATRIBUIÇÕES DOS CARGOS DE DIREÇÃO E CHEFIAS DA SETIC 1. Diretor da Secretaria de Tecnologia da Informação e Comunicação Coordenar

Leia mais

08/09/2011 GERÊNCIA DA INTEGRAÇÃO PMBOK GESTÃO DE PROJETOS

08/09/2011 GERÊNCIA DA INTEGRAÇÃO PMBOK GESTÃO DE PROJETOS GESTÃO DE PROJETOS Prof. Me. Luís Felipe Schilling "Escolha batalhas suficientemente grandes para importar, suficientemente pequenas para VENCER." Jonathan Kozol GERÊNCIA DA INTEGRAÇÃO PMBOK 1 GERÊNCIA

Leia mais

Engenharia de Software II: Criando a Declaração de Escopo. Prof. Msc Ricardo Britto DIE-UFPI rbritto@ufpi.edu.br

Engenharia de Software II: Criando a Declaração de Escopo. Prof. Msc Ricardo Britto DIE-UFPI rbritto@ufpi.edu.br Engenharia de Software II: Criando a Declaração de Escopo Prof. Msc Ricardo Britto DIE-UFPI rbritto@ufpi.edu.br Sumário Desenvolvendo o Plano de Gerenciamento do Projeto. Coletando Requisitos. Declarando

Leia mais

Gerenciamento de Projeto

Gerenciamento de Projeto UNIVERSIDADE ESTADUAL PAULISTA INSTITUTO DE BIOCIÊNCIAS, LETRAS E CIÊNCIAS EXATAS DEPARTAMENTO DE CIÊNCIAS DE COMPUTAÇÃO E ESTATÍSTICA Gerenciamento de Projeto Engenharia de Software 2o. Semestre/ 2005

Leia mais

Fatores Críticos de Sucesso em GP

Fatores Críticos de Sucesso em GP Fatores Críticos de Sucesso em GP Paulo Ferrucio, PMP pferrucio@hotmail.com A necessidade das organizações de maior eficiência e velocidade para atender as necessidades do mercado faz com que os projetos

Leia mais

Capítulo 1 - Introdução 14

Capítulo 1 - Introdução 14 1 Introdução Em seu livro Pressman [22] define processo de software como um arcabouço para as tarefas que são necessárias para construir software de alta qualidade. Assim, é-se levado a inferir que o sucesso

Leia mais

Engenharia de Software Qualidade de Software

Engenharia de Software Qualidade de Software Engenharia de Software Qualidade de Software O termo qualidade assumiu diferentes significados, em engenharia de software, tem o significado de está em conformidade com os requisitos explícitos e implícitos

Leia mais