Fluxo da Energia Solar

Enjoy!

I/O e RAID com Banco de Dados

Este post fornece uma visão geral do funcionamento de RAID (Redundant Arrays of Inexpensive Disks), os diferentes níveis de RAID e seus usos com bancos de dados.


RAID-0:

RAID-0 oferece apenas STRIPING de disco. O STRIPING permite que um arquivo grande seja distribuído entre vários discos/controladoras, fornecendo acesso simultâneo aos dados o que permite que todas as controladoras estejam trabalhando em paralelo. Ele não fornece proteção de dados proteção através de paridade ou redundância. Na verdade, no RAID-0 o único foco é o desempenho. Alguns fornecedores, tais como a EMC, não consideram o nível 0 como um "TRUE RAID" (RAID verdadeiro) e não oferecem soluções baseadas nele. RAID-0 é altamente performático mas muito perigoso, se um dos HD´s do ARRAY quebrar todo o sistema de arquivos ficará inativo derrubando o banco de dados.

RAID-1:

Com RAID-1, todos os dados são gravados em dois discos independentes (um "par de discos") para proteção completa dos dados em redundância. RAID-1 também é conhecido como disco de espelhamento ou efeito de sombra do disco. Os dados são gravados simultaneamente em dois discos e as gravações são tão rápidas como em um único disco. Durante a leitura, o disco que estiver menos ocupado é utilizado. O RAID-1 é o mais seguro e confiável de todos os níveis devido à redundância completa. No entanto, um dos problemas de desempenho seria a necessidade de gravar os dados em dois locais, duplicando o esforço de gravação. Na leitura, no entanto, o desempenho é melhorado, como a leitura pode vir de qualquer disco. O RAID-1 exige um investimento significativo pois duplica a quantidade de discos necessários para o armazenamento no entanto, ele fornece elevado tempo médio entre falhas (MTBF).

RAID-0 + RAID-1:

Se o RAID-0 (STRIPING), for combinado com RAID-1 (espelhamento), então você acaba de conseguir redundância com performance, mas a um custo de ter que duplicar o número de unidades de disco na configuração do ARRAY. Algumas implementações de RAID-1 no momento da leitura buscam os dados do dispositivo menos ocupado. Isso pode contabilizar um aumento no desempenho de mais de 85% em comparação com uma configuração apenas de RAID-1. Em uma implementação de RAID-1, no momento da gravação se faz necessário gravar em dois dispositivos, é recomendável para manter o ganho de performance a utilização de 2 controladoras, desta maneira obtendo a melhor relação no momento da gravação dos dados.
A combinação do RAID - 0 + 1, permite que os DADOS distribuídos em um STRIPING sejam espelhados.

RAID-3:

Em uma configuração de RAID-3, uma única unidade dedica-se ao armazenamento de correção de erros ou armazenamento dos dados de paridade. A informação é distribuída nas unidades restantes. O RAID-3 reduz drasticamente o nível de concorrência que o disco pode suportar (I/O por segundos) se comparado ao espelhamento por software. O pior caso para um sistema usando RAID-3, seria um ambiente OLTP, onde o número de transações rápidas grande e o tempo de resposta é crítico.
Para simplificar se o ambiente se destina principalmente a leitura, (ex. sistema de suporte a decisão) o RAID-3 fornece redundância com bom desempenho de leitura, mas as custas do desempenho de gravação. Infelizmente, mesmo sistemas de suporte a decisão requerem do banco de dados uma quantidade significativa de gravação em disco.

RAID-5:

Ao invés de um espelhamento total do disco, o RAID-5 calcula e grava a paridade para cada operação de gravação. Os discos de paridade evitam o custo da duplicação completa ocasionada pelo RAID-1. Se um disco falhar, a paridade é usada para reconstruir os dados sem perda de sistema. Os dados e a paridade são distribuídos em todos os discos do RAID, reduzindo assim os problemas de afunilamento de disco. O desempenho de leitura é melhorado, mas cada gravação tem que suportar a sobrecarga adicional de leitura da paridade antiga, cálculo da nova paridade, gravação nova paridade e em seguida, escrever os dados reais, com as duas últimas operações de forma simultânea em dois drives de disco. Essa sobrecarga é famosa como a penalidade de gravação do RAID-5. Esta penalidade na gravação pode fazer gravações significativamente mais lentas. Além disso, se um disco falhar em um RAID-5, a recuperação do RAID é extremamente lenta durante a sua reconstrução. Aplicativos que tem como característica a leitura-intensiva (DSS, DATA WAREHOUSING) podem usar RAID-5 sem degradação do desempenho de acesso em tempo real (a pena de gravação ainda seria bastante alta durante os períodos de carga em lote do sistema DSS). Em termos de armazenamento, no entanto, a paridade constitui uma sobrecarga estimada de 20 por cento, se  comparada aos 100% de sobrecarga no RAID-1 ou RAID-0 + 1. Inicialmente, quando foi introduzida a tecnologia RAID-5, ele foi identificada como a solução econômica que combinava alta disponibilidade e desempenho. Gradualmente, os usuários perceberam a verdade sobre o desempenho do RAID-5 e até sobre um par de anos atrás, o RAID-5 foi sendo considerado o vilão na maioria das implementações de ambientes OLTP. Muitos sites que implementaram RAID-5 começaram a olhar para soluções alternativas tentando se livrar do mesmo, o RAID-0 + 1 ganhou notoriedade como a melhor solução para ambientes OLTP.

RAID-S:

RAID-S é a implementação de RAID-5 da EMC. No entanto, difere da implementação pura de RAID-5  em dois aspectos:
(1) Ele faz STRIPING da paridade, mas não faz STRIPING com os dados.
(2) Incorpora um ambiente de hardware assíncrono com um cache de gravação.
Esse cache é um mecanismo para conter as gravações, para minimizar a sobrecarga de cálculo e gravação das informações de paridade que são necessárias, enquanto o sistema está menos ocupado. Muitos usuários de RAID-S imaginam que, uma vez que o RAID-S é, supostamente, uma versão aprimorada do RAID-5, o STRIPING dos dados é automático. É fundamental lembrar que no RAID-S, o STRIPING dos dados não é automático e tem de ser feito manualmente via um software de gerenciamento de disco de terceiros.

RAID-7:

O RAID-7 também implementa uma arquitetura de cache, controlado por um sofisticado esquema de acesso em tempo real. Aqui, no entanto, é feito STRIPING dos dados e não da paridade. Em vez disso, a paridade é realizada em uma ou mais unidades dedicadas a este processo. O RAID-7 é uma arquitetura patenteada da STORAGE COMPUTER CORPORATION.

Enjoy!

Características de micro e pequenas empresas comerciais e de serviços no Brasil

O IBGE (Instituto Brasileiro de Geografia e Estatística) divulgou em 2003 uma pesquisa sobre as micro e pequenas empresas comerciais e de serviços no Brasil (IBGE, 2003), onde é possível observar que as MPEs, em geral, apresentam algumas características comuns. CEZARINO (2006) interpreta o que foi apontado nesta pesquisa, elencando as seguintes características observáveis em MPEs:

• Pequeno volume de capital investido;
• Grande natalidade e mortalidade;
• Presença significativa de proprietários, sócios e funcionários com laços familiares;
• Grande centralização do poder decisório;
• Não distinção da pessoa física do proprietário com a pessoa jurídica, inclusive em balanços contábeis;
• Registros contábeis pouco adequados;
• Contratação direta de mão-de-obra;
• Baixo nível de tercerização;
• Baixo emprego de tecnologias sofisticadas;
• Baixo investimento em inovação tecnológica;
• Dificuldade de acesso a financiamento de capital de giro;
• Dificuldade de definição dos custos fixos;
• Alto índice de sonegação fiscal;
• Contratação direta de mão-de-obra;
• Utilização intensa de mão-de-obra não qualificada ou sem qualificação.

Enjoy!

Replace Conditional with Polymorphism

You have a conditional that chooses different behavior depending on the type of an object. Move each leg of the conditional to an overriding method in a subclass. Make the original method abstract.

double getSpeed() {
    switch (_type) {
      case EUROPEAN:
        return getBaseSpeed();
      case AFRICAN:
        return getBaseSpeed() - getLoadFactor() * _numberOfCoconuts;
      case NORWEGIAN_BLUE:
        return (_isNailed) ? 0 : getBaseSpeed(_voltage);
    }
    throw new RuntimeException ("Should be unreachable");
  }

Enjoy! 

Métricas – Complexidade Ciclomática

Esta é provávelmente a métrica complexa mais usada em engenharia de software e continua a ser uma tema recorrente de discussão. Ainda assim continua a ser um assunto obscuro para muitos programadores, coordenadores e gestores. A complexidade ciclomática foi definida por Thomas McCabe (em finais de 1976) e, de uma forma resumida, mede a complexidade estrutural de um processo. Traduzindo para o mundo da arquitectura de software a CC mede a complexidade estrutural de um método, de uma classe ou de qualquer unidade logica que possa ser encontrada num sistema de software.

Complexidade Ciclomática – CC

A CC define-se como o somatório de todas as decisões acrescido de 1. CC = Número de decisões + 1. Entenda-se por decisão todas operações condicionais:

Operação	Efeito no CC
if	+1
else if	+1
else	0
select case	+1 para cada caso
select default	0
for/foreach	+1
do while	+1
do	0
while	+1
catch	+1

Se analisarmos com atenção o seguinte exemplo de código face a estas regras:

public boolean metodo(int param1, int param2) {
    if (param1 > 0 && param2 > 0 && param1 < param2 )  {
        return true;
    }
    return false;
}

Verificamos que a complexidade das operações lógicas não é contabilizada, e no entanto, são um fator fundamental na complexidade do método. Assim surge uma variação à CC denominada de  Complexidade Ciclomática Extendida – CC2 ou ECC.

Complexidade Ciclomática Extendida – CC2

A CC2 não é mais que a extensão da CC por adição dos operadores booleanos.

CC2 = CC + Número de operadores booleanos

Interpretação

Existem mais variantes à CC mas a CC2 é a métrica mais usada e é sobre ela que a restante análise incide. A análise da CC2 é tão útil para o programador como para o coordenador ou gestor. É assumido que qualquer programador deve sempre procura melhorar: codificar melhor, de forma mais eficiente, de forma mais estruturada e procurando sempre produzir código de qualidade. O uso da CC2 é precisamente aferir a qualidade do código produzido. Um valor de CC2 reduzido é um indicador de código limpo, estruturado e testável. Por acréscimo, deverá ainda ser código solúvel, i.e., código cuja lógica será facilmente assimilada por um programador sem contexto. Esta caracteristica, embora frequentemente desprezada, tem um efeito directo sobre o projecto em curso, isto porque, as equipas são cada vez mais voláteis e a curva de aprendizagem de um novo elemento tem sempre bastante impacto na restante equipa e no projecto no seu todo. O código correspondente a um CC2 baixo é estrututura porque as competência de cada método estão bem definidas:

• métodos pequenos que implementam pequenas peças do negócio
• métodos pequenos/médios que orquestram os anteriores e implementam o negócio de forma mais macro

Uma vez que o CC2 é o somatório das operações condicionais e das operações booleanas é também um indicador do número mínimo de testes unitários necessários para testar toda a lógica do método e obter uma cobertura de 100%.

Ora um CC2 baixo significa que o método é completamente testável com poucos testes unitários, i.e., o esforço de criação de testes unitários pode ser calculado e quantificado. Devemos notar aqui que “o tempo dispendido para produzir os testes unitários” continua a ser a justificação mais frequente para a não criação dos mesmos. Agora que já percebemos a importância de analisarmos o CC2, convém apresentar os intervalos mais frequentes usados para avaliar o seu estado:

CC	Tipo	Risco
1-4	Simples	Baixo
5-10	Estável e bem estruturado	Baixo
11-20	Complexo	Moderado
21-50	Muito complexo	Alto
>50	Altamente complexo e não testável	Muito Alto

Uma vez que o CC está intimamente relacionado com o custo de manutenção, é usual ser usada a seguinte tabela de “probabilidade de efeitos colaterais” quando é realizada uma correção:

CC	Probabilidade de efeitos colaterais
1-10	5%
20-30	20%
>50	40%
aprox. 100	60%

Com o aumento da complexidade aumenta também a probabilidade de serem produzidos novos erros. Naturalmente que nem todos os métodos podem ter a CC a baixo do valor que foi determinado como razoavel, mas, nesses casos é fundamental que seja descrito o porquê de esse limite ter sido excedido.

Enjoy!

10 habilidades em Gerenciamento de Projetos que podem ajudar à sua carreira

1. Mostrar resultados. Gerenciamento de Projeto é a arte e a ciência de se fazer as coisas acontecerem. Quando você melhorar suas habilidades em Gerenciamento de Projetos, você saberá como fazer acontecer mais rapidamente e eficientemente, e ainda mais importante, você aprende como documentar os resultados. Em nossa carreira, comumente só somos bons pelas nossas últimas decisões. Você não pode ser um profissional de acertos únicos. Em vez disso, poderá, como um gráfico, ano após ano, mostrando sucesso após o sucesso.

2. Ser eficiente. Quando você aplica os princípios de Gerenciamento de Projetos no seu trabalho, na sua casa ou vida, você parar de reinventar a roda. O Gerenciamento de Projetos ensina você como tornar mais eficiente o uso dos recursos para gerar o melhor resultado no menor período de tempo. Ao final de cada projeto, você captura as melhores práticas e lições aprendidas, criando uma documentação de valor incalculável com erros e acertos. Soa muito bom para ser verdade? Bons Gerentes de Projetos o fazem em todos os projetos, e você pode também.

3. Criar um diálogo permanente. Um erro comum em Gerenciamento de Projetos e no time de projetos é o pressuposto que uma reunião basta para que todos possam seguir o trabalho do projeto e, em seguida, termina a comunicação, e de algum modo tudo magicamente será terminado. Suas competências de comunicação não são sobre o seu vocabulário. Elas são sobre a forma como você gerencia sua comunicação. Você está comunicando com freqüência suficiente e com clareza? Está comunicando o que é relevante? Você está comunicando o seu sucesso?

4. Jogar bem com os outros. As pessoas ouvem a palavra trabalho em equipe, e eles resmungam ou eles dizem que eles são, obviamente, um jogador da equipe. É por isso que eu queria trazê-lo de volta para o lugar em nossa mente, no jardim da infância, chamada: Caixa de Areia. Você brinca bem com os outros? Será que as outras pessoas querem estar na sua equipe? São respeitados por você? Você ouve ativamente o que os outros têm a dizer? Bons Gerentes de Projetos sabem quando devem conduzir e quando sair do caminho. Quando alguém é entrevistado, você sabe o que essa pessoa está pensando: Posso trabalhar com ele? Será que o meu trabalho será bom com ela?

5. Deixar sua confiança brilhar. Quando alguém mostra confiança, todos na sala sentem também.

6. Manter seus Compromissos. Errar nos prazos e projetos que escorregam em rachaduras são erros assassinos na carreira. As habilidades de Gerenciamento de Projeto têm como foco o cumprimento de marcos e resultados que constroem sua reputação e dá aos membros do projeto uma razão para confiarem em você. “Sei que posso sempre contar com ela para fazer o trabalho.” Esta citação pode, e deve, ser sobre você.

7. Manter a calma. Bons Gerentes de Projetos não se desesperam. Eles podem permanecer calmos e no controle, porque eles têm documentações que contém todas as Informações críticas do projeto.

8. Adaptação a mudanças. Não ignore a mudança. Empresas mudam. Prazos se alteram. As pessoas vêm e vão. Bons Gerentes de Projetos sabem que muitas vezes tem que adaptar os planos e documentar o que mudou e quais serão os impactos das mudanças no projeto inteiro.

9. Saiba o que você não conhece. Quais são seus pontos fortes e fracos? Quais as competências que você precisa para se deslocar a partir do “status quo” para o próximo nível? Uma vez que você tenha uma base sólida de Gestão de Projetos, continue crescendo nestas habilidades. Não estagnar, aprendizagem contínua e uma sede de conhecimento são sempre atraentes para os empregadores e membros da equipe.

10. Liderança com propósito e paixão. As pessoas vão acompanhar aqueles que sabem o que que estão fazendo e que pode gerar resultados. Gerenciamento de Projeto é uma poderosa ferramenta de liderança, pois não só nos mostra como manter o nosso olhar sobre o prêmio e da finalidade, mas é também sobre a paixão de conquistar o sucesso. Nada melhor do que o sentimento de realização.

Fonte: Published in PM World Today – September 2007 (Vol. IX, Issue IX)

http://www.pmworldtoday.net/tips/2007/sep.htm#4

Balanced Scorecard

The "Balanced Scorecard" is a strategic management approach developed in the early 1990s by Dr Robert Kaplan of Harvard Business School, and Dr David Norton.

Drs Kaplan and Norton describe the approach - "The balanced scorecard retains traditional financial measures. But financial measures tell the story of past events, an adequate story for industrial age companies for which investments in long-term capabilities and customer relationships were not critical for success. These financial measures are inadequate, however, for guiding and evaluating the journey that information age companies must make to create future value through investment in customers, suppliers, employees, processes, technology, and innovation."

The balanced scorecard identifies four perspectives from which to view an organisation. These are:

* The Learning and Growth Perspective

* The Business Process Perspective

* The Customer Perspective

* The Financial Perspective

Enjoy!

Rock and Roll Erudito!

Enjoy!

Um Pouco de Arte!

Enjoy!

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!

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!

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!

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."

Subversion + Apache + SSL + Ubuntu

http://andreferraro.wordpress.com/2009/04/05/linux-instalando-o-subversion-com-apache-2-e-ssl-no-ubuntu-intrepid-ibex-ubuntu-810/

Enjoy!