segunda-feira, 5 de janeiro de 2015

Análise de Pontos de Funções e o dimensionamento do esforço de desenvolvimento


Estimar tempo, custo e recursos para um projeto de software é um grande desafio empresarial, pois são diversos fatores que podem influenciar seu sucesso. Muitos dos fracassos que verificamos atualmente são decorrentes em sua maioria da ausência de planejamento e levantamento adequado do esforço para ter o projeto realizado. Muitos profissionais argumentam que mesmo que todas as funções sejam adequadamente apuradas, os resultados ainda não serão precisos pois existem diferenças técnicas dos profissionais que realizam atividades semelhantes, o que ocasionaria resultados divergentes.
A Análise de Pontos de Funções (APF), ou no original em inglês Function Point Analysis, é uma das principais técnicas utilizadas no mercado de software para dimensionamento do trabalho realizado. Originalmente idealizada por Allan Albrecht em um trabalho realizado em 1979, atualmente é mantida pela International Function Point Group (IFPUG). A certificação CFPS, ou Certified Function Point Specialist, gera grande valor para os profissionais que conseguem aprovação no exame.
A base da contagem deve ser realizada após a etapa de análise de sistemas, independentemente da metodologia utilizada. A criação de um protótipo é considerada boa prática pois facilita a identificação das funções da aplicação pelo ponto de vista do usuário, e após esta etapa identificamos e enumeramos as entradas externas, as saídas externas, os arquivos lógicos interno, arquivos de interface externa e as consultas externas. Logo a seguir classificamos de acordo com a complexidade cada uma das funções identificadas, por exemplo em simples, médio ou complexo, de acordo com parâmetros de complexidade publicados pela IFPUG. Por último clasificamos os pontos de função ajustáveis em conjunto, para estarem em conformidade com a complexidade de processamento.
Apesar de não apresentar acuracidade de 100%, a APF possibilita aos gestores de projetos de software contratar recursos e estimar tempo e custos. Em equipes maduras e utilizando-se de métodos de melhoria contínua é possível incrementar os percentuais de acerto. Além de ser uma atividade de grande complexidade técnica, existem fatores como a heterogeneidade dos recursos, que podem gerar grandes desvios, mas é melhor do que não existir planejamento algum.

--Marco Aurélio Monteiro de Barros Thomé

Fontes:

Function Point Analysis - Training Course
David Longstreet
Longstreet Consulting Inc - Março de 2004 - SoftMetrics.com



terça-feira, 16 de dezembro de 2014

Evolução da interação homem x máquina e seu impacto em nosso cotidiano

Vivemos um momento de grande desenvolvimento tecnológico, onde o grande poder de processamento e a minituarização dos componentes dos computadores está permitindo inovações que parecem ficção científica. Novas formas de interagir com a tecnologia surgem a cada momento e para os usuários destes avanços tudo parece cada vez mais simples e natural.
Com o lançamento do iPhone em 2007 o conceito de realidade aumentada passou a fazer parte de nosso cotidiano, pois o dispositivo era muito mais do que um telefone com uma tela sensível ao toque, possuindo sensores de posicionamento e de geolocalização, permitindo que o telefone interagisse de forma natural com o usuário. A HP, uma das gigantes do mercado de computadores pessoais, já possuia desde o ano de 2000 o iPaq, que era um computador de mão, com tela colorida, telefone celular, tela sensível ao toque, e uma versão leve do Windows, mas que não interagia com o usuário de forma muito diferente que um computador tradicional.
O filme Minority Report, filmado em 2002, prevê em seu roteiro uma evolução da interface com o computador onde o usuário interage movendo as informações no “ar”. Atualmente podemos fazer algo semelhante com o videogame Xbox, da Microsoft, equipado com o sensor Kinect, onde a interface é operada com movimentos das mãos. Atualmente na Petrobras, em seu escritório no centro do Rio de janeiro, existem ambientes de realidade virtual onde os geólogos podem interagir com o fundo do oceano para aumentar a acuracidade na prospecção de petróleo.
Outro grande avanço é o projeto Glass, da Google, que é um óculos inteligente que projeta em uma pequena tela diversas informações para o usuário. Mas o mais formidável não é apenas a forma de interação, onde o usuário fala os comandos, mas é a tentativa do dispositivo de adivinhar o que o usuário deseja, oferecendo bons restaurantes para almoçar ou lembrando automaticamente os nomes das pessoas. E isso sem que o usuário dê comandos específicos.
Interfaces utilizando o poder do pensamento, como o vídeo apresentado no TED, é o próximo passo lógico, mas culturalmente teremos que repensar a forma como tratamos a tecnologia. O Google Glass que, apesar de ainda não ser um projeto final, já é uma realidade e pode ser comprado normalmente nos Estados Unidos e na Europa, mas já está sendo proibido em diversos locais,  como cinemas e bares, pois atinge a privacidade das pessoas. Em possíveis interfaces operadas por ondas cerebrais, impedir que em provas de vestibulares estudantes consultem as respostas na internet será um desafio técnico, pois teremos que identificar se óculos é inteligente ou não. E ainda existem dispositivos que estão sendo desenvolvidos que serão subcutâneos, e praticamente invisíveis.
A evolução das interfaces com os computadores está mudando a forma como enxergamos a tecnologia e todas as preocupações são relevantes. Muitos questionam se interfaces que são operadas com movimentos das mãos não poderiam causar lesões por esforço repetitivo, ou se operações com telas em óculos sobre os olhos não poderiam criar problemas de visão, ou se utilizarmos ondas cerebrais não poderíamos ter algum efeito colateral. Também temos as questões ligadas à privacidade, pois culturalmente não estamos preparados para estar hiper conectados, com novas interfaces nos acompanhando por todos os lados e filmando tudo e todos.

--Marco Aurélio Monteiro de Barros Thomé

Fontes:

sexta-feira, 24 de outubro de 2014

Modelagem de Processo de Negócios utilizando BPMN


Projetos de software são desafiadores na grande maioria das vezes, pois sempre existirão diferenças fundamentais entre a realidade do negócio, o que será solicitado pelos usuários das áreas de negócios da empresa cliente, e o que os analistas de sistemas serão capazes de entender. A estruturação de diagramas para melhor entendimento pelas áreas de negócio do que será feito é um grande avanço em comparação ao processo de documentação em linguagem corrente, onde normalmente a leitura não é feita com grande esmero, é um grande avanço.
Os diagramas orientados a objeto, como por exemplo o UML, são excessivamente técnicos e direcionados para a área de tecnologia. A necessidade de ferramentas de documentação de processos direcionadas para a área de negócio tornou-se imprescindível, pois onde, normalmente, o analista de sistema documenta o que entendeu em uma reunião com um usuário de uma área de negócios, este mesmo usuário fica responsável por documentar seu processo.
Segundo Hammer e Champy (1994), precursores da reengenharia, um processo são atividades realizadas em uma sequência lógica que tem como objetivo produzir bens ou serviços que geram valor para seus clientes. Acrescento também que processo tem vida longa, pois depois que um processo é implantado e aprimorado dentro de uma organização, ele só muda se a organização mudar por algum fator interno ou externo. Portanto, os usuários das áreas de negócios que possuem o domínio das necessidades empresariais.
O BPMN, ou, em português, notação para modelagem para processos de negócio, que é mantida pelo Object Management Group, é uma notação que não é direcionada para os técnicos de tecnologia, mas para os usuários das áreas de negócios. Por ser simples e fácil de aprender, o próprio usuário é capaz de desenhar seu processo empresarial, mas este deve ser um processo bem conduzido pelas lideranças, pois sempre existem possíveis discrepâncias entre a realidade e o que foi documentado. O analista de sistemas deve sempre questionar a profundidade do que foi entregue, pois desta forma todos os problemas serão minimizados.

--Marco Aurélio Monteiro de Barros Thomé

-Curso BPM - Mapeamento e Modelagem de Processos - INSADI - Business Process School, 2008
-http://www.devmedia.com.br/introducao-ao-business-process-modeling-notation-bpmn/29892

quarta-feira, 3 de setembro de 2014

O Ecosistema SAP e o desafio da seleção de Bancos de Dados

A escolha de determinado banco de dados para a implementação de um sistema de gestão empresarial, ou ERP como é mais conhecido, é um desafio técnico. Caso a escolha não seja a mais adequada a troca por outro fornecedor pode ser extremamente onerosa.
Diversos ERP´s minimizam a dificuldade desta escolha, pois só trabalham com determinado Banco de Dados. A Datasul, que hoje faz parte do Grupo Totvs, obriga a utilização do Progress, o Oracle Applications, atualmente Fusion, apenas trabalha com o banco de dados da mesma fabricante, apenas como alguns exemplos.
A SAP, gigante alemã de software que atualmente ocupa a primeira colocação mundial em implantações em grandes empresas de Software de Gestão Empresarial, por possuir uma gama enorme e diversa de clientes teve que se adaptar a diversos fornecedores de Bancos de Dados. Para novas implantações esta liberdade de escolha é mais um problema do que uma vantagem competitiva.
O SAP ERP, que anteriormente era conhecido como SAP R/3 ou SAP ECC, utiliza preferencialmente para Bancos de Dados Relacionais Oracle, Microsoft SQL Server e IBM DB2. Digo preferencialmente pois ainda existem opções incomuns, como o MaxDB, que é uma variação da própria SAP do MySQL, e de bancos que perderam a relevância como o SyBase, que atualmente também pertence à SAP.
Atualmente a SAP também está oferecendo um novo banco de dados proprietário, o SAP HANA, que é comercializado apenas em conjunto com hardware específico (appliance) e tem como proposta principal trazer grandes blocos de dados críticos para memória. Atualmente está sendo muito utilizado em sistemas Business Warehousing, que é o Data Warehousing da SAP, mas gradativamente está sendo utilizado em sistemas ERP.
Independemente da escolha do Banco de Dados a administração é realizada, na maioria dos casos, por transações internas do SAP. Isso causa grande confusão nos DBA´s ou AD´s neófitos no mundo SAP, pois não utilização como a mesma frequência os “Enterprise Managers” comuns em qualquer empresa, e sim transações como DB11 e DB12 dentro do próprio SAP. Atividades corriqueiras como agendamento de backups, verificação de performance de consultas e até mesmo integridade devem preferencialmente ser utilizadas por estas transações. Os programas tradicionais continuam disponíveis, mas com isso se perdem as rastreabilidades disponíveis.
Com a administração sendo realizada por programas internos no próprio SAP, apenas a instalação se torna muito diferente. Portanto a seleção tem que levar em conta a característica de cada empresa, onde custo ou performance serão decisivos para a escolha ideal.

--Marco Aurélio Monteiro de Barros Thomé

segunda-feira, 14 de julho de 2014

Crowdtest

O Crowdtest, ou em português algo como teste em grupo ou teste da multidão, é uma metodologia para a realização de testes de software que possui a proposta de realizar os testes em um espaço curto de tempo e pela metade do preço de um processo de testes tradicional. Basicamente o Crowdtest organiza o trabalho de teste e distribui a atividade para o “poder da multidão”, que só recebe por erro encontrado.
A ideia é realmente muito interessante, mas se limita a projetos de software com relativa simplicidade ou poucas etapas. No site a proposta base de sistemas a serem testados foca em web, desktop e aplicativos móveis, o que é muito genérico. Um sistema para web pode, por exemplo, compreender um escopo de comércio eletrônico, o que é relativamente simples de ser testado pela perspectiva do usuário, mas pode se tornar algo extremamente complexo caso tenhamos que testar as questões contábeis e de plano de contas das operações posteriores. Provavelmente só os contadores que participaram do blueprint do projeto possam testar esta etapa.
Mesmo em softwares ERP de mercado, como o SAP ou o Oracle Applications, que possuem funções standard utilizadas de forma similar pela maioria das empresas terão especificidades em seu projetos em que apenas os usuários-chave que participarem dos processos de desenho de solução poderão fazer parte dos testes unitários e integrados da solução. Mas é óbvio que grande parte dos processos que são standard poderão ser testados pela “multidão”, como telas de cadastro de clientes e de fornecedores, apenas como exemplo.
De qualquer forma a ideia de usar o poder da multidão para testar software é muito positiva, apesar de não servir para todas as situações.

--Marco Aurélio Monteiro de Barros Thomé

sexta-feira, 2 de maio de 2014

A evolução da rede que mudou o mundo

As guerras sempre proporcionaram  grandes avanços tecnológicos para a humanidade, apesar do terrível custo das vidas dos envolvidos nos conflitos. Apesar do criador do avião, o brasileiro Alberto Santos Dumont, não ter como objetivo usar sua criação para a guerra, o grande desenvolvimento da aviação se deu no objetivo das nações de obter diferencial competitivo nas guerras. O grande desenvolvimento da logística, dos processos de gestão, das indústrias, dos navios, dos automóveis, e, é claro, das armas, tiveram como força motriz os grandes conflitos, apenas como alguns exemplos. Mas todos estes avanços se incorporaram ao cotidiano da sociedade. A mesma tecnologia que criou a bomba nuclear também tornou possível a geração de energia, o desenvolvimento da gestão que foi necessária para levar um número enorme de pessoas para a frente de batalha também foi utilizada no desenvolvimento das organizações, entre outros inúmeros outros exemplos.
A internet foi resultado de uma necessidade militar óbvia, a de comunicação. Apesar do telefone e do telégrafo terem sido suficientes até a segunda grande guerra, com o desenvolvimento das armas nucleares estas tecnologias passaram a ter grandes fragilidades estratégicas. Caso alguma arma deste porte fosse detonada no caminho de uma central interurbana, o sistema ficaria fragmentado, gerando diversas ilhas que não conseguiriam se comunicar.
Durante a guerra fria, no final da década de 1950 o Departamento de Defesa Americano investiu sem sucesso em projetos de comunicação de dados altamente distribuído. O principal obstáculo para a implantação dos projetos foi uma grande empresa americana que detinha o monopólio das comunicações nos Estados Unidos, a AT&T, por preocupações com a manutenção de seu posicionamento empresarial. Mas com o lançamento do Sputnik, o primeiro satélite artificial, pela União Soviética, o presidente americano Dwight Eisenhower e seus acessores chegaram a conclusão de que os Estados Unidos não estavam organizados o suficiente para vencer as corridas tecnológicas da época. Compreendendo que as forças armadas disputavam entre si o orçamento de pesquisa do Pentágono, e isto não estava gerando resultados, foi criada uma única entidade de pesquisa de defesa, a Advanced Research Projects Agency, a ARPA.
Os primeiros anos da ARPA foram relativamente confusos, pois existia dificuldade até em definir sua missão com clareza. Os orçamentos eram baixos para os padrões praticados pelo Pentágono, e consistiam em apoiar pesquisas relevantes em grandes universidades. A sua estrutura física consistia em apenas um escritório.
Em 1967 Larry Roberts, diretor da ARPA, concentrou sua atenção nas redes, entrando em contato com diversos pesquisadores para decidir qual caminho tomar. Era uma área nova e tinha como grande desafio encontrar possíveis especialistas que pudessem contribuir com experiências práticas. Em um simpósio realizado em Gatlinburg, Tennessee, neste mesmo ano, ele teve contato com um projeto já implementado sob a gestão de Donald Davies, do National Physical Laboratory da Inglaterra, demonstrando que a comutação de pacotes de dados poderia funcionar. Ele retornou de Gatlinburg decidido a contruir o que seria conhecido como ARPANET.

--Marco Aurélio Monteiro de Barros Thomé