Agora o Assunto é Beagleboard.

Acabei de assistir a palestra do Francisco Alecrim sobre a Beagleboard. A primeira impressão é boa por que tinha muita gente interessada no assunto. O auditório não era muito grande, mas estava cheio. O Alecrim, começou arrumando todo o ambiente para fazer as demonstrações. De início parece uma parafernalha sem fim espalhada, mas só depois percebi que ele guarda todas as coisas para sua demonstração numa pequena frasqueira. Dessa forma, 5 minutos depois, o ambiente já estava pronto, e começou a apresentação.

O Francisco trabalha no OpenBossa que é uma divisão do INdT(Instituto Nokia de Tecnologia) voltada para o desenvolvimento de soluções open source.

Então ele começa explicando que a principal aplicação futura de variantes da Beagleboard, ou melhor, de placas de desenvolvimento com processadores OMAP (Cortex- A8 da família 3), são a criação dos novos netbooks. Ele faz a demonstração de um netbook chamado de Touch Book, que deve ser lançado em meados de 2010 e cujo o hardware interno é exatamente igual a uma beagleboard, com uma extensão na placa principal. Uma das suas principais características é a duração de sua bateria que é de aproximadamente 15 horas, o que serve para demonstrar como o consumo dessa placa é baixo.

Logo depois Alecrim começou a discutir sobre a utilização de linux em dispositivos embarcados, principalmente os voltados para Beagleboard e para as outras plataformas utilizadas pela Nokia. Essa empresa utiliza basicamente chips OMAP em seus celulares mais avançados como o N95 e o Nokia 810. Esses processadores são de séries anteriores (utilizam ARM11) a utilizada na beagleboard, mas já contam com versões experimentais de linux portadas para eles. A Nokia ainda não possui um telefone comercial que utilize linux, mas os primeiros devices devem ser lançados brevemente, utilizando a mesma família de processadores Omap que a Beagleboard utiliza(série 3). Dentre as distribuições citadas temos, Angstron, Mamona, Ubuntu, mas nada impede que seja criada um distribuição específica para sua aplicação já que o que importa são o kernel do linux e o rootfs específicos para arquitetura ARM, ambos disponiveis na internet, no git do kernel.org e no site do projeto da Beagleboard no google code.

Então porque utilizar Processadores OMAP?

Os OMAPs são processadores do tipo SOC ( System on Chip ) que possuem um DSP integrado junto com o processador principal e memória. Para quem não sabe, um DSP - Digital Signal Processar - é um processador especializado em processamento de sinais digitais, nessa caso, sinais de áudio e vídeo. Como já foi dito anteriormente os processadores Omap 3 que a Beagleboard utiliza são processadores Arm Cortex A8 que rodam a velocidade de 600Mhz, mas que conseguem chegar até 800Mhz(vide o novo iPhone que está para ser lançado). Além disso ele possui recursos de aceleração de vídeo com suporte a Open GL. Aliado aos recursos de processamento outra grande vantagem da Beagleboard é o seu baixo consumo de energia, de aproximadamente 2W.

A família Cortex é a nova família de processadores ARM, e vai equipar os principais devices que serão lançados no mercado nos próximos anos. Logo, portar sua aplicação para outro device com a mesma arquitetura de processador não deve ser um problema.

A vantagem de se utilizar a Beagleboard é o baixo curso do kit de desenvolvimento, e a possibilidade de criar novos produtos com ela. Isso decorre do fato do projeto de hardware e software ser totalmente Open Source, desenvolvido e suportado pela comunidade. Por esse motivo ela é uma placa de desenvolvimento que simplesmente funciona. A prova de sua viabilidade é o release dos primeiros netbooks, como o Touch Book demonstrado anteriormente.

Daí a palestra segue para o lado mais técnico da coisa, e o Alecrim mostra o processo de boot, e a sua configuração e a inicialização da Beagleboard. Mostra o acesso utilizando o minicom.

Daí voltamos a apresentação para duas distribuições linux, o Mamona e o Angstrom. O Alecrim explica que a maior diferença entre as duas é o maior suporte que o Angstrom possui, e o objetivo do Angstrom é para desenvolvedores de plataforma, enquanto o Mamona é feito para desenvolvedores de aplicação. Dessa forma o Mamona é muito mais fácil de instalar e utilizar que Angstrom. Um aspecto interessante é que os dois projetos dividem os mesmos meta-arquivos de compilação para a criação do ambiente. Além disso eles compartilham algumas soluções para problemas comuns.

Basicamente para a utilização do mamona você precisa baixar e instalar o script mamona-installer.

Após o término da palestra conversei tanto com o Ricardo Salveti, quanto com o Francisco Alecrim, e eles se empolgaram com a iniciativa do projeto Karmonitor. O mais envolvido é o Francisco, que me passou algumas dicas iniciais de testes que podemos fazer na Beagleboard. Os dois estão disponíveis e constantemente estão conversando sobre o assunto no freenode.

O único ponto negativo foi ter perdido a palestra do Salveti no dia 24. Mesmo assim fiquei conversando com o pessoal do INdT no stand do Qt(Cuja a empresa desenvolvedora foi comprada pela Nokia).

Para encontrar os slides da palestra, é só ir em http://franciscoalecrim.com

* Depois posto as fotos e o vídeo da demonstração feita durante a palestra!

Abraço!

Palestra Stallman. Vendo o gordinho "por cima"(literalmente)

Sinceramente, eu não conhecia muito sobre o Richard Stallman, mas hoje tive a oportunidade de ver uma de suas apresentações, e tive uma boa surpresa. Por tudo o que já me haviam dito anteriormente, esperava ver um cara uniformizado ( mesmo que fosse somente com a camisa do GNU ), mal educado, que fala alto, interrompe todas as pessoas, meio psico-comunista/freetard/motherfucker/qualqueroutroadjetivotosco que não sorri e come criancinhas. Para minha surpresa, e de boa parte da platéia, vimos o pançudinho um tanto alegre, pulando em uma perna só durante a leitura do seu currículo, e fazendo várias correções, algumas sérias e as outras somente para tirar um sarro do apresentador, e que chegou a ensaiar uns passinhos de dança, arrancando algumas risadas meio tímidas da platéia. Daí sucederam-se várias surpresas, como a primeira frase: "eu não vim aqui falar de software livre (pausa), mas sim das perguntas que vocês sempre me fazem no final das minhas apresentações…". Isso resumiria o espírito da apresentação que no fim das contas foi sobre, como a consciência de software livre e liberdade , e não a visão de Stallman, pode ser aplicada no mundo real, onde quem trabalha (e quem não trabalha também), quer receber alguma coisa por isso. Como o modelo de software livre, a irrestrita liberdade de uso, modificação e distribuição pode ser implementada.

Como primeiro exemplo Stallman, cita a origem da cópia de livros e manuscritos. O compartilhamento dos livros nasceu da dificuldade de replicação dos mesmos. Ou seja, dai se criou a cultura do compartilhamento de conhecimento, gerado pela tecnologia de produção de mídia que existia antigamente. Claro que com a evolução da prensa, a forma mais fácil de se compartilhar conhecimento tornou-se a impressão de livros o que foi incentivado pelas leis de direitos autorais, que permitiam que um autor imprimisse um livro de forma exclusiva, direitos esses que era cedidos pelos reis, principalmente quando os autores estavam de acordo com as idéias da realeza e a citavam de forma positiva no começo dos seus livros. Eles faziam isso para proteger seu direito de comercialização e de divulgação dos seus livros. Com a criação de editoras de livros, essa funcionalidade protecionista perdeu o seu principal motivo. A partir daí a grande questão é que com a evolução tecnológica muitas coisas mudaram, e entre elas o conceito de compartilhamento de conhecimento.

Seguindo a mesma linha de pensamento, Stallman expõe questões pertinentes da indústria de filmes e indústria fonográfica. Nesse momento a surpresa foi ver que ele admite que existam regras de direitos autorais, e que as mesmas podem ser válidas e legítimas se aplicadas de uma forma diferente da forma atual. Citando um exemplo do ciclo de vida de uma publicação nos Estados Unidos, que Stallman classifica como de 3 anos da data de lançamento, ele propõe um tempo real para a manutenção dos direitos autorais de 9 anos. Fazendo um comparativo e citando algumas conversas com escritores americanos ele cita um caso em que um escritor disse que qualquer valor de tempo maior que 5 anos seria um abuso em termos de restrições criadas para manter os direitos autorais. Justamente nesse ponto, quando todo mundo começa a se perguntar, se isso não vai contra o objetivo de todo escritor, Stallman lança a idéia de que o objetivo do escritor sempre é, tirando a minoria que deseja somente ganhar dinheiro, ter seus livros lidos. Voltando ao tema da música, ele expõe que somente as super estrelas da música ganham valores significativos com a venda de CDs. As gravadoras fazem com que o lucro dos artistas com CDs sejam "confiscados" para pagar pelos adiantamentos dados por conta da produção de discos, produção de turnês, promoção pessoal, imagem, etc. Então acreditar que as leis copyright protegem o artista, segundo Stallman, é um erro. Dessa forma ele propõe alguns métodos de cobrança mais justos para a indústria, como a utilização de uma taxa que incide sobre o valor pago por cada pessoa ao seu ISP, para financiar a música e cultura. Os recursos seriam compartilhados entre os músicos que você baixou alguma música. Outro exemplo, é de algumas iniciativas de músicos que disponibilizam as suas músicas gratuitamente em seus sites, e se você gostar, pode dar uma contribuição ao músico. Outra opção é o modelo de contribuição voluntária. Você escuta uma musica, e se você gostar, doa 1 real ou 0,50 centavos para o músico. Você faria isso semanalmente ou diariamente, ou simplesmente não faria a doação. Só doa quem quiser.

Acho que a grande sensação da palestra é que a visão dele, depende de alterações profundas na nossa idéia de recompensa de valores, comércio e cultura.
 

Buenas e me espalho! Essa também foi minha primeira experiência no FISL e também com o frio gaúcho… tchê!

E foi então que escolhi assistir a palestra do pessoal da Cobra Tecnologia do Banco do Brasil. Escolhi porque se tratava de Monitoramento de Ambientes utilizando Software Livre.

E este era o título da palestra daí! Bah!

Edmilson de Novais Silva era o nome da figura que se encontrava em nossa frente, rapaz jovem começou logo mostrando o que estavam utilizando como ferramentas livres para o monitoramento do seu parque: Zabbix, MySQL e CACTI. Parque esse que inclui até as transações de depósitos bancários feitos em caixas de auto-atendimento do Banco do Brasil.

Nisso, Edmilson demonstrou um demo de sua solução instalado em seu notebook, detalhando seus recursos e capacidades e comentando sobre a experiência da Cobra no monitoramento de seu ambiente utilizando estes softwares.

Vimos então que o Zabbix é capaz de realizar o monitoramento de servidores HTTP, recursos físicos, monitoramento em tempo real, gerar gráficos, sendo inclusive capaz de monitorar máquinas virtuais Xen.

Ele disse também que estava previsto para o Zabbix o monitoramento de disco, tornando possível em versões futuras, o recurso de alerta para falha de disco em RAID, recurso muito importante segundo ele, pois evita a descoberta deste problema somente na visita do administrador ao CPD, quando as luzes do servidor estariam, nesse caso, piscando desesperadamente.

Edmilson chegou a comentar que haviam experimentado a solução Hyperic, disse ser uma ferramenta excelente também, que atendia bem a todos os requisitos de sua equipe. Porém foi batido o martelo para o Zabbix pois, segundo ele, o Hyperic consumia um pouco mais os recursos de processamento da máquina instalada.

O CACTI foi utilizado para a gerência da banda de rede e monitorar o tráfego via SNMP, foi falado pouco sobre ele, talvez quase nada.

Minha impressão foi de uma palestra um pouco fraca, um pouco tensa, não sei. Mas o palestrante soube bem responder as dúvidas, inclusive sobre questões como SLA, mostrando, pelo menos ao meu ver, que o pessoal dos órgão públicos tem muita coisa pra falar, muita experiência com Software Livre pra compartilhar e bom conhecimento técnico, faltando talvez, somente um traquejo a mais para palestrar.

Bom, temos mais palestras ainda pra comentar mas hoje vou ficando por aqui.

Até a próxima!

Após me recuperar do frio de Porto Alegre fui ter minha primeira experiência no FISL 10 na PUCRS. Depois de muito escolher, finalmente, decidi qual palestra assistir, a intitulada "VoIP sobre Redes sem Fio IEEE 802.11 (Wi-Fi) Limitações e Tendências", ministrada pelo palestrante Arlindo Flávio da Conceição.

A palestra foi sobre como integrar as duas tecnologias, VoIP e Wi-Fi, e os problemas decorrentes dessa integração.

O palestrante mostrou as pesquisas feitas no estudo relacionado ao já conhecido problema de perdas de pacotes e atrasos em redes Wi-Fi, o principal gargalo para a implementação de VoIP nessa tecnologia, pois a recepção em redes Wi-Fi ainda é irregular. A taxa de perda de pacotes na rede sem fio Wi-Fi é maior do que a da internet via cabo.

Na palestra, aprendemos que na comunicação VoIP, quando a perda de pacotes é pequena, ela não é percebida pelo usuário, mas se a taxa de perda for muito alta, a comunicação ficará prejudicada resultando no que é chamado de "voz picotada". É impossível recuperar dois segundos de perda de voz.

Também foi comentado a respeito do envolvimento de fabricantes do ramo de telefonia móvel na tecnologia VoIP + Wi-Fi. Umas das primeiras empresas a usar essa tecnologia foi a Motorola e atualmente existem diversas outras investindo nela.

Aqui no Brasil, o aparelho mais conhecido com este recurso é o N95 da Nokia.

A idéia destas empresas é que vários pontos de acesso do Wi-Fi sejam conectados à linha telefônica.

Uma curiosidade explicada pelo palestrante, o que acredito ser o que a maioria das pessoas não sabia (nem eu), é que Wi-Fi é uma marca, não uma tecnologia. Ela deriva da Wi-Fi Alliance para descrever a tecnologia da rede sem fio Wlan.

Tirei diversas fotos da palestra, postaria aqui no blog se não fosse o triste fato de terem roubado a minha câmera no evento. Como diria o Fábio de "A fazenda", o blog ficaria "beim melhor" (SIC).

Fico por aqui, tenho que dormir agora.

Até a próxima!!!

Pessoal acho que vocês estavam esperando pelo primeiro post sobre o FISL 10. Demorou, mas finalmente, temos conexão para mandar alguma coisa. Então vamos mandando as primeiras impressões:
 
Começamos nossa jornada pela palestra de Peter Sunde do Pirate Bay, chegou fazendo muito menos estardalhaço do que o esperado. No começo ele expôs a origem de tudo, o que para as vendedoras de jogo, filmes e software pode ser descrito como a "Origem do Mal". Como a maioria de nós ele sempre teve o costume de compartilhar arquivos, jogos e músicas com os amigos. É o conceito de copiar e colar, compartilhar e distribuir. Então, algum tempo ele se uniu a seus dois amigos Fredrik Neij, e Gottfrid Svartholm(A.K.A Anakata), para fazerem um servidor de "coisas" para eles e seus amigos. Então nos primeiros slides, Peter mostra o passado dos servidores do Pirate Bay, um computador comum, com um servidor de rede e um balanceador de carga, montados em um rack de 19” improvisado, com fiação mal-feita e mal organizada. Para acesso a internet, a banda que eles dispunham era de somente 1 mbps. A coisa toda cresceu, e 2 anos depois eles já contavam com mais de uma dezena de servidores em rack, e um link de 10mbps. Com o crescimento do site e o aumento no número de usuários e arquivos compartilhados, a grande maioria arquivos protegidos com regras de copyright de outros países, a iniciativa de Peter e seus amigos começou a chamar muita atenção, principalmente das grandes produtoras cinematográficas de Hollywood. Daí(to começando a falar que nem os gaúchos), começou a onda de cartas, primeiramente bem educadas, e depois com a contratação de agências de advocacia americanas especializadas em direitos autorais, cartas contendo vários tipos de ameaças citando leis não aplicáveis fora de seu país de origem, devidamente respondidas por seu amigo Anakata, que conseguiu aumentar ainda mais a ira dos advogados. Peter nos mostrou alguns casos curiosos como a primeira vez em que os servidores foram apreendidos. Para isso as empresas puseram um detetive particular atrás do Anakata para descobrir a localização dos servidores do site. O interessante é que o site divulgava essa localização em um dos seus links. Quando a localização dos servidores foi "descoberta", os advogados mandaram novas cartas ameaçando o grupo, mas como não haviam leis para puni-los ou para desligar os seus servidores então esses avisos também foram desconsiderados. Para contornar a situação, as empresas americanas "convenceram" a polícia sueca a fazer uma busca e apreensão nos servidores do Pirate Bay(que a propósito também hospedavam vários serviços de outras empresas). Essa foi a primeira atuação ilegal contra o site, o que gerou algumas reações por parte dos três amigos:
 - Os servidores do Pirate Bay agora são descentralizados, e não se sabe a localização deles, somente de um dos concentradores centrais.
 - Uma lista com as possíveis causas de queda do pirate bay, e o tempo que eles levam para levantar o servidor novamente. Coisas do tipo:
    # o Anakata ficou realmente bêbado, deu algum problema nos servidores e não tinha ninguém perto para ajudar - 7 dias
    # O Fredick ficou doente - 4 dias
    # Alguma empresa, ou a polícia sabotou os servidores do Pirate Bay - 3 dias fora do ar.
 
Depois de demonstrar outros casos de abuso, e outras situações engraçadas Peter encerra a palestra dando a sua visão sobre compartilhamento de arquivos, de que é da natureza humana compartilhar, e que o as pessoas tem o total direito de fazer isso. Muito interessante!
 

Vou ficar devendo as fotos agora porque to sem o cabo, mas mais tarde eu posto!

Abraços!
 

Agora que já sabemos por que usamos métricas e como medimos e estimamos através de PCU, resta saber como é o dia-a-dia trabalhando com isso. Vamos abordar aqui como estimamos o tamanho de um projeto novo, como a métrica se comporta ao longo do projeto, o que apresentamos aos clientes, como fazemos as cobranças e mais alguns temas afins.

Como estimamos o tamanho de um sistema novo

Podemos nos enganar achando que numa fase de inception, no início do projeto, conseguiremos levantar 80% dos UC’s que serão trabalhados. Mas a verdade é que tanto o cliente quanto nós ainda iremos aprender muito sobre o projeto ao longo dele, e ainda vamos mudar muito de idéia a respeito do que deve ou não fazer parte do sistema. E isso é muito bom! O que precisamos mesmo é de um mecanismo para servir de base para começarmos o trabalho e podermos negociar. Termos uma primeira idéia com nível de incerteza aceitável.

Se houver liberdade para trabalhar assim, o que fazemos é levantar e modelar os casos de uso do sistema, assim como explicado no post anterior; casos de uso pequenos, procurando por relações 1xN, procuramos por relatórios, grandes cadastros, includes e extends ocultos e o que mais pudermos. Não é necessário detalhar nenhum caso de uso, apenas contar os casos de uso e atores conhecidos até o momento.

Após esse cuidadoso levantamento, consideramos todos os casos de uso como médios e fazemos a contagem. Essa estratégia é parecida com a proposta da NESMA, usada em APF. Ao longo do projeto, novos cenários e casos de uso vão surgir, alguns casos de uso serão simples, outros se tornarão complexos. Alguns irão desaparecer também. O que criamos é um tipo de “crédito” em funcionalidades do sistema, um número plausível com que o cliente pode trabalhar.

Se ao longo do projeto o cliente perceber que precisava de menos coisas, só paga pelos créditos utilizados. E se percebe que não vai caber tudo, vai ter boa parte entregue, funcional e vai ter consciência das razões da estimativa não ter contemplado tudo. É uma questão de método de trabalho. Estimativas por definição sempre incluem um certo grau de incerteza. O que fazemos é torná-lo gerenciável e claro.

E isso tem funcionado muito bem por conta de algumas das maiores vantagens e principais características da métrica de PCU: transparência, simplicidade e facilidade de comunicação. Ora, é tão fácil para os clientes se acostumarem ao linguajar de cenários, casos de uso e atores que fica fácil negociar. Eles compreendem muito bem a dimensão dessas coisas, aprendem rapidamente a fazer a contagem e podem gerenciar seus recursos e desejos ao longo do projeto. É muito menos abstrato que ALI’s, EE’s, CE’s e muito mais fácil de se trabalhar pois não precisamos decompor campos e/ou tabelas. O próprio cliente se capacita em fazer estimativas velozes do sistema pra saber o que mais pode caber, quanto mais gastaria para adicionar alguma coisa e assim por diante. Sentem-se com o escopo sob controle. Temos clientes que têm até preferido mudar de APF para PCU por conta disso.

Como a métrica se comporta ao longo do projeto

Quando falamos de performance média no post anterior, usamos a palavra “média” por uma razão bem importante: ela não será sempre a mesma ao longo de todo o projeto. Observem os gráficos de performance em horas/PCU desses 2 projetos em que estamos trabalhando atualmente:

 
Horas/PCU - Projeto 2

Como a empresa normalmente pega projetos começando do zero, a performance inicial tende a ser baixa, resultando num alto número de horas/PCU. No começo, muitas questões do ambiente têm que ser resolvidas, os frameworks definidos e estudados, boa parte do negócio deve ser aprendida, a equipe pode estar “fria”, enfim, vários fatores contribuem para a baixa performance.

Mas não se assuste! Ao longo do tempo, a performance tende a estabilizar num número menor. Quando falamos em performance média para o projeto, estamos levando em consideração essas variações inclusive. Isso quer dizer que podemos num projeto aferir uma performance menor que 15 hs/PCU ou até maior que 40 hs/PCU, mas na média do projeto todo, ficaria nesse intervalo.  (Observem no projeto 2 também, o efeito de pesada documentação feita ao final do projeto. Espera-se o mesmo efeito no projeto 1).

Se a equipe já tiver trabalhado no projeto (por conseqüência ele já teria sido iniciado), já conhecer bem o negócio e o código, essa curva tende ser bem mais suave. Isso deve ser considerado ao gerar uma estimativa de performance para o projeto. (Assim como a natureza das próximas funcionalidades: seriam parecidas ou totalmente diferentes das feitas anteriormente? Se forem diferentes, provavelmente a performance média não será a mesma.).

Medidas, cobranças, melhorias e manutenções: o dia-a-dia no projeto

Agora que já sabemos como estimar e como medir software com PCU, resta saber como tratamos isso no dia-a-dia de um projeto.

Normalmente sustentamos alguns modelos de casos de uso ao longo do projeto. Alguns com a visão geral do projeto e alguns que evoluem ao longo das entregas. A visão geral nos mostra o tamanho atual do projeto, conforme o conhecemos.

Utilizamos cores para apresentar os UCs entregues (em verde) e os planejados para a próxima iteração (em azul), além de notas para indicar quais cenários foram ou não desenvolvidos. Ao longo do tempo, o cliente pode ver como evolui a compreensão dele  em relação ao sistema, bem como o que falta e o quanto já foi feito.

Este é um modelo apresentado para entrega. Os Ucs e cenários amarelados já estavam prontos. Os em azul foram os entregues e aprovados pelo cliente na mais recente iteração. Fazemos as medições e atualizações nos modelos mensalmente e os entregamos anexados à uma planilha com a diferença da contabilização dos pontos entre esta iteração e a passada => e é isto que é cobrado.

Por fim, os atores são contabilizados quando um usuário com o perfil do ator em questão já puder usar o sistema, tratadas as questões de autenticação e autorização inerentes a essa funcionalidade.

Parece simples? De fato, só complica um pouco quando você tem vários modelos para a visão geral e para a entrega, mas o princípio é o mesmo.

Se um projeto já existe e entramos para fazer evolução ou manutenção, fazemos a modelagem através do nosso método, como se fosse a visão geral (inclusive identificando os cenários com notas), e tratamos as evoluções ou manutenções como novos cenários nos UCs já existentes ou como novos UCs conforme o caso. Não importa como o projeto tenha sido ou será especificado, nem mesmo se a especificação esteja desatualizada, podemos fazer uma nova modelagem de casos de uso seguindo-se um padrão e tê-la como referência para estimar ou medir o tamanho do sistema.

O Problema com Mudanças

Há um ponto falho tanto em PCU quanto em APF que é o tratamento de mudanças. Numa casa você pode fazer uma reforma, digamos, mudar um piso ou quebrar uma parede pra instalar uma nova tomada, e o tamanho dela em m2 continua sendo o mesmo, não? Em APF ou PCU, o mesmo pode acontecer. Podemos ter mudanças que não implicam em novos UC’s, ou novos cenários, ou a quantidade de campos e operações continuar a mesma.

Mas na casa apesar do tamanho não ter mudado, a reforma gerou mais trabalho e mais custos. Logo, não seria justo refletir o mesmo nas métricas? Quando há possibilidade de se negociar isso, entramos em acordo com os clientes e tratamos as mudanças também como se fossem novos cenários ou novos UC’s. Deve-se haver muito bom senso no dimensionamento das mudanças, ou a confiança pode ser quebrada e isso é altamente prejudicial para qualquer projeto. Recomendamos total transparência nesses casos.

Na intenção de resolver esses problemas, também tenho visto manuais com padrões definidos para certos tipos de mudança, por exemplo: “alteração de botão equivalerá a 0,1 PF” (em recente edital do Min. Transportes saiu um desses).

Se não houver como negociar, o esforço de mudanças deve ser estimado e refletido na performance média. O problema é que isso pode inibir mudanças para se manter a performance estimada, o que não é desejável. Mudanças devem ser bem aceitas e são muito saudáveis para os projetos.

Observem que, ao contrário de PCU, o fato da APF ser aderente à norma ISO/IEC 14.143, que define um modelo para medição funcional de software e ter o manual padronizado pela ISO/IEC 20.926; não resolve bem este problema. Tanto as normas quanto as métricas ainda carecem de evoluções e adequações. Aqui trago apenas uma proposta, que é a forma com que trabalhamos.

Acredito que utilizar mais de uma métrica para gerar estimativas sempre agrega valor à estimativa. Se puder usar ainda outras métricas, use-as! Experimente! Combine! Existem várias. Tem uma cujo nome dá medo só de ouvir: a “Complexidade Ciclomática”, que mede a quantidade de caminhos linearmente independentes através do código fonte de um programa. Imagine seu chefe pedindo pra você estudar isso que a partir da semana seguinte a empresa vai passar a adotá-la? Eu sairia correndo gritando pela porta. Mas a idéia de verificar o tamanho programaticamente a partir do código fonte é boa! Acho que o caminho é por aí, mas primeiro haveria de se resolver a questão da qualidade (tratada no artigo da revista). Aqui todos concordamos que nenhuma métrica mede direito o que realmente dá trabalho de ser feito num software.

Organização e Certificação

De fato não existe uma organização responsável por padronizar e evoluir a métrica de PCU como o IFPUG. Tão pouco existe uma certificação na aplicação da métrica, logo, também não há um grupo de profissionais certificados que saibam comprovadamente aplicar a métrica e apoiar os demais. Isso não torna a métrica ruim. Talvez menos segura. O que existem são tímidas iniciativas independentes de uso, evolução e padronização, como a que apresentei aqui e as dos artigos indicados.

Pensando bem, até que seria uma boa criar uma organização para este fim, cobrar uma anuidade, ter um programa de certificação para valorizar o pessoal no mercado, não? Da forma que está hoje, ninguém está ganhando nada… isto não pode ser bom! :)

Espero ter contribuído de alguma forma para suas estimativas, medições e idéias! Quaisquer críticas, contribuições ou dúvidas serão bem-vindas!

[]s Willi

<!DOCTYPE html PUBLIC “-//W3C//DTD HTML 4.01 Transitional//EN”> Obrigado a todos que colaboraram na discussão sobre o Colapso 2.0.  Prossigamos com o raciocínio….

No post anterior eu falei do nosso fomento à cultura do empreendedorismo, do maior comprometimento e cumplicidade que se cria entre equipes e empresa e a crescente tensão gerada pela redução das diferenças de poder entre todos.

No processo de comprometimento crescente das equipes, naturalmente, aos poucos, desenvolve-se o senso crítico a respeito da distribuição de responsabilidades e de lucros, da propriedade do patrimônio em construção e das práticas até então em uso. (…) quanto mais 2.0 a empresa for, mais poder seu pessoal terá. Quanto mais poder, mais críticos serão. Quanto mais críticos, mais tenso será o ambiente e mais insustentável tornar-se-á a situação, até o ponto em que uma grande decisão há de ser tomada: corta-se as asinhas assanhadas de todos e retorna-se ao estilo padrão de empresa, ou acata-se a todos os bombardeios e promove-se uma grande revolução interna.

Obviamente, como bem disse @FabricioBuzeto em seu comentário, nenhum dos extremos é uma escolha inteligente. É óbvio que não vamos abandonar agora todo o processo e prol do comodismo fabril 1.0. Por outro lado, também não parece ser uma descisão esperta incentivar a ingerência anárquica e desmedida. @RicardoFunke foi bem feliz em sua citação.

Na vida, sempre temos que escolher entre o que é fácil e o que é certo!

E, neste mar de questões, temos quebrado a cabeça em busca de alguma proposta coerente com nossa filosofia e com a necessidade de sobrevivência empresarial.

Por nossa filosofia, as equipes devem ser autônomas para a definição dos melhores métodos e técnicas para seus projetos e acreditamos que essa autonomia não deve ser dada arbitrariamente, mas conquistada pelo mérito. Mas, para sobrevivência empresarial, esta autonomia não deve sobrepor as prioridades financeiras e estratégicas da empresa.

A questão meritocrática foi discutida no Manifesto 2.0. Mérito se conquista de diversas formas, mas todas convergem à confiança. Disso, fica explícita a grande barreira do empresariado 1.0 em atribuir autonomia a seus times. Se autonomia se conquista por mérito e mérito é uma questão de confiança, enquanto não houver cumplicidade integral entre a alta gestão e os grupos operacionais, dificilmente haverá a plena confiança e, logicamente, nunca se estabelecerá o livre direito às equipes de de fazer e acontecer.

Aos olhos externos, toda essa discussão parece superficial e muito óbvia de ser resolvida (aliás, conduzir uma empresa/equipe/família, de uma forma geral, é muito óbvio até você ter a sua própria). Mas pense comigo: um belo dia, você, profissional de sucesso, resolve abdicar de todas as benesses que o status lhe confere, sair de sua zona de conforto e iniciar a construção de um negócio próprio. Imediatamente, seus rendimentos mensairs serão reduzidos a 50, 30 ou 25% do anterior. Em pouco tempo, a alegria  de não ter chefe é cedida à cobrança constante e intensa de seus poucos clientes conquistados a ferro e fogo.  A muito custo e pauladas, o negócio começa a entrar nos trilhos e você vê um pequeno ponto luminoso no fim do túnel. Daí, insurge um movimento que reivindica mais direitos e maior autonomia para conduzir parte do seu negócio o.O. Pombas, não foi o sangue deles que escorreu para que sua empresa chegasse até aqui. Não tiveram o salário reduzido a 1/4 para garantir a sobrevivência do empreendimento. Por que raios então que agora chegam, a esta altura do campeonato, e ainda pedem pra sentar na janelinha? Você, como empresário, não se sentiria desconfortável e não ficaria com a pulga atrás da orelha? Você como mãe ou pai, não se sentiria insultado se um desconhecido lhe desse pitacos sob a criação de sua criança de 6 anos de idade? Exageros e sofismas a parte, acho que é mais ou menos este o sentimento que paira sob uma mente da maioria dos donos de empresa.

Voltando à questão, você daria este voto de confiança a pessoas que não carregaram a mesma cruz que você? Quais serão suas verdadeiras expectativas? Será que realmente têm valor a agregar ao negócio ou não passam de oportunistas embebedados por ideais comunistas com grande potencial de destruir retroceder sua empresa? Mantendo a metáfora, uma doméstica com 6 meses de casa tem ou não autonomia para conduzir a parte da educação de seus filhos? São essas as questões que fazem com que as empresas de hoje seja como são.

Ouvi recentemente um empresário dizendo que não abre mão do controle de sua área por não acreditar que outras pessoas terão a mesma capacidade de gestão que a sua. Ignorando a prepotência e arrogância, até que faz sentido. Mas então, como resolver a grande questão do universo sem rachá-lo ao meio?

Dizer que o poder deve ser igualmente repartido dentro da empresa, independente de raça, cor, credo, formação e salário não vale, pois isso significaria uma mudança de paradigma tão, mas tão grande, que talvez apenas 0.0001% das empresas do mundo aceitariam fazer. Seria o extremismo que o @FabricioBuzeto mencionou em seu comentário no post anterior. Então, como chegar a um meio termo?

[]s

<!DOCTYPE html PUBLIC “-//W3C//DTD HTML 4.01 Transitional//EN”>

P2V significa Physical to Virtual. O que vamos fazer agora é a migração de uma máquina física com RHEL4 para uma máquina pára-virtualizada, mantendo a versão do RHEL.

$ cat /etc/modprobe.conf
alias eth0 xennet
alias scsi_hostadapter xenblk

# My RHEL4
Xen guest name = "RHEL4"
memory = "256"
uuid = "13db28ea-8536-53dc-3646-1f20fcc1199b"
disk = [ 'phy:/dev/VolGroup00/RHEL4,xvda,w' ]
# disk = [ 'file:/path/to/disk/image,xvda,w' ]
vif = [ 'bridge=xenbr0,mac=00:16:3e:xx:xx:xx' ]
bootloader="/usr/bin/pygrub"
# vcpus = 2 

 # xm create -c /etc/xen/nome_da_maq 

• Posted in infra
• Tags infra, infraestrutura, linux, p2v, redhat, rhel, virtualização, virtualization, xen
• Meta 1 comment, permalink, rss, atom