pim vii e viii 7ana leila ronald

8/20/2019 Pim Vii e Viii 7ana Leila Ronald

1/52

1

UNIVERSIDADE PAULISTACURSO SUPERIOR DE TECNOLOGIA

GESTÃO EM TECNOLOGIA DA INFORMAÇÃO

ANA LEILA ANDRADE DE FARIAS

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/52

2


PIM V

PROJETO INTEGRADO MULTIDISCIPLINARDOCUMENTO DE ESTUDO CONTENDO ANÁLISE DE IMPACTO, PLANEJAMENTO,

DESENVOLVIMENTO E COMO IMPLEMENTAR MELHORAS NOS PROCESSOS DE TI DASOFTWARE 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 emTecnologia da Informação, da Universidade Paulista – UNIP, campus Entroncamento.

Monitora: NATÁLIA MORAES

BELÉM - PARÁ

2014


3/52

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 SoftwareDeveloper. A governança de Ti é de responsabilidade da diretoria e da gerência executiva. Umaimportante e comum preocupação da governança de TI e os objetivos atuais e futuros daorganização. A ISO 9000 é um conjunto de padrões auditáveis de alto nível voltados ao cliente parasistema de gerenciamento de qualidade. O Balanced Scorecard foi desenvolvido por Robert Kaplan eDavid 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/52

4

Abstract

This paper AIMS to study with analysis of impact planning, development and how toimplement improvements in the processes of corporate IT Software Developer. IT governance is theresponsibility of the board and executive management. An important and common concern of ITgovernance and the current and future goals of the organization. ISO 9000 is a set of auditablestandards high level customer focused for quality management system. The Balanced Scorecard wasdeveloped by Robert Kaplan and David Norton in the early 90s, made up a new strategic managementmodel, based on financial and non-financial indicators. linked to organizational strategy .


5/52

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 .......................................................... 122.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/52

6

1- Introdução

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


7/52

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 é deresponsabilidade da Diretoria e Gerência Executiva e que a Governança de TI faz parte daGovernança da Empresa”. A Figura 1 abaixo mostra a ligação entre Governança Corporativa eGovernança de TI, proposta pelo CISR do MIT SloanSchool, onde se percebe que TI é um dos ativoscontrolados pela Governança Corporativa. Na parte superior do modelo, são evidenciados osrelacionamentos entre a diretoria da empresa com acionistas, stakeholders, práticas demonitoramento e de disclosure para compor a GC. Os executivos da empresa, como agentes dadiretoria articulam estratégias e ações para gerar o comportamento desejável que possibilite que asdiretrizes da diretoria sejam concretizadas. Para implementar esta estratégia, é necessária agovernanç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 investiramou investir em projetos ruins? Como os financiadores controlam os gestores? Tais perguntas podemser desdobradas para outras áreas da organização, tornando-se mais específicas e mantendo oalinhamento com a GC.


8/52

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 TIinternos e o gerenciamento das operações de TI no presente. A GTI por sua vez é mais abrangente econcentra-se no desempenho e transformação de TI, para atender demandas atuais e futuras donegócio da corporação (foco interno) e negócio do cliente (foco externo). “Isto não diminui aimportância e complexidade do Gerenciamento de TI, ..., mas enquanto o Gerenciamento de TI efornecimento de serviços de TI e produtos podem ser realizados por um fornecedor externo, aGovernança de TI é específica da organização, e direção e controle sobre TI não podem serdelegados 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ócioe Mitigação dos Riscos de TI. O primeiro item é suportado pelo alinhamento estratégico entre TI e oNegócio. O segundo é suportado pela forma como as responsabilidades na empresa são divididas.


9/52

9

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

Para suportar os focos acima a GTI lida com cinco domínios, todos alinhados comas diretrizes dos stakeholders, dos quais dois são resultados: Valor de TI e Gerenciamento de Riscoe três são direcionadores: Alinhamento Estratégico, Gerenciamento de Recursos e Medidas dePerformance (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/52

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çade 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 Worldde 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 suanecessidade. Nas próximas sessões serão apresentados alguns dos modelos emetodologias 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 - foidesenvolvido na década de 90 pela ISACA - Information System Auditand Control Association - epode ser traduzido como Objetivos de Controle para a Informação e Tecnologia. O COBIT é ummodelo de governança em TI, criado para alinhar os recursos e processos de TI com os objetivos donegó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 a5, conforme tabela 2. São eles:


11/52

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 pelaCentral ComputingandTelecommunicationsAgency para o governo britânico, reunindo um conjunto derecomendações divididas em dois blocos: suporte de serviços (servicesupport), que inclui cincodisciplinas 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 comos clientes internos e externos. O ITIL trata de disciplinas táticas, ou de planejamento, eoperacionais.

2.6 - Seis Sigma

A Qualidade Seis Sigma foi desenvolvida pela Motorola nos anos 80 e é umaforma 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 aeficiê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 (livrede 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 oconhecimento existente sobre gerenciamento de projetos assim como melhorar o desempenho dosprofissionais 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,


12/52

12

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:Integração, Escopo, Tempo, Custo, Qualidade, Recursos Humanos, Comunicação, Análise de Riscoe 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 umgrupo 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 eOtimizado. Os níveis provêm de uma escala crescente para mensurar a maturidade das organizaçõesde 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 dealto 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 ISO9000 tem prestígio global e pode ser aplicada em toda a corporação. Cobre desenvolvimento desoftware, operações e serviços de TI. Porém, requer adaptação considerável quando utilizada emorganizaçõ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écadade 90, constituindo-se num novo modelo de gestão estratégica, baseado em indicadores financeiros enão-financeiros vinculados à estratégia organizacional e divididos em quatro perspectivas deavaliaçã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 daInformaçã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 mudadaspara Contribuição com a Corporação, Orientação para Usuários, Excelência Operacional eOrientação para o Futuro. Haeset al. (2004) cita também que a ligação entre o BSC Corporativo e oBSC da área de TI, conforme Figura 4, é considerado um mecanismo de suporte para a Governançade TI.


13/52

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 pelosChiefInformation Offices (CIOs), pela primeira vez constava: aprimorar a Governança de TI. Ementrevista concedida a Microsoft Business (WEILL[1], 2004) cita que de acordo com pesquisasrealizadas pelo Center for Information Systems Research (CISR), criado há 30 anos naSloanSchoolof Management do Massachusetts Instituteof Technology (MIT), empresas com políticasde 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 aPricewaterhouseCoopers uma pesquisa a respeito de Governança de TI que gerou o relatório: ITGovernance Global Status Report-2006. Esta foi a segunda pesquisa do gênero realizada pelo ITGI, aprimeira foi em 2003. A pesquisa foi realizada em 22 países e todos os continentes foramrepresentados. 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 StatusReport-2006 revelou que a maioria dos usuários de TI estão conscientes dos problemas relacionadosao uso de TI e da necessidade de se desenvolver melhores práticas para lidar com esta questão. Orelatório revelou também que uma parte representativa da comunidade dos usuários de TI reconhecea Governança de TI como uma solução para esses problemas ou como uma prática que deveriamadotar. Da parte do grupo que não reconheceu a Governança de TI como solução para os problemasenvolvidos no uso e administração de TI, cerca de 80% estão adotando ações que podem serclassificadas como Governança de TI. Quase todas as organizações que reconhecem o conceito deGovernança de TI sabem pelo menos o exemplo de um “modelo” ou “solução” de GTI. Em 2005 oCISR do MIT realizou uma pesquisa em 250 empresas do mundo com foco principalmente emanalisar como as empresas tomam decisões relacionadas a TI. Tal pesquisa deu origemposteriormente ao livro: IT Governance: How Top Performers Manage IT DecisionRights for SuperiorResults.

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

Neste trabalho efetuamos um estudo de caso descritivo e exploratório a respeitode Governança de TI. Nossa idéia consiste em verificar estatisticamente a existência de correlaçãoentre 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 apercepçã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/52

14

Consecução de Sistemas, ambas são provenientes do Sistema de BSC de TI da empresa e sãoconsiderados 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 algumasiniciativas tais como i) implementação de um Sistema de Gestão de Qualidade (SGQ), ii) criação eavaliação de indicadores de BalancedScoreCard para TI. O processo de Governança de TI preconizao alinhamento com Plano Estratégico para manter-se alinhado ao negócio. Tal processo utilizapráticas provenientes de metodologias desenvolvidas no Departamento de Informática, e aplicaalgumas práticas inspiradas em metodologias de mercado tais como o PMI (Project ManagementInstitute) e CobiT (ControlObjectives for InformationandRelated Technology).

Embora o processo de consolidação formal da Governança de TI seja recente, o processode 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, ilustradona Figura 5: Divisão de Manutenção e Desenvolvimento de Sistemas de Administração (FIA), Divisãode 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 aDiretoria 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/52

15

Figura 6 – Visão e Missão Departamento de InformáticaFonte: 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 acorrelaçã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” dametodologia “IT Strategy” da IBM GBS. Esta metodologia foi desenvolvida em 1998 pela empresaPriceWaterhouseCoopers 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 numaescala de 1 a 5 a percepção dos analistas de TI, usuários, fornecedores e usuários de TI sobre osdomínios. Estes questionários são posteriormente consolidados de forma a obtermos a percepçãodos respondentes sobre os domínios isoladamente. A média dos domínios é denominada como o


16/52

16

Nível de Governança ou Nível de Maturidade do Modelo de Gestão de TI. Estes questionários em2005 foram respondidos por um número significativo de funcionários, foram 58 gerentes, 52especialistas 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áriosde TI foram entrevistados. No entanto, o número de usuários que responderam ao questionário podeser 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 construtopossui 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/52


18/52

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 maisconsolidados e não tiveram mudanças expressivas de 2003 até 2005. Segue abaixo uma brevedescriçã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 deprazo, aderência e custo conforme planejado. Um projeto é considerado estratégico quando faz partedo 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íveispara uso dos usuários, analistas e desenvolvedores. O indicador mede mensalmente adisponibilidade 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 porterem seu processo de apuração mais consolidado. O ICP e IDS são acompanhados mensalmentedesde 2003.

A tabela 6 abaixo apresenta os valores percentuais mensais do ICP e IDS, desde 2003. Natabela, 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 metamensal do IDS é de 99,30%. Percebe-se pela tabela 6 que apesar das variações, em todos osanosos indicadores ficaram acima da meta.

Da mesma forma a disponibilidade dos sistemas de TI ficou sempre acima da metanos período de 2003 a 2005. Considerando uma disponibil idade de 99,9%, isto implica que umsistema esteve indisponível por 8.7 horas por ano. Cabe ressaltar que este indicador não consideraparadas programadas.

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


19/52

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 dosProjetos de TI.

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

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

A metodologia utilizada para testarmos as hipóteses H0, H1 e H2 foram testesde correlação. Para analisarmos se a hipótese “H0: O Grau de Maturidade do Modelo deGestão de TI influencia positivamente na Consecução do Projetos de TI foi testada a correlaçãoentre 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étricasOperacionais” é -0,99, indicando que não há dependência positiva entre as variáveis. Assim sendo, ahipótese Ho: “O Grau de Maturidade do Modelo de Gestão de TI influencia positivamente nosresultados 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 influenciapositivamente 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 medidoentre 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 deSistemas está sujeita a fatores não necessariamente ligados a Governança de TI, mas especialmenteligados 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/52


21/52


22/52

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/52

23

6-Glossário

Figura 1 – Relacionamento entre Governança Corporativa e Governança de TI........................7Na Tabela 1, citamos a adaptação destas perguntas para a área de TI.................................... 8Figura 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. .............................9Tabela 2: Modelos de processos de maturidade do COBIT..........................................................11Figura 4: Balanced Scorecard em TI.............................................................................................12 Figura 5 – Visão e Missão Departamento de Informática da Software Developer ........................14Figura 6 – Visão e Missão Departamento de Informática............................................................ 15Tabela 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.................................................................17Tabela 6 – Histórico Indicadores Operacionais (IDS e ICP)........................................................18


24/52

24

UNIVERSIDADE PAULISTACURSO SUPERIOR DE TECNOLOGIA

GESTÃO EM TECNOLOGIA DA INFORMAÇÃO


PIM V


DESENVOLVIMENTO E COMO IMPLEMENTAR MELHORAS NOS PROCESSOS DE TI DASOFTWARE DEVELOPER.

BELÉM – PARÁ

2014


25/52

25


PIM V


DESENVOLVIMENTO E COMO IMPLEMENTAR MELHORAS NOS PROCESSOS DE TI DASOFTWARE DEVELOPER

Trabalho do Projeto Integrado Multidisciplinar – PIM VII eVIII, apresentado como exigência para conclusão do 4ºSemestre do Curso Superior de Tecnologia Gestão emTecnologia da Informação, da Universidade Paulista – UNIP, campus Entroncamento.

Monitora: LUANE BARRAL

BELÉM - PARÁ

2014


26/52

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 podefazer 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 nosclientes. Muitas empresas acabam tendo certo medo de investir em empreendedores, mas é precisoque haja um planejamento bem eficiente e controlado para evitar os riscos de negócio. Hoje osprofissionais podem contar com uma grande variedade de ferramentas de apoio na gestão deprojetos para analisar a viabilidade do negócio. As ferramentas de apoio à gestão de projetos complanejamento, as normas e certificações de modelos de gestão e o espírito empreendedor devemcaminhar juntos na empresa para obter o sucesso no mercado competitivo, que está acirrado a cadadia que passa. Além disso, é importante que os profissionais que estão envolvidos no projeto daempresa estejam todos envolvidos com muita dedicação e com bom relacionamentos e comunicaçãocom qualidade, onde todos possam interpretar o objetivo de forma igual para garantir uma linguagempadrão dentro da empresa


27/52

27

Abstract

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


28/52


29/52

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/52


31/52

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. Nestecaso haverá um Gerente de projetos com a função de avaliar o progresso das atividades como aqualidade, custo e prazo, bem como seus desvios e seus riscos. Além disso, o Gerente de projetosdeverá ter certa autoridade sobre sua equipe de projeto.

Para que o projeto da Software Developer tenha sucesso é preciso que haja basicamentealgumas especificações a serem seguidas, que são: metodologia, no caso será adotado nodesenvolvimento 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 softwareseja 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 commais 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 paraatingir 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 ocusto já definido seguido das horas necessárias para o projeto, é preciso ser bem detalhado para quehaja um controle rígido das atividades e seus custos. Dessa forma o Gerente de Projetos terá umescopo sem mudanças garantindo a entrega do projeto ao cliente sem custos adicionais; recursosenvolvidos 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 paraselecionar os melhores profissionais com competência para as tarefas definidas; desenvolvimento docronograma, 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 melhorduração e o responsável por cada atividade, além disso será definido que haja uma revisão docronograma com todo o time para melhor identificar as atividades; riscos, será implantado umagestão de riscos do projeto para identificar os riscos, criando uma lista de fatores de risco e um planopara lidar com eles, assim poderá monitorar os riscos e as ações que deverão ser tomadas paraminimizar seu impacto no projeto, início e fim do projeto, será formalizado o início do projeto com oSponsor através de uma reunião de forma a sinalizar o início das atividades com todos os membrosda equipe, bem como o seu término demonstrando os resultados alcançados, após a finalização doprojeto a Consulting realizará uma reunião com a equipe para identificar os problemas, erros eacertos 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 SoftwareDeveloper.

3- Ferramenta para gestão de projetos

A Software Developer apresenta falhas no controle de criação dos projetos de softwares que sãodesenvolvidos 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 MicrosoftProject.

4 Microsoft Project

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


32/52

32

início e fim de cada atividade, gerando um mapa em forma de gráfico (gráfico de Gantt) comrelacionamentos 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 novosoftware. 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 podeacompanhar o progresso das atividades adicionando uma coluna indicando a porcentagem de cadaatividade concluída, dessa forma o gerente de projeto pode verificar se as atividades serãofinalizadas 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/52

33

5 Gestão dos riscos

Na Software Developer apresenta uma falha no cadastramento dos riscos associados aosprocessos de negócio, dessa forma será preciso implantar um sistema de gestão de riscos para quehaja uma administração de maneira eficiente podendo instalar uma maneira facilitada e previsívelpara 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 umaprevisão dos imprevistos; a análise de riscos, definirá as atividades que visam a identificação dosfatores de riscos, avaliando o impacto e definindo a ações que serão executadas para reduzir oueliminar os riscos.

O processo de gerenciamento de riscos, na verdade, é uma combinação da sua análise e doseu controle, pois para que uma empresa possa desempenhar seus projetos com segurança ecerteza é preciso haver uma gestão de risco muito bem elaborado e estruturada. A figura abaixomostra 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 riscossão identificados e analisados para determinar a importância de cada um deles. Os riscos serãoidentificados e descritos de forma compreensiva antes que sejam analisados e gerenciados. Osriscos serão documentados com textos, condições e conseqüências de sua ocorrência. A s atividadesde identificação de riscos foca somente nos riscos, não na colocação de culpa em alguém, ela nãopode 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 assuntoem foco, revisar os esforços de gestão de risco, examinar documentos ou banco de dados de liçõesaprendidas, examinar especificações de design e requisitos de acordos.


34/52

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 devida do software, revisar todos os elementos da WBS para ajudar a garantir que todos os aspectos doesforço de trabalho foram considerados, documentar o contexto, as condições e as potenciascconsequê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 importantesdo projeto. O plano de mitigação de riscos vai ser utilizado com o objetivo de evitar, reduzir econtrolar a probabilidade de ocorrência do risco, para isso a Software Developer vai implantaralternativas para tratamento dos riscos, como: evitar risco, a mudança ou diminuição de requisitosdurante o levantamento das necessidades do usuário; controlar risco; executar ações para minimizarriscos; 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; aceitarrisco 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 dorisco 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; elaborarum plano geral de mitigação de riscos com planos individuais; elaborar um plano de contingênciapara 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 derisco, o qual será usada ao ser identificado corretamente e logo documentado com todas as


35/52


36/52

36

estruturados e fácil compreensão e assimilação do que se pretende descrever adotará a linguagemUML para os desenvolvedores de software; e, para que esse documento seja controlado com maiseficiência dentro da empresa sua retenção e distribuição será feita através de uma política de controledirecionada 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 é umalinguagem visual para especificar, construir e documentar softwares dos clientes. Ela tem o propósitode modelar para entendimento e documentação dentro de um processo de desenvolvimento. Estalinguagem define vários tipos de modelos que abrangem uma escala de modelos e requisitosfuncionais no fluxo do trabalho para projetos de estrutura de classe e diagramas de componentes, elanão será usada somente para programadores, mas também aos funcionários que estão envolvidos noprojeto.

Para que ela possa ser implantada na empresa, antes será desenvolvido um curso aosfuncioná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 paracontribuir 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/52

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 deprojetos utilizará algumas ferramentas de apoio que darão suporte para uma administração bemestruturada dentro da Software Developer.

As ferramentas de apoio serão: diagrama de pareto, esta ferramenta permite descrevergraficamente a identificação que é responsável pela maior parte dos problemas, após a construçãodeste gráfico, onde temos no eixo vertical são organizadas as quantidades de problemasapresentados em um determinado período, e na horizontal as quantidades de erros de cada tipo deerro em ordem crescente, o percentual de cada tipo de erro e o percentual acumulado ao longo dostipos de erros etc., a partir deste gráfico analisa-se os dados obtidos para uma tomada de decisãopara verificar quais ações deverão ser tomadas e os tipos de erros que terão prioridades nas açõesda Software Developer, assim o administrador do projeto poderá ter um controle dos erros dandosuporte para uma decisão, já que a Software Developer também atua no suporte especializado emincidentes nos ambientes onde seus programas são instalados; diagrama de causa e efeito, estaferramenta identifica causas do problema envolvido de um processo produtivo, quando identificadoeste problemas e colocado como efeito no diagrama são identificados e relacionados, depois sãoidentificados as causas do problema e colocados no diagrama também, assim este diagrama vaiajudar a entender as causas que deram origem ao problema durante o processo de produção dosoftware; lista de verificações, esta l ista é 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 deforma eficiente as listas de verificações; histogramas, o histograma possibilita analisar asconcentrações de comportamento de uma pesquisa dos dados obtidos, classificando os dados emclasses e contagem de quantidade, traçando um retângulo cujas alturas são proporcionais asquantidades, 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 garantirum controle maior nos projetos, desenvolvimento, fornecimento, instalação e manutenção desoftware, visando atingir esta certificação. Ela vai orientar o estabelecimento de sistemas dequalidade nos produtos de software. Esta norma define e conceitua os termos de software produto desoftware e desenvolvimento.

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


38/52

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çõesreferentes à qualidade, os quais devem ser tomadas tanto pelo fornecedor do software (SoftwareDeveloper) como pelo cliente, nas fases do ciclo de vida do software, será implantado uma política dequalidade formal e documentada, divulgada e compreendida por todos os funcionários da SoftwareDeveloper. É preciso que os funcionários tenham responsabilidades e autoridades suficientes paraimplementar as políticas. Será implantado também um grupo de pessoas para verificar, de formaindependente, o uso correto das políticas de qualidade.

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

10.3 Ciclo de vida do software

A Software Developer vai administrar o ciclo de vida do desenvolvimento de software emetapas 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 ea manutenção. O ciclo de vida do software será avaliado em cada atividade, onde serão divididaspara obter um controle e avaliação com eficiência. Análise critica de contrato, a empresa vai adotaritens 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 docomprador, 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 emdesenvolvimento, 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 esuas responsabilidades específicas para cada atividade do projeto. Projeto e implementação, nesta


39/52


40/52

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/52

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 emoutros 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 essacertificação com intuito de integrar com as outras anteriormente definidas, buscando o máximo dequalidade nos softwares desenvolvidos, nos processos e nos atendimentos de suporte ao cliente. Elapretende 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ésdesse modelo, ele é constituído pelas melhores práticas das atividades de desenvolvimento emanutenção indicando como são aplicadas aos produtos e serviços. Esse modelo cobre o ciclo devida do produto desde a concepção até a entrega e manutenção, e ainda a empresa poderá oferecerum software com bons serviços, rápido e barato. Além disso, vai auxiliar nos processos que permitemalinhar com os negócios da empresa, permitindo alavancar recursos e examinar as tendências denegócios de forma mais competitiva.

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


42/52

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 aimplantação do CMMI-DEV na empresa esses problemas serão gerenciados e resolvidos com maisprecisão e eficiência.

Um dos problemas é quando um cliente abre um ticket reportando um problema, o atendenteanota em um caderno e faz uma avaliação pessoal de quanto é crítico o chamado para entãoclassificá-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 osanalistas enviam os pacotes para os ambientes em produção e executam atualizaçõesimediatamente, mas vários problemas nos ambientes de produção dos clientes da SoftwareDeveloper 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émenfrenta problemas com os clientes, pois eles estão reportando que independente do tipo deproblema, não há explicações claras do real motivo da causa raiz e normalmente não é aplicado ascorreçõ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 osrequisitos 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 entrevistase questionários, o qual é bastante eficaz na fazer inicial de obtenção de dados, podendo esclarecerdúvidas dos clientes. É importante que o entrevistador dê margem ao entrevistado para expor suasidéias, é preciso uma relação das pessoas na entrevista e também é importante que o entrevistantetenha capacidade de seguir um plano para a entrevista. O workshop de requisitos consiste numatécnica usada através de uma reunião estrutura, da qual devem fazer parte um grupo de analistas eum 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 deum sistema, através de exemplos práticos descritivos do comportamento de um sistema, os seusutilizadores 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 aencontrar desde cedo falhas que através da comunicação verbal não são tão facilmenteidentificáveis.

12.2 Planejamento de projeto

O planejamento de projeto busca estabelecer estimativas do projeto através das ferramentasque o gerente de projeto utilizará, ele vai elaborar um plano de projeto e obter comprometimento como 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 desua equipe.


43/52

43

O gerente de projeto deverá planejar um projeto com base em alguns itens: determinaralgumas condições para que o projeto seja finalizado ou completado antes que estejamabsolutamente claros quais são os objetivos do projeto; fazer um inventário da maioria do trabalhoque 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 oprazo com precisão, coloca-las fora do caminho crítico e fazer o planejamento separado; criar umcronograma 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 afazer é 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álisefornecendo resultados de medição.

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

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


44/52

44

especificar procedimentos de coleta e armazenamento de dados, especificarem procedimentos deaná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. Valeressaltar que os objetivos e atividades de medições são alinhados com as necessidades e objetivosde 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 umavisão clara sobre os processos e seus produtos de trabalho. Ocorre então, uma avaliação objetivados 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 formaisrealizadas por equipes de garantia da qualidade independentes na organização, revisões por paresque 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ãotreinados e os papéis são atribuídos às pessoas presentes, um membro da revisão por pares que nãoelaborou o software é designado para desempenhar o papel de garantia da qualidade, as listas deverificação são disponibilizadas para dar suporte às atividades QA e os defeitos são registrados comoparte 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 desoftware. Ela vai auxiliar no controle de versão, controle de mudança e auditoria das configurações. Ogerente de projetos deverá atentar para alguns itens: verificar o que mudou e quando mudou, omotivo 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, controlarversõ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 é aatividade que permite saber o motivo de uma configuração ter sido mudada. Ela tem por objetivomapear, 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/52

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/52

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/52


48/52

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 podecorrer 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 paragerenciar e apresentar novas idéias aos clientes, e, as fontes de investimento exigirão o plano denegó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 daSoftware 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, osumário executivo tem a função de fazer o leitor ler ou não a proposta; é um resumo que será dirigidoao alto nível gerencial e estratégico da empresa, contendo informações concisas e relevantes doplano; 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á descrevero produto e serviço em questão, onde serão enfatizados itens como: os recursos necessários paraprodução, o modo de produção, o ciclo de vida, as tecnologias envolvidas, nível de satisfação docliente, produção que detenha marcas e patentes, pretensão de futuros investimentos no processoprodutivo.

As ferramentas que vão auxiliar o empreendedor na análise mais detalhada nos produtos eserviç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 paramarketing, 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 daequipe do RH, nesta fase será apresentado o nível educacional e experiências da equipe envolvidano 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 dosetor, 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 serverificado o valor necessário para viabilizar o projeto, o propósito, o tempo necessário doinvestimento, 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, fazerconsiderações finais e necessárias para encerrar a proposta; anexos, esta parte será complementadocom documentações para comprovação e validação de dados no plano de negócio.


49/52

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 developerusará todo seu poder de relacionamento, sua habilidade de realização, sua criatividade para atingirseu 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 etransformá-lo em algo mercadologicamente viável.

A empresa exigirá que esse funcionário saia de dentro empresa, e solicitará ao RH queselecione este funcionário e que tenha as seguintes competências e perfis: habilidade de conhecer eentender o produto e explorá-lo, habilidade de realização e operação organizacionais, habilidade deconhecer os segmentos de mercado e suas tendências, habilidade de influenciar e direcionarsubordinados, habilidade de relacionarem-se com pessoas influentes, formadores de opinião e

tomadores de decisão, habilidade de planejar estrategicamente, habilidade de reconheceroportunidades e aproveita-las.

18 Inovação e criatividade

A Software developer preocupada com a concorrência de mercado implantará algumas metasque 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 maisqualidade e menor preço, acréscimo a funcionalidade do software com correções de defeitosaumentando a percepção de valor agregado do consumidor, mudança do software que signifique umanova 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 processosorganizacionais reduzindo o tempo nas aprovações dos processos de compras otimizando osrecursos.

19 Identificação das oportunidades

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


50/52


51/52

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 deJaneiro: brasport, 2006. Project Control. Controle de projetos. Disponível em:http://www.projectcontrol.com.br Maximiano, Antonio César Amaru. A. Administração paraempreendedores: 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/265Wikipédia, a enciclopédia livre. Definição e conceitos de empreendedorismo. Disponível em:http://pt.wikipedia.org/wiki/empreendedorismoWikipédia, a enciclopédia livre. Definição e conceitos do CMMI. Disponível em:http://pt.wikipedia.org/wiki/cmmiCMMI 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 daQualidade e garantia da Qualidade. Disponível em: http://www.lyfreitas.com/pdf/ISO%209000-3.pdfCapovilla, I. G. G. Elementos intrínsicos do software e sua influência na qualidade do processo dedesenvolvimento. 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.htmlhttp://qualidade-de-software.blogspot.com.br/2010_04_01_archive.html


52/52

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.............................................35Figura 4 – Fatores críticos da Software Developer ..........................................46

pim vii e viii 7ana leila ronald

Documents