Tuesday, September 07, 2010

Algumas Considerações Sobre Gerenciamento de Projetos

A primeira coisa que deve-se perguntar é: porque um projeto? De onde surge? Um projeto surge da necessidade ou desejo de se resolver um problema ou aproveitar uma oportunidade.


Como identificar o ponto onde estamos e o ponto onde vamos chegar? Diria que o mais difícil é ideintificar o ponto onde estamos.


Com esses pontos claramente definidos, pode-se aplicar uma metodologia para se alcançar os resultados esperados.



Um ponto importante, mas no geral esquecido pelos gestores ou gerentes de projeto, é a aderência do projeto a(s) estratégia(s) da empresa. Se o seu projeto não for aderente o sufuciente, a chance dele chegar ao final é pequena. A chance dos beneficios serem visiveis é menor ainda.




Mas afinal o que é um projeto? 

"Um projeto  é um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo".
PMBOK, 2008

Ciclo básico de um projeto se originou a partir do cliclo básico de gestão, no qual todos já ouvimos falar, mas poucos de nós conseguimos de fato utilizar na prática.





Mesmo quando tem-se uma visão clara de um projeto, surge a necessidade de gerenciamento do gerenciamento de projetos. Com isso surge a hierarquia.



O PMBOK apresenta 9 áreas de conhecimento relacionadas ao gerenciamento de projetos. Essas áreas foram catalogadas no corpo de conhecimento conhecido como PMBOK, atualmente na versão 4 de 2008.

Gerenciamento da Comunicação
Gerenciamento de Riscos
Gerenciamento de Aquisições
Gerenciamento de Tempo
Gerenciamento de Custos
Gerenciamento de Escopo
Gerenciamento de Qualidade
Gerenciamento de Recursos Humanos
Gerenciamento de Integração


Hacker in Action

Não se se é fake, mas nos faz lembrar de 2 fatos que quase sempre são esquecidos:

- segurança
- e a capacidade que nós, técnicos, temos de mudar o mundo



Enjoy!

Sunday, September 05, 2010

Atividades em Processos

• Atividades que agregam valor são atividades que, aos olhos do consumidor final, agregam valor ao produto ou serviço. Ou seja, atividades pelas quais o consumidor ficaria satisfeito em pagar;
• Atividades desnecessárias que não agregam valor são atividades que, aos olhos do consumidor final, não agregam valor ao produto ou serviço e que são desnecessárias em qualquer circunstância. Estas atividades são nitidamente desperdícios e devem ser eliminadas a curto e médio prazo;
• Atividades necessárias que não agregam valor são atividades que, aos olhos do consumidor final, não agregam valor ao produto ou serviço, mas que são necessárias. Trata-se de desperdícios difíceis de serem eliminados em curto prazo e que, portanto, necessitam de um tratamento em longo prazo, ao menos que sejam submetidos a um processo de transformação radical. O setup é um exemplo.



Enjoy!

Hieraquia de Processo

Um processo, para Davenport (1994), é uma ordenação específica das atividades de trabalho no tempo e no espaço, com um começo, um fim, inputs e outputs claramente identificados, enfim, uma estrutura para ação. Já Harrington (1993) o define como sendo um grupo de tarefas interligadas logicamente, que utiliza os recursos da organização para gerar os resultados definidos, de forma a apoiar os seus objetivos. Para Johansson (1995), processo é o conjunto de  aividades ligadas que tomam um insumo (input) e o transformam para criar um resultado (output). Johansson (1995) também destaca que a compreensão do processo é importante pois representa a chave para o sucesso em qualquer negócio. Afinal, uma organização é tão efetiva quanto os seus processos, sendo eles responsáveis pelo que será ofertado ao cliente. Neto (1994) diferencia processos fundamentais ou primários dos processos de apoio, estabelecendo a classificação da seguinte forma:

• Processos primários: são aqueles que tocam o cliente. Qualquer falha, o cliente logo identifica;
• Processos de apoio: são os que colaboram com os processos primários na obtenção do sucesso junto aos clientes;
• Processos gerenciais: são aqueles que existem para coordenar as atividades de apoio e os processos primários.

Harrington (1997) aponta para uma hierarquia que caracteriza o sistema, partindo de uma visão global para uma visão pontual:

• Macroprocesso: é um processo que geralmente envolve mais de uma função na estrutura organizacional, e sua operação tem um impacto significativo no modo como a organização funciona;
• Processo: é um conjunto de atividades seqüenciais (conectadas), relacionadas e lógicas, que tomam um input com um fornecedor, acrescentam valor a este e produzem um output para um consumidor;
• Subprocesso: é a parte que, inter-relacionada de forma lógica com outro subprocesso, realiza um objetivo específico em apoio ao macroprocesso e contribui para a missão deste;
• Atividades: são ações que ocorrem dentro do processo ou subprocesso. São geralmente desempenhadas por uma unidade (pessoa ou departamento) para produzir um resultado particular. Elas constituem a maior parte dos fluxogramas;
• Tarefa: é uma parte específica do trabalho, ou melhor, o menor enfoque do processo, podendo ser um único elemento e/ou um subconjunto de uma atividade.

Além disto, todo o processo, atividade, tarefa ou procedimento, segundo Cruz (1998), possui ainda um tempo de ciclo, que é o tempo necessário para a sua execução, sendo composto por tempos de início, meio e fim de uma parte executável. Estes tempos podem variar em função de uma série de fatores e comprometer a eficiência do processo, além da produtividade e a lucratividade da organização.

Enjoy!

Taxonomia para Serviços

As quatro categorias mais utilizadas são:
• Mass Service (alta intensidade de mão de obra, baixa customização)
• Service Factory (baixa intensidade de mão de obra, baixa customização)
• Service Shop (baixa intensidade de mão de obra, alta customização)
• Professional Service (alta intensidade de mão de obra, alta customização)

A categoria service factory caracteriza-se por ser análoga a processos do tipo linha de montagem de manufatura, onde o valor de instalações e equipamentos corresponde a uma fração muito grande dos custos totais. Muitas indústrias de transporte (linhas aéreas, companhias de transporte), hotéis e fast food

Já a categoria service shop caracteriza serviços com baixa intensidade de mão de obra mas com alto contato e customização com o cliente. Semelhante a um trabalho em loja, o service shop pode prover serviços variados para seus clientes. Hospitais e auto-reparadores são alguns exemplos de serviços do tipo loja (Fitzsimmons e Fitzsimmons, 2000).

Mass service são serviços caracterizados através da alta intensidade de mão de obra e baixo contato/customização com cliente. Companhias de varejo,  atacadistas e escolas são exemplos de serviço de massa.

A categoria professional service caracteriza serviços que envolvem um alto grau de contato/customização com os clientes como também um alto grau de intensidade de mão de obra. Serviços de médicos, advogados, contadores e arquitetos têm um grau muito alto de intensidade de mão de obra devido à grande quantidade de especialização associada com estas profissões. Além disto, estes serviços tendem a ser altamente customizados de acordo com a necessidade particular de cada cliente.





Enjoy!

Produto ou Serviço?

Você imagina um software como produto ou como serviço? Difícil classificação. Olhe a figura abaixo e procure alguma semelhança.



Enjoy!

Representação dos Diagramas da UML 2.0

Taxonomia dos Requisitos Não Funcionais

Fluxo de atividades para modelagem de negócio aplicado na fase de elaboração do UP

Fluxo de atividades para modelagem de negócio aplicado na fase de concepção do UP

O UP divide-se em quatro fases (levantamento de requisitos, análise, projeto, implementação e teste) e possui workflows (fluxos de atividades) que são executados em todas as fases, mas com características diferenciadas em cada uma delas. As atividades de levantamento de requisitos acontecem em todas as fases do desenvolvimento, tendo maior ênfase nas fases de Concepção e de Elaboração. Aplicando a técnica de Eriksson e Penker (2000) ao UP através da criação de workflows completos para a modelagem de negócio (inexistente na versão original do UP).

 

Enjoy!

Friday, September 03, 2010

Geração X e Y [resumido]

Muito do nosso trabalho é guiado por teorias fundamentadas há muito tempo atrás. Compreende-los nos faz entender porque certas situações são como são. Provavelmente você já deve ter ouvido falar na "Geração Y", isso provavelmente lhe soa como algo bom. Mas você sabe de onde vem isso?

Enjoy!

Construindo aplicações web de missão crítica

1.Use pool de conexões para read e write

2.Reduza a quantidade de acesso ao banco de dados

3.Reduza o tamanho das páginas da aplicação

4.Melhore o mecanismo de sessão da aplicação

5.Utilize cache de banco de dados

6.Utilize ambiente transacional de verdade

7.Utilize lock otimista

8.Crie um cluster do conteiner web

9.Crie um load balancer do conteiner web

10.Crie replicas do banco de dados e isole o banco de transação

11.Escalone o banco de dados de leitura

12.Utilize corretamente a memória do servidor de aplicação

13.Utilize corretamente os recursos de rede

14.Evite submissões demasiadas

15.Use segurança somente quando necessário

16.Use processamento em batch quando necessário

17.Use controladores bem delimitados

18.Use post somemete para POST

19.Use arquiterura escalonavel

20.Melhore a performance do banco de dados

21.Melhore a perfomance do conteiner web

22.Utilize padrões de projeto

23.Não use PDFs demasiadamente

Enjoy!

Thursday, September 02, 2010

PMBOK - Gerenciamento de Comunicação

Um início promissor para qualquer projeto é, tão logo tenha sido designado o seu gerente (também chamado de líder do projeto, coordenador do projeto, dentre outros nomes) e tenha sido concluída a fase de planejamento organizacional, obter: 1) a lista de todas as partes envolvidas no projeto; 2) a Matriz de Designação de Responsabilidades (normalmente uma tabela onde se relacionam nas colunas as pessoas participantes e nas linhas as principais fases do projeto, e preenchese a matriz resultante, indicando responsabilidades como: participa, responde, revisa, aprova); e 3) a lista da equipe designada para o projeto.


Dificuldades em se comunicar durante seu projeto? Para isso, existem práticas recomendadas pelos profissionais de gerenciamento de projeto e no PMBOK (PMI, 2002) que devem ser implementadas, pois serão muito úteis para garantir o engajamento de todos e para o controle efetivo das atividades do projeto. Nos eventos com as interações presenciais recomendase desenvolver:

• Reunião de pontapé inicial - essa reunião é fundamental para que todos se conheçam, para que se apresentem os procedimentos gerais que deverão ser utilizados no dia-a-dia do projeto e o resumo geral do plano do projeto. A idéia é combinar, desde o início, como as partes envolvidas irão trabalhar, com a maior satisfação possível, focadas nos objetivos do projeto.

• Reuniões de acompanhamento - são reuniões marcadas periodicamente para que se troquem informações sobre o projeto. Nelas é que são discutidos e resolvidos os problemas técnicos relativos ao desenvolvimento de cada um dos produtos que devem ser entregues nas sucessivas etapas do projeto, até que este seja concluído. Essas reuniões muitas vezes são realizadas em grupos por especialidade, quando o projeto é de grande porte.

• Reuniões de progresso do projeto - também conhecidas como reuniões de revisão de desempenho, essas reuniões não devem discutir como as entregas parciais (produtos ou serviços) do projeto foram executadas (isso já deve ser sabido), mas devem focar-se na averiguação quanto à execução destas dentro do  planejamento de prazos, recursos, custos, qualidade e riscos. Ou seja, ela deve ser direcionada para o trabalho que está sendo feito para entregar os produtos ou serviços avaliados nas reuniões de acompanhamento. Por isso, nessas reuniões (que devem ser rápidas) não se ficam contando os “causos” que ocorreram ao executar os trabalhos, mas procurase analisar o desempenho da execução, tratando dos desvios – como os serviços se desviaram do planejado quanto ao prazo, ao custo, à qualidade, ao risco –, e das tendências – se o desempenho atual for mantido, quais serão os resultados? Qual é a expectativa de data de término real, de custo final do projeto, da qualidade do produto ou serviço que será gerado?

São recomendados para uso na gestão das comunicações do projeto pelo Guia do Conjunto de Conhecimentos do Gerenciamento de Projetos – PMBOK (PMI, 2002), os seguintes instrumentos ou procedimentos:

• Relatórios de desempenho - são relatórios que resumem, de modo organizado, as informações de desempenho do projeto, dando ênfase a informações sobre desvios (compara o que ocorreu com o que devia ter ocorrido segundo o plano do projeto) e sobre as tendências do projeto. É um documento fundamental para as reuniões de progresso do projeto.

• Solicitações de mudança - são documentos que apresentam as solicitações de mudança ou de alterações, tanto nos produtos ou serviços a serem entregues durante o projeto, como no trabalho a ser desenvolvido para entregar esses produtos ou serviços. Essas solicitações, por mostrar de forma organizada e sintética o que se está pretendendo mudar, ajudam a que se tenham evidências mais estruturadas para decidir se de fato vale a pena mudar. Isso porque toda mudança geralmente causa impacto no prazo, no custo, na qualidade e na moral da equipe que desenvolve o projeto.

• Quadro das informações distribuídas no período - é recomendável disponibilizar para todos os participantes do projeto (preservando aspectos de confidencialidade, quando for o caso) a lista de todos os Registros do Projeto, todos os Relatórios do Projeto e todas as Apresentações do Projeto que foram distribuídas no último período. Além da transparência que propicia, este quadro permite aos participantes que identifiquem ocorrências de bloqueios nos canais de comunicação, uma vez que, ao ficar sabendo que uma informação que não chegou tinha de fato sido disponibilizada, é possível agir para sanar o problema.

Para aprimorar continuadamente a gestão de projetos é fundamental que ao final de cada etapa de trabalho, ou a cada entrega de um produto ou serviço intermediário, aproveite-se a oportunidade para:

• Organizar os arquivos do projeto relativos àquela fase (acervo do projeto), etapa ou produto/serviço intermediário que está sendo entregue - isso significa separar o que deve ser guardado de modo organizado e o que deve ser descartado. Montar os arquivos com índices, formas de recuperação e de empréstimo, pelo menos. Em suma: montar um banco de dados do projeto, não deixando que os arquivos virem apenas um “bando de dados” do projeto.

• Obter a aceitação formal do cliente - para cada entrega intermediária ou para a entrega final – essa prática é fundamental para que não ocorra um problema típico de projetos: o cliente não se pronuncia quanto à aceitabilidade ou não das entregas intermediárias, e com isso vaise acumulando uma enorme quantidade de itens que serão cobrados por ele no final, quando o prazo já está praticamente esgotado, e os recursos de pessoal e dinheiro, quase todos gastos. É como deixar que uma bomba seja gradualmente montada para explodir próxima à data de entrega do projeto.

• Levantar as lições aprendidas - quando é entregue ao cliente algum produto ou serviço intermediário importante, os participantes do projeto devem ser reunidos para analisar como o trabalho foi desenvolvido e procurar aprender a partir dos erros e acertos. Esse tipo de reunião não tem o espírito de caça aos culpados, mas, bem ao contrário, tem o propósito de identificar tudo o que foi feito de bom para fazer o trabalho futuro ser ainda melhor. É comum buscar, como resultado dessa reunião, o entendimento do que não se faria de novo, o que certamente se faria novamente, o que deverá ser proposto como melhor prática para a empresa, bem como o que deve ser recomendado como práticas a serem evitadas.

• Rever e atualizar o planejamento das comunicações - fixar um procedimento para rever, atualizar e refinar o plano das comunicações do projeto, pois, como qualquer projeto é uma empreitada de risco e repleto de novidades e mudanças, o plano de comunicações deve acompanhar toda essa dinâmica. Convém determinar a periodicidade com que esse plano será revisado, independentemente de revisão sob demanda.

Nos projetos em que não se pode errar, não há mais espaço para gerentes e equipes executoras que acreditam que as pessoas irão “naturalmente” criar e operar seus canais de comunicação com os outros membros do projeto, inclusive parceiros e fornecedores externos: isso infelizmente não ocorre via geração espontânea. A comunicação adequada entre as partes envolvidas em um projeto é fator fundamental para seu sucesso e exige o uso de instrumentos adequados.

"Quando o assunto é para ser tratado por muita gente e deve ser continuamente utilizado por todas elas, não há lugar para “regras do jogo” não escritas."

Tuesday, August 31, 2010

NBR ISO/IEC 12207 – Processos de Ciclo de Vida de Software

A Norma NBR ISO/IEC 12207 - Processos do Ciclo de Vida do Software foi criada em 1995 com o objetivo de fornecer uma estrutura comum para que o adquirente, fornecedor, desenvolvedor, mantenedor, operador, gerentes e técnicos envolvidos com o desenvolvimento de software utilizem uma linguagem comum. Esta linguagem comum é estabelecida na forma de processos bem definidos. Esses processos são classificados em três tipos: fundamentais, de apoio e organizacionais representado na Ffgura abaixo. Todos esses processos, executados durante o projeto de software, conduzem a qualidade tanto do produto quanto do processo. Devido à própria evolução da área de engenharia de software e da necessidade sentida por vários usuários da Norma, está sendo disponibilizado em 2001 um anexo que atualizará a Norma incluindo e expandido processos.


Enjoy!

Monday, August 30, 2010

Dificuldades com seus Projetos de IHC?

http://www.labiutil.inf.ufsc.br/ergolist/

Enjoy!

Mecanismos Arquiteturais

Example Architectural Mechanisms
Architectural Mechanism Description
Availability The percentage of time that the system must be available for use, including planned outages.
Archiving Provides a means to move data from active storage when it has reached a specific state.
Auditing Provides audit trails of system execution.
Communication A mechanism for handling inter-process communication.
Debugging Provides elements to support application debugging.
Disaster Recovery Provides facilities to recover systems, application, data and networks.
Error Management Allows errors to be detected, propagated, and reported.
Event Management Supports the use of asynchronous events within a system.
Graphics Supports user interface services, such as 3D rendering.
Information Exchange Supports information interchange accross technical and organisational boundaries, with appropriate semantic and format translations.
Licensing Provides services for acquiring, installing, tracking, and monitoring license usage. Might be required as part of authorising corporate bodies.
Localisation / Internationalisation Provides facilities for supporting multiple human languages and rendering the language preffered by the user.
Mail Services that allow applications to send and receive electronic mail.
Mega-data Support for handling very large amounts of data.
Memory Management Services for abstracting how memory is allocated and freed.
Meta-data Supports the runtime introspection of components and data.
Online help Provides online help capability
Persistence Services to handle the reading and writing of stored data.
Printing Provides facilities for interfacing with printers.
Process Management Provides support for the management of processes and threads.
Reporting Provides flexible reporting facilities
Resource Management Provides support for the management of expensive resources, such as database connections.
Scheduling Provides the ability to execute tasks at a specified time.
Security Provides services to protect access to certain resources or information.
System Management Services that facilitate management of applications in an operational environment.
Time Services to synchronise time on a network, and to translate times into different time zones.
Transaction Management A mechanism for handling ACID transactions.
Workflow Support for the movement of documents and

Podem possuir 3 estados:


 Enjoy!

Sunday, August 29, 2010

PO Darth Vader

Em projetos Ágeis o ScrumMaster é responsável por garantir o processo e que as práticas Scrum sejam seguidas. Já o ProductOwner(PO) é responsável pelo produto e pelo ROI do projeto, isto faz que o papel de PO seja um fator critico de sucesso. O PO deve trabalhar totalmente alinhado e integrado com o time para que o ROI seja alcançado.

Principais características desejáveis e as indesejáveis:

Desejáveis (obrigatórias)
- Saber entender a necessidade do cliente e usuários;
- Ter habilidade para criar, manter e comunicar a visão do produto;
- Entender o que é valor para o cliente;
- Ser Líder e Facilitador;
- Ter poder decisão sobre o projeto;
- Ser comprometimento com cliente, projeto e com a equipe;
- Manter um bom relacionamento com stakeholder;

Indesejáveis: 
- Ser uma pessoa sem tempo; 
- Ser adepto do micro-gerenciamento (comando controle) (Darh Vader);
- Não conhecer o produto ou negócio;
- Falta de coragem para tomar decisão sobre o projeto;
- Inabilidade técnica;
- Falta de conhecimento do SCRUM;
- Visão mal definida ou incompleta;
- Ter um ProductBacklog mal priorizado;



Enjoy!

Som de Algoritmos de Ordenação




Agora sei o que o R2D2 falava!

Enjoy!

Scrum - Product Backlog

Scrum é um framework (e não metodologia) interativo e incremental para gerenciamento de projetos e desenvolvimento ágil de software.




O product backlog é o coração do Scrum. É aqui que tudo começa. O product backlog é basicamente uma lista de requisitos, estórias, Coisas que o cliente deseja, descritas utilizando a terminologia do cliente. Nós as chamamos de estórias, ou algumas vezes apenas de itens do backlog. Nossas estórias incluem os seguintes campos:
 * ID – Uma identificação única, apenas um número com autoincremento. Isso é para evitar que percamos o controle sobre as estórias quando nós mudamos seus nomes.
 * Nome – Um nome curto e descritivo para a estória. Por exemplo, “Ver o histórico de transações”. Suficientemente claro para que os desenvolvedores e o product owner entendam mais ou menos sobre o que estamos falando, e claro o bastante para distingui-la das demais estórias. Normalmente de 2 a 10 palavras.
 * Importância – a pontuação de importância dessa estória para o product owner. Por exemplo 10. Ou 150. Mais pontos = mais importante. Eu tento evitar o termo “prioridade” já que prioridade 1 é tipicamente interpretado como “prioridade mais alta”, o que fica feio se mais tarde você decidir que algo é ainda
mais importante. Qual pontuação de prioridade esse item deveria receber? Prioridade 0? Prioridade -1?
 * Estimativa inicial – As estimativas iniciais da equipe sobre quanto tempo é necessário para implementar aquela estória, se comparada a outras estórias. A unidade é pontos por estória e geralmente corresponde mais ou menos a “relação homem/dias” ideal.
1. Pergunte à equipe “se vocês puderem ter o número ideal de pessoas para esta estória (nem muitas, nem
poucas, normalmnte duas), e se trancarem em uma sala cheia de comida e trabalharem sem distúrbio algum, após quantos dias vocês apresentarão uma implementação pronta, demonstrável e testada? Se a resposta for “com 3 pessoas trancados em uma sala levará aproximadamente 4 dias” então a estimativa inicial é de 12 pontos por estória. 
2. O importante não é ter estimativas absolutamente precisas (por exemplo, dizer que uma estória com 2 pontos deverá gastar 2 dias), mas sim obter estimativas relativas corretas (por exemplo, dizer que uma estória com 2 pontos gastará cerca da metade de uma estória com 4 pontos).
 * Como demonstrar – Uma descrição em alto nível de como a estória será demonstrada na apresentação do sprint. Isso é simplesmente uma simples especificação de teste. “Faça isso, então faça aquilo e então isso deverá acontecer.” o Se você pratica TDD (desenvolvimento orientado a testes) essa descrição pode ser usada como pseudocódigo para o seu código de teste de aceitação. 
 * Notas – quaisquer outras informaçòes, esclarecimentos, referências a outras fontes de informação, etc.   Normalmente agil bem breve.

Como todos os demais aterfatos, coloque no repositório de versionamento.

Enjoy!

Gerenciamento de Projetos

Ronnie Maschk sobre gerenciamento de projetos.


Enjoy!

Friday, August 27, 2010

O que é Análise de Negócio (segundo o Guia BABok) ?

“Análise de Negócio é o conjunto de tarefas e técnicas utilizadas para o trabalho como um elo de ligação entre todas as partes interessadas (stakeholders), a fim de compreender a estrutura, as políticas e operações de uma empresa e para recomendar soluções que permitam a empresa a alcançar seus objetivos”.
Análise de Negócio envolve entendimento de como as organizações realiza os seus propósitos e definindo as capacidades que uma empresa requer para fornecer produtos e serviços para seus os clientes (ou stakeholders externos). Inclui a definição de metas, o modo como esses objetivos conectam com objetivos mais específicos, a determinação dos planos de ação que uma organização tem de comprometer-se para atingir esses objetivos e metas e estabelecer a forma como as diferentes unidades de negócio e as partes interessadas internas e externas (stakeholders internos e externos), se interagem. Análise de Negócio pode ser feita para entender o cenário atual de empresa ou servir como base para identificação das necessidades de negócio. Em muitas casos, porém, Análise de Negócio, é feita para definir e validar as soluções que satisfaçam as necessidades de negócio, metas ou objetivos. Análise de Negócio deve avaliar e sintetizar as informações que são fornecidas por todas as pessoas que interagem com o negócio, tais como clientes, pessoal de Staff, fornecedores, pessoal de TI, executivos e etc. O Analista de Negócio é responsável por obter as reais necessidades das partes interessadas, não apenas os seus desejos expressos. Em muitos casos, o Analista de Negócio atuará como facilitador da comunicação entre as unidades de negócio. Um exemplo de atuação do Analista de Negócio como facilitar, é no alinhamento das necessidades das unidades de negócio com os serviços entregues pela TI (Tecnologia da Informação). Análise de Negócio pode ser feita para entender o cenário atual de empresa ou servir como base para identificação das necessidades de negócio. Em muitas casos, porém, Análise de Negócio, é feita para definir e validar as soluções que satisfaçam as necessidades de negócio, metas ou objetivos. Um Analista Negócio é qualquer pessoa que exerça atividades de Análise de Negócio, não importando qual seja seu cargo, função ou papel. A Análise de Negócio profissional não incluem apenas as pessoas com o cargo Analista de Negócios, ela também pode incluir Analista de Sistemas, Analista de Requisitos, Engenheiro de Sistemas Corporativo, Analista de Processo, Analista de Produto, Gerente de Produto, Product Owner (SCRUM), Arquitetos de Solução Corporativa, Consultores de Gestão ou qualquer outra pessoa que execute as tarefas descritas no Guia BABok® , incluindo aqueles que exercem também disciplinas relacionadas, tais como Gerenciamento de Projeto, Desenvolvimento de Software, Garantia de Qualidade e etc.

Enjoy!

Wednesday, August 25, 2010

O Relojoeiro Cego

"Por razões que não me são inteiramente claras, o darwinismo parece ter maior necessidade de defesa do que outras verdades igualmente bem estabelecidas de outros ramos das ciências. Muitos de nós não entendemos nada de física quântica ou das teorias de Einstein sobre relatividade especial e geral, mas isso não nos leva a fazer oposição a essas teorias! Mas o darwinismo, ao contrário do "einsteinismo" parece ser visto como legítimo saco de pancadas por críticos de todos os graus de ignorância. Suponho que um dos problemas do darwinismo, como bem observou Jacques Monod, é que todos pensam entendê-lo. Com efeito, tratase de uma teoria notavelmente simples - pensando bem, até mesmo infantil em comparação com quase todas as teorias da física e da matemática. Essencialmente, ela se resume à idéia de que a reprodução não aleatória, conjugada à variação hereditária, terá conseqüências de grande alcance uma vez que estas tenham tempo para ser cumulativas. Mas temos boas razões para crer que essa simplicidade é enganadora. Vale lembrar que, por mais simples que ela pareça, ninguém pensou nessa teoria antes de Darwin e Wallace, em meados do século XIX, quase duzentos anos depois dos Princípios de Newton e mais de 2 mil anos depois que Eratóstenes mediu a Terra. Como é possível que uma idéia tão simples não tenha sido descoberta por pensadores do calibre de Newton, Galileu, Descartes, Leibniz, Hume e Aristóteles? Por que ela teve de esperar por dois naturalistas vitorianos? O que havia de errado com os filósofos e matemáticos que a deixaram escapar? E como pode ser que uma idéia tão poderosa ainda seja tão estranha aos olhos do grande público? É quase como se o cérebro humano tivesse sido especificamente concebido para não entender o darwinismo, para achá-lo inacreditável. Tome-se como exemplo a questão do "acaso", tantas vezes melodramaticamente adjetivado como acaso cego. A maioria das pessoas que atacam o darwinismo agarra-se com avidez indecorosa à idéia errônea de que nele tudo é acaso e aleatoriedade. Uma vez que a complexidade dos seres vivos encarna a própria antítese do acaso, obviamente quem pensar que o darwinismo se resume ao acaso não terá dificuldade em refutá-lo! Uma das minhas tarefas será destruir o mito sofregamente acalentado de que o darwinismo é uma teoria do "acaso". Outro fator que talvez nos predisponha a não acreditar no darwinismo está em nosso cérebro, que foi feito para lidar com eventos em escalas de tempo radicalmente diferentes daquelas que caracterizam a mudança evolutiva. Estamos equipados para observar processos que se desenrolam em segundos, minutos, anos ou, no máximo, décadas. O darwinismo é uma teoria de processos cumulativos tão lentos que se desenrolam ao longo de milhares e milhões de anos. Todos os nossos juízos intuitivos sobre o que é provável mostram-se errados por larga margem. Nosso refinado instrumental de ceticismo e teoria da probabilidade subjetiva erra tanto o alvo justamente por ser calibrado - ironicamente, pela própria evolução para atuar no âmbito de algumas décadas. Escapar da prisão dessa escala de tempo familiar requer um esforço de imaginação."

- Richard Dawkins

Enjoy!

Monday, August 23, 2010

Abordagem Orientada a Modelos de Processos de Negócio

Abordagem Convencional

A engenharia de requisitos consiste em “um processo sistemático de desenvolvimento de requisitos através de um processo iterativo de análise do problema, documentação das observações resultantes e verificação acerca da precisão de entendimento” [1]. É uma atividade cujo sucesso depende diretamente da realização de uma comunicação eficaz. Diante disto, consideramos a modelagem de processos de negócio como técnica para facilitar a comunicação entre clientes e analistas. Abordagem Convencional de Engenharia de Requisitos A primeira técnica empregada na elicitação de requisitos é denominada abordagem convencional neste artigo, pois não emprega a modelagem de processos como ferramenta. Esta técnica descrita a seguir é embasada por referências pertencentes à documentos privados da companhia na qual a experiência desenvolveu-se. A tabela 1 mostra as fases deste processo, assim como os produtos gerados ao término de cada uma.


Abordagem Orientada a Modelos de Processos de Negócio

A abordagem de engenharia de requisitos orientada a modelos de processos de negócio se diferencia da abordagem denominada convencional pela inclusão de uma etapa de formalização explícita dos processos de negócios que serão apoiados ou geridos pelo sistema em desenvolvimento. Esta etapa visa facilitar a compreensão do ambiente organizacional no qual o sistema será usado e fornece subsídios para a adequação dos requisitos com os objetivos organizacionais.
A técnica de modelagem de processos empregada inicia-se pelo mapeamento da cadeia de valor organizacional que representa todos os macro-processos realizados para a concretização das estratégias organizacionais. O refinamento de macro-processos leva a cadeias de processos que representam os procedimentos coorporativos. Quando os processos atingem seu maior nível de refinamento, é possível a construção do modelo de atividades. No modelo de atividades, é possível então atribuir recursos próprios à execução destas ações atômicas.

Engenharia de Requisitos Orientada a Modelos de Processos de Negócio

Após a etapa de formalização dos processos de negócio, a etapa de engenharia de requisitos utiliza os modelos para a geração de seus respectivos requisitos de sistema. Na análise do processo podem ser identificados três conjuntos de atividades. O primeiro conjunto consiste nas atividades não passíveis de automatização, tais como certas atividades operacionais exclusivamente realizadas por atores humanos. O segundo conjunto consiste nas atividades que podem ser apoiadas por sistemas, enquanto o terceiro conjunto refere-se àquelas totalmente automatizáveis, ou seja, que podem ser realizadas por sistemas sem intervenção humana. A distribuição das atividades nos três grupos acima citados é realizada conjuntamente entre o cliente e o analista de sistemas e deve levar em consideração uma série de fatores dentre os quais podemos citar políticas da organização, leis, restrições tecnológicas, restrições de segurança, dentre outros. Dessa forma, deste ponto de vista, a utilidade do modelo de processos do negócio reside no fato de que ele é fonte de subsídios para descoberta dos serviços a serem prestados pelo sistema. A figura abaixo representa esquematicamente a relação entre um modelo de processos e uma gama de conjuntos de requisitos para sistemas que podem suportar este processo, cada conjunto de requisitos correspondendo um diferente conjunto de escolhas de nível de automatização das atividades deste processo. Nesta figura o modelo de processos é considerado o ponto de partida para o esforço de engenharia de requisitos, que envolve os stakeholders do sistema. A partir do mesmo modelo de processos é possível obter um conjunto de requisitos R1 para um sistema S1 que irá apoiá-lo, ou ainda obter um conjunto de requisitos R2 para um sistema S2 que possui um nível maior de automatização. Caminhando-se na escala de soluções, no limite da automatização, a escolha do conjunto de requisitos RN referente ao sistema SN também é viável e consiste no maior nível de automatização para o processo. A escolha de qual sistema será utilizado deve ser uma decisão consciente na qual considerado o equacionamento de fatores diversos tais como segurança, custo de desenvolvimento do sistema, dentre outros. Cabe ressaltar que a menção do termo nível de automatização, no texto, refere-se às atividades que podem ter sua execução suportada por certos sistemas que lhes provêem mecanismos de acompanhamento ou podem ser atividades cuja automatização é totalmente realizada por sistemas.










Neste momento, após a escolha mais adequada do sistema no suporte do processo e a divisão das atividades nas três categorias acima mencionadas, os requisitos podem ser elicitados a partir das atividades previamente escolhidas. Todo o procedimento acima descrito corresponde à fase de análise de requisitos e de regras relacionados ao processo e pode ser executado a partir da metodologia acima descrita. Neste momento, ocorre a transição dos modelos conceituais (relacionados com os processos em alto nível) para os modelos lógicos (relacionados com o projeto do sistema). As funcionalidades providas pelos sistemas às atividades são consideradas requisitos funcionais destes sistemas e são mapeadas nos casos de uso correspondentes. Os requisitos não funcionais que estão relacionados à qualidade dos serviços providos pelo sistema tais como desempenho, segurança e disponibilidade, são geralmente propriedades ou características de vários casos de uso.

Enjoy!

Sunday, August 22, 2010

O modelo de design hierárquico

O modelo de rede hierárquico é uma ferramenta útil de alto nível para projetar uma infra-estrutura de rede confiável. Ele fornece uma exibição modular de uma rede, o que facilita o projeto e a criação de uma rede escalável.

O modelo de rede hierárquico divide uma rede em três camadas:

Camada de acesso – concede acesso ao usuário a dispositivos de rede. Em um campus de rede, a camada de acesso costuma incorporar dispositivos de rede local comutados com portas que fornecem conectividade a estações de trabalho e servidores. No ambiente WAN, ele pode fornecer a funcionários remotos ou sites remotos o acesso à rede corporativa em toda a tecnologia WAN.
Camada de distribuição – agrega os wiring closets, utilizando switches para dividir os grupos de trabalho em segmentos e isolar problemas de rede em um ambiente de campus. Da mesma forma, a camada de distribuição agrega conexões WAN na borda do campus e fornece conectividade baseada na política.
Camada do núcleo (também conhecida como o backbone) – um backbone de alta velocidade projetado para comutar pacotes o mais rápido possível. Como o núcleo é essencial para conectividade, ele deve fornecer um alto nível de disponibilidade e se adaptar a alterações muito rapidamente. Ele também fornece escalabilidade e convergência rápida.



A figura representa o modelo de rede hierárquico em ambientes de campus. O modelo de rede hierárquico fornece uma estrutura modular que garante flexibilidade no projeto de rede e facilita a implementação e a solução de problemas na infra-estrutura. No entanto, é importante compreender que a infra-estrutura de rede só é a base de uma arquitetura mais ampla. As tecnologias de networking avançaram consideravelmente nos últimos anos, o que resulta em redes cada vez mais inteligentes. Os elementos de rede atuais têm mais características de tráfego, podendo ser configurados para fornecer serviços especializados com base em coisas como os tipos de dados transportados, a prioridade dos dados e até mesmo as necessidades de segurança. Embora grande parte desses serviços de infra-estrutura estejam fora do escopo desse curso, é importante compreender que eles influenciam o projeto da rede. No próximo tópico, iremos explorar a arquitetura corporativa Cisco, que expande o modelo hierárquico, utilizando a inteligência de rede para abordar a infra-estrutura de rede.

Enjoy!

Wide Area Network - Redes de Grande Distância

O que é uma WAN?

WAN é uma rede de comunicação de dados que funciona além do escopo geográfico de uma rede local.  As WANs são diferentes das redes locais em vários aspectos. Enquanto uma rede local conecta computadores, periféricos e outros dispositivos em um único prédio ou outra área geográfica menor, uma WAN permite a transmissão dos dados em distâncias geográficas maiores. Além disso, uma empresa deve contratar um provedor de serviço WAN para utilizar os serviços de rede dessa operadora. As redes locais costumam ser da companhia ou organização que as utilizam. As WANs utilizam instalações fornecidas por um provedor de serviços ou operadora, como uma companhia telefônica ou empresa de cabeamento, para conectar os locais de uma organização aos locais de outras organizações, a serviços externos e a usuários remotos. As WANs normalmente transportam vários tipos de tráfego, como voz, dados e vídeo.

Aqui estão as três principais características das WANs:

As WANs normalmente conectam dispositivos separados por uma área geográfica maior do que a que pode ser atendida por uma rede local.
As WANs utilizam os serviços das operadoras, como companhias telefônicas, empresas de TV a cabo, sistemas de satélites e provedores de rede.
As WANs utilizam conexões seriais de vários tipos para fornecer acesso à largura de banda em grandes áreas geográficas.

Por que as WANs são necessárias?


As tecnologias de rede local fornecem velocidade e economia na transmissão de dados em organizações em áreas geográficas relativamente pequenas. No entanto, há outras necessidades de negócios que precisam de comunicação entre locais remotos, inclusive as seguintes: As pessoas no escritório regional ou nas filiais de uma organização precisam ser capazes de se comunicar e compartilhar dados com o local central. As organizações normalmente desejam compartilhar informações com outras organizações em grandes distâncias. Por exemplo, fabricantes de software sempre comunicam informações sobre produtos e promoções aos distribuidores que vendem seus produtos para usuários finais. Os funcionários que viajam a negócios sempre precisam acessar informações presentes em suas redes corporativas. Além disso, os usuários de computadores domésticos precisam enviar e receber dados em distâncias cada vez maiores. Aqui estão alguns exemplos: Agora é comum em muitas residências que os clientes se comuniquem com bancos, lojas e vários fornecedores de mercadorias e serviços via computadores. Os alunos realizam pesquisas relativas às aulas acessando índices de bibliotecas e publicações localizados em outras partes do país, além de outras partes do mundo. Como obviamente não é possível conectar computadores em um país ou em todo o mundo da mesma forma que os computadores são conectados em uma rede local com cabos, surgiram tecnologias diferentes para atender a essa necessidade. Cada vez mais, a Internet está sendo utilizada como uma alternativa barata à utilização de uma WAN corporativa em alguns aplicativos. Há novas tecnologias disponíveis para as empresas fornecerem segurança e privacidade em suas comunicações e transações na Internet. As WANs utilizadas por elas mesmas, ou em conjunto na Internet, permitem a organizações e indivíduos atender a suas necessidades de comunicação remota.



Enjoy!


Otimizar a performance do MySQL em Linux

Uma das componentes mais importantes na optimização do desempenho de um ambiente LAMP (Linux, Apache, MySQL, PHP/Perl) é definitivamente a componente base de dados, ou seja, o MySQL. É o componente onde a sua correcta configuração pode fazer a maior diferença entre um servidor que fica de rastos com um pequeno pico no tráfego ou um que aguenta incólume.


É possível tornar o MySQL mais rápido de 3 formas:

   1. Hardware mais potente.Aumentar a capacidade do hardware é a mais fácil de todas, mas também a mais dispendiosa e menos eficiente.
   2. Correcta afinação dos parâmetros do MySQL (my.cnf). A correcta definição dos parâmetros permite que a memória disponível no servidor seja distribuída da melhor forma, tentamos pois minimizar que o processo mysqld tenha aceda ao disco. Também informamos a base de dados acerca do tipo de carga a esperar para que o MySQLprepare os seus recursos da forma mais eficiente.
   3. Otimização das consultas SQL. É de extrema importância que as tabelas tenham os índices bem definidos, entre outros aspectos.

Neste artigo mostro uma forma simples e expedita de saber quais os parâmetros e que valores aplicar no my.cnf (ficheiro de configuração do MySQL).


Aplicar o my.cnf mais apropriado ao sistema

Juntamente com todas as instalações do MySQL, vem um conjunto de ficheiros modelo de configuração para vários tipos de servidor. Devemos escolher aquele que é mais indicado para o nosso caso específico.

Os ficheiros modelo são os seguintes:

    * my-huge.cnf (enorme capacidade)
    * my-large.cnf (grande capacidade)
    * my-medium.cnf (média capacidade)
    * my-small.cnf (pequena capacidade)

As definições que vêm por defeito no my.cnf são para um servidor com capacidades muito reduzidas, isto para que, por defeito, o MySQL possa correr em qualquer servidor. Devemos por isso substituir esses parâmetros pelos encontrados num dos ficheiros modelo mais adequado ao nosso tipo de sistema.

Caso não saiba onde se encontram esses ficheiros no sistema pode aplicar o seguinte comando para descobrir a sua localização.

find / -name my-*.cnf

Depois de feitas as alterações deve reiniciar o MySQL e esperar até que ele tenha pelo menos 48 horas de carga.


Instalar e correr o MySQL Performance Tuning Primer Script

Fazer o download do scrip

wget http://day32.com/MySQL/tuning-primer.sh

Tornar o script executável

chmod +x ./tuning-primer.sh

Correr o script

./tuning-primer.sh


Exemplo do relatório para um caso real


-- MYSQL PERFORMANCE TUNING PRIMER --
     - By: Matthew  Montgomery -
MySQL Version 4.1.22-standard-log i686

Uptime = 2 days 7 hrs 2 min 31 sec
Avg. qps = 332
Total Questions = 65843202
Threads Connected = 44

Server has been running for over 48hrs.
It should be safe to follow these recommendations

To find out more information on how each of these
runtime variables effects performance visit:
http://dev.mysql.com/doc/refman/4.1/en/server-sys
tem-variables.html
Visit  http://www.mysql.com/products/enterprise/a
dvisors.html
for info about MySQL's Enterprise Monitoring and
 Advisory Service

SLOW QUERIES
Current long_query_time = 5 sec.
You have 1942348 out of 65843325 that take longer
than 5 sec. to complete
The slow query log is enabled.
Your long_query_time seems to be fine

WORKER THREADS
Current thread_cache_size = 8
Current threads_cached = 7
Current threads_per_sec = 0
Historic threads_per_sec = 0
Your thread_cache_size is fine

MAX CONNECTIONS
Current max_connections = 100
Current threads_connected = 47
Historic max_used_connections = 101
The number of used connections is 101% of  the
configured maximum.
You should raise max_connections

MEMORY USAGE
Max Memory Ever Allocated : 1 G
Configured Max Per-thread Buffers : 1 G
Configured Max Global Buffers : 426 M
Configured Max Memory Limit : 1 G
Physical Memory : 5.94 G
Max memory limit seem to be within
acceptable norms

KEY BUFFER
Current MyISAM index space = 179 M
Current key_buffer_size = 384 M
Key cache miss rate is 1 : 62678
Key buffer fill ratio = 23.00 %
Your key_buffer_size seems to be too high.
Perhaps you can use these resources elsewhere

QUERY CACHE
Query cache is enabled
Current query_cache_size = 32 M
Current query_cache_used = 14 M
Current query_cache_limit = 1 M
Current Query cache Memory fill ratio = 44.98 %
Current query_cache_min_res_unit = 4 K
MySQL won't cache query results that are larger
than  query_cache_limit in size

SORT OPERATIONS
Current sort_buffer_size = 2 M
Current record/read_rnd_buffer_size = 7 M
Sort buffer seems to be fine

JOINS
Current join_buffer_size = 132.00 K
You have had 766426 queries where a join could
not use an index properly
You have had 501 joins without keys that check
for key  usage after each row
You should enable "log-queries-not-using-indexes"
Then look for non indexed joins in the slow query
log.
If you are unable to optimize your queries you
may want to increase your
join_buffer_size to accommodate larger joins
in one pass.
Note! This script will still suggest raising
the  join_buffer_size when
ANY joins not using indexes are found.

OPEN FILES LIMIT
Current open_files_limit = 4166 files
The open_files_limit should typically be set
to at  least 2x-3x
that of table_cache if you have heavy MyISAM usage.
You currently have open more than 75% of your
open_files_limit
You should set a higher value for open_files_limit
in  my.cnf

TABLE CACHE
Current table_cache value = 2028 tables
You have a total of 1652 tables
You have 2028 open tables.
Current table_cache hit rate is 14%,  while 100%
of your table cache is in use
You should probably increase your table_cache

TEMP TABLES
Current max_heap_table_size = 16 M
Current tmp_table_size = 32 M
Of 793662 temp tables, 17% were created on disk
Effective in-memory tmp_table_size is limited to 
max_heap_table_size.
Created disk tmp tables ratio seems fine

TABLE SCANS
Current read_buffer_size = 1 M
Current table scan ratio = 69 : 1
read_buffer_size seems to be fine

TABLE LOCKING
Current Lock Wait ratio = 1 : 44
You may benefit from selective use of InnoDB.
If you have long running SELECT's against
MyISAM tables and perform
frequent updates consider setting
'low_priority_updates=1'



O relatório está dividido em várias secções. No final de cada secção é feita a sugestão se algo deve ser alterado ou se os parâmetros definidos estão corretos.

Finalmente devemos aplicar as sugestões e analisar o comportamento do sistema. Este script poupa muito tempo de análise e interpretação dos imensos parâmetros passíveis de optimização. Este processo deve ser revisto regularmente, principalmente se acontecerem mudanças na quantidade de tráfego a chegar ao sistema.

Alternativa mais demorada

Também é possível fazer este trabalho de otimização de uma forma não automática. Para este efeito recomendo a instalação do mysqlreport e leitura do manual de interpretação do relatório.

Enjoy!

Flexibilidade dos Softwares

Vários autores comentam que muitos dos sistemas de TI (incluindo alguns ERP's) possuem a flexibilidade (melhor seria fluidez) de "concreto líquido" antes da implantação, quando tudo é possível, qualquer forma é factível de se adaptar; porém, após a implantação, transforma-se em "concreto endurecido", dificílimo de ser alterado: qualquer alteração é custosa e demorada e transformações contínuas podem implicar em ter de alterar toda a estrutura inicial. Infelizmente nossos softwares não são tão "soft" assim.

Enjoy!

Visão geral das tecnologias WAN e Computadores

Uma WAN é uma rede de comunicações de dados que opera além da abrangência geográfica de uma rede local. Uma das principais diferenças entre uma WAN e uma rede local é que uma empresa ou organização precisa ser assinante de um provedor de serviços WAN para poder usar os serviços de rede da operadora. Uma WAN usa os enlaces de dados fornecidos pelas operadoras para prover o acesso à Internet, a conexão entre as diversas localidades de uma organização e a conexão com as redes de outras organizações, possibilitando ainda, a oferta de serviços externos e o acesso de usuários remotos. WANs geralmente transportam vários tipos de tráfego, como voz, dados e vídeo. Os serviços telefônicos e de dados são os serviços WAN mais comumente usados. Os dispositivos que ficam nas instalações do assinante são chamados CPE (customer premises equipment).  O assinante é dono do CPE ou o aluga do provedor de serviços. Um cabo de cobre ou fibra conecta o CPE à central da operadora (CO – Central Office). Esse cabeamento geralmente é chamado de loop local ou "last mile". Uma chamada discada é conectada a outros loops locais na mesma região através da própria central da operadora, ou a outros em regiões mais distantes através de um tronco com uma central principal. Em seguida, ela vai até uma central seccional e segue para uma central regional ou internacional da operadora, ao longo do trajeto até seu destino. Para que o loop local transporte dados, é necessário um dispositivo (por exemplo, um modem) que prepare os dados para transmissão. Os dispositivos que colocam dados no loop local são chamados de equipamentos de terminação do circuito de dados, ou equipamentos de comunicações de dados (DCE – Data Communications Equipment). Os dispositivos do cliente que passam os dados para o DCE são chamados de equipamentos terminais de dados (DTE – Data terminal Equipment).  A principal função do DCE é fornecer ao DTE uma interface com o enlace de comunicação que o conecta à nuvem WAN. A interface DTE/DCE usa vários protocolos de camada física, tais como HSSI (High-Speed Serial Interface – Interface Serial de Alta Velocidade) e V.35. Esses protocolos estabelecem os códigos e os parâmetros elétricos usados pelos dispositivos para se comunicarem. Os enlaces WAN são fornecidos em diversas velocidades, medidas em bits por segundo (bps), quilobits por segundo (kbps ou 1000 bps), megabits por segundo (Mbps ou 1000 kbps) ou gigabits por segundo (Gbps ou 1000 Mbps). Geralmente, os valores bps são full duplex. Isso significa que uma linha E1 pode transportar 2 Mbps ou que uma linha T1 pode transportar 1,5 Mbps em cada direção ao mesmo tempo.

O interessante é que pelas mesmas linhas telefônicas que antes levavam apenas vozes estáticas passam hoje ordens de compra, grandes somas de dinheiro, plantas de projetos de produtos, material de propaganda, reuniões e conferências. Os computadores, que a princípio automatizavam cálculos, hoje aconselha aos responsáveis por decisões, e até mesmo toma essas decisões, recolhe e coloca à disposição um grande volume de texto, números, imagens, siumula uma imensa variedade de processos e ambientes (inclusive aspectos limitados, mascrescentes da "realidade") e acompanha e controla o desempenho de vários aparelhos que vão de naves espaciais a corações artificiais.

Enjoy!

Cadeia de valor de Porter

Uma cadeia de valor representa o conjunto de atividades desempenhadas por uma organização desde as relações com os fornecedores e ciclos de produção e de venda até à fase da distribuição final. O conceito foi introduzido por Michael Porter em 1985. Ao decompor uma organização nas suas atividades de relevância estratégica, torna-se possível analisar o comportamento dos custos e as fontes existentes assim como potenciais de diferenciação em cada processo de negócio, otimizando o valor final que o seu produto representa para o cliente. A liderança de custo e a diferenciação pela qualidade acrescem valor ao produto e proporcionam vantagem competitiva à organização no contexto da indústria em que se insere. A cadeia de valor de uma organização insere-se num contexto mais amplo de atividades, ela constitui um sistema de valores onde estão integradas também as cadeias de valor de fornecedores e de distribuidores. Quando não temos um modelo especializado da organização para mapeamento de processos, a cadeia de valor de Porter torna-se um excelente ponto de partida.



Enjoy!

Friday, August 20, 2010

A Relação Entre TDD e Qualidade de Software

TDD é uma prática que visa aumentar a velocidade da entrega de produtos através da simplificação das atividades de desenho de software. [Koskela 2008] resume a filosofia do TDD em uma frase -- somente escreva código para fazer um teste falho passar. Enquanto isso, [Astels 2003] define o TDD como sendo um estilo de desenvolvimento onde:

    * Uma suíte exaustiva de testes de programadores é mantida;
    * Nenhum código entra em produção a não ser que tenha testes associados;
    * Os testes são escritos antes;
    * Os testes determinam que código precise ser escrito.

Qualidade não pode ser alcançada através da avaliação de um produto já feito. O objetivo, portanto, é prevenir defeitos de qualidade ou deficiências em primeiro lugar, tornando os produtos avaliáveis através de medidas de garantia de qualidade [Lewis 2004]. [Beck 1999] cita alguns exemplos de riscos relacionados ao desenvolvimento de software. Dos riscos citados, dois estão diretamente ligados a qualidade de software e podem ser tratados através da utilização de TDD:

    * Taxa de defeitos -- o software é colocado em produção mas a taxa de defeitos é tão alta que ele acaba não sendo utilizado. TDD eleva a validação de um software a um patamar superior, testando-o função por função;
    * Deterioração do sistema -- o software é colocado em produção com sucesso, porém após algum tempo o custo de se fazer modificações ou a taxa de defeitos aumenta tanto que o sistema precisa ser substituído. TDD mantém o programador focado na solução, de forma que o software não fica carregado de códigos desnecessários, duplicados ou de difícil manutenção, impedindo a deterioração do sistema.

Nesta mesma obra, [Beck 1999] elaborou três frases de impacto, que servem como um ponto de partida para entendermos como o TDD afeta a qualidade de um software:

    * Toda vez que alguém toma uma decisão e não a testa, existe uma grande probabilidade de que esta decisão esteja errada;
    * Funcionalidades de software que não podem ser demonstradas através de testes automatizados simplesmente não existem;
    * Testes nos dão à chance de pensar sobre o que queremos, independente da forma como a solução será implementada.

Ao utilizar TDD, devemos escrever testes para cada solução implementada. Dessa forma, diminuímos a probabilidade de tomarmos uma decisão errada. Ao mesmo tempo, temos a oportunidade de experimentar várias implementações diferentes para o mesmo problema e escolher aquela mais limpa, elegante e que apresente o melhor desempenho.

Desenho Simplificado e Evolucionário

Escrevendo somente o necessário para os testes e removendo toda a duplicação, você automaticamente obtém um desenho que é perfeitamente adaptado para os requisitos atuais e igualmente preparado para todas as futuras funcionalidades [Beck 2002]. Design simplificado reduz os custos porque ao escrever menos código para atender os requisitos, menos código existirá para ser mantido no futuro. Design simplificado é mais fácil de se construir, manter e entender.

Refatoração


Os testes lhe dão a confiança de que grandes refatorações não mudarão o comportamento do sistema, o que se conclui que, quanto maior a confiança, mais agressivamente você poderá conduzir refatorações em larga escala que estenderão a vida de seu sistema. A refatoração torna a elaboração dos próximos testes muito mais fácil [Beck 2002]. Custos são reduzidos porque a refatoração contínua evita que o desenho se degrade com o passar do tempo, assegurando que o código continue fácil de ser entendido, mantido e modificado.

Feedback Constante

[Beck 2002], no último capítulo de sua publicação, afirma que TDD o ajuda a dar atenção aos problemas certos na hora certa, de forma que o desenho do software fica mais limpo e com muito menos defeitos. O TDD faz com que o programador ganhe confiança sobre seu código com o passar do tempo, isto é, à medida que os testes vão se acumulando (e melhorando), ele ganha confiança no comportamento do sistema. E ainda, à medida que o desenho é refinado, mais e mais mudanças se tornam possíveis. Outra vantagem do TDD que [Beck 2002] acredita poder explicar seus efeitos positivos, é a forma como ele encurta o ciclo de feedback sobre as decisões de desenho. Ele dura apenas segundos ou minutos, e é seguido pela reexecução dos testes dezenas ou centenas de vezes por dia. Ao invés de se projetar um desenho e então esperar semanas ou meses para outra pessoa sentir as dores ou glórias de sua consequência, o feedback emerge em segundos ou minutos, enquanto você tenta traduzir suas idéias em interfaces plausíveis.

Suíte de Testes (Regressão)


Usando TDD, os testes unitários são criados num momento onde a funcionalidade a ser implementada está mais bem definida na mente do programador, e depois podem e devem ser utilizados para fazer testes de regressão. Uma suíte de testes automáticos feita por programadores reduz os custos de um software funcionando como uma rede de segurança de testes que capturam defeitos, problemas de comunicação e ambigüidades antes e permitem que o desenho possa ser modificado de forma incremental. Esta suíte de testes gerada pelo TDD é fundamental para viabilizar procedimentos de Integração Contínua.

Documentação Para Programadores

A suíte de testes serve como uma documentação voltada para o programador que tem um entendimento mais rápido e facilitado do que uma parte do código faz através do código que o testa. Cada teste unitário especifica o uso apropriado de uma classe de produção [Langr 2005].

Conclusões

Esta técnica de desenvolvimento   produz desenhos menos acoplados que são mais fáceis de manter, reduz altamente a quantidade de defeitos, e reforça a construção e manutenção apenas do que é realmente necessário. Finalmente, testes bem escritos atuam como um tipo de requisitos “executáveis” que ajudam a manter o entendimento compartilhado da equipe de desenvolvimento, sobre como o sistema de software representa os problemas do mundo real. Por outro lado, o fato de se ter um grande número de testes unitários passando com sucesso, pode passar uma falsa sensação de segurança, resultando na implementação de menos atividades de garantia de qualidade, como testes de integração e testes de conformidade. É importante ressaltar também que, esta técnica não garante a obtenção de níveis aceitáveis em certos aspectos do software final, como usabilidade e desempenho. Além disso, TDD não consegue mitigar riscos relacionados com a falta de requisitos ou com requisitos erroneamente definidos.

Referências


Astels, D. (2003). Test-Driven Development: A Practical Guide. Prentice Hall PTR.
Beck, K. (1999). Extreme Programming Explained: Embrace Change. Addison Wesley.
Beck, K. (2002). Test-Driven Development By Example. Addison Wesley.
Koskela, L. (2008). Test Driven: Pratical TDD and Acceptance TDD for Java Developers.Manning.
Langr, J. (2005). Agile Java Crafting Code with Test-Driven Development. Prentice Hall PTR.
Lewis, W. E. (2004). Software Testing and Continuous Quality Improvement. Auerbach, 2 edition.

Thursday, August 19, 2010

Arquitetura de Software

Os sistemas de software vêm se tornando cada vez mais essenciais à sociedade e às organizações. Dentre os fatores que impulsionaram este fato estão a evolução do hardware nas últimas décadas e a explosão do uso da Internet. Software representa atualmente um fator de competitividade para as empresas, as quais apresentam uma demanda crescente por sistemas e uma exigência de prazo e qualidade cada vez maiores. Com tudo isso, o perfil do desenvolvimento de software vai se modificando, com o foco migrando para sistemas distribuídos, mais complexos e com uma produção em grande escala. Para suportar este novo perfil do desenvolvimento de software, uma disciplina vem emergindo e ganhando importância: a arquitetura de software. A arquitetura enfatiza a organização global do sistema, definindo a sua topologia e permitindo que desenvolvedores voltem a sua atenção para os requisitos funcionais e não-funcionais que precisam ser atendidos, antes de se aterem ao projeto das estruturas de dados e algoritmos. Em outras palavras, projetar a estrutura global de um sistema emerge como um problema novo: o desenvolvimento de software orientado para arquitetura (MENDES, 2002). Diversas definições são dadas para arquitetura de software na literatura. Dentre elas, destacam-se: “Descrição dos elementos a partir dos quais os sistemas são construídos (componentes), interações entre estes elementos (conectores), padrões que guiam sua composição, e restrições sobre estes padrões” (SHAW e GARLAN, 1996). “A estrutura de componentes de um programa/sistema, seus relacionamentos, princípios e diretrizes que governam seu projeto e evolução ao longo do tempo” (GARLAN e PERRY, 1995). “A arquitetura de um sistema consiste da(s) estrutura(s) de suas partes (incluindo as partes de software e hardware envolvidas no tempo de execução, projeto e teste), da natureza e das propriedades relevantes que são externamente visíveis destas partes (módulos com interfaces, unidades de hardware, objetos), e dos relacionamentos e restrições entre elas” (D’SOUZA e WILLS, 1999). A arquitetura desempenha um papel ainda mais importante nas abordagens de engenharia de software voltadas à reutilização, como a ED, onde ela estabelece a estrutura na qual os componentes reutilizáveis do domínio são conectados e instanciados, e para a qual os novos componentes das aplicações devem apresentar compatibilidade. Neste contexto, torna-se cada vez mais evidente a necessidade do projeto arquitetural nos processos de engenharia de software.

Enjoy!

Saturday, August 14, 2010

O Teste Do Joel

   1. Você usa controle de código?
   2. Você pode compilar em somente um passo?
   3. Você faz compilações diárias?
   4. Você tem uma base de dados de bugs?
   5. Você corrige os bugs antes de escrever código novo?
   6. Você tem um cronograma atualizado?
   7. Você tem uma especificação?
   8. Os programadores tem condições de trabalho tranqüilas?
   9. Você usa as melhores ferramentas que o dinheiro pode comprar?
  10. Você tem testadores?
  11. Novos candidatos escrevem código durante a entrevista?
  12. Você faz testes de usabilidade de corredor?

Extraído de [http://brazil.joelonsoftware.com/Articles/TheJoelTest.html]

Enjoy!

Os programadores têm condições de trabalho tranqüilas?

Existe uma extensa documentação sobre ganhos de produtividade obtidos ao dar aos profissionais do conhecimento espaço, quietude e privacidade. O livro clássico de gerenciamento de software Peopleware documenta extensamente estes benefícios de produtividade.

Eis o problema. Todos nós sabemos que estes profissionais trabalham melhor entrando no "fluxo", também conhecido como "estar na zona", onde eles estão completamente concentrados em seu trabalho e totalmente desligados de seu ambiente. Eles perdem a noção do tempo e produzem grandes coisas através da concentração absoluta. Escritores, programadores, cientistas e mesmo jogadores de basquete podem te dizer algo sobre "estar na zona".

O problema é que entrar no "fluxo" não é fácil. Quando você tenta medí-lo, parece que leva uma média de 15 minutos para se começar a trabalhar na produtividade máxima. Às vezes, se você está cansado ou já fez uma porção de trabalho criativo naquele dia, você simplesmente não consegue entrar em transe e gasta o resto de seu dia de trabalho com besteiras, navegando na web, jogando Tetris.

O outro problema é que é muito fácil sair do transe. Barulho, chamadas telefônicas, sair para almoçar, dirigir 5 minutos até a Casa do Pão de Queijo para um café e interrupções de colegas de trabalho -- principalmente interrupções de colegas de trabalho -- tiram você do transe. Se um colega de trabalho te faz uma pergunta, causa 1 minuto de interrupção, mas tira-lhe do transe e faz com que você leve uma meia hora para estar produtivo novamente, e sua produtividade geral está em sérios problemas. Se você está em um ambiente de baias barulhento como o tipo que as cafeinadas empresas pontocom adoram criar, com caras do marketing gritando no telefone perto de programadores, sua produtividade será desperdiçada, assim como a do profissional do conhecimento que é interrompido de tempos em tempo e nunca entra "na zona".

Com programadores, é especialmente difícil. Produtividade depende de ser capaz de manipular uma série de pequenos detalhes em um curto espaço de memória tudo de uma vez. Qualquer tipo de interrupção pode causar a dispersão destes detalhes. Quanto você retoma o trabalho, você não pode se lembrar de cada um dos detalhes (como nomes de variáveis locais que estava usando ou onde você estava na implementação daquele algoritmo de busca) e você tem que lembrar estas coisas, o que o retarda um bocado até que você volta à velocidade original.

Eis a matemática. Digamos (como a evidência sugere) que se nós interrompermos um programador, mesmo que por um minuto, estaremos realmente desperdiçando 15 minutos de produtividade. Para este exemplo, vamos tomar dois programadores, João e Manoel, em baias abertas próximas no padrão Dilbert de fazenda de engorda de gado. Manoel não consegue lembrar o nome da versão Unicode da função strcpy. Ele pode procurá-la, o que leva 30 segundos, ou pode perguntar ao João, o que leva 15 segundos. Uma vez que ele está sentado ao lado do João, ele pergunta ao João. João se distrai e perde 15 minutos de produtividade (para economizar 15 segundos do Manoel).
Agora vamos colocá-los em escritórios separados com paredes e portas. Agora quando Manoel não lembrar o nome daquela função, ele pode procurar, o que ainda leva 30 segundos, ou ele pode perguntar ao João, o que agora leva 45 segundos e envolve se levantar (uma tarefa difícil, dada a forma física média de programadores!). Então ele procura. Agora Manoel perdeu 30 segundos de produtividade, mas nós salvamos 15 minutos do João. Ahhh