apostila-de-ti-para-concursos

Prévia do material em texto

Walter de Tarso
Material de referência
TI – ICMS
Walter de Tarso
Versão 1
2012
Sumário
 (
Curso de TI
)
 (
Walter de Tarso
)
 (
Pág. 
2
 de 143
)
Gerência de Projetos	1
Conceitos básicos	1
Processos do PMBOK	2
Áreas de conhecimento do PMBOK	3
Planejamento e controle de métricas de projeto	13
Métodos de gerenciamento do tempo do projeto	14
Exercícios	14
Gestão de Processos de Negócio (BPM)	18
BPMN - Modelagem de processos	18
Elementos	18
Técnicas de análise de processos	20
Automação de processos	20
Fluxograma	20
Service blueprint	20
Mapa do serviço	21
IDEF	21
Estrutura de processamento de clientes	22
Walk-through-audit	22
Análise da transação de serviço (STA – Service Transaction Analysis)	23
Exercícios	23
Gerência de Serviços de TI	25
Fundamentos da ITIL V2	26
Suporte a serviços	26
Entrega de Serviço	27
Fundamentos de ITIL V3	28
Estratégia do serviço (Service Strategy)	28
Desenho de serviço (Service Design)	28
Transição do serviço (Service Transition)	29
Operação do serviço (Service Operation)	29
Melhoria de serviço continuada (Continual Service Improvement)	29
Fundamentos de COBIT	29
Planejar e Organizar	30
Adquirir e Implementar	30
Entregar e Dar Suporte	30
Monitorar e Avaliar	31
Exercícios	31
Engenharia de Software	33
Software	33
Ciclo de vida do software	34
Fase de Definição	34
Fase de Desenvolvimento	34
Fase de Operação	35
Fase de retirada	36
Metodologias de desenvolvimento de software	36
Modelo caótico	36
Modelo Cascata	36
Desenvolvimento ágil	38
Planejamento e avaliação de iterações	39
Técnicas de avaliação de software	40
Análise por Pontos de Função	40
Método COCOMO	44
Gerência de Requisitos de Software	44
Conceitos de Requisitos	45
Requisitos Funcionais e Não-Funcionais	46
Gerência de Configuração e Mudança	47
Conceitos de Gerência de Configuração e Mudança de software	47
Solicitações de Mudança	48
Testes e Avaliação de Qualidade de Software	49
Qualidade de Software	49
Teste de software	51
Documentos de Teste	52
Exercícios	53
Arquitetura de Software	59
Conceitos básicos	59
UML	59
GED - Gerenciamento Eletrônico de Documentos e Workflow	61
Exercícios	62
Arquitetura Orientada a Serviço (SOA)	63
Serviço	63
Processos	63
Tecnologia	63
Definições de SOA	63
Web Services	64
SOAP	66
WSDL	67
UDDI	67
Segurança	68
Exercícios	68
Portais corporativos e colaborativos	69
Exercícios	70
Banco de Dados	73
Conceitos básicos	73
Modelagem de Dados Relacional	73
Normalização	74
Etapas de modelagem	75
Relacionamentos	75
Transação	76
Modelo Entidade Relacionamento	76
Modelagem de Dados Multidimensional	77
Sistemas Transacionais X Sistemas Analíticos	78
Conceitos de Datawarehouse e ETL	78
ETL	80
Conceitos de desenvolvimento em banco de dados SQL Server e Oracle	80
SQL	80
Arquitetura de um Servidor Oracle	82
Arquitetura de um Servidor SQL Server	83
Exercícios	84
Programação de Sistemas	90
Lógica de Programação	90
Tipos de dados e variáveis	91
Programação orientada a objetos	92
Objetos	92
Classe	93
Persistência	93
Métodos	93
Atributos	94
Mensagens	94
Herança	94
Polimorfismo	94
Sobrecarga	95
Interfaces	95
Pacotes	95
Programação na WEB	95
Linguagem HTML	96
Linguagens web de servidor	97
XML	98
Conceitos de linguagem de programação Microsoft .NET	98
arquitetura da .Net	99
Linguagens de programação	99
Common Language Specification (CLS)	100
Common Type System (CTS)	100
Framework Class Library (FCL)	100
Camada de apresentação	100
ADO.Net	100
.Net Remoting	100
Common Language Runtime (CLR)	101
Common Language Infrastructure (CLI)	101
Operating System (OS)	101
Outros detalhes da .Net	101
Exercícios	102
Segurança da informação	106
Conceitos básicos	106
Plano de Continuidade de Negócio	108
Vulnerabilidade	108
Auditoria e conformidade	109
Conhecimento sobre norma ISO 27001	111
Exercícios	111
Sistemas Operacionais	115
Conceitos de administração de servidores em plataforma Windows	115
Conceitos de administração de servidores em plataforma Linux	115
Alguns comandos no Linux	115
Gerenciando a iniciação do Linux	117
Fazendo Backups	117
Recompilando e Adaptando o Kernel	117
Agendando Processos	117
Syslogd - A Caixa Preta do Linux	117
Técnicas Básicas para Trabalhar com Redes (ifconfig, route)	118
Gerenciando os Serviços - inetd	118
Utilizando Ferramentas de Busca	118
Instalando SSh / SShD	118
Conceitos de Virtualização	119
Active Directory	121
Exercícios	122
Redes	125
Conceito de rede	125
Configuração de redes TCP-IP	125
Arquitetura de Rede	127
Camada Física	128
Camada de Enlace ou Ligação de Dados	128
Camada de Rede	128
Camada de Transporte	129
Camada de Sessão	129
Camada de Apresentação	129
Camada de Aplicação	129
Noções de administração de redes	130
Acesso Remoto	130
Rede Wireless	130
Exercícios	131
Referências	135
Sobre o autor	136
Gabarito	137
Sumário de imagens
Ilustração 1 Métricas	13
Ilustração 2 Exemplo de Fluxo utilizando pool, lanes, evento de início e fim, tarefas e gateway	19
Ilustração 3 Símbolos BMPN utilizados no MS Visio	19
1 Gerência de Projetos
1.1 Conceitos básicos
Um projeto1 é um esforço temporário empreendido para criar um produto, não necessariamente temporário, serviço ou resultado exclusivo. Os projetos e as operações diferem, principalmente, no fato de que os projetos são temporários e exclusivos, enquanto as operações são contínuas e repetitivas.
Os projetos são normalmente autorizados como resultado de uma ou mais considerações estratégicas. Estas podem ser uma demanda de mercado, necessidade organizacional, solicitação de um cliente, avanço tecnológico ou requisito legal.
As principais características dos projetos são:
· temporários, possuem um início e um fim definidos.
· planejados, executado e controlado.
· entregam produtos, serviços ou resultados exclusivos.
· desenvolvidos em etapas e continuam por incremento com uma elaboração progressiva.
· realizados por pessoas.
· com recursos limitados.
Esse é um resumo da definição de projeto feita pelo Guia PMBOK®, um guia que identifica o subconjunto do conjunto de conhecimentos em gerenciamento de projetos, amplamente reconhecido como boa prática na maioria dos projetos na maior parte do tempo e utilizado como base pelo Project Management Institute ( PMI®).
Gerência de projetos é a disciplina de manter os riscos de fracasso em um nível tão baixo quanto necessário durante o ciclo de vida do projeto. Sua função é definir e alcançar objetivos ao mesmo tempo em que se otimiza o uso de recursos (tempo, dinheiro, pessoas, espaço etc).2
Na abordagem tradicional, distinguimos cinco grupos de processos no desenvolvimento de um projeto:
· iniciação – autorização do projeto ou fase
· planejamento – são processos iterativos de definição e refinamento de objetivos e seleção dos melhores caminhos para atingir os objetivos.
· execução – realização dos planos do projeto: coordenação de pessoas e outros recursos para executar o plano
· controle – medição e monitoramento do desempenho do projeto. Garantem que os objetivos do projeto são alcançados através do monitoramento e medição regular do progresso, de modo que ações corretivas possam ser tomadas quando necessário.
· encerramento – aceitação formal do projeto (com verificação de escopo) ou fase para a sua finalização.
Repetir os processos de iniciação antes da execução de cada fase é uma maneira de se avaliar se o projeto continua cumprindo as necessidades de negócio. Envolver as partes interessadas no projeto em cada uma das fases é uma maneira de aumentar as probabilidades de satisfação dos requisitos do cliente.
O gerente de projetos precisa monitorar e comunicar o desempenho do projeto. Os resultados do trabalho que estiverem abaixo de um nível de desempenho aceitável precisam ser ajustados com ações corretivas para que o projeto volte a estar em conformidade com as linhas de base de custo, prazo e escopo. A comunicação do desempenho do projeto é um dos principais elementos para o gerenciamento de projetos bem sucedido.
O projeto ou empreendimento visa a satisfação de uma necessidade ou oportunidade, definida no texto acima como fase inicial na qual existem muitas áreas e/ou pessoasenvolvidas.
Um programa é um conjunto de projetos com um objetivo comum.
Em geral, existe mais do que uma solução ou alternativas para atender às mesmas necessidades. A técnica usada para definir a solução final passa pelo desenvolvimento de alternativas extremas. A primeira, de baixo custo, que atende as necessidades mínimas para ser funcional. A segunda tenta atender a maior parte das as exigências das diversas áreas envolvidas no escopo, que resulta num projeto com custo muito maior e pouco competitivo. A partir de ambas as alternativas é desenvolvida
1 http://pt.wikipedia.org/wiki/Projeto
2 http://pt.wikipedia.org/wiki/Gerência_de_projetos
 (
TI para concursos
)
 (
TI para concursos
)
 (
10
)
 (
11
)
uma solução intermediária entre as mesmas, que atende a uma boa parte das exigências com um custo competitivo.
O gerenciamento de projetos tenta adquirir controle sobre as variáveis
· tempo - influencia o prazo até o termino do projeto. Uma restrição de tempo pode significar custos aumentados e/ou escopo reduzido.
· custo - informa o valor monetário incluído no orçamento disponível para o projeto. Um orçamento apertado pode significar tempo aumentado e/ou escopo reduzido.
· escopo - designa o que deve ser feito para produzir o resultado de fim do projeto. O escopo aumentado pode significar o tempo aumentado e/ou o custo aumentado.
Na versão atual do PMBOK, tríplice restrição foi eliminada, passando a existir restrições do projeto que são elas: Escopo, Qualidade, Cronograma, Orçamento, Recursos e Riscos. Portanto, qualquer alteração em um desses itens certamente haverá restrições em um ou mais dos demais itens.
Para manter o controle sobre o projeto do início ao fim, um gerente de projetos utiliza várias técnicas, dentre as quais se destacam:
· Planejamento de projeto
· Análise de valor agregado
· Gerenciamento de riscos de projeto
· Cronograma
· Melhoria de processo
1.2 Processos do PMBOK
O Guia PMBOK3 identifica um subconjunto do conjunto de conhecimentos em gerenciamento de projetos, que é amplamente reconhecido como boa prática, sendo em razão disso, utilizado como base pelo Project Management Institute (PMI). Uma boa prática não significa que o conhecimento e as práticas devem ser aplicadas uniformemente a todos os projetos, sem considerar se são ou não apropriados.
O Guia PMBOK também fornece e promove um vocabulário comum para se discutir, escrever e aplicar o gerenciamento de projetos possibilitando o intercâmbio eficiente de informações entre os profissionais de gerência de projetos.
O guia é baseado em processos e subprocessos para descrever de forma organizada o trabalho a ser realizado durante o projeto. Essa abordagem se assemelha à empregada por outras normas como a ISO 9000 e o Software Engineering Institute's, CMMI.
A versão 2008 do guia, cita 42 processos agrupados em cinco grupos e nove áreas de conhecimento. O conhecimento de gerenciamento de projetos, descrito no Guia PMBOK consiste em:
· Definição do ciclo de vida e da organização de um projeto
· Descrição dos cinco grupos de processos de gerenciamento de projetos
· Grupo de processos de iniciação
· Grupo de processos de planejamento
· Grupo de processos de execução
· Grupo de processos de monitoramento e controle
· Grupo de processos de encerramento
· Descrição das nove áreas de conhecimento
Existem três documentos principais descritos no Guia PMBOK® e cada um deles possui um objetivo específico:
· Termo de abertura do projeto. Autoriza formalmente o projeto.
· Declaração do escopo do projeto. Determina qual trabalho deverá ser realizado e quais entregas precisam ser produzidas.
· Plano de gerenciamento do projeto. Determina como o trabalho será realizado.
3 http://pt.wikipedia.org/wiki/PMBOK
1.2.1 Áreas de conhecimento do PMBOK
Os quarenta e dois processos dos cinco grupos definidos pelo PMBOK podem ser classificados em nove chamadas áreas de conhecimento.
	
	Iniciação
	Planejamento
	Execução
	Monitoramento e controle
	Encerramento
	
4 - Integração
	Desenvolver o termo de abertura do projeto Desenvolver o escopo
preliminar do projeto
	Desenvolver o plano de gerenciamento de projeto
	Orientar e gerenciar a execução do projeto
	Monitorar e controlar o trabalho do projeto Controle integrado de
mudanças
	Encerrar o projeto
	
5 - Escopo
	
	Planejamento do escopo
Definição do escopo Criar EAP
	
	Verificação do escopo Controle do escopo
	
	
6 - Tempo
	
	Definição das atividades Sequenciamento de atividades
Estimativa de recursos das atividades
Estimativa de duração das atividades Desenvolvimento do
cronograma
	
	Controle do cronograma
	
	7 - Custo
	
	Estimativa de custos
Orçamentação
	
	Controle de custos
	
	8 - Qualidade
	
	Planejamento da qualidade
	Realizar a garantia da
qualidade
	Realizar o controle da
qualidade
	
	
9 - RH
	
	Planejamento de RH
	Controlar ou mobilizar a equipe do projeto Desenvolver a equipe do
projeto
	Gerenciar a equipe do projeto
	
	
10 - Comunicação
	
	Planejamento das comunicações
	Distribuição das informações
	Relatório de desempenho Gerenciar as partes
interessadas
	
	
11 - Riscos
	
	Planejamento de gerenciamento de riscos Identificação dos riscos Análise qualitativa dos riscos
Análise quantitativa dos riscos
Planejamento de respostas
a riscos
	
	Monitoramento e controle de riscos
	
	
12 - Aquisições
	
	Planejar compras e aquisições
Planejar contratações
	Solicitar respostas dos fornecedores
Selecionar fornecedores
	Administração de contratos
	Encerramentos de contratos
Os processos descritos se relacionam e interagem durante a condução do trabalho e a descrição de cada um deles é feita em termos de:
· Entradas – documentos, planos, desenhos etc.
· Ferramentas e técnicas - que se aplicam as entradas
· Saidas – que podem ser entradas de outros processos
1.2.1.1 Integração de projetos
Núcleo do gerenciamento de projetos, é composto dos processos do dia-a-dia com os quais o gerente de projetos conta para garantir que todas as partes do projeto funcionem juntas. É um processo contínuo que o gerente completa para garantir que o projeto prossiga do início ao fim – é a atividade diária de completar o trabalho do projeto..
1.2.1.2 Escopo de projetos
Garantir que o projeto inclui todo o trabalho requerido (requisitos), e somente o trabalho requerido.
· Destaca-se nesta área a criação da estrutura analítica de processos (EAP), ou Work Breakdown Structure (WBS), uma ferramenta de decomposição do trabalho do projeto em partes manejáveis, uma estrutura em forma de árvore exaustiva, hierárquica (de mais geral para mais específica) de entregáveis (deliverables) e tarefas, genericamente pacotes, que precisam ser feitas para completar um projeto. Um instrumento facilitador do planejamento de projeto que o desmembra em atividades menores que podem ser mais facilmente dimensionadas em relação a tempo de execução, recursos e custos.
1.2.1.3 Tempo de projetos
· Completar o projeto dentro do prazo.
1.2.1.4 Custo de projetos
· Completar o projeto dentro do orçamento.
1.2.1.5 Qualidade de projetos
· Garantir que o projeto vai satisfazer as necessidades pelas quais ele foi feito. Qualidade não é o melhor resultado possível, mas o atendimento justo dos requisitos, do cronograma e orçamento.
· Qualidade é a totalidade de características de uma entidade que a torna capaz de satisfazer necessidades declaradas ou implícitas .
· Um aspecto crítico da gerência da qualidade, no contexto do projeto, é a necessidade de traduzir as necessidades implícitas em necessidades declaradas, através da gerência do escopo do projeto
1.2.1.6 Recursos humanos de projetos
· Fazer o uso mais efetivo das pessoas envolvidas no projeto.
1.2.1.7 Comunicações de projetos
· Garantir rápida e adequada geração, coleção, disseminação, armazenamento e disposição final das informações do projeto.
1.2.1.8 Riscos de projetos
· Identificar, analisar e responder aos riscos do projeto.
1.2.1.9 Aquisições de projetos
· Adquirir bens e serviços externos.
1.3 Planejamento e controle de métricas de projeto
Métricas são medidas quantitativasque podem produzir informações usadas para minimizar atrasos e riscos, e para avaliar a qualidade durante o desenvolvimento.
Definições:
· Medida - fornece uma indicação quantitativa da extensão, quantidade, dimensão, capacidade ou tamanho de algum atributo de um produto ou processo.
· Medição - ato de determinação de uma medida.
· Métrica - medida quantitativa do grau em que um sistema se encontra em relação a um determinado atributo.
Ilustração 1 Métricas
· Indicadores - métrica ou combinação de métricas que fornece uma compreensão de um processo, projeto ou produto.
Tipos de métricas:
· Diretas - custo, esforço, linhas de código (LOC), velocidade de execução, memória utilizada, defeitos reportados etc.
· Indiretas - qualidade, funcionalidade, complexidade, eficiência, confiabilidade, manutebilidade etc. O planejamento de métricas pode ser feito em etapas.
· Fase 1 – caracterização dos indicadores
· Fase 2 – medição
· Fase 3 – tratamento estatístico
· Fase 4 – monitoramento e análise
· Fase 5 – gestão do processo
As tendências são mais importantes de serem monitoradas do que qualquer valor absoluto no tempo. As métricas para determinados aspectos do projeto incluem:
	Métrica
	Finalidade
	Exemplos de medidas/perspectivas
	Andamento em termos de tamanho e complexidade
	Planejamento de iteração Abrangência
	Número de classes SLOC
Pontos de função Cenários
Casos de teste
	
	
	Essas medidas também podem ser coletadas por classe e por pacote
	
	
	Quantidade de retrabalho por iteração (número de classes)
	Estabilidade em termos de taxa de mudança nos requisitos ou implementação, tamanho ou complexidade
	Convergência
	Número e tipo de mudanças (erro versus melhoria; interface versus implementação) Essa medida também pode ser coletada por iteração e por pacote
Quantidade de retrabalho por iteração
	Adaptabilidade
	Convergência "Retrabalho" de software
	Média de pessoa-horas/mudança
Essa medida também pode ser coletada por iteração e por pacote
	Modularidade em termos do escopo de mudança
	Convergência "Retalhamento" de software
	Número de classes/categorias modificadas por mudança
Essa medida também pode ser coletada por iteração
	Qualidade em termos
	Planejamento de iteração
	Número de erros
	da quantidade e do tipo
	Indicador de retrabalho
	Taxa de detecção de defeitos
	de erros
	Critério de release
	Densidade de defeitos
	
	
	Profundidade da herança
	
	
	Acoplamento de classes
	
	
	Tamanho da interface (número de operações)
	
	
	Número de métodos substituídos
	
	
	Tamanho do método
	Métrica
	Finalidade
	Exemplos de medidas/perspectivas
	
	
	Essas medidas também podem ser coletadas por classe e por pacote
	Maturidade em termos da freqüência de erros
	Adequação/cobertura de teste
Resistência para uso
	Falha/horas de teste e tipo de falha
Essa medida também pode ser coletada por iteração e por pacote
	Perfil de despesas do projeto versus despesas planejadas
	Visão financeira Planejado versus real
	Pessoa-dias/classe
Equipe em tempo integral por mês Porcentagem do orçamento já gasta
1.4 Métodos de gerenciamento do tempo do projeto
Existem métodos que objetivam formas de comprimir as durações das atividades sem alteração no escopo do projeto.
Crashing é usado para diminuir a duração total do cronograma do projeto pelo menor custo adicional, como redução das durações ou aumento da atribuição de recursos nas atividades do cronograma.
Paralelismo ou fast tracking é usado para tentar programar atividades em paralelo (simultâneas), mas costuma gerar retrabalho e aumenta os riscos. É uma técnica de compressão do cronograma de um projeto específico que altera a lógica de rede para sobrepor fases que normalmente seriam realizadas em seqüência, como a fase de projeto e a fase de construção, ou para realizar atividades do cronograma em paralelo.
Uma simulação do projeto utiliza um modelo que traduz as incertezas especificadas em um nível detalhado do projeto para seu impacto potencial nos objetivos do projeto. As simulações são normalmente realizadas usando a técnica de Monte Carlo. Em uma simulação, o modelo do projeto é calculado muitas vezes (iterado), sendo os valores das entradas randomizados a partir de uma função de distribuição de probabilidades (por exemplo, custo dos elementos do projeto ou duração das atividades do cronograma) escolhida para cada iteração a partir das distribuições de probabilidades de cada variável. Uma distribuição de probabilidades (por exemplo, custo total ou data de término) é calculada.
1.5 Exercícios
1. (ICMS-SP 2009) A respeito dos conceitos aplicados aos Projetos, segundo o PMBOK, é INCORRETO afirmar:1
(a) A equipe do projeto, como uma unidade de trabalho, raramente sobrevive ao projeto.
(b) Um projeto é um esforço contínuo que visa manter um serviço em funcionamento.
(c) Geralmente, o termo "temporário" não se aplica ao produto, serviço ou resultado criado pelo projeto.
(d) Pode ser classificado como projeto aquele que é do tipo de pesquisa que desenvolve um conhecimento.
(e) Os projetos podem criar uma capacidade de realizar um serviço.
2. (ICMS-SP 2009) São entradas para o processo de Planejamento da Qualidade (PMBOK):2
(a) Fatores ambientais da empresa, Ativos de processos organizacionais e Declaração do escopo do projeto.
(b) Análise de custo-benefício, Projeto de experimentos e Métricas de qualidade.
(c) Plano de melhorias no processo, Linha de base da qualidade e Métricas de qualidade.
(d) Plano de melhorias no processo, Fatores ambientais da empresa e Listas de verificação da qualidade.
(e) Plano de gerenciamento da qualidade, Fatores ambientais da empresa e Análise de custo-benefício.
3. (ICMS-SP 2009) No PMBOK, a técnica que compara as realizações técnicas durante a execução do projeto com as do cronograma do plano de gerenciamento do projeto, podendo usar parâmetros técnicos importantes do produto desenvolvido pelo projeto como uma métrica de qualidade, sendo que os valores medidos fazem parte das informações sobre o desempenho do trabalho, é denominada3
(a) Critical Chain Method.
(b) Probability and Impact Matrix.
(c) Work Performance Information.
(d) Performance Measurement Baseline.
(e) Technical Performance Measurement.
4. (ICMS-SP 2009) Planos mais exatos e completos, resultantes de sucessivas iterações do processo de planejamento e estimativas mais exatas, elaboradas à medida que o projeto se desenvolve, são produtos da técnica aplicada para melhoria e detalhamento contínuos dos planos. Essa técnica, no PMBOK, é denominada4
(a) Loop de rede.
(b) Elaboração progressiva.
(c) Estrutura Analítica dos Recursos.
(d) Gerenciamento de Portfólios.
(e) Estimativa paramétrica.
5. Segundo o PMBOK, as etapas de iniciação, planejamento, execução, monitoração/controle e encerramento representam apenas o 5
(a) ciclo de vida dos projetos ou ciclo de gerenciamento de projetos.
(b) grupo de processos dos projetos ou ciclo de gerenciamento de projetos.
(c) grupo de processos dos projetos ou ciclo de vida dos projetos.
(d) grupo de processos do gerenciamento de projetos ou ciclo de vida dos projetos.
(e) grupo de processos do gerenciamento de projetos ou ciclo de gerenciamento de projetos.x
6. Os processos do PMBOK: criação da estrutura analítica do projeto (EAP) e verificação do escopo do projeto devem ser realizados, respectivamente, nas etapas de 6
(a) planejamento e execução.
(b) planejamento e monitoração/controle.
(c) iniciação e execução.
(d) iniciação e monitoração/controle.
(e) iniciação e encerramento.
7. Considere a seguinte definição com respeito à gerência de projetos: Ferramenta de decomposição do trabalho do projeto em partes manejáveis. É uma estrutura em forma de árvore exaustiva, hierárquica (de mais geral para mais específica ) de deliverables e tarefas que precisam ser feitas para completar um projeto.
Tal é a definição de 7
(a) Histogram.
(b) Workflow.
(c) Timesheet.
(d) Work Breakdown Structure.
(e) Flowchart.
8. Um instrumento facilitador do planejamento de projeto que o desmembra em atividades menores que podem ser mais facilmentedimensionadas em relação a tempo de execução, recursos e custos, é o 8
(a) Flowchart.
(b) Organization Chart.
(c) Workflow.
(d) Histogram.
(e) Work Breakdown Structure.
9. De acordo com o corpo de conhecimento da gerência de projetos, as simulações para análise de risco de prazos são possíveis utilizando 9
(a) o Arrow Diagramming Method.
(b) a técnica Monte Carlo.
(c) o modelo WBS.
(d) a análise de custo/benefício.
(e) o Project Charter.
10. O WBS, Word Breakdown Structure, é a principal ferramenta de gerenciamento de 10
(a) escopo do projeto.xx
(b) integração dos elementos do projeto.
(c) pessoal envolvido com o projeto.
(d) comunicação das informações do projeto.
(e) qualidade do projeto.
11. Considere a seguinte figura:
No contexto da gerência de projetos de software, o diagrama parcialmente mostrado na figura representa, tipicamente, 11
(a) um PERT.
(b) um gráfico de Gantt.
(c) uma Work Breakdown Structure.
(d) um Project Charter.
(e) um Flowchart.
12. De acordo com o corpo de conhecimento da gerência de projeto, a necessidade de traduzir as necessidades implícitas em necessidades declaradas, através da gerência do escopo do projeto, é 12
(a) um aspecto crítico da gerência da qualidade, no contexto do projeto.
(b) objeto de avaliação da gerência do custo do projeto.
(c) dispensada se for elaborado um planejamento de respostas aos riscos.
(d) destacada durante a medição de desempenho.
(e) um aspecto crítico da análise de precedência de tarefas.
13. De acordo com o corpo de conhecimento da gerência de projeto, para estimar os custos totais, quando ainda existe uma quantidade limitada de informações detalhadas sobre o projeto (por exemplo, nas fases iniciais), é freqüentemente 13
(a) elaborado um modelo paramétrico.
(b) usada uma estimativa por analogia.
(c) usada uma estimativa bottom-up.
(d) elaborada uma análise de precedência.
(e) elaborada uma análise da variação.
14. Existem métodos que objetivam formas de comprimir as durações das atividades sem alteração no escopo do projeto. Um deles é usado para quando existem negociações de agenda e custos para determinar como (e se) fazer a maior compressão para o menor custo. Outro é usado para tentar programar atividades em paralelo (simultâneas), mas costuma gerar retrabalho e aumenta os riscos. São usual e respectivamente denominados de métodos 14
(a) crashing e what-if.
(b) de Monte Carlo e what-if.
(c) fast tracking e de Monte Carlo.
(d) crashing e fast tracking.
(e) what-if e crashing.
15. Para um gerenciamento de projeto de informática bem sucedido, a ordem de execução das atividades deve ser 15
(a) planejamento, integração, organização, medição e revisão.
(b) planejamento, organização, integração, medição e revisão.
(c) organização, planejamento, integração, medição e revisão.
(d) organização, planejamento, medição, integração e revisão.
(e) planejamento, organização, medição, revisão e integração.
16. (ARCE FCC 2006) O fator de máximo desempenho de um projeto está diretamente relacionado ao fator de 16
(a) escopo limitado.
(b) escopo genérico.
(c) tempo reduzido.
(d) custo alto.
(e) tempo excessivo.
17. (CVM FCC 2006) Dentre os fatores que afetam os projetos, o fator performance se aproxima do máximo, ou ponto ótimo, quando relacionado ao fator 17
(a) custo alto.
(b) tempo reduzido.
(c) tempo excessivo.
(d) escopo limitado.
(e) escopo genérico.
18. Duas atividades de um projeto podem ocorrer simultaneamente quando o inter-relacionamento das mesmas é do tipo 18
(a) início para início (SS) ou término para início (FS).
(b) término para término (FF) ou término para início (FS).
(c) início para início (SS) ou término para término (FF). x
(d) início para término (SF) ou término para término (FF).
(e) término para início (FS) ou início para término (SF).
19. Os produtos a serem entregues no mais baixo nível da estrutura do projeto (WBS) geralmente são 19
(a) pacotes de trabalho.
(b) planos do projeto.
(c) fases do projeto.
(d) recursos disponíveis.
(e) cronogramas do projeto.
20. Segundo o uso universal dos conceitos de gerenciamento de projetos, um programa é 20
(a) um empreendimento não repetitivo de eventos numa seqüência clara e lógica, com início, meio e fim.
(b) parte de um projeto ou subdivisão tática de fácil gerenciamento e controle.
(c) um subprojeto, desvinculado de um projeto, que pode ser terceirizado.
(d) um conjunto integrado de projetos que tem missões e objetivos comuns.
(e) um conjunto de subprojetos, que podem ter vidas próprias isoladamente.
21. No ciclo da vida de um projeto, são aplicáveis todos os nove processos componentes da área de gerenciamento de projetos somente na fase de 21
(a) iniciação.
(b) finalização.
(c) planejamento.
(d) execução.
(e) controle.
22. Na determinação de cronogramas utilizando os modelos PERT e CPM, o caminho crítico representa 22
(a) a estimativa de tempo mais provável para o conjunto de tarefas do projeto.
(b) o término mais breve da cada tarefa do projeto.
(c) os limites de tempo que definem o início e o término da cada tarefa.
(d) uma cadeia de tarefas que determina a duração do projeto.
(e) uma rede de todas as tarefas desde o começo até o final de um projeto.
2 Gestão de Processos de Negócio (BPM)
O Business Process Management (BPM) ou Gerenciamento de Processos de Negócio é um conceito que une gestão de negócios e tecnologia da informação com foco na otimização dos resultados das organizações através da melhoria dos processos de negócio. São utilizados métodos, técnicas e ferramentas para analisar, modelar, publicar, otimizar e controlar processos envolvendo recursos humanos, aplicações, documentos e outras fontes de informação. 4
Um processo de negócio é uma sequência de tarefas que, ao serem executadas, transforma insumos em um resultado com valor agregado.
Distingue-se do conceito de BI (business intelligence), pois este monitora as informações que dão suporte ao negócio, enquanto aquele monitora os processos que o compõe. O BI é uma ferramenta útil à gestão de processos de negócios.
2.1 BPMN - Modelagem de processos
O Business Process Modeling Notation, em português Notação de Modelagem de Processos de Negócio, é uma notação da metodologia de gerenciamento de processos de negócio e trata-se de uma série de ícones padrões para o desenho de processos, o que facilita o entendimento do usuário.
A modelagem é uma etapa importante da automação, pois é nela que os processos são descobertos e desenhados. É nela também que pode ser feita alguma alteração no percurso do processo visando a sua otimização.
A notação também pode ser utilizada para a modelagem de Arquitetura de Processos.
O objetivo do BPMN é de apoiar a gestão de processos de negócios tanto para usuários técnicos e usuários de negócios, fornecendo uma notação que é intuitiva para os usuários corporativos ainda capaz de representar a semântica complexa do processo.
2.1.1 Elementos
A modelagem em BPMN é feita através de diagramas simples, com um pequeno conjunto de elementos gráficos. Isto facilita que os usuários de negócio, bem como os desenvolvedores, entendam o fluxo e o processo. As quatro categorias básicas de elementos são as seguintes:
· Objetos de Fluxo – definem o comporatmento do fluxo. Fazem a movimentação das informações através de ações.
· Eventos – Qualquer coisa que acontece durante o fluxo. Ações (trigger) que interferem no fluxo (result), tipicamente prazos, também podendo ser uma chamada de um sistema externo (web service) ou alguma alteração no banco de dados (watching). Representado por um círculo. Há três tipos de eventos: início, intermediário e fim.
· Atividades – Ações (sub-processos ou tarefas) realizadas pelos usuários, chamados de atores, normalmente por tela de algum programa de computador. Representada por um retângulo arredondado.
· Gateways – Controla a convergência e divergência da sequência de fluxos e atividades no fluxo. Determina ramificações (branch), bifurcações (forking), mistura (merging) e junções (join) de caminhos. Representado por um losango.
· Objetos de Conexão
· Fluxo de Sequência– seta em linha contínua ligando dois objetos, indica a ordem de execução dos objetos.
· Fluxo de Mensagem – seta em linha tracejada indicando o fluxo de mensagens entre participantes
· Associação – linha ou seta em linha pontilhada indicando uma ligação entre uma informação, normalmente uma anotação, e um artefato.
· Swim lane – uma área de agrupamento de objetos de fluxo representado por uma faixa que vai da esquera à direita da página, com um nome para a faixa em seu lado esquerdo.
· Pool – indica um participante, setor, departamento ou qualquer lugar onde se encontram os atores. Um pool pode apresentar detalhes internos do processo (white box) ou pode ter nenhum processo (black box). A interação entre pools é feita através de fluxos de mensagens. Nenhum fluxo de sequência pode ser associado a black boxes, mas os fluxos de mensagem podem ligá-los.
· Lane – subdivisão de uma pool.
4 http://pt.wikipedia.org/wiki/Business_Process_Management
· Dados – possuem informações que os objetos de fluxo necessitam para serem realizadas
· Objetos de dados – informações armazenadas
· Dados de entrada – informações solicitadas
· Dados de saída – informações produzidas em uma atividade ou evento
· Armazenamento – gravação dos dados
· Artefatos – informações adicionais sobre o fluxo
· Grupo – agrupamento de elementos de uma mesma categoria para fins de entendimento, sem efeito sobre o fluxo. Representado por um retângulo arredondado tracejado.
· Anotação – uma observação para facilitar o entendimento do fluxo para o leitor. Represnetado por uma linha de associação terminada por um colchete e o texto.
· Mensagem – informação enviada entre dois participantes. Representado por ícone de uma carta.
Estas quatro categorias de elementos nos dão a oportunidade de fazer um diagrama de processos de negócio simples (BPD).
Ilustração 2 Exemplo de Fluxo utilizando pool, lanes, evento de início e fim, tarefas e gateway
Ilustração 3 Símbolos BMPN utilizados no MS Visio
2.2 Técnicas de análise de processos
2.2.1 Automação de processos
Realizada pelos BPMS, divide-se em modelagem, simulação, execução, controle e otimização.
Um aplicativo do tipo BPMS, tipicamente, inclui o mapeamento dos processos de negócio ponta-a- ponta, desenho dos fluxos e formulários eletrônicos, definição de workflow, regras de negócio, integradores, monitoração em tempo real das atividades e alertas. É uma poderosa ferramenta de gestão, para garantir que os processos estão sendo efetivamente executados como modelados, contribuindo para os objetivos da organização.
A modelagem de processos é feita no próprio BPMS. Alguns destes seguem a notação mais usada atualmente, o BPMN (Business Process Modeling Notation). Esta notação trata-se de uma série de ícones padrões para o desenho de processos, o que facilita o entendimento do usuário. A modelagem é uma etapa importante da automação pois é nela que os processos são descobertos e desenhados. É nela também que pode ser feita alguma alteração no percurso do processo visando a sua otimização.
Após o desenho e o estabelecimento dos usuários responsáveis pela conclusão de cada tarefa, pode ser feita uma simulação, onde se pode testar se as regras pré-estabelecidas estão de acordo com o objetivo da empresa e se as tarefas estão sendo encaminhadas para as pessoas corretas.
A execução do processo ocorre após as etapas anteriores já terem sido realizadas. O BPMS utilizado faz com que as tarefas sejam enviadas para os seus devidos responsáveis, controlando o seu tempo de execução por pessoa e pelo processo em geral. Podem ser utilizadas também regras de negócio (Business Rules) pré-estabelecidas.
O controle ideal de BPM é aquele que está presente durante todas as etapas do processo: antes, durante e depois. Desde o início da modelagem até a análise pós-conclusão da execução, o controle deve ser realizado. Um tipo de controle que existe em alguns BPMS são relatórios de fluxos em andamento, onde é fornecido o status do fluxo, com quem está parado, há quanto tempo está parado, etc. Isso é importante para evitar que os erros sejam encontrados somente quando o processo é concluído. Há também relatórios de fluxos concluídos, onde se pode ter uma noção geral de como se desenvolveu o processo. Alguns softwares apresentam gráficos e relatórios com bastantes detalhes dos processos.
A otimização tem crucial importância quando se trata de BPM. É essencial para que sejam feitas melhorias nos processos de modo a alcançar resultados positivos mais rapidamente, melhorando o serviço aos clientes e, possivelmente, com menores custos. Depende, obviamente, das etapas anteriores, principalmente do controle, onde deve haver uma busca pela perfeição.5
2.2.2 Fluxograma
Diagrama que descreve a sequência de atividades de um processo empresarial através de uma simbologia padronizada, utilizando retângulos para representar atividades, losangos para pontos de decisão e setas para indicar o fluxo. Estes simbolos vêm acompanhado de textos explicativos.
Fácil de utilizar, mas pouco apropriado para representar processos de grande complexidade e divergências.
O fluxograma considera o processo do ponto de vista da empresa.
2.2.3 Service blueprint
Técnica de mapeamenteo de serviços derivado do fluxograma que considera o aspecto de interação com o cliente.
É um mapa de todas as transações que constituem o processo de entrega do serviço. Divide-se em duas regiões separadas por uma linha, chamada de linha de visibilidade.
Na parte de cima da linha, é a área de evidências físicas percebida pelo cliente, as suas ações e interações com os empregados. Na parte de baixo, encontram-se as ações dos empregados e os processos de suporte que são invisíveis para o cliente.
As evidências físicas, mostradas na parte de cima, identificam elementos que o cliente pode usar como indicador da qualidade do serviço. Cada conexão vertical através da linha de interação indica um ponto
5 http://pt.wikipedia.org/wiki/Gest%C3%A3o_de_processos_de_neg%C3%B3cio
 (
TI para concursos
)
 (
TI para concursos
)
 (
22
)
 (
21
)
de contato. Estes pontos funcionam como o “momento da verdade” de cada serviço e podem ser usados como pontos de potencial falhas no sistema de serviço.
Fonte: http://www.lgti.ufsc.br/public/luciano.pdf
Apesar de ser mais evoluido do que os fluxogramas, também não consegue representar uma descrição completa da experiência com o cliente. O foco está na tarefa e não no cliente.
2.2.4 Mapa do serviço
Forma visual de três elementos críticos de serviços: processso de entrega de serviço, os papéis dos clientes e empregados e elementos visíveis de serviço. A criação do mapa requer a identificação de evidências físicas do serviço, indicadores de qualidade, as pessoas envolvidas e o fluxo operacional de atividades de entrega de serviços. Foca os serviços do ponto de vista do consumidor.
É uma evolução do service blueprint.
Logo acima da linha de visibilidade, há uma linha horizontal que indica o contato do cliente com os empregados de atendimento. Abaixo da linha de visibilidade há outra que indica a relação entre o suporte e o processso de entrega de serviço. Mais abaixo, outra linha separa a gerência do suporte.
O mapa pode ser lido horizontalmente para entender as ações ou passos realizados pelos clientes e empregados, ou lido verticalmente para compreender as ações de suporte, os processos e estruturas.
2.2.5 IDEF
Família de métodos de estruturar e analisar uma empresa. Utilizam-se de diagramas para representar os processos.
Cada tarefa é representada por um retângulo. Cada lado representa uma informação de entrada, saída de produtos e/ou informações, recursos disponíveis e condições para ativação.
A ênfase não está na sequência, mas no conteúdo das atividades e nos recursos envolvidos no processo. Exemplo:
Controle
Entradas
 (
Processo
)Mecanismo
Saídas
2.2.5.1 IDEF0
Método de modelagem funcional usado para processos associados a decisões, ações e atividades.
2.2.5.2 IDEF1
Método de modelagem de informação, para expressão dos requisitosde um sistema.
2.2.5.3 IDEF3
Método de captura da descrição do processo, que relaciona causa e efeito entre processos.
2.2.5.4 IDEF4
Método de desenho orientado a objeto, que auxilia no projeto de sistemas orientados a objetos.
2.2.5.5 IDEF5
Método de identificação de ontologias associadas aos processos e informações.
2.2.5.6 IDEF9
Método para auxiliar na identificação de restrições associadas a um sistema ou processo.
2.2.6 Estrutura de processamento de clientes
Modelo genérico de atividades-chave que são comuns à maioria dos processos de serviços. Visa especificamente o fluxo de clientes, indicando apenas atividades com eles.
São identificadas sete atividades-chave:
· seleção, cliente decide a escolha
· ponto de entrada, contato com a operação escolhida
· tempo de resposta, tempo de espera para que o sistema responda
· ponto de impacto, cliente é atendido
· prestação de serviço, o serviço é prestado
· ponto de partida, o cliente sai do processo
· acompanhamento, atividades sobre o cliente após a conclusão do serviço
2.2.7 Walk-through-audit
Método de auditoria, que consiste em uma série de questões dirigidas aos clientes, e gerentes de serviços, para avaliação sistemática da visão do cliente sobre o serviço prestado.
Utilizam-se questões estruturadas que avaliam cada etapa do processo em uma escala de um a cinco, respondidas durante ou imediatamente após o serviço, ou aplicadas em clientes da concorrência.
Além de avaliar a percepção do cliente, também permite analisar a lacuna entre a opinião do cliente e da gerência e entre a empresa e a concorrência.
Funciona em conjunto com alguma outra técnica gráfica.
2.2.8 Análise da transação de serviço (STA – Service Transaction Analysis)
Método de avaliação do processo do ponto de vista do cliente, combinando quatro elementos: o conceito do serviço, o processo do serviço, a avaliação da qualidade em cada transação e a interpretação do serviço pelo cliente. Utiliza um formulário denominado “folha de análise da transação de serviço”.
Pessoas fazendo papel de clientes caminham ao longo do processo para analisar como o cliente poderia avaliar cada transação, usando uma mensagem curta e uma escala de três pontos: (-) insatisfeito, (0) satisfeito ou (+) muito satisfeito.
2.3 Exercícios
23. (ICMS-SP 2009) No diagrama de fluxos de negócio (BPMN), para estabelecer "quem faz o que" devem ser representados os fluxos de negócio agrupados em 23
(a) processes e tasks.
(b) events e gateways.
(c) pools e lanes.
(d) pools e processes.
(e) lanes e tasks.
24. (ICMS-SP 2009) Na modelagem de processos de negócio (BPMN), NÃO se aplica um End Event no tipo de
trigger 24
(a) Exception.
(b) Link.
(c) Message.
(d) Multiple.
(e) Timer.
25. (ICMS-SP 2009) Na modelagem de processos de negócio (BPMN), os Fluxos de Mensagem devem ser desenhados 25
(a) entre white boxes.
(b) entre black boxes.
(c) entre tasks.
(d) dentro de tasks.
(e) dentro de black boxes.
3 Gerência de Serviços de TI
A administração moderna de tecnologia de informação busca fundamentos em boas práticas de gerenciamento alinhadas com objetivos do negócio.
Prática é uma maneira de trabalhar. Melhores práticas são atividades ou processos que tenham sido utilizados com sucesso.
O conceito de Governança Tecnológica, do termo em inglês IT Governance, define que a TI é um fator essencial para a gestão financeira e estratégica de uma organização. Governança Tecnológica é a metodologia (e seus processos integrados) de gestão corporativa dos recursos de TI.6
A governança de TI trata da integração e uso de processos corporativos suportados pelos pacotes de gestão, por exemplo: BI (Business Intelligence), CRM (Customer Relationship Management), ERP (Enterprise Resource Planning) e SCM (Supply Chain Management).
De acordo com a ISO/IEC 38500, são seis princípios para governança de TI:7
· Responsabilidade – papéis e responsabilidades bem definidos na entrega de TI aos clientes e na sua aquisição, e garantia de autoridade compatível para o exercício desses papéis.
· Estratégia – O desenvolvimento da estratégia de negócio considera a as capacidades atuais e futuras de TI e o planejamento de TI busca atender às necessidades atuais e continuadas do negócio da organização (alinhamento).
· Aquisições – As aquisições de TI são adequadamente motivadas por meio de análises apropriadas e continuadas e de decisões claras e transparentes, de modo a garantir o alcance de equilíbrio adequado entre benefícios, oportunidades, custos e riscos, tanto no curto como no longo prazo.
· Desempenho – A TI é estruturada para suportar adequadamente a organização e dispor serviços com os níveis e com a qualidade necessários para responder aos requisitos atuais e futuros do negócio.
· Conformidade – A TI está em conformidade com a legislação e regulamentos aplicáveis. As políticas e as práticas estão claramente definidas, encontram-se implementadas e são aplicadas.
· Comportamento Humano – As políticas, práticas e decisões relativas ao uso e gestão da TI consideram e respeitam o comportamento humano e incluem as necessidades atuais e a evolução das necessidades de todas as pessoas envolvidas no processo.
ITIL é um framework, ou uma estrutura de gerência de serviços de TI. Em sua versão 2, o foco era a própria prestação de serviços. Na versão 3, o ITIL mudou seu foco para a o alinhamento dos objetivos de serviços de TI com os do negócio, mudando da abordagem operacional para uma visão mais estratégica do uso da tecnologia.
O COBIT é um guia de boas práticas para a gestão de tecnologia, não apenas serviços.
6 http://www.trainning.com.br/download/Apostila_ITIL_Cobit.pdf
7 http://www.geraldoloureiro.com/wiki/images/9/98/WGov_Palestra_ClaudioCruz.pdf
3.1 Fundamentos da ITIL V2
Estrutura abstrata (framework) de serviços de TI. Orienta o “como fazer” das funções do gerente de tecnologia, dividindo estes serviços em dois grandes grupos – suporte a serviços e entrega de serviços
– unidos por uma central de atendimento (service desk).
3.1.1 Suporte a serviços
O suporte a serviços tem foco nos usuários da instituição, administrando incidentes, suas origens (problema) e definindo formas de tratamento e de alterações necessárias para resolução.
3.1.1.1 Central de serviços (service desk)
Suporte de primeiro nível. Atendimento ao usuário.
3.1.1.2 Gerenciamento de incidentes (apaga incêndio)
Restaurar o serviço o mais rápido possível, para minimizar o impacto nos negócios e para garantir o melhor nível de serviço, no tocante qualidade e disponibilidade.
Um incidente é um evento que não faz parte da operação padrão do serviço e que causa, ou poderá causar uma interrupção, ou uma redução na qualidade do serviço.
3.1.1.3 Gerenciamento de problemas (desenvolvimento de soluções)
Buscar a causa raiz do incidente e sua conseqüente solução e prevenção.
Um Problema é um erro de causa desconhecida que pode causar um ou mais incidentes.
Um Problema poderá ser um Erro Conhecido (Known Error) quando a causa raiz (root cause) tornar conhecida e uma Solução de Contorno (work-around) ou permanente for identificada e aplicada.
As soluções são registradas na gerência de configuração e as mudanças necessárias são requisitadas à gerência de mudanças.
3.1.1.4 Gerenciamento de mudanças (implementação)
A partir de requisições de mudanças dos usuários ou do gerenciamento de problemas, implementa mudanças aprovadas, de maneira eficiente, em um custo efetivo, com um mínimo risco à infra-estrutura de TI existente e à nova.
3.1.1.5 Gerenciamento de liberação (implantação)
Libera e distribui a alteração autorizada. Implanta.
3.1.1.6 Gerenciamento de configuração (controle da infra-estrutura)
Gerenciar o banco de dados de todos os componentes necessários para fornecer serviços
3.1.2 Entrega de Serviço
A entrega de serviços volta-se para o cliente, preocupando-se em garantir uma qualidade ótima em função da estratégia do negócio, além da efetividade do serviço prestado como resultado de uma gestão de recursos tecnológicos (ativos) e financeiros.
3.1.2.1Gerenciamento de nivel de serviço
A partir de um acordo do nível de serviço entre a TI e os usuários, contendo os requisitos do usuário, gerencia a qualidade dos serviços oferecidos, procurando a maior qualidade em consonância com o negócio da empresa.
3.1.2.2 Gerenciamento financeiro
Como JUSTIFICAR o orçamento? Necessidades da TI para o negócio planejados a partir dos processos (Mudança, Nível, Capacidade e Disponibilidade) compõe o orçamento e acompanhamento financeiro.
3.1.2.3 Gerenciamento de disponibilidade
Análise de riscos, oportunidades, satisfação, produtividade e tempo de manutenção e indisponibilidade.
3.1.2.4 Gerenciamento de capacidade
Confronto entre capacidade, demanda e satisfação do cliente. Taxa de utilização de recursos humanos e sistemas.
3.1.2.5 Gerenciamento de continuidade de serviços de TI
Todo o esforço possível para evitar interrupções. Implementação de medidas preventivas, testes para operar em ambientes de crise, redução do impacto dos incidentes, seguros.
3.2 Fundamentos de ITIL V38
O núcleo do ITIL V3 é composto de cinco processos baseados no ciclo de vida dos serviços:
· Estratégia do serviço (Service Strategy)
· Projeto de serviço ou Desenho de serviço (Service Design)
· Transição do serviço (Service Transition)
· Operação do serviço (Service Operation)
· Melhoria contínua do serviço (Continual Service Improvement)
Ilustração 4 Ciclo de vida do serviço - Núcleo do ITIL V3
3.2.1 Estratégia do serviço (Service Strategy)
Como ponto de origem do ciclo de vida de serviço ITIL, estratégia do serviço orienta sobre como tornar mais claro e priorizar investimentos sobre provimento de serviços, desenhar, desenvolver e implementar o gerenciamento de serviços.
Processos:
· geração de estratégia,
· gerenciamento de portfólio de serviços,
· gerenciamento de demandas,
· gerenciamento financeiro de TI.
3.2.2 Desenho de serviço (Service Design)
O desenho de serviço fornece orientações para o desenvolvimento de serviços e processos de gerenciamento de serviços, incluindo mudanças e melhorias para aumentar ou manter o valor, para a continuidade dos serviços, para o atingimento de níveis de serviço e para a conformidade às normas.
O trabalho de projetar um serviço de TI é agregado em pacote de projeto de serviços (Service Design Package - SDP).
Processos de gerenciamento de:
· nível de serviço (Service Level Management - SLM)
· disponibilidade
8 http://pt.wikipedia.org/wiki/ITILv3
· capacidade
· continuidade de serviços
· segurança da informação
· fornecedores
· catálogo de serviços.
3.2.3 Transição do serviço (Service Transition)
Este volume é direcionado à entrega dos serviços necessários ao negócio no uso operacional, e geralmente englobam o "projeto".
Processos:
· Planejamento de transição e suporte
· Avaliação
· Teste e validação
· Gerenciamento de configurações e ativos de serviço
· Gerenciamento de liberação e implantação (release and deployment)
· Gerenciamento de mudança (Change Management)
· Gerenciamento de conhecimento
3.2.4 Operação do serviço (Service Operation)
Parte do ciclo de vida onde serviços e valor são entregues diretamente. Assim, monitoramento de problema e balanceamento entre disponibilidade de serviço e custo são considerados.
Processos:
· Cumprimento de requisição.
· Gerenciamento de eventos.
· Gerenciamento de incidentes.
· Gerenciamento de problemas.
· Gerenciamento de acesso, (service desk).
Funções:
· Central de serviços
· Gerenciamento técnico
· Gerenciamento de aplicativos
· Gerenciamento de operações de TI
3.2.5 Melhoria de serviço continuada (Continual Service Improvement)
A meta do CSI é ajustar e reajustar serviços de TI às mudanças contínuas do negócio através da identificação e implementação de melhorias aos serviços de TI que apoiam processos negociais.
Utiliza um sistema cíclico de revisão baseado no modelo PDCA (Plan Do, Check and Act). Processos:
· Medição de serviço
· Relato de serviço
· Sete passos de melhoria
3.3 Fundamentos de COBIT
O COBIT – Control Objectives for Information and Related Technology, tem por missão explícita pesquisar, desenvolver, publicar e promover um conjunto atualizado de padrões internacionais de boas práticas referentes ao uso corporativo da TI para os gerentes e auditores de tecnologia.
A metodologia COBIT foi criada pelo ISACA – Information Systems Audit and Control Association através do IT Governance Institute, organização independente que desenvolveu a metodologia considerada a base da governança tecnológica. O COBIT funciona como uma entidade de padronização e estabelece métodos documentados para nortear a área de tecnologia das empresas, incluindo qualidade de software, níveis de maturidade e segurança da informação.
Os documentos do COBIT definem Governança Tecnológica como sendo uma estrutura de relacionamentos entre processos para direcionar e controlar uma empresa de modo a atingir objetivos corporativos, através da agregação de valor e risco controlado pelo uso da tecnologia da informação e de seus processos”.
COBIT é um guia de boas práticas, que podem servir como um modelo de referência para gestão da TI. Inclui um sumário executivo, um "framework", controle de objetivos, mapas de auditoria, ferramentas para a sua implementação e um guia com técnicas de gerenciamento.
Os domínios do COBIT são integrados da seguinte forma:
· A informação de uma empresa é gerada/modificada pelas atividades de TI.
· Esta informação é requisito para o domínio de Planejamento e Organização (PO).
· Os requisitos de saída do PO são requisitos de entrada de informação para o domínio de Aquisição e Implementação (AI),
· As saídas de AI definem os requisitos de entrada para o domínio de Entrega e Suporte (DS).
· O domínio de Monitoração (M) utiliza as informações do DS nos seus processos e atividades relacionadas.
Os requisitos da informação são dados por: efetividade, eficiência, confidencialidade, integridade, disponibilidade, conformidade e confiabilidade.
Os recursos de TI são classificados como: pessoas, sistemas aplicativos, tecnologia, infraestrutura e dados.
COBIT cobre os quatro domínios, os quais possuem 34 processos (dois objetivos de controle para cada processo).
3.3.1 Planejar e Organizar
Uso de informação e tecnologia e como isso pode ser usado para que a empresa atinja seus objetivos e metas. A forma organizacional e a infra-estrutura da TI deve ser considerada.
· PO1 Definir um Plano Estratégico de TI e Orientações
· PO2 Definir a Arquitetura de Informação
· PO3 Determinar o Gerenciamento Tecnológico
· PO4 Definir os Processos de TI, Organização e Relacionamentos
· PO5 Gerenciar o Investimento em TI
· PO6 Comunicar os Objetivos de Gerenciamento e Orientar
· PO7 Gerenciar os Recusos Humanos de TI
· PO8 Gerenciar a Qualidade
· PO9 Estimar e Gerenciar os Riscos de TI
· PO10 Gerenciar Projetos
3.3.2 Adquirir e Implementar
Requisitos de TI, aquisição de tecnologia e implementação dentro dos processos de negócios da companhia.
Desenvolvimento do plano de manutenção que a companhia adota para prolongar a vida do sistema de TI e seus componentes.
· AI1	Identificar Soluções Automatizadas
· AI2	Adquirir e Manter Software de Aplicação
· AI3	Adquirir e Manter Infraestrutura de Tecnologia
· AI4	Habilitar Operação e Uso
· AI5	Obter Recursos de TI
· AI6	Gerenciar Mudanças
· AI7	Instalar e Credenciar Soluções e Mudanças
3.3.3 Entregar e Dar Suporte
Entrega de tecnologia da informação. Cobre a execução de aplicações dentro do sistema de TI e seus resultados, assim como o suporte dos processos, que incluem questões de segurança e treinamento e habilitam a execução.
· DS1 Definir e Gerenciar Níveis de Serviço
· DS2 Gerenciar Serviços de Terceiros
· DS3 Gerenciar Performance e Capacidade
· DS4 Assegurar Serviço Contínuo
· DS5 Assegurar Segurança de Sistema
· DS6 Identificar e Alocar Recursos
· DS7 Treinar Usuários
· DS8 Gerenciar Serviços de Escritório e Incidentes
· DS9 Gerenciar a Configuração
· DS10 Gerenciar Problemas
· DS11 Gerenciar Dados
· DS12 Gerenciar o Ambiente Físico
· DS13 Gerenciar Operações3.3.4 Monitorar e Avaliar
Estimativa estratégica das necessidades da companhia. Avalia se o atual sistema de TI atinge os objetivos para o qual ele foi especificado e controla os requisitos para atender objetivos regulatórios. Estimativa e capacidade de atingir os objetivos de negócio, controlando os processos internos da companhia através de auditores internos e externos.
· M1	Monitorar os processos
· M2	Assegurar avaliação dos controles internos
· M3	Obter avaliação independente
· M4	Prover auditoria independente
3.4 Exercícios
26. (ICMS-SP 2009) NÃO se trata de elemento que deve ser considerado como parte do controle de mudanças no gerenciamento de configuração:26
(a) revisões e auditoria das mudanças.
(b) confiabilidade das instalações das modificações.
(c) análise de impacto de mudanças.
(d) conjunto de modificações.
(e) pedido de modificações.
27. (ICMS-SP 2009) A rastreabilidade ou a história das mudanças de cada software, incluindo quem fez o que, por que e quando, pode ser realizada no gerenciamento de configuração de software por meio do seu componente:27
(a) Acordo de nível de serviço.
(b) Configuração da construção.
(c) Identificação do item de software.
(d) Controle de versão.
(e) Controle de mudanças.
28. (ICMS-SP 2009) Os objetivos de controle detalhados do COBIT estão diretamente associados28
(a) aos domínios de governança.
(b) aos processos de TI.
(c) às atividades de TI.
(d) aos recursos de TI.
(e) aos critérios de informação.
29. (ICMS-SP 2009) O processo Gerenciamento de Configurações está definido no COBIT dentro do domínio 29
(a) Monitoração & Avaliação.
(b) Verificação & Controle.
(c) Aquisição & Implementação.
(d) Planejamento & Organização.
(e) Entrega & Suporte.x
30. (ICMS-SP 2009) NÃO se trata de um princípio de governança de TI: 30
(a) Responsabilidade corporativa.
(b) Objetivos do negócio.x
(c) Prestação de contas.
(d) Transparência.
(e) Equidade.
31. Gerenciar Projetos, segundo o COBIT, é um processo de TI pertencente ao domínio de 31
(a) Planejamento e Organização.
(b) Planejamento e Controle.
(c) Aquisição e Implementação.
(d) Entrega e Suporte.
(e) Monitoração e Controle.
32. (ICMS-SP 2009) No gerenciamento de serviços de TI, segundo o ITIL v.2, tem foco operacional o processo:32
(a) configuration management.
(b) capacity management.
(c) availability management.
(d) service level management.
(e) customer relationship management.
33. (ICMS-SP 2009) No gerenciamento de serviços de TI, segundo o ITIL v.2, tem foco tático ou estratégico o processo:33
(a) problem management.
(b) incident management.
(c) release management.
(d) continuity management.
(e) change management.
34. (ICMS-SP 2009) O processo de gerenciamento de serviços Service Desk, segundo o ITIL v.2, NÃO gerencia34
(a) os contatos entre o provedor de serviços e os usuários.
(b) a comunicação com os usuários.
(c) os incidentes nos serviços.
(d) os acordos de serviços.
(e) as requisições de serviços.
35. O processo de Gerenciamento de Problemas, segundo o ITIL, deve ser executado no estágio do ciclo de vida de serviços denominado 35
(a) estratégia de serviços.
(b) projeto de serviços.
(c) transição de serviços.
(d) operação de serviços.
(e) melhoria contínua de serviços.
4 Engenharia de Software
Engenharias da sistemas é um campo interdisciplinar da engenharia que foca no desenvolvimento e organização de sistemas artificiais complexos. As técnicas de Engenharia de Sistemas podem ser utilizadas em desenvolvimento de softwares.
Engenharia de produção é o ramo da engenharia que dedica-se à concepção, melhoria e implementação de sistemas que envolvem pessoas, materiais, informações, equipamentos, energia e maior de conhecimentos e habilidades, para especificar, prever e avaliar os resultados obtidos por tais sistemas.
A Engenharia de processos é um ramo da engenharia que se preocupa, entre outras coisas, em elaborar e executar projetos e estudos de formas de aproveitamento de mão-de-obra, máquinas e equipamentos, para melhorar processos, para o aumento da qualidade do produto, redução de perdas e maior produtividade.
Neste contexto, a engenharia de software aproveita diversas técnicas de engenharia de sistemas, de produto e de processos para a produção de aplicativos com maior eficiência e eficácia.
Nos anos 40, grande parte dos esforços e custos era concentrada no desenvolvimento do hardware.
À medida que a tecnologia de hardware foi sendo dominada, as preocupações se voltaram, no início dos anos 50, para o desenvolvimento dos sistemas operacionais e de linguagens de programação de alto nível, como FORTRAN e COBOL.
No início dos anos 60, com o surgimento dos sistemas operacionais com características de multiprogramação, a eficiência e utilidade dos sistemas computacionais tiveram um considerável crescimento, surgindo a necessidade de desenvolver grandes sistemas de software em substituição aos pequenos programas aplicativos utilizados até então.
Desta necessidade, surgiu um problema chamado de “crise do software”, que permitiu o nascimento do termo “Engenharia de Software”.
Atualmente, o custo de desenvolvimento de software corresponde a uma percentagem cada vez maior no custo global de um sistema informatizado.
A principal razão para isto é que a tecnologia de desenvolvimento de software implica em grande carga de trabalho, envolvendo muitas pessoas num prazo relativamente longo de desenvolvimento.
4.1 Software9
Software é um conjunto de instruções, estruturas de dados e documentação destinados a resolver um problema.
Em Engenharia de Software, o software deve ser visto como um produto a ser “vendido”.
Em sistemas simples, onde o usuário é o próprio autor, a documentação é pequena ou inexistente e a preocupação com a existência de erros de execução não é um fator muito relevante, pode não haver grandes dificuldades na detecção e correção de falhas, nem preocupação como a portabilidade, a flexibilidade e a possibilidade de reutilização.
Um produto de software é destinado ao uso por pessoas outras que os seus programadores, a sua interface é importante, reforçada com uma documentação rica em informações para que todos os recursos oferecidos possam ser explorados de forma eficiente.
Produtos de software devem passar normalmente por uma exaustiva bateria de testes, dado que os usuários não estarão de detectar e corrigir os eventuais erros de execução.
· o software é concebido e desenvolvido como resultado de um trabalho de engenharia e não manufaturado no sentido clássico;
· o software não se desgasta, não aumenta a possibilidade de falhas à medida que o tempo passa;
· a maioria dos produtos de software é concebida inteiramente sob medida, sem a utilização de componentes pré-existentes.
Em função destas características diferenciais, o processo de desenvolvimento de software pode desembocar um conjunto de problemas, os quais terão influência direta na qualidade do produto.
O processo de desenvolvimento de software procura responder:
9 http://jalvesnicacio.files.wordpress.com/2010/03/engenharia-de-software.pdf
· por que o software demora tanto para ser concluído?
· por que os custos de produção têm sido tão elevados?
· por que não é possível detectar todos os erros antes que o software seja entregue ao cliente?
· por que é tão difícil medir o progresso durante o processo de desenvolvimento de software?
4.2 Ciclo de vida do software
O ciclo de vida de um software descreve as fases pelas quais o software passa desde a sua concepção até ficar sem uso algum.10
Quatro fases que são delimitadas por eventos típicos em diversos ciclos de vida. Cada fase inclui um conjunto de atividades ou disciplinas que devem ser realizadas pelas partes envolvidas.
· Definição
· Desenvolvimento
· Operação
· Retirada
4.2.1 Fase de Definição
A fase de definição do software ocorre em conjunto com outras atividades como a modelagem de processos de negócios e análise de sistemas. Nesta atividade, diversos profissionais buscam o conhecimento da situação atual e a identificação de problemas para que possam elaborar propostas de soluçãode sistemas computacionais que resolvam tais problemas. Dentre as propostas apresentadas, deve-se fazer um estudo de viabilidade, incluindo análise custo-benefício, para se decidir qual solução será a escolhida.
O resultado desta atividade deve incluir a decisão da aquisição ou desenvolvimento do sistema, indicando informações sobre hardware, software, pessoal, procedimentos, informação e documentação.
Caso seja decidido pelo desenvolvimento do sistema, no escopo da engenharia de software, é necessário elaborar o documento de proposta de desenvolvimento de software. Esse documento pode ser a base de um contrato de desenvolvimento.
Profissionais de engenharia de software atuam nesta atividade com o objetivo de identificar os requisitos de software e modelos de domínio que serão utilizados na fase de desenvolvimento. Os requisitos são também fundamentais para que o engenheiro possa elaborar um plano de desenvolvimento de software, indicando em detalhes os recursos necessários (humanos e materiais), bem como as estimativas de prazos e custos (cronograma e orçamento).
Não existe um consenso sobre o que caracteriza o final da fase de definição. Isto varia de acordo com o modelo de processo adotado. Em algumas propostas, a fase de definição é considerada concluída com a apresentação da proposta de desenvolvimento apenas. Outros modelos de processo, considera que o software apenas está completamente definido com a especificação de requisitos e com a elaboração do plano de desenvolvimento de software.
De acordo com o modelo de processo adotado, pode-se iniciar atividades da fase de desenvolvimento mesmo que a fase de definição não esteja completamente concluída.
4.2.2 Fase de Desenvolvimento
A fase de desenvolvimento ou de produção do software inclui todas as atividades que tem por objetivo a construção do produto. Ela inclui principalmente o design, a implementação e a verificação e validação do software.
4.2.2.1 Design
A atividade de design compreende todo o esforço de concepção e modelagem que têm por objetivo descrever como o software será implementado. O design inclui:
· Design conceitual
· Design da interface de usuário
· Design da arquitetura do software
· Design dos algoritmos e estruturas de dados
10 http://engenhariadesoftware.blogspot.com/2007/02/ciclo-de-vida-do-software-parte-1.html
O design conceitual envolve a elaboração das idéias e conceitos básicos que determinam os elementos fundamentais do software em questão. Por exemplo, um software de correio eletrônico tradicional inclui os conceitos: mensagem, caixa de entrada, caixa de saída, etc. A mensagem, por sua vez, inclui os conceitos de para, cc, bcc, assunto, corpo, etc. Embora seja um design adotado pela maioria dos software, novos modelos conceituais podem vir a ser adotados. O conceito de conversação do Gmail é um exemplo.
O design conceitual exerce influência na interface de usuário e na arquitetura do software.
O design da interface de usuário envolve a elaboração da maneira como o usuário pode interagir para realizar suas tarefas, a escolha dos objetos de interfaces (botões, menus, caixas de texto, etc.), o layout de janelas e telas, etc. A interface deve garantir a boa usabilidade do software e é um fundamental fator de sucesso do software.
O design de arquitetura de software deve elaborar uma visão macroscópica do software em termos de componentes que interagem entre si. O conceito de componente em arquitetura varia de acordo com a visão arquitetônica adotada. São exemplos de visões arquitetônicas, a visão conceitual, visão de módulos, visão de código e visão de execução.
Na visão conceitual, os componentes de software são derivados do design conceitual. Estes componentes são abstrações que devem definir outros elementos menos abstratos. Exemplos são arquiteturas cliente-servidor e arquitetura em camadas. Na visão de código, deve-se determinar como as classes e/ou funções estão organizadas e interagindo entre si. Estas classes implementam os componentes abstratos ou conceituais. Na visão de módulos, deve-se determinar quais são os módulos que serão utilizados na implementação e como eles organizam as classes e/ou funções. Na visão de execução, a arquitetura deve descrever os diferentes processos que são ativados durante a execução do software e como eles interagem entre si. Enquanto as anteriores oferecem uma visão estática, esta é uma visão dinâmica do software.
O design de algoritmos e estrutura de dados, também conhecido como design detalhado, visa determinar, de maneira independente da linguagem de programação adotada, as soluções algorítmicas e as estruturas de dados associados. Deve-se decidir, por exemplo, como as informações podem ser ordenadas (algoritmo de bolha ou quicksort) e em qual tipo de estrutura de dados (array, lista encadeada) elas vão ser armazenados.
4.2.2.2 Implementação
A implementação envolve as atividades de codificação, compilação, integração e testes. A codificação visa traduzir o design num programa, utilizando linguagens e ferramentas adequadas. A codificação deve refletir a estrutura e o comportamento descrito no design. Os componentes arquiteturais devem ser codificados de forma independente e depois integrados. Os testes podem ser iniciados durante a fase de implementação. A depuração de erros ocorre durante a programação utilizando algumas técnicas e ferramentas. É fundamental um controle e gerenciamento de versões para que se tenha um controle correto de tudo o que está sendo codificado.
4.2.2.3 Verificação e validação
Verificação e validação destinam-se a mostrar que o sistema está de acordo com a especificação e que ele atende às expectativas de clientes e usuários. A validação visa assegurar se o programa está fazendo aquilo que foi definido na sua especificação (fazendo a coisa certa). A verificação visa verificar se o programa está correto, isto é, não possui erros de execução (fazendo certo a coisa). Existem diferentes formas de verificação e validação. Inspeção analítica e revisão de modelos, documentos e código fonte são formas que podem ser usadas antes mesmo que o programa seja completamente codificado. Os testes de correção, desempenho, confiabilidade, robustez, usabilidade, dentre outros, visam avaliar diversos fatores de qualidade a partir da execução do software. Diferentes técnicas de testes podem ser aplicadas para cada um destes fatores.
4.2.3 Fase de Operação
A fase de operação envolve diferentes tipos de atividades:
· Distribuição e entrega
· Instalação e configuração
· Utilização
· Manutenção
A distribuição e entrega pode ser feita diretamente pelo desenvolvedor (em caso de software personalizado), ou em um pacote a ser vendido em prateleiras de lojas ou para ser baixado pela Internet (em caso de software genéricos).
O processo de instalação e configuração, normalmente, pode ser feito com a ajuda de software de instalação disponibilizados pelos fabricantes dos ambientes operacionais.
A atividade de utilização é o objeto do desenvolvimento do software. A qualidade da utilização é a usabilidade do software.
A manutenção normalmente ocorre de duas formas: corretiva e evolutiva. A manutenção corretiva visa a resolução de problemas referentes a qualidade do software (falhas, baixo desempenho, baixa usabilidade, falta de confiabilidade etc.). A manutenção evolutiva ou adaptativa visa a produção de novas versões do software de forma a atender a novos requisitos dos clientes, ou adaptar-se às novas tecnologias que surgem (hardware, plataformas operacionais, linguagens, etc). Mudanças no domínio de aplicação implicam em novos requisitos e incorporação de novas funcionalidades. Surgimento de novas tecnologias de software e hardware e mudanças para uma plataforma mais avançada também requerem evolução.
4.2.4 Fase de retirada
A fase retirada é um grande desafio para os tempos atuais. Diversos software que estão em funcionamento em empresas possuem excelente níveis de confiabilidade e de correção. No entanto, eles precisam evoluir para novas plataformas operacionais ou paraa incorporação de novos requisitos. A retirada desses software legados em uma empresa é sempre uma decisão difícil: como abrir mão daquilo que é confiável e ao qual os funcionários estão acostumados, após anos de treinamento e utilização?
Processos de reengenharia podem ser aplicados para viabilizar a transição ou migração de um software legado para um novo software de forma a proporcionar uma retirada mais suave.
4.3 Metodologias de desenvolvimento de software.
4.3.1 Modelo caótico11
O produto é construído sem qualquer especificação ou projeto. O produto é retrabalhado quantas vezes forem necessárias para satisfazer o cliente. Este modelo pode funcionar razoavelmente para micro projetos (até 400 homens.hora). No entanto para projetos maiores ele é inadequado.
4.3.2 Modelo Cascata
Recomendado para sistemas onde a segurança e a confiabilidade tem grande importância.
Orientado para documentação, que abrange representações gráficas e simulações, e com uma abordagem disciplinada, a cada fase são feitos procedimentos de verificação e validação (incluindo testes), são liberadas definições da documentação e todos produtos são formalmente revisados.
Uma vez definido o modelo de ciclo de desenvolvimento, existem três abordagens para implementá-lo
· Cascata Pura
· Incremental
· Evolucionária
4.3.2.1 Abordagem Cascata Pura
Todas as fases do ciclo de desenvolvimento são executadas em sequência. As fases anteriores são revisitadas para correções de erros ou para adaptações. Esta abordagem é adequada quando :
· existe um conjunto de Requisitos do Usuário estáveis e de alta qualidade
· a duração do projeto é pequena
· o sistema completo deve estar disponível de um única vez
 (
TI para concursos
)
 (
TI para concursos
)
 (
11 
http://www2.dem.inpe.br/ijar/CicoloVidaSoftPrado.htm
l
36
)
 (
37
)
4.3.2.2 Abordagem Incremental
Nesta abordagem o desenvolvedor executa múltiplas fases de PD, TR e OM. Dentro desta abordagem está a abordagem cascata.
A abordagem incremental é adequada quando:
· a liberação do software deve estar de acordo com um conjunto de prioridades definidas nos Requisitos do Usuário
· é necessário melhorar a eficiência da integração do software com outra partes de um sistema maior
· são requeridas antecipadamente evidências de que o produto será aceito
· RU – Requisitos do usuário
· RS – Requisitos do software
· PA – Projeto da arquitetura
· PD – Projeto detalhado
· TR – Treinamento
· OM – Operação e Manutenção
4.3.2.3 Abordagem Evolucionária
Nesta abordagem, o desenvolvimento é formado por múltiplos ciclos da abordagem cascata pura, ocorrendo sobreposição das fases da operação e manutenção do sistema anterior com o novo desenvolvimento. Esta abordagem é adequada quando:
· é necessário alguma experiência do usuário para refinar e completar requisitos
· algumas partes da implementação podem depender da existência de tecnologia ainda não disponível
· existem requisitos do usuário não bem conhecidos
· alguns requisitos são muito mais difíceis de serem implementados do que outros, decidindo-se não implementá-lo para não atrasar o projeto
4.3.2.4 Modelo Espiral
Modelo em cascata onde cada fase é precedida por uma análise de risco e sua execução é feita evolucionariamente (ou incrementalmente).
A dimensão radial representa o custo acumulado atualizado e a dimensão angular representa o progresso através da espiral. Cada setor da espiral corresponde a uma tarefa (fase)do desenvolvimento.
Um ciclo se inicia com a tarefa "Determinação de objetivos, alternativas e restrições", onde ocorre o comprometimento dos envolvidos e o estabelecimento de uma estratégia para alcançar os objetivos.
Na tarefa "Avaliação de alternativas, identificação e
solução de riscos", executa-se uma análise de risco. Prototipação é uma boa ferramenta para tratar riscos. Se o risco for considerado inaceitável, pode parar o projeto.
Na terceira tarefa ocorre o desenvolvimento do produto. Neste quadrante pode-se considerar o modelo cascata.
Na quarta tarefa o produto é avaliado e se prepara para iniciar um novo ciclo.
Variações do modelo espiral consideram entre três e seis tarefas ou setores da espiral. Por exemplo, as regiões:
· comunicação com o cliente
· planejamento
· análise de risco
· engenharia
· construção e liberação
· avaliação do cliente
4.4 Desenvolvimento ágil12
Desenvolvimento ágil de software (do inglês Agile software development) ou Método ágil é um conjunto de metodologias de desenvolvimento de software. O desenvolvimento ágil, tal como qualquer metodologia de software, providencia uma estrutura conceitual para reger projetos de engenharia de software.
Existem inúmeros frameworks de processos para desenvolvimento de software. A maioria dos métodos ágeis tenta minimizar o risco pelo desenvolvimento do software em curtos períodos, chamados de iteração, os quais gastam tipicamente menos de uma semana a até quatro. Cada iteração é como um projecto de software em miniatura de seu próprio, e inclui todas as tarefas necessárias para implantar o mini-incremento da nova funcionalidade: planejamento, análise de requisitos, projeto, codificação, teste e documentação. Enquanto em um processo convencional, cada iteração não está necessariamente focada em adicionar um novo conjunto significativo de funcionalidades, um projecto de software ágil busca a capacidade de implantar uma nova versão do software ao fim de cada iteração, etapa a qual a equipe responsável reavalia as prioridades do projecto.
Métodos ágeis enfatizam comunicações em tempo real, preferencialmente face a face, a documentos escritos. A maioria dos componentes de um grupo ágil deve estar agrupada em uma sala. Isso inclui todas as pessoas necessárias para terminar o software: no mínimo, os programadores e seus clientes (clientes são as pessoas que definem o produto, eles podem ser os gerentes, analistas de negócio, ou realmente os clientes). Nesta sala devem também se encontrar os testadores, projectistas de iteração, redactores técnicos e gerentes.
Métodos ágeis também enfatizam trabalho no software como uma medida primária de progresso. Combinado com a comunicação face-a-face, métodos ágeis produzem pouca documentação em relação a outros métodos, sendo este um dos pontos que podem ser considerados negativos. É recomendada a produção de documentação que realmente será útil.
Os princípios do desenvolvimento ágil valorizam:
· Garantir a satisfação do consumidor entregando rapidamente e continuamente softwares funcionais;
· Softwares funcionais são entregues frequentemente (semanas, ao invés de meses);
· Softwares funcionais são a principal medida de progresso do projecto;
· Até mesmo mudanças tardias de escopo no projecto são bem-vindas.
· Cooperação constante entre pessoas que entendem do negócio e desenvolvedores;
· Projetos surgem através de indivíduos motivados, entre os quais existe relação de confiança.
· Design do software deve prezar pela excelência técnica;
· Simplicidade;
· Rápida adaptação às mudanças;
· Indivíduos e interações mais do que processos e ferramentas;
· Software funcional mais do que documentação extensa;
· Colaboração com clientes mais do que negociação de contratos;
· Responder a mudanças mais do que seguir um plano.
A maioria dos métodos ágeis compartilha a ênfase no Desenvolvimento iterativo e incremental para a construção de versões implantadas do software em curtos períodos de tempo. Métodos ágeis diferem dos métodos iterativos porque seus períodos de tempo são medidos em semanas, ao invés de meses, e a realização é efetuada de uma maneira altamente colaborativa. estendendo-se a tudo.
Algumas equipes ágeis usam o modelo em cascata em pequena escala, repetindo o ciclo de cascata inteiro em cada iteração. Outras equipes, mais especificamente as equipes de Programação extrema, trabalham com atividades simultaneamente.
 (
TI para concursos
)
 (
TI para concursos
)
 (
12 
http://pt.wikipedia.org/wiki/Desenvolvimento_Ágil_de_software
38
)
 (
39
)
A codificação cowboy, também chamada de Modelo Balbúrdia, é a ausência de metodologias