Arquivo da Categoria ‘Desenvolvimento’

Como promover a aprendizagem nas equipes de software

sexta-feira, 6 de novembro de 2009

Nas apresentações de Declan Whelan na Agile Testing centradas na promoção da aprendizagem em equipes de software. “Entregando valor a longo prazo para a nossa organização é bloqueada por nossa capacidade de aprender”, disse Whelan, apresentando várias grandes idéias como garantir que as equipes continuarão a aprender e melhorar.

Uma idéia para mim foi a criação de um projeto de estimação para a equipe experimentar coisas novas. As equipes podem, muitas vezes, apenas experimentar coisas novas para produzir um código evoluído. A única maneira que você pode ver como ele realmente funciona e como é fácil de manter, como muitos bugs existem e como eles são resolvidos rapidamente, a experiência realmente tem que ser prática. A menos que ele faça, você não pode realmente dizer se vai funcionar ou não. Às vezes as coisas acabam grandes e você decidi manter a experiência lá, às vezes eles acabam azedos e se pretende levr para outros projetos.  Por exemplo, fiquei muito impressionado com o Grails vários meses atrás e minha equipe decidiu construir uma aplicação web back-office com ele. Desenvolvimento inicial foi bem, mas que acabou por ser um desastre completo depois de bugs por causa de o ORM não ser fixo, upgrades quebraram a compatibilidade com versões anteriores e tivemos muito trabalho para manter a aplicação. O problema com algo parecido com isto é que é preciso ter tempo para mostrar como se comporta algo a longo prazo e o mundo não pára enquanto você está fazendo isso. No ponto em que você decide fazer alguma coisa, o projeto muda e outros componentes dependem do que você está fazendo agora. Isto é especialmente verdade se você quiser experimentar uma nova ferramenta de infra-estrutura.

Para resolver este problema, Whelan sugeriu a criação de campos de “prática” – têm uma base de código que está definido para jogar. Este poderia ser um projeto de estimação que a equipe está trabalhando em quanto está de folga, onde se pode experimentar e aprender novas ferramentas separadas do projeto de produção real. Para que isso funcione, pelo menos no meu caso, o projeto deve ser algo solto (sem dependências), para que você realmente sentir o alívio ou dor que o novo quadro ou a ferramenta trás depois de alguns meses. Se ele azeda, é um projeto de teste assim que você pode se dar ao luxo de tornar instável por um tempo. A manutenção de um projeto de teste trás trabalho suplementar e custo, mas isso deve ser orçado em R&D, que ajuda as equipes a aprender e não aumenta o risco da produção.

(mais…)

Filtros Bayesianos – parte 1

quarta-feira, 4 de novembro de 2009

Eu perguntei se alguem ia ler, e uns gatos pingados no twitter me disseram que sim, então vou escrever :)

Vou falar hoje sobre a possiblidade de classificaçnao de conteudo usando os filtros bayesianos.

Primeiramente gostaria de dizer que ele eh facil de implementar, veja definicao dele abaixo:

Pr(A |B) =Pr(B|A) x Pr(A)/Pr(B)

Bem, se voce nao fechou o browser apos o que leu acima quer dizer que estamos prontos para ver isso, juntos, ja que tanto quanto voce eu gosto do assunto, mas nao sou expert nele, e essas coisas eu aprendi pelo prazer de ver como funcionam(e saber que realmente funcionam).

Quem ja tomou uma cerveja comigo sabe que apos um certo numero de garragas/latinhas eu começo a divagar sempre sobre um assunto recorrente, algoritmos, algoritmos, algoritmos…(sim eu sou nerd e falo de programacao quando bebo)

E aqui temos um exemplo muito bonito de um algoritmo que apesar de simples, cumpre sua missão. Sua dificuldade esta no entendimento da teoria matematima que nele se encerra.

Uma das tarefas que os seres humanos mais praticam é classificar aquilo com que tem contato. Classificamos livros(romance, ficção, auto-ajuda…), música(rock, metal, punk, industrial, classica…)e tudo o mais que vemos pela frente, ate algoritmos, através dos padrões de projeto. Fazemos isso para facilitar nossa vida, afinal, categorizamos nossos gostos e podemos dar atenção a aquilo que nos interessa, sem nos perder no mar de informação que é gerado e apresentado diariamente.

Inicialmente, criamos o habito de classificar de acordo com o feeling, fazendo com que por exemplo, ao olharmos para uma pessoa tenhamos certeza de que ela não é uma pessoa legal, baseado numa sensação criada por um gesto, uma fala ou alguma outra coisa significante que ja notamos em alguem que pertencia a categoria dos “não legais”.

Depois, se a gente começa a ficar mais interessado em classificar as coisas, e sempre ficamos, passamos a usar um esquema de pontos: O burger King é melhor que o Mac Donald’s por que nele os lanches tem sabor(1 pt), tem o mesmo tamanho apresentado na foto(mais 1 ponto), o atendimento é melhor(outro ponto) e assim vai. Quanto mais pontos com relação ao outro, melhor.

Veja que nos dois apresentados acima temos situações onde a interação humana com o objeto classificado foi necessaria.

Porém, existem coisas que podem ser automatizadas e que podem ajudar nos humanos a resolver problema do dia-a-dia que de outra forma tomariam muito do nosso tempo.

Uma forma de automatizar essa classificação é através dos filtros bayesianos.

Como primeiro exemplo, vamos usar o classico de descobrir se uma mensagem é spam ou não.

Uma mensagem de e-mail é spam a partir do momento que ela é indesejada, correto. Ela é uma mensagem não solicitada que aparece na nossa caixa de e-mail e faz a gente perder um tempo batendo o olho e sacando que ela é spam ou abrindo ela para ver se tem algo importante ali. No final das contas, se fosse uma por dia, vá lá, a gente suportava, mas são muitas e fazem a leitura de e-mail ser uma tarefa penosa… fazem a gente perder tempo com coisas que não nos interessam de forma alguma.

Ai vem a sacada, podemos olhar as mensagem e classifica-las em spam e candidatas a leitura, logo, a gente pode escrever algo que ajude a fazer isso automaticamente.

Esse é um filtro que precisa ser treinado e para treinar vamos precisar de exemplos.

Vamos pegar cem e-mails que são spam, que a gente leu e confirmou que eram, e vamos pegar outros 100 que são bons para leitura.

No total temos entao 200 emails com 50% em cada categoria. A boa e a ruin(spam).

vejamos algumas palavras que apareceram em cada uma das categorias

ruim:

  • venda
  • viagra
  • remedio
  • cirurgia
  • ajuda
  • vagas
  • curso
  • assinatura
  • faculdade
  • promoção

bom:

  • venda
  • curso
  • assinatura
  • php
  • evento
  • faculdade
  • promoção

Ok, temos algumas palavras que ocorreram em cada uma das categorias que queremos classificar os e-mail que a gente recebe.

O proximo passo é ver quanto elas aparecem em cada uma das categorias. O quanto elas aparecem em cada categoria é a base para a avaliação da probabilidade de uma mensagem estar em uma categoria ou outra.

ruim (100 emails): Pr(palavra | ruim)

  • venda 40 ocorrências 0.4
  • viagra 60 0.6
  • remedio 70 0.7
  • cirurgia 30 0.3
  • ajuda 20 0.2
  • vagas 40 0.4
  • curso 30 0.3
  • assinatura 10 0.1
  • faculdade 5 0.05
  • promoção 50 0.5

bom(100 ocorrências): Pr(palavra | bom)

  • venda 30 ocorrências 0.3
  • curso 40 0.4
  • assinatura 10 0.1
  • php 50 0.5
  • evento 40 0.4
  • faculdade 30 0.3
  • promoção 15 0.15

A terceira coluna representa uma porcentagem de ocorrências das palavras em cada categoria.

Logo, podemos dizer que a palavras venda tem 40% de chance de estar num e-mail ruim(spam) e 30% de chance de estar em um e-mail bom. E isso ja nos diz algumas coisas. Diz que só a palavra venda, nessa amostragem de e-mail, não é uma boa candidata a indicar em que categoria o e-mail esta.

A avaliação que fizemos até aqui diz qual a probabilidade de uma palavra estar em uma categoria, logo, ela nos diz uma parte da equação, que é Pr(B|A). Probablidade de B(palavra) em A(categoria). Isso se chama probabilidade condicional. A probabilidade da palavra viagra na categoria ruim é de 60% e de php na categoria bom é de 50%.

Relembrando que:

Pr(A |B) =Pr(B|A) x Pr(A)/Pr(B)

resolvendo uma parte:

Sendo 100 a probabilidade da categoria (100 emails na categoria ruim, por exemplo)

e 200 a probabilidade do documento(total de email’s)

Pr(A | B) = pr(B|A) X 100 / 200

Digamos que chegou um e-mail na conta e dentro dele tinha somente uma palavra: viagra

Calculando a chance de ser um e-mail ruim

Pr(ruim | viagra) = 0.6 X 100 / 200

Pr(ruim | viagra) = 0.3

Calculando a chance de ser um bom e-mail, digno de leitura :)

Viagra não aparece na categoria “bom”, logo, temos 0% de change desse e-mail ser bom.

Então, que tal tirar esse e-mail da sua caixa de entrada, automaticamente, por que ele não vale seu tempo de atenção?!

Vamos avaliar outro caso: Outro e-mail, algum que tenha chegado com mais palavras, digamos: faculdade, curso, promoção e php. Aqui vai.

Pr(ruim| faculdade & curso & promoção & php) = 0.05 * 0.3 * 0.5 * 100 / 200= 0.00375

Pr(bom | faculdade & curso & promoção & php) = 0.3 * 0.4 * 0.15 * 0.5 * 100 / 200 = 0.0045

Pois é, esse e-mail pode aparecer na sua caixa de entrada, se olharmos o resultado ele esta mais para bom do que ruim.

Algumas observações devem ser feita nesse ponto.

Esta é uma demonstração do teorema de Bayes, mas na implementação existem outras considerações que devemos fazer que não foram incluidas aqui, como o fato de uma palavra, no inicio do treinamento do algoritmo poder ter ocorrido somente uma vez na categoria ruim e isso não poder indicar, de forma alguma, que ela representa somente mensagens ruins. Outro fato seria que o ideal é que um resultado da avaliação de uma categoria para outra tenham uma certa “distância” entre si, para poder garantir que realmente pertence a uma categoria, caso contrario, ainda pode haver dúvidas quanto a classificação. Mais um fato é que esse algoritmo tem se mostrado eficiente para qualificações, mas nao numa amostra tão pequena quanto a usada aqui.

Esse artigo tem continuação, na qual irei codificar o algoritmo na linguagem php, com cobertura das observações feitas acima. O artigo ja esta sendo escrito e vai ser postado, com certeza ate o fim dessa mesma semana pós Latinoware.

Algumas referências usadas aqui:

Livro Inteligência coletiva – toby Segaran (Alta Books)

Matematico Thomas Bayes

Teorema

Probablidade

Probabilidade Condicional

via @ivonascimento http://ianntech.com.br/

RED HAT REALIZA EM SEIS CAPITAIS ROADSHOW DE IMERSÃO NAS PLATAFORMAS RED HAT ENTERPRISE LINUX E JBOSS

sábado, 8 de agosto de 2009

Começando por Brasília e passando por Rio de Janeiro, Belo Horizonte, Porto Alegre, Florianópolis e São Paulo, evento visa apresentar as diversas tecnologías e novidades da empresa.

A Red Hat, Inc. (NYSE:RHT), líder mundial em soluções open source, realiza  no mês de agosto, o “Red Hat Roadshow 2009”, em seis capitais do Brasil. Começando por Brasília, no dia 4 de agosto, o evento destinado a parceiros e clientes visa apresentar as tecnologías e novidades da empresa, e casos prácticos de uso das mesmas.

O Roadshow terá duas tracks acontecendo em paralelo. Uma será voltada para infraestrutura e tratará da plataforma Red Hat Enterprise Linux com virtualização integrada, uso dos sistemas de gerenciamento Red Hat Network (RHN) e RHN Satellite e recursos para garantir a estabilidade dos sistemas com soluções de alta disponibilidade, todas integradas à plataforma Red Hat Enterprise Linux.  Também será feita uma demonstração das  tecnologias de Virtualização Red Hat (XEN, KVM, VDI, Gerenciamento e Provisionamento) e como se valer das mesmas para reduzir custos e incrementar performance dos sistemas virtualizados

A segunda track trata das soluções de middleware, com overview da plataforma JBoss Enterprise Middleware, incluindo principais casos de uso, benefício, SOA e desenvolvimento de aplicações. Também será feita uma apresentação sobre as melhores práticas e casos de sucesso com SOA, e uma segunda palestra de imersão prática nas demais soluções JBoss.

“Queremos proporcionar aos nossos parceiros e clientes de todo o Brasil a oportunidade de se aprofundarem nas inovadoras soluções de infraestrutura e desenvolvimento open source da Red Hat e da sua divisão JBoss, as quais têm auxiliado várias empresas a superarem seus desafios tecnológicos”, comenta Alejandro Chocolat, country manager da Red Hat Brasil.

O roadshow tem início no dia 4 de agosto em Brasília, das 8h30 às 17h00. Na seqüência, o evento segue para o Rio de Janeiro (05/08); Belo Horizonte (06/08); Porto Alegre (11/08); Florianópolis (12/08) e São Paulo (13/08).

Mais informações sobre o Red Hat Roadshow 2009 estão disponíveis no hotsite http://www.redhatroadshow.com.br/2009/index.html

Agenda:

Red Hat Roadshow 2009

Brasília
Data: 04/08/2009
Local: MERCURE LÍDER
Endereço: SHN Quadra 5 Bloco I – Asa Norte

Rio de Janeiro
Data: 05/08/2009
Local: SHERATON BARRA
Endereço: Avenida Lúcio Costa 3150 – Barra da Tijuca

Belo Horizonte
Data: 06/08/2009
Local: OURO MINAS
Endereço: Av. Cristiano Machado, 4001

Porto Alegre
Data: 11/08/2009
Local: SHERATON PORTO ALEGRE
Endereço: Rua Olavo Barreto Viana 18 – Moinhos do Vento

Florianópolis
Data: 12/08/2009
Local: MERCURE LINDACAP
Endereço: Rua Felipe Schmidt, 1.102 – Centro

São Paulo
Data: 13/08/2009
Local: AMCHAM
Endereço: Rua da Paz, 1431 – Chácara Santo Antônio

Sites
Red Hat Brasil — www.br.redhat.com
Red Hat Roadshow 2009  —  http://www.redhatroadshow.com.br/2009/index.html

Dica recebida pelo meu amigo Fabricio Tomasi

RibaFS – Cursos online gratuitos

quinta-feira, 16 de abril de 2009

Cursos disponíveis

Programa de Carreiras de Formação Tecnlógica – IBM e SENAI/SC

quinta-feira, 16 de abril de 2009

IBM – Analista de Suporte Técnico
Local: SENAI/SC – Florianópolis
IBM – Arquiteto de Informação
Local: SENAI/SC – Florianópolis
IBM – Desenvolvedor de Portais Corporativos
Local: SENAI/SC – Florianópolis
IBM – Gerente de Mudança, Configuração e Release (SCM)
Local: SENAI/SC – Florianópolis

ibm

Certificações Top em Tecnologia para 2009

quinta-feira, 19 de março de 2009

“Escrevo aqui uma lista das certificações top em tecnologia para este ano de 2009. Os critérios para escolha foram baseados na relevância do mercado e popularidade discutidas no site About.com.

Como a lista foi baseada em um site internacional, não coloquei o salário estimado como eles fizeram, porque aqui no Brasil a realidade é outra e o salário é bem menor do que o praticado lá fora.

toptechcerts

CCIE: O CCIE sempre está no topo de listas como essas. Muito provavelmente porque somente 26% passam, o que pode ser considerada como a mais difícil de todas as certificações em TI.

CISA: Uma certificação para Auditores de Sistemas, que diferentemente das certificações de mercado com orientação a funcionalidade, que torna-se obsoleta com o tempo, a certificação CISA possui foco às melhores práticas e conhecimentos necessários à eficiência no processo de auditoria de sistemas.

CCSE: O CCSE é a certificação em Segurança mais avançada da CheckPoint. Um CCSE é capaz de, por exemplo, identificar riscos para uma rede, criar um diagrama de rede e definir uma política de segurança.

MCSD: Microsoft Certified Solution Developer (MCSD) é uma certificação para Microsoft .NET, onde desenvolvedores de primeira linha projetam e desenvolvem soluções empresariais com ferramentas de desenvolvimento, tecnologias e plataformas Microsoft e com o Microsoft .NET Framework.

PMP: É um rigoroso Programa de Certificação Profissional desenvolvido e mantido pelo PMI – Project Management Institute. É uma certificação que requer muita experiência e habilidades para obtê-la.

certificationachieveCISSP: Certificações em Segurança estão em alta. Pessoas com a CISSP (Certified Information Systems Security Professional) ganham bem e precisam fazer apenas um exame para tê-la. Obviamente, é preciso alguns anos de experiência.

RHCE: Red Hat Certified Engineer (RHCE) é um teste baseado em desempenho que mensura a competência em sistemas reais. A principal certificação em Linux do mercado, o RHCE comprova as habilidades de configurar os serviços de rede e segurança em sistemas rodando o Red Hat Enterprise Linux. São mais de 5 horas de testes “hands-on”.

SCJP 6.0: Caso tenha vontade de se tornar um programador profissional e se aprofundar nas tecnologias java, essa é a certificação que deve ser adquirida. Com o SCJP, o profissional tem a possibilidade de se desenvolver futuramente nas plataformas JSE, JEE e JME. Ele também pode usar o SCJP 6.0 para as certificações “Oracle Certified Solution Developer” e “Oracle Certified Enterprise Developer”.

CAPM: Criada para ser um intermediário até a obtenção da certificação PMP®, a CAPM é indicada para pessoas que procuram estabelecer e demonstrar uma base comum de conhecimento e termos no campo do gerenciamento de projetos.”

Fonte:  GotchaIT

Adiciona a esta lista três certificações:

- LPI (agora atualizada e com a nova versão 303 – só existe um no Brasil, o meu amigo Leonardo Neves )

- Zend PHP 5 Certification – esta “separa o jóio do trigo”

- Zend Framework Certification – esta certifica que além da sintaxe o programador PHP tem o mínimo de procupação com padrões de projetos e engenharia de software

Qualidade de Software: custo ou investimento?

sábado, 14 de março de 2009

“O triângulo equilátero da gerência de projetos teve que sofrer ajuste. A máxima de que projetos de software são afetados somente por Custo, Tempo e Escopo caiu por terra. Atualmente um item, antes útil, que agora se torna diferencial competitivo, é “a tal” da Qualidade.

Mas o que é qualidade para você? E o que é qualidade de um software?
O meu conceito de qualidade de software pode ser um e para o cliente do projeto, outro completamente diferente. Num portal de notícias você aceitaria erros de língua portuguesa (com ou sem nova norma ortográfica da Língua Portuguesa)? E um e-commerce, seria tolerável sua venda não ser concluída por erro?

O conceito de qualidade é muito subjetivo, mas o fato é que todos nós, e o cliente não será exceção neste quesito, temos um padrão de qualidade esperado.

E quanto custa ter a qualidade desejada para o seu “sisteminha” funcionar corretamente? Opa! Corretamente? Acurácia é uma das Subcaracterística da Qualidade, segundo a Norma ISO/IEC 9126-1. É preciso profissionais capacitados e isso ainda é um dilema mesmo com o crescente número de certificações na área, cursos de formação e até MBA.

Testar com T maiúsculo

Muita gente ainda pensa, digo, gerentes, que testar é só sentar e ficar batucando o teclado ou dedilhando o mouse até que alguma coisa aconteça e que você nem saiba como foi causado. É preciso uma série de processos, conhecimentos, experiência e talento para esta atividade ainda tão negligenciada.

Bons profissionais de teste custam tão caro quanto muitos desenvolvedores, mas como ainda é uma área pouco valorizada pela maioria, guardemos as devidas proporções salariais.

É preciso prazo para que as atividades de teste sejam feitas de forma relevante ou do contrário será somente feito o Monkey Test: aquele teste que uma criança ou um macaco podem fazer e que, certamente, não garante absolutamente nada de qualidade.

Um erro muito cometido é deixar a atividade de teste para o final do desenvolvimento. A fase de desenvolvimento atrasa (ou isso só acontece nas Bahamas?), mas o tempo para testar parece não ser abalado por isso. Comparo a um paredão de tijolos: não é possível passar através dele.

Acredito que o sonho de todo bom desenvolvedor é ver um bug bem relatado, com passo a passo executado, resultado encontrado, resultado esperado, evidência do teste etc. Se os bugs são inevitáveis, que pelo menos sejam bem reportados. Isso é o mínimo aceitável. Sim, você também tem seu critério de qualidade e aceitação para atividades do cotidiano e por que não no seu trabalho?

Perfil profissional: não é para todos

Mas não pense que é qualquer um que pode sentar e testar. “Coisa de programador frustrado”, “atividade de segunda linha”, “analista de sistema que não é inteligente o bastante pra ser programador”… Tudo isso já ouvi dizer sobre testadores e/ou analistas de teste.
Isso não é verdade. Assim como existem desenvolvedores medíocres, existem testadores medíocres, gerentes medíocres e assim por diante em qualquer área de atuação profissional.
Entretanto, profissionais pouco qualificados, que são jogados ou caem de pára-quedas na área de teste, estão denegrindo a imagem desta.

Mas tenho que concordar que ouvir alguém que se diz Analista de Teste falar “pá mim fazer”, escrever “ecessão” entre tantas outras pérolas, dá medo só de pensar no resultado dos testes.

Algumas empresas antenadas com a nova tendência mundial de preocupação com a qualidade como diferencial competitivo, tem investido na formação de equipes de teste e ferramentas para automação. Pena que a maioria das empresas ainda veem como custo e não como investimento.”

Fonte: Fórum Meiobit

A equipe de um projeto de software

terça-feira, 10 de março de 2009

o clássico livro de Frederick Brooks, The Mythical Man-Month, um dos capítulos fala sobre a montagem de uma equipe de desenvolvimento. Ele apelida isso de equipe cirúrgica, na qual traça um paralelo entre uma equipe médica e uma célula de desenvolvimento de software.

A equipe cirúrgica de Brooks

O projeto descrito no livro é enorme e exigia uma quantidade grande de pessoas para terminá-lo. Para evitar os problemas de comunicação, adotaram o princípio de uma equipe cirúrgica, na qual temos 2 cirurgiões e 1 anestesista, sendo apoiados por várias outras pessoas. Lembre-se que o cirurgião deve ter foco total no trabalho e problema diante de sí e não pode nem deve ser distraído com coisas como buscar soro aquecido ou procurar luvas esterelizadas. Essa analogia serve para projetos de software, o dividir para conquistar. Um projeto é dividido em vários outros menores, com seu prazo e escopo definidos.

Inspirado no livro, fiz o diagrama abaixo, baseado nas minhas próprias experiências e literatura corrente como o SWEBOK. Aproveitei para usar outra analogia também. Espero que gostem e entendam.

equipe_Software

Essencialmente, temos uma equipe de pelo menos 3 pessoas. Um analista/programador principal, que toma as decisões de arquitetura, tecnologia e projeta o software e um outro analista/programador de apoio. Um coordenador ou gerente de projetos é necessário para tomar conta de toda a burocracia que afeta o projeto diretamente, mas não faz parte da construção do mesmo.

O diagrama acima é apenas uma sugestão do que seria uma célula de desenvolvimento e cabe a você adaptar e decidir o que é melhor para o seu projeto. Preste atenção na quantidade de pessoas, pois aumenta a dificuldade de comunicação e difusão de conhecimento entre seus membros. Uma equipe de desenvolvimento deve ser coesa na forma de trabalhar e se expressar no código-fonte gerado.

Lembrete: de nada adianta criar regras e padrões se ninguém irá aderir a eles. Determine o que é mais confortável e que irá ser seguido, mesmo debaixo de pressão. Algum planejamento é essencial, por menor que seja.

Outros analistas/programadores podem fazer parte do projeto, mas devem seguir as normas, arquitetura e estilo definidos pela dupla principal. Se isso não for seguido, o que você terá no final é código-lixo, com estilos de programação diferentes e que apenas uma ou outra pessoa será capaz de efetuar manutenções, alterações e correções. Nem sempre o programador concorda com uma abordagem. Ele pode e deve sugerir mudanças, mas cabe ao líder pesar se essa melhoria vale a pena ser propagada para todo o restante do código. Boas idéias e soluções sempre surgirão durante um projeto, mas coesão é mais importante que inovação depois de 10 meses.

Mas… e se a empresa for muito pequena? Euquipe?

euquipe

A primeira coisa a se fazer, é planejar seu tempo. Considere tudo, até os minutinhos gastos em reunião, telefonemas com o cliente, etc. Precisou passar no banco, contabilize. Justifique seu tempo com ajuda a colegas e avise o seu gerente o tempo todo e liste o que foi feito com o seu tempo durante o dia ou semana. São os 15 minutos mais bem gastos do seu dia, nem que precise ficar depois do horário ou chegar uns minutos antes.

Um bom gerente irá criar um escudo contra as burocracias e atividades da empresa que atrapalham o trabalho de análise e programação. A melhor saída é usar um velho conhecido, o TimeBox.

Ele consiste em definir o que pode ser feito dentro de um prazo de 2 semanas. E o que estiver pronto em duas semanas é entregue. O prazo nunca muda e sim os requisitos. Se um requisito é grande demais para ser feito e entregue em duas semanas, o CLIENTE deve ser informado e a decisão é tomada de forma conjunta. Lembre-se também que o tempo gasto em planejamento deve ser contado e justificado. É muito comum o capataz gerente considerar o seguinte no cronograma, se houver um: 2 semanas = 10 dias = 8-10 horas/dia => 80-100 horas-homem de programação. É mais seguro considerar 5-6 horas por dia no começo e ajustar semanalmente.

Não é possível 9 mulheres gerar um bebê em 1 mês. (Frederick Brooks)

Fontes:
Meiobit
Bicalho’s Memory About Fraked Up Projects
BROOKS, Frederick P., Jr. 1995. The Mythical Man-Month, Anniversary Edition. Reading, Mass.: Addison-Wesley.
(referência não está no formato ABNT)

Engenharia de Software: Anatomia de um Projeto Fracassado

domingo, 8 de março de 2009

Houve um feedback muito positivo sobre os posts relacionados a engenharia de software e projetos. É impressionate como as empresas e obviamente, as pessoas que fazem parte delas, continuam cometendo os mesmos erros. E mais, são erros tão comuns que não importa a tecnologia. Prazos muito curtos, estimativas completamente erradas, requisitos mutantes, gambiarra e fracassos, muitos fracassos.

O The Standish Group publica um relatório chamado The Chaos Report e mostra o cenário da indústria de software:

- Aproximadamente 18% do projetos são cancelados por atrasos e orçamento estourados.
- Aproximadamente 52% dos projetos estouram o orçamento e/ou o prazo.
- Aproximadamente 30% de todos os projetos de TI atingem seus objetivos dentro de prazo e custo estimados.

Se apenas 3 de cada 10 projetos dão certo, o que raios está havendo com os outros 7? A taxa de falhas é enorme e não há comparação com outros tipos de indústria e os motivos já foram descritos em inúmeros livros e um deles é: software é abstrato.

Quando alguém pede para colocar rodas de liga leve no carro, espera pagar por isso. O objeto “roda de liga leve” pode ter sua qualidade analisada imediatamente: menor peso, mais bonito, etc. A mesma lógica não funciona para software, já que ele não existe no mundo físico, é texto que magicamente faz alguma coisa acontecer dentro do computador.

“…colocar uns botões dinâmicos aqui, sem refresh… poderia ser em Flash ou quem sabe Silverlight. Hum… será que Flex seria vantajoso? Vamos fazer em Flex. Se ficar ruim, tentamos Flash e/ou Silverlight. Mas não pode atrasar!”

O que assusta muita gente é que não há linguagem, framework, ferramenta ou plataforma que resolvam problemas que estão além da tecnologia. As metodologias de desenvolvimento ágil como o Iconix, Scrum e XP tem o mantra “embrace change”, ou seja, não lute contra mudanças, mas integre-as ao seu dia a dia. Apesar disso parecer uma novidade, não é. Esse tipo de busca já havia sido objeto de pesquisa e análise nos anos 60 e 70 do século passado.

E o que é mais interessante. A lista que vou apresentar abaixo é antiga e muita gente lê e diz: nossa, verdade.

anatomia_fracasso

Agora, dos listagem acima, quantos deles o PHP, Ruby on Rails, Java ou .Net possuem influência?

Nenhum. São atividades que precedem a escrita do código e a escolha da tecnologia. Todas circulam em torno de Planejamento. Há um enorme vício em começar a trabalhar sem planejamento algum. É impressionante como o importante é sempre o mantra “começar o desenvolvimento o mais rápido possível”. É o velho pensamento de que se não há código, não há progresso.

Se traçarmos um paralelo com o mundo real, é como começar a construir um prédio, sem saber quantos andares ele vai ter.

Fonte:

Meiobit

Bicalho’s Memory About Fraked Up Projects

Os 25 erros de programação mais perigosos segundo a SANS

segunda-feira, 2 de março de 2009

Fonte: core.eti.br

Saiu no site da SANS a lista criada com o consenso entre varios profissionais e empresas do ramo de segurança e desenvolvimento descrevendo os 25 erros de programação mais perigosos para o desenvolvimento seguro. Eu vou traduzir os nomes e informação básicos mas o melhor é ler o artigo na íntegra, em inglês.

Os erros estão separados em três categorias: Interação insegura entre componentes, Gerenciamento arriscado de recursos, Defensas porosas.

Categoria: Interação insegura entre componentes

  1. Validação Imprópria de Entradas: Entradas que recebem dados e os aceitam mesmo sem certificar que eles são do tipo/formato esperado.
  2. Codificação ou Escape Impróprios de Saída: Saídas que não são codificadas ou escapadas corretamente são a maior fonte de ataques de injeção de código.
  3. Falha ao Preservar a Estrutura da Busca SQL (conhecido como Injeção de SQL): Se os atacantes podem influenciar as procuras SQL do seu programa, então eles podem controlar o seu banco de dados.
  4. Falha ao Preservar a Estrutura do Código da Página (conhecido como “Cross-site Scripting”): Assim como o anterior, se os atacantes podem injetar código ou scripts em sua página, eles podem controlar a página.
  5. Falha ao Preservar a Estrutura de Comandos do Sistema Operacional: Se você permitir que entradas ilegais sejam passadas para aplicativos do sistema operacional, o atacante pode controlar o servidor.
  6. Transmissão de Dados Sensíveis em Texto Puro: Senhas, dados de cartão e qualquer informação considerada sensível deve ser criptografada.
  7. Falsificação de Requisição Entre Sites: Um atacante pode criar uma requisição que é enviada a outro site forjando a origem e fazendo o mesmo partir de um usuário inocente, aproveitando credenciais de autenticação e acessos.
  8. Condição de Corrida: Atacantes vão sempre procurar por condições de corrida no software para conferir se alguma informação importante não é obtida no processo.
  9. Vazamento de Informações em Mensagens de Erro: Atacantes vão procurar por mensagens de erro que descrevam mais que o necessário, como nomes de campos SQL, objetos e bibliotecas sendo utilizadas.

Categoria: Gerenciamento arriscado de recursos:

  1. Falha ao Limitar Operações aos Limites de um Buffer de Memória: O conhecido buffer overflow.
  2. Controle Externo de Dados Sensíveis: Informações críticas que são mantidas fora de um banco de dados por questões de performance não deviam ser facilmente acessíveis por atacantes.
  3. Controle Externo de de Caminho ou Nome de Arquivo: Quando você usa dados externos para montar um nome de arquivo ou caminho de gravação, você está se arriscando a ser atacado.
  4. Caminho de Procura Inseguro: Se o caminho de procura de recursos estiver em algum lugar sob controle de um atacante, bibliotecas ou código pode ser inserido a revelia.
  5. Falha ao Controlar a Geração de Código: Caso o atacante consiga influenciar a geração de código dinâmico (se geração de código dinâmico for utilizada no programa) ele poderá controlar todo seu código.
  6. Download de Código sem Verificação de Integridade: Se você executa código obtido por download, você confia na fonte. Atacantes podem aproveitar esta confiança.
  7. Desligamento ou Liberação Impróprias de Recursos: Arquivos, conexões e classes precisam ser corretamente encerradas.
  8. Inicialização Imprópria: Dados, bibliotecas e sistemas inicializados incorretamente podem abrir margens para problemas.
  9. Cálculos Incorretos: Quando o atacante tem algum controle sobre as entradas usadas em operações matemáticas, isso pode gerar vulnerabilidades.

Categoria: Defensas porosas:

  1. Controle de Acesso Impróprio: Se você não garante que seus usuários estão fazendo apenas o que deviam, os atacantes irão se aproveitar de sua autenticação.
  2. Uso de um Algoritmo Criptográfico Quebrado ou Vulnerável: Utilização de algoritmos fracos ou comprometidos levam a falhas de criptografia e vulnerabilidades.
  3. Senha no Código: deixar um usuário e uma senha no próprio código traz inúmeros problemas.
  4. Permissão de Acesso Insegura para Recurso Crítico: Configurações, arquivos de dados e bancos de dados devem ter suas permissões de acesso protegidas.
  5. Uso de Valores Insuficientemente Aleatórios: Se você usa tipos de segurança que dependem de aleatoriedade, usar um gerador aleatório insuficiente só vai causar problemas.
  6. Execução com Privilégios Desnecessários: Se seu programa precisa de privilégios elevados para executar suas funções, ele deve abrir mão destes direitos assim que ele termina de executar as ações que precisavam dos privilégios.
  7. Aplicação de Segurança do Lado do Servidor pelo Cliente: Atacantes podem usar engenharia reversa em um cliente de software e escrever seus próprios clientes removendo testes e aplicações de segurança.

Algumas coisas foram realmente chatas de traduzir, sinta-se livre para sugerir correções.

intel

PS: Lembre-se sempre “os 25 mais” não quer dizer “os 25 únicos”. Grain of Salt faz bem.

Fonte: core.eti.br