quinta-feira, 31 de maio de 2012

Engenharia de Requisitos para Concursos Parte 2 - Tipos de Requisitos

Tipos de Requisitos

Funcionais: Definem as funcionalidades do sistema. São as capacidades e serviços providos pelo sistema.

Não Funcionais: São as restrições aplicadas ao sistema ou qualidades específicas que o software deve ter. Exemplos: tempo de resposta máximo, quantidade de armezenamento e outras coisas.

De Domínio (coisa do Sommerville): Vêm do domínio (area de negócio) da aplicação do sistema e refletem características específicas do domínio. Algo mais relacionado ao domínio do que ao sistema. Depois são derivados em requisitos funcionais ou não funcionais.

Outros Tipos de Requisitos - Ponto de vista da evolução e manutenção. Visa saber quais requisitos são mais estáveis e quais são instáveis. Todos são modificáveis, mas alguns são mais propensos a mudanças do que outros

Requisitos Permanentes - Estáveis - (enduring): Estão diretamente ligados a atividade principal da organização. É pouco provável que sejam modificados por causa disso. São derivados do Modelo de Domínio. 

Requisitos Voláteis (volatile): São mais propensos a mudança. Se modificam quando o sistema está em desenvolvimento ou em uso. Requisitos resultantes de políticas governamentais fazem parte desse conjunto.

Os requisitos voláteis são divididos em 4 tipos:

Requisitos Mutáveis: se modificam por causa do ambiente do sistema. Ambiente onde o sistema está inserido. Sistemas que cuidam de impostos estão muito sujeitos a essas modificações.

Requisitos Emergentes: surgem à medida que a compreensão do cliente sobre o sistema se desenvolve. Só aparecerão durante o desenvolvimento.

Requisitos Consequentes: são resultado da introdução do sistema no ambiente do usuário. O usuário percebe a necessidade enquanto utiliza o sistema e esses requisitos são uma consequência do uso.

Requisitos de Compatibilidade: dependem de algum outro elemento. Equipamento, processo, componente, etc. Conforme outros elementos mudam, esses requisitos também mudam.

Requisitos Funcionais
Descrevem as funcionalidades ou serviços do sistema. Dependem da área de interesse relacionada ao software (domínio), dependem dos usuário e do tipo de software. Declaram as funções que o sistema deve fazer, seu comportamento, e ainda, o que o sistema NÃO deve fazer.

Podem ser escritos em alto nível, voltado para o cliente, ou podem ser especificados em detalhes para os desenvoldores.

Exemplos: o sistema deve permitir cadastros, gerar relatórios gerenciais, deve executar tarefas agendadas, etc. Tudo o que não é qualidade, atributo ou restrição do sistema, é considerado requisito funcional.

Requisitos Não Funcionais (RNF)
Definem propriedades, atributos, restrições e qualidades do software. E aí podemos colocar questões como usabilidade, confiabilidade, desempenho, manutenibilidade, escalabilidade, portabilidade. Exemplo: o sistema precisa ser fácil de usar, precisa se manter no ar por um tempo x, precisa ter tempo de resposta máximo e etc.

Segundo o Sommerville, os requisitos não funcionais NÃO se limitam a requisitos do produto, mas do sistema como um todo. Para este autor, o próprio processo, a linguagem de programação escolhida, ferramentas case e etc, também são considerados como RNF

Esses requisitos normalmente são mais críticos e adicionam mais complexidade do que os funcionais. Na grande maioria dos sistemas é assim, não é sempre. Acontece isso porque eles afetam diretamente a sensação de qualidade do usuário ao utilizar o sistema. O sistema é rápido? Está sempre disponível? Consegue suportar milhões de acessos ao mesmo tempo?

Tipos de Requisitos Não Funcionais

Requisitos de Produto: especificam que o software deve se comportar de determinada forma: confiável, robusto, rápido e coisas do tipo.

Requisitos organizacionais: são consequências das politicas, prodecimentos, processos, padrões adotados pela empresa que afetam o seu sistema.

Requisitos Externos: requisitos externos ao sistema, à organização e ao desenvolvimento. Leis e regulamentos do país por exemplo. A interoperabilidade, que é a capacidade de um sistema de se comunicar com outro sistema também é um exemplo.

Os requisitos não funcionais podem ser muito difíceis de especificar de forma precisa. Eles podem ser vagos, ambíguos, ou impossíveis de se verificar. Exemplo: o sistema deve ser fácil de usar.

RNF precisam ser VERIFICÁVEIS e mensuráveis. Deve existir alguma forma de medir objetivamente.

Muitas vezes os RNFs são conflitantes entre sí. Uma escolha de ter mais qualidade em uma determinada coisa pode significar menos de outra coisa. Exemplo: Sistemas em Java possuem portabilidade, por outro lado, costumam ser mais lentos. Interfaces muito elaboradas podem reduzir a manutenibilidade do sistema e por aí vai.

Formas de Medir um RNF

Propriedade Medida
Desempenho Transações por segundo; tempo de resposta para eventos, etc
Armazenamento  Megabytes armazenados.
Usabilidade Tempo de treinamento, número de cliques de mouse para executar uma função
Confiabilidade Tempo médio entre falhas, Taxa de ocorrência de falhas, Disponibilidade
Robustez Tempo para recomeçar depois de uma falha, Probabilidade de corrupção de dados em uma falha
Portabilidade Porcentagem de declarações dependentes de platarforma; Número de platarformas-alvo

Requisitos de Domínio
São derivados do domínio da aplicação. Descrevem características e funcionalidades do sistema que são reflexo do domínio envolvido. No final das contas deriavam para requisitos funcionais ou não funcionais. Na verdade, não serve para nada, mas o Sommerville classifica assim.

É algo extremamente específico daquele domínio. Detalhes técnicos da área que está sendo tratada.

Se não forem satisfeitos, podem inviabilizar o funcionamento do sistema ou sacrificar a qualidade. Bem óbvio, já que são funcionais ou não funcionais.

Eles são expressados na linguagem do domínio da aplicação, o que dificulta muito o entendimento do requisito. Imagine um sistema da bolsa de valores. Não é fácil especificar requisitos de domínios complexos. Muitas informações são táticas e não explíticas. Os especialistas da área acham aquilo tão óbvio que não comentam determinados requisitos.

Engenharia de Requisitos para Concursos - Parte 1

Bom galera, esse é mais um resumo que eu faço para os meus estudos. Esses também são baseados nas aulas do Pedrosa. Só lembrando que esses são os meus resumos. Usem como quiser, mas não me culpem por informações imprecisas.

Engenharia de Requisitos é a área da Engenharia de Software preocupada com os objetivos do mundo real para sistemas de software. É uma disciplina muito próxima do mundo real ou natural, próxima das necessidades do cliente. Também se preocupa com as funcões de sistemas de softwares (requisitos funcionais) e restrições em sistemas de software (não funcionais)

"Engenharia de Requisitos é o processo de descobrir, analisar, documentar e verificar as funções e restrições do sistema."

O objetivo final é gerar especificações precisas do comportamento do software e de sua evolução.

Os requisitos devem gerar uma concordância entre os clientes e a equipe de desenvolvimento, estabelecer o combinado, um entendimento sobre o que vai ser feito. Além disso, esses requisitos devem fornecer aos desenvolvedores uma compreensão melhor das funcionalidades do sistema a ser desenvolvido.

Por servirem como um entendimento sobre o que será feito, eles também informam, por exclusão, o que não será feito, então delimitam o escopo do sistema. Tudo o que está dentro do Modelo de Casos de Uso pode ser considerado como escopo do produto. Casos de Uso é a forma mais comum de especificação de requisitos, mas é pouco usado em metodologias ágeis.

Os requisitos fornencem a base para o planejamento das iterações, para estimar o custo e o tempo de desenvolvimento do sistema.

Definem uma interface para o sistema de acordo com as necessidades dos usuários. Os casos de uso sozinhos podem deixar dúvidas na cabeça dos usuários. Os protótipos de interface ajudam a clarear os requisitos. Isso gera requisitos de melhor qualidade.

Os documentos de requisitos precisam ser completos (todas as funcionalidades), consistentes, sem ambiguidades e corretos, com as reais necessidades do cliente. Normalmente os requisitos não são corretos porque o analista não consegue entender as necessidades do cliente.


A primeira caixa da figura mostra o Estudo de Viabilidade e como já estamos na especificação requisitos, o sistema já teria sido considerado viável.

A segunda estapa é a Elicitação e Análise de Requisitos. É onde se descobre os requisitos. A etapa mais imporante.

A terceira etapa é a Especificação de Requisitos, pega-se o que foi descoberto na Elicitação e é criada uma especificação formal e padronizada.

A quarta etapa é a Validação de Requisitos. É onde se verifica se os requisitos atendem as reais necessidades do cliente. Os clientes assinam a especificação e assim dão o aceite para a versão final do documento.

A figura tem o foco na geração dos requisitos. Depois ainda existe a etapa de Gestão de Requisitos que foca em gerenciar os requisitos depois que eles são gerados. Cuida da evolução desses requisitos.

Na prática, o processo de engenharia de requisitos é iterativo, pode haver sobreposição de atividades e o Sommerville fala isso. Reparem que as setas vão e voltam de uma etapa para outra.

"Requisito é uma condição ou uma capacidade com a qual o sistema deve estar de acordo." ou "Uma condição ou uma funcionalidade necessária a um usuário para resolver um problema."

Pode ser algo abstrato ou uma especificação matemática detalhada. Tudo depende do grau de detalhe dos requisitos, depende do seu público alvo.


Requisitos definem o que o sistema deve fazer e sob quais limitações deve operar.



O Sommerville define requisitos de 3 níveis:
Requisitos de Usuário: em linguagem natural e escrito para clientes leigos.
Requisitos de Sistema: são documentados formalmente, já para a equipe de desenvolvimento
Especificação do Software: Um terceiro nível que é a própria especificação do software, algo bastante detalhado, bem próximo no nível computacional. (isso precisa ser melhor estudado por mim)

Os stakeholders ou partes interessadas são as pessoas que podem ter interesse nos requisitos do sistema por algum motivo. Entre eles podemos citar os engenheiros de software do sistema, os usuários finais que irão usar o sistema, os gerentes da empresa, os especialista no domínio da organização em que o software será implementado e até mesmo fiscais externos para ver se o sistema satisfaz os requisitos legais.

Problemas com Requisitos

Os requisitos apresentam problemas e dificuldades para serem tratados. Eles podem vir de várias fontes diferentes e com interesses diferentes, então, é preciso compatibilizar esses interesses. Um erro comum é o requisito não refletir as necessidades reais dos usuários. É comum a fonte consultada não conhecer a nessecidade real do usuário. Essa fonte pode ser um cliente, mas não é será um usuário do software. Além disso, o analista pode entender as coisas de forma errada.

Outro problema é o requisito inconsistente ou incompleto. As vezes um requisito contraria outro requisito ou alguém esquece de colocar determinado requisito na especificação.

Poder ser muito caro alterar um requisito depois de longo tempo de execução do projeto. Quanto mais tempo um requisito permanece errado, mas caro será o seu reparo quando o erro for detectado e corrigido. Um erro corrigido durante a ênfase na condificação pode custar até 5 vezes mais. Se o produto já estiver em produção pode custar até 20 vezes mais.



Mal entendido entre clientes e analistas podem gerar erros de interpretação dos requisitos. O sucesso das etapas posteriores do seu software vai depender da qualidade dos requisitos gerados.




domingo, 27 de maio de 2012

RUP para Concursos Parte 4 - Fase de Iniciação e Disciplinas Modelagem de Negócio e Requisitos

As disciplinas do RUP podem ser executadas em qualquer uma das fases. A única exceção é a disciplina de implantação (deployment) que não é executada na fase de iniciação (inception).


Fase de Iniciação ou Concepção
Na fase de iniciação, a ênfase é nas disciplinas de Modelagem de Negócios e Requisitos que estão relalcionadas com definição de escopo, levantamento das necessidades e entendimento dos processos de negócio da organização. Os objetivos dessa fase e dessas disciplinas são semelhantes.

A maioria do esforço é feito na disciplina de Requisitos, mas na Iniciação você já pensa na sua arquitetura candidata para fazer uma análise de viabilidade e provas de conceito. Por isso, alguma coisa já será codificada e testada também.

A meta principal é atingir o consenso sobre os objetivos do ciclo de vida do projeto. Todos os interessados precisam chegar em um consenso. É uma fase muito importante para projetos novos, onde os riscos são desconhecidos. É preciso fazer análise de viabilidade, mapeamento de escopo e objetivos. Para Ciclos de Evolução, pode ser uma fase mais rápida e até mesmo uma fase opcional, caso a evolução seja simples.

Nessa fase você determina se continuar com o projeto compensa ou não. A análise de viabilidade não trata apenas de código, mas é preciso verificar se o projeto é financeiramente viável. Também é preciso fazer um estudo de viabilidade técnica. Quais tecnologias e arquiteturas devem ser usadas? É possível fazer o projeto nessas tecnologias?

Essas perguntas precisam ser respondidas para que a gerência possa determinar se vale a pena ou não executar o projeto.

Objetivos da Fase de Iniciação

Estabelecer o escopo do software: qual é o escopo do meu produto? Que requisitos considerar e quais deixar de fora? É determinado com o levantamento dos casos de uso.

Estimar custos: quanto vai custar o software? Isso é uma estimativa inicial. A cada iteração o custo é ajustado.

Estimar tempo : estimativa inicial de tempo. Também é ajustada a cada iteração.

Estimar riscos: identificar os casos de uso arquiteturalmente significativos (os mais críticos, complexos, arriscados e nebulosos) e principais cenários de operação do sistema.

Propor pelo menos uma opção de arquitetura para alguns cenários básicos.

Principais Artefatos da Fase de Iniciação

Documento de Visão (disciplina de Requisitos): descreve as necessidades e características mais importantes do sistema. Não é um artefato de engenharia de software. É um documento de alto nível que dá uma visão geral do sistema para o patrocinador do projeto, para servir como base para um contrato. Não possui informações técnicas ou arquiteturais. Também pode conter uma especificação de requisitos formal. Fornece informações para o processo de aprovação do projeto e, portanto, está intrinsecamente relacionado ao Caso de Negócio.

Caso de Negócio (disciplina de Gerenciamento de Projetos)
É um documento com informações do ponto de vista do negócio para determinar se vale a pena investir no projeto sobre o ponto de vista do retorno de investimento (ROI). Mostra a estimativa de custos. É este documento que vai basear a decisão do patrocinador de continuar ou não com o projeto.

Plano de Desenvolvimento do Software (disciplina de Gerenciamento de Projetos)
É como o Plano de Projeto do PMBOK e reúne as informações necessárias para o gerenciamento do projeto durante todo o ciclo do desenvolvimento.

Modelo de Caso de Uso
Descreve os requisitos funcionais de um sistema em termos de Casos de Uso e atores que interagem com os casos de uso. Determina o escopo do sistema. Contém as funções pretendidas para o sistema e serve como um contrato estabelecido entre os clientes e os desenvolvedores. O Modelo de Casos de Uso mapeia os casos de uso que existem e determina o escopo, logo, o que não está neste modelo, não deve ser feito.

O modelo de casos de uso é usado como fonte de informações essencial para atividades de análise, design e teste.

Glossário
Conjunto consistente de definições para evitar mal entendidos. Define termos importantes usados pelo projeto. Em muitos domínios, os termos não são simples e é preciso garantir que toda a equipe tenha o mesmo entendimento sobre os itens.

Disciplina Modelagem de Negócio
Entender a estrutura e a dinâmica da organização cliente ou organização-alvo, identificando oportunidades de melhoria. Trata de aspectos anteriores ao software. Antes de automatizar os processos da organização, é preciso entender o problema da organização. Sem isso, corre-se o risco de implementar um software que não resolve os problemas da empresa e não agrega valor nenhum.

Assegurar que todos os interessados tenham um entendimento comum sobre a organização.

Principais Papéis e Atividades:

Papel - Analista de Processo de Negócios
Identifica os processos na organização-alvo e descreve estes processos para entender como a organização trabalha. Depois define o que pode e deve ser melhorado. Em seguida propõe redesenho dos processos se for necessário. Ele está entendendo os processos de Negócio, não existe nada de software aqui.

Artefato Importante

Modelo de Domínio  (modelo de objetos de negócio)
Lembrando que um modelo é um agrupamento de artefatos. Inclui diagramas, especificações, entidades e etc.

É um modelo conceitual e mosta  os tipos de objetos mais importantes para o domínio. Como é um artefado da Modelagem de Negócio, que é anterior ao software, não mostra entidades do software, apenas entidades do mundo real, do negócio.

A figura acima mostra um diagrama de classes. Essas ainda são classes conceituais de entidade e controle.

Relação com outras Disciplinas

Requisitos
Utiliza o Modelo de Negócio como informação fundamental para entender os requisitos de sistema. Ou seja, os requisitos de sistema são derivados dos requisitos de negócio.

Análise e Design
Utiliza as entidades de negócio para identificar classes de entidade no projeto, que são as classes que representam a informação a ser armazenada.

Ambiente
Desenvolve e mantém artefatos de suporte como o Guia de Modelagem de Negócios, que é um padrão que mostra como executar as atividades de modelagem de negócio na organização.

Abmiente é uma disciplina que se relaciona com todas as disciplinas do RUP. É ela quem configura o RUP, estabelece guias, padrões e seleciona as ferramentas a serem utilizadas. Normalmente configura guias e padrões para as outras disciplinas.

Disciplina Requisitos
É uma das disciplinas mais importantes porque estrutura os casos de uso e o RUP é orientado a casos de uso. Estabelece o que o sistema deve fazer e define as fronteiras (escopo) do sistema, que são as funcionalidades descritas nos casos de uso.

Fornece uma base para planejar o conteúdo técnico das iteração e para estimar o custo e o tempo do desenvolvimento do sistema. Tudo isso baseado nos casos de uso.

Principais Papéis, Atividades e Artefatos:
Papel - Analista de Sistemas
É um dos papeis mais importante do RUP. Levanta os requisitos do sistema (Atores e CDU´s). Estrutura o Modelo de Casos de Uso e diagramas de casos de uso.

Papel - Especificador de Casos de Uso
O especificador é quem detalha a especificação dos casos de uso que foram elvantados pelo analista. Faz o passo a passo, detalha os fluxos e etc.

Artefatos Importante para o Marco

Glossário - Explicado acima

Modelo de Casos de Uso
Modelo das funções que são pretendidas pelo sistema. Serve como contrato entre o cliente e os desenvolvedores. Os requisitos funcionais do sistema são dispostos aqui agrupados em diagramas de casos de uso. Além disso, contém também as especificação dos casos de uso. Os requisitos não funcionais ficam em um artefato chamado Especificações Suplementares, também da disciplina de requisitos.

Documento de Visão - Explicado acima
Contém as necessidades e características mais importantes do sistema. Fornece uma base de alto nível para que o leitor possa compreender o sistema a ser desenvolvido. Não possui detalhes técnicos.

Relação com outras Disciplinas

Modelagem de Negócios
A Modelagem de Negócios fornece a entrada para a disciplina de Requisitos. Fornece as regras de negócio e um contexto organizacional para que os casos de uso sejam especificados.

Análise e Design
Usa a saída da disciplina de Requisitos como informações primárias dos requisitos para realizar os Casos de Uso. Mostra como os casos de uso se comunicam e se comportam. Pode encontrar falhas dos casos de uso.

Teste
Os Casos de Teste são gerados a partir dos casos de uso. Portanto, a saída dos requisitos é usada como entrada para validação do sistema. O que gera os objetivos do esforço de teste.

Gerenciamento de Configuração e Mudanças
Fornece o mecanismo de controle para as mudanças nos requisitos e isso se repete nas outras disciplinas. É basicamente o controle de versão dos artefatos.

Gerenciamento de Projeto
Usa o Modelo de Casos de Uso para planejar as iterações. É o Plano de Iteração.

Ambiente
Desenvolve e mantém artefatos utilizados nessa disciplina. É a mesma coisa para as outras disciplinas.

Marco da Fase de Iniciação: Objetivos do Ciclo de Vida
Marco é um resultado a ser alcançado. Um estado em que se encontra o projeto e onde alguns critérios precisam ser satisfeitos. São os critérios de avaliação da fase. É preciso responder sim a essas perguntas que estabelecem os critérios de avaliação.

Os casos de uso definem claramente o escopo? Que é o grande objetivo da fase de iniciação.

Caso necessário, foi possível fazer um protótipo da aquitetura? Se não foi possível, seu sistema pode não ser viável.

Todos os riscos foram encontrados? Se sim, foram mitigados? Os riscos precisam ser encontrados e deve existir um plano para tratar os casos de uso mais complicados.

Existe condição de se fazer o projeto? Todos os interessados, os técnicos, gerentes e usuários, precisam concluir que é possível fazer o projeto.

quinta-feira, 24 de maio de 2012

RUP para Concursos - Parte 3 - As 6 Melhores Práticas do RUP


Desenvolvimento Iterativo
É uma estratégia de resolução de problemas. Percorre-se várias vezes as disciplinas de engenharia durante o ciclo de vida do projeto. Cada iteração é uma passada pelas disciplinas e a cada uma delas a equipe aprende e ganha compreensão a respeito do projeto, dos requisitos e dos componentes. A arquitetura se torna mais robusta a cada incremento. É uma maneira mais flexível de desenvolvimento e impede que o risco seja acumulado para o final do projeto. O risco diminui com o tempo porque é percebido, avaliado e mitigado a cada iteração.

Lida com mudanças com mais facilidade. A cada incremento existe a chance de se verificar as mudanças nos requisitos e é possível se adaptar e replanejar o projeto. O replanejamento acontece a cada iteração.

Diminui os riscos porque são avaliados mais cedo. A cada iteração é possível integrar o código, verificar as interfaces e os usuário também poderão avaliar o que foi produzido para dizer se o caminho está correto.

Melhora a qualidade do software e a equipe aprende e melhora porque a cada iteração os usuários avaliam o que foi feito, passam o feedback e é possível corrigir os rumos do projeto. O conhecimento do negócio aumenta de forma mais precisa a cada interação com os usuários.

Aumenta o reuso porque é mais fácil pensar em reutilizar um componente que já está parcialmente ou totalmente implementado do que pensar em todos os componentes de forma antecipada. É quase impossível prever estes componentes apenas com os casos de uso especificados.

As iterações incorporam um conjunto quase sequencial das atividades. Só não é sequencial de fato porque algumas disciplinas podem não ser executadas em determinada fase.

Gerenciamento de Requisitos
Requisitos mal especificados, mal compreendidos e mal documentados geram problemas para TODO o projeto. Requisito é a necessidade e o propósito do seu cliente. É uma condição ou restrição com a qual o sistema deverá estar em conformidade. Não adianta implementar um requisito errado da melhor forma do mundo, porque isso não atende às necessidades do cliente. A forma como o requisito é entendido nem sempre é o que o cliente precisa e deseja.

Normalmente os requisitos se resumem a funcionais e não funcionais.

O RUP diz que o documento de requisitos deve ser feito de maneira clara. E o Gerenciamento de requisitos é uma abordagem sistemática para localizar, documentar, organizar e controlar os requisitos variáveis em um sistema. Além disso é preciso manter a integridade dos requisitos através da rastreabilidade.

Os requisitos possuem vários problemas: nem sempre são claros e podem vir de várias fontes diferentes. Cada fonte tem a sua visão e a sua prioridade. Duas fontes diferentes podem ter visões conflitantes. Além disso, existe uma interdependência entre requisitos diversos e os documentos devem tratar isso de forma consistente.

Cada requisito é diferente. A complexidade muda e a importância também. Alguns são simples e pouco importantes e outros podem trazer problemas para todo o projeto. É preciso identificar essa complexidade e tratá-los no momento certo do ciclo de vida do projeto.

Existem várias partes interessadas e pode haver conflito de interesses entre as essas partes. Além disso, o número de requisitos pode se tornar tão grande que fica impossível gerenciá-los.

Os requisitos são alterados a todo tempo.
Mudanças de requisitos identificadas tardiamente são as principais causas de insucesso nos projetos de desenvolvimento de software.

Como gerenciar essas dificuldades? Analisando o problema.
Entenda o "problema por trás do problema".
Estabeleça um vocabulário comum (UML e Glossário).
Proponha soluções em alto nível: nível de análise e não em nível de projeto.

Entenda a necessidade das partes interessadas e evite o desenvolvimento customizado
Todos querem algo. Determine qual é a melhor fonte dos requisitos, a fonte que realmente agrega valor. Utilize técnicas de elicitação de requisitos. Faça acordos, balancie prioridades, ou seja, negocie com as partes interessadas para saber o que é crítico, o que é importante, o que é desejável e dispensável. Alguns requisitos são fundamentais para entrada em produção. Outros não.

Defina o sistema.
Defina o que o sistema deve fazer, em termos gerais, utilizando linguagem natural e linguagem gráfica (UML).

Gerencie  o escopo do sistema
Tudo o que está no Modelo de Casos de Uso faz parte do escopo do sistema. O que está dentro? e fora? Estabeleça as prioridades para selecionar o que entra e o que sai.

Gerencie os requisitos variáveis
Garanta que os requisitos tenham uma estrutura que os tornem facilmente atualizáveis (utilize referências em seus documentos de casos de uso). Rastreie as mudanças em seus requisitos. Toda vez que uma mudança afetar um requisito ela deve ser analisada, o impacto e os riscos devem ser considerados e só poderá ser executada se aprovada após a análise. Mudanças sem análise não devem ser implementadas.

Os Casos de Uso guiam o desenvolvimento
O RUP recomenda a utilização de Casos de Uso como método para a organização dos requisitos funcionais. Assim você consegue organizar uma visão de como o usuário enxerga o sistema.

Os casos de uso definem um conjunto de cenários e cada cenário descreve o comportamento do sistema em uma sequência de ações. Esses cenários devem produzir um resultado de sucesso ou de erro de valor observável para um ator.

Atores são entidades externas que se relacionam com o seu sistema. Podem ser pessoas, outros sistemas e etc.

Quem utiliza os casos de uso? Os clientes utilizam para compreenção do comportamente do sistema e para aprovação do funcionamento antes da implementação. Os arquitetos analisam os casos de uso para definir a arquitetura do sistema logo na fase de elaboração. Os analistas, projetistas e programadores para entender o comportamento do sistema, refinar e implementar. Os casos de testes também são gerados a partir dos casos de uso. O gerente utiliza para acompanhar o progresso do projeto e por aí vai. Por isso se diz que o RUP é guiado por Casos de Uso

Arquitetura de Componentes
A arquitetura é a estrutura organizacional do software. Segundo o RUP é "a sua organização ou estrutura de componentes significativos que interagem através de interfaces". A arquitetura de um sistema reflete as grandes decisões a respeito da implementação. Diz em quantas camadas o sistema é feito, quais frameworks são utilizados, quais padrões de projeto foram implementados e coisas do tipo. E o RUP dá grande ênfase à arquitetura.

Segundo o RUP a arquitetura do software inclui: As decisões significativas sobre a organização de um sistema. A seleção dos elementos estruturadores e suas intefaces, a especificação dos elementos do sistema e como eles colaboram entre si.

A arquitetura não se preocupa apenas com estrutura e comportamento, mas também com funcionlidades, desempenho, segurança, reuso, manutenibilidade, decisões técnológicas e econômicas. Por isso os requisitos não funcionais, podem influenciar fortemente na decisão da arquitetura.

O que é um Componente?
É uma parte independente do seu sistema. Grupos de código coesos com interfaces e comportamentos bem definidos. Possui forte encapsulamento de conteúdo. Pode ser substituído por outro. Os componentes se comunicam através de suas interfaces visíveis e um nunca conhece o comportamenteo interno do outro.

Vantagens
Permite reuso em grande escala. Por serem independentes e coesos, podem ser usados diversas vezes e em sistemas diferentes. O caso do Hibernate é clássico: um componente para mapeamento OO-Relacional que é utilizado em praticamente todos os sistemas de software web em java atualmente.

Bom gerenciamento da complexidade do projeto e mantém a integridade do sistema. A separação em componentes permite que os problemas sejam tratados de forma separada, já que eles são isolados. Isso identifica, isola, projeta, desenvolve e testa as partes bem formadas do sistema em separado.

É possível utilizar componentes de prateleiras disponíveis no mercado.

Visões Arquiteturais
No RUP a arquitetura é representada por uma série de visões de arquitetura diferentes. São perpectivas diferentes da arquitetura. Conhecido como modelo de visão 4 + 1 porque são 5 visões disponíveis. Seria como a construção de uma casa, ondem existem vários projetos diferentes. Um arquitetônico, um de instalações elétricas, um de hiráulica e etc.

Visão Lógica ou Visão de Projeto descreve as principais classes no projeto do sistema. Define as classes de projeto mais importantes, a organização em pacotes e subsistemas, e a organização destes pacotes em camadas. É uma das principais visões e é obrigatória. Os diagramas de classes, sequencia e pacotes aparecem muito nesta visão.

Visão de Implementação contém a organização em termos de módulos, pacotes e camadas. É uma visão opcional que entra nos detalhes da Visão Lógica. Descreve o código da sua aplicação. Tudo o que foi gerado a partir do projeto. Visão mais detalhada do projeto do sistema.

Visão de Processos descreve o ascpecto simultâneo do sistema. As tarefas (processos e threads) que são concorrentes devem ser definidas nessa visão. Só deve ser usado caso o sistema possua alto grau de paralelismo. Por isso é opcional.

Visão de Implantação descreve como serão as configurações das instalações físicas do sistema. Contém a descrição dos vários nós físicos do sistema e a aloção de taréfas atribuídas a eles. É uma visão opcional, que pode ser usada quando o sistema for distriuído.

Visão de Caso de Uso é uma visão externa, o ponto de vista do cliente a respeito da perspectiva funcional. Contém os casos de uso e cenários que abrangem comportamentos significativos em termos de arquitetura, classes, ou riscos. É uma visão obrigatória do documento de arquitetura.

Modelagem Visual (UML)
Fazer uso de notação gráfica para exibir o projeto do software. A linguagem gráfica permite que o nível de abstração seja aumentando, escondendo detalhes e faciliando a comunicação com os clientes. Um usuário não consegue entender o código e a linguagem escrita é muito ambígua para isso. Essa notação visual também adiciona precisão à captura dos requisitos. Como a ambiguidade é reduzida, acontece uma melhora na comunicação da equipe.

O RUP determina o uso da UML (Unified Modeling Language)
UML é uma notação padrão para modelagem de software. Oferece diferentes perspectivas de um problema: estática, dinânima, colaborativa e etc. Ajuda a manter o projeto (os diagramas) e o código consistentes.

Os artefatos UML possuem suporte das ferramentas automatizadas recomendadas pelo RUP para ajuda na produtividade da equipe.

Verificação da Qualidade
Qualidade não é algo pontual, não deve ser verificada apenas no fim ou em pontos específicos, mas em todo o seu projeto de forma contínua. "A característica de ter demonstrado a realização de um produto que atende ou excede os requisitos acordados, conforme avaliado por medidas e critérios acordados".

Você deve estabelecer os critérios de qualidade anteriormente, já com critérios de medida. Para ter qualidade, o produto precisa, no mínimo, atender esses critérios que foram estabelecidos.

O RUP prevê duas atividades para assegurar a qualidade do produto.

Controle de Qualidade
Tem foco no produto e encontra defeitos específicos. Faz o teste no que foi gerado, no final. Verifica se existe um defeito naquilo que foi produzido.

Garantia da Qualidade
O foco fica nos processos e na execução deles. Garante que você está fazendo as coisas de maneira certa. Pode ser alcançado com utilização de boas práticas de mercado e etc.

Qualidade é multidimensional e possui vários critérios ou dimensões.
Andamento: o progresso do projeto.
Variação:  diferença entre planejado e executado.
Confiabilidade: o quanto seu produto é confiável?
Funcionalidade: os casos de uso foram implementados corretamente?

Desempenho: o desempenho está adequado às necessidades.

Muitos outros critérios podem ser utilizados para medir a qualidade, mas o importante é que esses critérios sejam definidos antes da execução do projeto, para que não sejam adaptados para dar uma falsa ideia de qualidade no final de tudo.

A verificação da qualidade é importante porque o custo de uma correção sobe exponencialmente com o passar do tempo. Os defeitos corrigidos após implantação custam muito mais caro do que a correção durante o desenvolvimento. A verificação da qualidade diminui os custos e os riscos.

Gerenciamento de Mudanças
Sempre que existe muito paralelismo no projeto, é preciso controlar o ambiente. Quando existem vários desenvolvedores e equipes, diferentes locais de desenvolvimento, muitas iterações, releases, produtos e plataformas heterogêneas, se não existir um controle disciplindo do processo de desenvolvimento, o projeto tende ao caos rapidamente.

Item de Configuração
Uma entidade que satisfaz algum propósito para o usuário final e que pode ser unicamente identificado. Podem ser código-fonte, especificações, modelos, artefatos e etc.

Primeiro é preciso identificar quais são esses itens que necessitam estar sob a Gestão de Configuração.

Gerenciar Mudanças é utilizar uma abordagem sistemática para avaliar, decidir sobre as mudanças e coordená-las. É o processo de coordenar, avaliar e decidir sobre a realização de mudanças propostas naqueles itens que estão sendo gerenciados.

Apenas as mudanças aprovadas são implementadas nos itens de configuração, nos dados e documentos relacionados. É preciso avaliar o impacto, pertinência e o custo-benefício antes de aprovar.

No RUP existem as atividades de :
Coordenação de atividades e artefatos: procedimento repetíveis para gerenciar as mudanças nos artefatos.

Coordenação de iterações e releases: controle sobre os releases ao final das iterações. (baseline)

Controle de mudanças no software: mantém uma estrutura bem definida para grenciar mudanças no software.

terça-feira, 22 de maio de 2012

RUP para Concursos - Parte 2 - Metodologia e Conceitos Chave

Metodologia
É composta por um Processo de Desenvolvimento que é configurado especificamente para a sua organização. É composta por um conjunto de métodos e práticas bem definidos e que possuem responsáveis (papéis), entradas, saídas e ordem de precedência. Inclui ferramentas, tecnologias, pessoas, padrões e guias.

Ao instânciar um processo de desenvolvimento baseado no RUP, o que se está procurando é definir quem faz (papéis)o que é feito (produtos de trabalho) , como é feito (descrições das tarefas) e quando é feito (fluxos de trabalho). Nas disciplinas existem papéis que executam determinada tarefa ou atividade que resulta em um produto de trabalho ou artefato. Um exemplo seria a disciplina de Requisitos possui o papel Analista de Sistemas que deve executar a tarefa Estruturar Modelo de Caso de Uso e o produto de trabalho gerado será o Modelo de Caso de Uso.

Você terá uma metodologia baseada no RUP e não a metodologia RUP em sí. A organização deve pegar o RUP e adaptá-lo de acordo com as necessidades e assim, criar o seu próprio processo de desenvolvimento de software.

A metodologia conta com alguns componentes: Modelos, padrões, guias, equipes treinadas, linguagem padrão (UML) e ferramentas de automação.

Benefícios da Metodologia embasada no RUP:  

Qualidade de Software através da utilização das melhores práticas de mercado, que já foram testadas e comprovadas.

Maior produtividade e Previsibilidade porque as equipes seguem um processo definido, o que evita conflitos dentro do projeto. As pessoas já sabem quem faz qual atividade e quando fazer.

As características acima, o controle de riscos e a disciplina de gerência de projetos do RUP levam a um Maior controle sobre custos e prazos.

Conceitos Chave do RUP

As 4 Fases do RUP
São as etapas dos projeto de desenvolvimento com base no RUP. (1º eixo, Eixo Dinâmico do Gráfico das Baleias). Cada fase termina com um marco.

Concepção / Iniciação
Determinar o escopo do projeto para que seja possível estimar custos e riscos do projeto. É gerado um macro-planejamento. Estima-se o tamanho do projeto, os custos e os riscos. São definidos os objetivos que a organização pretende alcançar com o projeto. Todas as partes interessadas devem entender os objetivos a serem alcançados.

Elaboração
Assegura que os principais riscos foram diminuídos e uma arquitetura estável foi definida. Dentre os casos de uso, que foram definidos na fase anteior, aqueles mais arriscados, importantes e complexos são identificados e implementados para garantir que a arquitetura está adequada. Isso já reduz o risco do projeto. O marco é a aquitetura do projeto estabilizada.

Construção
Desenvolver o produto de forma iterativa e incremental para a Transição. 20% dos casos de uso foram detalhados e implementados até a fase de Elaboração. Aqui os outros casos de uso são implementados. Nessa fases as equipes trabalham muito em paralelo e com velocidade. O marco da fase é o build estabilizado do sistema ou a capacidade operacional inicial. O produto deve ser capaz de ser operado.

Transição
Disponibilizar o software para o usuário final. Assegurar que o sistema esteja disponível e funcionando corretamente. Inclui documentação do sistema, guias do usuário e etc. O marco é o lançamento do produto.

As fases não são idênticas em termos de esforço e tempo gasto. Abaixo estão alguns números mágicos da metodologia.

  Iniciação Elaboração Construção Transição
Esforço ~5 % 20 % 65 % 10%
Programação (Cronograma) 10 % 30 % 50 % 10%

É possível ver que a fase Construção é a que consome maior tempo (50%) e maior esforço (65%).

Uma passada pelas quatro fases é chamada de Ciclo de Desenvolvimento e gera uma primeira versão do seu software, o que seria a versão 1.0. Uma próxima versão, de evolução do software, seria a versão 2.0. Essa segunda parte é considerada um novo ciclo e é conhecida como Ciclo de Evolução.

Durante o Ciclo de Evolução a ênfase nas fases não é a mesma do Ciclo de Desenvolvimento. Na maioria dos casos, os riscos já são conhecidos e arquitetura já está estabilizada, então, a fase de elaboração, por exemplo, será menor.

Iterações
"Uma sequência distinta de atividades que resulta em um release do seu produto". Uma iteração é uma passada pelas 6 disciplinas de ENGENHARIA do seu projeto. As iterações podem ser consideradas como mini-projetos em cascata.

As 6 disciplinas de engenharia são: Modelagem de Negócios, Requisitos, Análise e Design, Implementação, Teste e Implantação.



A cada iteração as atividades de cada disciplina são executadas e no final é gerado um produto de trabalho (release), que é um incremento no sistema. Pode ser um release interno (para a equipe ou usuários específicos) ou um release externo (para os clientes). Para que o release seja liberado, é perciso estar estabilizado de alguma forma. Para isso é criada uma baseline. A baseline é o estado estável e aprovado que libera o release.

Cada fase possui várias iterações. O que muda de uma fase/iteração para outra é a enfase que é dada nas disciplinas. Durante a passagem por uma disciplina pode não haver necessidade de executar nenhuma atividade de uma disciplina específica. Isso acontence principalmente no início e no fim do projeto.

Disciplinas
Conjunto de atividades (fluxo de trabalho) relacionadas a uma área de interesse do projeto para geração de resultados. As disciplinas do RUP lembram as fases do modelo em cascata, porque são as atividades técnicas que são executadas durante o projeto. Detalham como executar as atividades, quem executa e quais produtos de trabalho são gerados após a execução das atividades.

Algumas disciplinas estão associadas a conjuntos específicos de modelos e os modelos são conjuntos de artefados. Cada disciplina possui seu próprio fluxo de trabalho, que é um diagrama de atividades da linguagem UML.

Disciplinas de Engenharia
Modelagem de Negócios
Requisitos
Análise e Projeto
Implementação
Testes
Implantação

Disciplinas de Suporte
Gerenciamento de Projetos
Gerenciamento de Configuração e Mudanças
Ambiente

M-RAITIGGA

Papéis
Definem o comportamento e as responsabilidades em um processo. Dentro de uma disciplina, os responsáveis por executar as atividades são os papéis. Exemplos de papéis são: programador, testador, gerente de projeto, arquiteto e etc.

No final das contas, os papéis acabam associados a um ser humano, mas a definição de um papel trata de um comportamento e de um conjunto de responsabilidades. Uma pessoa pode executar um, nenhum ou vários papéis.

Tarefas ou Atividades
Uma unidade de trabalho desempenhada por um papel. Algo que um papel faz e produz um resultado dentro do contexto de uma disciplina. São compostas por: finalidade, passos, entradas e saídas, papel responsável, além de guias e padrões para auxiliar a execução. 

Produtos de Trabalho
São o resultado de um processo de trabalho utilizados como entradas e/ou saídas na execução das atividades. São divididos em artefatos (termo genérico), entregáveis (os que são entregados aos clientes) e os resultados (outcomes), que são produtos intangíveis, representam o alcance de algum objetivo. No geral, produtos de trabalho são chamados de artefatos.

Podem ser: modelos, documentos, código fonte, executáveis, etc

Resumindo: Papéis executam Tarefas que geram Artefatos.
Exemplo: O Especificados de Requisitos (papel) executa Atividade chamada Detalhar Caso de Uso e gera um artefato, que é o próprio Caso de Uso.

Um ciclo de vida de desenvolvimento no RUP é a passagem pelas quatros fases: Iniciação, Elaboração, Construção e Transição. Cada fase possui seus objetivos próprios e são delimitadas por marcos. Quando uma fase é executada e seus objetivos são alcançados, o marco é alcançado. Cada fase pode ter N iterações, que são as passadas sequenciais pelas 6 disciplinas de engenharia do projeto. Dentro das disciplinas existem os papéis que executam as atividades e geram artefatos.


segunda-feira, 21 de maio de 2012

RUP para Concursos - Parte 1 - Características e Gráfico das Baleias

O RUP é um produto da IBM em formato de um framework de processos adaptável. Não devemos pegar este framework e aplicar tudo o que está escrito. É necessário entendê-lo e configurar a estrutura do RUP para adaptá-lo à realidade da sua organização.

RUP É um modelo prescritivo (diz como as coisas devem ser feitas) que fornece atividades, artefatos e guias que geralmente recomendam a utilizaçào de outros produtos da IBM e da linguagem de modelagem UML.

Em provas o RUP é tratadado como processo de desenvolvimento ou metodologia.

Características do RUP
Iterativo e Incremenntal
O ciclo de vida do produto é divido em iterações, que são passagens sequenciais pelas disciplinas de engenharia de software. O problema total a ser resolvido é dividido em partes menores e a cada incremento uma parte acabada do software é entregue.

Guiado por Casos de Uso
Os casos de uso são utilizados por todas as partes interessadas, inclusive os stakeholders. É o documento que conecta todas as fases e disciplinas do RUP de uma forma ou de outra.

Centrado na Arquitetura
É a macroestrutura que organiza os principais elementos do seu sistema, como classes, interfaces e componentes. A arquitetura evolui de acordo com as principais necessidades dos sistema. Essas necessidades estão maepadas nos casos de uso.

Orientado a Objetos
Os componentes são baseados em objetos e colaboram entre si para implementar (realizar) os casos de uso.

Planejado por Riscos
Os riscos são analisados a todo tempo e aqueles que MAIS CRÍTICOS são tratados prioritariamente. Os casos de uso arquiteturalmente significativos (os mais difíceis, nebulósos, críticos, arriscados, etc) são os primeiros a serem implementados.

Gráfico das Baleias
O RUP é compostos por 4 fases e 9 disciplinas.

No gráfico você percebe dois eixos. O eixo horizontal, a primeira dimensão ou a dimensão dinâmica representa o passar do tempo ao longo do projeto. Mostra os aspectos do ciclo de vida do processo a medida que o projeto se desenvolve.

Possui as 4 fases (Iniciação, Elaboração, Construção e Transição). Cada fase possui várias iterações e dá ênfase em determinadas disciplinas, cada disciplina possui mais importância em determinada fase e menor importância em outra fase. A iteração de uma fase passa por todas as disciplinas.


Ao final de cada fase existe um marco ou milestone. É um ponto do projeto e um determinado conjunto de artefatos que foi alcançado e estabilizado. Cada fase possui o seu marco. Determina o fim da fase.

O eixo vertical, segunda dimensão ou eixo estático, é onde são representadas as disciplinas (agrupamento das atividades de engenharia de software, por área de interesse ou natureza das atividades). É estático porque as atividades a serem executadas são sempre as mesmas, não variam de acordo com o tempo. Um determinada disciplina possui as mesmas atividades em todas as fases. Assim, o eixo estático não considera a passagem do tempo. O que varia é a ênfase em uma disciplina ou em outra de acordo com o tempo.

As disciplinas possuem atividades, papéis, artefatos e produtos de trabalho. São 9 disciplinas no total. 6 de engenharia (Modelagem de Negócios, Requisitos, Análise e Design, Implementação, Teste e Implantação) e 3 de suporte (Gerenciamento de Configuração e Mudança, Gerenciamento de Projeto e Ambiente)

No gráfico, quanto maior a área que uma disciplina ocupa em determinada fase, maior a ênfase naquela disciplina durante a fase. Todas as disciplinas são consideradas em todas as fases, mas algumas possuem maior atividade e outras possuem menor ou nenhuma atividade em determinado momento.

O RUP tem duas dimensões.

A primeira dimensão, eixo horizontal, representa o aspecto dinâmico do processo.
Expresso em fases, marcos e iterações.

A segunda dimensão, eixo vertical, representa o aspecto estático do processo.

Expresso em componentes, disciplinas, atividades, artefatos, papéis e etc.

sexta-feira, 18 de maio de 2012

COBIT 4.1 para Concursos - Parte 5 - Domínios e Processos


Os 4 Domínios do COBIT
Planejar e Organizar (PO - 10 processos)  - é o Domínio de mais alto nível e relacionado com planejamento e estratégia da empresa. É ele quem dá o rumo da organização. Provê a direção para a entrega de soluções e serviços. Não existe mão na massa, somente planejamento do rumo da organização.

Adquirir e Implementar (AI - 7 processos) - Domínio onde se coloca a mão na massa. As soluções são imlpementadas e ficam prontas para rodar. Fornece as soluções e as transfere para se tornarem serviços No COBIT, o gerenciamento de mudanças aparece em Adquirir e Implementar e o gerenciamento de configuração aparece separado, em Entrega e Suporte.

Entrega e Suporte (DS - 13 processos) - Recebe as soluções e as torna passíveis de uso para os usuários finais. Garante a operação de todo o ambiente necessário para utilização dos sistemas.

Monitorar e Avaliar (ME - 4 processos) - Monitorar e avaliar os processos para garantir que o planejamento inicial do PO não esteja sofrendo desvios ou que estes desvios estejam sendo corrigidos. Implementa a melhoria contínua e exerce a Governança de TI.

Os Requisitos de Controle Genéricos do COBIT
Além dos 210 objetivos de controle que são distribuídos pelos 34 processos, existem 6 requisitos de controle genéricos que se aplicam a todos os processos. São identificados como PC (Process Control)

PC1 - Metas e Objetivos do Proceso
Cada processo deve ter metas e objetivos claros e mensuráveis. Você deve ser capaz de medir o desempenho do processo e esses objetivos precisam estar relacionados com os objetivos de negócio da organização

PC2 - Propreidade dos Processos
Cada processo deve ter um proprietário, uma pessoa que responde pelo processo.

PC3 - Repetibilidade dos Processos
O processo precisa ser capaz de repetir os resultados de forma consistente.

PC4 - Papéis e Responsabilidades
Cada processo deve ter suas atividades-chave atribuídas para papéis e responsabilidades. É o que a Tabela RACI faz.

PC5 - Políticas, Planos e Procedimentos
Os processos devem possuir políticas, planos e procedimentos associados documentados formalmente, revisados, mantidos atualizados e os envolvidos devem ser comunicados sobre qualquer mudança.

PC6 - Melhoria do Desempnho do Processo
Cada processo deve ter métricas identificadas para medir o seu desempenho.

Planejar e Organizar (PO)
Domínio tático e estratégico. Não trata questões operacionais e de baixo nível. É o domínio de alto nível, que cuida de questões de longo prazo, estratégicas e fundamentais para a sobreviência da empresa. Diz como a TI pode contribuir para o atendimento dos objetos de negócio e envolve planejamento, comunicação e gerenciamento em diversas perspectivas. 

Questão abordadas neste domínio e que devem ser respondidas de forma afirmativa após a implantação dos processos: A estratégia do negócio e a TI estão alinhadas? A empresa está otimizando a utilização de recursos? Todos na organização compreendem as metas de TI? Os riscos relacionados à TI estão compreendidos e gerenciados? A qualidade dos sistemas de TI está adequada às necessidades do negócio? 

PO1 - Definir um plano estratégico
Tudo começa neste processo. A empresa precisa saber como vai se posicionar no mercado e daí criar um plano estratégico de TI. Integrar e alinhar a gestão de TI ao negócio. Traduz os objetivos de negócio em objetivos e serviços de TI. Diz quais projetos e serviços serão escolhidos e disponibilizados. 

PO2 - Definir a arquitetura de informação
Definir o modelo coorporativo de dados. É importante ter uma arquitetura global de dados para a organização. Sempre que um novo projeto começa pode já utilizar este modelo coorporativo. Criar também uma classificação das informações na sua organização.

PO3 - Determinar as diretrizes de tecnologia
Define o padrão tecnológico da empresa. Aplicativos, plataformas e etc. Isso é estratégico, já que ambientes muito heterogênos ou com pouca portabilidade podem prejudicar a estratégia da empresa. Algumas empresas utilizam toda a plataforma de um mesmo fornecedor. Exemplo: plataforma da Oracle ou Microsoft.

PO4 - Definir os processos, organização e relacionamentos de TI
Definir como a área de TI vai funcionar. Escolher quais processos do COBIT você vai usar. Definir os comitês. Escolher quais coisas do modelo do COBIT se aplicam a realidade da sua empresa. 

PO5 - Gerenciar o investimento em TI
Definir os critérios para o investimento em TI. Decidir como e onde investir. Quais projetos são prioritários e o quanto será alocado em cada um deles. É extremamente estratégico pois pode levar a empresa a falência. A gerência pode considerar o retorno de investimento ou outros fatores financeiros para tomar tal decisão.

PO6 - Comunicar metas e diretrizes gerenciais
É preciso comunicar as metas, políticas, procedimentos, guias e diretrizes às pessoas para que tudo o que foi definido seja seguido. É preciso disseminar o conhecimento. 

PO7 - Gerenciar os recursos humanos de TI
Gerenciar as pessoas. Contratar, definir competências, responsabilidades e cargos. Definir quantas pessoas de cada perfil. Quantos programadores? Quantos analista? Gerentes? Projetistas? 

PO8 - Gerenciar qualidade
É importante definir os critérios de qualidade e uma forma de controlar a qualidade nos processos de TI. Determinar o que vai ser feito na TI para manter a qualidade. 

PO9 - Avaliar e gerenciar os riscos de TI
Definir uma forma para avaliar, mitigar e tratar os riscos. Mapear todos os riscos importantes que podem afetar a organização, classificá-los e definir estratégias para tratá-los. 

PO10 - Gerenciar Projetos
Gerenciar os projetos com a integração de todos os outros gerenciamentos. Integra todos os planos de gerenciamento de projetos.

Adquirir e Implementar (AI)
Pega as diretrizes vindas dos processos de PO, que identifica o que deve ser implementado, e executa os processos de implementação. Cobre a identificação, desenvolvimento e aquisição de soluções de TI. Neste domínio você decide se desenvolve a solução desde o início ou se adquire a solução pronta.

Mudanças e manutenções em sistemas já existentes também estão incluídas neste domínio. Então este domínio deve ser considerado  sempre que houver uma necessidade de desenvolvimento ou manutenção.

Questão abordadas neste domínio e que devem ser respondidas de forma afirmativa após a implantação dos processos: As soluções dos novos projetos conseguem atender as necessidades do negócio? Os projetos conseguem ser entregues dentro do prazo e orçamento planejados? Os novos sistemas funcionam adequadamente depois de implementados? As mudanças são conduzidas com baixo impacto nas operações que estão em execução no negócio?

Adquirir e Implementar faz 3 coisas básicamente: identifica as soluções que serão providas e depois desenvolve do zero ou as adquire prontas do mercado. 

AI1 - Identificar soluções automatizadas
Identifica as soluções automatizadas que vão atender as necessidades do negócio. Essas soluções devem ser técnicamente adequadas e economicamente viáveis. É preciso estudar a viabilidade das soluções

AI2 - Adquirir e manter software aplicativo
Garantir que a empresa tenha um processo de desenvolvimento de software. O COBIT não diz qual processo você deve ter, mas que é preciso ter um para adquirir, manter ou desenvolver software.

AI3 - Adquirir e manter infraestrutura de tecnologia
Baseado nas diretrizes do PO3 - Determinar as Diretrizes de Tecnologia, que definiu as platarformas técnológicas da empresa, é preciso aplicar as diretrizes para desenvolver a infraestrutura técnológica para as aplicações de forma controlada e sistemática.

AI4 - Habilitar operação e uso
Se preocupa com a transferência de conhecimento. Elaboração de manuais, procedimentos, guia de usuários, treinamentos e etc. Tudo o que é necessário para de fato fazer as pessoas operarem e utilizarem os sistemas e serviços.

AI5 - Adquirir recursos de TI
São 4 recursos de TI no COBIT. aplicativos, informação, infraestrutura e pessoas. O processo cuida de como contratar os recursos necessários para a implantação. Contratação de pessoas, acordos com fornecedores e etc. 

AI6 - Gerenciar mudanças
Criar um método para gerências as mudanças. É preciso receber as solicitações de mudanças, verificar o impacto delas, priorizar, autorizar e revisar todas as mudanças que podem atrapalhar a operação dos serviços de TI.

AI7 - Instalar e homologar soluções e mudanças
É preciso instalar e homologar as soluções e mudanças. Aqui você testa as soluções implantadas para conseguir deixá-las disponíveis para uso no ambiente desejado.


Entregar e Suportar (DS)
Cobre a entrega propriamente dita dos serviços. É na execução destes processos que colocam os serviços para funcionar. É onde o valor é agregado de fato. Gerencia a segurança e a continuidade dos serviços. Dá suporte aos usuários. Aqui estão os processos operacionais, como gestão dos dados e da infraestrutura.

Questão abordadas neste domínio e que devem ser respondidas de forma afirmativa após a implantação dos processos: Os serviços de TI estão sendo entregues de acordo com as necessidades do negócio? Os custos de TI estão otimizados? Os usuários conseguem utilizar os sistemas com segurança e produtividade? Atributos como confidencialidade, integridade e disponibilidade estão implementados de forma adequada?

DS1 - Definir e gerenciar níveis de serviço
É como a gerência de nível de serviço do ITIL. Estabelece acordos com os clientes da organização. Diz as características de disponibilidade dos sistemas. Traça planos de contingência. Define-se a capacidade dos sistemas e outras coisas do tipo. Tudo isso é definido em um SLA, que é um contrato de nível de serviço entre a TI e os clientes.

DS2 - Gerenciar serviços de terceiros
Os contratos com terceirizados são firmados no domínio de Aquisição e Implementação no AI5 - Adquirir recursos de TI. Aqui acontece a gerencia dos contratos. Estabelece-se as responsabilidades das partes e garante-se que os fonecedores estão entregando o que é esperado de acordo com o SLA definido para o contrato no DS1 - Definir e gerenciar níveis de serviço.

DS3 - Gerenciar capacidade e desempenho
Garantir que existe desempenho suficiente, hoje e no futuro, para atender as necessidade da organização e para sustentar o acordo de nível de serviço. Aqui também é tratado o gerenciamento da disponibilidade dos sistemas.

DS4 - Garantir continuidade dos serviços
Assegurar que existe um plano de contingência e um plano de continuidade para recuperar os serviços caso um problema desastroso aconteça. O plano de contingência prevê um nível mínimo de operação para os serviços, mesmo que sejam procedimentos manuais. O plano de continuidade prevê a recuperação quando o desastre acontece. Diz como voltar a operar. 

DS5 - Garantir a segurança dos sistemas
Garantir a confidencialidade, integridade e disponibilidade dos serviços. Definir os procedimentos de segurança para detectar e tratar incidentes de segurança da informação.

DS6 - Identificar e alocar custos
O PO5 - Gerenciar Investimentos de TI possui um foco a longo prazo e estratégico. Aqui a ideia é contabilizar quanto os serviços estão realmente custando e cobrar os clientes pelo uso do serviço. O foco é operacional e não decidir onde investir o dinheiro.

DS7 - Educar e treinar os usuários
O AI 4 - Habilitar Operação e Uso é ligado ao treinamento dos usuários. O DS7 precisa garantir a continuidade do conhecimento que foi passado no treinamento que aconteceu no AI4. (depois estudar melhor esse)

DS8 - Gerenciar a central de serviços e os incidentes
É preciso ter um ponto único de contato para ser disponibilizado aos usuários para que se comuniquem com a organização para reportar problemas, obter orientações e acesso aos serviços. Incidentes são os relatos dos usuários sobre acontecimentos "ruins", desvios negativos que acontecem nos serviços.

DS9 - Gerenciar a configuração
Para dar suporte à gerência de incidentes é preciso existir a gerência de configuração, que trata da integridade dos ativos de processo, de tudo aquilo que mantém os serviços rodando. É o controle das versões. Com isso é possível comparar e verificar se as versões que estão rodando correspondem ao que deveria estar rodando.

DS10 - Gerenciar os problemas
Os problemas são as causas dos incidentes. Vários incidentes relatados pelos usuários ao service desk  podem ser causados pelo mesmo problema. Os problemas podem ser resolvidos de forma reativa ou proativa. Gerenciar problemas é tratar a causa raíz dos incidentes.

DS11 - Gerenciar os dados
Basicamente se resume a fazer o bakcup dos dados e ter procedimentos para restauração quando for necessário.

DS12 - Gerenciar o ambiente físico
Gerenciar as instalações físicas onde os equipamentos são hospedados.

DS13 - Gerenciar as operações
Executar as operações de dia a dia da TI, o que for necessário para manter a produção. Agendar e executar os jobs que rodam em horários específicos e coisas do tipo. (estudar melhor esse).

Monitorar e Avaliar (ME)
Visa assegurar a qualidade dos processos de TI e manter a conformidade com os objetivos de controle. É um domínio voltado para melhoria continua da qualidade dos processo. Garante que os resultados prometidos e esperados estão sendo alcançados. Utiliza mecanismos de acompanhamento e monitoramento dos controles internos com avaliações ou auditorias internas e externas. 

Questão abordadas neste domínio e que devem ser respondidas de forma afirmativa após a implantação dos processos: As medições encontram problemas antes que seja muito tarde? Existem garantias de que os controles internos são eficientes e eficazes? É possível associar o desempenho da TI às metas do negócio que foram estabelecidadas? A Governança de TI está sendo alcançada? 

ME1 - Monitorar e avaliar o desempenho
Foco nas metas e indicadores. Verifica se os processos estão atingindo os resultados esperados através das Medidas de Resultado e dos Indicadores de Performance. Se os resultados não estiverem de acordo, verifica o que pode ser modificado para que o desempenho melhore.

ME2 - Monitorar e avaliar os controles internos
Checar se a organização está usando normas adequadas para gerenciar os processos que foram escolhidos pela organização. São 210 objetivos de controle no COBIT e é preciso um processo que verifique se os controles escolhidos são os mais adequados para o gerenciamento dos processos. 

ME3 - Assegurar conformidade com requisitos externos
Peculiaridade do COBIT. Verificar se as leis, regulamentos e normas externas ou internas estão sendo seguidos. 

ME4 - Prover a governança de TI
É preciso prover relatórios informativos para a gerência da empresa exercer a Governança de TI.

segunda-feira, 14 de maio de 2012

COBIT 4.1 para Concursos - Parte 4 - Modelo de Maturidade, Objetivos e Indicadores


Modelo de Maturidade do COBIT
O Modelo de maturidade mede o desempenho ou maturidade de CADA PROCESSO DE TI. Para avaliar o desempenho ou nível de determinado processo é preciso ter um modelo de medição.

O modelo de maturidade permite identificar o estágio atual da empresa com relação ao que o modelo propõe. Permite identificar o estágio atual médio do mercado e assim comparar com a organização. Dessa forma é possível criar uma meta de aprimoramento da empresa para determinar até onde a instituição quer chegar.

No CMMI, a maturidade é da empresa e não do processo. Aqui no COBIT, a maturidade é medida para cada processo.

A principal utilidade de um modelo de maturidade é realizar comparações

O Modelo de Maturidade Genérico do COBIT vai dar as diretrizes para os modelos de maturidade de cada um dos 34 processos.


Os níveis são parecidos com o CMMI, mas existem diferenças.

Um processo está nos seguintes níveis quando:

Nível 0 - Inexistente - quando o processo nem é reconhecido, a empresa não reconhece a necessidade de tratar a questão.

Nível 1 - Inicial - quando o processo é reconhecido e as soluções são aplicadas caso a caso de maneira Ad hoc. É executado de forma desorganizada.

Nível 2 - Repetível (porém Intuitivo) - Quando tem uma gestão básica e segue um caminho padrão, um conjunto de regras básicas. Procedimentos similares são seguidos por pessoas que executam a mesma tarefa. Não existe formalização na empresa. A coisa é intuitiva e depende do conhecimento dos indivíduos. (semelhante ao nível 2 do CMMI)

Nível 3 - Definido - quando possui documentação e o conhecimento sobre o processo é compartilhado por toda a empresa. Passa a existir padronização dos processos. Possíveis desvios são difíceis de detectar por que não existe medição. (semelhante ao nível 3 do CMMI) 

Nível 4 - Gerenciado e Mensurável - quando possui monitoramento e medição do processo. Assim passa a existir correção quando necessário. Existe automação e utilização de ferramentas de forma fragmentada. 

Nível 5 - Otimizado - quando são alcançadas as melhores práticas de acordo com os resultados mensuráveis daquele processo. As ferramentas automatizadas são utilizadas de maneira mais efetiva e completa para aprimorar a qualidade e efetividade do processo.

O modelo de maturidade do COBIT admite níveis quebrados. O enfoque desses modelo não é medir os níveis de forma precisa ou certificar que a empresa alcançou determinado nível, não é isso. A intenção é traçar um perfil da empresa para que se possa melhorar seus processos. Não existe certificação COBIT para nível de maturidade.

Um processo pode estar em vários níveis de maturidade ao mesmo tempo. Cada questão do processo estará em um nível de maturidade diferente. 

Objetivos e Indicadores
Eles ajudam a medir o desempenho dos seus processos. Assim é possível realizar comparacões com outras empresas, com as melhores práticas do mercado e com o objetivos da sua instituição. Assim é possível identificar falhas e desvios. Só é possível controlar os processos com uma medição clara e objetiva.

A medição ajuda a responder as seguintes questões: estamos atingindo nossas metas? Estamos seguindo no caminho certo? Como medimos os resultados? Como controlamos os processos? Como determinamos se estamos fazendo as coisas certas?

Existem 4 níveis de objetivos para os 34 processos do COBIT. Cada processo mapea os objetivos que devem ser alcançados e estes são dividos em 4 níveis. A definição dos objetivos acontece de cima para baixo, do negócio para a atividade. O negócio representa o nível de objetivo mais alto e as atividades representam o nível mais baixo.

Objetivos de Negócio: definem os objetivos da organização, é a parte estratégica.
Objetivos de TI: são derivados dos objetivos do negócio e definem o que o negócio espera da TI.
Objetivos de Processo: definem o que os processos de TI precisam fazer e entregar para atender os objetivos de TI
Objetivos das Atividades: Definem o que precisa ser feito dentro de cada processo.

Além de definir os objetivos, que são os resultados esperados, é preciso verificar se os resultados foram ou serão alcançados. O COBIT possui 2 tipos de indicadores estratégicos.

Medidas de Resultado - Indica se um processo alcançou seu resultado esperado, que são os objetivos. Esse indicador responde se os objetivos FORAM atingidos. São indicadores históricos. Conhecidos como lag indicators (indicadores históricos).

Indicadores de Performance - Indicado para medir o progresso em relação ao objetivo que se quer alcançar. Indica se os objetivos SERÃO atingidos no futuro. Conhecidos como lead indicators (indicadores futuros)

Como ligar os objetivos ao indicadores?

Para cada objetivo identificado é preciso estabelecer uma Medida de Resultado para determinar se o objetivo foi alcançado. Com medidas tiradas em momentos diferentes, é possível avaliar ser o processo melhorou ou não em relação aos momentos anteriores. Para as Medidas de Resultado, utiliza-se as medidas do próprio nível do objetivo para saber se o objetivo foi alcançado.

As Medidas de Resultado de um objetivo do nível imediatamente mais baixo servem como Indicadores de Performance para objetivos de nível imediatamente mais alto. Exemplo: As medidas tiradas no nível Objetivos de TI, para apuração dos Indicadores de Performance, são consideradas no nível imediatamente mais alto, que é Objetivos de Negócio. Se essas medidas estão melhorando com o tempo, significa que, provavelmente, os objetivos do negócio serão alcançados. Se essa medida piora com o passar do tempo, é provável que os objetivos não sejam alcançados no futuro. 

Medidas de Resultado:
Olham o passado com medições após os resultados (lag indicators)
Foco financeiro e nos clientes
Ajudam a responder se os objetivos FORAM atingidos.
Medidas de Resultado de nível mais baixo se tornam indicadores de performance de nível mais alto.

Indicadores de Performance
Olham para o futuro. As medições são feietas antes dos resultados. (lead indicators)
Foco nos processos e aprendizado
Indicam se os objetivos definidos SERÃO atingidos.

domingo, 13 de maio de 2012

COBIT 4.1 para Concursos - Parte 3 - Componentes do COBIT - Informações, Recursos de TI e Tebela RACI

Essa é a segunda parte do meu resumo de COBIT para concursos públicos. Só lembrando que esses são meus resumos de estudo. Utilize as informações por sua conta e risco.



Os 7 Critérios da Informação
Para atender aos objetivos de negócio da organização, a informação precisa seguir determinados critérios de controle, que são denominados como os critérios da informação. São dividos em 3 categorias: Qualidade, Segurança e Guarda (Fiduciary). 

Efetividade ou Eficácia (Qualidade): A informação entregue precisa ser relevante e pertinente, entregue em tempo, de maneira correta, para a pessoa correta, de forma consistente e utilizável. 


Eficiência (Qualidade): A informação entregue deve fazer o melhor uso possível dos recursos da organização. Deve-se buscar a máxima produtividade com o menor custo. 


Confidencialidade (Segurança): A informação deve ser protegida para evitar divulgação indevida e ser conhecida apenas pelas pessoas que possuem permissão para isso. 

Integridade (Segurança):  A informação precisa ser correta, completa e consistente. 

Disponibilidade (Segurança):  A informação deve estar disponível sempre que for necessária para o negócio. 

Conformidade (Guarda ou Fiduciary): A informação deve estar de acordo com as leis, regulamentos e contratos que afetem o negócio de alguma forma. As regras internas da empresa também são consideradas. 

Confiabilidade (Guarda ou Fiduciary): A informação entregue para a gerência deve ser confiável para a tomada de decisão negocial.

Resumindo, as informações precisam ter qualidade, ser seguras, atender às leis e percisam ser confiáveis.

Os 4 Recursos de TI
Uma organização deve considerar 4 tipos de recursos de TI para adiquirir e estes recursos serão gerenciados pelos 34 processos descritos no COBIT.

Aplicativos ou Aplicações: sistemas automatizados ou procedimentos manuais que processem informação. Atenção: procedimentos manuais também estão incluídos.

Informações ou Dados: são dados em todas as suas formas, que servem de entrada ou saída para os sistemas de informação da organização.

Infraestrutura: toda tecnologia que possibilida o processamento dos aplicativos. Isso inclui hardware, sistemas operacionais, bancos de dados, redes e ambientes de suporte. Tudo aquilo que dá suporte a operação dos sistemas.

Pessoas: Equipe necessária para planejar, adiquirir, entregar, suportar e monitorar os serviços. Inclui as equipes internas e externas (terceirizadas).

Matrizes de Responsabilidade ou Tabelas RACI
É uma matriz que fornece a compreensão dos papéis e responsabilidades de cada processo. Diz quem faz  o que dentro de um processo. Cada um dos 34 processos possui a sua matriz.

As Quatro Categorias de Responsabilidades dos Pepéis:

Reponsável (Responsible) - pessoa responsável pela execução da atividade. É quem coloca a mão na massa

Responsabilizado (Accountable) -  não é a pessoa que executa atividade. É a pessoa que presta contas pelo resultado da atividade. É quem aceita e/ou aprova.

Consultado (Consulted) - opina sobre determinada atividade. O responsável pela atividade pode consultar o a pessoa que tiver essa atribuída desta responsabilidade, essa poessoa pode opinar na atividade. É uma comunicação bi-direcional.

Informado (Informed) - pessoa mantida informada sobre o andamento de uma atividade. Normalmente um gerente da empresa ou coisa semelhante.


A tabela mostra uma lista de atividades para um determinado processo (linhas). Em cinza, no alto e na diagonal, são mostrados os papéis. Olhando-se linha e coluna, estão marcadas as categorias dos papéis com as letras RACI. Assim você sabe qual responsabilidade está associado a qual papel e a qual atividade.

Por exemplo: O CIO (chefe da TI) é o responsabilizado (Accountable) por desenvolver a estratégia para operacionalizar a solução. É ele quem aprova ou não aprova esta estratégia e é ele que irá responder pelo sucesso ou falha dessa atividade.

Essas atividades descrevem O QUE deve ser feito e NÃO COMO deve ser feito.

COBIT 4.1 para Concursos - Parte 2 - Estrutura

As 5 áreas de Foco da Governança de TI segundo COBIT
Os 5 pilares da Governança de TI

São os 5 tópicos que direcionam a área de TI:

Alinhamento Estratégico: garantir que o planejamento da TI esteja diretamente alinhado ao planejamento do negócio. Liga as operações da TI aos planos do negócio.

Entraga ou Agregação de Valor: entregar serviços que vão agregar algo de fato às empresas. São benefícios que vão ajudar o funcionamento da empresa e com custos otimizados.

Gestão de Risco: transparência com relação aos riscos e incorporação da gestão de riscos aos processos da organização.

Gestão de Recursos: Melhor utilização possível dos investimentos e recursos de TI. É preciso justificar os investimentos em aplicativos, informação, infraestrutura e pessoas e gerenciá-los de forma adequada.

Mensuração de Desempenho: acompanha e monitora o desempenho da TI através de BSC (Balanced Scorecard).

Estrutura do COBIT
Tudo o que acontece na organização é em função da necessidade de negócio. Para atender esses requisitos e prover as informações necessárias à gerência são criados os processos de TI com os objetivos da própria TI, que são derivados dos objetivos de negócio.

Com base nesses processos, existem 3 linhas de atuação:

A primeira linha divide os processos de TI em atividades chave. Essas atividades possuem tabelas de responsabilidades (RACI) relacionadas a cada atividade.

Na segunda linha de atuação é preciso medir a performancee e os resultados para garantir a maturidade da organização.

Na terceira linha de atuação os 210 objetivos de controle garantem que os objetivos da TI e do negócio estão sendo e serão alcançados. Define-se que resultados são esperados para cada processo. Cada objetivo de controle é implementado por práticas não obrigatórias de controle.

Abaixo a figura que mostra os componentes da estrutura do COBIT


Princípios Báscios do COBIT
Tudo nasce com os requisitos e objetivos do Negócio. Esse Negócio precisa de informações, que devem atender aos 7 critérios da informação, e essas informações são produzidas por recursos de TI (4 tipos de recursos de TI). O Negócio define o quanto vai ser investido nos recursos de TI. Esses recursos são utilizados e gerenciados pelos 34 Processos de TI do COBIT, que definem o que deve ser feito, as respnsabilidades e as metas que devem ser alcançadas. Os 210 processos possuem indicadores de desempenho e resultado, além de um modeo de maturidade. Por fim, estes Processos de TI entregam a informação para a organização e o ciclo recomeça.

Para prover a informação que a organização precisa para atingir seus objetivos de negócios, a organização precisa investir em recursos de TI e gerenciá-los usando um conjunto de processos para entregar os serviços necessários.


Os Objetivos da TI são derivados a partir da estratégia da empresa. A decisão é de cima para baixo.

Primeiro define-se a estratégia organizacional. Depois da estratégia definida, são definidos os objetivos do negócios.para a TI, só então os objetivos da TI são definidos. Para alcançar estes objetivos, a TI depende de uma arquitetura cooportativa de TI, que são os recursos necessários para as coisas funcionarem. Com essa infraestrutura funcionando, os processos vão gerar as informações que serão processadas em aplicativos e que percisam de pessoas para gerenciá-los.

quinta-feira, 10 de maio de 2012

COBIT 4.1 para Concursos - Introdução - Parte 1

Esse é mais um dos meus resumos para concurso que faço durante os meus estudos. Quem vem ao blog já conhece o esquema. Se algo estiver errado, não me culpem, mas podem aproveitar o quanto quiserem. 

O COBIT nasceu como um modelo para auditoria de TI. Os auditores iam na empresa realizar a auditoria e verificavam se as empresas tinham objetivos de controles implementados. Era uma compilação de itens a serem verificados em uma auditoria de TI. Só as versões criadas a partir de 2005 (4.0 em diante) é que vieram focadas na governança de TI.

O COBIT - Control Objectives for Information and Related Technology é uma estrutura de controles com as seguintes características: é uma estrutura focada no negócio, orientada a processos (34), baseada em objetivos de controle e que utiliza métricas e medições baseadas em modelos de maturidade. Não é uma metodologia (assim como ITIL e CMMI também não são), mas como já foi dito, é uma estrutura de controle.

Metodologia é uma receita de bolo, é um passo a passo, diz você como fazer. O COBIT é muito resumido para isso. O CMMI e o ITIL até sugerem como fazer algumas coisas, mas o COBIT, nem isso.

Desafios da TI segundo o COBIT

Alinhar a TI ao Negócio (todos os modelos dizem isso)
O que a TI entrega não costuma ser o que a organização espera, então a TI deve trabalhar em conjunto com o negócio e não em paralelo.

O problema é que nem sempre a empresa sabe quais são as suas prioridades e muitas vezes levantam suas necessidade de forma superficial. As prioridades devem ser bem estabelecidas e seguidas.

As decisões tomadas pela TI não podem ser independentes, é preciso que elas sejam tomadas em conjunto com o resto da organização e de acordo com a finalidade da instituição. Para isso, é preciso uma boa comunicação e uma definição clara das prioridades. No geral, os problemas são causados pela falta de comuniação.

Manter a TI Funcionando
As empresas dependem fortemente da TI e a interrupção de um serviço de TI pode causar impactos muito significativos para o negócio. Por isso, os serviços precisam estar sempre disponíveis. Serviços indisponíveis significam perda de oportunidades, redução de lucros e isso impacta na reputação da organização.

É fundamental garantir a continuidade de serviços críticos de TI

Entregar Valor aos Clientes
Como a TI é muito importante nas empresas atualmente, é necessário garantir que TODAS as ações da TI forneçam algum tipo de valor à organização. Os projetos devem ser entregues dentro de prazo e no custo acordado.

A TI precisa justificar o retorno sobre investimento. O cliente precisa perceber que o dinheiro gasto está sendo traduzido em alguma coisa.

Gerenciar os Custos da TI
Os gastos da TI costumam estar fora de controle. As empresas possuem conhecimento dos custos e do retorno do investimento em outros setores, mas não conseguem apurar essa informações com relação à TI. Elas sabem quanto gastam com advogados, logística, contabilidade e outras coisas, mas não com a Informática e isto é igualmente importante. Os custos envolvidos com os ativos de TI não são bem compreendidos

Gerenciar a Complexidade
A quantidade de sistemas e tecnologias é muito grande e nem sempre as arquiteturas são compatíveis, não existe interoperabilidade entre os diversos sistemas. Isso gera muitas dificuldades e aumenta a a complexidade para manutenção do ambiente.

As inovações técnológicas são muito rápidas e é necessário atualizar a equipe.

Além disso é preciso gerenciar fornecedores, que é um tarefa crítica. Onde está escrito fornecedores, está incluído também os terceirizados e qualquer agente que forneça algo para a organização.

Cumprir Leis e Regulamento
Explicitar esta característica é uma peculiaridade do COBIT.

A área de atuação da empresa possui diversos regulamentos governamentais que impactam nos sistemas de TI da organização. A TI precisa estar ciente disso e implantar os sistemas em conformidade com as leis. O mercado exige responsabilidade social e legal.

Manter a Segurança da Informacão
Com o avanço da técnologia, o risco de vazamento de informação é muito maior do que era. As instituições e pessoas estão cada vez mais integradas e com acesso a Internet. A informação precisa estar sempre disponível e os usuários não se preocupam com a segurança da informação.

É importante garantir que a informação chegue somente a quem deve recebê-la.

Solução do COBIT para os Desafios
É preciso ligar os desafios de TI a uma estrutura de controle para alcançar a Governança de TI. Governança pode ser resumida em uma palavra: controle. São 210 objetivos de controle.

Este Controle / Governança de TI visa permitir que a TI se alinhe com os objetivos da empresa para que a instituição obtenha vantagem competitiva. Tratando os riscos significativos é possível exeplorar melhor os benefícios da TI e garantir o alinhamento com o negócio e o cumprimento das leis e regulamentos.

Governança de TI é responsabilidade da ALTA GERÊNCIA. Quem define as estratégias e objetivos não é a TI, mas a liderança da organização.

Governança de TI Segundo COBIT: 
Conjunto de estruturas e processos para garantir que a TI suporte e maximize os objetivos e estratégias de negócio da organização, adicionando valores aos serviços entregues, balanceando os riscos e obtendo o retorno sobre os investimentos em TI.

A TI não existe por razão própria, mas para suportar e maximizar os objetivos e estratégias do negócio. 

O COBIT é um modelo integrador com estrutura de controle, focado no negócio para tudo o que diz respeito a TI e serviços relacionados. 

Dentro do COBIT existem processos de gerencialmento de serviços de TI (ITIL), processos de melhores práticas para desenvolvimento de software (CMMI), normas de segurança (27001), processos de gerenciamento de projeto (PMBOK) e etc. É um modelo de alto nível, trata desses assuntos, mas não se aprofunda.

Características do COBIT

Focado no Negócio: todos os objetivos da TI são derivados sempre depois das metas do negócio. As decisões vem sempre de cima para baixo.

Orientado a Processos: as atividades são organizadas em 34 processos divididos em 4 domínios.

Baseado em Controles: cada processo possui seus próprios objetivos de controle, totalizando 210. Esse objetivos são resultados que se deseja obter.

Dirigido por Métricas: possui indicadores de performance e medições de resultados. Além disso possui um modelo de maturidade próprio.