Pim Vii e Viii 7 Ronald

1

UNIVERSIDADE PAULISTA CURSO SUPERIOR DE TECNOLOGIA

GESTÃO EM TECNOLOGIA DA INFORMAÇÃO

RONALD RENATO SILVA DA SILVA

PIM V

PROJETO INTEGRADO MULTIDISCIPLINAR

DOCUMENTO DE ESTUDO CONTENDO ANÁLISE DE IMPACTO, PLANEJAMENTO,

DESENVOLVIMENTO E COMO IMPLEMENTAR MELHORAS NOS PROCESSOS DE TI DA

SOFTWARE DEVELOPER.

BELÉM – PARÁ

2014

2


PIM V




SOFTWARE DEVELOPER

Trabalho do Projeto Integrado Multidisciplinar – PIM VII e

VIII, apresentado como exigência para conclusão do 4º

Semestre do Curso Superior de Tecnologia Gestão em

Tecnologia da Informação, da Universidade Paulista –

UNIP, campus Entroncamento.

Monitora: NATÁLIA MORAES

BELÉM - PARÁ

2014

3

Resumo Este trabalho tem como objetivo um estudo contendo análise de impacto, planejamento, desenvolvimento e como implementar melhoras nos processos de TI da empresa Software Developer. A governança de Ti é de responsabilidade da diretoria e da gerência executiva. Uma importante e comum preocupação da governança de TI e os objetivos atuais e futuros da organização. A ISO 9000 é um conjunto de padrões auditáveis de alto nível voltados ao cliente para sistema de gerenciamento de qualidade. O Balanced Scorecard foi desenvolvido por Robert Kaplan e David Norton no início da década de 90, constituído-se um novo modelo de gestão estratégica, baseado em indicadores financeiro e não-financeiros. vinculado a estratégia organizacional

4

Abstract This paper AIMS to study with analysis of impact planning, development and how to implement improvements in the processes of corporate IT Software Developer. IT governance is the responsibility of the board and executive management. An important and common concern of IT governance and the current and future goals of the organization. ISO 9000 is a set of auditable standards high level customer focused for quality management system. The Balanced Scorecard was developed by Robert Kaplan and David Norton in the early 90s, made up a new strategic management

model, based on financial and non-financial indicators. linked to organizational strategy.

5

Sumário 1- Introdução ............................................................................................................................... 6

2- Governança de TI e Governança Corporativa .................................................................. 7

2.1 – Governança de TI e Gerenciamento de TI ................................................................... 8

2.2 – Domínios da Governança TI ................................................................................... 8,9,10

2.3 – Metodologias para Suporte a Governança TI ............................................................ 10

2.4 - CobiT - Control Objectives for Information and Related Technology ...................... 10

2.5 - ITIL - Information Technology Infrastructure Library .................................................. 11

2.6 - Seis Sigma ....................................................................................................................... 11

2.7 - PMI (Project Management Institute) ............................................................................. 11

2.8 - CMM - Capability Maturity Model for software ............................................................ 12

2.9 - ISO 9000 ........................................................................................................................... 12

2.10 – Balanced Scorecard ..................................................................................................... 12

3 – Pesquisas sobre Governança TI ..................................................................................... 13

O 3.1- Análise do Modelo de Governança de TI ............................................................... 13

3.2 – Governança de TI na SoftwareDeveloper .................................................................. 14

3.3 – Estrutura Organizacional, Visão e Missão da SoftwareDeveloper ......................... 14

3.4 – Nível de Governança de TI da SoftwareDeveloper................................................... 15

3.5 – Obtenção das medidas de nível de governança ....................................................... 15

3.6 – Aplicação dos Questionários ........................................................................................ 16

3.7 - Resultados ........................................................................................................................ 16

3.8 – Métricas de Performance ......................................................................................... 17,18

3.9 – Hipóteses Testadas ....................................................................................................... 19

4- Conclusão ............................................................................................................................. 20

5-Referecias Bilbiográficas ..................................................................................................... 22

6-Glossário ................................................................................................................................ 23

6

1- Introdução

O cliente da Consulting é uma empresa de desenvolvimento de software para Bancos e os principais produtos são: Sistema de Consórcio; Sistema de Financiamento; Sistema para Empréstimos; A Software Developer prove sistemas para instituições financeiras, entretanto os sistemas desenvolvidos apresentam falhas para prover as seguintes necessidades: Controle de criação, edição e versão dos documentos; Cadastramento dos riscos associados aos processos de negócios e armazenar os desenhos de processo; Gerenciamento dos documentos e controle dos períodos de retenção e distribuição;

7

2- Governança de TI e Governança Corporativa

A Definição de Governança de TI proposta pelo IGTI expressa que “Governança de TI é de responsabilidade da Diretoria e Gerência Executiva e que a Governança de TI faz parte da Governança da Empresa”. A Figura 1 abaixo mostra a ligação entre Governança Corporativa e Governança de TI, proposta pelo CISR do MIT SloanSchool, onde se percebe que TI é um dos ativos controlados pela Governança Corporativa. Na parte superior do modelo, são evidenciados os relacionamentos entre a diretoria da empresa com acionistas, stakeholders, práticas de monitoramento e de disclosure para compor a GC. Os executivos da empresa, como agentes da diretoria articulam estratégias e ações para gerar o comportamento desejável que possibilite que as diretrizes da diretoria sejam concretizadas. Para implementar esta estratégia, é necessária a governança adequada dos ativos da empresa, dentre eles a Tecnologia da Informação (Weill, Ross,

2004).

Figura 1 – Relacionamento entre Governança Corporativa e Governança de TI

De acordo com Shleiferand Vishny, as questões típicas de Governança Corporativa são: Como os financiadores se asseguram de que os gestores vão dar retorno de seus investimentos? Como os financiadores se asseguram de que os gestores não vão expropriar o capital que investiram ou investir em projetos ruins? Como os financiadores controlam os gestores? Tais perguntas podem ser desdobradas para outras áreas da organização, tornando-se mais específicas e mantendo o alinhamento com a GC.

8

Na Tabela 1, citamos a adaptação destas perguntas para a área de TI.

2.1 – Governança de TI e Gerenciamento de TI

Uma importante e comum preocupação da GTI é a ligação entre a TI e os objetivos atuais e

futuros da organização. Esta preocupação nos remete a refletir sobre as diferenças entre Governança

de TI e Gerenciamento de TI, que nem sempre são claras (Grembergeret al. 2004). Esta distinção

pode ser melhor visualizada na Figura 2.

Figura 2: As diferenças entre Governança de TI e Gerenciamento de TI

Gerenciamento de TI tem como foco o fornecimento efetivo de serviços e produtos de TI internos e o gerenciamento das operações de TI no presente. A GTI por sua vez é mais abrangente e concentra-se no desempenho e transformação de TI, para atender demandas atuais e futuras do negócio da corporação (foco interno) e negócio do cliente (foco externo). “Isto não diminui a importância e complexidade do Gerenciamento de TI, ..., mas enquanto o Gerenciamento de TI e fornecimento de serviços de TI e produtos podem ser realizados por um fornecedor externo, a Governança de TI é específica da organização, e direção e controle sobre TI não podem ser delegados para o mercado” (PETERSON (2003) apud GREMBERGER et. Al (2004)).

2.2 – Domínios da Governança TI

A GTI está relacionada a dois focos: o Valor dos Serviços de TI para o Negócio e Mitigação dos Riscos de TI. O primeiro item é suportado pelo alinhamento estratégico entre TI e o Negócio. O segundo é suportado pela forma como as responsabilidades na empresa são divididas.

9

Ambos os focos precisam ser suportadas por recursos e medidas adequados para que os resultados desejados sejam alcançados.

Para suportar os focos acima a GTI lida com cinco domínios, todos alinhados com as diretrizes dos stakeholders, dos quais dois são resultados: Valor de TI e Gerenciamento de Risco e três são direcionadores: Alinhamento Estratégico, Gerenciamento de Recursos e Medidas de Performance (Board Briefing on IT Governance, 2 Edição).

A Figura 3 abaixo mostra graficamente a relação entre os domínios da GTI.

A seguir, apresenta-se um resumo sobre o objetivo de cada um dos domínios, conforme o

“Board Briefing on IT Governance”:

* Alinhamento Estratégico

O domínio Alinhamento Estratégico tem como objetivo manter o alinhamento entre as soluções de TI

e o negócio da empresa.

* Valor de TI

O domínio Valor de TI tem como objetivo otimizar os custos dos investimentos de TI e o retorno dos

mesmos.

* Gerenciamento de Risco

10

O domínio Gerenciamento de Risco tem como objetivo assegurar a proteção dos ativos de TI,

recuperação de informações em caso de desastres e manter a continuidade da operação dos

serviços de TI.

* Gerenciamento de Recursos

O domínio Gerenciamento de Recursos tem como objetivo otimizar o

conhecimento e infraestrutura de TI.

* Medidas de Performance

O domínio Medidas de Performance tem como objetivo acompanhar a entrega

dos projetos de TI e monitorar os serviços de TI.

2.3 – Metodologias para Suporte a Governança de TI

É comum as organizações que estão desenvolvendo seus processos de Governança de TI se depararem com uma diversidade de modelos de qualidade e governança à sua disposição. Surge então a primeira dúvida: qual modelo seguir? Na edição especial da Revista Computer World de maio de 2004, Terzian (2004) cita que, embora haja alguma sobreposição entre esses modelos, na maior parte dos casos eles não entram em conflito e podem até mesmo serem complementares. Assim, as empresas podem utilizar mais de um modelo, ou adaptar os modelos existentes para sua necessidade. Nas próximas sessões serão apresentados alguns dos modelos e metodologias utilizados como suporte a GTI, conforme edição especial da Revista Computer World.

2.4 - COBIT - Control Objectives for Information and Related Technology

O COBIT – Control Objectives for Information and Related Technology - foi desenvolvido na década de 90 pela ISACA - Information System Auditand Control Association - e pode ser traduzido como Objetivos de Controle para a Informação e Tecnologia. O COBIT é um modelo de governança em TI, criado para alinhar os recursos e processos de TI com os objetivos do negócio, padrões de qualidade, controle monetário e necessidades de segurança (OLTISIK, 2003). Ele é composto por quatro domínios: Planejamento e Organização; Aquisição e Implementação; Entrega e Suporte; e Monitoramento. Cada um dos quatro domínios possui uma série de processos. O COBIT possui em suas ferramentas modelos de maturidade dos processos, variáveis de 0 a

5, conforme tabela 2. São eles:

11

Tabela 2: Modelos de processos de maturidade do COBIT

2.5 - ITIL - Information Technology Infrastructure Library

O ITIL, Information Technology Infrastruture Library, foi criado no final dos anos 80 pela Central ComputingandTelecommunicationsAgency para o governo britânico, reunindo um conjunto de recomendações divididas em dois blocos: suporte de serviços (servicesupport), que inclui cinco disciplinas e uma função; e entrega de serviços (servicedelivery), com mais cinco disciplinas (CACIATO, 2004). O foco deste modelo é descrever os processos necessários para gerenciar a infra-estrutura de TI eficientemente e eficazmente, de modo a garantir os níveis de serviço acordados com os clientes internos e externos. O ITIL trata de disciplinas táticas, ou de planejamento, e

operacionais.

2.6 - Seis Sigma

A Qualidade Seis Sigma foi desenvolvida pela Motorola nos anos 80 e é uma forma disciplinada para acelerar o aprimoramento de processos, produtos e serviços, tendo como base o uso de métodos estatísticos. Também é uma medida de Qualidade Total para conhecer a eficiência da empresa em eliminar a variação e os defeitos dos processos. O alvo do Seis Sigma é obter o desempenho de 3,4 defeitos por milhão de oportunidades ou 99,9997% de conformidade (livre de falhas) (CAMPOS, 2000). O Seis Sigma utiliza o ciclo DMAIC, formado pelas seguintes etapas:

Definir, Medir, Analisar, Implementar, Controlar.

2.7 - PMI (Project Management Institute)

O PMI (Project Management Institute) é uma organização sem fins lucrativos, composta por profissionais da área de gerenciamento de projetos. Esta organização visa promover e ampliar o conhecimento existente sobre gerenciamento de projetos assim como melhorar o desempenho dos profissionais e organizações da área. As definições e processos do PMI estão publicados no PMBOK (Guidetothe Project Management BodyofKnowledge). Esse manual define e descreve as habilidades, ferramentas e técnicas para o gerenciamento de um projeto. Este compreende cinco processos – Início, Planejamento, Execução, Controle e Fechamento, bem com nove áreas de conhecimento:

12

Integração, Escopo, Tempo, Custo, Qualidade, Recursos Humanos, Comunicação, Análise de Risco e Aquisição.

2.8 - CMM - Capability Maturity Model for software

O modelo CMM – CapabilityMaturityModel foi produzido pelo SEI (Software EngineeringInstitute) da Universidade Carnegie Mellon (CMU), em Pittsburgh, EUA, por um grupo de profissionais de software, sendo a 1ª versão lançada em 1991. O processo do CMM é dividido em cinco níveis seqüenciais bem definidos: Inicial, Repetível, Definido, Gerenciável e Otimizado. Os níveis provêm de uma escala crescente para mensurar a maturidade das organizações de software e ajudam as organizações a definir prioridades nos esforços de melhoria dos processos.

2.9 - ISO 9000

A International Standards Organization (ISO) 9000 é um conjunto de padrões auditáveis de alto nível voltados ao cliente (ISO 9000, 9001 e 9004) para sistemas de gerenciamento de qualidade. Destinado a garantir controle, repetibilidade e boa documentação de processos (não de produtos). Como pontos fortes da ISO, tem-se o fato de ser uma norma bem estabelecida e amadurecida. A ISO 9000 tem prestígio global e pode ser aplicada em toda a corporação. Cobre desenvolvimento de software, operações e serviços de TI. Porém, requer adaptação considerável quando utilizada em organizações de TI. Enfoca a repetibilidade e a consistência de processos, e não diretamente a qualidade dos processos. A ISO 9000 não é indicada para descobrir a origem de problemas (Terzian, 2004).

2.10 – Balanced Scorecard

O Balanced Scorecard foi desenvolvido por Robert Kaplan e David Norton no início da década de 90, constituindo-se num novo modelo de gestão estratégica, baseado em indicadores financeiros e não-financeiros vinculados à estratégia organizacional e divididos em quatro perspectivas de avaliação: perspectivas Financeira, dos Clientes, dos Processos Internos e do Aprendizado e Crescimento (KAPLAN, NORTON, 1997).

O conceito do BSC tem sido aplicado nos processos de Tecnologia da Informação. Considerando que a área de TI é provedora de serviços internos, Haeset al. (2004) sugere que as perspectivas propostas originalmente pela metodologia do BSC devem ser mudadas para Contribuição com a Corporação, Orientação para Usuários, Excelência Operacional e Orientação para o Futuro. Haeset al. (2004) cita também que a ligação entre o BSC Corporativo e o BSC da área de TI, conforme Figura 4, é considerado um mecanismo de suporte para a Governança de TI.

13

Figura 4: Balanced Scorecard em TI

3 – Pesquisas sobre Governança TI

A GTI tornou-se recentemente foco de estudo e pesquisa em diversas instituições. Em 2003, na lista elaborada pelo Gartner com os 10 principais tópicos a serem priorizados pelos ChiefInformation Offices (CIOs), pela primeira vez constava: aprimorar a Governança de TI. Em entrevista concedida a Microsoft Business (WEILL[1], 2004) cita que de acordo com pesquisas realizadas pelo Center for Information Systems Research (CISR), criado há 30 anos na SloanSchoolof Management do Massachusetts Instituteof Technology (MIT), empresas com políticas de governança em TI mais efetivas têm lucros mais altos do que as outras – mais de 20% superior.

O ITGI (IT Governance Institute) encomendou em 2005 para a PricewaterhouseCoopers uma pesquisa a respeito de Governança de TI que gerou o relatório: IT Governance Global Status Report-2006. Esta foi a segunda pesquisa do gênero realizada pelo ITGI, a primeira foi em 2003. A pesquisa foi realizada em 22 países e todos os continentes foram representados. A pesquisa foi conduzida através de entrevistas, e abrangeu 695 CIOs e CEOs (ChiefExecutive Office) de organizações de setores diversificados. O IT Governance Global Status Report-2006 revelou que a maioria dos usuários de TI estão conscientes dos problemas relacionados ao uso de TI e da necessidade de se desenvolver melhores práticas para lidar com esta questão. O relatório revelou também que uma parte representativa da comunidade dos usuários de TI reconhece a Governança de TI como uma solução para esses problemas ou como uma prática que deveriam adotar. Da parte do grupo que não reconheceu a Governança de TI como solução para os problemas envolvidos no uso e administração de TI, cerca de 80% estão adotando ações que podem ser classificadas como Governança de TI. Quase todas as organizações que reconhecem o conceito de Governança de TI sabem pelo menos o exemplo de um “modelo” ou “solução” de GTI. Em 2005 o CISR do MIT realizou uma pesquisa em 250 empresas do mundo com foco principalmente em analisar como as empresas tomam decisões relacionadas a TI. Tal pesquisa deu origem posteriormente ao livro: IT Governance: How Top Performers Manage IT DecisionRights for Superior Results.

3.1- Análise do Modelo de Governança de TI Neste trabalho efetuamos um estudo de caso descritivo e exploratório a respeito de Governança de TI. Nossa idéia consiste em verificar estatisticamente a existência de correlação entre o nível de Governança e a performance de métricas operacionais de TI. Para isto, utilizamos dados obtidos a partir do modelo de Governaça de TI utilizado na empresa permitindo mensurar a percepção de usuários, fornecedores e analistas de TI em relação ao nível de Governança de TI. Utilizamos duas métricas operacionais : Índice de Disponibilidade de Sistemas e Índice de

14

Consecução de Sistemas, ambas são provenientes do Sistema de BSC de TI da empresa e são considerados indicadores estratégicos do BSC de TI.

3.2 – Governança de TI na Software Developer

Para consolidar o processo de governança, o departamento de informática realizou algumas iniciativas tais como i) implementação de um Sistema de Gestão de Qualidade (SGQ), ii) criação e avaliação de indicadores de BalancedScoreCard para TI. O processo de Governança de TI preconiza o alinhamento com Plano Estratégico para manter-se alinhado ao negócio. Tal processo utiliza práticas provenientes de metodologias desenvolvidas no Departamento de Informática, e aplica algumas práticas inspiradas em metodologias de mercado tais como o PMI (Project Management Institute) e CobiT (ControlObjectives for InformationandRelated Technology).

Embora o processo de consolidação formal da Governança de TI seja recente, o processo de SGQ do departamento já foi certificado em 2005 pela ISO 9001:2000. Nas sessões que seguem abaixo, descrevemos algumas das características do modelo de Governança.

3.3 – Estrutura Organizacional, Visão e Missão da Software Developer

O Departamento de Informática (FDI) é atualmente subdividido em três divisões, ilustrado na Figura 5: Divisão de Manutenção e Desenvolvimento de Sistemas de Administração (FIA), Divisão de Manutenção e Desenvolvimento de Sistemas de Produção (FIP), Divisão de Infra-Estrutura (FIT). As divisões acima citadas têm como objetivo prover soluções e informações gerenciais para a Diretoria e Departamentos , através de consultoria e ferramentas de TI, conforme ilustrado na Figura 5.

Figura 5 – Visão e Missão Departamento de Informática da Software Developer

As divisões acima citadas têm como objetivo prover soluções e informações gerenciais para a

Diretoria e Departamentos da Arcelor Brasil – CST, através de consultoria e ferramentas de TI,

conforme ilustrado na Figura 6.

15

Figura 6 – Visão e Missão Departamento de Informática

Fonte: Documento do Sistema de Gestão de Qualidade da FDI

A Figura 6 retrata a visão do FDI de ampliar continuamente o nível de contribuição estratégico

da empresa, tendo como missão auxiliar na tomada de decisão no nível operacional, tático e

estratégico, objetivando melhorar os indicadores das áreas de negócio.

3.4 – Nível de Governança de TI da Software Developer

Nesta sessão, descrevemos inicialmente a metodologia utilizada para apurar o nível de GTI. Em seguida, apresentamos duas métricas de performance de TI, cujos dados coletados nos três últimos anos serão analisados estatisticamente. Como resultado, apresentamos e discutimos a correlação entre o nível de governança de TI e as métricas de performance.

3.5 – Obtenção das medidas de nível de governança

Para apurar o Grau de Maturidade do Modelo de Gestão de TI (Nível de Governança de TI), analisaremos os dados provenientes de uma pesquisa. Na pesquisa foram aplicados questionários, para diagnóstico do nível de Governança de TI, que fazem parte do módulo “Diagnóstico de TI” da metodologia “IT Strategy” da IBM GBS. Esta metodologia foi desenvolvida em 1998 pela empresa PriceWaterhouseCoopers Consulting, que em 2003 foi adquirida pela IBM GBS.

A idéia é de utilizar questionários com questões relativas a 5 domínios de TI: Serviços, Tecnologia, Sistemas, Pessoas e Estratégia. As respostas do questionários fornecem numa escala de 1 a 5 a percepção dos analistas de TI, usuários, fornecedores e usuários de TI sobre os domínios. Estes questionários são posteriormente consolidados de forma a obtermos a percepção dos respondentes sobre os domínios isoladamente. A média dos domínios é denominada como o

16

Nível de Governança ou Nível de Maturidade do Modelo de Gestão de TI. Estes questionários em 2005 foram respondidos por um número significativo de funcionários, foram 58 gerentes, 52 especialistas das áreas de negócio, 60 analistas de TI e 15 empresas prestadoras de serviços de TI. Nos anos de 2002, 2003 e 2004 o público alvo foi similar a 2005.

Claramente a amostragem para a obtenção dos dados é finita, isto é, nem todos os usuários de TI foram entrevistados. No entanto, o número de usuários que responderam ao questionário pode

ser considerado suficiente para os propósitos deste estudo.

3.6 – Aplicação dos Questionários

A aplicação dos questionários para apuração do grau de maturidade de TI foi realizada através

do envio de formulários Microsoft Word via correio eletrônico para os analistas de TI, e prestadores de

serviços, especialistas das áreas de negócio e gerentes. Em alguns casos os gerentes foram

entrevistados.

3.7 - Resultados

A avaliação do grau de maturidade do Modelo de Gestão de TI levou em consideração os

construtos relacionados com: Estratégia, Serviços, Tecnologia, Pessoal e Sistemas. Cada construto

possui uma série de sub- construtos que estão detalhados na Tabela 3.

Tabela 3 – Construtos e Sub-Construtos Metodologia de Gestão TI

17

Observa-se que os construtos apresentados na tabela 3 podem ser correlacionados com os

domínios direcionadores do modelo apresentado pelo ITGI e citado na sessão 2.2.3 e com os

indicadores do BSC de TI da SoftwareDeveloper, citados na sessão 3.2.2.2. Desta forma teríamos a

correspondência apresentada na Tabela 4.

Tabela 4 – Domínios ITGI versus Construtos Modelo Gestão CST

A Tabela 5 apresenta resumidamente a percepção dos analistas de TI, especialistas

e gerentes da área de negócio e fornecedores de TI sobre os construtos avaliados no Modelo de

Gestão de TI da Software Developer. A Avaliação do Modelos de Gestão de TI é a média dos

construtos: Estratégias, Tecnologia, Pessoas, Sistemas e Serviços.

Tabela 5 – Histórico Avaliação do Modelo de Gestão

Observa-se que embora a Avaliação do Modelo de Gestão tenha aumentado de 2002 a 2005, nem todos os construtos acompanharam evolução. Os construtos “Estratégia”, “Tecnologia” e “Serviços” também evoluíram, porém a os construtos “Sistemas” e “Pessoas” declinaram. Considerando que “Tecnologia” e “Serviços” estão associados a infra-estrutura, podemos observar que embora os recursos tecnológicos tenham evoluído, os “Sistemas” e desempenho dos analistas de TI (“Pessoas”) não acompanharam esta evolução. Ressaltamos que esta tendência pode ser explicada pelo fato de que o aumento de tecnologia trouxe certa insatisfação inicial tanto das “pessoas” devido a mudança cultural, quanto dos administradores de sistemas que precisaram se readaptar com a nova tecnologia.

3.8 – Métricas de Performance

Para apurar as Métricas Operacionais de TI serão analisados dados provenientes do Sistema de BSC de TI da empresa Software Developer. O BSC de BI faz parte do Sistema de Gestão da Qualidade (SGQ) do Departamento de Informática, que conforme citado anteriormente foi certificado em 2005 pela ISO 9001:2000. O BSC de TI foi adotado em 2003 e é composto por indicadores estratégicos de TI, que visam suportar o modelo de gestão. Os indicadores estão alinhados com os processos e objetivos da empresa e são constantemente reavaliados. Foram

18

escolhidos dois dos indicadores do BSC de TI: Índice de Consecução de Projetos Estratégicos e Índice de Disponibilidade de Sistemas, porque são indicadores cujos critérios de apuração são mais consolidados e não tiveram mudanças expressivas de 2003 até 2005. Segue abaixo uma breve descrição das métricas operacionais que serão utilizadas:

* Índice de Consecução de Projetos Estratégicos (ICP)

Este indicador mensura se os Projetos Estratégicos de TI estão tendo uma consecução de prazo, aderência e custo conforme planejado. Um projeto é considerado estratégico quando faz parte do Plano Empresarial da empresa. Os Projetos Estratégicos são classificados em Gerenciais, Administrativos e Produção.

* Índice de Disponibilidade de Sistemas de TI (IDS)

Este indicador mensura se os servidores que suportam os sistemas de TI estão disponíveis para uso dos usuários, analistas e desenvolvedores. O indicador mede mensalmente a disponibilidade de software /hardware tanto internos como externos (rede, servidor, banco de dados) com exceção das paradas para manutenção.

Tais indicadores foram selecionados por fazerem parte do Balanced Scorecard de TI e por terem seu processo de apuração mais consolidado. O ICP e IDS são acompanhados mensalmente desde 2003.

A tabela 6 abaixo apresenta os valores percentuais mensais do ICP e IDS, desde 2003. Na tabela, ilustra-se também a média anual dos indicadores citados, obtida mediante média dos meses. Conforme definições do BSC de TI da empresa analisada, a meta mensal do ICP é 85% e a meta mensal do IDS é de 99,30%. Percebe-se pela tabela 6 que apesar das variações, em todos osanos os indicadores ficaram acima da meta.

Da mesma forma a disponibilidade dos sistemas de TI ficou sempre acima da meta nos período de 2003 a 2005. Considerando uma disponibilidade de 99,9%, isto implica que um sistema esteve indisponível por 8.7 horas por ano. Cabe ressaltar que este indicador não considera

paradas programadas.

Tabela 6 – Histórico Indicadores Operacionais (IDS e ICP)

19

3.9 – Hipóteses Testadas

Para analisar se há influência da GTI na performance das métricas operacionais, foram elaboradas as seguintes hipóteses:

* H0: O Grau de Maturidade do Modelo de Gestão de TI influencia positivamente na Consecução dos Projetos de TI.

* H1: O Grau de Maturidade do Modelo de Gestão de TI influencia positivamente na Disponibilidade dos Sistemas de TI.

* H2: O Grau de Maturidade do Modelo de Gestão de TI influencia positivamente nos resultados das Métricas Operacionais de TI

A metodologia utilizada para testarmos as hipóteses H0, H1 e H2 foram testes de correlação. Para analisarmos se a hipótese “H0: O Grau de Maturidade do Modelo de Gestão de TI influencia positivamente na Consecução do Projetos de TI foi testada a correlação entre as variáveis “Avaliação do Modelo de Gestão” e “Métricas Operacionais”, conforme tabela 7. Observa-se que coeficiente de correlação medido entre as variáveis “Gestão” e “Métricas Operacionais” é -0,99, indicando que não há dependência positiva entre as variáveis. Assim sendo, a hipótese Ho: “O Grau de Maturidade do Modelo de Gestão de TI influencia positivamente nos resultados das Métricas Operacionais” não é verdadeira de acordo com este estudo.

Para testarmos a hipótese “H1: O Grau de Maturidade do Modelo de Gestão de TI influencia positivamente na Disponibilidade dos Sistemas de TI” foi feita a correlação entre as variáveis “Avaliação do Modelo de Gestão” e “IDS”, apontados na tabela 7. O coeficiente de correlação medido entre os construtos “Gestão” e “IDS” é -0,99, o que indica novamente que não há dependência positiva entre as variáveis. Uma justificativa para este resultado é de que 15 a Disponibilidade de Sistemas está sujeita a fatores não necessariamente ligados a Governança de TI, mas especialmente ligados a tecnologia de informação, por exemplo, falhas de hardware e software, sobrecarga na rede, queda da rede. Portanto, apesar do nível de governança ser suficientemente elevado, isto não implica

20

em uma melhoria nas métricas de performance, já que as métricas estão ligadas especificamente à tecnologia.

Para testarmos a hipótese “H2: O Grau de Maturidade do Modelo de Gestão de TI influencia positivamente nos resultados das Métricas Operacionais de TI” foi realizado um teste de correlação entre as variáveis “Avaliação do Modelo de Gestão” e “ICP”, apontados na tabela 7. O coeficiente de correlação medido entre os construtos “Gestão” e “ICP” é -1, o que indica que também não há dependência positiva entre as variáveis. A razão que justifica o resultado segue a argumentação anterior, ou seja, a Consecução dos Projetos de TI está sujeita a fatores que vão além da GTI tais como, mudança na prioridade dos projetos, alterações expressivas de escopo.

21

4- Conclusão Considerando as emergentes discussões e pesquisas sobre GTI, este artigo contribuiu através de um estudo de caso exploratório, investigando se as métricas operacionais de TI da empresa estavam correlacionadas com o nível do Modelo de Governança. O estudo foi conduzido na Software Developer, com analistas e usuários de TI cujos dados foram obtidos de uma pesquisa realizada pela empresa IBM. Com relação aos dados sobre Métricas Operacionais de TI provenientes, estes foram obtidos a partir do BSC de TI da empresa citada.

O trabalho demonstrou que o Nível de Governança de TI na Software Developer alcançou grau de maturidade entre 3 e 4, o que significa, segundo o modelo COBIT, que o modelo de gestão pode ser considerado como “Processos bem definidos e documentados”, tendendo a “Processos gerenciáveis e avaliados”. De acordo com a análise estatística, verificou-se que não há correlação positiva entre o Nível de Governança de TI e a performance das Métricas Operacionais de TI. No entanto, verificou-se também que os indicadores analisados ficaram acima da meta estipulada no BSC de TI no período analisado.

Assim podemos concluir que existem outros fatores, além dos mecanismos de GTI, que influenciam na performance dos indicadores de TI, considerando o estudo de caso realizado. Tais fatores podem ser estritamente técnicos como problemas de hardware não detectados em manutenções ou serem provenientes das áreas usuárias tais como mudança na priorização de atividades e atividades paralelas. Outro resultado importante é que embora o nível de GTI nem todos os itens que compõem a GTI evoluíram. Os construtos “Estratégia”, “Tecnologia” e “Serviços” também evoluíram, porém a os construtos “Sistemas” e “Pessoas” declinaram. Considerando que “Tecnologia” e “Serviços” estão associados ainfra-estrutura, podemos concluir que embora os recursos tecnológicos tenham evoluído, os “Sistemas” e desempenho dos analistas de TI (“Pessoas”) não acompanharam esta evolução.

Como trabalhos futuros, estamos interessados em incluir outras métricas operacionais além de “Índice Consecução Projetos Estratégicos” e “Índice de Disponibilidade de Sistemas” para que possamos continuar a investigação usando outras métricas do BSC de TI tais como o “Índice de Assertividade do Plano Estratégico de TI”, “Percentual de Desempenho do Fornecedores”. Outra direção a ser explorada é a extensão do estudo para outras empresas tanto do mesmo setor quanto de outros setores. Por último, uma vez que neste trabalho foi feita uma ligação entre Governança de

TI e Métricas Operacionais de TI, sugere-se analisar a correlação entre GTI e o ROI e/ou ROA de TI.

22

5-Referecias Bibliográficas

http://www.ietec.com.br

http://pt.wikipedia.org/wiki

http://www.projectcontrol.com.br

Manual do PIM

Apostilas

23

6-Glossário

Figura 1 – Relacionamento entre Governança Corporativa e Governança de TI........................7 Na Tabela 1, citamos a adaptação destas perguntas para a área de TI.................................... 8 Figura 2; As diferenças entre Governança de TI e Gerenciamento de TI.....................................8 A Figura 3 abaixo mostra graficamente a relação entre os domínios da GTI. .............................9 Tabela 2: Modelos de processos de maturidade do COBIT..........................................................11 Figura 4: Balanced Scorecard em TI.............................................................................................12

Figura 5 – Visão e Missão Departamento de Informática da Software Developer ........................14

Figura 6 – Visão e Missão Departamento de Informática............................................................ 15 Tabela 3 – Construtos e Sub-Construtos Metodologia de Gestão TI...........................................16

Tabela 4 – Domínios ITGI versus Construtos Modelo Gestão CST.............................................16 Tabela 5 – Histórico Avaliação do Modelo de Gestão.................................................................17 Tabela 6 – Histórico Indicadores Operacionais (IDS e ICP)........................................................18

24

UNIVERSIDADE PAULISTA CURSO SUPERIOR DE TECNOLOGIA

GESTÃO EM TECNOLOGIA DA INFORMAÇÃO


PIM V




SOFTWARE DEVELOPER.

BELÉM – PARÁ

2014

25


PIM V




SOFTWARE DEVELOPER

Trabalho do Projeto Integrado Multidisciplinar – PIM VII e

VIII, apresentado como exigência para conclusão do 4º

Semestre do Curso Superior de Tecnologia Gestão em

Tecnologia da Informação, da Universidade Paulista –

UNIP, campus Entroncamento.

Monitora: LUANE BARRAL

BELÉM - PARÁ

2014

26

Resumo As empresas que desejam conquistar o mercado competitivo precisam a cada dia estabelecer normas e conquistar certificados que visam um controle de processos e produtos bem estruturados. Nos dias de hoje as empresas devem investir pesado no profissional empreendedor, pois ele pode fazer com que a empresa busque oportunidades de negócio no mercado externo indicando à empresa o tipo de empreendimento que está voltado ao mercado externo baseado nos clientes. Muitas empresas acabam tendo certo medo de investir em empreendedores, mas é preciso que haja um planejamento bem eficiente e controlado para evitar os riscos de negócio. Hoje os profissionais podem contar com uma grande variedade de ferramentas de apoio na gestão de projetos para analisar a viabilidade do negócio. As ferramentas de apoio à gestão de projetos com planejamento, as normas e certificações de modelos de gestão e o espírito empreendedor devem caminhar juntos na empresa para obter o sucesso no mercado competitivo, que está acirrado a cada dia que passa. Além disso, é importante que os profissionais que estão envolvidos no projeto da empresa estejam todos envolvidos com muita dedicação e com bom relacionamentos e comunicação com qualidade, onde todos possam interpretar o objetivo de forma igual para garantir uma linguagem padrão dentro da empresa

27

Abstract Companies wishing to gain the competitive market need every day to establish standards and certificates that aim to gain control of a well-structured processes and products. Nowadays companies must invest heavily in professional entrepreneur; it can cause the company to seek business opportunities in foreign markets to the company indicating the type of enterprise that is focused on market-based external clients. Many companies end up having some fear of investing in entrepreneurs, but there must be a very effective planning and controlled to avoid business risks. Today, professionals can count on a wide variety of support tools for project management to analyze the viability of the business. The support tools project management with planning, standards and certification of management models and entrepreneurship must come together in the company to succeed in the competitive market, which is heated with each passing day. Furthermore, it is important that professionals who are involved in the project company are all involved with great dedication and good communication and relationships with quality, where everyone can interpret the purpose equally to ensure a standard language within the company.

28

Sumário

1 Introdução .............................................................................................................................................. 30

2 Gerência de projetos ............................................................................................................................ 30

3- Ferramenta para gestão de projetos ................................................................................................ 31

4 Microsoft Project ................................................................................................................................... 31

4.1 controle de custos ............................................................................................................................. 32

4.2 geração de relatórios ........................................................................................................................ 32

4.3 Gráfico de Gantt ................................................................................................................................ 32

5 Gestão dos riscos ................................................................................................................................. 33

5.2 avaliar, categorizar e priorizar riscos ............................................................................................. 34

5.3 elaborar planos de mitigação de riscos ......................................................................................... 34

5.4 ferramentas de apoio para riscos ................................................................................................... 34

6 Sistema de gestão da qualidade NBR ISO 9001 ............................................................................ 35

7 UML (unified Modeling language) ...................................................................................................... 35

8 Qualidade em softwares ...................................................................................................................... 36

9 Ferramentas da qualidade .................................................................................................................. 37

10 Norma NBR ISO 9000-3 ................................................................................................................... 37

10.1 qualidade de processos ................................................................................................................. 38

10.2 estrutura do sistema de qualidade ............................................................................................... 38

10.3 Ciclo de vida do software ............................................................................................................... 38

10.4 atividades de suporte ..................................................................................................................... 39

11 Norma NBR ISO/IEC 9126-1 ............................................................................................................ 39

11.1 funcionalidade ................................................................................................................................. 40

11.2 Confiabilidade .................................................................................................................................. 40

11.3 Usabilidade ...................................................................................................................................... 40

11.4 Eficiência .......................................................................................................................................... 40

11.5 Manutenibilidade ............................................................................................................................. 41

11.6 Portabilidade .................................................................................................................................... 41

12 CMMI – DEV ....................................................................................................................................... 41

12.1 Gerenciamento de requisitos ........................................................................................................ 42

12.2 Planejamento de projeto ................................................................................................................ 42

12.3 Monitoramento e controle do projeto ........................................................................................... 43

12.4 Gerenciamento de acordos com fornecedores .......................................................................... 43

12.5 Medição e análise ........................................................................................................................... 43

12.6 Garantia da qualidade de processo e produto ........................................................................... 44

29

12.7 Gerenciamento de configuração .................................................................................................. 44

12.8 Verificação ....................................................................................................................................... 44

12.9 Validação.......................................................................................................................................... 45

12.10 Treinamento organizacional ........................................................................................................ 45

12.11- Gerenciamento de riscos .......................................................................................................... 45

13 Empreendedorismo ............................................................................................................................ 46

14 O Perfil do empreendedor ................................................................................................................. 47

15 A oportunidade ................................................................................................................................... 47

16 Plano de negócio ................................................................................................................................ 48

17 Intraempreendedorismo .................................................................................................................... 49

18 Inovação e criatividade ...................................................................................................................... 49

19 Identificação das oportunidades ...................................................................................................... 49

20- Conclusão .......................................................................................................................................... 50

21 Referências bibliográficas ................................................................................................................. 51

22-Glossário ............................................................................................................................................. 52

30

1 Introdução A empresa desenvolvedora de software chamada Software Developer localizada na cidade de São Paulo – SP necessita de uma empresa que possa auxiliá-la nos seus projetos, devido a este fator achou necessário e contratou a consultora “Consulting” com o objetivo de entregar um estudo que contenha a análise de impacto, planejamento, desenvolvimento e a implementação de melhorias nos processos de TI.

A empresa Software Developer é uma empresa que desenvolve software para bancos que fornece produtos como: sistema de consórcio, sistema de financiamento e sistemas para empréstimos; ela prove sistemas para instituições financeiras, mas apresenta falhas que devem ser administradas pela Consulting. Além disso, os sistemas desenvolvidos pela Software Developer possuem falhas quando já estão em produção.

O gestor da área de TI da Software Developer definiu que era mais importante investir no smart phones e Voip para todos os funcionários e colocou o projeto que iria trocar as máquinas que são usadas para testes dos programas desenvolvidos, sendo que as máquinas de desenvolvimento e produção são SUN-Solaris 10.

A empresa Software Developer também prove serviços de suporte especializado para atuar em incidentes nos ambientes onde seus programas estão instalados, a consultora Consulting deverá administrar alguns problemas que foram notados no processo dessa empresa para que haja uma solução a estes problemas e adotar um sistema de qualidade para que tenha uma melhoria de processos.

A empresa Consulting de consultoria deverá implantar um sistema de gerenciamento dos projetos de software da Software Developer com qualidade de forma que possa implementar o obter a certificação CMMI, baseado nos sistemas de gestão da qualidade com base nas normas de qualidade de software e modelos de melhoria do processo de software.

31

2 Gerência de projetos

Na Software Developer será adotado um sistema de gerenciamento de projetos com o objetivo de obter um controle e uma administração com eficiência, objetivando o sucesso do projeto. Neste caso haverá um Gerente de projetos com a função de avaliar o progresso das atividades como a qualidade, custo e prazo, bem como seus desvios e seus riscos. Além disso, o Gerente de projetos deverá ter certa autoridade sobre sua equipe de projeto.

Para que o projeto da Software Developer tenha sucesso é preciso que haja basicamente algumas especificações a serem seguidas, que são: metodologia, no caso será adotado no desenvolvimento do projeto o CMMI, a mais adequada para desenvolvimento de software; comunicação, será implantado um sistema de comunicação bem estruturado, para que o software seja desenvolvido de forma que todos os envolvidos possam obter informações inerentes ao projeto, através de reuniões e boletins informativos, assim o time poderá desenvolver suas atividades com mais conhecimento, facilitando uma solução aos problemas no decorrer do projeto; escopo e atividades, nesta parte o gerente de projetos definirá todas as atividades que será executado para atingir o objetivo, definindo o esforço necessário de cada colaborador do time definido.

O Gerente de Projetos pode definir as atividades de cada um através de uma tabela, bem como o custo já definido seguido das horas necessárias para o projeto, é preciso ser bem detalhado para que haja um controle rígido das atividades e seus custos. Dessa forma o Gerente de Projetos terá um escopo sem mudanças garantindo a entrega do projeto ao cliente sem custos adicionais; recursos envolvidos no projeto, será definido no projeto todas as pessoas envolvidas: membros da equipe, clientes, fornecedores, líder.

O Gerente vai definir os recursos para o desenvolvimento do projeto definindo uma métrica para selecionar os melhores profissionais com competência para as tarefas definidas; desenvolvimento do cronograma, na Software Developer o desenvolvimento do cronograma não será feito pelo Gerente de projetos, ele será criado pelas pessoas que executam a tarefa, dessa forma obterá uma melhor duração e o responsável por cada atividade, além disso será definido que haja uma revisão do cronograma com todo o time para melhor identificar as atividades; riscos, será implantado uma gestão de riscos do projeto para identificar os riscos, criando uma lista de fatores de risco e um plano para lidar com eles, assim poderá monitorar os riscos e as ações que deverão ser tomadas para minimizar seu impacto no projeto, início e fim do projeto, será formalizado o início do projeto com o Sponsor através de uma reunião de forma a sinalizar o início das atividades com todos os membros da equipe, bem como o seu término demonstrando os resultados alcançados, após a finalização do projeto a Consulting realizará uma reunião com a equipe para identificar os problemas, erros e acertos e gerar um documento das lições aprendidas que poderão ser úteis em novos projetos, evitando o acontecimento dos mesmos erros e problemas da desenvolvedora de software, a Software Developer.

3- Ferramenta para gestão de projetos

A Software Developer apresenta falhas no controle de criação dos projetos de softwares que são desenvolvidos aos seus clientes. Para que esse problema seja solucionado a Consulting implantará nos projetos de softwares a utilização de uma ferramenta para a gestão de projetos, a Microsoft Project.

4 Microsoft Project

A ferramenta Microsoft Project possui várias funcionalidades que vão auxiliar o gerente de projeto nas decisões e nos caminhos que irão percorrer durante todo o projeto. Para que um projeto funcione é preciso definir as atividades, duração, predecessor e responsável. Na Microsoft Project ao definirmos a duração da atividade e seus predecessores, ele calcula automaticamente as datas de

32

início e fim de cada atividade, gerando um mapa em forma de gráfico (gráfico de Gantt) com relacionamentos entre atividades tornando mais fácil a visualização do projeto.

Dentre as fases mais importantes do projeto, podemos citar a fase piloto, implantação, processo de mudança e o treinamento necessário para que os usuários saibam como utilizar o novo software. Através de uma tabela informativa contendo as fases do projeto da Software developer é possível um maior controle da criação das fases do projeto, pois o gerente de projeto pode acompanhar o progresso das atividades adicionando uma coluna indicando a porcentagem de cada atividade concluída, dessa forma o gerente de projeto pode verificar se as atividades serão finalizadas dentro do prazo previsto.

4.1 controle de custos

O controle de custos dos projetos da Software Developer possui falhas, e por isso a Microsoft

Project vai auxiliar no controle de custos do projeto, pois nele pode ser informado os valores de cada

profissional e recurso, verificando quanto já foi gasto no projeto das máquinas que são usadas para

testes dos programas desenvolvidos e seus profissionais envolvidos no projeto e os stackholders.

4.2 geração de relatórios

A ferramenta Microsoft Project permite que o gerente de projeto possa emitir relatórios gráficos

e textos que auxiliarão no gerenciamento do projeto, ele pode contar com relatórios de visão geral do

projeto, atividades atuais do projeto, custos do projeto, tarefas assinaladas para cada recurso, carga

de trabalho sobre todos os funcionários etc., permitindo que a Software Developer tenha um auto

controle administrativo do projeto para evitarem falhas em todos os setores.

4.3 Gráfico de Gantt

O gerente de projeto da Software Developer também pode contar com uma ferramenta muito

importante da Microsoft Project que vai auxilia-lo no gerenciamento, o qual vai demonstrar um gráfico

de ligação entre as atividades no tempo do projeto. Além disso, a Microsoft Project possuem recursos

de diagrama de rede, gráficos de recursos e planilhas de recursos.

33

5 Gestão dos riscos

Na Software Developer apresenta uma falha no cadastramento dos riscos associados aos processos de negócio, dessa forma será preciso implantar um sistema de gestão de riscos para que haja uma administração de maneira eficiente podendo instalar uma maneira facilitada e previsível para lidar com os riscos de TI.

Para que a gestão de riscos da Software Developer tenha uma estrutura funcional eficiente é preciso primeiramente dividi-la em duas partes, que são: a gerência de riscos, o qual vai definir uma previsão dos imprevistos; a análise de riscos, definirá as atividades que visam a identificação dos fatores de riscos, avaliando o impacto e definindo a ações que serão executadas para reduzir ou eliminar os riscos.

O processo de gerenciamento de riscos, na verdade, é uma combinação da sua análise e do seu controle, pois para que uma empresa possa desempenhar seus projetos com segurança e certeza é preciso haver uma gestão de risco muito bem elaborado e estruturada. A figura abaixo mostra como será implantado o sistema de gestão de riscos da Software developer.

Figura 1– modelo de gestão de riscos da Software Developer

5.1 Identificar e analisar riscos

A identificação dos riscos será feita por um profissional especializado nesta área, os riscos são identificados e analisados para determinar a importância de cada um deles. Os riscos serão identificados e descritos de forma compreensiva antes que sejam analisados e gerenciados. Os riscos serão documentados com textos, condições e conseqüências de sua ocorrência. A s atividades de identificação de riscos foca somente nos riscos, não na colocação de culpa em alguém, ela não pode ser usada pela gerência para analisar o desempenho dos indivíduos.

Para identificar os riscos do projeto da Software Developer serão adotados alguns métodos: examinar cada elemento da estrutura de decomposição de trabalho do projeto para descobrir riscos, conduzir uma avaliação de riscos usando a classificação de riscos, entrevistar os peritos no assunto em foco, revisar os esforços de gestão de risco, examinar documentos ou banco de dados de lições aprendidas, examinar especificações de design e requisitos de acordos.

34

Algumas práticas serão implantadas nesta fase do risco na Software Developer, como: identificar os riscos associados a custo, cronograma e desempenho em todas as fases do ciclo de vida do software, revisar todos os elementos da WBS para ajudar a garantir que todos os aspectos do esforço de trabalho foram considerados, documentar o contexto, as condições e as potencias cconsequências dos riscos e identificar os stackholders associados a cada risco.

5.2 avaliar, categorizar e priorizar riscos

Nesta fase será categorizado cada risco identificado utilizando as categorias do risco e

determinar suas prioridades relativas.

As práticas implementadas nesta fase dos riscos serão avaliadas de forma eficiente e com

qualidade. A Software Developer implantará as seguintes práticas: avaliar os riscos identificados a

partir dos parâmetros de risco definidos, estas conterão as conseqüências, que são: baixa, média,

alta, desprezível, marginal, significante, crítica e catastrófica; categorizar e agrupar os riscos de

acordo com as categorias de riscos definidos; priorizar os riscos para mitigação.

5.3 elaborar planos de mitigação de riscos

Agora é preciso elaborar um plano de mitigação de riscos para os riscos mais importantes do projeto. O plano de mitigação de riscos vai ser utilizado com o objetivo de evitar, reduzir e controlar a probabilidade de ocorrência do risco, para isso a Software Developer vai implantar alternativas para tratamento dos riscos, como: evitar risco, a mudança ou diminuição de requisitos durante o levantamento das necessidades do usuário; controlar risco; executar ações para minimizar riscos; transferir risco; realocar os requisitos de design para diminuir riscos; monitorar riscos; observação e reavaliação periódica do risco de mudança de parâmetros dos riscos atribuídos; aceitar risco sabendo reconhecer o risco, mas não tomar nenhuma ação precipitada.

Para elaborar um plano de mitigação de risco serão implantadas as seguintes práticas: determinar os níveis que definem quando o risco se torna aceitável seguido do plano de mitigação do risco ou plano de contingência; identificar a pessoa ou equipe responsável pelo tratamento dos riscos; determinar o motivo custo-benefício de implementar o plano de mitigação para cada risco; elaborar um plano geral de mitigação de riscos com planos individuais; elaborar um plano de contingência para os riscos críticos selecionados dos impactos conhecidos.

5.4 ferramentas de apoio para riscos

Além de todo o plano de risco que foi implantado na Software Developer, ainda poderá contar

com duas ferramentas de apoio para gerenciamento de riscos, onde temos a ficha de controle de

risco, o qual será usada ao ser identificado corretamente e logo documentado com todas as

35

informações de cada fator de risco. A outra ferramenta é o software de controle de risco que auxiliará

no gerenciamento de riscos utilizando-o como apoio para gestão.

6 Sistema de gestão da qualidade NBR ISO 9001

A Software Developer implantará um sistema de gestão da qualidade em software baseada na NBR ISO 9001, através dessa norma ela poderá ter um produto e serviço para o cliente com mais qualidade, pois esta norma oferece ao cliente a garantia de que o provedor de serviço conforme as especificações dos clientes, baseada no sistema de melhoria contínua chamado de PDCA.

É importante implantar na Software Developer aos funcionários, a garantia de que o sistema esteja sendo executado de forma uniforme e padronizada, ou seja, que todos estejam cientes de procedimento dessa norma; vale destacar neste item que uma comunicação eficiente implantada dentro da empresa será de extrema importância, juntamente com um esquema de documentação do processo para que o sistema funcione de forma eficaz, assim há a garantia principal do sistema PDCA, que é consistência e repetitividade.

Neste sistema serão adotadas auditorias para verificar se os funcionários estão seguindo os padrões das normas, para analisar se o funcionário conhece os processos e os utiliza de forma correta;

Os clientes da Software Developer estão reportando que independente do tipo de problema, não há explicações claras do real motivo da causa raiz e normalmente não é aplicado as correções nos demais ambientes, neste caso deverá implantar o PDCA para melhoria do software, devendo ser parte de uma ação corretiva com base nas lições aprendidas, pois a idéia do PDCA é garantir a melhoria constante do processo, pois ele é baseado no planejamento, execução, checagem e ações corretivas para melhora-lo com mais performance possível.

Este sistema será somente uma base para a empresa Software Developer, pois outras normas mais especificadas serão adotadas para melhoria de software e seus processos com qualidade.

Figura 2 - Ciclo PDCA

7 UML (unified Modeling language)

A Software Developer apresenta falhas no armazenamento de desenhos de processo e no gerenciamento dos documentos e controle dos períodos de retenção e distribuição. Dessa forma para que a empresa possa administrar os desenhos dos processos com mais elegância, claros e bem

36

estruturados e fácil compreensão e assimilação do que se pretende descrever adotará a linguagem UML para os desenvolvedores de software; e, para que esse documento seja controlado com mais eficiência dentro da empresa sua retenção e distribuição será feita através de uma política de controle direcionada aos funcionários para que não haja falhas e perdas na empresa.

Este tipo de linguagem facilitará o processo da empresa com mais agilidade, pois é uma linguagem visual para especificar, construir e documentar softwares dos clientes. Ela tem o propósito de modelar para entendimento e documentação dentro de um processo de desenvolvimento. Esta linguagem define vários tipos de modelos que abrangem uma escala de modelos e requisitos funcionais no fluxo do trabalho para projetos de estrutura de classe e diagramas de componentes, ela não será usada somente para programadores, mas também aos funcionários que estão envolvidos no projeto.

Para que ela possa ser implantada na empresa, antes será desenvolvido um curso aos funcionários envolvidos no projeto, para que haja uma padronização, evitando conflitos futuros.

Figura 3 – uml call center da Software Developer

Este exemplo mostra basicamente um modelo de call center para que haja um gerenciamento

na Software developer, com controle de gastos e execuções utilizadas e solicitadas pelos clientes,

tipos de solicitações, tempo de atendimento, quantidade de chamadas etc.

8 Qualidade em softwares

A Software Developer vai implantar um sistema de gestão da qualidade no desenvolvimento

de softwares, baseada em qualidade de processos e de produtos eficientes, utilizando normas de

qualidade de software e modelos de melhoria do processo dos softwares desenvolvidos. Assim, o uso

dessas normas e técnicas vai serem utilizado de forma interligadas e inter-relacionadas para

contribuir no desempenho da qualidade de forma cooperativa e integrada, visando atingir metas para

que a empresa possa ser certificada, atingindo uma crescente demanda de clientes interessados nos

37

produtos de software da Software Developer e buscando uma melhor competitividade de produtos

dos concorrentes de mercado de software.

9 Ferramentas da qualidade

Para que a administração dos projetos de software possa ser controlados o gerente de projetos utilizará algumas ferramentas de apoio que darão suporte para uma administração bem estruturada dentro da Software Developer.

As ferramentas de apoio serão: diagrama de pareto, esta ferramenta permite descrever graficamente a identificação que é responsável pela maior parte dos problemas, após a construção deste gráfico, onde temos no eixo vertical são organizadas as quantidades de problemas apresentados em um determinado período, e na horizontal as quantidades de erros de cada tipo de erro em ordem crescente, o percentual de cada tipo de erro e o percentual acumulado ao longo dos tipos de erros etc., a partir deste gráfico analisa-se os dados obtidos para uma tomada de decisão para verificar quais ações deverão ser tomadas e os tipos de erros que terão prioridades nas ações da Software Developer, assim o administrador do projeto poderá ter um controle dos erros dando suporte para uma decisão, já que a Software Developer também atua no suporte especializado em incidentes nos ambientes onde seus programas são instalados; diagrama de causa e efeito, esta ferramenta identifica causas do problema envolvido de um processo produtivo, quando identificado este problemas e colocado como efeito no diagrama são identificados e relacionados, depois são identificados as causas do problema e colocados no diagrama também, assim este diagrama vai ajudar a entender as causas que deram origem ao problema durante o processo de produção do software; lista de verificações, esta lista é uma forma de coleta de dados referente aos fatos ocorridos para uma atividade ou problema, a finalidade dela é organizar os dados para facilitar o entendimento, serão implantadas listas de várias categorias, como listas de freqüências, classificação de erros, listagem de defeitos, lista de verificação etc., cada setor terá a responsabilidade de implantar de forma eficiente as listas de verificações; histogramas, o histograma possibilita analisar as concentrações de comportamento de uma pesquisa dos dados obtidos, classificando os dados em classes e contagem de quantidade, traçando um retângulo cujas alturas são proporcionais as quantidades, assim o histograma permite uma visualização de forma resumida.

10 Norma NBR ISO 9000-3 A Software Developer vai implantar um sistema de gestão baseada nesta norma para garantir um controle maior nos projetos, desenvolvimento, fornecimento, instalação e manutenção de software, visando atingir esta certificação. Ela vai orientar o estabelecimento de sistemas de qualidade nos produtos de software. Esta norma define e conceitua os termos de software produto de software e desenvolvimento.

É preciso primeiramente estruturar a empresa com profissionais envolvidos no sistema que tenham habilidades, e também administrar o desenvolvimento do software no levantamento e especificações corretas das necessidades ou requisitos dos usuários, dos objetivos da qualidade e dos critérios de aprovação, os quais devem reduzir o tempo de desenvolvimento, diminuindo custos e aumentando a lucratividade e a competitividade da empresa nos softwares, na verdade é necessária uma busca contínua da melhoria da qualidade de software.

38

10.1 Qualidade de processos

A Software Developer vai implantar através da ISO-9003-3 as seguintes diretrizes: efetuar o

entendimento dos requisitos funcionais pelo contratante e contratada, utilizar metodologias de

desenvolvimento de software desde a concepção até a instalação do software e utilizar as

metodologias de gerenciamento do projeto.

10.2 Estrutura do sistema de qualidade

A Software Developer através desta norma descreverá as responsabilidades e ações referentes à qualidade, os quais devem ser tomadas tanto pelo fornecedor do software (Software Developer) como pelo cliente, nas fases do ciclo de vida do software, será implantado uma política de qualidade formal e documentada, divulgada e compreendida por todos os funcionários da Software Developer. É preciso que os funcionários tenham responsabilidades e autoridades suficientes para implementar as políticas. Será implantado também um grupo de pessoas para verificar, de forma independente, o uso correto das políticas de qualidade.

A estrutura do sistema de qualidade da Software Developer, adotará os pontos de estabelecimento de responsabilidades gerenciais inclusive o gerente de projeto, definir e documentar o sistema da qualidade, adotar procedimentos de auditoria interna, e procedimentos para ações corretivas.

10.3 Ciclo de vida do software

A Software Developer vai administrar o ciclo de vida do desenvolvimento de software em etapas e atividades. Elas irão cobrir os itens de estudo preliminares o qual definirá o escopo do sistema, análise ou especificação do sistema, detalhando e elaborando as funcionalidades, estruturação física do sistema, programação e construção, implantação para produção do software e a manutenção. O ciclo de vida do software será avaliado em cada atividade, onde serão divididas para obter um controle e avaliação com eficiência. Análise critica de contrato, a empresa vai adotar itens valiosos nos contratos de compra e venda de software, como: abrangência do trabalho, contingências e as proteções de informações proprietárias. Especificações de requisitos do comprador, as especificações serão preparadas em conjunto pelos compradores e fornecedores, devendo atentar aos aspectos de performance, confiabilidade, segurança e privacidade. Planejamento do desenvolvimento, nesta fase será definido o plano de desenvolvimento, o qual será incluído a definição do projeto, organização dos recursos, as fases do desenvolvimento, cronogramas, plano de testes, e também metodologias de monitoração e verificação do progresso. Planejamento da qualidade, o plano da qualidade vai objetivar a qualidade do software em desenvolvimento, ele abrange a redução do reprocessamento, redução do número de chamadas da assistência técnica, redução do número de horas para treinamento;

Nesta fase ocorre um planejamento detalhado das atividades de verificação e validação e suas responsabilidades específicas para cada atividade do projeto. Projeto e implementação, nesta

39

fase ocorre uma análise do software onde o comprador e os fornecedores concordarão com as informações fornecidas ao comprador, o projeto deverá planejar as futuras manutenções aderindo aos padrões da empresa na interfase do homem com a máquina e no uso do ambiente de programação. Teste e verificação, o plano de teste será montado com base nos seguintes itens: ambiente, documentação, cases de teste e dados, simulação do sistema completo e testes de campo. Aceitação, esta é a fase onde deverão cobrir os termos acordados previamente e suas condições impostas pelo comprador para aceitação do produto. Reprodução e instalação, esta é a parte onde irão tratar do registro referente ao número de cópias, tipo do meio físico utilizado, direitos autorais e licenças, critérios de envio e obrigações do fornecedor e comprador, os quais estarão ligados à instalação do software que foi desenvolvido. Manutenção, a manutenção será incluída no contrato de compra dos clientes da Software Developer, os quais irão cobrir os seguintes serviços de manutenção: mudanças no software, solução de problemas, correção de defeitos, modificação de interfaces, melhorias de desempenho e expansões funcionais.

10.4 atividades de suporte

A Software Developer vai implementar atividades de suporte visando o suporte a todas as fases do projeto, o qual será desenvolvido em todo o ciclo de vida do software. Sistema de gestão da configuração, vai identificar e rastrear o controle de alterações do software, fornecendo mecanismo para o controle do software pelo gerente de projetos, visando identificar cada versão e controlar a atualização simultânea do software, e, rastrear e identificar as alterações resultantes do pedido de alteração. Controle de documentos, a Software Developer vai implantar procedimentos através do gerente de projetos para controlar toda a documentação relacionada ao software.

Os documentos que serão controlados de forma mais aprofundada com mais atenção dentro da Software Developer, são: documento de descrição do sistema de qualidade em todo o ciclo de vida do software, documento de planejamento das atividades da Software Developer e as interações com o cliente e os documentos que estão relacionados com o produto.

Registros da qualidade, deverá implantar normas que os registros da qualidade sejam rapidamente recuperáveis; mantendo formas que identifica, coleta, arquiva, armazena e mantém os registros. Medição, é preciso implantar métricas e técnicas que irão medir os produtos e os processos desde o desenvolvimento até a produção, indicando as falhas e defeitos prejudiciais ao cliente. Ferramentas e técnicas, a Software Developer utilizarão as ferramentas e as técnicas da empresa com padrões através do gerente de projetos. Aquisição, a Software Developer tem o compromisso de garantir o software com qualidade de acordo com os requisitos especificados dos serviços e ferramentas de desenvolvimento. Treinamento, a Software Developer terá a responsabilidade de identificar as necessidades de treinamento, visando qualificar as pessoas envolvidas e seus clientes,

preparando as pessoas que executam as tarefas influenciando na qualidade.

11 Norma NBR ISO/IEC 9126-1 A Software Developer vai incluir no seu plano de projeto as normas da NBR ISO/IEC 9126-1, visando buscar uma alta qualidade de produto dos softwares desenvolvidos, através dessa norma a empresa vai buscar uma garantia de qualidade adequada ao cliente.

Esta norma vai auxiliar na avaliação da qualidade em situações que podem apontar adequação eficiente ao cliente. Ela vai definir os requisitos da qualidade do software; avalia as especificações do software para verificar se vai satisfazer aos requisitos da qualidade durante o desenvolvimento; descreve as particularidades do software através de manuais de usuário; avalia o software antes da entrega; avalia o software antes da aceitação.

40

11.1 funcionalidade

Serão apresentadas as funções que atenderão todos os requisitos do cliente e usuário, de

forma que satisfaça as necessidades do cliente. A funcionalidade vai caracterizar em partes para

obter um estudo com melhor qualidade, temos: adequação, vai garantir as especificações do software

e suas funções; conformidade, os softwares serão desenvolvidos com os padrões e regras

estabelecidas no projeto pelo gerente de projeto; segurança de acesso, garantir que o software não

seja acessado por pessoas ou aplicações não autorizados; interoperabilidade, capacidade de

interagir com outros sistemas, de acordo com as especificações.

11.2 Confiabilidade

A confiabilidade vai garantir que o cliente confie no software, não o perdendo para o

concorrente, dessa forma é preciso manter o alto nível de desempenho dentro das condições

estabelecidas com o cliente. A confiabilidade deve manter: maturidade, obter uma baixa freqüência

de falhas e defeitos dos softwares em operação, tolerância à falhas, o software deve manter seu bom

desempenho mesmo quando apresentarem problemas durante sua execução, recuperabilidade, é

preciso ter capacidade e suporte para restabelecer o nível de desempenho garantindo a recuperação

das bases de dados em caso de falhas.

11.3 Usabilidade

A Software Developer deve garantir ao cliente o uso do software de forma mais usual possível.

Ela deve garantir a inteligibilidade, o qual vai facilitar ao usuário reconhecer a lógica de

funcionamento do software e suas aplicações; apreensibilidade, a garantia de facilidade encontrada

pelo usuário para aprender a utilizar o software; operacionalidade, facilidade do cliente em operar o

software.

11.4 Eficiência

O software deve ter bom desempenho com bastantes recursos disponibilizados aos clientes. O

software deve conter comportamento com relação ao tempo, ou seja, o tempo de resposta e de

41

processamento e taxas de saídas ao executar funções especificadas; comportamento com relação ao

uso de recursos, ou seja, quantidade dos recursos necessários e a duração do seu uso.

11.5 Manutenibilidade

A Software Developer deverá estruturar a disponibilidade necessária de pessoas por hora

para alterações no software. Ela deve cobrir os seguintes itens: analisibilidade, diagnosticar

deficiências localizando as partes para a correção dos problemas; modificabilidade, remoção de

falhas e adequação do produto às mudanças na tecnologia e no ambiente operacional; estabilidade,

são os riscos de efeitos inesperados nas modificações do software; testabilidade, teste do software

alterado.

11.6 Portabilidade

A Software Developer para que não corra o risco de perder os seus clientes que migram para

outros ambientes operacionais, deverá manter um software com fácil transferência para outros

ambientes. Ela deverá manter: adaptabilidade, facilidade de adaptação do software para funcionar em

outros ambientes operacionais; facilidade de instalação, manter uma instalação do software de

maneira fácil e prática; capacidade de coexistir, ser um software com padrões de conformidade

referentes à portabilidade; facilidade para substituir, o seu uso substituto a outro software de forma

mais fácil possível ao cliente.

12 CMMI – DEV A Software Developer vai implantar no seu modelo de gestão o CMMI, ela quer essa certificação com intuito de integrar com as outras anteriormente definidas, buscando o máximo de qualidade nos softwares desenvolvidos, nos processos e nos atendimentos de suporte ao cliente. Ela pretende conquistar um crescimento de clientes muito rápido com as certificações pretendidas.

O CMMI vai oferecer a Software Developer oportunidade de eliminar os obstáculos através desse modelo, ele é constituído pelas melhores práticas das atividades de desenvolvimento e manutenção indicando como são aplicadas aos produtos e serviços. Esse modelo cobre o ciclo de vida do produto desde a concepção até a entrega e manutenção, e ainda a empresa poderá oferecer um software com bons serviços, rápido e barato. Além disso, vai auxiliar nos processos que permitem alinhar com os negócios da empresa, permitindo alavancar recursos e examinar as tendências de negócios de forma mais competitiva.

Através dessa ferramenta a Software Developer poderá contar com auxilio nos problemas que

42

estão enfrentando no dia a dia. Ela apresenta falha em alguns modelos básicos do sistema quando já estão em produção.

A Software Developer prove serviços de suporte especializado para atuar em incidentes nos ambientes onde seus programas estão instalados, e, alguns problemas foram notados, mas com a implantação do CMMI-DEV na empresa esses problemas serão gerenciados e resolvidos com mais precisão e eficiência.

Um dos problemas é quando um cliente abre um ticket reportando um problema, o atendente anota em um caderno e faz uma avaliação pessoal de quanto é crítico o chamado para então classificá-lo, mas é possível notar a classificação totalmente diferente para problemas iguais quando é outro analista que atende. Outro problema é quando no desenvolvimento de uma nova correção os analistas enviam os pacotes para os ambientes em produção e executam atualizações imediatamente, mas vários problemas nos ambientes de produção dos clientes da Software Developer aconteceram coincidentemente logo após algumas atualizações, deixando o ambiente do cliente por horas parado e impactando diretamente nas operações. A Software Developer também enfrenta problemas com os clientes, pois eles estão reportando que independente do tipo de problema, não há explicações claras do real motivo da causa raiz e normalmente não é aplicado as correções nos demais ambientes.

12.1 Gerenciamento de requisitos É importante ressaltar que nesta PA os requisitos abordados não são do software, más sim os requisitos do negócio. Na verdade define o que o cliente quer, e não como o software será.

No gerenciamento de requisitos deverão conter técnicas de identificação, como: as entrevistas e questionários, o qual é bastante eficaz na fazer inicial de obtenção de dados, podendo esclarecer dúvidas dos clientes. É importante que o entrevistador dê margem ao entrevistado para expor suas idéias, é preciso uma relação das pessoas na entrevista e também é importante que o entrevistante tenha capacidade de seguir um plano para a entrevista. O workshop de requisitos consiste numa técnica usada através de uma reunião estrutura, da qual devem fazer parte um grupo de analistas e um grupo representando o cliente, para então obter um conjunto de requisitos bem definidos.

Quanto aos cenários, será uma forma de levar as pessoas a imaginarem o comportamento de um sistema, através de exemplos práticos descritivos do comportamento de um sistema, os seus utilizadores podem comentar acerca do seu comportamento. O uso da prototipagem trata-se de uma versão inicial do sistema, baseada em requisitos ainda pouco definidos, mas que pode ajudar a encontrar desde cedo falhas que através da comunicação verbal não são tão facilmente

identificáveis.

12.2 Planejamento de projeto

O planejamento de projeto busca estabelecer estimativas do projeto através das ferramentas que o gerente de projeto utilizará, ele vai elaborar um plano de projeto e obter comprometimento com o plano.

O planejamento vai qualificar o tempo e o orçamento que um projeto custará, a sua finalidade é criar um plano do projeto onde o gerente de projeto possa usar para acompanhar o progresso de sua equipe.

43

O gerente de projeto deverá planejar um projeto com base em alguns itens: determinar algumas condições para que o projeto seja finalizado ou completado antes que estejam absolutamente claros quais são os objetivos do projeto; fazer um inventário da maioria do trabalho que precisa ser feito; identificar os recursos necessitados para executar cada elemento terminal de cada tarefa; definir algumas dependências entre tarefas; nas tarefas na qual é impossível estimar o prazo com precisão, coloca-las fora do caminho crítico e fazer o planejamento separado; criar um cronograma do projeto; obter o comprometimento da organização em iniciar a execução do projeto. Em algumas organizações este pode ser um processo burocrático e que toma tempo, o melhor a fazer é iniciar o projeto em paralelo enquanto a aprovação não é obtida.

12.3 Monitoramento e controle do projeto

Neste item do CMMI-DEV o foco é no monitoramento do projeto em relação ao plano pré-

definido; o gerente do projeto deve gerenciar as ações corretivas até o encerramento. O propósito do

monitoramento e controle do projeto é proporcionar um entendimento do progresso do projeto, de

forma que ações corretivas apropriadas possam ser tomadas quanto o desempenho do projeto

desviar significativamente do plano.

12.4 Gerenciamento de acordos com fornecedores

A Software Developer vai estruturar meios de obter aquisição de produtos ou componentes

através de acordos com o fornecedor estabelecendo acordos e satisfazendo acordos com eles.

Este item busca gerenciar uma gestão de acordos com fornecedores na aquisição de

produtos. Os componentes e produtos gerenciados do projeto são: subsistemas, software, hardware,

documentação etc.

12.5 Medição e análise

O foco neste item é estabelecer uma estrutura para monitoramento dos projetos e processos. O gerente de projetos deve ter uma visão de alinhamento das atividades de medição e análise fornecendo resultados de medição.

O objetivo da medição e análise é desenvolver e sustentar a capacidade de medições utilizada para dar suporte às necessidades de gerenciamento de informações.

O gerente de projetos deverá estruturar ferramentas que vão apoiá-lo para alinhar as atividades de medição e análise, onde irá estabelecer objetivos de medições, especificarem medidas,

44

especificar procedimentos de coleta e armazenamento de dados, especificarem procedimentos de análises. Além disso, deve fornecer resultados de medições, como: coleta de dados de medição, análise de dados, armazenamento de dados e resultados e comunicação de resultados. Vale ressaltar que os objetivos e atividades de medições são alinhados com as necessidades e objetivos de informações identificados.

12.6 Garantia da qualidade de processo e produto

Agora o gerente de projeto da Software Developer vai munir a equipe com sua gerência com uma visão clara sobre os processos e seus produtos de trabalho. Ocorre então, uma avaliação objetiva dos processos e produtos de trabalho e o fornecimento de um entendimento objetivo.

A empresa vai utilizar as seguintes formas de executar avaliações objetivas: auditorias formais realizadas por equipes de garantia da qualidade independentes na organização, revisões por pares que podem ser realizadas com vários níveis de formalidade, revisões detalhadas do trabalho onde ele é realizado, revisões e comentários distribuídos de produtos de trabalho; onde os membros são treinados e os papéis são atribuídos às pessoas presentes, um membro da revisão por pares que não elaborou o software é designado para desempenhar o papel de garantia da qualidade, as listas de verificação são disponibilizadas para dar suporte às atividades QA e os defeitos são registrados como parte do relatório da revisão por pares e endereçadas para fora do projeto quando necessário.

12.7 Gerenciamento de configuração

A gerência de configuração é responsável por fornecer o apoio para o desenvolvimento de software. Ela vai auxiliar no controle de versão, controle de mudança e auditoria das configurações. O gerente de projetos deverá atentar para alguns itens: verificar o que mudou e quando mudou, o motivo da mudança, o responsável por ela e a possibilidade de reproduzir esta mudança. Além disso, o gerente de projetos deverá estruturar sua equipe que seja capaz de identificar objetos, controlar versões, sincronizar as mudanças concorrentes, políticas de cópia tanto o modelo trava – modifica – destrava, quanto o modelo copia – modifica – resolve.

A gerência de mudanças é uma parte importante da gerência de configuração, pois é a atividade que permite saber o motivo de uma configuração ter sido mudada. Ela tem por objetivo mapear, para cada mudança efetuada no sistema, qual foi o motivo que gerou esta mudança.

12.8 Verificação

Neste item a Software Developer trabalha para que seja assegurado que os softwares atendam

aos seus requisitos especificados. O gerente de projetos vai efetuar uma preparação para a

verificação, vai realizar revisão por pares e verificar os softwares selecionados.

45

12.9 Validação

A validação busca demonstrar que um produto ou componente de produto atende ao seu uso

pretendido quando colocado em seu ambiente alvo. Neste item a gestão busca preparar uma

verificação e validar o software ou os componentes de software. O gerente de projetos na fase de

validação dos requisitos deve verificar através de checklists, os seguintes atributos: validade,

consistência, compreensibilidade, completude, realismo, verificabilidade, rastreabilidade e

conformidade com normas.

12.10 Treinamento organizacional

Este item irá estabelecer a capacidade de treinamento organizacional fornecendo treinamento

necessário aos envolvidos no projeto. O propósito do OT é desenvolver as habilidades e o

conhecimento das pessoas para que elas possam desempenhar seus papéis de forma eficiente e

eficaz.

O gerente de projetos deverá implantar uma estrutura de treinamentos seguindo as seguintes

normas: estabelecer uma capacidade de treinamento organizacional, estabelecer necessidades

estratégicas de treinamento, determinar as necessidades de treinamento de responsabilidade da

organização, estabelecer um plano tático de treinamento organizacional, estabelecer capacidade de

treinamento, fornecer treinamento necessário, realizar os treinamentos, estabelecer registros de

treinamento e avaliar as eficiências dos treinamentos.

12.11- Gerenciamento de riscos

O gerenciamento de riscos é um item que merece destaque e que deve ser observado com

bastante eficiência e detalhado, é um item crítico no negócio, pois ele é quem vai mostrar o quanto é

conveniente o projeto para a empresa.

A gestão dos riscos vai auxiliar em abordagens incluindo um auxilio ao projeto, como:reserva de

recursos para responder a eventos de interrupção, listas de equipamentos apropriados de backup a

serem disponibilizados, pessoas que possam substituir o pessoal – chave, planos e resultados para

46

testar sistemas emergenciais, procedimentos divulgados de emergência e listas divulgadas de

contratos – chave e recursos de informações para emergências.

A gestão de risco neste projeto foi abordada com detalhe no item 5 e seus subitens, pois se trata

de uma gestão muito delicada num projeto.

13 Empreendedorismo

A Software Developer através do uso de normas certificadoras, além de visar o seu

crescimento empresarial com softwares de qualidade e bem estruturado; possui uma visão

empreendedora para a empresa. Ela quer buscar também o empreendedorismo na empresa para

obter competitividade com os concorrentes. É possível observar que o empreendedorismo é tão

importante nas empresas, que uma das funções do gerente de projetos é ser empreendedor. Para

obter um bom desenvolvimento econômico, vai trabalhar basicamente com quatro fatores críticos.

Figura 4 – Fatores críticos da Software Developer

O talento prevê que a empresa necessita de pessoas com habilidade de ser visionária, correr

riscos calculados e trabalhar de forma perseverante. O empreendedor deverá criar uma equipe eficaz

e eficiente, muito bem selecionada, e ainda, possuir a prática de networking.

47

A tecnologia no empreendedorismo deve ser somada através de suas inovações de forma que

haja investimento de capital de risco, infra-estrutura tecnológica, invenções ou inovações e uma

cultura empreendedora com foco no futuro.

O capital é o bem essencial para que o negócio possa sair do papel. O empreendedor utilizará

seu networking para atrair os recursos necessários para a realização do projeto.

O sistema de informação envolve a utilização de ferramentas tecnológicas voltada à

administração e ao desenvolvimento de comercialização de produtos e serviços, a informação agora

passa a ter valor de capital. Com a informação a Software Developer vai obter vantagem competitiva,

adquirindo diferencial de mercado, mas este deve ser utilizado de forma correta para o sucesso

desejado. Na verdade os sistemas de informação precisam ser estratégicos e contribuir para que o

empreendedor possa alcançar os objetivos e metas da Software Developer.

14 O Perfil do empreendedor

A Software Developer, para garantir que haja um resultado eficiente no setor de

empreendedorismo, resolveu implantar em sua empresa algumas diretrizes para que eles possam ser

seguidos.

A empresa exigirá que os empreendedores sigam as seguintes diretrizes: o empreendedor

terá certa independência e oportunidade para criar modelos de softwares novos aos clientes de forma

a aumentar o seu lucro; ele terá a prerrogativa de investir no negócio visando uma sobrevivência de

cinco a dez anos no crescimento de negócio; ele executará as atividades de forma envolvente e

diretamente às pessoas da empresa; ele terá o poder de assumir riscos calculados; vai utilizar meios

de corrigir-se com erros e falhas; ele terá o poder de relacionar-se com outras pessoas através de

transações e acordos como base no relacionamento.

15 A oportunidade

O empreendimento da Software Developer deverá cultivar o relacionamento com seus clientes

chaves, aproximando deles como conselheiros. E assim ocorre uma valorização para desenvolver,

implantar e construir um negócio de sucesso ao redor dessa idéia. O empreendedor precisará ter

48

timing de idéias, ele precisa ter uma visão que busque um ciclo de vida dos softwares mais longos, ou

seja, o empreendedor tem que obter ideais onde o software seja usado de forma mais abrangente.

Para que as idéias e as oportunidades sejam feitas com sucesso, a Software developer

adotará os tipos de análises que devem ser seguidos: será analisado qual o perfil de cliente que

compra e não compram o software, quais os tipos de mercado que é alvo, analisar o retorno de

negócio, as vantagens competitivas desse negócio, caso haja desvantagem verificar o modo como

poderá ser superada, definir uma equipe que transformará a idéia em negócio, comprometimento do

empreendedor com os negócios da empresa.

16 Plano de negócio

É preciso que o empreendedor busque ferramentas de planejamento, pois assim ele pode correr riscos calculados. Para que a empresa estruture seu plano de negócio com eficiência deverá implantar dois fatores críticos a serem considerados: a empresa precisará do planejamento para gerenciar e apresentar novas idéias aos clientes, e, as fontes de investimento exigirão o plano de negócio para avaliar os riscos envolvidos e possibilidades de retorno.

O plano de negócio é um documento formal, usado para descrever o negócio em questão, contendo informações sobre o modelo gerencial que manterá. Por isso, o plano de negócio da Software Developer vai ser estruturado da seguinte forma: capa, nesta parte conterá informações que apresentam o nome da empresa, endereço e contato, nome do autor do plano e data da elaboração; sumário, contém o título de cada seção do plano de negócio e sua paginação; sumário executivo, o sumário executivo tem a função de fazer o leitor ler ou não a proposta; é um resumo que será dirigido ao alto nível gerencial e estratégico da empresa, contendo informações concisas e relevantes do plano; descrição da empresa, nesta seção será descrito a empresa, seu histórico, a evolução nos últimos anos, estrutura organizacional, certificações etc.; produtos e serviços, esta parte irá descrever o produto e serviço em questão, onde serão enfatizados itens como: os recursos necessários para produção, o modo de produção, o ciclo de vida, as tecnologias envolvidas, nível de satisfação do cliente, produção que detenha marcas e patentes, pretensão de futuros investimentos no processo produtivo.

As ferramentas que vão auxiliar o empreendedor na análise mais detalhada nos produtos e serviços da Software Developer serão o SWOT e a matriz BCG; análise da estratégia, nesta parte do documento apresenta a essência de negócio, contendo a missão, visão e valores da empresa, situação atual e potencialidades; plano de marketing, vai descrever a operação desenvolvida para marketing, o preço, o produto, a promoção.

Neste item irá demonstrar como manter o interesse dos clientes e como aumentar a demanda; plano de recurso humanos, nesta parte apresentará a estratégia de preparação e desenvolvimento da equipe do RH, nesta fase será apresentado o nível educacional e experiências da equipe envolvida no negócio, indicando o esforço da empresa na formação do capital intelectual; análise de mercado, deve demonstrar que conhece a segmentação de mercado em referência abordando crescimento do setor, características do consumidor, concorrência, participação de mercado, economia, política, normas, cultura etc.; plano financeiro, esta fase deve planejar todas as projeções futuras, deve ser verificado o valor necessário para viabilizar o projeto, o propósito, o tempo necessário do investimento, retorno previsto, deve conter o demonstrativo de fluxo de caixa, balanço patrimonial, análise do ponto de equilíbrio, necessidades de investimento, demonstrativos de resultados, indicadores financeiros, faturamento previsto, margem prevista e o TIR; conclusão, fazer considerações finais e necessárias para encerrar a proposta; anexos, esta parte será complementado com documentações para comprovação e validação de dados no plano de negócio.

49

17 Intraempreendedorismo

A Software Developer além de ter uma equipe empreendedora, também irá contar com uma sub-equipe direcionada ao intraempreendedorismo. O intraempreendedor da Software developer usará todo seu poder de relacionamento, sua habilidade de realização, sua criatividade para atingir seu objetivo, ele terá um maior comprometimento como qualquer outro funcionário. Este profissional é de grande importância para a empresa, pois ele tem a capacidade de integrar tecnologia do produto e transformá-lo em algo mercadologicamente viável.

A empresa exigirá que esse funcionário saia de dentro empresa, e solicitará ao RH que selecione este funcionário e que tenha as seguintes competências e perfis: habilidade de conhecer e entender o produto e explorá-lo, habilidade de realização e operação organizacionais, habilidade de conhecer os segmentos de mercado e suas tendências, habilidade de influenciar e direcionar subordinados, habilidade de relacionarem-se com pessoas influentes, formadores de opinião e tomadores de decisão, habilidade de planejar estrategicamente, habilidade de reconhecer oportunidades e aproveita-las.

18 Inovação e criatividade

A Software developer preocupada com a concorrência de mercado implantará algumas metas que auxiliará o empreendedor a conquistar oportunidades de negócio com inovações. Ele deverá estar atento aos projetos de implantação, como: desenvolvimento de novos softwares ou serviços sendo uma novidade de mercado, desenvolvimento de um novo software ou serviço com mais qualidade e menor preço, acréscimo a funcionalidade do software com correções de defeitos aumentando a percepção de valor agregado do consumidor, mudança do software que signifique uma nova utilidade, mudanças no segmento de mercado, mudança na forma de entrega do produto, parcerias com fornecedores, mudança no modelo de negócio e mudança nos processos organizacionais reduzindo o tempo nas aprovações dos processos de compras otimizando os recursos.

19 Identificação das oportunidades

Dentro da equipe de empreendedores da Software Developer, será selecionado um funcionário com habilidades de identificar as oportunidades com capacidade de observação. Ele deverá identificar chances no mercado competitivo transformando-os em negócios, este funcionário deverá ter uma diferenciação aos outros para que haja um incentivo por parte dele, já que para identificar a oportunidade depende dele e somente dele. Porém, algumas metas e normas serão indicadas a ele para que possa seguir de forma mais conveniente à empresa, como: deverá encontrar oportunidades nas fontes internas da empresa baseando-se na redução de tempo e custos de um processo, criar vantagem competitiva ao negócio, comunicar a todos os níveis da empresa a voz do cliente e do consumidor dos softwares, estar atento a novas demandas é a melhor forma de aproveitar a oportunidades, os riscos e as oportunidades no ambiente externo deverão ser exemplos para proporcionar excelentes idéias.

50

20- Conclusão

A integração dos modelos de gestão implantados na Software Developer, como CMMI-DEV, NBR ISO/IEC 9126-1 e NBR ISO 9000-3 serão gerenciados de forma estruturada com o objetivo de garantir estas certificações. Assim a empresa poderá ter uma visão de futuro com crescimento de clientes e usuários dos seus softwares, tendo como ferramentas de apoio através do gerente de projetos para auxiliar na gerência desses modelos integrando-os com o planejamento empreendedor e buscando atingir metas.

A Software Developer deve ser capaz de gerir e controlar todo o processo de desenvolvimento e manutenção de softwares, para então conquistar uma gestão eficaz da empresa e o sucesso empresarial.

É importante destacar que se pode gerenciar a qualidade do processo e do produto dos softwares desenvolvidos através de medições e acompanhamento em todo seu processo, obtendo uma eficaz na correção de defeitos de softwares prevenindo-o de problemas futuros ocasionados pela falta de prevenção, e assim se evita softwares com problemas e defeitos na sua produção. Por isso, a Software Developer baseia-se nestas normas, e conta com uma gerência eficaz no nível 2 (gerenciado) completo do CMMI, porém está buscando otimizar ainda mais seus softwares visando atingir o nível 3 do CMMI; a Software Developer conseguiu atingir o gerenciamento e a implantação de quatro PAs do CMMI nível 3, que são: verificação, validação, treinamento organizacional e gerenciamento de riscos. Porém, ela tem como objetivo atingir a gerência das 14 PAs do nível 3 (definido) do CMMI que será o próximo passo de suas metas.

51

21 Referências bibliográficas Microsoft. Um histórico rápido do gerenciamento de projeto. Disponível em: http://office.microsoft.com/pt-br/project/ha011353421046.aspx Alencar, A. J; Schimtz, E. A. Análise de risco em gerência de projetos. 1. ed. Rio de Janeiro, Rio de Janeiro: brasport, 2006. Project Control. Controle de projetos. Disponível em: http://www.projectcontrol.com.br Maximiano, Antonio César Amaru. A. Administração para empreendedores: fundamentos da criação de novos negócios. São Paulo: Pratice Prentice Hall, 2006. Martins 2003. Gestão profissional de projetos. Disponível em: http://www.ietec.com.br/hp2/site/ietec/cursos/detalhes/265 Wikipédia, a enciclopédia livre. Definição e conceitos de empreendedorismo. Disponível em: http://pt.wikipedia.org/wiki/empreendedorismo Wikipédia, a enciclopédia livre. Definição e conceitos do CMMI. Disponível em: http://pt.wikipedia.org/wiki/cmmi CMMI para desenvolvimento. Versão 1.2 em português. CMMI-DEV v1.2. Tradução de André Villas Boas e José Marcos Gonçalves. ABNT – Associação Brasileira de Normas Técnicas. NBR-ISO-9000-3. Normas de Gestão da Qualidade e garantia da Qualidade. Disponível em: http://www.lyfreitas.com/pdf/ISO%209000-3.pdf Capovilla, I. G. G. Elementos intrínsicos do software e sua influência na qualidade do processo de desenvolvimento. São Paulo: dissertação, IMECC, Unicamp, 1999. Guerra, A.C; colombo, R.M.T. Tecnologia da informação: qualidade de produto de software. Brasília; PBQPO software, 2009. http://qualidade-de-software.blogspot.com.br/2010_04_01_archive.html

http://qualidade-de-software.blogspot.com.br/2010_04_01_archive.html

52

22-Glossário

Figura 1– modelo de gestão de riscos da Software Developer ...................... 32

Figura 2 - Ciclo PDCA...................................................................................... 35

Figura 3 – uml call center da Software Developer.............................................35 Figura 4 – Fatores críticos da Software Developer ..........................................46

Pim Vii e Viii 7 Ronald

Documents

Transcript of Pim Vii e Viii 7 Ronald