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,

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

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

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

9 RECURSOS HUMANOS 10 COMUNICAÇÕES

9 RECURSOS HUMANOS 10 COMUNICAÇÕES 10 COMUNICAÇÕES O gerenciamento das comunicações do projeto é a área de conhecimento que emprega os processos necessários para garantir a geração, coleta, distribuição, armazenamento, recuperação e destinação

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

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

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

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

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

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

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

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

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

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

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

Qualidade de Software

Qualidade de Software Engenharia Nesta seção você encontra artigos voltados para testes, processo, modelos, documentação, entre outros Qualidade de Software Desvendando um requisito essencial no processo de desenvolvimento

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

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

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

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

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

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

CARACTERÍSTICAS DE UM PROJETO

CARACTERÍSTICAS DE UM PROJETO CARACTERÍSTICAS DE UM PROJETO Temporário: significa que cada projeto tem um início e um fim muito bem definidos. Um projeto é fundamentalmente diferente: porque ele termina quando seus objetivos propostos

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

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

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

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

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

Gerência de Projetos de Software CMM & PMBOK

Gerência de Projetos de Software CMM & PMBOK Gerência de Projetos de Software CMM & PMBOK http://www.sei.cmu.edu/ Prefácio do CMM Após várias décadas de promessas não cumpridas sobre ganhos de produtividade e qualidade na aplicação de novas metodologias

Leia mais

PMI - PMBoK PMI PROJECT MANAGEMENT INSTITUTE. PMBoK PROJECT MANAGEMENT BODY OF KNOWLEDGE

PMI - PMBoK PMI PROJECT MANAGEMENT INSTITUTE. PMBoK PROJECT MANAGEMENT BODY OF KNOWLEDGE PMI - PMBoK PMI PROJECT MANAGEMENT INSTITUTE PMBoK PROJECT MANAGEMENT BODY OF KNOWLEDGE 1 PMI- Project Management Institute Fundado nos Estudos Unidos em 1969; Instituto sem fins lucrativos, dedicado ao

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

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

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

Questionário de Governança de TI 2014

Questionário de Governança de TI 2014 Questionário de Governança de TI 2014 De acordo com o Referencial Básico de Governança do Tribunal de Contas da União, a governança no setor público compreende essencialmente os mecanismos de liderança,

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

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

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

SISTEMA DE GESTÃO DA QUALIDADE MQ 01 Rev. 07 MANUAL DA QUALIDADE

SISTEMA DE GESTÃO DA QUALIDADE MQ 01 Rev. 07 MANUAL DA QUALIDADE Rev. Data. Modificações 01 14/09/2007 Manual Inicial 02 12/06/2009 Revisão Geral do Sistema de Gestão da Qualidade 03 22/10/2009 Inclusão de documento de referência no item 8. Satisfação de cliente, Alteraçã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

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

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

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

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

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

Qualidade de Software. Prof. Natália Oliveira M.Sc queiroz.nati@gmail.com

Qualidade de Software. Prof. Natália Oliveira M.Sc queiroz.nati@gmail.com Qualidade de Software Prof. Natália Oliveira M.Sc queiroz.nati@gmail.com Ementa Conceitos sobre Qualidade Qualidade do Produto Qualidade do Processo Garantida da Qualidade X Controle da Qualidade Conceitos

Leia mais

Fundamentos de Teste de Software

Fundamentos de Teste de Software Núcleo de Excelência em Testes de Sistemas Fundamentos de Teste de Software Módulo 2- Teste Estático e Teste Dinâmico Aula 3 Teste Estático SUMÁRIO INTRODUÇÃO... 3 1. Definição... 3 2. Custo Versus Benefício...

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

CobiT: Visão Geral e domínio Monitorar e Avaliar. Daniel Baptista Dias Ernando Eduardo da Silva Leandro Kaoru Sakamoto Paolo Victor Leite e Posso

CobiT: Visão Geral e domínio Monitorar e Avaliar. Daniel Baptista Dias Ernando Eduardo da Silva Leandro Kaoru Sakamoto Paolo Victor Leite e Posso CobiT: Visão Geral e domínio Monitorar e Avaliar Daniel Baptista Dias Ernando Eduardo da Silva Leandro Kaoru Sakamoto Paolo Victor Leite e Posso CobiT O que é? Um framework contendo boas práticas para

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

DESAFIO ETAPA 1 Passo 1

DESAFIO ETAPA 1 Passo 1 DESAFIO Um dos maiores avanços percebidos pela área de qualidade de software foi comprovar que a qualidade de um produto final (software) é uma consequência do processo pelo qual esse software foi desenvolvido.

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

Módulo 2: Gerenciamento de Escopo, Tempo e Custos do Projeto

Módulo 2: Gerenciamento de Escopo, Tempo e Custos do Projeto 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 2: Gerenciamento de Escopo, Tempo e Custos do

Leia mais

Gestão de Projetos de Software

Gestão de Projetos de Software Gestão de Projetos de Software Atividade Essencial à Engenharia de Software U Antonio Mendes da Silva Filho antoniom.silvafilho@gmail.com Professor e consultor em área de tecnologia da informação e comunicação

Leia mais

Projetos na área de TI. Prof. Hélio Engholm Jr

Projetos na área de TI. Prof. Hélio Engholm Jr Projetos na área de TI Prof. Hélio Engholm Jr Projetos de Software Ciclo de Vida do Projeto Concepção Iniciação Encerramento Planejamento Execução e Controle Revisão Ciclo de Vida do Produto Processos

Leia mais

Gestão da qualidade do software

Gestão da qualidade do software Gestão da qualidade do software Empenhada em assegurar que o nível de qualidade requerido de um produto de software é atingido Envolve a definição de normas e procedimentos de qualidade apropriados, e

Leia mais

Metodologia de Desenvolvimento de Sistemas (MDS - ANEEL)

Metodologia de Desenvolvimento de Sistemas (MDS - ANEEL) Metodologia de Desenvolvimento de Sistemas (MDS - ANEEL) Versão 2.0 Escritório de Gerenciamento de Projetos - EGP Superintendência da Gestão Técnica da Informação SGI Agência Nacional de Energia Elétrica

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

Comparação entre a Instrução Normativa SLTI/MP n 4 e o Guia de Aquisição do MPS.BR

Comparação entre a Instrução Normativa SLTI/MP n 4 e o Guia de Aquisição do MPS.BR Comparação entre a Instrução Normativa SLTI/MP n 4 e o Guia de Aquisição do MPS.BR Rejane Maria da Costa Figueiredo UNIVERSIDADE DE BRASÍLIA CAMPUS FGA *Fonte: Material: Edméia Andrade e Claudio Cruz Agenda

Leia mais

Palavras-Chave: Aquisições; Planejamento de Aquisições; Controle de Aquisições; Projeto; Lead time; Processo; Meta.

Palavras-Chave: Aquisições; Planejamento de Aquisições; Controle de Aquisições; Projeto; Lead time; Processo; Meta. 1 A INFLUÊNCIA DO PLANEJAMENTO E CONTROLE DA AQUISIÇÃO NO PRAZO FINAL DO PROJETO Euza Neves Ribeiro Cunha RESUMO Um dos grandes desafios na gerência de projetos é planejar e administrar as restrições de

Leia mais

Normas e Padrões de Qualidade em Software - I

Normas e Padrões de Qualidade em Software - I Tema da Aula Normas e Padrões de Qualidade em - I Prof. Cristiano R R Portella portella@widesoft.com.br Certificação da Qualidade Certificações emitidas por entidades públicas conceituadas: 9 ABIC Selo

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

CONSELHO NACIONAL DE JUSTIÇA RESOLUÇÃO Nº 99, DE 24 DE NOVEMBRO DE 2009

CONSELHO NACIONAL DE JUSTIÇA RESOLUÇÃO Nº 99, DE 24 DE NOVEMBRO DE 2009 CONSELHO NACIONAL DE JUSTIÇA RESOLUÇÃO Nº 99, DE 24 DE NOVEMBRO DE 2009 Institui o Planejamento Estratégico de Tecnologia da Informação e Comunicação no âmbito do Poder Judiciário. O PRESIDENTE DO CONSELHO

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

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

Conceitos de Qualidade em Software

Conceitos de Qualidade em Software Tema da Aula Conceitos de Qualidade em Prof. Cristiano R R Portella portella@widesoft.com.br Qualidade Qualidade é um conceito subjetivo, que varia para cada local, época, tipo de produto e pessoa que

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

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

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

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

QUALIDADE DE SOFTWARE

QUALIDADE DE SOFTWARE QUALIDADE DE SOFTWARE MODULO 3 SISTEMA DE GARANTIA DA QUALIDADE CONTEÚDO 3.1 A ABORDAGEM NBR ISO 9000 3.2 MODELOS DE QUALIDADE DE PRODUTO DE SOFTWARE 3.2.1 NBR ISO/IEC 9126 (SOFTWARE) 3.2.2 NBR ISO/IEC

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

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

Evolução dos sistemas ERP nas empresas

Evolução dos sistemas ERP nas empresas Evolução dos sistemas ERP nas empresas Aloísio André dos Santos (ITA) aloisio@mec.ita.br João Murta Alves (ITA) murta@mec.ita.br Resumo Os sistemas ERP são considerados uma evolução dos sistemas de administração

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

Cartilha. Gestão de Projetos. Superintendência de Planejamento e Gestão SUPLAN Ministério Público do Estado de Goiás

Cartilha. Gestão de Projetos. Superintendência de Planejamento e Gestão SUPLAN Ministério Público do Estado de Goiás Cartilha Gestão de Projetos SUPLAN Ministério Público do Estado de Goiás Esta cartilha tem como objetivo transmitir os conceitos básicos relacionados ao Gerenciamento de Projetos e compartilhar da metodologia

Leia mais

GERÊNCIA DE INTEGRAÇÃO DO PROJETO

GERÊNCIA DE INTEGRAÇÃO DO PROJETO GERÊNCIA DE INTEGRAÇÃO DO PROJETO Estevanir Sausen¹, Patricia Mozzaquatro² ¹Acadêmico do Curso de Ciência da Computação ²Professor(a) do Curso de Ciência da Computação Universidade de Cruz Alta (UNICRUZ)

Leia mais

ADMINISTRAÇÃO GERAL GESTÃO DE PROJETOS

ADMINISTRAÇÃO GERAL GESTÃO DE PROJETOS ADMINISTRAÇÃO GERAL GESTÃO DE PROJETOS Atualizado em 31/12/2015 GESTÃO DE PROJETOS PROJETO Para o PMBOK, projeto é um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo.

Leia mais

METODOLOGIA DE DESENVOLVIMENTO DE SISTEMAS

METODOLOGIA DE DESENVOLVIMENTO DE SISTEMAS PODER JUDICIÁRIO JUSTIÇA DO TRABALHO TRIBUNAL REGIONAL DO TRABALHO DA 11ª REGIÃO SECRETARIA DE TECNOLOGIA DA INFORMAÇÃO - SETI Versão 1.0 MANAUS-AM (2010) MDS Metodologia de Desenvolvimento de Sistemas

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

Faça mais, com menos: Como crescer em um mercado de trabalho desafiador

Faça mais, com menos: Como crescer em um mercado de trabalho desafiador Faça mais, com menos: Como crescer em um mercado de trabalho desafiador Investir em pessoal com um programa de gestão de desempenho permite que uma operação de abastecimento não só sobreviva, mas cresça

Leia mais

Projetos (PMO) : Oportunidades de Sinergia

Projetos (PMO) : Oportunidades de Sinergia Escritórios de Processos (BPM Office) e de Projetos (PMO) : Oportunidades de Sinergia Introdução...2 Uniformizando o entendimento dos conceitos... 4 Entendendo as principais similaridades... 5 Entendendo

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

Palavras-Chaves: estoque, modelagem, requisitos, UML, vendas.

Palavras-Chaves: estoque, modelagem, requisitos, UML, vendas. UTILIZAÇÃO DA UML NO DESENVOLVIMENTO DE SISTEMA DE CONTROLE DE VENDAS E ESTOQUE GILBERTO FRANCISCO PACHECO DOS SANTOS Discente da AEMS Faculdades Integradas de Três Lagoas JACKSON LUIZ ARROSTI Discente

Leia mais

Qualidade de Software Aula 6 / 2010. luis@garcia.pro.br www.garcia.pro.br

Qualidade de Software Aula 6 / 2010. luis@garcia.pro.br www.garcia.pro.br Qualidade de Software Aula 6 / 2010 Prof. Dr. Luís Fernando Garcia luis@garcia.pro.br www.garcia.pro.br Introdução As três dimensões críticas Introdução Começando MAL CMMI Impeditivos CMMI Desculpas CMMI

Leia mais

Lista de Exercícios - COBIT 5

Lista de Exercícios - COBIT 5 Lista de Exercícios - COBIT 5 1. O COBIT 5 possui: a) 3 volumes, 7 habilitadores, 5 princípios b) 3 volumes, 5 habilitadores, 7 princípios c) 5 volumes, 7 habilitadores, 5 princípios d) 5 volumes, 5 habilitadores,

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

Experiência: Sistema de Custos e Informações Gerenciais do Banco Central do Brasil

Experiência: Sistema de Custos e Informações Gerenciais do Banco Central do Brasil Experiência: Sistema de Custos e Informações Gerenciais do Banco Central do Brasil Ministério da Fazenda Banco Central do Brasil Responsável: José Clovis Batista Dattoli, Chefe do Departamento de Planejamento

Leia mais

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

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

Leia mais

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

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

9001:2000 - EPS - UFSC)

9001:2000 - EPS - UFSC) Implantação de um sistema de gestão da qualidade conforme a norma ISO 9001:2000 numa pequena empresa de base tecnológica, estudo de caso: Solar Instrumentação, Monitoração e Controle Ltda. Gustavo Slongo

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

Capítulo 1 Introdução ao gerenciamento de projetos

Capítulo 1 Introdução ao gerenciamento de projetos Capítulo 1 Introdução ao gerenciamento de projetos 1.1 Introdução 31 1.2 O que é um projeto? 31 1.3 Ciclo de vida do projeto 33 1.4 O que é gerenciamento de projetos? 36 1.5 Relacionamento entre grupos

Leia mais

Notas de Aula 02: Processos de Desenvolvimento de Software

Notas de Aula 02: Processos de Desenvolvimento de Software Notas de Aula 02: Processos de Desenvolvimento de Software Objetivos da aula: Introduzir os conceitos de um processo de desenvolvimento de software Definir os processos básicos Apresentar as vantagens

Leia mais

Qualidade de Software. MC626 Adaptado de notas de aula da Prof. Eliane Martins (http://www/ic.unicamp.br/~eliane/cursos)

Qualidade de Software. MC626 Adaptado de notas de aula da Prof. Eliane Martins (http://www/ic.unicamp.br/~eliane/cursos) Qualidade de Software MC626 Adaptado de notas de aula da Prof. Eliane Martins (http://www/ic.unicamp.br/~eliane/cursos) Qualidade de Software MC626 Adaptado de notas de aula da Prof. Eliane Martins (http://www/ic.unicamp.br/~eliane/cursos)

Leia mais

PMBOK - Project Management Body of Knowledge - PORTUGUÊS

PMBOK - Project Management Body of Knowledge - PORTUGUÊS PMBOK - Project Management Body of Knowledge - PORTUGUÊS Sr(as) Gerentes de Projeto, O PMBOK, compilado pela expertise do PMI Project Management Institute, é a linha mestra que nos conduz ao conhecimento

Leia mais

Estudo de Viabilidade

Estudo de Viabilidade Universidade Federal de Pernambuco Centro de Informática Estudo de Viabilidade SorveTech (Sistema de Gerenciamento) Professora: Carla Silva Disciplina: Especificação de Requisitos e Validação de Sistemas

Leia mais

Nº Questionamento na íntegra Resposta

Nº Questionamento na íntegra Resposta Ref.: LPI 001/2014 - Fábrica de Software Respostas aos questionamentos Nº Questionamento na íntegra Resposta 1 No Edital em questão, no item 6.1 d Não serão aceitas joint venture, Seção VIII - Condições

Leia mais

Aula 7 Elaboração do Plano de Gerenciamento da Qualidade

Aula 7 Elaboração do Plano de Gerenciamento da Qualidade Aula 7 Elaboração do Plano de Gerenciamento da Qualidade Objetivos da Aula: Os objetivos desta aula visam definir termos e conceitos da qualidade. Para tal, pretende-se discutir a relação que se estabelece

Leia mais