[Seminário] Gerenciamento Ágil de Projetos de Software

FACULDADE ANHANGUERA DE CAMPINAS

UNIDADE III

Thiago luciano STEFANELLI – ra 0941464430

joão paulo de souza santos – ra 0970475006

Gerenciamento Ágil de Projetos de Software

Campinas

2011

O Gerenciamento Ágil de projetos de software foi criado a partir de valores e princípios discutidos no Manifesto para Desenvolvimento Ágil de Software em 2001. É considerado uma nova plataforma de gerenciamento de projetos, que é aplicado em ambientes que sofrem constantes mudanças, em que o método de gerenciamento de projetos clássico não se aplica.

O objetivo desse tipo de gerenciamento é se desfazer de antecipações de ações e atividades do gerenciamento clássico, buscando o desenvolvimento da visão de futuro e capacidade de exploração. Para que o processo de exploração tenha sucesso, tem base em cinco objetivos:

1. Inovação contínua: entregar ao cliente, produtos que atendam as necessidades e superem as expectativas. Estímulo do autogerenciamento e autodisciplina em organizações que possuam tal cultura;

2. Adaptabilidade do produto: produtos entregues aos clientes devem atendê-los no presente e ser adaptáveis no futuro;

3. Tempos de entrega reduzidos: equipes altamente técnicas e focadas são fundamentais para o desenvolvimento de produtos que retornem investimentos.

4. Capacidade de adaptação do processo e das pessoas: equipes formadas por profissionais que superem mudanças e desafios em ambientes dinâmicos;

5. Resultados confiáveis: entrega de produtos com valor agregado que proporcionem o aumento de lucratividade da organização.

O Gerenciamento Ágil de Projetos é visto como resposta às pressões por constantes inovações, redução dos ciclos de desenvolvimento e implantação de novos produtos ou serviços e adaptação a um ambiente de negócio bastante dinâmico.

Definição, Valores e Princípios do Gerenciamento Ágil de Projetos

O Gerenciamento Ágil de Projetos é um conjunto de valores, princípios e práticas que auxiliam a equipe de projeto a entregar produtos ou serviços de valor em um ambiente desafiador. Os valores e os princípios descrevem o porquê do gerenciamento e as práticas como realizá-lo.

O Gerenciamento Ágil possuem quatro valores centrais:

1. Respostas às mudanças são mais importantes que o seguimento de um plano. Caracterizado por processos que enfatizam a visão do futuro e a exploração, ao invés do planejamento detalhado e a respectiva execução.

2. Entrega de produtos está acima da entrega de documentação. Não se trata de desconsiderar a importância da documentação, mas assumir que os resultados só podem ser avaliados pela equipe de projeto e pelo cliente quando algo concreto é apresentado.

3. Priorização da colaboração do cliente sobre a negociação de contratos. Deve ser estabelecida uma parceria entre o cliente e a equipe de projeto.

4. Os indivíduos e suas interações são mais importantes que os processos e as ferramentas. Os processos servem como guias e as ferramentas utilizadas para melhorar a eficiência, mas sem pessoas com qualificações técnicas e comportamentais adequadas, nenhum processo ou ferramenta produz resultado algum.

Ciclo de vida e Fases do Gerenciamento Ágil de Projetos

Apesar dos processos não serem tão importantes quanto as pessoas, o Gerenciamento Ágil defende não atribuir excessos de documentação e padronização, por isso deve ter foco no conceito de agilidade e assegurar o alcance dos objetivos de negócio. Por isso deve:

· Favorecer a exploração e a cultura adaptativa;

· Permitir a auto-organização e autodisciplina;

· Promover a confiabilidade e a consistência possíveis, dados o grau de incertezas e a complexidade inerentes ao projeto;

· Ser flexível e facilmente adaptável;

· Permitir visibilidade ao longo do processo;

· Incorporar o aprendizado;

· Englobar as práticas específicas de cada fase;

· Prover pontos de verificação;

O Gerenciamento Ágil de Projetos possui uma etapa inicial, seguida por vários ciclos ou iterações. A cada ciclo é feito um novo planejamento de escopo, prazo, custo e qualidade, visando à entrega de produtos ou resultados e possibilitando incrementos de funcionalidades conforme a necessidade do negócio. É estruturado em cinco fases:

1. Visão: determinação da visão do produto e escopo do projeto, definição da comunidade do projeto e definição de como a equipe de projeto trabalhará em conjunto;

2. Especulação: identificação dos requisitos iniciais para o produto, definição das atividades, desenvolvimento de um plano de projeto, incorporação de estratégias para minimização de riscos, estimativas de custos e outras informações financeiras;

3. Exploração: entrega de produtos planejados através do gerenciamento da carga de trabalho;

4. Adaptação: revisão de resultados entregues, análise da situação atual e avaliação de desempenho da equipe e projeto;

5. Encerramento: finalização das atividades do projeto.

No decorrer do projeto, as fases de especulação, exploração e adaptação se alternam, de modo a aperfeiçoar os produtos do projeto e a etapa de especulação é retomada a cada ciclo e, somente, após a obtenção do produto final, chega-se a fase de encerramento.

Práticas do Gerenciamento Ágil de Projetos

O Gerenciamento Ágil de Projetos possui um conjuntos de práticas para serem implementadas em cada uma de suas fases.

Práticas da Fase Visão

Na fase visão é identificado o que precisa e como deve ser feito o trabalho. As práticas dessa fase são estruturadas em visão do produto, escopo do projeto, comunidade do projeto e abordagem.

1. Visão do produto: desenvolvimento de um conceito e arquitetura do produto de forma a garantir o entendimento a todos os envolvidos

2. Escopo do projeto: documentação do objetivo principal do projeto, que descreva prazo, custos, recursos, qualidade e riscos do projeto.

3. Comunidade do projeto: definição da equipe do projeto, identificação das partes envolvidas e estabelecimentos de papéis e nível de envolvimento entre as partes envolvidas no projeto.

4. Abordagem: estabelecer a forma de trabalho em conjunto da equipe de projeto.

Práticas da Fase Especulação

As práticas dessa fase são divididas em estrutura analítica do produto e planejamento de entregas.

1. Estrutura analítica do produto: definição de funcionalidades do produto e documentação para registro de funcionalidades e requisitos do produtos e prazo para desenvolvimento.

2. Planejamento das entregas: desenvolvimento de roteiro para ser seguido pela equipe de projeto para a entrega do produto.

Práticas da Fase Exploração

Conjunto de práticas que proporcionam ao gerente de projeto o acompanhamento e desenvolvimento de uma equipe com alto desempenho e promover inovação e encorajamento à equipe. As práticas são divididas em entrega segundo os objetivos, práticas técnicas e comunidade do projeto.

1. Entrega segundo os objetivos: atribuição de responsabilidades aos integrantes do projeto.

2. Práticas técnicas: redução de custos ao longo das fases do projeto, mas com o objetivo de entregar valor ao cliente “hoje” com olhos no futuro.

3. Comunidade do projeto: desenvolvimento constante da equipe de projeto, reuniões para coordenação das atividades do projeto, realizações de reuniões com cliente para garantir o atendimento de suas expectativas.

Práticas da Fase Adaptação

A prática da fase adaptação é definida como revisão do produto/projeto/equipe e ações de adaptação. Devem ser realizados feedbacks frequentes para garantir que as funcionalidades, qualidade, desempenho da equipe e progresso estejam acontecendo corretamente no projeto.

Práticas da Fase Encerramento

Essa fase é marcada pela celebração, que tem o propósito de reconhecer e marcar o encerramento do projeto e, a limpeza de eventuais itens em aberto, entrega da documentação final e relatórios financeiros e administrativos requeridos.

Comparação: Gerenciamento Clássico e Gerenciamento Ágil de Projetos

Com relação aos processos, e em comparação ao método clássico de desenvolvimento de projetos, o gerenciamento ágil dá foco à execução ao invés do planejamento, visando à entrega de valor ao cliente e à apresentação de resultados ao longo do projeto e adaptação ao invés de controle, o que permite alterações substanciais de escopo a cada ciclo ou interação, de forma a atender mudanças de requisitos.

Com relação à área de conhecimento, o gerenciamento ágil de projetos aborda todas as áreas do gerenciamento clássico, porém dá foco diferenciado à entrega de valor ao cliente, respostas rápidas às necessidades de mudanças e valorização do indivíduo.

[Seminário] Estimativa de software

Seminário Engenharia de Software

Cleiton Urban Silva RA: 0991003417

Fabio Barros Mateus RA: 0901404282

Estimativa de software

Quando nos deparamos com obstáculos para desempenhar nosso trabalho com eficiência, precisamos buscar alternativas para corrigi-los e ferramentas a fim de diminuir as porcentagem de novos acontecimentos. Para isso nada melhor do que um bom planejamento. O projeto de software não se torna essa exceção, tendo-se que realizar, não apenas um planejamento superficial, mas sim um especifico, a fim de facilitar sua execução.

Algumas informações são essências, tais como o tamanho, a complexidade, os custos, tempo e esforços relacionados no projeto em questão buscando ao maximo a qualidade no desenvolvimento. Logo tomamos o uso de estimativas de software.

Estimativas de software nos servem como base para o planejamento do projeto de software, elas nos fornecem dados que auxilia a prever a quantidade de pessoas que serão necessárias (recursos humanos), o custos e tempo necessário de cada projeto. Sem o uso das estimativas fica difícil elaborar cronograma e orçamento, prejudicando o andamento do projeto.

Para realizar os cálculos dessas estimativas de software utilizamos as métricas. Métricas referem-se à mensuração dos indicadores quantitativos do tamanho e complexidade de um sistema. Estes indicadores, são utilizados para comparar os desempenhos observados no passado a fim de prever o desempenho futuro.

A métrica de software tem como princípios especificar as funções de coleta de dados de avaliação e desempenho, atribuir essas responsabilidades a toda a equipe envolvida no projeto, reunir dados de desempenho referentes ao software, analisar os históricos dos projetos anteriores e o do próprio software em questão, determinando então o efeito desses fatores e utilizar esses efeitos para pesar as previsões futuras, se prevenindo de possíveis erros. Estes princípios nos permitem prever o resto do processo, avaliar o progresso e reduzir a complexidade. Como ele podemos obter todo esse controle gerencial, melhorando seu desempenho e sua implementação.

As estimativas podem ser:

- Estimativa de custos: o objetivo é calcular antecipadamente os gastos que teremos com o sistema. Temos que fazer o levantamento das ferramentas que iremos utilizar, a infra-estrutura, quantidade de pessoas envolvidas no projeto como encargos e salários mensais, que devemos levar em consideração a dependência do prazo, (por exemplo, falando de um desenvolvedor que tem seu salário mensal, quanto maior for o prazo maior será o custo com o mesmo) e custos com falhas ou manutenção.

- Estimativas de Prazo: auxiliará-nos a estimar a extensão do tempo que o projeto exigirá, onde diretamente dependerá das atividades e do pessoal disponíveis, e dos recursos que teremos a disposição.

- Estimativa do tamanho do produto: dependente do tipo de produto. O tamanho dos requisitos é o número absoluto de requisitos. Quando está na fase projeto representa o número de elementos projetados. O tamanho final de um produto é dado em linhas de código, subrotinas, ou classes existentes.

- Estimativa do esforço requerido para o desenvolvimento: é medido em homens/horas. O projeto deve estimar quantos homens/horas é necessário para se construir o produto. Como vimos acima, este item esta interligado a estimativa de prazo.

- Estimativa á qualidade do produto: é medida em taxas de erros encontrados e solucionados. Tais erros podem ser achados em qualquer uma das fases do projeto, não apenas nas fases de teste. A qualidade também pode ser questionada após a implementação, medindo-se através de manutenção e correção.

- Estimativa de cronograma: descreve no tempo como as atividades planejadas serão executadas. Deve indicar quando cada atividade começa e termina. Seve como base para cumprir o prazo e deve ser acompanhada, sendo reprogramada ser houver qualquer alteração

Para fazermos essa estimativa usamos metricas para poder estimar um software, essas metricas podem ser historias onde podemos obter informações de projetos anteriores elaborados pela equipe ou empíricas onde ajuntamos varias informações obtidas por equipes diferentes.

As principais métricas são: Linhas de Codigo (LOC), Pontos por Função (PF), LOC/FP, Pessoa-Mês(PM), Pessoa-mes/LOC, Defeitos/LOC , Custos/LOC e Pontos por Caso de Uso (PCU).

Conclusão

Concluímos então que para obter um bom desempenho em um processo de desenvolvimento de software é preciso medir custo, produtividade e qualidade durante todo o processo. As métricas nos ajudam a calcular as estimativas que precisamos, através desses cálculos podemos decidir a viabilidade e o andamento do mesmo. Fica mais fácil para o Gestor do Projeto, discernir quais as decisões que serão tomadas caso haja divergência entre o planejamento e a situação atual. Com as estimativas futuras, há como mensurar o projeto durante toda sua execução. As estimativas jamais serão exatas, mas é fundamental para previsões e controle de suas fases

[Seminário] Seminário: SCRUM

SCRUM

Diego de Souza Moraes RA 0950142
Paula Renata de Carvalho RA 0951507526

O que é o Scrum

Scrum é uma metodologia ágil muito usada para organizar e agilizar os processos de gerenciamento de projetos.
Durante um desenvolvimento de um projeto, temos muitas informações que chegam e muitos processos para seguir. Para organizar e não desviar o foco, o Scrum separa por prioridade tudo que deve ser feito, e seta tarefas para a equipe, que trabalha em tarefas separadas, em busca de um resultado em comum.

Vantagens:
- Melhorar a habilidade de responder rapidamente à necessidades.
- Acabar com desperdicios e períodos de espera.
- reduzir o estress de funcionários enquanto aumenta a produtividade simultaneamente.

Em um processo gerenciado pelo Scrum, todas as mudanças planejadas são compiladas pelo dono do produto e suas funcionalidades são priorizadas em uma lista. O resultado desse trabalho do dono do produto é uma Product Backlog, que consiste em uma lista de afazeres que é constantemente repriorizada. Antes de cada Sprint, os objetivos mais priorizados são transferidos para uma Sprint Backlog.

Junto com um usuário, os membros do projeto formam uma Equipe de Scrum. Através de reuniões com o dono do produto, o objetivo do Sprint é determinado e as funcionalidades priorizadas são quebradas em tarefas detalhadas.
A equipe então se auto organiza com as tarefas e possue uma responsabilidade em comum, que é o resultado final para o cliente.
O Scrum Master supervisiona o time de desenvolvimento e foca em tirar qualquer possivel obstáculo dos membros da equipe.
Cada Sprint adiciona novas funções e melhorias para ser entregue ao cliente.

Participantes de um Scrum
A Equipe Scrum (Scrum Team)
Segundo pesquisas, o numero ideal de pessoas para trabalhar na equipe são de 5 a 9 pessoas. São eles que solucionam os problemas. Ele decidem como o trabalho será feito e como ele será devidamente distribuido. Mas nenhuma tarefa é definitiva de um membro, eles precisam ser capazes de trocar de tarefa entre si caso necessário, previnindo que um individuo tenha um conhecimento enorme e único em um campo específico.

Dono do Produto (Product Owner)
Representa a voz do cliente e garante que a equipe trabalhe de acordo com uma visão de negócio. É ele que administra a Backlog do Produto (Product Backlog) - uma lista de afazeres onde todas as especificações de um produto estão listadas de acordo com a sua importância.
O documento fica visivel para toda a organização para que todos estejam notificados do que esperar quando o produto for lançado.
O dono do produto é geralmente um client, mas também pode ser parte da organização interna.

Scrum Master
É uma espécie de organizador da equipe. Uma pessoa central que se encontra com a equipe todo dia para uma reunião rápida, as Daily Scrums. Quando alguém de fora tem algo importante para conversar sobre o processo, o Scrum Master faz essa interface entre esse alguém de fora e o time, para que a equipe seja interrompida o menos possível. O objetivo principal do Scrum Master é providenciar as melhores circunstâncias para que a equipe realize os objetivos do Sprint.
Depois de cada Sprint, o Scrum Master faz uma reunião de avaliação com a equipe - Sprint Retrospective - onde revisam as experiências e conclusões, tendo como objetivo aumentar o conhecimento e motivação do time para o próximo Sprint.

Processo

Criando uma Backlog
O dono do produto compila todos os pedidos e especificações que são a base das mudanças do produto, como novas funcionalidades e concerto de bugs. Assim que os objetivos são definidos, o resultado é quebrado em segmentos. Cada segmento deve criar um valor de negócio.
Ao mesmo tempo, uma lista de prioridades é criada. Até aqui, todas as decisçoes são feitas pelo dono do produto. Em qual ordem as mudanças devem ser entregues? O resultado é uma lista de afazeres organizada de acordo com a demanda do mercado e pedidos de mudanças pelo cliente ao longo do tempo. Quando é hora de começar um novo Sprint, o dono do produto "congela" os principais ítens da lista e chama a Equipe de Scrum para uma reunião.
A Fase de Sprint
Uma fase de Sprint normalmente dura 30 dias. Desses 30 dias, os primeiros são dedicados a criação de uma Backlog. Quando as tarefas e tempo requerido são determinados, o dono do produto deixa o projeto nas mãos da equipe de Scrum, que trabalha sob própria responsabilidade. Se o grupo for composto apropriadamente, o trabalho se auto organizará.

Daily Scrum (Scrum Diária)
Todos os dias, no mesmo horário, o Scrum Master e a Equipe de Scrum tem uma reunião rápida. O propósito é eliminar todos os obstáculos do grupo. Cada participante do grupo deve em algum ponto responder às 3 perguntas:
- O que você fez desde a última reunião?
- O que você fará entre essa reunião e a próxima?
- Existe alguma coisa te atrapalhando os seus planos?
As primeiras duas perguntas dão aos participantes uma visão do progresso do projeto. A terceira pergunta providencia uma base para a solução de problemas, que variam de um mouse de computador, para mudanças organizacionais na empresa.

Diagrama Burn-Down
É usado pelo Scrum Master para marcar dia-a-dia o quanto falta para a finalização do trabalho. O diagrama ilustra claramente o quanto do projeto já foi concluído e o quanto falta concluir.

[Seminário] Metodologias Ágeis

Metodologias Ágeis
Uma Visão Prática

Tatiane Regina Baldin _ 0940481012
Flávio Roberto Pereira _ 0991003869


• Do que se trata:
Avaliação da presença das metodologias ágeis no mercado de desenvolvimento de software. Verificando quantitativamente alguns pontos de interesse, identificando o estado atual do movimento ágil e a pouca disponibilidade de estudos de caso que possam ser usados como fonte sistemática de resultados para comparação.
• Para que serve:
Fornecer subsídios para o processo de escolha de uma metodologia de desenvolvimento a ser adotada por uma empresa de software através de uma avaliação crítica das informações disponíveis sobre os resultados da aplicação das metodologias ágeis em projetos reais de desenvolvimento.
• Em que situação o tema é útil:
As metodologias ágeis como o Estreme Programming (XP), e o Scrum, entre outras tem despertado atenção crescente do mercado. Esse movimento baseado no ciclo de desenvolvimento incremental e interativo está focado na colaboração do cliente, no valor dos indivíduos e na adaptação das mudanças, tendo mostrado ganhos de produtividade nos mais diversos tipos de projeto de desenvolvimento de software.

• A escolha da metodologia mais adequada para o desenvolvimento de software em uma organização não é uma tarefa trivial. As metodologias ágeis têm despertado o interesse do mercado, apresentando evidencias de melhorias na produtividade, mas, para que possam ser efetivamente usadas em larga escala, precisam provar alguns de seus pontos de vista. Procuramos verificar quantitativamente alguns pontos de interesse identificando a presença das metodologias ágeis no mercado, o estado atual do movimento ágil e a pouca disponibilidade de estudos de caso que possam ser usados como fonte sistemática de resultados para comparação.


• Introdução:
A maior parte dos projetos de desenvolvimento de software pode ser descrita simplesmente como “programar e corrigir”, sendo desenvolvidos sem planejamento ou uma fase organizada de design do sistema. Disso usualmente decorre uma grande quantidade de erros, os quais precisam ser resolvidos, em uma longa etapa que sempre estende o prazo inicialmente proposto. O movimento original de melhoria no setor foi o que introduziu a noção de metodologia, ou seja, uma abordagem disciplinada para o desenvolvimento de software como objetivo de tornar o processo mais previsível e eficiente.
• Importância dos estudos para o mercado:
As idéias relativas ao movimento ágil têm sido rapidamente disseminadas pela comunidade e desenvolvimento. Todavia, mesmo que os desenvolvedores avaliem, de forma favorável, técnicas como o desenvolvimento incremental e a programação orientada a testes, sugerindo a adoção de uma metodologia ágil, essa decisão ainda tem que ser tomada pela organização na qual estão inseridos. Para isso se faz necessário uma argumentação quantitativa.
Na curva de Adoção de Tecnologia introduz o conceito de “decisão sobre a inovação”, o qual indica que um grupo (ou individuo) procura determinar as vantagens e desvantagens de uma inovação, com o objetivo de reduzir a incerteza antes de sua adoção. A partir disso, descreve cinco categorias sociais, determinadas com base no seu grau de adoção das inovações. Os “inovadores” são os que mais facilmente adotam as inovações e, para a direita do gráfico, cada grupo apresenta uma resistência maior, terminando com os “tardios”, menos afeitos à adoção de qualquer inovação.

• Existe uma grande mudança na percepção do mercado, nos dois lados do “abismo” apontado nessa curva. As empresas à direita do abismo possuem uma expectativa significativamente diferente daquelas à esquerda da curva. As empresas do lado esquerdo do abismo estão mais interessadas em novas idéias e mais propensas a aceitar riscos, enquanto que as empresas no lado direito são mais conservadoras e preferem aguardar por uma prova de que a idéia realmente funciona.

• Segundo uma pesquisa realizada pela empresa DigitalFocus (www.digitalfocus.com) e apresentada em um dos eventos mais importantes da comunidade ágil, a Agile 2006, o interesse nas metodologias de desenvolvimento ágil está crescendo, com 81% das empresas adotando uma metodologia ágil ou procurando por uma oportunidade para fazê-lo. Essa pesquisa a qual coletou informações de 136 profissionais, provindos de 128 empresas de diferentes portes, teve como objetivo identificar os fatores chave envolvidos na adoção das metodologias ágeis, sob o ponto de vista técnico e gerencial.

• Fatores de adoção de uma metodologia ágil:


• Com relação às barreiras para a adoção do desenvolvimento ágil, no início o principal motivo citado era a falta de apoio por parte das gerências e da organização como um todo. Agora, isso não é mais tão importante. A falta de profissionais qualificados para o desenvolvimento ágil e a resistência dos próprios desenvolvedores á mudança são agora apontados como os principais fatores.


• Conclusões:

A escolha da metodologia mais adequada para o desenvolvimento de software em uma organização, levando em consideração os inúmeros fatores envolvidos, não é uma tarefa trivial. Por outro lado, é um fator preponderante para o sucesso da organização. Embora um bom processo possa garantir o sucesso de um projeto, certamente a adoção de um processo inadequado pode comprometê-lo. O movimento ágil ainda de ser classificado como uma inovação, embora alguns dados já apontem para um novo cenário, no qual o desenvolvimento ágil está em um momento de inflexão, passando a ser defendido também na esfera gerencial das organizações.

[Aula] Processo de Desenvolvimento de Software

Na aula passada aprendemos os conceitos referentes aos processos de desenvolvimento de software.

Segundo Ivar Jacobson, Grad Booch e James Rumbaugh:

 "Um processo define quem está fazendo o quê, quando e como para alcançar um certo objetivo."

Também abordamos em sala de aula os seguintes processos:

•     Ciclo de Vida Clássico
•     Prototipação
•     Modelo Espiral
•     Modelo Iterativo
•     Modelo Incremental
•     RUP

Como estudo complementar, sugiro que assistam ao seguinte vídeo:

Até a próxima aula!

[Seminário]

Anhanguera Educacional S.A
Faculdade Comunitária de Campinas – Unidade 3

Tecnologia em Análise e Desenvolvimento de Sistemas



SEMINARIO SOBRE ATIL

Aderli de Oliveira Leitão 0919445177
Guilherme Camargo 0995536385






Seminário apresentado para obtenção do grau de Tecnólogo no curso de Tecnologia em Análise e Desenvolvimento de Sistemas da Faculdade Comunitária de Campinas – FAC 3.


Orientadora: Prof.Tania Ramires


Campinas, 24 de Março 2011

Introdução a ITIL

Atualmente temos a ITIL (IT Infrastructure Lybrary), que é uma biblioteca composta das melhores práticas para Gerenciamento de Serviços de TI. Criada pelo Governo Britânico em 1980, se tornou padrão de fato no mercado em 1990. Trata-se de uma biblioteca composta de 7 livros principais. Não se trata de uma metodologia e sim de um conjunto de melhores práticas adotadas em várias empresas. Atualmente é o framework mais adequado para o Gerenciamento de serviços para os departamentos de TI, sendo utilizado por mais de 10.000 empresas no mundo todo.
Podemos tratar a ITIL apenas como um consenso de como devem ser tratados os processos dentro de um departamento de TI. Os processos propostos são genéricos, podendo ser utilizados por qualquer empresa, seja pública ou privada, de grande ou pequeno porte. Estes processos devem ser adotados e adaptados ao seu negócio, tenha em mente que não existe receita de bolo pronta.

Não é correto afirmar que um processo é “compatível com a ITIL”, nem mesmo falar em implantar a ITIL. O objetivo é implementar o Gerenciamento de Serviços de TI, e para isto pode ser utilizado a ITIL como base das melhores práticas.

Os processos e organizações podem ser avaliados se estão compatíveis com a norma BS 15.000 ou ISO 20.000 (criada em dezembro de 2005), que são padrões de Gerenciamento de Serviços de TI. Entretanto, nem ferramentas ou pessoas podem ser certificadas em BS 15.000 ou ISOs. A ISO 20.000 é voltada para empresas prestadoras de serviços, que tem como foco avaliar a conformidade dos processos da empresa com as práticas sugeridas, o padrão ISO substitui o padrão BS 15.000.

A ITIL foi desenvolvida inicialmente pela CCTA (Central Computing and Telecommunications Agency) atual OGC (Office of Government Commerce). O OGC é órgão do Governo britânico que tem como objetivo desenvolver metodologias e criar padrões dentro dos departamentos do governo britânico, buscando otimizar e melhorar os processos internos. A biblioteca da ITIL foi desenvolvida pela CCTA, e tinha como objetivo melhorar os processos dos departamentos de TI do governo britânico. Desde o seu surgimento em 1980, as empresas e outras entidades do governo perceberam que as práticas sugeridas poderiam ser aplicadas em seus processos de TI também. Em 1990 a ITIL acabou se tornando um padrão de fato em todo o mundo, e a partir dela houve várias adaptações de outros fornecedores, como a Microsoft, IBM e HP.

A ITIL atualmente desperta grande interesse no mercado, pois há uma preocupação com o Gerenciamento de Serviços de TI nas empresas. Como falamos anteriormente, a grande dependência da TI para os negócios faz com que os gestores de TI busquem a adoção da melhores práticas com o objetivo de trazer resultados positivos, como redução de custos e agilidade em seus processos.

Mais de 10.000 empresas no mundo todo já adotaram as melhores práticas da ITIL, isto comprova sua maturidade e aceitação pelo mercado. O Brasil e EUA estão na fase inicial de implementação destas práticas, muitas empresas aqui já adotaram e já temos vários cases de sucesso.

A ITIL oferece um framework comum para todas as atividades do departamento de TI, como a parte da provisão dos serviços, baseada na infra-estrutura de TI. Estas atividades são divididas em processos, que fornecem um framework eficaz para um futuro Gerenciamento de Serviços de TI aprimorado. Cada um destes processos cobre uma ou mais tarefas do departamento de TI, tais como desenvolvimento de serviços, gerenciamento da infra-estrutura, fornecimento de serviços e suporte a serviços.

Estes processos propiciam o uso das melhores práticas, fazendo com que o departamento de TI possa adotar independente da estrutura da organização.

As melhores práticas da ITIL têm como objetivos:
 Servir de inspiração para melhorar seus processos de TI;
 Sugerir onde é possível chegar, pois outras empresas já conseguiram resultados positivos;
 Sugerir para que servem os processos e práticas;
 Sugerir por que adotar os processos e práticas.

Muitas destas melhores práticas são claramente identificáveis e na verdade são utilizadas na maioria das organizações de TI, talvez muitos dos conceitos que você vai ver aqui você já utiliza ou conheça.

A ITIL apresenta as melhores práticas de forma coesa. Os livros da ITIL descrevem como estas podem ser otimizadas e como a coordenação das atividades pode ser aperfeiçoada. Os livros também explicam como os processos podem ser formalizados dentro de uma organização. Fornecem uma referência dentro da organização para uma terminologia padronizada, e ajudam a definir os objetivos e determinar o esforço requerido.

A ITIL não pode ser vista como uma metodologia, pois as melhores práticas são flexíveis a ponto de você adaptar aos seus processos, já uma metodologia possui uma implementação mais rígida, com regras bem definidas. “Na ITIL tudo pode nada deve.”

A vantagem da adoção das melhores práticas está no fato de não ter que “reinventar a roda”, adotar práticas já testadas propicia um ganho de tempo e retorno mais rápido sobre o projeto de implementação de uma Gestão de Serviços.















Organizações envolvidas com a ITIL

A figura abaixo apresenta as organizações que estão envolvidas na manutenção e disseminação da ITIL:



OGC (Antigo CCTA)

A ITIL era originalmente um produto da CCTA. A CCTA era a Agência de Processamento de Dados e Telecomunicações do governo britânico. No dia 1 abril de 2001, o CCTA foi fundido com o OGC (Office of Government Commerce), que é agora o novo "proprietário" da ITIL. O objetivo do OGC é ajudar seus clientes no setor público britânico a atualizar suas atividades de procurement(obtenção) e melhorar seus serviços fazendo o melhor uso possível da TI e de outros instrumentos. O OGC busca modernizar a forma de procurement (licitações) no governo, e agregar valor substancial para o uso do dinheiro público. O OGC promove o uso das melhores práticas em muitas áreas (por exemplo, gestão de projetos, procurement e Gerenciamento de Serviços de TI). O OGC publica diversas séries (bibliotecas) dos livros escritos por especialistas Britânicos e outros internacionais de várias empresas.

A Biblioteca consiste em um número claro de “Código de Práticas” para promover e fornecer Serviços de TI de forma eficiente e eficaz.
ITSMF

O Fórum de Gerenciamento de Serviços de Tecnologia da Informação (ITSMF), originalmente ficou conhecido como o fórum do Gerenciamento da Infra-estrutura de TI (ITIMF), foi criado no Reino Unido em 1991. O ITSMF holandês foi o primeiro chapter(capítulo), criado em novembro de 1993. Em 2001 mais de 500 empresas tornaram-se membros, entre fornecedores e grupos de usuários. Atualmente existem chapters do ITSMF em vários países tais como África sul, Bélgica, Alemanha, Áustria, Suíça, EUA, Austrália, e Brasil, que participam no grupo internacional do ITSMF.
O ITSMF promove a troca de informações e experiências que permitem às organizações melhorarem os serviços que fornecem. Organiza congressos, encontros especiais, e outros eventos sobre assuntos ligados a Gerenciamento de Serviços de TI.
Os associados contribuem também com o desenvolvimento do assunto. A associação publica um boletim de notícias e fornece um website com informações sobre suas atividades (http://www.itsmf.com.br).
EXIN e ISEB

O “Examination Institute for Information Science” (EXIN) e o “Information Systems Examinations Board” (ISEB), juntos desenvolveram uma certificação profissional para a ITIL. Isto foi feito em cooperação com o OCG e ITSMF. O EXIN e ISEB são organizações sem fins lucrativos que cooperam para oferecer uma escala de qualificação ITIL em três níveis:

• Certificado Foundation em Gerenciamento de Serviços de TI
• Certificado Practitioner em Gerenciamento de Serviços de TI
• Certificado Manager em Gerenciamento de Serviços de TI

O sistema de certificação é baseado nas exigências para cumprir o papel relevante dentro de uma organização de TI. Até agora, os certificados foram concedidos para mais 170.000 profissionais de TI em mais de 30 países.
Certificações para os Profissionais de TI

Para obter a certificação Foundation não é necessário participar de um curso oficial, nem mesmo comprovar experiência na área. É importante que o candidato já atue na área de serviços de TI, isto facilita os estudos. Com o apoio de livros e simulados é possível obter a certificação de maneira fácil. A prova é composta de 40 questões, sendo que é necessário você obter um acerto de 65% (26 questões apenas). As questões são objetivas e de múltipla escolha. As provas podem ser feitas em qualquer lugar do Brasil através de centros de testes VUE (www.vue.com) ou PROMETRIC (www.prometric.com). As provas eletrônicas estão disponíveis apenas no idioma inglês, espanhol e português.

Na certificação Practitioner o candidato deve realizar um curso oficial reconhecido pela EXIN ou ISEB. Este curso será focado em 2 ou 3 processos da ITIL, dando ao aluno um conhecimento mais profundo sobre os processos estudados. É ideal para as pessoas que vão trabalhar na parte operacional do projeto de implementação da Gestão de Serviços de TI. O curso normalmente tem a duração de 3 dias, a avaliação do candidato acaba sendo feita durante o próprio treinamento. É pré-requisito já possuir a certificação Foundation para este nível.




A certificação Manager é voltada para os gestores de TI que terão uma visão ampla e aprofundada de todos os processos da ITIL. Para realizar esta certificação também é necessário realizar um curso oficial, e é pré-requisito ter a certificação Foundation, mas não é necessário realizar a Practitioner. A certificação é extramente cara, pois o curso tem duração de 2 semanas, além de workshops de preparação. O exame é composto de 2 provas, realizadas em 2 dias. Cada exame foca um livro da ITIL. Esta certificação também é muito indicada para quem busca desenvolver carreira na área de consultoria.

Os Livros da ITIL

ITIL (IT Infrastructure Library)

ITIL é uma série de livros. Assim como o nome já sugere é uma biblioteca (IT Infrastructure Library). Esta seção descreverá os vários componentes da biblioteca. Os livros oficiais da OGC estão disponíveis para compra nas livrarias. É de domínio público a utilização destas práticas na sua empresa, entretanto todo o material da ITIL possui direitos de cópia da coroa inglesa.

Cada um dos livros da ITIL faz parte do framework completo da ITIL. A ITIL na verdade é uma biblioteca de muitos livros. Esta apostila é focada na entrega do serviço e nos livros de Suporte a Serviços e Entrega de Serviços. Nós descrevemos a ITIL conforme esses dois livros durante toda a apostila.

A ITIL define os objetivos e atividades, as entradas e saídas de cada um dos processos encontrados em uma organização de TI. Entretanto, a ITIL não dá uma descrição específica de como estas atividades devem ser executadas, porque em cada organização estas são diferentes, ou seja, não existe receita de bolo pronta para você implementar a ITIL. A ênfase está em sugestões que foram provadas na prática, mas (dependendo das circunstâncias) pode ser implementada de várias formas. ITIL não é um método, ao invés disto oferece um framework para planejar os processos mais comuns, papéis e atividades, indicando as ligações entre elas e que linhas de comunicação são necessárias.

A ITIL é baseada na necessidade de fornecer os serviços de alta qualidade, com uma ênfase no serviço e no relacionamento com cliente. A organização tem que cumprir exigências do "cliente", o que significa um bom relacionamento com ele, com os parceiros e com os fornecedores.

Parte da filosofia da ITIL é baseada nos sistemas de qualidade, tais como a série ISO-9000, Qualidade Total. A ITIL suporta tais sistemas de qualidade com uma descrição clara dos processos e das melhores práticas em Gerenciamento de Serviços de TI. Isto pode significativamente reduzir o tempo necessário para obter a certificação da ISO.
Originalmente, a ITIL era consistida por um grande conjunto de livros, cada um deles descrevia uma área específica de manutenção e operação da Infra-estrutura de TI. Os dez livros que descreviam o Suporte de Serviços e Entrega de Serviços eram considerados o núcleo da ITIL. Havia aproximadamente outros 40 livros nos assuntos complementares relacionados ao Gerenciamento de Serviços de TI, desde mandar um telegrama ao cliente a relacionar-se com o cliente. Entretanto, a série original dos livros da biblioteca de Infra-estrutura focou-se mais no Gerenciamento de Serviços de TI a partir da perspectiva de TI.
O conjunto de Perspectiva de Negócios foi introduzido para construir uma ponte entre o negócio e a organização de TI.
O núcleo dos livros da ITIL foi revisado e publicado apenas como dois livros, um Suporte a Serviços e outro Entrega de Serviços. Isto eliminou sobreposições e inconsistências da séria anterior.
O quebra-cabeça da ITIL mostra os principais elementos localizados nos seus livros. Cada um destes elementos se relaciona entre si, e se sobrepõem em alguns tópicos.
Estes elementos são:
• Perspectiva de Negócio
• Entrega de Serviço
• Suporte à Serviço
• Gerenciamento da Segurança
• Gerenciamento da Infra-estrutura
• Gerenciamento de Aplicações
• Planejamento da implementação do Gerenciamento de Serviços
Principais livros que compõem a biblioteca da ITIL:

Fonte: baseado no livro Service Support da OGC
Estes sete módulos constituem o corpo da ITIL. Abaixo você terá uma descrição resumida do propósito de cada livro:

Suporte a Serviços: descreve os processos associados ao suporte do dia-a-dia e atividades de manutenção associadas com a provisão de Serviços de TI.

Entrega de Serviços: cobre os processos necessários para o planejamento e entrega de Serviços de TI com qualidade e se preocupa ao longo do tempo com o aperfeiçoamento desta qualidade.

ICT - Gerenciamento da Infra-estrutura: cobre todos os aspectos do Gerenciamento da Infra-estrutura como a identificação dos requisitos do negócio, testes, instalação, entrega, e otimização das operações normais dos componentes que fazem parte dos Serviços de TI.

Planejamento para Implementação do Gerenciamento de Serviços: examina questões e tarefas envolvidas no planejamento, implementação e aperfeiçoamento dos processos do Gerenciamento de Serviços dentro de uma organização. Também foca em questões relacionadas à Cultura e Mudança Organizacional.

Gerenciamento de Aplicações: descreve como gerenciar as aplicações a partir das necessidades iniciais dos negócios, passando por todos os estágios do ciclo de vida de uma aplicação, incluindo até a sua saída do ambiente de produção (quando o sistema é aposentado). Este processo dá ênfase em assegurar que os projetos de TI e as estratégias estejam corretamente alinhados com o ciclo de vida da aplicação, assegurando que o negócio consiga obter o retorno do valor investido.

Perspectiva de Negócio: fornece um conselho e guia para ajudar o pessoal de TI a entender como eles podem contribuir para os objetivos do negócio e como suas funções e serviços podem estar mais bem alinhados e aproveitados para maximizar sua contribuição para a organização.
Gerenciamento da Segurança: detalha o processo de planejamento e gerenciamento a um nível mais detalhado da segurança da informação e Serviços de TI, incluindo todos os aspectos associados com a reação da segurança dos incidentes. Também inclui uma avaliação e gerenciamento dos riscos e vulnerabilidade, e implementação de custos justificáveis para a implementação de contra-recursos (estratégia de segurança).

Esta apostila irá descrever apenas os 2 livros principais da ITIL: Suporte a Serviços e Entrega de Serviços, considerados o coração do framework.
Suporte a Serviços





O livro Suporte a Serviços descreve como um cliente consegue acesso aos serviços para suportar seus negócios.

Este livro cobre os seguintes assuntos:
• Central de Serviços
• Gerenciamento de Incidentes
• Gerenciamento de Problemas
• Gerenciamento da Configuração
• Gerenciamento de Mudanças
• Gerenciamento de Liberação



A figura abaixo apresenta o relacionamento entre os processos do livro Suporte a Serviços.



Entrega de Serviços








O livro Entrega de Serviços descreve os serviços que o cliente necessita, e o que é necessário para fornecer estes serviços.

Este livro cobre os seguintes assuntos:
• Gerenciamento do Nível de Serviços
• Gerenciamento Financeiro para Serviços de TI
• Gerenciamento da Capacidade
• Gerenciamento da Disponibilidade
• Gerenciamento da Continuidade dos Serviços de TI
• Gerenciamento da Segurança (com referência ao livro Gerenciamento da Segurança)





A figura abaixo apresenta o relacionamento entre os processos do livro Entrega de Serviços.
Por que a ITIL é importante?

Como visto no capítulo de Introdução ao Cenário, a área de TI tem ganhado grande importância dentro do negócio, tem servido como meio para alcançar os objetivos da empresa. Em virtude da necessidade de um Gerenciamento de Serviço de TI mais robusto, a biblioteca da ITIL tem ganhado destaque, servindo como apoio para melhorar os processos de TI.

Entre os principais objetivos da adoção da melhores práticas da ITIL podemos destacar os seguintes:

 Alinhar os Serviços de TI com as necessidades atuais e futuras do negócio e seus clientes. Todos os processos da ITIL falam que a TI precisa entender os requisitos de negócio da empresa para poder planejar e prover seus serviços para atender as expectativas.
 Melhorar a qualidade dos serviços de TI. Através de um programa de melhoria contínua deve se buscar a consistência na entrega dos serviços, atendendo as necessidades de negócio.
 Reduzir custos na provisão de serviços. Este é um dos motivos chaves que levam os gestores de TI a adotarem as melhores práticas, já existem vários casos de sucesso onde houve grande redução dos custos operacionais e investimentos em TI.
 Processos mais eficientes e eficazes, buscando rapidez e resultados nos processos.
 Adoção das melhores práticas, evitando reinventar a roda.

Possíveis resultados com a adoção da ITIL

 Falhas: ò30% quantidade, ò50% tempo resolução;
 Mudanças: ò25% tempo de conclusão, ò50% mudanças urgentes e caras;
 Capacidade: ò15% capacidade ociosa;
 CTP (TCO): ò10%;
 Disponibilidade: ñ10%;
 ñConfiabilidade;
 òTempo de lançamento no mercado.

Fonte: ITIL Forum 2003

Abaixo temos alguns exemplos de resultados alcançados em algumas empresas e setores de TI que foram pesquisados.

 Redução do custo total até 48% - Gartner
 6-8% de redução de custos operacionais. $ 125 milhões de economia (10% do budget). Procter e Gamble
 Aumento da satisfação do cliente
 Aumento de resolução de incidentes de 5% para 30% com o uso de uma base de conhecimento - IS Organizations
 Redução de 50% no tempo médio de resolução. Redução de 30% no tempo para realizar novas mudanças. Redução de 50% dos recursos – Utility Provider

Possíveis Problemas

Um projeto de implementação das práticas da ITIL pode ter vários problemas, é importante que você esteja ciente e busque contornar alguns obstáculos já conhecidos:

 Falta de patrocínio, comprometimento e entendimento. É importante que todas as pessoas relacionadas com o projeto estejam conscientes das melhorias que a mudança poderá trazer. O comprometimento de todos é fundamental para fazer com que os processos sejam implementados.
 Cultura da empresa. Se a empresa não tiver cultura para a gestão de serviços se torna muito complicado a TI obter a colaboração dos demais departamentos.
 Excesso de expectativa. Tenha em mente que a adoção das melhores práticas não se faz em dias, é necessário planejamento, insistência, acompanhamento e adaptações ao longo do projeto.
 Problemas na Gestão do Projeto. A implementação de um Programa de Gerenciamentos de TI deve ser encarado como um projeto, com responsáveis por cada etapa, prazos para implementação e recursos necessários.
 Falhas de Comunicação.
 Objetivos não alcançados: melhoria de qualidade, redução de custo, satisfação do usuário, alinhamento de TI com a estratégia de negócio.

[ATPS] 1ª e 2ª PARTE ATPS

FACULDADE ANHANGUERA DE CAMPINAS

UNIDADE III

CURSO DE TADS

1ª e 2ª PARTE ATPS

Disciplina: Engenharia de Software e Gerência de Projetos

Profa. Tânia Ramires

Curso de Tads – 5^o. Sem Noturno

Alunos RA

Claudinei Aparecido de Paula 0955516766

Guilherme C. M. O. de Carvalho 0995536385

Luiz Carlos Bernardes 0901337161

Aderli de Oliveira Leitão 0919775177

Campinas / 2011

Etapa Nº 1.

Equipe de Projeto:

A equipe que foi organizada para a realização desse projeto foi constituída por 4 integrantes sendo eles:

Luiz Carlos Bernardes: Gerente de projetos

Cursando a faculdade de Tecnologia em Análise e Desenvolvimento de Sistemas com experiência em controladoria, almoxarifados e grande potencial de liderança.

Guilherme Camargo: Analista de Sistemas

Cursando a faculdade de Tecnologia em Análise e Desenvolvimento de Sistemas com experiência em analises de requisitos, modelagens de dados e conhecimentos em linguagens de programação.

Aderli de Oliveira Leitão: Programador

Cursando a faculdade de Tecnologia em Análise e Desenvolvimento de Sistemas com experiência em linguagens de programação e banco de dados SQL e ORACLE .

Claudinei Aparecido de Paula: Tester

Cursando a faculdade de Tecnologia em Análise e Desenvolvimento de Sistemas com experiência em linguagens de programação e banco de dados SQL.

Etapa Nº 2.

Escopo de Projeto:

Nome do Projeto: FOXERHT

Objetivos do Sistema: O objetivo desse Projeto é controlar a locação e liberação dos quartos no sistema após o pagamento do cliente incluindo todos os gastos do mesmo com locação, alimentação e serviços do hotel no período de sua estadia.

De acordo com o cliente a reserva de um quarto poderá ser feita através de telefone junto a um recepcionista que estará acessando o sistema e fazendo assim o preenchimento do cadastro do cliente, passando ao mesmo as informações sobre normas e valores de locação dos quartos ou através de um site do hotel com todas as especificações dos quartos, normas, valores de locação, formas e condições de pagamento, e uma ficha cadastral do cliente.

O sistema só permitirá reserva se houver quarto disponível, quando feito pela internet ou telefone.

O sistema também terá a opção de cancelamento de reserva tanto por telefone ou por internet.

Todos os serviços do hotel, tais como internet e restaurante serão agregados no valor final do fechamento da conta relacionado ao numero do quarto.

No encerramento da estadia do cliente, será cobrado do cliente o valor total da locação do quarto mais os gastos extras relacionados a serviços e alimentação do período, emitindo assim um relatório com o gasto total do cliente.

Após o pagamento do cliente o quarto é disponibilizado para limpeza, e após a limpeza para nova locação.Essa liberação será feita através do próprio sistema pelo setor de limpeza.

‘ O sistema será estruturado por tabelas de cliente, quartos, funcionários, serviços, formas de pagamento, valor de locação, Data Entrada/Saída.

Previsão de Inicio e Termino do Projeto: O inicio do projeto será de 2 dias após a contratação dos serviços e com prazo de entrega de 4 meses , se não houver nenhum tipo de alteração no escopo do projeto , caso haja alguma alteração , a data prevista de entrega será modificada.

Plataforma (sistema operacional): A plataforma escolhida foi a do Windows pois a ferramenta que usaremos para a criação do sistema é compatível com o mesmo e de fácil utilização , alem de ser o sistema mais usado no mercado.

Linguagem de Programação: A programação será feita em Visual Studio, HTML, PHP e banco de dados em SQL SERVER.

Principais Stakeholders: O envolvidos no projeto além da diretoria do hotel e dos membros da equipe serão : gerente, pessoal de limpeza, recepcionistas, funcionários do bar e restaurante do hotel.

Premissias: O programa deve ser de fácil utilização,

Restrições: De forma alguma poderá haver 2 locações para o mesmo quarto no mesmo período,o quarto só poderá ser locado novamente após a liberação pelo serviço de limpeza, não pode haver uma locação ou reserva sem que o cadastro do cliente seja realizado no sistema.

[ATPS] 2ª ETAPA ATPS - Felipe Araujo E Grupo

2ª ETAPA ATPS - TADS 5º Sem. FAC 3 - Engenharia de Software e Gerência de Projetos


Felipe Soares - 0836162
William Ribeiro - 0919453818
Tiago Luis - 0924437995
Henrique Estevam - 0901416966
Cesar Fernandes - 1060132900

Relatório 2 - Escopo Do Projeto

Este documento possui as principais especificações e características do projeto:

1. Nome Do Projeto

Hosting Manager

2. Objetivos Do Sistema

Executar o gerenciamento de hospedagem em um hotel. O sistema deverá realizar o gerenciamento da locação dos quartos (reservado, locado ou disponível) fazendo o controle das despesas dos clientes referente ao tempo de hospedagem e consumo de produtos e ou serviços do hotel. Ao final da estadia, quando o cliente efetuar o CheckOut, ou seja, o encerramento de sua estadia no hotel, o sistema deverá apresentar um relatório com as despesas do cliente.

3. Plataforma

Sistema Operacional: Win XP. Opção em função das características funcionais, de suporte e compatibilidade a aplicações e da necessidade de hardware de acordo com os padrões comuns encontrados no mercado sendo uma boa opção de custo benefício.
Configuração de Hardware:
Processador Intel® Celeron® 450 (2.20 GHz, 512 KB L2 Cache, 800 MHz FSB)
Memória 2GB DDR3 1333MHz (1x2GB)
Disco Rígido Disco Rígido SATA de 320GB (7200RPM) c/ Cache DataBurst™
Unidade ÓpticaGravador de DVD/CD (Unidade DVD+/- RW 16x)
Placa de VídeoPlaca de Vídeo Integrada Intel® GMA X4500 Graphics
Teclado, caixas de som e monitor de padrão comum fornecidos atualmente.
Opção em função de custo benefício, flexibilidade de utilização e facilidade de aquisição em função das configurações padrão de mercado.

4. Linguagem De Programação

C#: O C Sharp é uma linguagem de programação desenvolvida pela Microsoft que é completamente suportada pela plataforma .NET Framework, abrange pontos positivos do Visual Basic, C++ e Javascript. Em função da grande semelhança com essas linguagens de programação permite que desenvolvedores destas possam se adaptar com facilidade. Possui recurso de programação orientada a objeto, uso de evento nos controles, facilidades para validação de dados e tratamento de erros.
Banco de dados: O banco de dados será o SQL Server 2005. Os pacotes de intercâmbio de arquivos serão desenvolvidos em Microsoft SQL Server Integration Service. Em função do armazenamento de grandes históricos, excelente organização das tabelas, relação entre as mesmas e integridade das conexões com as aplicações fornece uma estrutura robusta para suportar uma aplicação que será utilizada com freqüência e por um longo tempo.

5. Principais Stakeholders

Índice Papel Características
1 Cliente Será responsável por fornecer as características desejadas no produto que será entregue pelo projeto.
Aprovar questões estratégicas do projeto. Estabelecer prioridades de entre demandas.
2 Gerente De Projeto Gerenciar o projeto de software em todo seu ciclo de vida, considerando aspectos como levantamento de requisitos, homologação e implantação da solicitação.
3 Analista De Requisitos Será responsável por fornecer as características desejadas no produto que será entregue pelo projeto.
4 Desenvolvedor Implementar os requisitos descritos neste documento.
5 Analista De Testes Definir e projetar os planos de teste que servirão de guia para a realização dos testes.
6 Patrocinador Aprovar questões estratégicas do projeto. Estabelecer prioridades de entre demandas. Viabilizar contato com fornecedores de requisitos externos.
7 Gerente De Negócio Aprovar questões estratégicas do projeto. Estabelecer prioridades de entre demandas. Viabilizar contato com fornecedores de requisitos externos.
8 Gerente De Sistemas Acompanhamento do status das atividades junto ao Analista de Negócios garantindo entrega do produto ao cliente.
Interceder junto a Fornecedores / Parceiros em casos que se façam necessários.
Auxiliar na condução de tarefas traduzidas dentro do contexto de desenvolvimento de novas soluções, aplicando a metodologia utilizada pelo CR Sistemas / Serviços.
Eliminar obstáculos políticos que impeçam o andamento do projeto.
9 Líder Técnico Especificar Tecnicamente o Escopo do projeto.Garantir o entendimento do desenvolvedor alocado no projeto.
Validar e Homologar junto com o Arquiteto de solução os casos de testes implementados pelo Desenvolvedor.
10 Tester Realizar testes referentes aos casos de uso implementados pelo desenvolvedor.
Realizar os testes e garantir que na homologação não ocorrerá erros.
11 Analista De Qualidade Garantir a qualidade da visão do projeto, gerência de configuração de artefatos, atendimento ao processo padrão de sistemas.
12 Analista De Configuração Garantir a montagem e configuração de ambientes para testes e homologação.
Garantir configuração no controle de alteração das versões de fontes.



6. Premissas

O sistema será desenvolvido de acordo com as seguintes premissas solicitadas:

 Efetuar o cadastro de uma base de clientes que utilizaram o Hotel e a manutenção dos dados registrados
 Realizar o controle da utilização de todos os quartos do Hotel ( quartos que estão sendo utilizados, quartos que estão reservados e os que estão livres para utilização ). Há nesse controle uma opção específica para que seja realizado o controle de utilização dos quartos reservados para pessoas com necessidades especiais
 Realizar o controle de utilização do estacionamento do Hotel sendo por hóspedes e por clientes avulsos. No caso do hospede há a limitação da locação de uma vaga por quarto
 Realizar o controle de utilização dos serviços de alimentação do hotel sendo café da manhã, almoço, jantar e refeições extras
 Realizar o controle de utilização do serviço de lavagem de automóveis que será realizado no estacionamento do hotel
 Realizar o controle dos pontos acumulados pelos clientes fidelidade do hotel bem como a utilização dos mesmos
 Realizar o gerenciamento dos dados de registro de ponto dos funcionários do hotel controlando os registros de entrada e saída bem como a questão de escala de trabalho, folgas e ausências
 Realizar o controle de entrada e saída nos quartos do hotel para que seja realizado o serviço de limpeza e arrumação dos quartos
 Realizar o controle de reservas e locação do salão de convenções do hotel
 Realizar o controle de validade dos itens de segurança do hotel sendo extintores de incêndio e equipamentos de segurança auxiliares
 Realizar o controle de itens guardados no cofre de segurança do hotel
 Realizar o controle da liberação e utilização das senhas de acesso a internet sem fio disponível no hotel
 Realizar a segmentação de acessos ao sistema de acordo com os perfis solicitados para os usuários e suas se senhas sendo gerencia com acesso a todas as funcionalidades do sistema com exceção do acesso ao controle do cofre do hotel. Terá acesso ao cofre do hotel somente o usuário com o perfil de dono do hotel. Para os demais usuários serão disponibilizadas as funcionalidades necessárias para atendimento aos clientes do hotel somente.
 Será desenvolvida com integração ao sistema uma página de internet que conterá as principais informações sobre o hotel. Essa página deverá conter uma funcionalidade específica para que possam ser realizadas reservas de quartos pela internet e que deverão ser feitas com três dias de antecedência mediante pagamento total do serviço

7. Duração Do Projeto

Data de início do projeto: 03/03/11
Data prevista para o término do projeto: 24/06/11

8. Precificação

A precificação do sistema levará em consideração as seguintes características no desenvolvimento:

 Equipe: 6 desenvolvedores
 Horas Produtivas/Dia: 6 horas
 Total De Horas Dia: 36 horas de produção
 Total De Meses Do Projeto: 4
 Horas Produtivas/Mês: 900 horas
 Total De Horas Produtivas Para 4 Meses: 3600 horas de produção
 Valor Da Horas Produtiva: R$ 27,10
 Precificação Total: R$ 97.560,00

Observações:
A precificação apresentada contempla horas de desenvolvimento do sistema, horas de elaboração da documentação funcional do sistema e horas de utilização para as fases de teste e implementação do sistema.,

9. Restrições

É necessária aprovação e assinatura deste documento por todos os envolvidos no projeto.
Os testes no ambiente de desenvolvimento são obrigatórios.
Os testes no ambiente de produção são obrigatórios.
A manutenção e administração do sistema serão realizadas mediante a uma nova contratação de serviços que não estão inclusos neste documento.
Somente serão alocados recursos para a execução do sistema de acordo com as características descritas neste documento.
Somente serão consideradas para precificação do sistema as especificações que estão de acordo com as características descritas neste documento.
Qualquer alteração nas características e funcionalidades necessárias ao sistema e que estejam em desacordo com as informações deste documento irão gerar alterações nos prazos e nos preços pré estabelecidos devendo assim ser gerada uma nova versão da documentação que deverá também ser obrigatoriamente assinada por todos os envolvidos no projeto.
Itens não inclusos neste documento serão avaliados e negociados podendo haver alteração no tempo e custos do projeto estabelecidos inicialmente.