Mostrando postagens com marcador Gerencia de Projetos. Mostrar todas as postagens
Mostrando postagens com marcador Gerencia de Projetos. Mostrar todas as postagens

quinta-feira, 15 de setembro de 2011

Diagrama de Caso de Teste


Diagrama de Caso de Teste tem por objetivo, auxiliar na visualização do Cenário como um todo do ponto de vista do Analista de Testes e o Testador. Ele testa um Cenário com suas principais funcionalidades e suas integrações.


Notação:

* Atores
* Casos de Teste
* Relacionamento entre estes elementos


Estes relacionamentos podem ser:

* Associações entre Atores e Casos de Teste
* Generalizações, extends, includes entre os Casos de Teste
Os Casos de Teste podem estar opcionalmente estar envolvidos por um ou mais retângulos (herdado dos Diagramas de Casos de Uso), onde representam os limites do Cenário.
Em maiores detalhes:
  •     Atores 
Um Ator é representado por um boneco e um rótulo com o nome do Ator. Um Ator, na situação em questão, o Analista de Teste ou o Testador que pode ser um usuário humano ou um sistema computacional. 
 
  •  Casos de Teste
Um
Caso de Teste é representado por uma elipse e um rótulo com o nome do
Caso de Teste (herdado do Diagrama de Caso de Uso). Um Caso de Teste
define o que será testado dentro do Cenário e suas funcionalidades.

 
  • Relacionamentos
 
o Ajudam a descrever Casos de Teste
o Entre um Ator e um Caso de Teste
* Associação
Define uma funcionalidade do sistema do ponto de vista do usuário. 
 
o Entre Casos de Testes

Include
Um relacionamento include de um Caso de Teste A para um Caso de Teste B, indica que B é essencial para o comportamento de A. Pode ser dito também que B é_parte_de A.
Extend
Um relacionamento "extendido" de um Caso de Teste B para um Caso de Teste A, indica que o Caso de Teste B pode ser acrescentado para descrever o comportamento de A (é facultativo). A extensão é inserida em um ponto de extensão do Caso de Teste A.
Ponto de extensão em um Caso de Teste é uma indicação de que outros Casos de Teste poderão ser "adicionados" a ele. Quando o Caso de Teste for invocado, ele verificará se suas extensões devem ou não ser invocadas.
Quando se especifica B extends A, a semântica é:
• Dois Casos de Teste são definidos: A e A é "extendido" por B;
• B é uma variação de A. Contém eventos adicionais, para certas condições;
• Tem que ser especificado onde B é inserido em A.
 
o Generalização ou Especialização (é_um)

* O Caso de Teste B é_um Caso de Teste A (A é uma generalização de B, ou B é uma especialização de A).
* Um relacionamento entre um Caso de Teste genérico para um mais específico, que herda todas as características de seu pai.
 
  • Cenário
* Limites do Cenário: representado por um retângulo envolvendo os Casos de Teste que compõem o Cenário.
* Nome do Cenário: Localizado dentro do retângulo.
 
Caixa de Expedição de Documentos – Exemplo Básico 1

 
 
 
 
 
 
 
 
 
Cadastro de Clientes – Exemplo Básico 2

    


Fonte Atrigo Completo  http://www.testexpert.com.br/?q=node/1381
Por : Ricardo Franco

segunda-feira, 5 de setembro de 2011

Introdução e exemplo de Análise & Design (A&D) Orientado a Objetos


Nos ciclos de desenvolvimento de sistemas, costumamos ter as fases de análise e design. Vamos ver neste artigo, um exemplo de AD orientada a objetos com UML.
Na fase de análise os envolvidos devem obter uma idéia clara do que o sistema deverá fazer, sem se preocupar com detalhes relacionados à maneira como ele irá implementar as funcionalidades levantadas nos requisitos do projeto.
Para buscar este entendimento, podemos utilizar interessantes propostas de mercado, baseado no levantamento e análise dos requisitos do projeto através de Casos de Uso da UML (Unified Modeling Language).
Após entrevistar os envolvidos no projeto da área de negócios do cliente, podemos analisar os Cenários de Caso de Uso identificados, elaborando e refinando diagramas de Caso de uso e de Atividades. Todas as informações levantadas devem ser registradas em algum documento formal baseado em propostas de mercado, veja propostas de Especificação de Caso de Uso e Relatório Sintético de Caso de Uso na referência bibliográfica deste artigo. Estes documentos devem ser validados pelos envolvidos no projeto e divulgados para toda a equipe do mesmo.
Veja abaixo, representação UML do Caso de Uso de um sistema no cenário responsável pela emissão de conta de restaurante.
Este digrama UML mostra claramente um usuário (Ator) e uma funcionalidade do sistema (Caso de Uso) que estaremos implementado em nosso sistema e deve ser elaborado na fase de análise de nosso projeto, vindo a incorporar a documentação técnica a ser aprovada e enviada para os desenvolvedores da aplicação.
A Especificação de Caso de Uso deve conter uma série de informações adicionais. Neste exemplo, poderíamos citar as informações e processamento abaixo para ser possível encerrar a conta:
  • Em qual mesa se deseja encerrar a conta.
  • Quais itens foram consumidos na mesa e qual o valor de cada um.
  • Realizar processamento e emitir a conta.
  • Registrar que o consumo da respectiva mesa está encerrado.
Como parte da análise, torna-se extremamente interessante termos o Diagrama de Atividades relacionado ao Caso de Uso. Este diagrama deve ser validado com os donos do requisito, para aprovação e corroboração de nosso entendimento do que deve ser efetivamente desenvolvido, mostrando inclusive regras de negócio envolvidas, quando possível.
Observe no diagrama abaixo como este diagrama torna muito claro o funcionamento, sequencia de eventos e regras de negócio envolvidos no mesmo.
Na fase de análise, podemos definir sem detalhamento as classes envolvidas no Caso de Uso, sendo que na fase de design teremos que detalhar as mesmas. Neste momento, algumas classes sugeridas na fase de análise podem deixar de ser consideradas enquanto muitas outras provavelmente irão aparecer, conforme evoluímos em nosso trabalho.
Veja abaixo, diagrama de classes inicial de nosso processo de modelagem.
Já na fase de design, temos que ter as classes muito bem definidas para termos um desenvolvimento correto, documentado, com facilidades de manutenção corretiva e evolutiva como a modelagem sugerida abaixo.
Na verdade, considero todo este processo muito empolgante e ainda existe muitos detalhes bem interessantes a se considerar na modelagem, tais como patterns, arquitetura, persistência de dados, …
Luck favors the prepared mind!
Veja exemplo completo juntamente com templates em Engenharia de Software na Prática: Editora Novatec, 2010. ISBN 978-85-7522-217-1

quarta-feira, 31 de agosto de 2011

Entenda por que você deixa tudo para a última hora


A coisa é tão ruim que até o nome é feio: procrastinação. O "palavrão" designa a ofensa que a pessoa faz a si mesma, mesmo sabendo que isso só a deixará mais vulnerável, sujeita a cometer mais erros, angustiada e exaurida.
"Troquei o 'deixa pra amanhã' pelo 'faça agora'"
"Sou o tipo que só consegue agir na urgência"

O impulso da procrastinação leva você a fazer qualquer coisa, mesmo sem graça, em vez daquilo que é mesmo necessário. Ou você nunca se pegou deletando o lixo do e-mail na hora em que deveria estar enviando um relatório?
ENROLATION
Em levantamento inédito, 33% dos profissionais brasileiros afirmaram gastar duas horas da jornada sem fazer nada de efetivo e 52% admitiram deixar atividades necessárias para a última hora.

Os índices da pesquisa feita por Christian Barbosa, especialista em gestão de tempo, são mais altos que os de pesquisas semelhantes nos EUA, no Reino Unido e na Austrália, onde enroladores crônicos são 20% da população economicamente ativa.
"Aqui, as pessoas se sentem poderosas deixando tudo para a última hora e não ficam culpadas por isso", diz a psicóloga Rachel Kerbauy, da Sociedade Brasileira de Psicoterapia e Medicina Comportamental, que pesquisou como brasileiros protelam exames e cuidados de saúde.
A culpa com a procrastinação pesa mais em sociedades influenciadas pelo luteranismo ou calvinismo, diz o professor de filosofia Mario Sergio Cortella, da PUC-SP. "A religião colocou o trabalho como elemento de salvação. Adiá-lo vira um vício."
Independentemente de aspectos culturais e morais, a procrastinação, além de não ajudar, atrapalha. E empurrar com a barriga não tira o problema da frente, só faz ele crescer nos pensamentos.
"A única coisa que se pode ganhar é culpa. A pessoa nem consegue fazer algo prazeroso em troca, porque não é uma escolha livre do uso do tempo", diz Cortella.
Na pesquisa, que incluiu 1.606 pessoas, as principais explicações para a enrolação foram falta de tempo, medo do fracasso e complexidade da tarefa a ser feita.
Mas, para a psicanalista Raquel Ajzenberg, da Sociedade Brasileira de Psicanálise, as causas do comportamento podem estar ligadas a dificuldades maiores.
AUTOBOICOTE
Um dos motivos é o que Freud chamou de "fracasso como êxito". É quando a pessoa, por motivos inconscientes, recua sempre que está perto de uma situação de sucesso. Os adiamentos crônicos são um autoboicote.

Acontece também com os perfeccionistas. Para eles, o medo de não conseguir fazer algo impecável paralisa a ação, e o planejamento excessivo para cumprir metas muito idealizadas os leva a adiar o trabalho constantemente.
"A pessoa tem uma coisa importante para fazer, mas fica cavando mais buracos, descobrindo problemas para resolver antes e não faz o que deve ser feito", diz Barbosa.
Ele diz que a maioria é treinada na infância a deixar tudo para a última hora, porque os pais agiam assim.

Culpa também do sistema educacional, vê Cortella. "O estudante daqui é viciado em provas feitas só com a memória. Se é para decorar, o mais fácil é só estudar na véspera."
Enquanto psicanalistas analisam as motivações inconscientes da procrastinação e filósofos se debruçam sobre seus aspectos éticos e morais, os economistas estudam o problema pensando na relação custo-benefício.
Até um prêmio Nobel de economia, o americano George Akerlof, tratou do assunto. Ele concluiu que as pessoas adiam porque os custos imediatos de fazer determinada tarefa parecem mais reais do que o preço de fazê-la no futuro.
"Você tem certeza de qual é o custo imediato, o desprazer do esforço, e tem certa miopia em relação aos benefícios futuros. Acredita que protelar é uma escolha racional, mas é um autoengano", diz o economista Paulo Furquim, professor da Fundação Getúlio Vargas de São Paulo.
SOB PRESSÃO
Essa ilusão de óptica ajuda a entender por que algumas pessoas embaçam até nas tarefas necessárias para fazer algo de que gostam.

Algumas pessoas também tentam fazer do adiamento uma tática de ação, porque só conseguem se motivar no sufoco da última hora.
Para Barbosa, isso é um padrão mental adquirido por força do hábito. "A pessoa treinou para produzir sob pressão. Se treinou, dá para destreinar e aprender um novo modelo de lidar com o tempo", afirma.


http://www1.folha.uol.com.br/equilibrioesaude/966952-entenda-por-que-voce-deixa-tudo-para-a-ultima-hora.shtmlFonte : 

quinta-feira, 25 de agosto de 2011

COMO DESENHAR FLUXOGRAMAS DE PROCESSOS DE NEGÓCIO




Aghatha Maxi Consulting – Serviços Gerenciados de Segurança e Governança de TI

Parte 1 – Introdução, Conceitos e Modelos.

Como desenhar fluxograma de processos de negócio – parte 1 – Introdução, Conceitos e Modelos.

Muitas vezes nos deparamos com a dificuldade que os responsáveis pelos processos nas organizações têm ao demonstra-los graficamente.
Com o objetivo de auxiliar os colegas nesta atividade  vamos descrever neste artigo um método simples, mas que ao mesmo tempo é bastante útil e prático.
Vamos utilizar na confecção deste artigo, fluxos e gráficos desenhados com o uso do VISIO da Microsoft,  no entanto o leitor poderá fazer uso de qualquer outra ferramenta disponível no mercado, inclusive ferramentas livres.
O nosso objetivo aqui não é avaliar esta ou aquela ferramenta, ou determinar se uma ferramenta é melhor que a outra, ou ainda a possibilidade de utilização de outros modelos e formatos para a documentação de processos.
O nosso objetivo é descrever um método que o leitor possa aprender facilmente e aplicar na documentação de seus processos.
1 – Introdução ao estudo de processos
Antes de abordar a técnica a ser utilizada no desenho propriamente dito dos  processos é necessário que o nosso leitor tenha o entendimento dos princípios básicos dos processos, para isto vamos abordar os tópicos principais e neste sentido nivelar os conhecimentos.
1.1    – Componentes Básicos dos Processos
Por definição, um “Processo” deve possuir um conjunto de componentes básicos para ser considerado um processo, são eles:  Componente  de “entrada”, com base neste componente é realizado as atividades de  “processamento”, e como resultado  deverá produzir uma  “saída” qualquer.
1.2   - Controle de qualidade entre os Componentes do Processo
Como qualquer atividade destinada a produzir algo, o processo requer a realização de atividades de controle para assegurar a sua qualidade e que deverá ser aplicada em cada um dos seus componentes (Entrada-Processamento-Saída). Agindo desta forma estaremos evitando comunicação de eventuais erros ou falhas entre os elementos que compõem o processo, dentro do universo compreendido pelo próprio processo.
Traduzindo isto de uma forma mais clara:
 
 1.3   - Controle de qualidade entre Processos
No entanto, um processo não é um elemento absoluto e restrito a si próprio,  possivelmente em algum momento dependerá de outros processos para ser “alimentado” e possivelmente, após a execução de seu próprio processamento, passará a “alimentar” outro processo através do seu “produto” e assim sucessivamente.
Diante disto, é uma boa prática considerar ações de controle de qualidade também entre processos, e com isto garantir a qualidade e a integração entre os mesmos, ou seja, é importante assegurar que o “produto” gerado por um “processo fornecedor” seja validado por ele mesmo antes de ser comunicado ao seu “Processo Cliente”.
Traduzindo isto de uma forma mais clara:
 
Em tese, quando agimos desta forma, o “Processo Executor” não teria necessidade de validar os seus “insumos” no momento de proceder o recebimento de sua “entrada”, uma vez que isto deveria ter ocorrido previamente no “Processo fornecedor”, pouco antes do mesmo proceder a liberação de “saída”.
No entanto,
Se verificarmos a qualidade apenas uma única vez, estamos sujeitos à possiilidade de ocorrência de alguma falha na saída do “Processo fornecedor” e nem sempre a “Qualidade declarada” na saída de um processo, atenderá plenamente os requisitos de qualidade necessários para atender a  “entrada” no processo seguinte.
Exemplo Prático: Experimente executar o ciclo de vida de um projeto de desenvolvimento de sistemas, onde cada etapa do ciclo pode ser comparada a um processo. Quando não realizamos estas verificações de entrada e saída em cada uma das etapas do processo de produção do sistema, o grau de variação do produto resultante será um fatorial das taxas de erro ocorridas em cada etapa, (O Resultado será medido pela multiplicação das taxas de erro existentes em cada etapa,  pelas taxas de erro das etapas seguintes, e assim sucessivamente), esta é a explicação matemática de possíveis distanciamentos  entre o “requisito original do negócio” e o  “resultado do produto do projeto”, note que antes de mais nada uma Metodologia é um Processo e pode-se utilizar este conceito na formulação do controle de qualidade na formatação de etapas ou fases de uma MDS.
Traduzindo isto de uma forma mais clara:
 Uma vez entendido estes componentes e os critérios básicos de revisão de qualidade e  integração entre os componentes de um processo e entre processos fornecedores e processos clientes, retornaremos ao nosso objetivo inicial, que é demonstrar graficamente os processos de negócio através de fluxogramas.
2        – Padrão de Simbologia
Existem diversos padrões de símbolos possíveis para desenhar fluxogramas de processos, e inclusive padrões destinados a especificações e desenho técnico de software, modelos de dados e tantos outros. Vamos adotar aqui um modelo bastante simples e composto por um número reduzido de símbolos, mas que são suficientes para demonstrar um processo de negócio através de um fluxograma.
São eles:
 

3        – O  Modelo de Estrutura do Fluxograma do Processo.
Existem diversos formas possíveis de estruturar um fluxograma de processo, a mais indicada para mapear processo é a denominada (CROSS-FUNCTIONAL), o que poderia ser traduzido mais ou menos como “fluxograma cruzado entre funções”.
Neste formato, o fluxograma possibilita a inclusão de informações adicionais, além da sequencia de atividades proporcionada pelo encadeamento dos símbolos, e é possível segmentar o desenho do processo em “setores/celulas” como se fossem uma matriz, sendo inseridos nas linhas os Atores ou funções responsáveis pela execução das Atividades e nas Colunas as etapas existentes em um determinado processo.
Veja como ficaria o desenho de um processo seguindo a estrutura Cross-Functional na visão Horizontal:
 
 O mesmo Processo, seguindo a visão Cross-Functional na visão Vertical:
 
E ainda, o mesmo processo utilizando-se a forma Livre normalmente utilizada. Note que as informações adicionais presentes nas duas opções anteriores fazem de fato a diferença no entendimento do processo.
Fonte - http://goo.gl/ha7JF 

terça-feira, 23 de agosto de 2011

O que e Governanca de TI – A Sua Origem, Historia, Conceitos e Fundamentos Basicos – Parte 1 agosto 20, 2011 por Aghatha Maxi Consulting


O QUE É GOVERNANÇA  DE TI ?

A Sua Origem, História,  Conceitos e Fundamentos Básicos – Parte 1.

O que é Governança de TI ? – A Sua Orígem,  História, Conceitos e
Fundamentos Básicos – Parte 1.

1 – Introdução, Histórico e Conceitos.

1.1 – Introdução / Histórico.
 A Governança em TI ainda é um assunto bastante controverso e pouco entendido de forma geral pelos Gestores ou “Governantes” e na maioria das vezes o assunto é abordado de forma muito ampla ou superficial e não é raro observarmos abordagens equivocadas daquilo que se julgaria ser de fato Governança e ainda o que vem a ser de fato Governança de TI.
 Com o objetivo de auxiliar os colegas e gestores das empresas que necessitam dispender algum esforço em futuro próximo em direção a Governança em suas organizações,  resolvemos escrever este artigo, compartilhando algumas experiências e conhecimentos adquiridos ao longo dos últimos oito anos de atuação neste segmento de consultoria.
 É necessário prevenir ao nosso leitor que o tema Governança de TI é bastante amplo e dependendo das condições preexistentes na organização e da abordagem utilizada para a adoção dos critérios da Governança, a missão poderá ser mais ou menos complexa e ainda irá requer mais ou menos investimento e esforço para ser de fato atingida.
 Primeiramente, é necessário entendermos a origem da “Governança” e quais são os seus reais motivos e objetivos. Explicar a as razões da Governança de TI através da sua relação com a Governança Corporativa,  embora seja a “forma acadêmica” correta, enquanto “abordagem em si”,  não é de todo suficiente para exprimir todos os objetivos a serem tratados e atingidos,  e mais ainda,  não esclarece qual deve ser o papel do “Governante”  antes, durante e depois de  obter a condição de “Governança”, principalmente quando o assunto é relacionado ao uso e gestão da tecnologia da informação.

  • O Conceito “Puro” de Governança.

O conceito “puro” de governança não nasceu em 2002, com a aprovação da Lei Sarbanes-Oxley pelo Governo Norte Americano, ou seja, não foi o congresso deste país que inventou o conceito de Governança (Há colegas que acreditam que isto seja uma verdade, e que a “culpa” destas obrigatoriedades tenha  sido originado pelos políticos norte americano, o que obviamente não é verdade). O conceito de Governança é muito antigo e tem a sua origem nas primeiras organizações politicas e democráticas  nas  cidades-estados da Grécia Antiga (500 AC a 300 AC).

O Termo  “Governança” tem origem na palavra “Governo” e representa em sua essência o “Ato de Governar”, mesmo na Grécia antiga, era exigido do “Governante” certa “conduta” durante o exercício do “poder público” e relacionado aos “Atos” praticados pelo “Governante” durante o seu “Governo”,  sendo requerida pelos “eleitores”  uma conduta baseada em “valores” tais como: “Coerência”, “Transparência”, “Responsabilidade”, “Respeito”, “Ética” em relação ao “Grupo ou coletividade” o qual o governante deveria “representar” através dos seus “atos”.
Enfim, praticar “tudo aquilo” que pudesse ser “julgado pelo bom senso de todos” como sendo um “bom governo”.

  • O Conceito “moderno” de Governança.

Nos tempos atuais, o conceito “público” de governança permanece praticamente inalterado, mudando apenas as formas adotadas pelos governantes para a identificação das “necessidades” dos seus “eleitores” ou “representados” em razão do aumento significativo da quantidade de “eleitores”, e das formas adotadas para comunicar aos mesmos os seus “valores” e o “resultado” obtido pelo seu “governo”, sendo isto denominado “transparência” das ações realizadas, e visam basicamente obter “aprovação” dos “eleitores” dos atos praticados pelo  “governante” em seu “governo”.
Na Grécia antiga, bastavam os Governantes se deslocarem até a praça central e com alguma competência em oratória, quaisquer questões existentes entre  “governo” e “eleitores” poderiam ser de pronto resolvidas.
Nos dias atuais isto se tornou uma prática impossível de ser realizada “pessoalmente”, o que justifica aos “governantes” apoiarem-se nos meios de comunicação para promover a “transparência” dos atos e fatos.

  • O Conceito “organizacional” da Governança.
 Deste ponto em diante, iniciamos o tratamento do que seja Governança no contexto anunciado como sendo o objetivo deste artigo.
    • A Governança em Empresas onde o Dono é Único
 Uma organização, durante o período de tempo onde o  “proprietário” é o gestor único do seu negócio, em tese,  não há razão para aplicação dos princípios de  Governança, pois o “Único Dono” do negócio é o seu “único governante” e “ele próprio” por suas “ações”, “omissões”, “atos de empreendedorismo”  se  “auto constituiu” no exercício desta função.
  
    • A Governança em Empresas onde há poucos Sócios / Investidores

A Partir do momento que o “único dono” recebe “sócios” ou “investidores”, surge automaticamente à necessidade de aplicar os princípios de “governança”, pois surge ai as funções de “governo”, uma vez que dentre os sócios  e investidores existentes, haverá sempre a condição de que “um” mais que os “outros”, seja denominado o “governante” da organização, ou ainda, o seu “gestor”.
Note que mesmo nesta relação, o “gestor” é “aceito” pelos demais “sócios”, materializando a  relação de “governança”, pois há um “governante” e também há  a figura dos seus “eleitores”.

Neste caso, os conceitos e atitudes requeridos historicamente aos “políticos” passam a ser  aplicáveis ao “gestor” da organização, agora não mais  se relacionando com “eleitores”, mas sim em relação aos  demais “sócios e/ou investidores” que o instituiram nesta função.
Como a dimensão do público aqui exposta ainda é reduzida (Quando há poucos Investidores),  o esforço praticado pelo “governante” é um pouco maior,  do que seria necessário ser praticado por um “governante” da Grécia antiga, ou seja, através da execução de algumas reuniões, atas, e comunicados, todas  as questões de “governança” e “transparência” dos atos praticados em  sua “gestão” podem ser dadas como “satisfeitos”.
Neste caso, as questões de “transparência” dos atos de seu “governo”  ainda podem ser “comunicadas” e “avaliadas” com a “presença” de todos os “interessados”.
Pelo menos em “tese”,  as questões de “governo” podem ser resolvidas assim,  em organizações onde há incidência de poucos “sócios” e um “gestor” principal.

    • A Governança em Empresas onde há Muitos Sócios / Investidores
A partir do momento que uma organização, inicialmente com apenas “um dono” ou com “poucos sócios” resolve  “abrir” o seu “capital”, ou seja, transforma as “cotas capitais” em “ações”, e estas por sua vez, passam a serem disponibilizadas para “negociação” junto ao mercado de capitais, estas empresas passam a ser “acometidas” em termos de “governança” pelas mesmas “dificuldades” enfrentadas  pelos “políticos modernos” em razão da grande quantidade de  “eleitores”, só que agora estes “interessados” passam a ser “todos os acionistas” da organização (Aqueles que detêm ações), no entanto, um “gestor” de uma grande corporação não tem a possibilidade de utilizar-se de um canal de TV aberto ou dos meios de comunicação em massa  para comunicar e resolver ali as suas questões de “governo” e dar conta da “transparência” de suas ações,  frente ao publico em geral, uma vez que as “organizações” possuem caráter “privado”, e estas questões só dizem a respeito apenas a uma “parcela” do publico em geral composta apenas pelos seus “investidores”.

Então o nosso leitor poderá se perguntar: Se os assuntos de “governo”  de uma organização são tratados de forma “privada” ou “reservada”. Como então estas organizações atraem novos investidores?

Em resposta a esta dúvida, há ainda que explanar sobre as questões legais, relacionadas às grandes empresas (Lei das Sociedades Anônimas), regras e atribuições impostas pelo Mercado de Capital (Novo Mercado/BOVESPA, SOX, BASEL), e cuja ênfase, estão relacionadas a estabelecer critérios e proteções para o investidor, visando  promover a sua “confiança” em relação às organizações, e este,  é o “fator determinante” que irá “atrair ou repelir” novos investidores para uma organização, ou seja, o foco passa a ser uma “questão de confiança”  e não o critério de “aceitação/aprovação” como é a dimensão enfatizada pela  “governança publica”,  tanto a antiga como na moderna.

Em razão desta “transparência” com o seu “publico investidor”,  que uma “organização de capital aberto” estabelece a sua relação de “confiança”  entre os seus “gestores” e seu “publico investidor”. Isto em essência é o que se denomina “Governança Corporativa”.

Este conceito, embora possa parecer recente, também é antigo e tem a sua origem na “Revolução Industrial”, quando as primeiras “oficinas” se transformar em  “pequenas fábricas” e estas,  após  receberem a  adesão de investidores e sócios veio a se transformar nas primeiras grandes organizações modernas, ai surgiu o conceito e a necessidade do “governante organizacional” e em sua consequência as ações de “governança”.
  
  • A Relação da Governança de TI com a Governança Corporativa.

Em meados do Século passado surge a presença da informática, e com o uso desta ferramenta, as grandes corporações elevaram a sua “capacidade” de processar grandes volumes de operações, e este aumento,  acelerou o crescimento destas empresas e aumentando mais ainda a quantidade de investidores, promovido por décadas de operações e de crescimento constante.

No entanto, como todo o remédio tem o seu efeito colateral, o advento da “informatização” e do aumento “em ordem geométrica” das operações, surge um “Risco” que não havia antes, ou seja,  a “Possibilidade” de que uma “ação isolada” de alguém, em um determinado momento, alterar o conteúdo de um “número” para “mais ou para menos”, e modificar com isto o “resultado final” de uma organização em detrimento da ocorrência de  “fatos reais”  que o justifiquem.

Este tipo de ação “fraudulenta”, uma vez de conhecida  pelo “publico” investidor, pode comprometer drasticamente a “confiabilidade”  que os investidores possuem pela empresa em questão, desvalorizando o “valor” de suas ações no mercado de capitais, e com isto,  prejudicando seriamente a todos os seus investidores.

Pois fatos desta natureza de fato ocorreram, envolvendo algumas empresas americanas entre os anos de 2001 e 2002, foram descobertos e após serem comunicados ao público daquele país, acabou por prejudicar as “economias pessoais” de uma grande quantidade de investidores americanos. Visando a proteção do mercado de capitais e de seus investidores, surgiu em Junho de 2002 a Lei Sarbanes-Oxley,  estabelecendo o “conceito” atual de “Governança Corporativa” e em consequência da participação e importância da “informática” nas operações das organizações, surge também a “Governança de TI”, visando exclusivamente estabelecer mecanismos de proteção, segurança, confiabilidade nas empresas e com isto evitar a ocorrência de fraudes, viabilizar meios para a sua identificação e com isto,  proteger o mercado investidor americano, e demais investidores que atuam naquele pais.
É um fato pouco conhecido como os legisladores americanos chegaram a este “formato” de exigências a serem satisfeitas pelas empresas. Após os escândalos financeiros de 2001/02, os legisladores perceberam que havia algumas empresas, mesmo em detrimento dos eventos  ocorridos no mercado de capitais, continuavam apresentando um alto índice de “confiança” pelos  seus “investidores”, e posteriormente,  visitando cada uma destas empresas,  notaram que elas possuíam em comum a adoção de modelos de gestão baseados em regras de “governo”, controle de condutas administrativas, contábeis e dos processos de qualidade relacionados ao uso da tecnologia e operações embasadas em  “documentos e processos formais que incluíam o uso de melhores práticas sugeridas por diversos padrões de qualidade entre eles: “ISO – International Organization for Standardization e BS- British Standards Institution ” e praticavam ainda uma relação  de “transparência” e  forma “regular” com os seus investidores.

Com base nestas constatações e na inclusão da “responsabilização criminal pela ocorrência de fraudes” a que os gestores passariam responder, foram criadas às bases dos requisitos de Governança que foram instituídos através da Lei Sarbanes-Oxley. O conteúdo da lei em si não proporciona todo o seu conteúdo, pois ela o faz com o auxilio de instruções complementares emitidas por instituições regulatórias (Self-Regulatory Organization- SRO) as quais são instituídas e apoiadas pelo Governo Americano,  tais como: PCAOB – Public  Company Accounting Oversight Board e  ISACA- Information Systems Audit and Control Association,  e que juntas deram origem a base aos requisitos daquilo que denominamos “Melhores Práticas” aplicáveis em Governança e Governança de TI respectivamente.

1.2 – O Início da Governança no Brasil

A Governança Corporativa e a Governança de TI  passam a integrar como “necessidade real” para os Gestores de TI brasileiros, somente dois anos após a aprovação da Lei Sarbanes Oxley pelo Congresso Norte Americano,  visto que nos dois primeiros anos de aplicação desta lei (2002-2003), o  foco inicial era o processos de Compliance das empresas americanas sediadas no território americano, fazendo com que a “onda de Compliance”  chegasse para valer ao Brasil apenas em meados de 2004 e que perdurou fortemente até o final de 2006 (Limite para Conclusão de Compliance SOX).
Neste período, o foco das certificações passaram a ser subsidiarias e filiais das empresas norte americanas sediadas fora do território americano e incluindo algumas poucas empresas brasileiras, que nesta mesma época,  mantinham suas ações na Bolsa de Valores de Nova York (NYSE).

Desta época aos dias de hoje, diversas empresas que inicialmente não figuravam nesta pequena e seleta lista, buscou atender aos requisitos e certificações necessárias e obtiveram  o “direito”  de incluir as suas ações na bolsa de valores norte americana.

Para quem “não é do meio”, isto pode parecer algo “sem sentido”, mas certamente o é:

Para exemplificar a mudança promovida por este “Compliance”, seria mais ou menos em “termos de comparação” a  um fornecedor que vende o seu produto apenas para um “mercado” nas proximidades da sede de sua fábrica e de uma hora para outra, passa e estender as suas vendas para uma grande rede de “supermercados” presentes em todo o país.
Este “aumento”  na presença no mercado e consequentemente do aumento do volume de vendas apresentado pelo “produto”  é comparável  ao  possível impacto causado quando uma “ação” passa a ser comercializada na bolsa de valores  Norte Americana,  e as consequências disto para a empresa são extremamente positivas, pois há um aumento sensível no volume de vendas das suas  “ações” e também do “aporte de recursos” quando este direito é alcançado.

Nesta mesma época (entre 2001/2006),  diversas bolsas de valores pelo mundo afora acabaram criando regras de proteção aos seus  mercados de acionistas, seguindo os mesmos moldes adotados pela NYSE , e no Brasil não foi diferente, e ainda em 2001, iniciamos a adoção de critérios  baseados em “Governança Corporativa”, através da adoção de regras estabelecidas pela CVM- Comissão de Valores Mobiliários e BOVESPA, onde a adesão das empresas,  continua sendo voluntária aos critérios de “Governança Corporativa”, podendo ainda receber classificações de Nível 1 e Nível 2 (Mercado Novo / Bovespa) de acordo com o seu nível de adesão.

Nos critérios de Governança Corporativa estabelecida pelo Nível 2 – Mercado Novo/BOVESPA, a Governança de TI, é tratada de forma “indireta” e através das “verificações” de auditoria aplicadas aos controles internos operacionais e financeiros  nas empresas e realizados com base e referencia as  “melhores práticas de mercado”, quando observadas pelas Auditorias, onde a  ênfase está direcionada a verificação dos riscos e efetividade dos controles internos (Quando menciona o atendimento de “conformidade”  e nos remete as  “melhores práticas de Mercado”, indiretamente nos remete  as “melhores práticas” aplicáveis a Governança de TI, e que são  estabelecidas pela SOX e regradas de acordo com os critérios de auditorias indicados pelo  ISACA e PCAOB.
Embora o nível de exigência aplicado no Brasil não seja o mesmo (é Mais flexível), os critérios de uma “forma geral” utilizados durante a “identificação” e “mitigação” dos riscos seguem a mesma lógica e práticas adotadas pela Governança de TI  norte americanos.

1.3 – Os Novos Paradigmas da Governança no Brasil

Pense um pouco comigo, e veja se o conteúdo do paragrafo a seguir representa ou não uma “realidade muito possível” a médio e longo prazo em nosso país:

No ritmo que as empresas brasileiras estão crescendo, mais dia ou em menos dia, ela penderá para a abertura do seu capital e visando disponibilizar as suas ações para ser negociada na Bolsa de Valores, isto é algo inevitável e representa a única forma de uma empresa de “médio” ou  “médio-grande” porte se capitalizar e tornar-se uma empresa de “grande-porte” em  toda a sua plenitude.

E,  mesmo que a empresa onde atuamos seja uma empresa “familiar”, mesmo para elas,  este dia vai chegar, caso isto não ocorra de fato, estas empresas estão “fadadas” a permanecerem nos patamares atuais ou crescerão em ritmo mais lento, passando a correr o risco de que em algum dia, uma empresa pertencente ao “ grupo principal” venha a lhes adquirir ou venha a ocupar a sua parcela e lugar no mercado. “Infelizmente o mundo é assim mesmo, se não avançarmos rapidamente o “leão” vem e nos consome”.
Entenderá com mais propriedade o conteúdo desta frase, aquele que em alguma vez em sua vida teve a oportunidade de realizar um “salto com paraquedas”. Não é uma decisão fácil, mas será de fato “um paraquedista”, somente aquele que, efetivamente “realizar o salto”. “Para aqueles que “não saltaram” o voo foi apenas um passeio panorâmico, com uma mochila diferente atada as costas”.

Ou Ainda, se a empresa onde atuamos já possui ações negociadas na bolsa de valores em nosso país e obteve com isto um nível de crescimento que a tornou maior do que era inicialmente, é inevitável que em algum dia estas ações passem a ser negociadas em alguma das principais bolsas de valores espalhadas pelo mundo. Esta é a única forma de uma “grande-empresa nacional” vir a tornar-se uma multinacional global e hastear a nossa bandeira em mastros espalhados mundo afora.

Nada disto é, ou poderá ser possível, sem que as questões de Governança Corporativa e as relacionadas à Governança de TI estejam resolvidas e que os controles e métodos envolvidos estejam em pleno uso e funcionamento.”

Se a base  aplicada nesta linha de raciocínio te faz algum sentido e de alguma forma,  você leitor,  concorda com estes argumentos, você está mesmo “fadado” a vir a conhecer a aprofundar-se em “assuntos” relacionados a Governança.

Vamos pensar um pouco mais adiante: Se você esta no início de sua carreira (seja ela relacionada  às ciências de tecnologia ou a administração de empresas em geral), e  pretende vir a ocupar as posições de CIO ou CEO em grandes corporações daqui a  20 ou 30 anos, este é irremediavelmente o seu caminho a ser seguido,  comece a trilha-lo ainda hoje,  ou quem ocupará  esta vaga lá no futuro,  possivelmente será algum “profissional treinee” em  fase de treinamento neste assunto nos dias atuais.
Foi com base nesta lógica e visão deste futuro que criamos o Instituto Hermann Haan e instituímos o projeto IH2, destinado a formar consultores capazes hoje, para que possam vir a se transformar em gestores capacitados e globalizados no futuro.

Mesmo tendo atuado na organização de processos e controles organizacionais e, na organização de processos relacionados a TI durante mais de 25 anos,  confesso que  no início o entendimento e aplicação destes conceitos nos foi um pouco “confuso”, pois as abordagens utilizadas pelos diversos institutos e organizações envolvidas ou inseridas no contexto da  Governança nos parecia ser desconexas e muitas vezes sem sentido, quando analisadas de forma conjunta e integradas entre si, e infelizmente posso lhes garantir que em verdade é assim mesmo. Esta primeira “impressão” causada pelos “conceitos e aplicação” de tudo aquilo que seja relacionado à “governança” aos  “leigos” promove, e acreditamos que continuará a promover durante muito tempo ainda,  muita confusão, tentativas frustradas e uma sucessão infindável de erros de aplicação e integração dos diversos conceitos e práticas envolvidas.

A bem da verdade, cada instituição promove a sua “área de foco” ou “especialidade”, e cada qual,  dentro do limite estabelecido pelo universo contido em seu “quadrado”, promovem da melhor forma possível aquela “parcela” do conjunto de “conhecimentos e práticas” daquilo que denominamos ser governança de TI.  E, o grande “segredo” de tudo isto está relacionado à adoção de modelos que possam integrar e fazer interagir as diversas áreas do conhecimento envolvidas, para que tenhamos como produto final, aquilo que se denomina “Governança Funcional de  TI”.

1.4 – Componentes Principais da Governança de TI.

Vamos inserir aqui uma figura, colocando os principais modelos e recomendações, que juntos, proporcionam um “razoável” grau de cobertura  e  maturidade  em  Governança,  para que o nosso leitor possa perceber a dimensão geral do tema em questão:
 
Embora a figura represente um “organograma”, nos aludindo certa relação de “hierarquia” e “relação de dependência” entre os diversos “modelos” e “melhores práticas”, esta alusão não é de todo correta, embora exista de fato está “relação”, ela é absolutamente relativa quando passamos do campo teórico para o campo prático das relações entre os diversos processos e disciplinas que o compõe.

1.5– Erros comuns causados pela Unitarização dos Componentes da Governança de TI

O erro mais comum aplicado no entendimento e aplicação das disciplinas contidas em cada um dos componentes listados nesta figura e muitas outras variações publicadas mundo afora, é  acreditar que colocá-las em ordem unitária em um plano de ação  (To-do-list) e priorizar uma sequencia para a sua aplicação e então adotá-las  e ainda, que ao final desta  “jornada”,  o “assunto” governança estará resolvido,  Quem pensa assim,  sugerimos repensar imediatamente os seus conceitos, pois embora esta seja uma “abordagem possível”, é também aquela que representa o principal motivo pelo qual a adoção da  “Governança” seja tão dispendiosa, traumática e tão complexa para as empresas.

Vou lhes citar um exemplo, que pode nos representar isto que lhes afirmo, em relação ao volume de investimentos e das inúmeras “rodadas” de “tentativas e erros” que são necessárias muitas vezes para adotar uma melhor prática exigida pela Governança. Vamos citar aqui apenas um,  mas que geralmente é o “mais comum” é o mais “representativo” , e é o que mais facilmente pode ser percebido e entendido.

Exemplo:

Imaginemos que a nossa empresa “fictícia”,  necessita adotar uma “Metodologia”  para manter as suas iniciativas de mudanças em “projetos” sob controle, e com isto, atender aos requisitos estabelecidos pela Governança TI em relação a mudanças e projetos.  (Veja PO10 e AI6 – COBIT 4.1).

Por cinco minutos, vamos “fazer de conta” que a figura contida no gráfico acima citado “não existe ou ainda não seja conhecido por completo”, e sendo assim, “seria razoavelmente correto” imaginar que ao contratar alguém ou você mesmo compor uma metodologia para gerir os seus projetos de “desenvolvimento de sistemas” seria o “suficiente” para considerar o assunto “Gerenciamento de Projetos e mudanças” por concluído e atendido.
Em primeira análise, esta “missão” seria uma atividade razoavelmente “simples”, bastaria alocar alguns de nossos melhores analistas de sistemas, e determinarmos a eles que definam um modelo de trabalho “metodologia” se possível obtendo um “consenso” com os demais analistas de sistemas e programadores da companhia, e era isto, Em pouco tempo, teremos um “método” em uso para promover as mudanças e os projetos de desenvolvimento de sistemas na companhia.

No entanto, se trouxermos o “conteúdo contido em nossa figura” de volta a vida, e repassar cada quadro com um pouco mais de “critério”, facilmente poderemos perceber que  um “projeto”  que se propõe a  “desenvolver ou modificar  um sistema”,  possa ter algum tipo de “relação” e poderia muito bem “causar impactos” em quase “todos”  os quadros que compõem o referido organograma contido em nossa figura.

Vamos entender alguns relacionamentos possíveis, enumerando “uma pergunta” para cada “quadro”, considerando nela algumas “possíveis relações” entre a “disciplina” descrita em cada quadro com um “projeto/atividade” que se propõe a desenvolver/modificar um novo sistema:

  • O controle de acesso a ser inserido no escopo de desenvolvimento do sistema/aplicação foi avaliado pela equipe de riscos e segurança, no momento de analisar os requisitos da nova aplicação?
  • O desenvolvimento e testes, segregação entre as funções / perfis envolvidos na operação do sistema, alçadas e controles compensatórios, conflitos de interesse entre os usuários foram considerados como requisitos no escopo da nova aplicação?
  • Os requisitos do sistema consideram somente as questões de negócio (solicitante) ou também são consideradas as questões de ordem técnicas de TI, tais como: Modelos de  arquitetura, padrões de infraestrutura e serviços de TI, padrões de analise e codificação segura de sistemas,  integrações com os demais sistemas?
  • A Infraestrutura, serviços de apoio e suporte para a nova aplicação foram avaliadas durante o levantamento dos requisitos técnicos para o novo sistema?,  há recursos de TI capazes de absorver a nova aplicação sem causar impacto nas demais existentes?
  • O método de engenharia de software contempla ações de governança em relação ao registro de requisitos, analise, construções, validações e testes,  responsabilidades pela implantação e suporte aos usuários do negócio? – Normalmente as metodologias somente atendem a este requisito.
  • O projeto possui controles que possibilitam o seu gerenciamento durante todo o seu  ciclo de vida de desenvolvimento do software? – Normalmente é construída uma MDS para tratar as questões do ciclo de vida do software  e uma  MGP  atendendo as questões relacionadas ao ciclo de vida do Gerenciamento de projetos. Nestes casos, quando o projeto “não dá certo”,  não há formas de identificar claramente onde ocorreu a falha (Eis aqui a eterna discussão entre o PMO, GP , Analista de Sistemas, Programadores e Testadores, onde cada um fez exatamente a sua “cota parte”, mas o sistema não saiu conforme o combinado.).
  • E Por último e não menos importante,  estão as questões de segurança e não vamos nos enganar acreditando que a segurança deve estar restrita apenas as questões de acesso, pois há ainda as questões de segurança física, redes, backup /restore, continuidade, contingencias, e tudo mais relacionado ao gerenciamento da segurança da informação.

E  para Concluir,  duas perguntas finais:

  • Seria sensato incluir no ciclo de vida de desenvolvimento de sistemas,  “gatilhos” que pudessem atender e responder a estas questões  “durante” o ciclo de vida do projeto?

ou

  • Faria mais sentido não incluir estes “gatilhos”  no contexto da metodologia e deixar para que todas as áreas impactadas  controlem estas “integrações”  de forma paralela a Metodologia Desenvolvimento do sistema?

Quando ocorre uma resposta não adequada para estas perguntas,  verificamos posteriormente a existência de alguns possíveis “vícios”,  mesmo depois de investirmos tempo e dinheiro no desenvolvimento de  metodologias continuamos não atingindo o resultado proposto pela Governança TI e consequentemente causando impactos desastrosos na Governança Corporativa,  no que tange as questões relacionadas a “manter projetos sob controle”, e dai verificam-se situações como as abaixo relacionadas:

  • Sistemas sem controle de acessos, segregação de função, ou com controles falhos e incompletos.
  • Sistema que criam novas situações de risco para a TI e ao negócio, fraudes, erros, inconsistência de dados, apurações incorretas de valores, etc.
  • Sistemas, embora tecnicamente bem desenvolvidos, que não possuem os recursos de infraestrutura e serviços necessários para lhe oferecer o devido suporte, provocando paradas no negócio, perda performance, atrasos operacionais, incidentes recorrentes, etc.
  • Sistemas que acarretam impacto no ambiente e performance em recursos destinados a suportar outros  sistemas pré-existentes (Funcionava bem no inicio, agora demora ou perdeu a performance de uma hora para outra sem nenhuma explicação ou motivo aparente),
  • Projetos que demandam mais tempo para serem concluídos do que o inicialmente planejado, o software ficou pronto e a infraestrutura ainda não, faltam periféricos, instalações de rede até o ponto de utilização, etc.
  • Projetos que demandas mais recursos do que os inicialmente previstos,
  • Sistemas que apresentam falhas de engenharia de software ou de atendimento de escopo,  faltando ou sobrando requisitos em seu produto final,
  • Sistemas confeccionados para os usuários, mas estes,  inexplicavelmente não o utilizam ou apoiam o uso do sistema,
  • Sistemas sem documentação, sem rastreabilidade em seu processo de produção, quem mesmo foi o usuário que solicitou este sistema?
  • Sistemas que após serem concluídos, demandam novas solicitações de desenvolvimento para então integra-los aos sistemas pré-existentes,
  • E tantos outros vícios que poderiam ser aqui relacionados, cuja causa é a falta de  integração entre  a aplicação das melhores práticas com as demais melhores práticas de TI e que na grande maioria das vezes não tem nenhuma relação com aspectos de competência dos técnicos que construíram as soluções, mas sim os que definiram a amplitude dos seus métodos de trabalho (Aqui vale registrar a máxima de Albert Einstein, onde a “pergunta “certa” contém “metade” da resposta”, e a qual eu acrescentaria ainda um pequeno complemento: ”Quando a ”pergunta” ou a  ”resposta” é errada, teremos como resultado o ”dobro ou o triplo” do esforço que seria “realmente necessário” para obter a resposta “realmente certa”.)
Ai o nosso leitor poderá se perguntar, ou ainda continuar tendo dúvidas, relacionadas ao real motivo pelo qual devemos adotar “melhores práticas” em TI para o gerenciamento de projetos e mudanças e os motivos pelos quais estes métodos devem ser integrados a todos os
demais processos de TI.
A resposta é bastante “simples”,  quando inserimos a Tecnologia nas questões de governança, estamos endereçando com isto o “risco” atrelado as suas “operações” e incluindo nelas as atividades de  “desenvolvimento e manutenção” dos sistemas e consequentemente as informações que eles manipulam e armazenam (estas informações irão compor o resultado da empresa ao final do exercício contábil, e serão endereçadas e publicadas no seu Balanço).
Os fatos ocorridos em 2001/2002 ocorreram devido a “fraudes” relacionadas à “manipulação indevida” das informações das empresas.
O “ato” de “desenvolver ou modificar” sistemas esta relacionado diretamente as “informações”, seja através de “projetos ou atividades mudanças” aplicada em sistemas, e ainda, manter isto “sob controle” é um dos  “pontos chaves” da governança corporativa e Governança de TI,  pois interage diretamente na “relação” de Integridade, confiabilidade e disponibilidade das “informações”, e isto,  é à base da “confiabilidade” a que os “governantes”  devem “transparecer” para as partes  “interessadas” em seu “governo”, e, portanto, o resultado obtido pela sua gestão.
Fim Artigo.
—–
—- Fim Conteúdo Artigo —-
Agradecimentos e Convites:
As informações e comentários existentes neste artigo são o fruto de observações e experiências adquiridas pelo autor durante a  execução de projetos ao longo de 30 anos de atuação no mercado. Utilizamos este espaço para a divulgação e intercâmbio destes conhecimentos junto aos nossos leitores, clientes e amigos.
Caso você tenha alguma dúvida ou necessidade de informações adicionais para o seu entendimento ou aplicação, entre em contato conosco através do e-mail abaixo.
Fonte TI Especialista Brasil - http://goo.gl/tvqcb