Esta série de posts, que começa hoje, terá a seguinte divisão:

1) Ferramentas e Instruções de Captura;

2) Interpretação do tráfego capturado;

3) Exercício de demonstração.

Vamos ao trabalho …

1) Ferramentas e Instruções de Captura

Há algumas ferramentas do tipo sniffer para realização de captura de tráfego. As mais comuns são TCPDump para hosts GNU/Linux e Windump para Windows. Tipicamente o Cespe usa trechos capturados com o TCPDump. O ideal é instalar na tua máquina e botar a mão na massa, assim jamais esquece. Caso você não tenha um sistema GNU/Linux instalado, sugiro fazê-lo dentro de uma máquina virtual no SO de sua preferência. Aqui vou sugerir o uso de Debian/Ubuntu. Mas o sabor da distribuição fica a teu critério.

Para quem for instalar a ferramenta, lembro que é importante instalar o pacote libpcap (não tenho certeza se o apt-get resolve essa dependência). Em seguida vá com fé e digite no shell sudo apt-get install tcpdump . Como o GNU/Linux é um SO muito difícil de usar, quando terminar estará tudo instalado e pronto para a captura

Antes de chegarmos ao ponto de digitar o comando, vamos conhecer alguns parâmetros do TCPDump.

• -i <interface>: especifica a interface em que será feita a análise (eth0, eth1, etc);
• -v : verbose;
• -n : inibe a resolução de nomes ou conversão de números de portas em nomes de serviços;
• -w <arquivo> : grava a saída em um arquivo;
• -r <arquivo> : lê um arquivo de especificação de interfaces para captura/análise;
• src host <ip> : delimita a análise sobre um determinado host de origem;
• dst host <ip> : delimita a análise sobre um determinado host de destino;
• dst port <valor>: delimitação por porta de destino;
• src port <valor>: delimitação por porta de origem;
• not host <ip> : exclui da análise os pacotes enviados pelo host do IP especificado.

Vamos à sintaxe. O básico é mandar de cara uma captura de tudo que passa pela interface eth0. Para fazer isso, é só digitar:

• sudo tcpdump -i eth0

Digamos que agora a bola da vez é capturar através da nossa interface eth0 o tráfego destinado à porta 80, comumente http:

• sudo tcpdump -i eth0 dst port 80

Agora, trabalhando uma sintaxe mais completa, podemos analisar o tráfego que passa por nossa if eth0, do host de origem X.X.X.X (onde X.X.X.X é um ip válido) para a porta 80, não resolvendo nomes e escrevendo a saída no arquivo xurupita.txt (a extensão do arquivo é desnecessária) :

• sudo tcpdump -i eth0 src host X.X.X.X dst port 80 -n -w xurupita.txt

Bem, por hoje é isso. No próximo post especifico como interpretar o conteúdo do nosso arquivo gerado. Para facilitar um pouco, sugiro que dêem uma relembrada na pilha TCP/IP.

Luv,

Bonehead

(quem gosta de britrock vai entender a despedida )

Segue minha prometida apostila de Itil V3. É a primeira versão, um beta, na verdade. Erros que forem encontrados podem ser submetidos aqui mesmo para correção nas próximas versões. Seu nome será divulgado no controle de versão da mesma. O material é baseado na Biblioteca Itil V3, no documento oficial de overview do Itil V3 e também no livro Implantando a Governança de TI do Aragon Fernandes e do Wladimir Ferraz de Abreu.

Bons estudos =)

Faça aqui o download.

Apostila ITIL V3 by Thiago Fagury is licensed under a Creative Commons Atribuição-Compartilhamento pela mesma licença 3.0 Unported License.
Permissions beyond the scope of this license may be available at www.fagury.com.br.

É incrível como qualquer apanhado de conhecimentos que seja prescritivo demais precisa de um overhaul de tempos em tempos. Que isso sirva de reflexão.

Pulando a baboseira, vamos ao que interessa. O que mudou, na prática? Vejam:

• Menos processos, 42 desta versão contra 44 da anterior;
• Processos com nomes padronizados (qualquer semelhança com as ISO não é mera coincidência): Verbo + Substantivo;
• Adequado ao novo acordo gramatical (uau!);
• Distinção mais clara entre Ativos de Processos Organizacionais e Fatores Ambientais;
• Padronização taxonômica das Mudanças Solicitadas, das Ações Preventivas e Corretivas e Correção de Defeitos;
• Diagramas de Fluxo Processos foram substituídos por Diagramas de Fluxo de Dados.
• Distinção entre os Documentos do Projeto comuns e o Plano de Gerenciamento do Projeto (antes este era um apanhado daqueles).

Dentro das áreas de conhecimento, as mudanças nos processos ficaram assim:

• Integração: removido o processo “Desenvolver a Declaração de Escopo Preliminar“;
• Escopo: excluído o “Planejamento de Escopo” e inserido o processo de “Coletar Requisitos“;
• Comunicações: novo processo intitulado “Identificação de Stakeholders“;
• Aquisições: um novo processo intitulado “Planejar as Aquisições” trouxe para dentro de si dois processos da versão anterior, “Planejar Compras e Aquisições” e “Planejar as Contratações“, que deixaram de existir. Outros dois processos, “Solicitar Resposta de Fornecedores” e “Selecionar Fornecedores“, também deram lugar a um processo maior, chamado de “Conduzir Aquisições“.

Gerência de Tempo, Custos, Qualidade, Rh e Riscos não sofreram alterações. Na minha opinião a “normalização” dos nomes e os novos processos deixaram mais fácil identificá-los dentro das áreas de conhecimento e dos grupos de processo, podendo até facilitar algum macete para decorar. Vou pensar nisso e no próximo post falo a respeito.

Até.

A inscrição pode ser feita nesse link: http://www.flisolgo.org.br/gyn/index.php/inscricoes

Participem!

Há dois meses recebi este e-mail de um colega concurseiro, que pediu dicas de como proceder para confeccionar um estudo de caso ou uma prova discursiva de TI. Respondi e fiz alguns comentários que podem ser úteis para mais gente, por isso solicitei publicar aqui no blog. Vamos lá.

Olá Thiago!
Sou ———– , concurseiro de Brasília.
Thiago, preciso de um help seu, mas se puder me ajudar, é claro (…).
(…) Minha maior dúvida é como desenvolver esse estudo (de caso), o que eu uso pra fazer isso,
quais técnicas? Se preciso de diagrama(s) ou não…? Você tem noção de como pode ser feito isso?

Prezado Colega,

Vamos ao estudo de caso.

Uma boa dica é dar uma lida neste artigo publicado pelo Nando Pedrosa, no site do Walter Cunha: http://waltercunha.com/blog/index.php/2009/10/03/como-fazer-uma-prova-discursiva-parte-22/ . Ele ensina como fazer uma prova discursiva, além de trazer junto o melhor estudo de caso já feito em um concurso, na minha opinião. Trata-se da prova do Klauss Henry, para o TCU de 2007. Leia com carinho.

É isso pessoal. Bom fim de semana e bons estudos!

Não poderia deixar de registrar minha felicidade em poder ter visto o BB King ao vivo, no Ulysses Guimarães, em Brasília, dia 22/03. Aos 84 anos, Riley B. King é um exemplo para todos nós. Mesmo com dificuldades para se locomover, é uma pessoa de energia incrível, simpático, bem humorado e especialmente feliz por fazer o que gosta. Ainda canta como ninguém e toca como poucos.

Ele sabe que não lhe restam mais muitos dias, no entanto, está na estrada, trabalhando e fazendo o que sabe fazer de melhor. Muitos de nós trabalhamos hoje pensando em nos aposentar no futuro, claro. BB King nunca pensou assim. Sempre quis oferecer ao mundo o que ele tem de melhor, e isso é genial. Acho que Deus dá determinados dons às pessoas certas.

King influencia e influenciou uma geração inteira de músicos de blues e rock. É uma lenda viva, de fato. E além de me emocionar com cada música tocada, como ‘Key to the Highway’ e ‘Thrill is gone’, agora também agradeço a oportunidade de estar lá, testemunhar uma história muito interessante e, claro, tomar mais uma lição para a vida.

“Thank you B.B.!”

BB King em Brasília, foto do amigo JP

This month’s column is simply a collection of what I consider to be facts—truths, if you will—about software engineering. I’m presenting this software engineering laundry list because far too many people who call themselves software engineers, or computer scientists, or programmers, or whatever nom du jour you prefer, either aren’t familiar with these facts or have forgotten them.

I don’t expect you to agree with all these facts; some of them might even upset you. Great! Then we can begin a dialog about which facts really are facts and which are merely figments of my vivid loyal opposition imagination! Enough preliminaries. Here are the most frequently forgotten fundamental facts about software engineering. Some are of vital importance—we forget them at considerable risk.

Complexity

C1. For every 10-percent increase in problem complexity, there is a 100-percent increase in the software solution?s complexity. That’s not a condition to try to change (even though reducing complexity is always desirable); that’s just the way it is. (For one explanation of why this is so, see RD2 in the section “Requirements and design.”)

People

P1. The most important factor in attacking complexity is not the tools and techniques that programmers use but rather the quality of the programmers themselves.

P2. Good programmers are up to 30 times better than mediocre programmers, according to “individual differences” research. Given that their pay is never commensurate, they are the biggest bargains in the software field.

Tools and techniques

T1. Most software tool and technique improvements account for about a 5- to 30-percent increase in productivity and quality. But at one time or another, most of these improvements have been claimed by someone to have “order of magnitude” (factor of 10) benefits. Hype is the plague on the house of software.

T2. Learning a new tool or technique actually lowers programmer productivity and product quality initially. You achieve the eventual benefit only after overcoming this learning curve.

T3. Therefore, adopting new tools and techniques is worthwhile, but only if you (a) realistically view their value and (b) use patience in measuring their benefits.

Quality

Q1. Quality is a collection of attributes. Various people define those attributes differently, but a commonly accepted collection is portability, reliability, efficiency, human engineering, testability, understandability, and modifiability.

Q2. Quality is not the same as satisfying users, meeting requirements, or meeting cost and schedule targets. However, all these things have an interesting relationship: User satisfaction = quality product + meets requirements + delivered when needed + appropriate cost.

Q3. Because quality is not simply reliability, it is about much more than software defects.

Q4. Trying to improve one quality attribute often degrades another. For example, attempts to improve efficiency often degrade modifiability.

Reliability

RE1. Error detection and removal accounts for roughly 40 percent of development costs. Thus it is the most important phase of the development life cycle.

RE2. There are certain kinds of software errors that most programmers make frequently. These include off-by-one indexing, definition or reference inconsistency, and omitting deep design details. That is why, for example, N-version programming, which attempts to create multiple diverse solutions through multiple programmers, can never completely achieve its promise.

RE3. Software that a typical programmer believes to be thoroughly tested has often had only about 55 to 60 percent of its logic paths executed. Automated support, such as coverage analyzers, can raise that to roughly 85 to 90 percent. Testing at the 100-percent level is nearly impossible.

RE4. Even if 100-percent test coverage (see RE3) were possible, that criteria would be insufficient for testing. Roughly 35 percent of software defects emerge from missing logic paths, and another 40 percent are from the execution of a unique combination of logic paths. They will not be caught by 100-percent coverage (100-percent coverage can, therefore, potentially detect only about 25 percent of the errors!).

RE5. There is no single best approach to software error removal. A combination of several approaches, such as inspections and several kinds of testing and fault tolerance, is necessary.

RE6. (corollary to RE5) Software will always contain residual defects, after even the most rigorous error removal. The goal is to minimize the number and especially the severity of those defects.

Efficiency

EF1. Efficiency is more often a matter of good design than of good coding. So, if a project requires efficiency, efficiency must be considered early in the life cycle.

EF2. High-order language (HOL) code, with appropriate compiler optimizations, can be made about 90 percent as efficient as the comparable assembler code. But that statement is highly task dependent; some tasks are much harder than others to code efficiently in HOL.

EF3. There are trade-offs between size and time optimization. Often, improving one degrades the other.

Maintenance

M1. Quality and maintenance have an interesting relationship (see Q3 and Q4).

M2. Maintenance typically consumes about 40 to 80 percent (60 percent average) of software costs. Therefore, it is probably the most important life cycle phase.

M3. Enhancement is responsible for roughly 60 percent of software maintenance costs. Error correction is roughly 17 percent. So, software maintenance is largely about adding new capability to old software, not about fixing it.

M4. The previous two facts constitute what you could call the “60/60″ rule of software.

M5. Most software development tasks and software maintenance tasks are the same—except for the additional maintenance task of “understanding the existing product.” This task is the dominant maintenance activity, consuming roughly 30 percent of maintenance time. So, you could claim that maintenance is more difficult than development.

Requirements and design

RD1. One of the two most common causes of runaway projects is unstable requirements. (For the other, see ES1.)

RD2. When a project moves from requirements to design, the solution process’s complexity causes an explosion of “derived requirements.” The list of requirements for the design phase is often 50 times longer than the list of original requirements.

RD3. This requirements explosion is partly why it is difficult to implement requirements traceability (tracing the original requirements through the artifacts of the succeeding lifecycle phases), even though everyone agrees this is desirable.

RD4. A software problem seldom has one best design solution. (Bill Curtis has said that in a room full of expert software designers, if any two agree, that’s a majority!) That’s why, for example, trying to provide reusable design solutions has so long resisted significant progress.

Reviews and inspections

RI1. Rigorous reviews commonly remove up to 90 percent of errors from a software product before the first test case is run. (Many research findings support this; of course, it’s extremely difficult to know when you’ve found 100 percent of a software product’s errors!)

RI2. Rigorous reviews are more effective, and more cost effective, than any other error-removal strategy, including testing. But they cannot and should not replace testing (see RE5).

RI3. Rigorous reviews are extremely challenging to do well, and most organizations do not do them, at least not for 100 percent of their software artifacts.

RI4. Post-delivery reviews are generally acknowledged to be important, both for determining customer satisfaction and for process improvement, but most organizations do not perform them. By the time such reviews should be held (three to 12 months after delivery), potential review participants have generally scattered to other projects.

Reuse

REU1. Reuse-in-the-small (libraries of subroutines) began nearly 50 years ago and is a well-solved problem.

REU2. Reuse-in-the-large (components) remains largely unsolved, even though everyone agrees it is important and desirable.

REU3. Disagreement exists about why reuse-in-the-large is unsolved, although most agree that it is a management, not technology, problem (will, not skill). (Others say that finding sufficiently common subproblems across programming tasks is difficult. This would make reuse-in-the-large a problem inherent in the nature of software and the problems it solves, and thus relatively unsolvable).

REU4. Reuse-in-the-large works best in families of related systems, and thus is domain dependent. This narrows its potential applicability.

REU5. Pattern reuse is one solution to the problems inherent in code reuse.

Estimation

ES1. One of the two most common causes of runaway projects is optimistic estimation. (For the other, see RD1.)

ES2. Most software estimates are performed at the beginning of the life cycle. This makes sense until we realize that this occurs before the requirements phase and thus before the problem is understood. Estimation therefore usually occurs at the wrong time.

ES3. Most software estimates are made, according to several researchers, by either upper management or marketing, not by the people who will build the software or by their managers. Therefore, the wrong people are doing estimation.

ES4. Software estimates are rarely adjusted as the project proceeds. So, those estimates done at the wrong time by the wrong people are usually not corrected.

ES5. Because estimates are so faulty, there is little reason to be concerned when software projects do not meet cost or schedule targets. But everyone is concerned anyway!

ES6. In one study of a project that failed to meet its estimates, the management saw the project as a failure, but the technical participants saw it as the most successful project they had ever worked on! This illustrates the disconnect regarding the role of estimation, and project success, between management and technologists. Given the previous facts, that is hardly surprising.

ES7. Pressure to achieve estimation targets is common and tends to cause programmers to skip good software process. This constitutes an absurd result done for an absurd reason.

Research

RES1. Many software researchers advocate rather than investigate. As a result, (a) some advocated concepts are worth less than their advocates believe and (b) there is a shortage of evaluative research to help determine the actual value of new tools and techniques.

There, that’s my two cents’ worth of software engineering fundamental facts. What are yours? I expect, if we can get a dialog going here, that there are a lot of similar facts that I have forgotten—or am not aware of. I’m especially eager to hear what additional facts you can contribute.

And, of course, I realize that some will disagree (perhaps even violently!) with some of the facts I’ve presented. I want to hear about that as well.

Robert L. Glass is the editor of Elsevier’s Journal of Systems and Software and the publisher and editor of The Software Practitioner newsletter. Contact him at rglass@indiana.edu; he’d be pleased to hear from you.

Reprinted from IEEE Software, vol. 18, no. 3, 2001, pp. 112, 110–111.

Segundo o decreto: “Toda AÇÃO FINALÍSTICA do governo federal deverá ser estruturada em programas orientados para a consecução dos objetivos estratégicos definidos para o período do plano”

Entende-se por ação finalística toda aquela que proporciona bem ou serviço para atendimento direto a demandas da sociedade.

Programas: Formulação e Seleção

Orientação (Prévia): de acordo com objetivos estratégicos e a previsão de recursos;

A formulação deve promover sempre que possível o DIP: Descentralização, Integração com Estados e Municípios e Parcerias com o Setor Privado.

Programas: Estabelecimento

1. Por Atos próprios de cada ente da federação;
2. Devem ser respeitados os conceitos definidos no âmbito federal (Portaria do MPOG);
3. A classificação funcional-programática deverá ser aperfeiçoada visando estimular a adoção, em todas as esferas de governo, do uso de gerenciamento por programas.

Programas: Conteúdo

1. Objetivo;
2. Indicador;
3. Metas;
4. Órgão Responsável;
5. Prazo de Conclusão;
6. Valor Global;
7. Fonte de financiamento;
8. Ações não-OGU (não integrantes do orçamento Geral da União);
9. Regionalização das Metas por Estado.

Quando houverem no programa ações predominantemente continuadas, deverão ser fixadas metas de qualidade e produtividade, dentro de prazos definidos.

Programas: Modelo de Gerenciamento

1. Uso de sistema informatizado de apoio ao gerenciamento (respeitando os conceitos a serem definidos em portaria do MPOG);
2. Deve ser realizado Controle de Prazos e de Custos;
3. Deve ser definida unidade responsável pelo gerenciamento;

Avaliação:

1. Deve ser realizada avaliação física e financeira dos Programas (Projetos/Atividades), de modo a aferir resultados, subsidiar a alocação de recursos e evitar a dispersão/desperdício;
2. Realização de avaliação anual da consecução dos objetivos estratégicos do Governo Federal e do resultado dos programas, com o objetivo de subsidiar a elaboração da lei de diretrizes orçamentárias de cada exercício;
3. Quando cabível, deve ser realizada avaliação de satisfação da sociedade.

HISTÓRICO:

A evolução histórica do Orçamento Público passa pela Inglaterra, em 1217, através da Magna Carta do Rei João Sem Terra. Através dela o poder de tributar do reino estava limitado, tendo impacto direto no volume da receita pública.

Em seguida, a edição da `Petition of Rights` o parlamento trouxe para si a responsabilidade de determinar a legitimidade de um tributo.

Com a criação da lei do fundo consolidado em 1787, foi disciplinado o processo autorizativo das receitas e despesas públicas, inclusive com a publicação de relatório anual detalhado.

Em 1822 passa a ser necessário que o Chanceler do Erário apresente ao parlamento o orçamento da receita e despesa pública no exercício. Coube então ao parlamento a tarefa de aprovar o orçamento e fiscalizar sua execução.

TIPOS DE ORÇAMENTO:

Orçamento Tradicional: O foco dessa modalidade de orçamento está nos Insumos (Objetos)

Orçamento de Desempenho: No orçamento de desempenho são contemplados não só os Insumos, mas também os produtos por ele gerados.

Orçamento Programa: O orçamento programa possui foco no planejamento, além de contemplar os insumos e produtos.

O orçamento tradicional difere do orçamento programa (moderno) quanto à função, aos critérios de classificação e o tipo de controle.

No ORÇAMENTO TRADICIONAL:

• Função: Controle Político;
• Critérios de Classificação da Despesa: Unidade Administrativa (QUEM) e Elementos de despesa (Objetos – O QUÊ);
• Tipo de Controle: Quanto à legalidade.

No ORÇAMENTO PROGRAMA (MODERNO):

• Função: Instrumento de Administração;
• Critério de Classificação: Funcional-Programático (em qual função estou gastando? em qual programa de governo?)
• Tipo de Controle: Quanto à eficiência, eficácia e efetividade.

ORÇAMENTO BASE ZERO X INCREMENTALISMO

Entende-se como Orçamento Base Zero aquele em que inexistem direitos adquiridos. Nele, o gestor deve sempre justificar a necessidade da despesa para um novo exercício. O gestor deve propor PACOTES DE DECISÃO em três níveis de esforço para despesa solicitada: Um nível MÍNIMO; Um nível CORRENTE (para manter a dada função como está); Um nível de EXPANSÃO.

O orçamento base zero contrapõe-se frontalmente ao Incrementalista, haja vista que o Incrementalista permite direitos adquiridos, fazendo com que o orçamento do exercício seguinte seja sempre:

ORÇAMENTO PARA O EXERCÍCIO ATUAL = ORÇAMENTO PARA O EXERCÍCIO ANTERIOR + INCREMENTO

RIGIDEZ ORÇAMENTÁRIA (BRASIL)

O Conceito de Rigidez orçamentária no Brasil decorre do fato de haver Nível elevado de vinculações às receitas do país, aliados à nível elevado de despesas obrigatórias. Isso implica em um orçamento rígido, com pouca margem de trabalho e poucas possibilidades de melhorias mais amplas.

Função Alocativa: tem como objetivo o provimento de BENS, sejam eles públicos, privados ou semi-públicos. É importante entender que o intuito é PROVER, não necessariamente PRODUZIR.

Função Distributiva: tem como objetivo (re)distribuir a RENDA, seja através de impostos ou de transferências (como o Bolsa Família).

Função Estabilizadora: atua na esfera ECONÔMICA, de modo a modificar os resultados e desempenho de economia. Políticas que modifiquem o PIB, a Inflação, o Desemprego e o Balanço de Pagamentos são ditas estabilizadoras. Em geral podem dividir-se em Expansionista e Contracionista. Na primeira o estado abre mão de parte de suas receitas e aumenta suas despesas, com o intuito de aquecimento econômico (como foi feito na crise econômica deflagrada em 2008/2009). Na segunda, há um notório ajuste fiscal, com aumento das receitas e diminuição de despesas.