Neomind

Tag: Desenvolvimento (DEV)

Descubra conteúdos que abordam os diferentes aspectos do desenvolvimento (DEV) e entenda mais sobre soluções de software.

  • Conheça sobre o Dimensionamento de Hardware (Sizing)

    Conheça sobre o Dimensionamento de Hardware (Sizing)

    Ao adquirir um software ou implantar uma nova funcionalidade, as primeiras perguntas geralmente são: “Qual o requisito de hardware?” ou “O servidor vai suportar?”.

    Outro cenário bastante comum no qual aparece a mesma dúvida é quando o gestor de TI começa a receber reclamações de usuários de seu sistema em relação ao desempenho da aplicação. Neste momento, surge o questionamento: “Será que o ambiente (servidor) ainda está adequado para a demanda atual?”.

    Essas são dúvidas muito comuns, todavia, como diversos fatores estão envolvidos, encontrar as respostas não é algo tão simples assim. Para isso, é necessário entender sobre Dimensionamento de Hardware, também conhecido como Sizing.

    Antes, temos que entender sobre Dimensionamento de Software

    Para falarmos de Dimensionamento de Hardware, é importante abordarmos rapidamente o Dimensionamento de Software, o qual consiste em transformar em números o tamanho de um software (ou parte dele). Neste caso, estamos falando em determinar o tamanho do software, mas não o esforço que foi empregado para desenvolvê-lo.

    Algumas maneiras de medir o tamanho de um software são analisando seus Pontos de Função ou FP’s (Function Points), ou LOC (Lines Of Code). O tamanho e complexidade do software são fatores muito importantes para o dimensionamento do hardware que irá executá-lo.

    E o que é Dimensionamento de Hardware?

    Uma definição simples de Dimensionamento de Hardware é: “Uma aproximação dos recursos de hardware necessários para suportar uma implementação de software”.

    Como qualquer modelo teórico, vale frisar que este é uma aproximação da realidade, mas que costuma alcançar resultados muito mais sólidos do que um simples “chute”. Mais importante ainda: suportar a implementação de software determina que ele deve não só ser executado, mas executado com performance adequada e que atenda às necessidades dos usuários.

    Dependendo do projeto ou do software a ser implantado, várias abordagens podem ser adotadas quando tratamos de Dimensionamento de Hardware, sempre envolvendo análise de fatores como:

    • Complexidade das rotinas: é possível prever quais rotinas mais complexas irão demandar mais processamento (aqui se aplica muito o dimensionamento de software);
    • Quantidade de usuários: quanto mais usuários (principalmente concorrentes) maior será o volume de processamento e armazenamento necessário;
    • Volume de transações: sabendo que a função “X” tem determinada complexidade, qual será o volume de vezes que ela será utilizada?;
    • Armazenamento: quanto espaço ocupará cada transação iniciada (falando de armazenamento de banco de dados e disco rígido);
    • Crescimento: quanto se espera de crescimento no uso do software para os próximos anos? Qual a margem segura para termos sobras de hardware que façam o investimento durar mais?

    Estes fatores podem ser estimados do zero ou baseados em fatos históricos de um ambiente já existente. A composição destes fatores permite estabelecer uma base de cálculo que vai determinar o hardware adequado, assim justificando e protegendo o eventual investimento em hardware.

    Conforme mencionado, cada projeto de software pode exigir uma abordagem diferente para dimensionamento. Provedores de hardware e software têm diversos artigos do correto dimensionamento dos seus produtos (servidores dell, bancos de dados SQL Server e Oracle, por exemplo).

    Existem também metodologias de mercado para este tipo de medição. Uma delas é a TPC-C (Transaction Processing Performance Council – Benchmark C), a qual inclusive utilizamos comumente nos projetos de Sizing de nossos clientes.

    Metodologias para Dimensionamento de Hardware

    A metodologia TPC-C é um benchmark de processamento de transações online (OLTP). Neste tipo de benchmark são medidas combinações de servidores e bancos de diversos fabricantes, determinando o índice de transações que os mesmos suportam.

    Simplificando, na metodologia, em posse dos diversos fatores expostos acima, é possível calcular um índice necessário aproximado. Com isso é possível comparar este cálculo com equipamentos já medidos e determinar qual hardware será necessário, ou se o hardware atual está de acordo.

    Outro método de Dimensionamento de Hardware é realizar testes sintéticos com a aplicação através de testes de carga. Pode-se usar uma ferramenta de testes automatizados (JMeter, por exemplo) para verificar quantas transações simultâneas um processador simples suporta.

    Se a estação simples suporta 100 transações simultâneas, mas for determinado que teremos 1000 usuários concorrentes, sabemos que para atender 1000 transações simultâneas devemos ter um equipamento com 10 vezes o poder computacional do processador simples. Este tipo de estudo (prévio quando a aplicação ainda não foi implantada) pode ajudar bastante em um correto dimensionamento de hardware.

    Concluindo

    Como podemos ver, determinar a capacidade necessária de processamento para um software pode ser uma tarefa complexa, e somente respeitar os requisitos mínimos passados por um fornecedor pode não trazer os resultados desejados. Também é importante frisar que não existe uma fórmula mágica, mas felizmente contamos com uma série de instrumentos que podem ajudar.

    Independentemente do método utilizado, deve-se realizar um Dimensionamento de Hardware adequado para que as soluções de software consigam ter o desempenho necessário e garantir uma maior produtividade da empresa.

    Para nossos clientes, nossa equipe de consultoria oferece serviços de Sizing para ambientes Fusion. Caso necessite, ficaremos felizes em tirar todas as suas dúvidas.


    Deixe seu e-mail e receba novos conteúdos da Neomind:


    Referências:
    TPC, KuscholarWorks, Wikipedia, Wikipedia

  • A importância do Guia de Estilos no processo de desenvolvimento de software

    A importância do Guia de Estilos no processo de desenvolvimento de software

    A competividade do mercado e a necessidade de projetos serem entregues de maneira mais rápida e com qualidade é algo que toda empresa almeja. Não existe uma fórmula mágica para atingirmos esse objetivo, mas é possível dar pequenos passos para chegarmos lá. A padronização de alguns processos internos é um desses passos, principalmente quando nos referimos ao desenvolvimento de software.

    Na Neomind, um dos processos que recebeu uma atenção especial foi a etapa de criação e desenvolvimento de interfaces. Tudo começou com um Guia de Estilos criado pela equipe de User Experience e é essa história que vamos contar a você hoje.

    Por que criar um Guia de Estilos?

    Seguir padrões pré-estabelecidos é muito importante para manter a consistência de um produto. Isso permite com que o processo de criação e desenvolvimento aconteça de forma mais rápida, possibilitando a viabilidade dos projetos executados e garantindo a qualidade do produto.

    Percebemos isso quando ainda não tínhamos um padrão de código-fonte. Na ocasião, muitos dos componentes acabavam sendo criados diversas vezes, por várias pessoas e sempre com um código-fonte diferente. Além disso, existiam pontos de inconsistência que não batiam com o mockup das telas, tanto no estilo, como no comportamento daquele componente.

    Foi aí que vimos a necessidade da adoção de um guia de estilos (style guide). Com a adoção, o projeto passou a facilitar a aprendizagem dos padrões utilizados no design e no código-fonte do produto, além de se tornar um recurso acessível a todos os colaboradores para visualização dos componentes.

    Era uma vez… nosso Style Guide

    No início, nosso Guia de Estilos era um pequeno livro (físico) e um arquivo PDF, nos quais eram exibidos os padrões de cores, tamanhos de fontes, botões, iconografia e alguns modelos de componentes. Manter um guia de estilos físico trazia certos problemas. Um deles era o de que a cada alteração ou inserção de um componente novo era necessário imprimir uma nova versão e descartar a antiga, o que ocasionava em custos de impressão e muito desperdício de papel (fato que não combina com uma mentalidade paperless, a qual somos adeptos aqui na Neomind).

    Percebendo isso, começamos a utilizar apenas o arquivo PDF. Desse modo, todos os colaboradores passaram a ter o documento em seus computadores e a atualização do mesmo era mais fácil.

    Elementos do Fusion Platform no Guia de Estilos da Neomind

    Nosso guia de estilos passou para uma nova etapa, com o projeto batizado de “Style Guide”. O objetivo era o de torná-lo digital e, para isso, ele foi baseado no framework Bootstrap.

    O Bootstrap foi criado em 2010 por um designer e um desenvolvedor do Twitter, com o propósito de facilitar o desenvolvimento de telas. Essencialmente, trata-se de uma biblioteca que possui diversos componentes com interfaces amigáveis e modernas, além da responsividade que facilita muito a criação de telas que necessitam se adaptar conforme a resolução dos monitores, tablets e smartphones.

    Ele é uma das bibliotecas mais populares e mais utilizadas no mundo, em virtude da facilidade de uso, da documentação disponibilizada e por ser totalmente gratuito. Isso faz com que exista também uma grande comunidade envolvida.

    Bootstrap

    Como o Bootstrap possui o seu próprio padrão de interface, fizemos a customização, transformando-o em uma biblioteca específica para uso da Neomind. Além disso, foi necessário adaptar os componentes para que os mesmos ficassem com a cara do Fusion Platform. Fazendo isso, conseguimos manter a nossa identidade visual e adaptar os comportamentos dos componentes. Também atualizamos nossa biblioteca com componentes que já haviam sido criados ou que estavam em processo de desenvolvimento.

    Como trabalhamos com o Guia de Estilos

    Todas as interfaces criadas para o Fusion Platform são modeladas com base nos comportamentos e necessidades dos usuários, que são nossos clientes. Isso acontece porque buscamos sempre deixar nosso produto intuitivo e fácil de ser utilizado.

    Toda vez que notamos que os usuários estão com dificuldades de realizar determinada ação, reavaliamos a funcionalidade e aplicamos os devidos ajustes para torná-la mais usual possível. Por isso é tão importante manter nossos clientes próximos dos nossos processos de criação e de desenvolvimento.

    Com o guia de estilos, nossa equipe de UX consegue ter uma referência para a criação de novas telas e funcionalidades, sem que seja necessário criar diferentes componentes com comportamentos similares e até mesmo iguais. Assim é possível ter ganhos de produtividade na etapa de criação e de desenvolvimento, pois os componentes são desenvolvidos apenas uma vez.

    Muitos dos componentes possuem variações, como por exemplo o componente de seleção de itens, onde em um dos modelos é possível selecionar apenas um dos itens. Em outro, pode-se selecionar vários itens, itens com ícones ou fotos, itens pré-selecionados e opção apenas para o modo de visualização.

    Design Fusion Platform
    Exemplo de componente do Guia de Estilos

    Quando há a necessidade de criação de um novo componente, é realizado um alinhamento da equipe de UX com o time de Inovação para discutir a viabilidade técnica. Além de seguir os padrões pré-estabelecidos, é necessário que os componentes sejam compatíveis com diferentes navegadores e versões antigas desses navegadores, o que muitas vezes inviabiliza alguns cenários planejados.

    O código-fonte dos componentes deve ser criado de uma maneira que possibilite a reutilização em outros cenários sem que seja necessário realizar ajustes. É claro que algumas vezes mudanças precisam ser feitas, pois alguns cenários podem ser muito específicos e não terem sido pensados no momento de criação.

    Fechando…

    Todos os componentes ficam disponíveis para serem consultados e testados para que o cliente possa ter sempre o melhor em interface. Como o Style Guide é um projeto a parte, nossos desenvolvedores só precisam fazer o download do projeto em nosso repositório e executá-lo.

    Para os colaboradores da empresa, o Guia de Estilos é de grande valia, pois dessa forma é possível entender os padrões que foram pré-estabelecidos no design e no desenvolvimento do produto e conhecer a gama de componentes disponíveis.

    Um guia de estilos não é algo imutável. Por isso, é importante mantê-lo em constante evolução, já que a tecnologia evolui rapidamente e precisamos acompanhá-la para não ficarmos para trás.

    Referências:
    Coletivo UX, Get Bootstrap, UX Design Brasil, Guia de Estilo Web



  • Conheça o AngularJS, novo aliado do Fusion Platform

    Conheça o AngularJS, novo aliado do Fusion Platform

    A introdução do framework AngularJS ao Fusion Platform oferece vantagens aos desenvolvedores e abre portas a novos mercados para este sistema que já vem apresentando resultados surpreendentes na gestão integrada de processos, documentos e indicadores para obtenção de soluções mais ágeis e assertivas para as empresas.

    Um dos principais pontos melhorados foi o desenvolvimento da aplicação, que passou a ser mais elegante e estruturado, com menos linhas de código, passível de testes e compatível com outros frameworks emergentes, agregando também mais valor de mercado ao produto. Do ponto de vista comercial, a introdução do Angular JS foi responsável pela modernização do Fusion, trazendo o produto a um patamar mais elevado. Confira abaixo as cinco principais características do AngularJS que contribuem para a sua utilização no Fusion:

    1. Organização dos componentes de forma hierárquica e independente

    A organização hierárquica de uma aplicação AngularJS é prevista em documentação, e os desenvolvedores podem optar por seguir as boas práticas de programação. Foi escolhida uma configuração de pastas relacionada ao modelo de camadas do AngularJS, que é baseado no MVC e permite a separação de conceitos (separation of concerns) de uma aplicação web.

    root/# diretório raíz.
    app.js# js do módulo principal da aplicação.
    ….assets/# componentes javascript não relacionados à aplicação Angular (ex. jquery).
    ….common/….css/# serviços e diretivas compartilhados por toda a aplicação Angular.# folhas de estilo
    ….controllers/….services/….directives/….filters/….tpl/

     

     

    		# controllers, serviços, diretivas, filtros e templates html.

    Através desta configuração, cada conceito da aplicação Angular é disposto em pastas diferentes. Por exemplo, todos os arquivos HTML (interfaces) estão presentes na pasta tpl, enquanto todos os serviços (comunicação com o servidor) ficam na pasta services. Estes conceitos, quando separados, permitem o desenvolvimento independente dos componentes da aplicação.

    1. Programação reativa através do conceito de Two way data-binding

    O paradigma da programação reativa pode ser explicado da seguinte maneira: imagine um documento Excel contendo diversas células. A alteração no valor de uma célula pode refletir no valor de outra, sem que a pessoa a altere explicitamente. O AngularJS é um framework reativo. Qualquer alteração em tela, como por exemplo, o preenchimento de um campo texto, reflete no modelo javascript subjacente que contém as informações da tela, sem que o programador precise “codificar” esta alteração.

    01
    Figura1 – Reatividade no AngularJS

    Qualquer alteração realizada no campo texto é refletida no modelo Javascript, e vice-versa (Two way data-binding). Esta característica proporciona ganhos de produtividade e redução do número de linhas de código, pois o AngularJS fica responsável pela sincronia dos dados da aplicação, assim como o Excel é responsável pela alteração automática do valor de uma célula.

    1. Templates HTML

                No AngularJS, os templates HTML são arquivos que podem ser anexados a qualquer parte da aplicação e garantem o reuso de componentes. Um designer pode, por exemplo, definir um arquivo HTML contendo um formulário, e disponibilizá-lo para todos os pontos da aplicação que necessitem de um.

    form.html

    02

    A grande vantagem desta abordagem é a criação de um trabalho conjunto envolvendo designers e desenvolvedores. Enquanto os designers criam os templates, os desenvolvedores podem utilizá-los de acordo com suas necessidades. O Fusion utiliza o framework Bootstrap como suporte ao desenvolvimento de componentes reutilizáveis.

    1. Arquitetura MVC

                O AngularJS utiliza o conceito de MVC (Model-View-Controller), que é caracterizado por:

    MODEL: Camada de negócios, responsável pela lógica dos dados da aplicação.

    VIEW: Responsável pela visualização dos dados da aplicação.

    CONTROLLER: Controla a interação com o usuário. Comunica-se com a view e o model.

    A arquitetura MVC permite que cada aspecto da aplicação web seja analisado separadamente. É permitido, por exemplo, desenvolver o layout da aplicação (view) sem ter conhecimento do modelo (dados) da aplicação. Isto torna possível, por exemplo, a separação entre desenvolvedores front e back-end. Enquanto os primeiros desenvolvem a interface (view), os últimos se preocupam com a lógica dos dados (model), sem ter conhecimento da interface. Isto gera um senso de independência entre os desenvolvedores e possibilita a contratação de pessoas especializadas em áreas específicas.

    1. Serviços RESTful

     A comunicação entre o navegador web e o servidor da aplicação é realizada pelo AngularJS através do padrão REST. Esta arquitetura estabelece padrões na utilização do protocolo HTTP  e define, por exemplo, que o comando PUT deve ser utilizado para enviar um recurso ao servidor e DELETE para removê-lo. Antes da utilização do AngularJS, o Fusion utilizava o conceito de servlets para realizar a comunicação cliente-servidor. Este conceito não enfatiza os mesmos padrões do REST e por isso torna-se inferior ao analisar-se a aplicação do ponto de vista organizacional. Outra característica do padrão REST é permitir que as interfaces sejam chamadas de forma isolada. Normalmente, um serviço REST é acessado através de uma URL, exemplo: http://192.168.1.25:80/app/rest/getusers. O retorno deste serviço – neste exemplo, uma listagem de usuários (getusers), pode ser anexado a qualquer parte da aplicação, basta chamar a URL.

    03
    Figura 2 – Chamada da interface pela URL


    A facilidade que o AngularJS trouxe para o Fusion Platform é mais um dos vários motivos para você conhecer e implantar este sistema em sua empresa, levando mais praticidade e inteligência à gestão integrada de processos, documentos e indicadores.

Fale com a gente