25

UNIVERSIDADE PAULISTA CURSO SUPERIOR DE TECNOLOGIAGESTO EM TECNOLOGIA DA INFORMAO

ANTONIO LAERCIO NUNES DE AMORIM JUNIOR

PIM VIIPROJETO INTEGRADO MULTIDISCIPLINAR

SOFTWARE DEVELOPER.

BELM PAR2014

ANTONIO LAERCIO NUNES DE AMORIM JUNIOR

PIM VIIPROJETO INTEGRADO MULTIDISCIPLINARSOFTWARE 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 - PAR2014

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.................................................................................................................................................4ABSTRACT.............................................................................................................................................51. INTRODUO.62. GOVERNANA DE TI.72.1 APRESENTAO.73. GOVERNANA CORPORATIVA.8,94. SLA E SLM.95. PLANO ESTRATGICO DE TI - PETI................................................................................................96. METODOLOGIA DE GERENCIAMENTO DE PROJETOS................................................................97. METODOLOGIA ITIL...........................................................................................................................97.1 - CONCEITO................................................................................................................................9,108. METODOLOGIA PROPOSTA PARA AVALIAO........................................................................108.1 - FUNDAMENTOS..........................................................................................................................10 8.1.2 - CMMI.................................................................................................................................10,119. DEFINIO DO PLANEJAMENTO ESTRATGICO DE TI..............................................................119.1 - COBIT......................................................................................................................................11,129.2 - METODOLOGIA PROPOSTA....................................................................................................129.3 - OBTENO DE RESULTADOS.................................................................................................12 9.3.1 - DEFINIR UM PLANO ESTRATGICO DE TI..........................................................................129.4 RESULTADOS FINAIS.............................................................................................................12,1310 - RECOMENDAES...................................................................................................................1311 - PROCESSO DEFINIDO.............................................................................................................1312 - DEFINIR ARQUITETURA DA INFORMAO..........................................................................1312.1 - RECOMENDAES.............................................................................................................13,1412.2 - DETERMINAR A DIREO TECNOLGICA..........................................................................14 12.2.1 - RECOMENDAES.........................................................................................................1412.3 - PROCESSO DEFINIDO.........................................................................................................1513 - GESTO DA QUALIDADE.................................................................................................15,1614 - ESTUDO DE CASO............................................................................................................16,1715 - SISTEMAS DE INTERNET E SOFTWARE LIVRE....................................................................1715.1 - O QUE TORTOISESVN?..................................................................................................1715.2 - CARACTERSTICAS DO TORTOISESVN.................................................................... 17,18,1915.3 - LICENA..................................................................................................................................1915.4 - DESENVOLVIMENTO..............................................................................................................1916. O INVESTIMENTO EM VOIP..................................................................................................19,2017. A ADOO DO E-MARKETING2018. CONCLUSO.21122.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.5

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.

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. 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 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. 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 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 fazia-se 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.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. 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. 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 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 * Fluxogramas14. 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.

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.

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

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 direesatravs 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 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 concorrncia17. 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 E-Marketing 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.

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-erp-crm-bi.html?gclid=CKS2n-20vagCFcK77QodfEWJNQ > acesso em 10 de outubro de 2012.

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 PAULISTACURSO SUPERIOR DE TECNOLOGIAGESTO EM TECNOLOGIA DA INFORMAO

ANTONIO LAERCIO NUNES DE AMORIM JUNIOR

PIM VIIPROJETO INTEGRADO MULTIDISCIPLINAR

SOFTWARE DEVELOPER.

BELM PAR

2014ANTONIO LAERCIO NUNES DE AMORIM JUNIOR

PIM VIIPROJETO INTEGRADO MULTIDISCIPLINARSOFTWARE 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 - PAR2014

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 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 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-Introduo282-As falhas292.1- Enumerao das falhas292.2 Anlise das falhas293-Requisitos do Projeto303.1 Descrio bsica do Projeto303.2 Objetivo do Projeto303.2.1 Requisitos Funcionais desejveis (priorizados)303.3 Requisitos de Qualidade iniciais e principais303.4 Critrios de Aceitao do Projeto303.5 Impactos do Projeto304-Implantando as Solues314.1 Os Problemas314.2- Aplicando as solues313.3 EAP do Projeto324.4 Consideraes gerais335 As falhas345.1 Aplicando as melhorias355.2 Desenvolvimento da Unidade355.3 Teste da Unidade355.4 Teste de Integrao355.5 Teste de Sistema356 Escopo , Custo e Tempo356.1 - Escopo356.2 Custo366.3 Tempo366.3.1 - User Stories36 6.3.2 Planejamento36,376.3.3 Priorizao376.3.4 Stand up Meeting37 6.3.5 Pair programming376.3.6 Collective Code ownership.387-Concluso398-REFERNCIAS BIBLIOGRFICA........................................................................................409-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 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 falhas2.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 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 falhasAtravs 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 Projeto3.1 Descrio bsica do ProjetoCriao 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.3.2 Objetivo do ProjetoA 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 Solues4.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.4.2- Aplicando as soluesFigura 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.

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 ProjetoO 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 geraisA 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.

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.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 melhoriasUm 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 SoftwareDurante 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 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 UnidadeTem 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 SistemaInclui diversos tipos de testes, realizados na seguinte ordem:

- Teste funcional- Teste de desempenho- Teste de aceitao- Teste de instalao6 Escopo , Custo e Tempo6.1 - EscopoEm 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).

6.2 CustoO 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 TempoA 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 StoriesAs Funcionalidades so informadas atravs de user stories.

Estrias devem ser simples. Desenvolvedores estimam tempo.

6.3.2 PlanejamentoO 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

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 PriorizaoO 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.

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.

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).

8-Referncias Bibliogrficas

http://oplk.com.br/service-desk/http://www.ebah.com.br/content/ABAAAepvgAH/produtividade?part=2http://blogs.msdn.com/b/wcamb/archive/2010/05/17/arquitetura-de-composi-o-e-seus-diferentes-desafios.aspxhttp://dearchitectura.files.wordpress.com/2008/11/humpchart.jpghttp://oncast.com.br/blog/?p=217http://gpfdp.files.wordpress.com/2014/02/planejamento-i-b.jpg

9-Glossrio

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