FACULDADE IMPACTA DE TECNOLOGIA SOFTWARE COMO SERVIÇO (SAAS) ALEX CORCIOLI ALEX SOUZA FORNAZARO GONÇALO BESSA TIAGO CORREIA

Transcrição

1 FACULDADE IMPACTA DE TECNOLOGIA SOFTWARE COMO SERVIÇO (SAAS) ALEX CORCIOLI ALEX SOUZA FORNAZARO GONÇALO BESSA TIAGO CORREIA SÃO PAULO 2008

2 FACULDADE IMPACTA DE TECNOLOGIA SOFTWARE COMO SERVIÇO (SAAS) SÃO PAULO 2008

3 FACULDADE IMPACTA DE TECNOLOGIA SOFTWARE COMO SERVIÇO (SAAS) ALEX CORCIOLI ALEX SOUZA FORNAZARO GONÇALO BESSA TIAGO CORREIA Trabalho de Conclusão de Curso apresentando ao Curso de Gestão em Sistemas de Informação da Faculdade Impacta de Tecnologia, para obtenção do grau de Bacharel em Gestão de Sistemas de Informação. Aprovada em de. BANCA EXAMINADORA Prof. José Luiz Moraes de Souza Faculdade Impacta de Tecnologia Faculdade Impacta de Tecnologia Faculdade Impacta de Tecnologia

4 Dedicamos este trabalho aos nossos pais, esposas e namoradas pela compreensão e colaboração durante o desenvolvimento deste trabalho.

5 AGRADECIMENTOS Aos nossos professores e coordenadores do curso, que nos forneceram base para iniciar a pesquisa científica deste trabalho. Aos nossos maiores incentivadores, nossos Pais, que sempre nos apoiaram nos maiores desafios, e nos deram força nos momentos difíceis desse percurso.

6 RESUMO Este documento tem como objetivo apresentar uma solução para disponibilização de serviços através da Internet, denominado SaaS Software as a Service. Além de informações gerais sobre seu conceito, será apresentada sua arquitetura, seu posicionamento no mercado, bem como seus níveis de maturidade. Baseado nestas definições, será sugerido caminhos para elaboração de um projeto SaaS, seguindo as melhores práticas sugeridas pelo PMBOK, metodologias de desenvolvimento ágil, com o SCRUM, para elaboração do produto (serviço) e uma forma para dar suporte ao produto, através das melhores práticas sugeridas pelo ITIL. A integração destas informações fornecerá uma base para construção de projetos SaaS, do início ao fim. Palavras-chave: SaaS, PMBOK, ITIL, Agile, Scrum, Integração.

7 ABSTRACT This document aims to provide a solution for provision of services via the Internet, known as SaaS - Software as a Service. In addition to general information about their concept, will be presented their architecture, their positioning in the market, as well as their levels of maturity. Based on these definitions, it will be suggested ways to prepare a project SaaS, following best practices suggested by PMBOK, agile development methodologies, with the Scrum, to manufacture the product (service) and a way to support the product through the best practices suggested by ITIL. The integration of this information will provide a basis for construction of SaaS projects, from start to finish. Keywords: SaaS, PMBOK, ITIL, Agile, Scrum, Integration.

8 SUMÁRIO 1 INTRODUÇÃO SOFTWARE COMO SERVIÇO - SAAS Arquitetura Situação do SaaS no Mercado METODOLOGIAS E MELHORES PRÁTICAS PMI Gestão de Projetos Engenharia de Software Metodologias Ágeis Metodologias Scrum ITIL CONCEBENDO O PROJETO SAAS COM O PMI Missão Objetivos Premissas e Restrições Obstáculos Estratégias Análise de Viabilidade Plano de Projeto Escopo Recursos Humanos Cronograma - Plano de Ação Responsabilidades Gerenciamento de Riscos Orçamento Despesas Fixas - Fornecedores Fluxo de Caixa Orçamento Plano de Qualidade Relatórios do Projeto Plano de Comunicação Contratos... 36

9 Documentos complementares DESENVOLVENDO O PRODUTO COM SCRUM Etapas de Desenvolvimento Pré-game Game Pós-Game REALIZANDO O SUPORTE COM ITIL Missão Premissas e Restrições Suporte ao Serviço Gerenciamento de configuração Central de serviços Gerenciamento de incidentes Gerenciamento de problemas Gerenciamento de mudanças Gerenciamento de liberações Entrega de Serviços Gerenciamento do nível de serviço Gerenciamento Financeiro Gerenciamento da capacidade Gerenciamento da segurança Gerenciamento da disponibilidade Gerenciamento da continuidade CONCLUSÃO REFERÊNCIAS GLOSSÁRIO ANEXOS ANEXO A APRESENTAÇÃO ANEXO B PRINCIPAIS ATIVIDADES WBS ANEXO C RESPONSABILIDADE ANEXO D EMPRESAS FORNECEDORAS ANEXO E MODELO CONTRATO ANEXO F BACKLOG PRODUTO ANEXO G ANALISE DE FRAMEWORK... 77

10 ANEXO H ANALISE DE REQUISITOS ANEXO I PADRÕES ANEXO J FLUXO DE VIDA DO CHAMADO ANEXO L PLANILHA DE ATENDIMENTO ANEXO M ANALISE DE CAUSA E RESOLUÇÃO ANEXO N CONTRATO DE SLA ANEXO O PLANILHA DE FATURAMENTO ANEXO P SCRIPT DE ATENDIMENTO ANEXO Q ANALISE DE RISCO... 95

11 LISTA DE ILUSTRAÇÕES FIGURA 1 - REPRESENTAÇÃO DOS NÍVEIS DE MATURIDADE DO SAAS (BLOGS MSDN, 2008) 18 FIGURA 2 - MODELO DE ARQUITETURA SAAS (BLOGS MSDN, 2008) 20 FIGURA 3 - PLANILHA DE RECURSOS HUMANOS 29 FIGURA 4 - CRONOGRAMA DO PROJETO 30 FIGURA 5 - ORGANOGRAMA 31 FIGURA 6 - FLUXO DE CAIXA 33 FIGURA 7 - RELATÓRIO DE FLUXO DE CAIXA DO PROJETO 34 FIGURA 8 - ANÁLISE DE ORÇAMENTO 34

12 LISTA DE TABELAS TABELA 1 - RELAÇÃO PROCESSOS X DISCIPLINAS (AUTORES, 2008) TABELA 2 - RELAÇÃO DE PAPÉIS NO SCRUM (AUTORES, 2008) TABELA 3 - CLASSIFICAÇÃO DE RISCOS (AUTORES, 2008) TABELA 4 - RISCOS DE UM PROJETO DE DESENVOLVIMENTO DE SOFTWARE (MARTINS, 2007) TABELA 5 - DESPESAS FORNECEDORES (AUTORES, 2008) TABELA 6 - IMPACTO X URGÊNCIA (AUTORES, 2008) TABELA 7 - REQUISITOS DE SEGURANÇA (AUTORES, 2008) TABELA 8 - INDICADORES DE DISPONIBILIDADE (AUTORES, 2008) TABELA 9 - PLANO DE RECUPERAÇÃO (AUTORES, 2008)... 51

13 13 1 INTRODUÇÃO O tema está divido em três grandes partes, o projeto apresenta a união de conceitos para formação de um conceito conjugado misturando o Software com Serviço (SAAS), que podemos considera-lo como conceito inicial de negócio agrupado melhores praticas e metodologias. No capitulo SOFTWARE COMO SERVIÇO SAAS, é demonstrado todo o conceito sobre Software com Serviço (SAAS) no qual será apresento como identificar quando um sistema está utilizando este dentro deste conceito, quais as arquiteturas que podem ser utilizadas para criação de um sistema SAAS, também pouco sobre o mercado atual e futuro do SAAS. METODOLOGUAS E MELHORES PRÁTICAS neste capitulo trata-se de definições de metodologias e melhores práticas que serão abordados em vários tópicos do projeto, como PMI, Agile e ITIL. As definições serão apresentadas de modo a darem uma base para o bom entendimento no contexto do projeto e não como uma referência completa sobre o assunto. Dentro do capitulo CONCEBENDO O PJETO SAAS COM O PMI utilizando dos conhecimentos apresentados no capitulo METODOLOGUAS E MELHORES PRÁTICAS é criado um projeto completo de formação de um Software como Serviço, dês do escopo até planejamento de um projeto (seguindo as melhores práticas sugeridas pelo PMI), utilizando como base um sistema de gerenciamento educacional. No capitulo DESENVOLVENDO O PRODUTO COM O SCRUM é criado do o planejamento, organização da equipe e criação de artefatos (arquivos de controle) para desenvolver o sistema tecnicamente, tudo isso baseado na metodologia de desenvolvimento SCRUM.

14 14 É apresentado no capitulo REALIZANDO O SUPORTE COM ITIL a formação um exemplo de como estruturar o suporte aos serviços da empresa, seguindo as melhores praticas sugeridas pelo ITIL v2.0.

15 15 2 SOFTWARE COMO SERVIÇO - SAAS O Software como um Serviço (SaaS) é um conceito para implementação e divulgação de sistemas via Internet. A partir dele, o software desenvolvido é encarado como um serviço, ou seja, utilizando uma hospedagem em um servidor remoto, a aplicação fica disponível para determinados usuários usufruírem das funcionalidades que o mesmo disponibiliza, de forma ágil e objetiva. Comercialmente falando, empresas que tarifam o acesso aos serviços utilizando este conceito, o fazem como um aluguel (assinatura), ou seja, os usuários pagam por aquilo que utilizam. Outras empresas utilizam de recursos como disponibilizar parte dos serviços gratuitamente, para despertar o interesse do usuário. Caso o usuário queira estender a utilização do sistema, o mesmo deve investir por isso. Há grandes exemplos de implementação de SaaS no mercado. Um dos maiores, Google, disponibiliza aplicações em forma de serviços de maneira integrada (Google Docs, Google Maps, Orkut, Gmail, Picasa Web, entre outros). (ITWeb, 2008) No Brasil, há um grande exemplo de implementação de SaaS, é o sistema Aprex ( que disponibiliza ferramentas para um escritório remoto, úteis para empresas, instituições, ou grupos de estudo, aplicando fortemente o conceito de Web 2.0, focando o compartilhamento e as interações entre usuários distintos, separados fisicamente ou não. O SaaS não menciona nenhuma linguagem de programação ou tecnologias específicas. O mais importante é o entendimento dos principais conceitos que fazem parte de sua estrutura. Para um consumidor, as principais vantagens na utilização do SaaS são:

16 16 Alta Disponibilidade: Como o aplicativo fica armazenado em um servidor remoto, a mesma pode ser acessada de qualquer local que tenha conexão com a Internet. Geralmente, o fornecedor do serviço menciona no contrato o SLA de disponibilização do serviço. Redução da dependência do departamento de TI interno: Como os serviços estarão disponíveis em um servidor remoto via internet, não há necessidade de instalações ou processos de integração que envolvem diretamente os responsáveis de TI da empresa. Com isso, se ganha tempo na disponibilização do novo recurso. Precificação simplificada e diferenciada: Conforme já citado neste capítulo geralmente, a forma de investimento se dá através de assinaturas mensais, onde o cliente só paga pelo que utiliza, eliminando valores elevados de implantações de sistemas convencionais. Fast Deployment (Implantação Rápida) : A implantação dos serviços é instantânea, visto que o sistema já está disponível na rede, bastando, apenas liberálo para novos usuários. Customização: Softwares implementados dentro deste conceito podem ser facilmente adaptados às necessidades do cliente. Uso descentralizado: Com o desenvolvimento em camadas é possível disponibilizar o acesso em diferentes interfaces, além do navegador do PC do usuário. Celulares e PDA s são um dos exemplos de interfaces alternativas que podem acessar a ferramenta. Atualmente, as aplicações utilizam recursos como Feeds RSS, ical, flexibilizando a forma de acesso aos dados. Segundo a Tech Guide (Tech Guide,2008), para o desenvolvedor, as principais vantagens na utilização do SaaS são: Maior eficiência Maior Produtividade Agilidade no atendimento ao cliente Atualizações centralizadas

17 17 Compatibilidade entre versões É necessário listar algumas desvantagens ou limitações na utilização do conceito: Dependência de conexão com a Internet Dados/Arquivos armazenados em servidor de terceiros Disponibilização de informações confidenciais da empresa na rede As restrições listadas acima fazem com que tomadores de decisões, com um perfil tradicional, não contratem aplicativos estruturados desta maneira. À medida que as empresas desenvolvedoras vão atingindo um grau de maturidade maior, novos recursos vêm sendo agregados para que certas limitações sejam supridas. Atualmente, é possível acertar contratualmente a disponibilização de backups de dados e arquivos, na freqüência necessária, para clientes que tiverem esta necessidade. 2.1 Arquitetura Uma dos pontos mais importantes em uma arquitetura de sistemas é a escalabilidade que a mesma propicia. A Microsoft define escalabilidade da seguinte forma: "Escalar o aplicativo significa maximizar a simultaneidade e utilizar os recursos do aplicativo de forma mais eficiente, por exemplo, otimizando a duração do bloqueio, ausência de estado, compartilhamento de recursos agrupados como threads e conexões de rede, armazenamento em cache de dados de referência e particionamento de grandes bancos de dados" (Microsoft, 2008). Para consolidação de um aplicativo SaaS maduro, é necessária a identificação de alguns critérios. Estes critérios, estão separados em níveis de maturidade que padronizam alguns pontos importantes para elaboração dos sistemas.

18 18 Figura 1 - Representação dos níveis de maturidade do SaaS (Blogs MSDN, 2008) Nível I (Ad-Hoc/Personalizado) modelo onde cada cliente dispõe de uma instância isolada e executada de forma independente de outros inquilinos. Todas as personalizações são feitas sem preocupações com outros clientes, visto que a implementação do código é totalmente distinta e isolada Nível II (Configurável) modelo onde os clientes utilizam instâncias distintas, como ocorre no nível I, porém a implementação do código é a mesma. Neste nível, o provedor SaaS já fornece opções para o próprio cliente personalizar a aplicação, dentro dos limites estabelecidos. Nível III (Configurável e eficiente para vários inquilinos) modelo onde os clientes utilizam a mesma instância da aplicação, aplicando-se fortemente o serviço de metadados configuráveis, onde cada cliente pode adaptar as regras de negócio, níveis de acesso, configurações gráficas, etc. Nesta categoria, o serviço de segurança é fundamental para assegurar que, apesar de disponibilizar um ambiente único para execução da aplicação para vários clientes, jamais ocorrerá problemas de inconsistências de dados, no sentido de um

19 19 cliente ver dados de outros. Neste formato, a escalabilidade só é permitida verticalmente, ou seja, alterando toda a aplicação para um servidor com maior capacidade. Nível IV (Escalonável, configurável e eficiente para vários inquilinos) modelo que utiliza a mesma base do nível III, no que diz respeito ao compartilhamento de recursos e ao serviço de metadados para personalização da aplicação. O que diferencia este modelo é que ele possibilita um crescimento horizontal da aplicação, agregando recursos para aumento da escalabilidade. A grande característica utilizada neste caso é o balanceamento de carga de instâncias idênticas, de acordo com a demanda. O modelo de arquitetura SaaS é formado por quatro serviços básicos: Metadados Processos Negócios Segurança A integração destes itens pode ser observado na Figura 2.

20 20 Figura 2 - Modelo de Arquitetura SaaS (Blogs MSDN, 2008) Metadata Services (Serviços de Metadados): Este serviço é responsável por fornecer uma base para personalização e configuração do aplicativo SaaS, de modo que ele atende as necessidades do cliente. Basicamente, podemos classificar as alterações em quatro categorias: Alterações Gráficas, permite que o cliente padronize as características gráficas do sistema, seguindo a identidade visual de sua corporação (logotipo, cores, fontes) Alterações na Regra de Negócio, permite que o cliente opte por fluxos de trabalhos distintos, visando maior flexibilidade e identificação com as regras de negócio da empresa. Alterações no Modelo de Dados, permite que o cliente altere, de forma sucinta, o modelo de dados inicial, modificando tamanho e tipos de campos. De acordo com sua necessidade, é possível até criar novos campos nas tabelas, para completar aquilo que já é existente. Alterações no Controle de Acesso: O cliente é quem cadastra os usuários que irão interagir no sistema, bem como as restrições que cada um terá na aplicação.

21 21 Process Services (Serviços de Processos), Business Services (Serviços de Negócios) "Os serviços de processo mostram interfaces que clientes inteligentes e/ou a camada de apresentação da Web podem chamar e dão início a um fluxo de trabalho síncrono ou uma transação de longa duração que chamará outros serviços de negócios, o que interage com os armazenamentos de dados respectivos para ler e gravar dados de negócios." (Microsoft, 2008). Security Services (Serviços de Segurança) este serviço é o responsável pela segurança da aplicação SaaS. Ele está dividido em Autenticação e Autorização. Autenticação: Através da administração delegada, ou seja, o processo onde o próprio cliente cria e mantém as contas de permissões de usuários, as aplicações SaaS transferem a responsabilidade de gerenciamento de contas para os próprios inquilinos. Após a criação das contas, é realizado o processo de autenticação pelo provedor. Esta autenticação pode ser classificada de duas maneiras: Centralizada: O fornecedor gerencia um grande banco de dados, que possui a informação de todos os inquilinos cadastrados. Cada inquilino tem um administrador responsável por gerenciar suas contas de usuários. No momento em que algum usuário solicitar acesso ao sistema, seus dados são enviados para o diretório central, responsável pela validação de seus dados. Após este processo, caso os dados fornecidos estejam corretos, o acesso é liberado. Este tipo de autenticação inviabiliza a integração com serviços de Log-on corporativos. Descentralizada: A diferença desta modalidade é o acréscimo de uma camada de federação, onde o usuário se autentica de forma local. O sistema local emite um Token para o provedor SaaS e este realiza o restante do procedimento da mesma forma da apresentada anteriormente.

22 22 Autorização, o meio de acesso às funções do sistema pode ser configurado em forma de permissões de usuários. Desta forma, é possível liberar ou bloquear fragmentos das funcionalidades disponíveis. Além das permissões, o controle de acesso pode ser feito através das regras de negócio. Estas regras refinam o modo pelo qual o controle é feito, pois podem fazer referências a horários, estados do sistema e outras implicações que não estão diretamente ligadas às configurações do usuário. 2.2 Situação do SaaS no Mercado O modelo de negócio SaaS está em constante crescimento. É um novo modelo que promete tomar mercado de softwares voltados para empresas de pequeno e médio porte. De acordo com o IT Web (itweb, 2007), no ano de 2007 chegou ao orçamento de US$ 5,1 bilhões, representando um crescimento de 21% em relação ao alcançado em Em 2011 deverá chegar até US$ 11,5 bilhões de orçamento, o que equivale em um crescimento aproximado de 125 % desde os dias atuais, representando em um pequeno intervalo de 3 (três) anos comparado com o crescimento do ano de Em meio deste imenso crescimento podemos destacar, como responsável, os ramos de e-learning e conferência via Internet, com 70 % orçamento de todo o SaaS, enquanto setores de gerenciamento de conteúdo corporativo (EMC - enterprise content management) e pesquisas destinam somente 2% do orçamento. (itweb, 2007).

23 23 3 METODOLOGIAS E MELHORES PRÁTICAS Este capítulo define conceitos sobre metodologias e melhores práticas que serão abordadas durante todo o projeto de forma direta, ou seja, o nível de detalhe será dado até o ponto aonde irá o contexto deste documento. 3.1 PMI Gestão de Projetos O PMBOK sugere algumas práticas para gerenciamento de projetos. Estas práticas são compostas por grupos de processos e cada processo, possui suas respectivas disciplinas, conforme Tabela 1. Tabela 1 - Relação Processos x Disciplinas (autores, 2008) Processo Iniciação: Definir e autorizar o projeto ou uma fase do mesmo. Planejamento: Definir os objetivos e estratégias de implementação, planejando cada um das atividades a serem executadas, recursos pessoais, prazos e custos. Neste processo, o maior número de riscos também são identificados, evitando transtornos futuros Execução: Coordenar os recursos para execução do plano de projeto. Monitoração e Controle: Acompanha, em forma de medições e monitorações, o progresso do projeto. Este processo é importante para identificar desvios, com relação ao que foi planejado. Encerramento: Formaliza a entrega e aceitação dos produtos ou serviços projetados. Disciplina Integração: Termo de abertura, declaração de escopo preliminar do projeto Integração: Plano de gerenciamento do projeto Escopo: Planejamento e definição do escopo, WBS Tempo: Definição das atividades, bem como seu sequenciamento, durações, estimativas de recursos e criação do cronograma Custos: Estimativa de custos Qualidade: Planejamento da qualidade RH: Planejamento de recursos humanos Comunicações: Planejamento de comunicações Riscos: Identificação, análises quantitativas e qualitativas, planejamento de respostas Aquisições: Compras, aquisições e contratações Integração: Orientar e gerenciar a execução das atividades Qualidade: Realizar a garantia da qualidade RH: Contratar ou mobilizar recursos humanos, com o objetivo de formar a equipe do projeto Comunicações: Distribuição das informações Aquisições: Seleção de fornecedores Integração: Controle as atividades e as mudanças do projeto Escopo: Verificação e controle Tempo: Controle do cronograma Custos: Controle de custos Qualidade: Controle da qualidade RH: Controle da equipe Comunicações: Levantamento de relatórios de desempenho e realização de feedbacks para os Stake Holders Riscos: Monitoramento e controle dos riscos Aquisições: Administração do contrato Integração: Encerrar o projeto Aquisições: Encerrar o contrato

24 Engenharia de Software Metodologias Ágeis A metodologia ágil é indicada para desenvolvimentos complexos, de sistemas que possam variar as entradas, onde pode sofrer muita alteração durante o desenvolvimento. Por ser indicado para este tipo de sistemas, exige um monitoramento e controle mais regrado, contendo interações com maior freqüência. Esta metodologia geralmente é utilizada para novos produtos ou sistemas de inovação tecnológica, onde adere perfeitamente a estas necessidades. Este tipo de metodologia foca em desenvolver primeiramente as partes mais importantes e com mais valor do produto. Desta forma seria adequado o desenvolvimento de um sistemas SaaS, utilizando um modelo ágil, pois o SaaS é um produto fornecido normalmente via web, é uma inovação tecnológica e sofre freqüentes atualizações. Desta forma Como o scrum também é focado em desenvolver o que tem mais valor do produto, utilizando o scrum em um projeto SaaS seria possível ganhar dinheiro antes com o produto Metodologias Com a metodologia ágil é possível citar algumas já muito utilizadas no mercado de desenvolvimento, são elas: Unified Process (UP) Agile Project Management (APM) Scrum Extreme Programming (XP) Feature Driven Developpment (FDD) Agile Modeling (AM) Cada uma das metodologias definem "regras" de monitoramento e de controle das interações no processo de desenvolvimento, porem não devem ser

25 25 utilizadas como "regras", pois funciona como um conceito, sendo assim entendendo o conceito, é possível reinventar o processo criando novas metodologias que se adéqüem as necessidades de sua empresa. Após definida a metodologia ou a mistura delas, escreva e as transforme em novas "regras", não só do Scrum ou do XP, mas sim as suas "regras" de desenvolvimento Scrum O Scrum tem como principio desenvolver as coisas mais importantes, primeiro organizando as features e necessidades para o produto a través de um artefato chamado Backlog do Produto e Backlog de Interação, tudo organizado pelos responsáveis: Dono do Produto e Mestre Scrum. A equipe utiliza planilhas para este controle, normalmente utiliza interações de 2 (duas) ou 4 (quatro) semanas para os desenvolvimento, tudo organizado por fases bem definidas, tudo é um jogo de desenvolvimento. A Tabela 2 detalha os um projeto. Tabela 2 - Relação de Papéis no Scrum (autores, 2008) Papel Dono do Produto Mestre Scrum Equipe do Projeto Descrição Pode ser considerado como o cliente que será oferecido o serviço de desenvolvimento, ele será o responsável por definir juntamente com os interessados ao projeto quais são os requisitos gerais do produto, analisa juntamente com a equipe qual o valor de cada item no Backlog do produto. Assim gerando um ranking de prioridades. Este seria o similar a um gerente de projeto, ele é o responsável que as regras do Scrum estão sendo seguidas, além de remover possíveis obstáculos que venham a aparecer no andamento do desenvolvimento. O Mestre Scrum está mais para um líder de equipe do que para um gerente propriamente dito. Além disso, ele é responsável em ensinar o Dono do Produto a maximizar o ROI e a atingir seus objetivos, melhorar a vida da equipe através do Empowerment, manter informação sobre o progresso da equipe sempre atualizado. É o grupo de pessoas responsáveis por construir o projeto, a equipe geralmente contém entre 5 (cinco) e 10 (dez) pessoas sendo que o recomendado são 7 (sete) pessoas, pois um número maior que esse fica complicado manter a integração entre a equipe. As equipes são auto-gerenciadas, auto-organizadas e multifuncionais, composta de indivíduos de diferentes especializações, podendo ser composta por desenvolvedores em tempo integral e participantes externos (marketing, vendas, clientes e etc). 3.3 ITIL

26 26 Atualmente os negócios são altamente dependentes da TI. Conseqüentemente, a falha em algum componente que comprometa a disponibilidade de um serviço afetará diretamente o negócio. A filosofia ITIL adota uma estratégia orientada a processos que é escalável para atender tanto a grandes quanto a pequenas organizações de TI. Ela considera o gerenciamento de serviços em TI como um conjunto de processos estreitamente relacionados e altamente integrados. ITIL constitui uma documentação estruturada e consistente das melhores práticas para gerenciamento de serviços de tecnologia de informação. Diferente de metodologia, que detalha uma série de passos para realizar um trabalho, ITIL proporciona um arcabouço lógico ou modelo de referência. Previsão de ótimos serviços a custos justificáveis. O ITIL é descrito por um grupo de livros os quais descrevem as práticas para o gerenciamento de serviços de TI. A versão 2.0 do ITIL traz os seguintes livros como principais: Suporte ao serviço Entrega do serviço Perspectivas de negócios Gerenciamento da infra-estrutura Gerenciamento das aplicações Gerenciamento da segurança Planejamento da implantação do gerenciamento de serviços

27 27 4 CONCEBENDO O PROJETO SAAS COM O PMI Este capítulo apresenta um modelo de documentação para elaboração e gerenciamento do projeto de produto/serviço a ser criado. Os itens apresentados seguem as melhores práticas sugeridas pelo PMI. 4.1 Missão Propiciar que instituições educacionais consigam disponibilizar todos os serviços pertinentes ao aproveitamento, freqüência e situação financeira de seus alunos, de modo a ganhar em agilidade, confiabilidade e qualidade das informações. 4.2 Objetivos Elaborar um software, disponibilizando-o como um serviço na Internet, que tenha, de forma macro, os seguintes requisitos: Gerenciamento de alunos Gerenciamento de turmas Gerenciamento de professores Gerenciamento de disciplinas Controle de notas Controle financeiro 4.3 Premissas e Restrições Haverá um critério muito grande com relação aos prazos de finalização do projeto, pois no plano de marketing, temos atividades que contemplam a divulgação do serviço já com a data de disponibilização.

28 28 O orçamento da empresa é de R$ ,00. Desta forma, todos os investimentos deverão ser aplicados sobre este valor. Deveremos considerar a necessidade de expandir a equipe, contratando funcionários que serão fundamentais para cumprimento do prazo estipulado e a metodologia de trabalho escolhida. O provedor escolhido para armazenar o serviço a ser criado deverá ser bem conceituado no mercado, oferecendo segurança, confiabilidade e um SLA maior que 99,2%. 4.4 Obstáculos O pioneirismo no mercado é um item fundamental. Como já existem empresas que prestam este tipo de serviço, deverá ocorrer um preparo para superar a concorrência existente. 4.5 Estratégias Será realizada uma pesquisa em diversas universidades, com o objetivo de levantar os principais gargalos que existem na gestão de dados internos. Além de profissionais técnicos, a equipe será formada por um consultor da área educacional e um consultor na área administrativa/financeira. A equipe técnica será preparada para trabalhar com a elaboração do produto, em cima da metodologia ágil Scrum. 4.6 Análise de Viabilidade O crescimento de alunos nas universidades está fazendo com que a administração dos dados necessite ser cada vez mais eficaz. Esta nova demanda do mercado abre uma grande oportunidade para implantação de sistemas com este fim. O serviço, juntamente com uma boa organização por parte das instituições, fará com que este gargalo seja sanado de maneira satisfatória.

29 Plano de Projeto projeto SaaS. O plano de projeto descreve as etapas necessárias para a concepção do Escopo No ANEXO B, será apresentada, de maneira estruturada, as principais atividades do WBS do projeto Recursos Humanos A alocação de recursos está diretamente ligada com a fase em que o projeto se encontra. Inicialmente, haverá uma fase de especificação do produto a ser desenvolvido (F1). Na sequência, terá a fase de desenvolvimento (F2) e posteriormente de suporte (F3). Na figura 3, a lista de recursos humanos, com o respectivo valor/hora e fase do projeto em que se encaixa: Cronograma - Plano de Ação Figura 3 - Planilha de Recursos Humanos

30 30 Com base no cronograma apontado na Figura 4, grande partes das tarefas que compõem o projeto foram listadas. Nele é possível observar o nível de cada tarefa (WBS), o esforço, a duração, o início e término previstos, o recurso e custo correspondente. A estimativa de esforço para execução das tarefas (em horas) foi realizada com base em históricos de outros projetos da mesma espécie que a empresa já executou. Os profissionais-chave também deram sua contribuição para estimar as durações, com base na experiência adquirida por eles ao longo do tempo. Figura 4 - Cronograma do Projeto A tarefa "Desenvolver Produto" será detalhada em outro capítulo ("Desenvolvendo o Produto com Scrum"). Esta tarefa possui várias sub-tarefas, que foram omitidas neste cronograma Responsabilidades

31 31 Para se obter o conhecimento sobre todas as responsabilidades no projeto, no ANEXO C, há uma demonstração real sobre como estruturar uma planilha de controle de funções. Na Figura 5 é possível visualizar um exemplo de organograma da empresa desenvolvedora do sistema. Figura 5 - Organograma Gerenciamento de Riscos O plano de gerenciamento de riscos documenta as estratégias e procedimentos que serão utilizados, analisando qual metodologia, funções e responsabilidades, orçamento, freqüência, categoria de riscos, limites de tolerância, formatos de relatórios e acompanhamento. No processo de identificação todos os riscos possíveis devem ser listados, espaço, recursos, falta de competência do cliente, mudança de escopo, problemas com fornecedores, ações governamentais e riscos de mercado. Portanto esses critérios serão analisados. Na tabela 3 classificação de riscos, é possível visualizar as prioridades de resolução dos riscos, que serão classificados conforme os riscos da tabela 4.

32 32 Tabela 3 - Classificação de Riscos (autores, 2008) Baixo Requer um controle para que não aumente. Médio Necessidade de monitoração para redução do risco. Alto Necessidade de uma ação imediata para reduzir o risco. Os riscos podem ser identificados de formas diferentes: listas de checagem; entrevistas e reuniões; revisão do plano de projeto, processos e requisitos dos produtos; revisões e inspeções. Segundo Martins (2008, p ). Os riscos mais comuns, presentes na maioria dos projetos, estão mostrados no anexo B - Riscos de um projeto de desenvolvimento de software (Martins, 2007) Orçamento O objetivo deste item é demonstrar os custos associados ao projeto. Como o projeto em questão é para desenvolvimento de um software, o valor/hora para alocação dos recursos nas tarefas é a grande base para orçamentação, porém, demonstraremos também os valores referentes às despesas fixas com fornecedores e futuras entradas no caixa. O método utilizado para estimativa dos custos foi o bottom-up, pois necessitaremos de valores precisos nos levantamentos realizados. Nesta categoria, os custos são atribuídos nos níveis mais baixos do WBS, compondo, assim, o custo total do projeto Despesas Fixas - Fornecedores projeto. Na Tabela 4 é possível visualizar a relação de fornecedores envolvidos no Tabela 4 - Despesas Fornecedores (autores, 2008)

33 33 Fornecedor Categoria Valor Mensal Parcelas Locaweb Hospedagem R$ 3000,00 12 Telefônica Telefone / Internet R$ 500,00 12 Embratel Internet R$ 1000,00 12 Dell Computadores Computadores R$ 300,00 36 Posto Shell Deslocamento R$ 500,00 12 Claro Celulares / Internet R$ 600,00 12 Microsoft Softwares R$ 250,00 12 Sobre a Tabela 4 é importante categorizarmos a despesa para determinação de sua origem e influência no projeto Fluxo de Caixa Demonstração do fluxo de caixa, baseado no WBS do projeto conforme Figura 6 e o gráfico para análise na Figura 7. Figura 6 - Fluxo de caixa

34 34 Figura 7 - Relatório de Fluxo de Caixa do Projeto Orçamento orçamento. Na Figura 8 pode-se verificar um exemplo de acompanhamento do Figura 8 - Análise de orçamento Plano de Qualidade

35 35 O plano da qualidade contempla itens de controle e monitoramento do projeto, características que o produto/serviço a ser entregue deve possuir, bem como relatórios indicativos de rendimentos e andamento das atividades, conforme os itens apresentados: Seguir fielmente as datas estipuladas no cronograma Trabalhar dentro do orçamento planejado Seguir o plano de comunicação corretamente Monitorar o progresso das atividades Relatórios do Projeto Visão Geral: Resumo do projeto Tarefas de Nível Superior Tarefas Críticas Etapas Dias Úteis Atividades: Tarefas não-iniciadas Tarefas com início breve Tarefas em andamento Tarefas concluídas Tarefas que já deveriam ter iniciado Tarefas adiadas Atribuições: Uso dos recursos Uso das tarefas

36 Plano de Comunicação Nesta fase de comunicação serão definidas as informações que precisarão ser geradas, para quem e como serão distribuídas. Mestre Scrum. Será feita reuniões diárias de até 15 minutos com os programadores e o Em cada Sprint, começará com uma reunião de planejamento que não deve ultrapassar mais que 8 horas, onde o dono do produto e a equipe trabalham juntos, de forma colaborativa, para decidir o que será trabalhado até a próxima reunião. No plano cada pessoa precisará saber qual parte do projeto é de sua responsabilidade e deve compreendê-las. O mestre scrum deverá manter todos informados e em sincronismo com o projeto, reportando o status a todos os stakeholders para identificar os problemas e tomar medidas corretivas a tempo, essa comunicação para sincronização poderá ser feita através de , telefone e reuniões, onde o cliente poderá interagir no projeto ainda em desenvolvimento para evitar correções desnecessárias e perda de tempo. Haverá reunião de andamento do projeto para monitoração, onde irá manter todos informados, ter certeza de que a equipe dividiu as responsabilidades sobre os objetivos do projeto. As informações que serão distribuídas durante a execução aos interessados na periodicidade definida pelo mestre scrum, poderão ser distribuídas de forma escrita ou oral, podendo ser interna ou externo usando os mecanismos como reuniões, , documentos impressos, sistemas de computador e outros Contratos

37 Neste processo será avaliado o desempenho dos fornecedores, onde poderá haver uma empresa terceira para administrar as implicações legais dos contratos. 37 Segundo o PMBOK, citado por Martins (2007, p ), o processo de administração de contratos inclui, orientar e gerenciar a execução do projeto para autorizar o trabalho dos fornecedores no momento adequado. Elaboração do relatório de desempenho para monitoração dos custos do cronograma e desempenho técnico dos fornecedores. Inspeção e verificação do trabalho do fornecedor para realizar o controle de qualidade. Controle integrado das mudanças, incluindo sua aprovação e acompanhamento da sua implementação. Monitoramento e controle dos riscos pertinentes aos trabalhos dos fornecedores conforme contido no documento ANEXO D. O modelo do contrato sugerido está contido no documento ANEXO E Documentos complementares Os seguintes documentos são necessários para controle constante do projeto (Prontuário) e encerramento: Registros (Prontuário) Contratos (Prontuário) Alteração de escopo (Prontuário) Relatório de auditoria (Encerramento) Termo de encerramento (Encerramento) Relatório final (Encerramento)

38 38 5 DESENVOLVENDO O PRODUTO COM SCRUM Este capítulo trata do desenvolvimento do produto/serviço, com base no projeto já elaborado, utilizando técnicas de desenvolvimento ágil (Agile), com o Scrum. 5.1 Etapas de Desenvolvimento O desenvolvimento de sistemas utilizando a metodologia scrum, exige alguns ciclos para o desenvolvimento, na qual é dividido em 3 (três) grandes etapas, Pré-game, Game e Pós-Game Pré-game O pré-game é a etapa de desenvolvimento onde os responsáveis pelo projeto se reúnem e decidem quais são as features necessárias, quais os prazos a serem cumpridos e qual o orçamento disponível para o projeto. Para isso é necessário definir algumas informações especificadas neste capítulo. Planejamento: No planejamento é importe descrever quais são os requisitos funcionais e não funcionais, onde os requisitos funcionais representam as funcionalidades que serão implementadas no sistema, já os requisitos não funcionais representam os requisitos para funcionamento do sistema conforme exemplo no ANEXO G. Requisito de Qualidade: Nos requisitos de qualidade deve-se descrever qual o nível de qualidade que o sistema de seguir conforme exemplo no ANEXO G. Risco: Para a analise de riscos é necessário identificar alguns pontos no produto que tem muita importância.

39 39 Visão (Funcionalidades): Fase onde é descrito em forma de features, quais são as necessidades para o desenvolvimento do produto, neste momento será criado o backlog do produto, onde terá uma previsão de prazo de entrega de cada features e qual o custo estimado, desta forma será possível gerar as prioridades de cada uma das features. Recursos Humanos: Nesta etapa é necessário já identificar as equipes necessárias para o desenvolvimento dos itens do backlog do produto. Também é necessário definir-se quem são os responsáveis pelos principais papéis (Dono do produto, Scrum Master e Equipe do Projeto), também é necessário especificar qual o gasto mensal com cada um dos recursos envolvidos. Para o desenvolvimento deste produto foi definido pelos responsáveis do projeto a seguinte equipe: Dono do Produto Scrum Master A equipe de desenvolvimento foi formada da seguinte maneira: Emilio Peres Facas Luis Henrique de Moura Rafael Rodrigues Vieira Acelino Freitas Roberto Alberto David Souza Viviane Barrela Analista de usabilidade Analista de sistemas Analista de dados Desenvolvedor Web Pleno Desenvolvedor Web Júnior DBA Designer Arquitetura: É importante definir-se toda a arquitetura do sistema que será desenvolvimento para que facilite a manutenção no futuro e automaticamente melhorando a qualidade do sistema.

40 40 Estrutura de Desenvolvimento, na arquitetura do sistema a ser desenvolvido é importante frisar, como será organizado o sistema para que suporte a alta freqüência de mudanças, mesmo assim seja de fácil manipulação e fácil criação de novos módulos, para isso pode-se utilizar MVC e Designer Pattners. Framework de Desenvolvimento, para um desenvolvimento de qualidade é importe definir um Framework seguindo os padrões de estrutura citados no tópico Estrutura de Desenvolvimento, para assim ter um sistema maleável de forma que todos os integrantes da equipe saibam onde está cada parte do sistema e assim conhecer também todas as ferramentas fornecidas pelo sistema. Para do framework existem duas opções, Framework Prontos e Framework Próprio, conforme ANEXO H. Opção Escolhida: Optamos por utilizar um framework próprio, pois desta forma teremos o controle sobre todas as alterações e bugs existentes no core. Estimativa: Deve-se entender qual o tamanho do projeto, e qual a dificuldade do mesmo, e assim facilitando para gerar a prioridade das tarefas, esta estimativa é bem superficial, pois será refeito na hora do planejamento do sprint. Como ANEXO I constata um exemplo de como ficaria o backlog: Tempo/Tamanho de cada requisito Numero de Sprints Entrega dos Releases Custo do produto Game Este é o momento que todos envolvidos colocam a mão na maça de verdade, sempre seguindo o planejamento que foi feito no Pré-Game.

41 41 Reunião de Plano de Sprint, está reunião é escolhido juntamente com o Dono do Produto o Scrum Master e a equipe quais são as Features que serão atacadas nesta etapa. Assim fazendo uma reunião que é separada em 2 (duas) etapas. Onde a primeira etapa são discutidos quais serão as features e a segunda como será feito e o que envolverá para ser desenvolvido, será estabelecido quais serão as tarefas desenvolvidas neste momento e assim gerando um novo documento com o Backlog do Sprint. No ANEXO H pode-se visualizar um exemplo de backlog do produto. Trabalhando nas Tarefas, nesta etapa a equipe está trabalhando nas tarefas definidas na reunião de plano de Sprint e alimentando o documento do backlog do sprint, com o progresso das tarefas que estão sendo desenvolvidas, desta forma sairão indicadores de como a equipe está indo neste sprint. No ANEXO I pode ser visualizado um exemplo do gráfico de acompanhamento. Reunião diária do Sprint, está reunião deve conter todos os integrantes da equipe mais o Dono do Produto e o Scrum Master, está é feita diariamente, para acompanhamento e prevenção de problemas, reunião de no máximo 15 minutos. Reunião de Fechamento do Sprint, após o termino do sprint é feita uma reunião para que a equipe discuta os pontos positivos que ocorreram neste sprint e quais o pontos negativos, está reunião deve gerar um documento para que exista a melhoria constante, após esta reunião volta-se para o planejamento do novo sprint que se iniciará Pós-Game Quando o dono do produto e os patrocinadores do projeto decidem o momento de publicação das features desenvolvidas, é criado um novo sprint que tratará principalmente de testes e validações do que foi desenvolvido. Após a conclusão deste sprint é gerado um "pacote" que será aplicado na produção e versionado para que qualquer problema seja feita o retorno da versão com facilidade.

42 42

43 43 6 REALIZANDO O SUPORTE COM ITIL Este capítulo apresenta o modelo de documentação estruturada para o suporte e entrega do serviço a ser criado. Os itens apresentados seguem as melhores práticas sugeridas pelo ITIL v Missão Propiciar que instituições educacionais garantam que todos os serviços pertinentes a gestão educacional disponíveis para o acesso de forma confiável com garantia de qualidade na resolução de incidentes e suporte flexível, métricas e indicadores de atendimento, níveis de excelência na prestação do serviço. 6.2 Premissas e Restrições Haverá um critério muito grande com relação aos prazos de implantação do processo, pois existem outros orçamentos que comprometem os custos de TI o quais estão mencionados no item 4 CONCEBENDO O PROJETO SAAS COM O PMI. 6.3 Suporte ao Serviço Descreve os processos associados ao suporte do dia-a-dia e atividades de manutenção associadas com a provisão de Serviços em TI Gerenciamento de configuração Identificação e catalogação de todos os itens de configuração (IC) que compõem o BDGC (Banco de dados de gerência de configuração) a fim de mostrar a

44 representação lógica de cada componente da infra-estrutura de TI. O BDGC compõe hardware, software, documentação, pessoas, acomodações e componentes de rede. 44 fabricante, etc. Exemplo de atributos de um IC: Nome, nr. De série, versão, localização, Através deste gerenciamento podemos realizar auditorias, garantia de atualização, rastreabilidade e controle Central de serviços Implantar um único ponto de contato operacional para o tratamento de incidentes até a resolução. Necessita de pessoas articuladas e metódicas com habilidades interpessoais e discernimento dos negócios com consciência empresarial. As atividades que a central de serviços realizará são: Primeiro nível de suporte. Orientação e assistência cotidiana no uso dos serviços. Comunicação com o cliente. Monitoração dos incidentes. Escalação de acordo com o SLA: hierárquico ou funcional. Pesquisa de satisfação. A central de serviços estrategicamente ficará alocada de forma centralizada a qual receberá solicitações e chamados de diversas localidades. O modelo de formulário para registrar um chamado está no ANEXO J. O modelo de ciclo de vida de um chamado está no ANEXO L Gerenciamento de incidentes

45 45 O principal objetivo do processo de gerenciamento de incidentes é restabelecer a operação normal do serviço o mais rápido possível em conformidade com o nível de serviço acordado e as prioridades do negócio. Para que isto ocorra de forma eficaz à central de serviço deve classificar um chamado de forma correta. Um incidente é qualquer evento que não faz parte da operação padrão do serviço que cause, ou possa causar a interrupção ou degradação na qualidade do serviço. Requisição de serviço é um incidente que não representa uma falha, exemplo: um pedido de informação ou solicitação de um relatório. Além disso, precisamos combinar o impacto e a urgência os quais fornecerão a código da prioridade conforme Tabela 5. Impacto Urgência Baixo Médio Alto Alta Média Baixa Tabela 5 - Impacto x Urgência (autores, 2008) Impacto = criticidade para o negócio Urgência = velocidade O gerenciamento de incidentes se beneficiará do BDGC para identificar quais os IC s que geraram a possível falha no serviço. O modelo de planilha para controle de prioridades está no ANEXO M Gerenciamento de problemas O objetivo é evitar a repetição de incidentes a partir da solução definitiva dos mesmos. Um problema é a causa raiz desconhecida de um ou mais incidentes de

46 46 sintomas comuns. Um erro conhecido é quando temos um problema diagnosticado com sucesso, com a causa raiz identificada e com uma solução de contorno estabelecida. O foco do gerenciamento de problemas é chegar à causa raiz dos incidentes identificando, classificando e investigando. O foco do controle de erros é corrigir problemas através de mudanças e atualizar a base de erros conhecidos. Para isto devemos implantar a análise de tendências que é a ação pró-ativa na identificação de problemas e a base de erros conhecidos, desta forma podemos reduzir o volume de incidentes, aumentar a qualidade do serviço, aprender com os erros do passado e reduzir os custos de manutenção com TI. N. O modelo de planilha para realizar a análise de causa raiz está no ANEXO Gerenciamento de mudanças O objetivo é assegurar que sejam utilizados métodos para administrar as mudanças de tecnologia, a fim de prevenir incidentes e minimizar o tempo de interrupções nos serviços (Saas). Uma mudança do serviço disponibilizado necessita do registro através do formulário de solicitação de mudança, classificação (categorização e priorização), aprovação do comitê de controle de mudanças, agendamento da mudança, disponibilidade projetada de serviço, coordenação e a RPI (revisão pósimplantação). Um ponto importante a esclarecer é que a gerência de mudanças não realiza a mudança, mas avalia sua necessidade. Após a avaliação e aprovação do comitê, o formulário (RM requisição de mudança) será enviado para o setor de engenharia de software o qual realizará as devidas às mudanças.

47 Gerenciamento de liberações O objetivo é garantir que todos os aspectos da liberação sejam considerados em conjunto no ambiente de homologação. Vale ressaltar que os erros encontrados nesta etapa não serão classificados como incidentes, pois não se trata de um serviço em produção. Os erros encontrados fazem parte do processo de engenharia de software. Após todos os testes serem realizados, uma versão do software será liberada da seguinte forma: Delta (independente) Completa (componentes interdependentes) Pacote (uma ou mais mudanças) Emergência (pode ser delta ou completa, exceto pacote). Através do gerenciamento de liberações será possível gerar o versionamento do software na BSD (Biblioteca de software definitivo) a qual é a área de armazenamento físico para cópias de software em produção. Além disso, conterá a documentação dos incidentes relacionados à liberação ou requisições de mudanças a fim de manter o histórico e possíveis auditorias. serviços. Quem executa a liberação e comunicação com o cliente é a central de 6.4 Entrega de Serviços Cobre os processos necessários para o planejamento e entrega de Serviços em TI com qualidade e se preocupa ao longo do tempo com o aperfeiçoamento desta qualidade Gerenciamento do nível de serviço

48 48 forma: O objetivo é manter e melhorar a qualidade dos serviços de TI da seguinte O cliente define as necessidades e expectativas através da RNS (Requisição do nível de serviço). O comitê executivo define com o cliente o ANS (Acordo do nível de serviço) detalhando quais são os objetivos e responsabilidade de ambos. O comitê executivo define o ANO (Acordo de nível operacional) com o provedor de serviços de TI interno (área de engenharia de software). O setor de engenharia de software define o CA (Contrato de apoio) com o provedor de serviços de TI externo. A engenharia de software disponibiliza o catálogo de serviços de TI. O comitê executivo promove o programa de melhoria do serviço o qual tem foco na satisfação do cliente. Através destes insumos será gerado o contrato de acordo do nível de serviço (ANS) com os requisitos: Número de versão e datas de criação e de revisão Responsabilidades: TI e cliente Descrição do serviço de TI Horário de operação Disponibilidade do serviço Condições de suporte Meta de tempo para solução de incidentes Tempo de resposta das transações Controles de segurança da informação Condições da prestação de informes dos níveis de serviço Revisão dos serviços

49 49 Plano de continuidade do serviço. O processo do gerenciamento do nível de serviço é medido através do ciclo PDCA (Plan, Do, Check, Act) - Planejar, Executar, Verificar e Atuar. Desta forma é possível visualizar a melhoria contínua no software como um serviço. O modelo de contrato para o acordo com o nível de serviço está no ANEXO O Gerenciamento Financeiro O objetivo do gerenciamento financeiro é prestar contas das despesas de TI e apropriar aos serviços. O departamento de suporte fornecerá o custo efetivo dos ativos de TI usado no fornecimento de serviços e rateará para os clientes. Além disso, realizará o orçamento com a previsão dos gastos e investimentos para o exercício seguinte. Realizará a contabilidade, balanço e ROI, além de gerar o relatório para a cobrança do cliente. O modelo de planilha de faturamento está no ANEXO P Gerenciamento da capacidade O objetivo é assegurar a capacidade e desempenho às demandas atuais e futuras de forma preventiva, ou seja, assegurar que a capacidade corresponda às demandas atuais e evolutivas dos negócios, com atendimento de forma econômica e rentável, buscando sempre atualizações tecnológicas em conjunto com a área de engenharia de software.

50 50 Para que isto ocorra de forma eficaz o departamento de suporte deverá agir de forma pró-ativa com especialistas em novas tecnologias, realizar o gerenciamento de recursos com monitoração, análise e ajustes. Avaliar continuamente os recursos requeridos pela aplicação, realizar pilotos, protótipos e simulações para avaliar o comportamento do software sob um dado volume de informações, gerenciar cobrança diferenciada de acordo com a demanda. Atualizar o banco de dados da capacidade (BDC) e o plano da capacidade futuro Gerenciamento da segurança O objetivo é atender os requisitos de segurança da informação conforme os requisitos da Tabela 6. Tabela 6 - Requisitos de segurança (autores, 2008) Confidencialidade Ac es s o à inf or maç ão e s erviç os ap en a s p or pes s oas a ut orizadas. Integridade Altera ção da inf orma ção ape nas por pe ssoa s e procedi men tos autori zado s Disponibilidade I nfor m aç ã o e ser viços s em pr e di s po nívei s qu an do requ eri dos. Para que isto o ocorra de forma adequada o departamento de suporte definirá a política de segurança interna, com os riscos, impactos e vulnerabilidades da aplicação em conjunto com o departamento de engenharia de software Gerenciamento da disponibilidade O objetivo é entregar um nível de disponibilidade que atenda a necessidade do cliente, através de: Sustentabilidade (Contrato de acordo de nível de serviço) Oficiosidade (Contrato de apoio) Implementação da segurança Monitoração dia a dia dos serviços

51 51 A Tabela 7 indica o cálculo para os indicadores de disponibilidade dos serviços de TI. Tabela 7 - Indicadores de disponibilidade (autores, 2008) Uptime %Disponibilidade = (Tempo ANS downtime) x Tempo ANS TMEI (Tempo médio entre incidentes) %Disponibilidade = Tempo Real x Tempo ANS Gerenciamento da continuidade Garantir que os serviços possam ser recuperados nos tempos acordados. Para isto que isto ocorra de forma correta o plano de recuperação de desastres deverá ser implantado. Desta forma será possível manter o negócio em funcionamento durante uma interrupção devido à causa tecnológica, humana ou natural. As aplicações e dados precisam estar acessíveis para que os processos de negócio possam continuar a operar mesmo após a interrupção. A abordagem para a criação do plano B e procedimentos que serão regularmente testados e atualizados será fundamental para a continuidade dos serviços de TI. Tabela 8 - Plano de recuperação (autores, 2008) Recuperação gradual (horas/dias) Provisão de acomodações com energia elétrica, controle ambiental, cabeamento de rede e telecom pronto para instalação de computadores Recuperação intermediária (min / horas) Recuperação imediata (segundos / minutos) Uso de instalações comerciais específicas para a finalidade, geralmente compartilhadas - Neste caso o uso de Data center s de terceiros Uso de instalação alternativa que é mantida idêntica ao ambiente de produção, geralmente como espelhamento dos servidores.

52 52

53 53 7 CONCLUSÃO O SaaS demonstra a evolução da Tecnologia da Informação, em forma de disponibilização de serviços. Como isto é uma tendência de mercado, o documento descrito servirá como uma referência para elaboração de projetos desta espécie. Todos os tópicos abordados são apenas sugestões que, sendo integradas, ajudarão no sucesso do que foi proposto. A proposta de software como serviço tem como objetivo final reduzir os custos com licenças de softwares, atualizações constantes de hadwares e outros requisitos que tornam o orçamento de TI elevado. Além de custos reduzidos outro fator importante é a velocidade de implementação. O cliente poderá avaliar o produto mais rapidamente e facilmente adaptar a sua necessidade. Os níveis de serviços acordados mostram a qualidade do produto e apresenta a maturidade dos processos de desenvolvimento de software das empresas que o fornecem, esses acordos estabelecem multas, penalizações ou descontos caso ocorra alguma falha no produto. Devido a crescente atualização tecnológica e cada vez mais pessoas conectadas através de dispositivos móveis, o modelo SaaS é a tendência natural do desenvolvimento de softwares. A agilidade na troca de informação e colaboração on-line de dados, será o diferencial competitivo das empresas que utilizaram o SaaS.

54 54 REFERÊNCIAS Brasil está preparado para SaaS. (15 de 01 de 2008). Acesso em 04 de 05 de 2008, disponível em ITWeb: Carraro, F. C. (04 de 05 de 2008). Estratégias de Arquitetura para Cauda Longa (Long Tail) - SaaS. Acesso em 04 de 05 de 2008, disponível em Microsoft: Koscianski, A. (2006). Qualidade de Software. São Paulo: Novatec. Martins, J. C. (207). Gerenciando Projetos de Desenvolvimento de Software com Pmi, Rup e Uml. São Paulo: Brasport. Pressman, R. S. (2006). Engenharia de Software. McGraw-Hill. CCTA. (2001). Service Support - ITIL The Key to Managing IT services IT Infrastructure Library. OGGC: CCTA, ISBN: , ISBN-13: CCTA. (2001). Service Delivery - ITIL The Key to Managing IT services IT Infrastructure Library. OGGC: CCTA, ISBN: , ISBN-13: Acesso em 05 de 05 de 2008, disponível em PMI-MG: IT Service Management Forum Brasil Heldman, K. (2003). Gerência de projetos - PMP Project Management Professional. Rio de Janeiro: Campus. Keelling, R. (2002). Gestão de Projetos %u2013 Uma abordagem global. São Paulo: Saraiva. Martins, J. C. (2002). Gestão de Projetos de Desenvolvimento de Software. Rio de Janeiro: Brasport. Phillips, J. (2003). Gerência de projetos de tecnologia da informação. Rio de Janeiro: Campus. PMI-SP. (s.d.). Acesso em 02 de 05 de 2008, disponível em Martins, J. C. (2002). Gestão de Projetos de Desenvolvimento de Software. Rio de Janeiro: Brasport.ISBN PMI. (s.d.). Acesso em 03 de 05 de 2008, disponível em Profissionais de gerenciamento de projetos. (s.d.). Acesso em 03 de 05 de 2008, disponível em PMI-MG: Heldman, K. Gerência de Projetos. Editora Campus, ISBN %u VALERIANO, Dalton, Moderno gerenciamento de projetos, São Paulo: Prentice Hall, 2005, 254p, ISBN:

55 Bibliografia Erich Gamma, R. H. (2000). Padrões de Projeto - Soluções Reutilizáveis de Software Orientado a Objetos. Porto Alegre: Ed. Bookman. Jennifer Greene, A. S. (2008). Use a Cabeça PMP. Rio de Janeiro: Alta Books. Sommerville, I. (2005). Engenharia de Software 6 edição. São Paulo: Abril. Teles, V. M. (01 de 04 de 2008). Acesso em 17 de 04 de 2008, disponível em improveit: Tonsig, S. L. (2003). Engenharia de Software. São Paulo: Futura. 55

56 56 GLOSSÁRIO Agente Também conhecido como agente de atendimento, operador, atendente ou representante. É o responsável pelo atendimento das chamadas que chegam a um call center ou pela realização de chamadas externas como em campanhas de telemarketing. PMI: Entidade internacional sem fins lucrativos que congrega os profissionais de áreas relacionadas a gerência de projetos. Eles foram os responsáveis pela elaboração de uma série de procedimentos que visam padronizar a teoria associada a gerência de projetos. PMP: Profissional que aplica os padrões do PMI PMBOK: Documento que formaliza os procedimentos criados pelo PMI Stakeholders: Partes interessadas no projeto (gerentes, equipe, cliente) WBS: Estrutura analítica do projeto, representada em forma de diagrama ROI (Return on Investment): Retorno do investimento Empowerment: Delegação do poder, descentralização dos processos de tomada de decisão, delegação de autoridade a todos os níveis. Release: consiste da liberação pública de uma nova versão de um produto de software. Backlog: Diferença entre a capacidade de fornecimento ou instalação de produtos e serviços ea demanda existente por estes produtos ou serviços. Backlog do Produto: Local centralizado com a lista de necessidades do produto. Subversion: Software de controle de versões para código fonte de linguagens de programação. Código Fonte: Codificação legível de determinada linguagem. Software: Sistema informatizado BUG: Falhas/Erros encontrados em um sistema computacional WebServer: Servidor de serviços web. Ajax: Tecnologia utilizada para comunicação da pagina diretamente com a aplicação. JavaScript: Linguagem de programação que é interpretada pelo navegador de internet. Features: Novas implementações definidas para um sistema. Sistemas Operacional: Sistema base para rodar em um computador. Orientação a Objetos: Conseito/Paradigma para desenvolvimento de sistemas, Sistema Portável: Um sistema que pode funcionar em mais de um local diferente sem alterações em seu codigo fonte Core do Sistema: Nucleo do sistema, coração parte vital para o software. Happy Hours: Comemoração feita após o horario de serviço, muito utilizado para integração. Servidor Remoto: Servidor de algum serviço que está hospedado em outro lugar fisico. SSL: Certificado de segurança digital utilizado para sites que tenham interações que necessitem de segurança. Client: Sistema para que seja utilizado um serviço remotamente. Instâncias: Replicações sistemicas de um determinado ambiente (confome contexto) Escalabilidade: Possibilidade de crescimento conforme necessidade. Logotipo: Marca visual que representa uma empresa. Modelo de Dados: Modelo estrutural representativo para armasenagem de dados.

57 Autenticação: Verificação da veracidade de algo. Autorização: Verifica se tem permissão para algo. Banco de Dados: Sistema de armazenagem de informações de dados. Logon: Ato de efetuar autenticação. Token: Em computação é um segmento de texto ou símbolo que pode ser manipulado por um parser Fragmentos: o tempo de transição para bits individuais numa sequência pseudorandômica. Também conhecido como circuito integrado. Metodologias: Toda forma que você utiliza para determinar a forma mais correta e sem viés (sem erros) para que a sua pesquisa tenha um padrão mais científico de pesquisa e não seja constestada por falta de critérios científicos. Sprint: Interações da fase de desenvolvimento da metodologia SCRUM, pode ser interações de 2 ou 4 semanas. SLA: Contrato entre um prestador de serviço eo cliente que estipula e compromete o prestador de serviço com um determinado nível de serviço. 57

58 58 ANEXOS ANEXO A APRESENTAÇÃO

59 59

60 60

61 61

62 62

63 7.1 63

64 64 Anexo B # Categoria Ação 1 Deficiência de capacitação técnica da equipe Considerar contingência de tempo nas estimativas de tempo das fases iniciais do projeto para treinar o pessoal. Manter reservas de recursos extras de pessoal. Criar um programa de treinamento para a equipe. Conduzir sessões de treinamento 2 Excesso de mudanças nos requisitos 3 Requisitos pouco precisos 4 Indisponibilidade de recursos humanos 5 Decisões externas causam mudanças forçadas no projeto 6 Não consegue atingir os requisitos de performance cruzado entre os membros da equipe. Obter aceite formal do cliente para os requisitos já documentados. Negociar mudanças de custo e prazo com o cliente, para cada mudança de registro, e obter aprovação formal. Definir um procedimento para lidar com as solicitações e aprovações de mudanças de requisitos. Negociar pagamento para os trabalhos já executados. Usar a experiência anterior e a lógica para estabelecer premissas, manter o cliente informado e obter aprovações formais do Cliente. Desenvolver protótipos e fazer revisões dos requisitos junto com o cliente. Garantir que os recursos estejam associados às atividades do caminho critico do projeto. Fazer sessões de montagem de equipe. Rotacionar as funções entre os membros da equipe. Manter contingência de recursos humanos. Seguir as diretrizes e processos de gerenciamento de configuração. Listar as desvantagens com os argumentos e fatos pertinentes e negociá-las com as pessoas responsáveis pelas decisões Se for inevitável, aplicar o plano e gerenciamento de riscos. Verificar criteriosamente os requisitos de performance e revisá-los com o cliente.

65 65 Revisar a especificação técnica do produto. Simular, através de protótipos, a performance das transações criticas. Fazer testes com volumes de dados que sejam representativos. 7 Cronograma não realista Negociar prazos realistas com o cliente e fornecedor, principalmente se as atividades do caminho crítico estiverem fora do prazo. Identificar atividades que possam ser executadas em paralelo. Obter recursos com antecedência. Identificar tarefas do projeto que possam ser automatizadas. Negociar pagamento por esforço (contrato por administração ou preços unitários). 8 Uso de novas tecnologias de hardware e software 9 Conhecimento insuficiente do negócio 10 Falhas de comunicação ou baixa performance Considerar a divisão do projeto em fases, para disponibilizar múltiplas versões do produto. Disponibilizar primeiro os módulos mais críticos. Incluir uma contingência de prazo no cronograma para estudo e aprendizado. Providenciar treinamento para a equipe. Desenvolver um protótipo de prova de conceito. Aumentar a integração com o cliente e garantir a transferência de conhecimento. Providenciar treinamento no domínio do negócio. Criar protótipo para simular as transações de negócio e obter aprovação do cliente. Definir claramente as expectativas do cliente. Planejar-se antecipadamente para o nível adequado de carga. Planejar par o nível normal e para os picos.

66 66 ANEXO C PRINCIPAIS ATIVIDADES WBS 1. Iniciação 1. Analisar o mercado 2. Definir a estratégia de negócio 3. Declarar o escopo preliminar - visão do produto 2. Planejamento 1. Elaborar planejamento financeiro 2. Elaborar plano de marketing 3. Elaborar plano comercial 4. Planejar compras e aquisições do projeto 5. Definir plano de desenvolvimento do produto 6. Definir plano de suporte ao produto 7. Definir plano de suporte ao usuário 8. Definir plano de treinamento ao usuário 9. Definir equipe de desenvolvimento 3. Execução 1. Contratar fornecedores 2. Mobilizar / contratar equipe do projeto 3. Distribuir informações entre os stakeholders 4. Desenvolver o produto 5. Elaborar documentação técnica 6. Elaborar manual do usuário 7. Divulgar o produto na mídia 8. Comercializar o produto

67 67

68 68 ANEXO D RESPONSABILIDADE Empresa Colaborador Cargo Responsabilidade Raul de Souza Cavalcante Analista de negócio Avalia as necessidades dos clientes, levantamento de necessidades de sistemas específicos para o processo, identificando e sugerindo inovações no software existente ou aquisição de softwares apropriados, de forma que permita atender todas as necessidades do negócio no menor tempo e custo, com a melhor qualidade; Coordena/orienta os trabalhos dos consultores externos e fornecedores de serviços de informática, no desenvolvimento e/ou lançamento de novos produtos, com a finalidade de viabilizar o atingimento de metas e objetivos dos negócios. Alexandre Cavalcanti Galvao Analista de processo Auxilia na avaliação das necessidades dos clientes, decidindo pela viabilidade de sistemas específicos para o processo. Auxilia na identificação e sugere inovações no software existente ou aquisição de software apropriado, de forma que permita atender todas as necessidades do negócio no menor tempo e custo, com a melhor qualidade. Ajuda a coordenar/orientar os trabalhos dos consultores e fornecedores de serviços de informática, no desenvolvimento e/ou lançamento de novos produtos. Soluciona problemas de complexidade média. Domina parte das atividades de sua função. Trabalha sob supervisão geral. Emilio Peres Facas Fernando Soares de Oliveira Neto Analista de usabilidade Representante comercial Elabora um roteiro de testes contendo uma lista de tarefas, de acordo com as necessidades estratégicas do cliente, cujo objetivo será avaliar, em condições reais, a usabilidade e funcionalidade da interface. Acompanha todo o processo, desde o pedido do cliente, a entrega ao cliente e também o acompanhamento no que se refere aos prazos, quantidade, qualidade, todo o processo de logística e

69 69 Priscila Garcia Luis Henrique de Moura Rafael Rodrigues Vieira Aparecido Rodrigues Acelino Freitas Roberto Alberto David Souza Analista de marketing Analista de sistemas Analista de dados Líder de desenvolvimento Desenvolvedor Web Pleno Desenvolvedor Web Júnior DBA cumprimento dos pagamentos. Estudo de mercado, macroeconomia e conhecimento de potencial de mercado Acompanha o levantamento das necessidades do cliente, participa da construção do modelo de dados(conceitual) do sistema a ser desenvolvido. Atua com os programadores do sistema. Soluciona problemas de baixa complexidade.possui conhecimento acadêmico para solucionar os problemas simples da área. Demanda supervisão direta Planejador assegura que todo dado relevante tenha sido analisado apropriadamente antes das decisões. Acompanha a codificação, depuração e testes para o desenvolvimento de sistemas. Interage com os analistas de maior conhecimento. Soluciona problemas de baixa complexidade.possui conhecimento acadêmico para solucionar os problemas simples da área. Demanda supervisão direta. Atua na codificação, depuração e testes para o desenvolvimento de sistemas. Em alguns casos participa do levantamento das necessidades do cliente, além de também contribuir na construção do modelo conceitual do sistema a ser desenvolvido. Repassa as instruções para os profissionais de menor conhecimento. Soluciona problemas de média complexidade.domina a maioria das atividades de sua função. Trabalha sob supervisão geral Participa da codificação, depuração e testes para o desenvolvimento de sistemas. Contribui na construção do modelo conceitual do sistema a ser desenvolvido. Soluciona problemas de menor complexidade.domina parte das atividades de sua função. Demanda supervisão direta. Responsável pela validação de modelo de dados, assegurando a integração dos dados ao modelo corporativo das empresas. Efetua a padronização das nomenclaturas,

70 70 Viviane Barrela Rodrigo Rezende Ferreira Rubem Gontijo Cardoso Sergio Gabriel Domingos Vinicius Sena de Lima Designer Atendente Nível I Atendente Nível II Atendente Nível III Analista de Suporte dicionarização de dados, elaboração de Modelos de Entidades e Relacionamentos. Efetua a concepção, o desenho e realiza a manutenção do modelo corporativo do banco de dados. Interage com os profissionais responsáveis pelo desenvolvimento e/ou contratação de sistemas para a empresa, objetivando a melhor adequação dos novos modelos ao modelo corporativo. Desenvolve relatórios usando componentes visuais e recursos. Atendente aos clientes em primeiro nível. Atendente aos clientes em segundo nível. Atendente aos clientes em terceiro nível, responde s para os clientes ao seu alcance. Responsável pela área de suporte, visão sistêmica, organização e foco em resultados. Faculdade Roberto Justos Diretor da faculdade Responsável pela estrutura da faculdade, expondo suas necessidades para melhoria do projeto. Vitor Barros Rego Representante de TI Responsável por toda área de TI da faculdade, estuda o software junto com o Diretor que melhor atende suas necessidades. Talita Leão de Almeida Auxiliar Administrativa Responsável pela administração do sistema na faculdade, tendo outras funções administrativas. Monica Severo Pereira Gomes Administradora do sistema Tem como responsabilidade a administração do sistema por completo.

71 71 ANEXO E EMPRESAS FORNECEDORAS Empresa Locaweb Embratel Agt Consultoria de Sistemas SA Claro Dell Computadores HP Silvel imobiliaria Faculdade Posto Shell Microsoft Serviço Prestado Responsável pelos servidores da empresa. Fornece link para empresa. Fornece serviço de consultoria de negocio. Telefonia móvel usada pela empresa. Desktops/Notebooks utilizados pela empresa. Servidores da empresa. Responsável pela locação do imóvel. Usuário do sistema fornecido. Fornece combustível para transporte. Sistema Operacional usado em estações de trabalho.

72 72 ANEXO F MODELO CONTRATO CONTRATANTE - (Empresa contratante), com sede em (xxx), na Rua (xxx), nº (xxx), bairro (xxx), Cep (xxx), no Estado (xxx), inscrita no C.N.P.J. sob o nº (xxx), e no Cadastro Estadual sob o nº (xxx), neste ato representada pelo seu diretor (xxx), (Nacionalidade), (Estado Civil), (Profissão), Carteira de Identidade nº (xxx), C.P.F. nº (xxx), residente e domiciliado na Rua (xxx), nº (xxx), bairro (xxx), Cep (xxx), Cidade (xxx), no Estado (xxx); CONTRATADO - (Empresa contratada), com sede em (xxx), na Rua (xxx), nº (xxx), bairro (xxx), Cep (xxx), no Estado (xxx), inscrita no C.N.P.J. sob o nº (xxx), e no Cadastro Estadual sob o nº (xxx), neste ato representada pelo seu diretor (xxx), (Nacionalidade), (Estado Civil), (Profissão), Carteira de Identidade nº (xxx), C.P.F. nº (xxx), residente e domiciliado na Rua (xxx), nº (xxx), bairro (xxx), Cep (xxx), Cidade (xxx), no Estado (xxx). Cláusula I - Do objeto A Contratada concorda em realizar serviços de que constituem o Anexo P desse Contrato. Cláusula II - Do prazo Os serviços a que se refere à cláusula antecedente serão concluídos e postos à disposição da Contratante no prazo de (...) dias, contados da assinatura deste Contrato, podendo estender-se mediante adendo contratual. Cláusula III - Da remuneração A Contratante pagará por tais serviços o valor bruto global de R$... (...) contra a apresentação e a aceitação do relatório final, conforme estabelecido. 1 O pagamento dos serviços será feito em...(...) parcelas de acordo com o cronograma de desembolsos e orçamento apresentado no Anexo "...", parte integrante deste contrato. 2 As despesas de transporte e material necessárias ao desenvolvimento das atividades e produtos serão custeadas pelo...(contratante / Contratada). 3 Os pagamentos serão efetuados na conta bancária em nome de..., Banco..., agência..., conta corrente nº..., na praça de... (Cidade e Estado). 4 Quando do pagamento de cada parcela à Contratada, esta firmará o respectivo recibo, nos termos do modelo que integra o presente como Anexo "...". 5 (Para o caso de pessoas físicas) Para o pagamento de honorários de..., caso o mesmo não possua registro de autônomo, a Contratante descontará do seu pagamento...% de imposto. No caso de pagamentos mensais de honorários que excedam o limite da legislação brasileira para isenção de imposto de renda, a Contratante também descontará do valor a ser pago ao consultor o montante equivalente ao Imposto de Renda, de acordo com a tabela da Receita Federal. Cláusula IV - Das obrigações do Contratado O Contratado se compromete a utilizar qualquer informação e/ou documentos obtidos da Contratante, ou proporcionados por ela para fins do presente Contrato, exclusivamente para as atividades aqui estipuladas.

73 1 Este Contrato não poderá ser cedido, no todo ou em parte, ressalvada a concordância expressa, escrita, de ambas as partes. Cláusula V - Das obrigações da Contratante 1 Serão de responsabilidade da Contratante o custeio das despesas de... (transporte, hospedagem, material, comunicação, reprodução, etc.) realizadas pelo Contratado na execução dos serviços estipulados neste contrato, mediante...(reembolso, solicitação prévia por escrito, adiantamento, outra modalidade). Cláusula VI - Da Liberação dos pagamentos Todos os pagamentos previstos neste instrumento serão liberados e realizados após aprovação formal pela Contratante, no que diz respeito à qualidade do trabalho apresentada pela Contratada. Cláusula VII - Das alterações Qualquer modificação que afete os termos, condições ou especificações do presente Contrato deverá ser objeto de alteração por escrito com anuência de ambas as partes. Cláusula VIII - Do foro O foro deste contrato é o da Comarca... Estado de... com preferência sobre qualquer outro. E, por estarem assim justas e contratadas, as partes assinam o presente instrumento em 2 (duas) vias de igual forma e teor, para um só efeito. (local),... de... de Contratante Contratada Testemunhas a)... b)...

74 ANEXO G BACKLOG PRODUTO 74