1

UNIVERSIDADE PAULISTA
CURSO SUPERIOR DE TECNOLOGIA
GESTO EM TECNOLOGIA DA INFORMAO

ANTONIO LAERCIO NUNES DE AMORIM JUNIOR

PIM VII
PROJETO INTEGRADO MULTIDISCIPLINAR
SOFTWARE DEVELOPER.

BELM PAR
2014

ANTONIO LAERCIO NUNES DE AMORIM JUNIOR

PIM VII
PROJETO INTEGRADO MULTIDISCIPLINAR
SOFTWARE DEVELOPER

Trabalho do Projeto Integrado Multidisciplinar

PIM VII e VIII, apresentado como exigncia para
concluso do 4 Semestre do Curso Superior de
Tecnologia Gesto em Tecnologia da Informao, da
Universidade Paulista UNIP, campus Entroncamento.
Monitora: LUANE BARRAL

BELM - PAR
2014

3
.

RESUMO

O presente trabalho uma atividade necessria concluso da disciplina Projeto Integrado

Multidisciplinar VII PIM VII, da Universidade Paulista UNIP. Consiste de estudo de caso sobre
uma empresa fictcia, onde deve ser gerada anlise gerencial de processos e ocorrncias no mbito
da rea de Tecnologia da Informao de uma empresa fictcia denominada Software Developer. A
anlise deve se utilizar dos conhecimentos hauridos pelas disciplinas Governana de TI, Gesto da
Qualidade e Sistemas para Internet e Software Livre, gerando propostas de melhorias para os
processos de TI da empresa Software Developer baseados em frameworks como ITIL e COBIT.
Palavras-chave: Governana, Qualidade, Software livre, ITIL, COBIT.

ABSTRACT

This work is an activity necessary to complete the course 'Integrated Multidisciplinary Project
VII - IMP VII, at Universidade Paulista - UNIP. It consists of a case study on a fictitious company. Must
be generated analysis of managerial processes and occurrences within the area of Information
Technology for a fictional company called Software Developer.The analysis should utilize the
knowledge we draw the disciplines of IT Governance, Quality Management and Internet Systems and
Free Software, generating proposals for improvements to the processes of corporate IT Software
Developer based on frameworks such as ITIL and COBIT.
Keywords: Governance, Quality, Free software, ITIL, COBIT.

SUMRIO

RESUMO.................................................................................................................................................4
ABSTRACT.............................................................................................................................................5
1. INTRODUO................................................................................................................................... 6
2. GOVERNANA DE TI........................................................................................................................ 7
2.1 APRESENTAO......................................................................................................................... 7
3. GOVERNANA CORPORATIVA..................................................................................................... 8,9
4. SLA E SLM......................................................................................................................................... 9
5. PLANO ESTRATGICO DE TI - PETI................................................................................................9
6. METODOLOGIA DE GERENCIAMENTO DE PROJETOS................................................................9
7. METODOLOGIA ITIL...........................................................................................................................9
7.1 - CONCEITO................................................................................................................................9,10
8. METODOLOGIA PROPOSTA PARA AVALIAO........................................................................10
8.1 - FUNDAMENTOS..........................................................................................................................10
8.1.2 - CMMI.................................................................................................................................10,11
9. DEFINIO DO PLANEJAMENTO ESTRATGICO DE TI..............................................................11
9.1 - COBIT......................................................................................................................................11,12
9.2 - METODOLOGIA PROPOSTA....................................................................................................12
9.3 - OBTENO DE RESULTADOS.................................................................................................12
9.3.1 - DEFINIR UM PLANO ESTRATGICO DE TI..........................................................................12
9.4 RESULTADOS FINAIS.............................................................................................................12,13
10 - RECOMENDAES...................................................................................................................13
11 - PROCESSO DEFINIDO.............................................................................................................13
12 - DEFINIR ARQUITETURA DA INFORMAO..........................................................................13
12.1 - RECOMENDAES.............................................................................................................13,14
12.2 - DETERMINAR A DIREO TECNOLGICA..........................................................................14
12.2.1 - RECOMENDAES.........................................................................................................14
12.3 - PROCESSO DEFINIDO.........................................................................................................15
13 - GESTO DA QUALIDADE.................................................................................................15,16
14 - ESTUDO DE CASO............................................................................................................16,17
15 - SISTEMAS DE INTERNET E SOFTWARE LIVRE....................................................................17
15.1 - O QUE TORTOISESVN?..................................................................................................17
15.2 - CARACTERSTICAS DO TORTOISESVN.................................................................... 17,18,19
15.3 - LICENA..................................................................................................................................19
15.4 - DESENVOLVIMENTO..............................................................................................................19
16. O INVESTIMENTO EM VOIP..................................................................................................19,20
17. A ADOO DO E-MARKETING..................................................................................................... 20
18. CONCLUSO................................................................................................................................. 21
122.REFERNCIAS BIBLIOGRFICAS...........................................................................................22

1. Introduo.
A empresa Software Developer uma empresa desenvolvedora de software para clientes
de todo o pas e necessita de melhorias em seu processo de desenvolvimento de software para poder
aumentar sua lucratividade e eficincia.
A nossa empresa, Consulting, pretende, com este trabalho, fazer uma anlise de quais e
como sero implementadas as melhorias na empresa, de forma a reduzir custos e encontrar solues
para diversas falhas constatadas pela Consulting e pelos clientes da Software Developer.
Alm de falhas, foram constatadas ausncia de padronizao dos processos na empresa,
falta de um marketing agressivo e desorganizao e falta de educao por parte dos funcionrios.
Tudo isso objeto de anlise neste relatrio de consultoria, que tem o objetivo de transformar a
empresa Software Developer em uma empresa organizada e lucrativa.

7
2. Governana de TI.
2.1 Apresentao.

Nesta fase apresentada a Governana de TI, suas definies segundo os principais

autores e as vantagens alcanadas com sua adoo. Logo em seguida so apresentados os
conceitos de Governana Corporativa e o modo com que a mesma agrega valores empresa.
Aps a explanao dos conceitos, so apresentadas as principais ferramentas e tcnicas para
a governana de TI, que compem o Framework de Governana de TI. Na ltima parte deste
referencial terico, abordado o COBIT e suas funcionalidades e moldes e a metodologia de
GAP Analysis.
Um nmero significativo de empresas vem adotando alguns dos modelos de gesto
no mercado, procurando obter sucesso na administrao e no alinhamento com a rea de TI,
pois realizam um grande investimento em TI, esperando obter vantagens e,
consequentemente, lucros.
Conforme a ISACA (2000), a Governana de TI uma estrutura de relacionamentos e
processos para dirigir e controlar a empresa a fim de alcanar os seus objetivos pela adio de
valor, ao mesmo tempo em que equilibra riscos x retorno sobre TI e seus processos.
A Governana de TI essencial para garantir melhorias eficazes e eficientes nos
processos da empresa. Ela fornece uma estrutura que liga os processos de TI, os recursos de
TI e as informaes s estratgias e objetivos da empresa, contudo, compor uma governana
de TI significa assegurar que as informaes da empresa e a tecnologia aplicada suportam os
objetivos do negcio, permitindo, dessa forma, que a empresa absorva total proveito das
informaes, maximizando benefcios, capitalizando em oportunidades e adquirindo vantagem
competitiva.
Encontramos ainda outras definies como: um sistema formado por regras,
processos e estruturas que busca garantir efetividade nas tomadas de deciso relacionadas a
TI (ROSSI, 2004) e uma estrutura de relaes e processos que dirige e controla uma
organizao a fim de atingir seu objetivo de adicionar valor ao negcio, atravs do
gerenciamento balanceado dos riscos com o retorno sob os investimentos (ROI) em TI
(FAGUNDES, 2004). Dessa forma, h uma busca pelos papis e responsabilidades oriundas
do CIO, definio de processos, controle de riscos de negcios, identificao de uma cadeia de
valor, alinhamento com as estratgias e os mecanismos que permitem realizar e controlar o
sistema. Esses fatores podem levar obteno no apenas de vantagem competitiva, mas
tambm:
Maior agilidade e capacidade para novos modelos de negcios e/ou ajustes em modelos
j em vigor.
Explicitao na relao entre custos de TI e valor da informao.
Explicitao da importncia da rea de TI na continuidade do negcio.
Medio e melhoria contnua da performance de TI.
Viabilizao de acompanhamento de contratos internos e externos.
Definio de condies para o exerccio eficaz da gesto com base em
conceitos consolidados de qualidade (BRODBECK, 2004).
3. Governana Corporativa.

8
Desde os anos 90, a governana corporativa vem ganhando espao, que pode ser
definida de modo simplrio como uma nova forma de organizar as relaes entre a empresa e
o mercado.
Segundo o Instituto Brasileiro de Governana Corporativa (IBGC, 2003), a governana
corporativa o sistema pelo qual as sociedades so dirigidas e monitoradas, envolvendo os
relacionamentos entre Acionistas/Cotistas, Conselho de Administrao, Diretoria, Auditoria
Independente e Conselho Fiscal. As boas prticas de governana corporativa tm a finalidade
de aumentar o valor da sociedade, facilitar seu acesso ao capital e contribuir para a sua
perenidade.
De forma anloga, temos que a governana corporativa o sistema pelo qual se
exerce e monitora o controle das corporaes. Est claro, desde logo, que este sistema est
intimamente vinculado estrutura de propriedade, s caractersticas do sistema financeiro,
densidade e profundidade dos mercados de capitais e ao arcabouo legal de cada economia
(RABELO e SILVEIRA, 1994).
A expresso Governana designada para abranger os assuntos relativos ao poder
de controle e direo de uma empresa, bem como as diferentes formas e esferas de seu
exerccio e os diversos interesses que, de alguma forma, esto ligados vida das sociedades
comerciais.
Governana corporativa valor, apesar de, por si s, no cri-lo. Isto somente ocorre
quando, ao lado de uma boa governana, temos tambm um negcio de qualidade, lucrativo e
bem administrado. Neste caso, a boa governana permitir uma administrao ainda melhor,
em benefcio de todos os acionistas e daqueles que lidam com a empresa.
Podemos encarar a necessidade da governana sob o ponto de vista de Oliveira
(2005), em que os objetivos do titular de uma propriedade nem sempre esto alinhados com os
interesses dos administradores desta propriedade. Deste modo, surge a necessidade de
mecanismos de monitoramento e incentivo para garantir que o comportamento executivo esteja
alinhado com os o interesse dos acionistas.
As caractersticas tendem a ser modificadas de acordo com o meio no qual est
inserida. O Estado, atravs da definio dos sistemas financeiro e legal, modela a formao do
mercado de capitais local e do grau de proteo dos investidores, influenciando o modelo de
governana das empresas. Desta forma, os pases apresentam diferenas significativas entre
os sistemas de governana corporativa das suas empresas (SILVEIRA, 2002).
No Brasil, o IBGC prope um Cdigo de Melhores Prticas de Governana
Corporativa, em que est definida uma srie de objetivos e princpios para guiar as empresas
sobre seus passos na governana corporativa, tendo por objetivo:
Melhorar seu desempenho.
Aumentar o valor da sociedade.
Contribuir para sua perenidade.
Facilitar seu acesso ao capital a custos mais baixos.
Destacam-se entre os princpios do cdigo:
Transparncia: para agregar um clima de confiana nas relaes com terceiros
necessrio alm de informar, ter a vontade de informar no apenas os resultados financeiros,
mas tambm os demais fatores que levam criao de valor.
Equidade: eliminao de toda e qualquer diferenciao entre os grupos, Sejam eles
majoritrios ou minoritrios, a fim de estabelecer uma relao justa.

9
Prestao de Contas: prestao de contas de todos os atos praticados durante o
exerccio do mandato.
Responsabilidade Corporativa: mais do que uma viso estratgica, uma integrao
dos valores sociais e ambientais visando continuidade e sustentabilidade da empresa.
4. SLA.
SLA - Um Acordo de Nvel de Servio (ANS ou SLA, do ingls Service Level
Agreement) a parte contratual de servios entre duas ou mais entidades no qual o nvel da
prestao de servio definido formalmente. Na prtica, o termo usado no contexto de tempo
de entregas de um servio ou de um desempenho especfico. Um contrato do tipo SLA inclui: a
definio dos servios, performance, gerenciamento de problemas, responsabilidade de ambas
as partes, garantias, medidas emergenciais, planos alternativos, planos para solues
temporrias, relatrios de monitoramento, segurana, confiana e cancelamento do contrato.
Em fim acredita-se que a metodologia adotada pode trazer uma transformao na
prestao de Nvel de Servios (ANS), permite que a empresa contratante e contratada
acordem sobre quais os servios devem ser fornecidos dentro dos prazos pr-estabelecidos e
o custo determinado a esse servio de suporte.
5. Plano estratgico DE TI PETI.
Para garantir e suportar um crescimento anual esperado, uma forte estratgia de
internacionalizao e expanso, nossa empresa, identificou a necessidade de efetuar melhores
planejamentos de suas aes e investimentos em TI. Visando isto, a Developer iniciou a
estruturao do PETI. Ele tem como objetivo nortear as estratgias e aes da TI em total
sintonia com o planejamento estratgico da organizao viabilizando aes de crescimento,
expanso com novos negcios e internacionalizao da empresa.
Inicialmente o PETI foi elaborado em 2001 e por se tratar de um processo contnuo,
passa por revises a cada dois anos, sempre com viso estratgica de cinco anos. A ltima
reviso realizou-se no final de 2005 e teve como viso estratgica de futuro o ano 2010. A
necessidade de avaliar os processos internos de TI com relao ao COBIT foi uma das aes
identificadas atravs deste processo.
6. Metodologia de gerenciamento de projetos.
No departamento de TI da Software Developer, as atividades so tratadas como
projetos que, por sua vez, so gerenciados atravs de uma metodologia baseada nas reas de
conhecimento do PMBOK. Seguindo esta metodologia, para a elaborao do estudo, foi
necessrio definir e documentar um Plano de Projeto contendo os seguintes itens: prazo, custo,
escopo, comunicao, riscos, recursos envolvidos, aquisies, qualidade e responsabilidades.
Com base na metodologia de gerenciamento de projetos implantada na Software
Developer, as etapas para o desenvolvimento do trabalho foram planejadas e detalhadas em
uma Estrutura de Documentao do Trabalho (EDT).
7. Metodologia ITIL.
7.1 Conceito:
ITIL definida como sendo uma biblioteca personalizada de melhores
prticas para implementar os processos de gesto de TI. Trata-se de um conjunto de
documentos que definem os processos a serem implementados para os servios de suporte e
de disponibilidade de forma a atingir uma gesto eficaz de servio de TI de acordo com o
negcio a que se destina. Cada mdulo da biblioteca fornece um cdigo de prtica para
melhorar a eficcia das TI, reduzindo custos e aumentando a eficcia e a qualidade de gesto
e de infraestrutura dos servios de TI. Esta gesto de servios uma abordagem orientada ao

10
negcio para a gesto das TI que considera o valor estratgico do negcio pela organizao TI
e a necessidade de disponibilizar uma elevada qualidade de servio TI. A adoo de ITIL
fornece, hoje em dia, documentao consistente e compreensiva de melhores prticas na
gesto de servios de TI. ITIL consiste num conjunto de livros que fornecem conselhos e
orientao para obter qualidade dos servios de TI e para acomodao e ambientao de
necessidades para suportar as TI. No s apresenta um modelo de como as atividades de
gesto de servios interagem umas com as outras, como tambm apresenta uma forma flexvel
de integrar e estruturar processos existentes.
8. Metodologia proposta para avaliao.
8.1 Fundamentos:
8.1.2 CMMI
O CMMI Capability Mature Model Integration, particularmente a CMMI-DEV, consiste
de um framework que visa a ampliao de maturidade de processos de desenvolvimento, tendo
como benefcios a reduo de custos, atendimento de prazos, melhoria na produtividade,
aumento da qualidade dos produtos e do retorno sobre investimentos.
De acordo como Software Engineering Institute, existem trs dimenses sobre as
quais uma organizao necessita atuar para melhoria de seu negcio: pessoas, processos e
tecnologia.
Estrutura-se em cinco nveis crescentes de maturidade os quais so aplicados sobre
os processos de uma organizao. Cada nvel entendido como um estgio para melhoria de
processos organizacionais.
Em linhas gerais, os nveis de maturidade possuem as seguintes caractersticas:
* Nvel 1 Inicial: Caracteriza-se pela existncia processos isolados e caticos, sem um
ambiente estvel e capaz de reproduzir sucessos;
* Nvel 2 Gerenciado: Caracteriza-se pela predominncia de processos que so planejados
de acordo com polticas estabelecidas, so monitorados, controlados e revistos;
* Nvel 3 Definido: Caracteriza-se pela caracterizao e compreenso dos processos. Neste
nvel de maturidade as polticas so customizadas e consistem de padres para toda a
organizao e no apanas para processos isolados;
* Nvel 4 Quantitativamente gerenciado: Caracteriza-se pelo estabelecimento de
indicadores, objetivos de qualidade, nveis de servio baseados nas necessidades dos clientes;
* Nvel 5 Otimizado: Caracteriza-se pela melhoria contnua dos processos, otimizando sua
performance e inovando seus processos, mtodos e tecnologia.
Dentre as ferramentas disponibilizadas para a aplicao do COBIT encontra-se o
COBIT Management Guidelines que prov um modelo de maturidade, semelhante ao CMMI,
com nveis de zero (No existente) a cinco (Otimizado) onde, em cada nvel, existe uma
descrio de como devem estar dispostos os processos para alcan-los. Alm disso, este
modelo pode ser utilizado como uma lista de checagem (checklist) para identificar melhorias
nos processos de TI existentes na organizao. Os seis nveis de maturidade com suas
descries genricas so (ITGI, 2005):
Nvel zero: Inexistente - Ausncia total de processos identificveis. A organizao no
reconhece que h um aspecto a ser tratado.
Nvel um: Inicial - H evidncias de que a organizao reconhece que o aspecto existe e
deve ser considerado. Entretanto, no h processos padronizados, apenas abordagens
eventuais que tendem a ser aplicadas de forma isolada ou caso a caso.

11
Nvel dois: Repetvel - Os processos foram desenvolvidos at o estgio em que
procedimentos similares so adotados por pessoas distintas que realizam a mesma tarefa. No
h treinamento ou divulgao formal de procedimentos padronizados e as responsabilidades
so deixadas a cargo das pessoas. H um alto grau de confiana no conhecimento pessoal e
conseqente tendncia a erros.
Nvel trs: Definido - Os procedimentos foram padronizados e documentados, bem como
divulgados atravs de treinamento. Contudo, cabe s pessoas seguir tais processos, sendo
pouco provvel que desvios sejam detectados. Os procedimentos em si no so sofisticados,
consistindo na formalizao de prticas existentes.
Nvel quatro: Gerenciado - possvel monitorar e mensurar a conformidade dos
procedimentos, bem como adotar medidas quando os processos aparentarem no funcionar
efetivamente. Os processos esto sob constante melhoria e propiciam boas prticas.
Automao e ferramentas so utilizadas de forma limitada.
Nvel cinco: Otimizado - Os processos foram refinados ao nvel de melhores prticas, com
base nos resultados de melhorias contnuas e modelagem da maturidade com outras
organizaes.
Com base nos nveis descritos, o COBIT prope um modelo de maturidade especfico
para cada um dos 34 processos. No Anexo A, apresentado o modelo de maturidade
especfico para o processo PO1 Definir um plano estratgico de TI.
Geralmente, estes nveis de maturidade so utilizados para uma organizao definir
rapidamente, com base nos cenrios descritos, em que nvel se encontra e em que nvel
pretende chegar futuramente. Na maior parte das vezes, a aplicao deste modelo feita
atravs de reunies com os gestores, onde se pede que estes identifiquem o nvel atual e o
desejado dos processos. Entretanto, entendeu-se que, por esse modelo, a anlise muito
genrica e baseia-se apenas na intuio das pessoas, nem sempre especialistas dos
respectivos processos.
Outra limitao, que este modelo estritamente incremental, ou seja, para
determinar em qual nvel a empresa se encontra, deve-se atender a todos os requisitos
daquele nvel e tambm os requisitos dos nveis anteriores. Dessa forma, iniciativas em nveis
posteriores ao encontrado so difceis de serem identificadas.
9. Definio do planejamento estratgico de TI
9.1 COBIT
A necessidade de um Planejamento estratgico de TI conhecida pela gerncia
estratgico de TI conhecida pela gerncia de TI. O Planejamento de TI executado em de TI.
Resposta a uma exigncia especfica do - O Planejamento de TI executado em
negcio. O Planejamento estratgico de TI resposta a uma exigncia especfica do
ocasionalmente discutido nas reunies do negcio..
No seguindo a estratgia da organizao. O alinhamento das exigncias do negcio,
posio de risco estratgico identificada as aplicaes e a tecnologia tratada informalmente,
projeto por projeto. De forma reativa e no seguindo a estratgia da organizao.
A posio de risco estratgico identificada informalmente, projeto por projeto.

9.2 Metodologia proposta

Para o desenvolvimento da Metodologia de Avaliao de Maturidade utilizada no
trabalho, adotou-se o COBIT Management Guidelines com a abordagem proposta, pois se

12
acredita que avaliando cada sentena, independente do nvel de maturidade, no final se obtm
um resultado mais fiel realidade. Alm disso, pde-se identificar que a compreenso dos
envolvidos foi facilitada, haja vista que estes deram suas opinies com relao a pequenas
sentenas e no a um cenrio nico e complexo.
Em relao s limitaes encontradas no modelo oficial, relativos dificuldade de
identificar requisitos cumpridos em nveis posteriores ao encontrado, alem de identificar o nvel
oficial, foi criado o valor Conformidade, que leva em considerao apenas o nmero de
requisitos atendidos e o nmero de sentenas existentes em cada processo. Este valor permite
identificar com maior facilidade o nmero de requisitos atendidos para cada processo.
Seguem, apresentados os passos utilizados no trabalho de avaliao de maturidade
dos processos da Software Developer. Para realizar o mapeamento do nvel de maturidade na
Software Developer, foram marcadas entrevistas com trs ou quatro especialistas em cada um
dos processos mapeados.
No incio, a folha de entrevista, vide Apndice A, era entregue aos presentes, e faziase uma pequena explicao do COBIT e de sua importncia. Em seguida, explicava-se o
processo a ser mapeado e uma breve discusso era feita, para que possveis dvidas fossem
sanadas e houvesse um alinhamento do contedo do processo.
Em seguida, as sentenas extradas do modelo de maturidade COBIT eram expostas
conforme explicado anteriormente. Aps lida cada sentena, os entrevistados respondiam em
consenso se a mesma era verdadeira ou falsa para a situao atual da DEVELOPER.
Depois de efetuado o mapeamento de todas as sentenas do processo, o nvel
alcanado era revelado e discutido, sanando eventuais dvidas e deixando claro o
entendimento sobre o nvel de maturidade alcanado. Com base no nvel alcanado, os
entrevistados apontavam o nvel desejado para o ano 2010. Este ano foi utilizado em
alinhamento com o Planejamento Estratgico de TI da Software Developer que considera o
mesmo como cenrio futuro.
9.3 Obteno de resultados.
A seguir, so apresentados os resultados obtidos na avaliao dos processos de TI da
Developer para os processos do domnio Planejamento e Organizao. Os resultados foram
formatados atravs de um modelo de relatrio padro.
9.3.1 Definir um plano estratgico de TI.
O planejamento estratgico de TI (PETI) necessrio para gerenciar e direcionar os
recursos de TI de acordo com a estratgia e as prioridades do negcio. Os stakeholders da TI e
do negcio so responsveis por assegurar que o retorno sobre o investimento nos projetos e
servios seja timo.
O plano estratgico deve melhorar a compreenso dos stakeholders sobre as
oportunidades e limitaes da TI, deve tambm avaliar o desempenho atual e esclarecer o
nvel de investimento necessrio a TI. A estratgia e as prioridades do negcio devem ser
refletidas nos portflios e devem ser executadas pelo plano ttico de TI, que estabelece
objetivos concisos, planos e tarefas compreendidas e aceitas pelo negcio e pela TI.
9.4 Resultados finais.
Nvel Atual Valor oficial. Nvel mais elevado a ter 100% dos requisitos atendidos pela
Software Developer.
Nvel Meta - Nvel desejado para a Software Developer o Cenrio Software Developer
2011. Conformidade Software Developer - Valor no oficial. Representa a aderncia da
Software Developer aos requisitos do COBIT 48% para este processo, observando cada nvel
de maturidade.

13
10. Recomendaes:
Formalizar o processo de avaliao de riscos e benefcios estratgicos no PETI.
Estabelecer um processo de comunicao do PETI com os gestores do negcio.
Estabelecer um processo formal que defina quando e como elaborar e executar o
PETI.
Definir indicadores que permitam aos gestores do negcio monitorar o andamento e a
eficcia do PETI e como tambm tomar decises baseados nele.
Elevar o PETI a uma funo administrativa, sendo de responsabilidade da Diretoria.
Fazer com que ambos os planejamentos, de curto e longo prazo, ocorram e sejam
profundamente seguidos na organizao.
Incluir o PETI na pauta das reunies de Diretoria.
Considerar, na elaborao do PETI, o planejamento dos recursos internos e externos
requeridos no desenvolvimento e operao dos sistemas.
11. Processo definido:
Uma poltica define quando e como executar o planejamento estratgico de TI.
Entretanto, a deciso a respeito de como ser a execuo destes processos deixada
aos gerentes e no h nenhum procedimento para examinar este processo de execuo.
A estratgia de TI inclui uma definio consistente dos riscos a que a organizao est
disposta a correr como inovadora ou seguidora.
O Planejamento estratgico de TI discutido em reunies da gerncia de negcio.
12. Definir a arquitetura da informao
Os sistemas de informao devem criar e atualizar continuamente um modelo de
informao do negcio como tambm definir os sistemas apropriados para otimizar o uso
destas informaes. Isto abrange o desenvolvimento de um dicionrio corporativo dos dados
com as regras de sintaxe dos dados da organizao, o esquema de classificao e os nveis de
segurana dos dados. Este processo melhora a qualidade das decises da gerncia ao
assegurar que as informaes fornecidas so de confiana e seguras, alm de permitir a
racionalizao dos recursos dos Sistemas de Informao para ser compatvel com as
estratgias de negcio. Este processo tambm necessrio para definir as responsabilidades
sobre a integridade e a segurana dos dados e assegurar o controle sobre o compartilhamento
das informaes atravs das aplicaes.
12.1 Recomendaes
Formalizar o processo de desenvolvimento e validao da arquitetura da informao
atravs de mtodos e tcnicas formais.
Comunicar de forma consistente a necessidade e a importncia da arquitetura da
informao para a organizao.
Direcionar as definies sobre a arquitetura no s para os dados, mas tambm para
as informaes.
Definir, documentar e aplicar consistentemente um processo de treinamento sobre
arquitetura da informao.

14
Atribuir formalmente as responsabilidades sobre a entrega e o desempenho da
arquitetura da informao.
Gerenciar a conformidade da arquitetura com relao a polticas, padres e
ferramentas.
Definir mtricas e implantar um sistema para gerenciar o desempenho da arquitetura
da informao.
Focar o processo de arquitetura da informao para identificar pr - ativamente
oportunidades futuras para o negcio.
Implementar modelos de dados mais complexos para levantar as informaes
contidas nas bases de dados.
12.2 Determinar a direo tecnolgica
Os servios de informao devem determinar a direo tecnolgica para suportar o
negcio.
Isto requer a criao de um plano de infraestrutura tecnolgica e de uma gerncia de
arquitetura que ajuste e controle, clara e realisticamente, as expectativas de o que a tecnologia
pode oferecer em termos de produtos, servios e mecanismos de entrega. O plano deve ser
atualizado regularmente e abranger aspectos tais como a arquitetura dos sistemas, a direo
tecnolgica, os planos de aquisio, os padres, as estratgias de migrao e contingncia.
Isto permite respostas oportunas s mudanas no ambiente competitivo, nas economias com
relao equipe e em investimentos bem como na melhoria da interoperabilidade das
plataformas e das aplicaes.
12.2.1 Recomendaes
Formalizar o processo de avaliao, desenvolvimento e implantao de novas
tecnologias.
Estruturar um processo de avaliao e comunicao do impacto potencial das
mudanas tecnolgicas e das novas tecnologias ao negcio.
Definir um plano tecnolgico bem documentado que vise alinhar o uso das novas
tecnologias com as necessidades do negcio, alm de comunic-lo e aplic-lo
consistentemente.
O plano deve incluir uma compreenso de onde a organizao pretende chegar com o
uso da tecnologia, baseado em riscos e em alinhamento com a estratgia da organizao.
Alm disso, deve ser preparado para mudanas.
Definir indicadores para identificar desvios e antecipar problemas no plano.
Fornecer treinamento e comunicao formal sobre os papis e responsabilidades do
processo.
Analisar o nvel aceitvel de risco a respeito do uso da tecnologia para desenvolver
novas oportunidades de negcio como tambm melhorias operacionais.
Alinhar a estratgia de recursos humanos com a direo tecnolgica para assegurar
que o pessoal de TI pode controlar mudanas tecnolgicas.
12.3 Processo definido:
Existe um plano de infraestrutura tecnolgico bem documentado e comunicado, mas
este aplicado inconsistentemente.

15
A direo da infraestrutura tecnolgica inclui uma compreenso de onde a
organizao pretende chegar com o uso da tecnologia, baseado em riscos e em alinhamento
com a estratgia da organizao.
Existem treinamento e comunicao formal dos papis e das responsabilidades.
O impacto potencial de tecnologias emergentes e em constantes mudanas levado
em considerao.
A gerncia pode identificar desvios no plano e antecipar problemas.
A responsabilidade para o desenvolvimento e a manuteno de um plano de
infraestrutura tecnolgica foi atribuda.
O processo de desenvolvimento do plano de infraestrutura tecnolgico sofisticado e
preparado para mudanas.
As boas prticas internas foram introduzidas ao processo.
A estratgia de recursos humanos alinhada com a direo tecnolgica, para
assegurar-se de que o pessoal de TI pode controlar mudanas na tecnologia.
Planos de migrao para introduzir novas tecnologias so definidos.
A gerncia analisou o nvel aceitvel de risco a respeito do uso da tecnologia para
desenvolver novas oportunidades de negcio como tambm melhorias operacionais.
13. Gesto da qualidade
Apesar dos conceitos de qualidade serem originados em sculos anteriores, o
enfoque a ser dado neste trabalho, visando a consultoria Software Developer se concentra
nas teorias desenvolvidas no sculo XX, sobretudo no desenvolvimento de um sistema de
Gesto da Qualidade Total alinhado a um planejamento estratgico corporativo e com o foco no
cliente.
A escolha pelo enfoque oriundo da adoo de um Sistema de Gesto da Qualidade
Total, em contraponto gerncia tradicional da qualidade deve-se consonncia desta com a
aplicao dos demais frameworks apresentados at ento.
Longo (1996), resume as principais causas de desempenhos negativos de
corporaes e que so amplamente tratados pela qualidade total.
A competitividade e o desempenho das organizaes so afetados negativamente em
termos de qualidade e produtividade por uma srie de motivos. Dentre eles destacam-se: a)
deficincias na capacitao dos recursos humanos; b) modelos gerenciais ultrapassados, que
no geram motivao; c) tomada de decises que no so sustentadas adequadamente por
fatos e dados; e d) posturas e atitudes que no induzem melhoria contnua.
Um sistema de Gesto da Qualidade Total possui enfoque voltado a processos e
deve estar alinhado s metas da organizao, assim como tambm preconiza o COBIT e ITIL e
a Governana de TI. Ocasiona uma mudana profunda na organizao de uma corporao,
voltando o foco de sua atuao para o cliente, o monitoramento por meio de indicadores. Exige
comprometimento para uma melhoria contnua atravs de uma gesto participativa em todos os
nveis da organizao, bem como a capacitao continuada com enfoque nas competncias
necessrias ao bom desempenho dos processos.
A partir dos conceitos oriundos da Qualidade Total, sero utilizadas ferramentas que
permitam a anlise dos processos da Software Developer para adoo de mudanas. Tais

16
ferramentas tem por objetivo facilitar a visualizao e entendimento de problemas, sintetizar o
conhecimento e as concluses e fornecer elementos para o monitoramento dos processos.
Dentre as ferramentas da qualidade, observaremos a utilizao de:
* Histogramas
* Diagramas de disperso
* Diagrama de casa-efeito (diagrama de Ishikawa);
* Diagrama de Pareto
* Fluxogramas
14. Estudo de caso
A consultoria desenvolvida consiste na anlise de situaes detectadas pela
CONSULTING durante o perodo de julho a setembro de 2011. Durante este perodo, foram
analisados processos e realizadas entrevistas com as equipes dos diversos departamentos da
SOFTWARE DEVELOPER, onde puderam ser identificadas oportunidades de melhoria nos
processos relativos rea de Tecnologia da Informao e ao quadro de pessoal.
O enfoque das anlises visa mitigar possveis falhas nos processos, bem como
apresentar proposta de planejamento, desenvolvimento e de implementao de melhorias nos
processos de TI da Software Developer.
Considerando-se a deciso da Software Developer em consolidar sua atuao no
mercado, torna-se imprescindvel a anlise de trs pilares dos servios prestados por esta
empresa: pessoas, processos e tecnologias.
A anlise realizada, bem como as informaes prestadas considera a avaliao de
recursos e procedimentos disponveis nestes trs segmentos, e sugere aes que permitam
sua evoluo, estabelecendo capacidade adequada de gesto e operao da infraestrutura e
dos processos, possibilitando otimizar a prestao de servios a seus clientes.
Sob este aspecto, evidenciou-se a necessidade de constncia e eficcia nos
treinamentos para obteno de resultados positivos. O comprometimento das pessoas pde
ser verificado pela eficcia das aes de treinamento, e influenciou os prprios resultados de
melhoria percebeu-se que o treinamento teve influncia na melhoria de qualidade da Software
Developer.
Uma outra referncia importante para avaliao do nvel de qualidade da empresa,
a pesquisa de satisfao dos clientes. Periodicamente a empresa efetuou pesquisas de
satisfao dos clientes, por meio de questionrios padronizados que permitiram a quantificao
da satisfao ou da insatisfao. Com o intuito de obter maior abrangncia de resposta dos
clientes, a empresa sempre insistiu em ter retorno dos questionrios, evitando-se assim a
omisso de qualquer cliente eventualmente insatisfeito.
Diante do exposto, conclui-se que a iniciativa exgena de implementao dos
sistemas de gesto da qualidade pode dificultar o comprometimento das pessoas dentro da
organizao e a implementao dos sistemas de gesto da qualidade pode encontrar
dificuldades devido a possveis mudanas de cultura e resistncia dos funcionrios. A
certificao dos sistemas de gesto da qualidade traz benefcios diversos, mas no
necessariamente aumento da qualidade.

17
No caso da Software Developer, o comprometimento das pessoas pde ser
verificado pela eficcia das aes de treinamento e o treinamento teve influncia na melhoria
de qualidade da empresa.
Acrescente-se tambm que a implementao do sistema de gesto da qualidade e
sua certificao contriburam para a melhoria da qualidade, evidenciada pela diminuio dos
ndices de no conformidades , com melhoria na satisfao dos clientes, como decorrncia da
melhoria na qualidade no mbito da empresa.
15. Sistemas de internet e software livres
A empresa Consulting sugere a Software Developer para suprir as falhas e
necessidades como: Controle de criao, edio e verso dos documentos; Cadastramento
dos riscos associados aos processos de negcios e armazenar os desenhos de processo;
Gerenciamento dos documentos e controle dos perodos de reteno e distribuio, o uso da
ferramenta apresentada a seguir:
Controle de verso a arte de administrar as mudanas das informaes. Isto uma
ferramenta crtica para programadores, que normalmente gastam horas fazendo pequenas
modificaes em seus aplicativos e ento desfazem ou verificam algumas dessas modificaes
no dia seguinte. Imagine uma equipe de vrios desenvolvedores trabalhando juntos - e talvez
simultaneamente em mesmos arquivos! - e voc precisa ver porque um bom controle
necessrio para controlar uma possvel desordem.
15.1. O que o Tortoise SVN?
TortoiseSVN um cliente do Subversion para Microsoft Windows. Com cdigo aberto,
est licenciado sob GNU General Public License.
Entre suas funcionalidades esto integrao com o Windows Shell, independncia de
ambiente de desenvolvimento integrado, 34 lnguas disponveis e suporte a diferenciao e
fuso de arquivos de aplicativos de escritrio como Microsoft Word.
Alguns sistemas de controle de verso tambm so um aplicativo de gerenciamento
de configurao (SCM). Esses sistemas so especificamente adaptados para controlar
estruturas de cdigo fonte, e tem muitas caractersticas de um aplicativo especfico de
desenvolvimento - como um aplicativo para uma linguagem de programao especfica, or
fornecendo ferramentas de construo de software. Subversion, entretanto, no um desses
sistemas; um sistema genrico que pode ser usado para administrar qualquer conjunto de
arquivos, incluindo cdigo fonte.
15.2 Caractersticas do TortoiseSVN
O que faz do TortoiseSVN um bom aplicativo cliente para Subversion? Aqui est uma
pequena lista de recursos.

Interface integrada

TortoiseSVN integra-se perfeitamente ao shell do Windows (ou seja, o Explorer). Isto

significa que voc pode continuar trabalhando com as ferramentas com as quais voc j est
familiarizado. E voc no tem que mudar para uma aplicao diferente cada vez que precisar
das funes de controle de verso.
E voc no est limitado a usar o Windows Explorer; os menus de contexto do
TortoiseSVN funcionam em muitos outros gerenciadores de arquivos, e tambm na caixa de
dilogo Arquivo/Abrir que comum na maioria dos aplicativos padro Windows. Voc deve,
entretanto, ter em mente que o Tortoise SVN intencionalmente desenvolvido como uma
extenso para o Windows Explorer. Assim, possvel que em outras aplicaes, a integrao
no seja to completa e, por exemplo, as sobreposies de cones podem no ser exibidas.

18

Sobreposio dos cones

A situao de cada arquivo e diretrio controlado indicado por uma pequena

sobreposio de cones. O que permite a voc ver rapidamente qual a situao da sua cpia
de trabalho.

Interface Grfica de Usurio

Quando voc lista as alteraes em um arquivo ou pasta, voc pode clicar em uma
reviso para ver os comentrios para aquela submisso. Voc tambm pode ver uma lista de
arquivos alterados - basta clicar duas vezes em um arquivo para ver exatamente o que mudou.
A caixa de dilogo de submisses lista todos os itens que sero includos em uma
submisso, e cada item tem uma caixa de seleo para que voc possa escolher os itens que
voc deseja incluir. Arquivos sem verso tambm podem ser listados, no caso de voc ter
esquecido de adicionar aquele novo arquivo.
Fcil acesso aos comandos do Subversion
Todos os comandos do Subversion esto disponveis nos menus do explorer.
TortoiseSVN adiciona seu prprio submenu.
Uma vez que TortoiseSVN um aplicativo cliente do Subversion, tambm
gostaramos de mostrar a voc algumas das funcionalidades do Subversion:

Controle de diretrio

CVS somente mantm o histrico de alteraes de arquivos individuais, mas

Subversion usa um controle virtual de sistema de arquivos que mantm o histrico de toda a
estrutura de diretrio ao longo do tempo.
Arquivos e diretrios so controlados. E como resultado, temos verdadeiros
comandos para mover e copiar arquivos e diretrios.

Submisso atmica

Cada submisso enviada completamente para o repositrio, ou no enviado

nada. Isto permite aos desenvolvedores construir e submeter as alteraes em partes coesas.

Metadados controlados

Cada arquivo e diretrio possue um conjunto de propriedades invisveis. Voc

pode inventar e gravar qualquer conjunto de chave/valor que desejar. Propriedades so
controladas ao longo do tempo, exatamente como o contedo dos arquivos.

Escolha das camadas da rede

Subversion tem uma noo abstrata de acesso ao repositrio, tornando fcil para as
pessoas desenvolverem novos mecanismos de rede. O servidor de rede avanado do
Subversion um mdulo para o servidor web Apache, do qual expe uma variante do HTTP
chamada WebDAV/DeltaV. Isto d ao Subversion uma grande vantagem em estabilidade e
interoperabilidade, e prov vrias funcionalidades chave de graa: autenticao, autorizao,
compresso, e navegao no repositrio, por exemplo. Uma caracterstica menor, um processo
servidor autnomo do Subversion tambm est disponvel. Este servidor exterioriza um
protocolo especfico que pode ser facilmente encapsulado sobre o protocolo ssh.

Manipulao consiste de dados

19
Subversion apresenta as diferenas de arquivos usando um algoritmo de
comparao binria, que funciona igualmente para arquivos texto (compreensveis) and
binrios (ilegveis). Ambos os tipos de arquivos so gravados compactados da mesma forma no
repositrio, e as diferenas so trasmitidas em ambas as direes
atravs da rede.

Ramificao e Rotulao eficiente

Os recursos necessrios para ramificar e rotular no propocional ao tamanho do

projeto. Subversion cria ramos e rtulos simplesmente copiando o projeto, usando um
mecanismo parecido ao hard-link. Deste modo estas operaes so realizadas rapidamente
sem variao de tempo, e consomem muito pouco espao no repositrio.
15.3. Licena
TortoiseSVN um projeto Open Source desenvolvido sob a licena GNU General
Public License (GPL). gratuito para baixar e de uso gratuito, pessoalmente ou
comercialmente, em qualquer nmero de computadores.
Embora a maioria das pessoas baixem apenas o instalador, voc tambm tem total
acesso de leitura do cdigo fonte deste programa. Voc pode navegar at o cdigo atravs do
link http://code.google.com/p/tortoisesvn/source/browse/. A linha de desenvolvimento atual est
localizado sob /trunk/, e as verses publicadas em /tags/.
15.4. Desenvolvimento
TortoiseSVN e Subversion so desenvolvidos por uma comunidade de pessoas que
esto trabalhando nestes projetos. Eles vm de diferentes pases pelo mundo, trabalhando
juntos para criar um timo software.
16. O investimento em VOIP
Foram detectadas algumas falhas dos mdulos bsicos dos sistemas quando j esto
em execuo. O gestor da rea de TI achou definiu que era mais importante investir em smart
phones e VolP.
VoIP uma tecnologia que permite a transmisso de voz por IP, tornando possvel
a realizao de chamadas telefnicas pela internet. Est se popularizando e surgem cada vez
mais empresas que lidam com essa tecnologia. Com essa tecnologia possvel fazer ligao
para telefones fixos ou celulares utilizando o microfone e as caixas de som do computador.
A tecnologia VoIP tambm aplicada em PABX, os sistemas de ramais telefnicos.
Dessa forma, muitas empresas esto deixando de ter gastos com centrais telefnicas por
substiturem estas por sistemas VoIP.
Para que o VoIP seja uma tecnologia vivel, necessrio investir em QoS, isto , em
qualidade de servio, pois, sem uma qualidade de transmisso similar ao telefone atual tudo se
torna pouco til. Uma das solues para isso seja possvel o aumento da largura de banda,
ou seja, o aumento da velocidade de transmisso e recepo dos dados. No caso da Software
Developer a Consulting recomenda que seja que tal atitude seja tomada.
Apesar dos vrios padres de VoIP, praticamente todas as empresas adotaram o
protocolo RTP (Real Time Protocol), que, basicamente, tenta fazer com que os pacotes sejam
recebidos conforme a ordem de envio. Esse protocolo "ordena" os pacotes de dados,
possibilitando a transmisso de dados em tempo real. Se algum pacote chegar com atraso, o
RTP causa uma interpolao.
A tecnologia Voip no est limitada s empresas nos dias de hoje. Graas ao
programa Skype, possvel fazer chamadas telefnicas por usurios domsticos com uma

20
largura de banda que no precisa ser muito alta. Pagando uma pequena quantia por ms
possvel fazer ligaes a um custo bastante inferior s ligaes pelos meios convencionais.
No caso da Software Developer a empresa optou pelo seu uso mas no gerenciou
corretamente a operao e a correo das falhas nos seus sistemas. O que poderia ser um
benefcio em economia para empresa tornou-se um problemas pela m gesto do recurso de
TI.
Quanto ao Sun Solaris 10, alguns analistas declaram que as mquinas que rodam o
sistema operacional SUN Solaris 10, afirmam ele o mais rpido da atualidade. Contem uns
atributos singulares e bem interessantes. construdo em cima da plataforma UNIX/BSD.
Embora seja desenvolvido historicamente como um software proprietrio, a maioria de seu
cdigo-fonte hoje em dia est disponvel como o sistema OpenSolaris.
Ele um sistema operacional para servidores, ento no se deve medir sua qualidade
somente porque ele mais difcil de instalar que o Linux (ou seja, ele no reconhece tantos
hardwares diferentes quanto o Linux ou o Windows).
A Sun lana a maior parte do cdigo fonte do Solaris sobre a CDDL, que
incompatvel com a GNU GPL, mas uma licena considerada livre pela OSI (Open Source
Initiative). Para uma empresa desenvolvedora de sistemas como a Software Developer o uso
de Software Livre vem benefici-la pela reduo dos custos associados e principalmente pela
garantia da liberdade n 0 e n 1: a liberdade de utilizar o programa para qualquer propsito e a
liberdade de adapt-lo para as suas necessidades. Nesse sentido, o acesso ao cdigo-fonte
um pr-requisito para esta liberdade.
Porm o prazo para implantao de novas mquinas para o terceiro trimestre de 2011
muito extenso. Por se tratar aqui de uma falha bsica no desenvolvimento e instalao de
sistemas para clientes, essas falhas devem ser classificadas pela Gesto de Problemas e
priorizadas para o primeiro atendimento. A Consulting destaca aqui a falha que pode ser
corrigida pela gesto da Qualidade, dando nfase na total satistafao do cliente. Se o produto
atende ao que se props, tem-se um consumidor satisfeiro; se no atende, tem-se um
consuidor frustrado que se voltar para a concorrncia
17. A adoo do E-MARKETING
Em visita empresa Software constatamos tambm que no foi adotada por essa
empresa nenhuma estratgia de venda de seus produtos pela internet. O gerente me informou
que no havia necessidade pois os clientes da Software Developer so clientes grandes que
pode ser feito o contato direto por meio de telefone para a venda de produtos.
Porm, em uma pesquisa de mercado, a Consulting verificou que o nicho de
mercado em que a Software Developer trabalha restrito. Diante disso, para expandir os
lucros, a Consulting recomenda expandir a carteira de clientes para para clientes como
financeiras e lojas de mdio e pequeno porte que concedem crdito. Nesse contexto, o EMarketing uma ferramente fundamental para se atingir esse objetivo.
Com o E-Marketing, a Software Developer concentrar seus esforos em na
promoo, comunicao e venda de seus produtos pela internet. A grande vantagem ser a
reduo de custos com propagandas que a Software Developer vai ter. Alm disso, a
propaganda estar disponvel 24h por dia e no haver limite de espao para a propaganda.

18. Concluso.

21
A Consulting, empresa de consultoria elaborou este estudo contendo anlise de
impacto, planejamento, desenvolvimento e como implementar melhorias nos processos de
Tecnologia da Informao da Software Developer.
Em anlise, a Consulting sugeriu que a contratante prove servios de suporte
especializado para atuar em diversos setores onde seus programas esto instalados e que
foram notados alguns problemas.
A Consulting sugere ento Software Developer um modelo de gesto no guia das
melhores prticas na gesto de servios voltados tecnologia da informao, o ITIL e
conceitos de gesto pela Qualidade Total.
Dentre os diversos modelos de gesto de TI fica a Software Developer aconselhada a
implementao de melhores prticas na gesto pelo ITIL, focando a melhoria na prestao dos
seus servios e na melhoria contnua dos seus produtos e servios. Aprimorar os servios na
rea de suporte ao cliente (Service Desk) pela melhoria nas Gerncias de incidentes e de
problemas. A correo do atendimento efetuada por parte da rea do Service Desk significa o
fortalecimento do ponto nico de contato com o cliente, a melhoria da interface com os clientes.
Foi sugerida tambm a ferramenta TortoiseSVN para o melhor gerenciamento de
documentos.
A Governana corporativa trar benefcios diversos, melhoria no controle financeiro,
qualidade nos servios, reafirmando assim o correto rumo em que a Software Developer deve
tomar para se tornar mais competitiva.
A essas gerncias cabendo a misso de aplicar tambm as ferramentas da
Qualidade, detectando e implantando melhoria nos seus mtodos, processos, meio ambiente,
mo de obra, mquinas e matria prima.
Quanto s implementaes dos conceitos da Qualidade Total importante lembrar
que quando h um aumento expressivo na qualidade do produto ofertado, ocorrem,
proporcionalmente, aumentos de produtividade e de ganhos. A Consulting destaca aqui a falha
que pode ser corrigida pela gesto da Qualidade. A grande quantidade e diversidade de
reclamaes dos clientes d indcios que a Software Developer no est dando nfase na total
satistafao do cliente. Se o produto atende ao que se props, tem-se um consumidor
satisfeito; se no atende, tem-se um consumidor frustrado que se voltar para a concorrncia.

19. Referncias Bibliogrficas.

Intech Brasil: Disponvel em > http://www.intechpro.com.br/gestao-implantacao-softwares-erpcrm-bi.html?gclid=CKS2n-20vagCFcK77QodfEWJNQ > acesso em 10 de outubro de 2012.

22

AD&M
Consultoria
Empresarial:
Disponvel
em
http://www.admconsultoria.com.br/novo/index.php/site > acesso em outubro de 2012.

>

[BASTOS 2007] Bastos, Anderson. Base de conhecimento em teste de software. Niteri-RJ,

2007.
Campos, Vicente Falconi. TQC - Controle da Qualidade Total. no estilo japons ANO: 1999 Belo
Horizonte Fundao de Desenvolvimento Gerencial.
[ISO9000] NBR ISO/IEC 9001:2000, 9000-3 Software - Rio de Janeiro, ABNT Associao
Brasileira de Normas Tcnicas.
LAURINDO, F. J. B. Tecnologia da Informao: Planejamento e Gesto de Estratgias. Editora
Atlas, 2008.
UNIVERSIDADE PAULISTA. Governana de TI Unidade I, II, III, IV, V, VI, VII, VIII. 2012
UNIVERSIDADE PAULISTA. Gesto da Qualidade Unidade I, II, III e IV. 2012
UNIVERSIDADE PAULISTA. Sistemas de Internet e Software Livre Unidade I, II, III e IV. 2012
RAC, Curitiba - Investimentos em Tecnologia da Informao e Impactos na Produtividade
Empresarial: uma Anlise Emprica Luz do Paradoxo da Produtividade - , v. 13, n. 3, art. 3, p.
391-409, Jul./Ago. 2009.
WIKIPEDIA. A enciclopdia livre. Acesso em: 14/10/2012
REVISTA INFO EXAME. Qual o melhor S.O. Publicado em setembro de 2010. Pag. 30
RIBEIRO, H. 5S A Base para a Qualidade Total: um roteiro para uma implantao bem
sucedida. Salvador: Casa da Qualidade. 1994. 115p.
URAN, J.M. A qualidade dede o Projeto. 4 ed. So Paulo: Cengange Learning, 2009.
MARTINS, Jos Carlos Cordeiro. Gerenciando projetos de desenvolvimento de software com
PMI, RUP e UML. 15.ed. Rio de Janeiro: Brasport, 2004.
SILBERSCHATZ, Abraham; GALVIN, Peter; GAGNE, Greg. Sistemas Operacionais Conceitos e
aplicaes. 8. ed. Rio de Janeiro: Campus, 2000.

UNIVERSIDADE PAULISTA
CURSO SUPERIOR DE TECNOLOGIA
GESTO EM TECNOLOGIA DA INFORMAO

23

ANTONIO LAERCIO NUNES DE AMORIM JUNIOR

PIM VII
PROJETO INTEGRADO MULTIDISCIPLINAR
SOFTWARE DEVELOPER.

BELM PAR
2014
ANTONIO LAERCIO NUNES DE AMORIM JUNIOR

24

PIM VII
PROJETO INTEGRADO MULTIDISCIPLINAR
SOFTWARE DEVELOPER

Trabalho do Projeto Integrado

Multidisciplinar PIM VII e VIII, apresentado como
exigncia para concluso do 4 Semestre do Curso
Superior de Tecnologia Gesto em Tecnologia da
Informao, da Universidade Paulista UNIP,
campus Entroncamento.
Monitora: LUANE BARRAL

]
BELM - PAR
2014

Resumo
A empresa Software Developer apresenta inmeros problemas em sua estrutura de
TI. Esses problemas tanto afetam diretamente o suporte operacional aos clientes como
tambm afetam o suporte administrativo j que seus produtos no esto alinhados com as

25
convenes internacionais de produtividade e segurana como a adequao a lei SOX e as
convenes ISSO e CMMI. Aps estudo de caso, enloco de forma shadow working inmeras
falhas nos processos do cliente Software Developer foram levantadas. Atravs de grficos de
situao algumas estratgias sero apontadas como forma de solucionar as falhas e tambm a
gerao de processos de melhorias continuas. Atravs do grfico de Ishigawa, cser traado
um perfil dos problemas operacionais da empresa Software Developer. Criao de um Service
Desk para prover um nico ponto de contato com os clientes. Gerenciar os chamados de forma
a poder gerar documentos para mtricas de produtividade, mapeamento de problemas e
oportunidade de novos negcios. A atual estrutura possui srias dificuldades para gerao,
classificao e soluo dos problemas relatados nas ligaes dos clientes. Falta consistncia
nos chamados abertos pelo mesmo problema, mas por pessoas diferentes.

Abstract
Software Developer The company presents numerous problems in their IT
infrastructure. These problems directly affect both operational support to clients as well as affect

26
the administrative support since their products are not aligned with international conventions
productivity and safety as the adequacy SOX and ISO and CMMI conventions . After the case
study, so enloco "shadow working" numerous failures in the client processes " Software
Developer " were raised . Through charts situation some strategies are identified as a way to
solve the faults and also the generation process of continuous improvement . Through the
Ishigawa graphic, cser trace a profile of operational problems the company Software
Developer. Creating a Service Desk to provide a single point of contact with customers .
Manage the calls so you can generate documents for productivity metrics , mapping problems
and opportunities for new business . The current structure has serious difficulties in generation ,
classification and resolution of reported problems in customer calls . Lack consistency in open
calls for the same problem, but for different people.

SUMRIO

1-INTRODUO

27
2-AS FALHAS
2.1- ENUMERAO DAS FALHAS
2.2 ANLISE DAS FALHAS
3-REQUISITOS DO PROJETO
3.1 DESCRIO BSICA DO PROJETO
3.2 OBJETIVO DO PROJETO
3.2.1 REQUISITOS FUNCIONAIS DESEJVEIS (PRIORIZADOS)
3.3 REQUISITOS DE QUALIDADE INICIAIS E PRINCIPAIS
3.4 CRITRIOS DE ACEITAO DO PROJETO
3.5 IMPACTOS DO PROJETO
4-IMPLANTANDO AS SOLUES
4.1 OS PROBLEMAS
4.2- APLICANDO AS SOLUES
3.3 EAP DO PROJETO
4.4 CONSIDERAES GERAIS
5 AS FALHAS
5.1 APLICANDO AS MELHORIAS
5.2 DESENVOLVIMENTO DA UNIDADE
5.3 TESTE DA UNIDADE
5.4 TESTE DE INTEGRAO
5.5 TESTE DE SISTEMA
6 ESCOPO , CUSTO E TEMPO
6.1 - ESCOPO
6.2 CUSTO
6.3 TEMPO
6.3.1 - USER STORIES
6.3.2 PLANEJAMENTO
6.3.3 PRIORIZAO
6.3.4 STAND UP MEETING
6.3.5 PAIR PROGRAMMING
6.3.6 COLLECTIVE CODE OWNERSHIP .
7-CONCLUSO
8-REFERNCIAS BIBLIOGRFICA........................................................................................40
9-GLOSSRIO..........................................................................................................................41.

1-Introduo
A implementao de um servio de Service Desk o item inicial dentro dos processos
de melhorias e melhores prticas. um contato objetivo e profissional feito com o cliente no
s uma ttica importante, mas primordial para dar uma ordem aos demais acontecimentos

28
derivados desse atendimento. O Service Desk desenvolver um nico ponto de contato com o
cliente assim como mediar alguns processos internos
Dentre os problemas relacionados e analisados na Software Developer os problemas
com o atendimento ao cliente, gerenciamento das chamadas e o gerenciamento das falhas so
os problemas mais notrios j que o manuseio e o gerenciamento desses itens no fazem
parte do afim da empresa. Mas conhecido que a organizao e um bom relacionamento com
os clientes fazem parte do negcio e dessa forma a soluo trazida pelo Service Desk s vem
solidificar esse argumento.
A Software Developer uma fbrica de software que apresenta srios problemas em
sua estrutura de desenvolvimento. Uma anlise demonstra que nenhum processo
reconhecidamente empregado quer seja na gesto TI quer seja na prpria rvore de
desenvolvimento de aplicativos.
Um processo de melhorias contnuas dever ser implementado para possibilitar que a
empresa se enquadre em moldes de qualidade sustentveis e esteja apta a desenvolver e
entregar seus produtos dentro dos padres internacionais.

2-As falhas
2.1- Enumerao das falhas
A empresa Software Developer apresenta inmeros problemas em sua estrutura de
TI. Esses problemas tanto afetam diretamente o suporte operacional aos clientes como
tambm afetam o suporte administrativo j que seus produtos no esto alinhados com as
convenes internacionais de produtividade e segurana como a adequao a lei SOX e as

29
convenes ISSO e CMMI. Aps estudo de caso, enloco de forma shadow working inmeras
falhas nos processos do cliente Software Developer foram levantadas. Atravs de grficos de
situao algumas estratgias sero apontadas como forma de solucionar as falhas e tambm a
gerao de processos de melhorias continuas.
A atual estrutura possui srias dificuldades para gerao, classificao e soluo dos
problemas relatados nas ligaes dos clientes. Falta consistncia nos chamados abertos pelo
mesmo problema, mas por pessoas diferentes.
As novas releases apresentam falhas quando implantadas no ambiente de produo dos
clientes. Suas operaes ficam impactadas por horas.
Os clientes reclamam que no possuem um suporte adequado e nem um retorno satisfatrio
com as causas dos problemas.
Os sistemas vendidos apresentam deficincias para prover vrias necessidades aos clientes
que precisam seguir a lei Sarbanes-Oxley.
As reas mais afetadas pela atual crise de processos so:
Operaes
Desenvolvimento e Release de softwares
Gesto de TI
2.2 Anlise das falhas
Atravs do grfico de Ishigawa, como descrito na figura 1, ser traado um perfil dos
problemas operacionais da empresa Software Developer.
Figura 1: Grfico de Ishigama da Software Developer

* RFO Reason For Outage ( Razo do problema )

3-Requisitos do Projeto
3.1 Descrio bsica do Projeto
Criao de um Service Desk para prover um nico ponto de contato com os clientes.
Gerenciar os chamados de forma a poder gerar documentos para mtricas de produtividade,
mapeamento de problemas e oportunidade de novos negcios.
Criar uma base de dados consistente de todos os problemas novos e j conhecido
com o propsito de melhorias constantes e progressivas. Garantir todos os requisitos e
procedimentos para novas instalaes e reduzir retrabalho e custos desnecessrios.

30
3.2 Objetivo do Projeto
A criao do Service Desk busca gerar um ambiente de segurana e qualidade no
atendimento e no gerenciamento de problemas relatados pelos clientes e tambm visa abrir um
novo canal de contato, parceria e novos negcio frente a antigos e novos clientes.
3.2.1 Requisitos Funcionais desejveis (priorizados)
O Service Desk dever apresentar requisitos mnimos desejveis para o incio de
suas funes:
> Um banco de dados consistente e atualizado.
> Uma ferramenta CRM estvel.
> Operadores Treinados.
> Uma escala operacional auto suficiente.
> Rpida inteirao entre o CALL management e o FAULT management.
3.3 Requisitos de Qualidade iniciais e principais
O Service Desk na funo de SPOC (Single point of Contact) deve ter requisitos de
qualidade bastante visiveis aos clientes tais como:
> Atendimento no terceiro toque.
> Greetings curtos e objetivos.
> Rapidez na abertura dos chamados.
> Manter o cliente sempre informado do andamento de sua reclamao.
> Sempre informar ao cliente a razo problema e a soluo aplicada.
> Ser proativo sempre que necessrio como avisar a disponibilidade de um novo release por
exemplo.
3.4 Critrios de Aceitao do Projeto
O projeto dever ser aceito quando os requisitos funcionais estiverem todos
operacionais de forma satisfatria.
3.5 Impactos do Projeto
Pela Viso do Cliente O Cliente deve ter uma viso positiva a respeito da Software
Developer aps a implementao do projeto. A organizao e a agilidade dos atendimentos e
das solues sero facilmente percebidos.
Pela viso Interna de Outras reas Qualquer mudana inspira preoculpao por parte dos
que esto diretamente envolvidos o que pode trazer certos desconfortos no incio, mas ao
longo da maturidade do projeto suas qualidades logo sero percebidas pelos integrantes das
reas envolvidas.
4-Implantando as Solues
4.1 Os Problemas
A atual estrutura possui srias dificuldades para gerao, classificao e soluo dos
problemas relatados nas ligaes dos clientes. Falta consistncia nos chamados abertos pelo
mesmo problema, mas por pessoas diferentes.
Os clientes reclamam que no possuem um suporte adequado e nem um retorno satisfatrio
com as causas dos problemas.

31
4.2- Aplicando as solues
Figura 2: Processos Internos do Service Desk

A implementao de um servio de Service Desk o item inicial dentro dos processos

de melhorias e melhores prticas. um contato objetivo e profissional feito com o cliente no
s uma ttica importante, mas primordial para dar uma ordem aos demais acontecimentos
derivados desse atendimento. O Service Desk desenvolver um nico ponto de contato com o
cliente assim como mediar alguns processos internos como visto na figura 2.
Dentre os problemas relacionados e analisados na Software Developer os problemas
com o atendimento ao cliente, gerenciamento das chamadas e o gerenciamento das falhas so
os problemas mais notrios j que o manuseio e o gerenciamento desses itens no fazem
parte do afim da empresa. Mas conhecido que a organizao e um bom relacionamento com
os clientes fazem parte do negcio e dessa forma a soluo trazida pelo Service Desk s vem
solidificar esse argumento.
Como todo processo o Service Desk ter uma linha de tempo delineada entre o inicio
e o trmino quando sua operao dever ser plena. Essa linha de tempo representada na
figura 3.

Figura 3: Linha do tempo do Service Desk.

32

Na linha de tempo um dos pontos muito importantes o que tange ao treinamento

dos agentes que estaro envolvidos no dia a dia do Service Desk. Ser importante definir
durante a avaliao de requisitos e avaliao de custos alguns itens outros itens como o tipo de
mo de obra a ser empregada no atendimento. Questes como: sero os atendentes tcnicos
ou no e essa uma viso importante j que ela vai ajudar a delinear os custos de operao.

4.3 EAP do Projeto

O processo para a criao do Service Desk ser dividido da seguinte forma:
Infraestrutura Contratao (se necessrio) - Treinamento e Operao. Usando uma
ferramenta EAP (Estrutura Analtica do Projeto) descrevemos na figura 4 a estrutura bsica do
projeto do Service Desk.
Figura 4: a estrutura bsica do projeto do Service Desk.

Aps vencidas todas as etapas que precedem o lanamento do projeto para plena
operabilidade incluindo os testes finais, j ser possvel iniciar as operaes.
4.4 Consideraes gerais
A empresa Software Developer desenvolvedora de softwares (Fbrica de Software),
mas possui srios problemas em sua estrutura de TI, tanto no que tange a infraestrutura de TI
quanto na rea de desenvolvimento e governana. A engenharia de software envolve o
gerenciamento de trs elementos como descrito na figura 5.

33

Figura 5:Gerenciamento de trs elementos

A criao de software, assim como outros produtos, tambm passa por uma cadeia
de passos e processos at seu desenvolvimento final e aceitao do cliente. O aprendizado e o
aprimoramento desses processos o que constitui a maturidade da fbrica. A maturidade de
uma fbrica de software o que vai ditar seu posicionamento no mercado uma vez que
experincia e confiabilidade so requerimentos cruciais para todos aqueles cujos negcios
dependeram constantemente de algum tipo de aplicativos. Essa arquitetura em camadas
vista na figura 6.
Figura 6:Arquitetura em camadas

A Software Developer uma fbrica de software que apresenta srios problemas em

sua estrutura de desenvolvimento. Uma anlise demonstra que nenhum processo
reconhecidamente empregado quer seja na gesto TI quer seja na prpria rvore de
desenvolvimento de aplicativos.

34
Um processo de melhorias contnuas dever ser implementado para possibilitar que a
empresa se enquadre em moldes de qualidade sustentveis e esteja apta a desenvolver e
entregar seus produtos dentro dos padres internacionais.
5 As falhas
As novas releases apresentam falhas quando implantadas no ambiente de produo dos
clientes. Suas operaes ficam impactadas por horas.
Os sistemas vendidos apresentam deficincias para prover vrias necessidades aos clientes
que precisam seguir a lei Sarbanes-Oxley.
5.1 Aplicando as melhorias
Um software tem um perodo de vida que vai desde o seu incio passando por todos
os estgios at o seu release (Entrega). Na figura 7 est um grfico do RUP do ciclo de vida de
um Software.
Figura 7: Grfico RUP.

Existem quatro atividades bsicas inerentes ao ciclo de criao e vida de um

software:
Especificao do Software
Desenvolvimento do Software
Validao do Software
Evoluo do Software
Durante o ciclo de criao de um software cada passo seguido corretamente
importante para garantir que o software tenha os requisitos chaves a oferecer que so:
Funcionalidade
Desempenho
Facilidade de Manuteno
Facilidade de Uso
Confiabilidade

35
A Software Developer deve implantar um processo no qual seja possvel
verificar a qualidade de seus produtos durante todas as fases da criao. Essa a forma de se
evitar o retrabalho, gastos desnecessrios com projetos que j deveriam estar em produo e
reclamaes dos clientes que acabam impactados pela baixa qualidade dos aplicativos.
Todos os requisitos devem convergir para mecanismos que venham
possibilitar o monitoramento das etapas de criao e assim alm de garantir a qualidade na
entrega tambm inclui-los em moldes de segurana internacionais assim como o SOX.
Assim sendo uma normativa de particionamento do projeto em unidades menores e o
teste constante de cada unidade individualmente e depois testes dessa unidade no conjunto
garantir a qualidade final.

5.2 Desenvolvimento da Unidade

Esta a fase de criao da primeira unidade caso seja um software novo ou de mais uma
unidade caso seja o desenvolvimento de uma nova release ou verso.
5.3 Teste da Unidade
Tem por objetivo testar a menor unidade do projeto (um componente de software que
no pode ser subdividido), procurando identificar erros de lgica e de implementao em cada
mdulo separadamente.
5.4 Teste de Integrao
Visa descobrir erros associados s interfaces entre os mdulos quando esses
so integrados para formar a estrutura do produto de software.
- Ascendente (bottom-up)
- Descendente (Top-down)
- Sanduche (camada do meio, bottom e up)
- Big-bang (integra de uma s vez todos os mdulos)
5.5 Teste de Sistema
Inclui diversos tipos de testes, realizados na seguinte ordem:
- Teste funcional
- Teste de desempenho
- Teste de aceitao
- Teste de instalao
6 Escopo , Custo e Tempo
6.1 - Escopo
Em qualquer projeto o Escopo o Custo e o Tempo so os norteadores das aes. O
desenvolvimento de software no foge a essa regra e o no uso correto delas pode causar
srios danos ao projeto ao ponto de compromet-lo completamente. Essa a fase de
concepo, o foco principal recai sobre o entendimento dos requisitos e a determinao do
escopo do projeto (planejamento e levantamento de requisitos).

36
6.2 Custo
O tempo um dos fatores de muita importncia tanto para o cliente quanto para o
desenvolvedor. Da mesma forma que o desenvolvedor estabelece outras atividades j
prevendo o termino de outra o cliente tambm estabelece certa expectativa com relao ao
release do produto.
Um software de qualidade e que atende bem a demanda do cliente representa
economia para o cliente e para o desenvolvedor. O cliente pode ter suas operaes
comprometidas por problemas de operacionabilidade do software e ter prejuzos. J para o
desenvolvedor o custo de localizar e solucionar o problema de um software j implementado
pode elevar seu custo em at 1000 vezes.
Nesse caso o tempo para ambos tambm fica severamente afetado j que recursos e
pessoas tero que ser realocados para trabalhar em um elemento que j deveria estar em
produo. Uma relao simples de tempo e custo.
6.3 Tempo
A correta administrao do tempo um fator crucial j que muitos fatores como
valores de alocao de recursos dependem deste item. Algumas regras devem ser seguidas
para que o tempo seja aproveitado da forma mais produtiva e eficiente possvel.
6.3.1 - User Stories
As Funcionalidades so informadas atravs de user stories.

Estrias devem ser simples.

Desenvolvedores estimam tempo.
6.3.2 Planejamento
O Cliente entrega as estrias priorizadas para serem implementadas.
Desenvolvedores respeitam as prioridades dos clientes.
Projeto dividido em partes: Releases e Iteraes como relacionado na figura 8.
Figura 8: Releases e interaes

Na figura 9, o desmembramento do planejamento (Panning) para o release.

Figura 9: o desmembramento do planejamento

37

O cliente recebe um oramento dos desenvolvedores.

Seleciona as estrias prioritrias que possam ser implementadas dentro do oramento.
Pode trocar estrias durante o release.
6.3.3 Priorizao
O cliente deve priorizar as estrias para obter o mximo de valor rapidamente.
Se baseia nas suas necessidades e nas estimativas dos desenvolvedores.

6.3.4 Stand up Meeting

Reunio rpida
Diria
Atualiza a equipe
6.3.5 Pair programming
Todo cdigo escrito em par.
Duas pessoas trabalham em um nico computador.
Uma digita, enquanto a outra revisa, corrige e sugere.

38

6.3.6 Collective Code ownership

Todos so responsveis por todas as partes do sistema.
Cdigo tem que estar sempre limpo.
Todos so capazes de modific-lo.

39

7-Concluso

Dentre os problemas relacionados e analisados na Software Developer os problemas

com o atendimento ao cliente, gerenciamento das chamadas e o gerenciamento das falhas so
os problemas mais notrios j que o manuseio e o gerenciamento desses itens no fazem
parte do afim da empresa. Mas conhecido que a organizao e um bom relacionamento com
os clientes fazem parte do negcio e dessa forma a soluo trazida pelo Service Desk s vem
solidificar esse argumento.
A Software Developer deve implantar um processo no qual seja possvel
verificar a qualidade de seus produtos durante todas as fases da criao. Essa a forma de se
evitar o retrabalho, gastos desnecessrios com projetos que j deveriam estar em produo e
reclamaes dos clientes que acabam impactados pela baixa qualidade dos aplicativos.
Todos os requisitos devem convergir para mecanismos que venham
possibilitar o monitoramento das etapas de criao e assim alm de garantir a qualidade na
entrega tambm inclui-los em moldes de segurana internacionais assim como o SOX.
Em qualquer projeto o Escopo o Custo e o Tempo so os norteadores das aes. O
desenvolvimento de software no foge a essa regra e o no uso correto delas pode causar
srios danos ao projeto ao ponto de compromet-lo completamente. Essa a fase de
concepo, o foco principal recai sobre o entendimento dos requisitos e a determinao do
escopo do projeto (planejamento e levantamento de requisitos).

40

8-Referncias Bibliogrficas
http://oplk.com.br/service-desk/
http://www.ebah.com.br/content/ABAAAepvgAH/produtividade?part=2
http://blogs.msdn.com/b/wcamb/archive/2010/05/17/arquitetura-de-composi-o-e-seusdiferentes-desafios.aspx
http://dearchitectura.files.wordpress.com/2008/11/humpchart.jpg

http://oncast.com.br/blog/?p=217
http://gpfdp.files.wordpress.com/2014/02/planejamento-i-b.jpg

41
9-Glossrio
Figura 1: Grfico de Ishigama da Software Developer........................................................29
Figura 2: Processos Internos do Service Desk.....................................................................31
Figura 3: Linha do tempo do Service Desk...........................................................................32
Figura 4: a estrutura bsica do projeto do Service Desk......................................................32
Figura 5:Gerenciamento de trs elementos.........................................................................33
Figura 6:Arquitetura em camadas........................................................................................33
Figura 7: Grfico RUP...........................................................................................................34
Figura 8: Releases e interaes..........................................................................................36
Figura 9: o desmembramento do planejamento...................................................................37