• Osmar Pedrozo fala sobre gerência de projetos.
  • Carlos Poitevin fala sobre modelos de maturidade, qualidade e testes. Confira!
  • Karina Hartmann explica os métodos de estimativa e medição de software.
  • Acompanhe a SoftDesign no Twitter!

Workflow no processo de desenvolvimento de software

Por Daniel Olsson*

A gerência de processos aliada à utilização de workflow tem sido alvo das práticas modernas de gestão de negócio nas organizações. Diante disso, as empresas de engenharia e desenvolvimento de software, que atuam em um mercado de tecnologia em constante mudança, podem tirar grande proveito das vantagens de se aplicar o workflow aos seus processos.

Workflow e processos de negócio

Em 1996, a Workflow Management Coalition (WfMC) publicou um glossário de termos relacionados com workflow e o definiu como a automação de um processo de negócio total ou parcial, no qual documentos, informação e tarefas são passadas de um participante para outro, segundo uma série de regras de procedimentos. É cada vez mais comum as empresas utilizarem essa tecnologia para melhorar os seus processos de negócio através da modelagem, melhoria e automatização do conjunto de seus procedimentos ou atividades interligadas, a fim de que a execução das mesmas alcance o objetivo ou meta almejada pela organização.
Um sistema de workflow deve conhecer e controlar a lógica das transições entre as tarefas do processo e ativar os recursos humanos e recursos de informação necessários para completar essas tarefas. Em outras palavras, em um processo sem workflow o participante vai buscar a tarefa, enquanto que num processo com workflow, a tarefa é atribuída ao participante, ou ao papel desempenhado por ele. O processo se torna mais eficiente pois reduz os custos de pessoal e material, diminui o tempo para um participante perceber que tem uma tarefa a realizar e possibilita balancear as tarefas entre os participantes do processo. Por outro lado, a habilidade de gerenciar o negócio é melhorada com a padronização dos procedimentos, permitindo também que problemas de desempenho sejam mostrados de maneira explícita e então compreendidos.
Apesar da péssima reputação do workflow nos anos 90, decorrente da sua utilização como parte do processo de reengenharia de negócios muito mais focado na tecnologia, ou seja, aplicações e sistemas, do que na participação humana no processo, sua capacidade de controlar e modelar processos da empresa em tempo real gerou o interesse da área de gestão de negócios. De fato, o Business Process Management (BPM) não apenas requer o uso de um forte componente de workflow como espera que o mesmo possua condições de se adaptar para permitir que a integração e automação sejam flexíveis e configuráveis, independente do modelo de processo em si.

O Processo de Desenvolvimento de Software

Um processo de software pode ser visto como um caso particular de um processo empresarial na medida em que engloba um conjunto de atividades ordenadas que têm como objetivo o desenvolvimento ou manutenção de software. Desta forma, a tecnologia de workflow pode ser utilizada para dar apoio ao processo de software em um Ambiente de Desenvolvimento de Software Orientados a Processo (Process-Centered Software Engineering Environments – PSEE).
PSEE é um tipo especial de ambiente de desenvolvimento de software que surgiu nos últimos anos para apoiar a definição rigorosa de processos de software, objetivando automatizar a gerência do desenvolvimento. Tais ambientes provêem serviços para análise, simulação, execução e reutilização das definições de processos, que cooperam no aperfeiçoamento contínuo de processos. Ele ainda permite que os participantes envolvidos no processo recebam orientação automatizada e assistência na realização de suas atividades, sem interferência no processo criativo. Além disso, os processos podem ser modificados dinamicamente, em resposta a estímulos organizacionais ou mudança nos requisitos do software em desenvolvimento. Por todos esses motivos, o processo de desenvolvimento de software pode ser visto como um processo bastante complexo.

Sistemas de gerenciamento de workflow

Um sistema de gerenciamento de workflow (Workflow Management Systems – WfMS) é, por definição, um software capaz de identificar, criar e gerenciar workflows, interpretar a definição do processo, interagir com os participantes e, quando necessário, invocar ferramentas e aplicativos de sistemas de informação. Apesar da grande variedade de produtos de workflow disponíveis no mercado, é possível conceber um modelo genérico de implementação de sistemas de workflow, que abranja a grande maioria destes produtos a fim de tornar-se mais fácil a compreensão do seu funcionamento.
A figura abaixo apresenta os principais componentes de um sistema de gerenciamento de workflow que, segundo a WfMC, são identificados pelas funções que os mesmos desempenham, a saber:
1. Função de tempo de construção: oferece suporte à definição e modelagem do processo de workflow;
2. Funções de controle em tempo de execução: gerencia os processos de workflow em um ambiente operacional. Preocupa-se também com o seqüenciamento de várias atividades para serem manuseadas como parte de cada processo;
3. Interações em tempo de execução com usuários e ferramentas para processamento dos vários passos das atividades.


Figura 1 – Principais componentes de um sistema de gerenciamento de workflow

Workflow no processo de desenvolvimento de software

Os WfMS são capazes de suportar fluxos de controle complexos, podendo perfeitamente ser aplicados a um processo de engenharia de software. Também devido à característica flexível desses sistemas, eles atendem a certas particularidades, como definições de processos específicos a cada contexto de desenvolvimento de software, e contribuem para a evolução desses processos em relação às modificações.
Entre as vantagens que um WfMS pode trazer ao processo de desenvolvimento de software, destacam-se:
  • A modelagem de processos, auxiliada por linguagens de programação de alto nível e ferramentas gráficas;
  • A separação entre modelo e implementação, permitindo maior flexibilidade para realizar modificações no processo, sem alterar os que já estão em execução;
  • A integração com outros ambientes de workflow distribuídos e heterogêneos, envolvendo diversos setores de uma organização ou mesmo diferentes organizações;
  • A execução do processo em si, auxiliando os participantes a entenderem seu papel dentro do processo e coordenarem suas atividades individuais;
  • A coordenação, supervisão e auditoria do processo, bem como identificação de pontos a serem melhorados;
  • A colaboração entre grupos de trabalho;
  • O reconhecimento do processo de trabalho, oferecendo maior liberdade de gerência de responsabilidades.
Conclusão

As complexidades e dificuldades normalmente encontradas no ambiente de desenvolvimento de software podem ser minimizadas com aplicação da gerência de processos auxiliada pela utilização de um sistema de workflow. Os benefícios proporcionados por esta técnica podem resultar em aumento da produtividade e da qualidade do software produzido – metas constantemente almejadas pelas empresas que atuam neste mercado.


Referências

ALLEN, R. Workflow: An Introduction. Disponível em: http://www.wfmc.org/Download-document/Workflow-An-Introduction-Rob-Allen.html. p. 1.

GIORDANI, B. T. Protótipo de um Sistema de Gerenciamento de Workflows Baseado em Eventos. Campinas, 1999. Cap. 3, p. 19-25.

MAZONI, L. V. Uso de Sistema de Gerência de Workflow para Apoiar o Desenvolvimento de Software Baseado no Processo Unificado da Rational Estendido para Alcançar Níveis 2 e 3 do Modelo de Maturidade. Porto Alegre, 2001. p. 152-155.

PRIOR, C. Workflow and Process Management. Australia: WMC.

SILVA, R.A.C.; SOARES, L.Z.; BRAGA, J.L. Workflow Aplicado a Engenharia de Software Baseada em Processos: Uma Visão Geral. Viçosa, 2006.

WIKIPEDIA. Sistema de gerenciamento de workflow. Disponível em: http://pt.wikipedia.org/wiki/Sistema_de_gerenciamento_de_workflow. Acesso em 18 jun. 2010.


* Atuando como consultor e projetista na PROCERGS pela SoftDesign há cerca de 5 anos, atualmente é reponsável pela gerência de desenvolvimento do módulo de Administração de Materiais do sistema FPE (Finanças Públicas do Estado do RS), implantado em mais de 15 órgãos públicos. É graduado em Administração de Empresas com ênfase em Produção e Sistemas pela Universidade Federal do RS (UFRGS) e está concluindo o curso de Pós-Graduação em Gerenciamento de Projetos de TI pela Unisul, SC..
Read More

Multidisciplinaridade e o Gerenciamento de Projetos

Por Osmar A. M. Pedrozo*

Neste post vou destacar a questão da multidisciplinaridade no gerenciamento de projetos. A multidisciplinaridade é por definição a condição em que uma atividade é realizada através da aplicação coordenada de um conjunto de disciplinas. A "arte" de gerenciar projetos exige do profissional uma formação multidisciplinar que além de conhecimentos formais de gerenciamento de projetos exige noções muitas vezes avançadas de psicologia, direito, administração, informática, contabilidade, etc.

Mas então, um gerente de projetos deve ser um generalista? Em minha opinião, o conhecimento específico, formal, em gerenciamento de projetos é uma exigência mínima de conhecimento para a atuação do profissional. A visão sistêmica, do todo, do contexto onde está inserido é uma qualidade desejável (senão obrigatória) para fortalecer sua atuação. O conhecimento de outras áreas e disciplinas completam as exigências de formação do gerente.

Vamos imaginar um caso prático onde um gerente de projetos, com domínio da técnica do gerenciamento de projetos, tem que decidir a viabilidade financeira de um projeto. Quais as necessidades de conhecimento para apoiar esta decisão? No mínimo, este gerente deve conhecer administração financeira, saber calcular a TIR, VPL, certo? E para calcular essa informação, deve ter conhecimentos mínimos de contabilidade, como apurar um demonstrativo de resultados e fluxo de caixa esperados do projeto, certo? E se o projeto mostrar-se inviável ou parcialmente viável? Como torná-lo viável? Que conhecimentos das leis sobre direito tributário são necessárias em um país que possui umas das legislações mais complexas do mundo e ainda assim oferece benefícios fiscais para projetos de inovação? E sobre estratégia (aquela do planejamento estratégico de administração de empresas, lembra?) Qual a estratégia da empresa em relação a esta decisão? Qual será a sua orientação como gerente? Lembre-se: um projeto não muito interessante financeiramente pode ser importante do ponto de vista estratégico.

Se até neste ponto de estudo de viabilidade econômico-financeira você como gerente conseguiu chegar sem utilizar nada de informática, então você é mágico. Toda a avaliação deste estudo de viabilidade do projeto já exige do profissional bons conhecimentos de informática, ou no mínimo conhecimentos de uso de uma planilha de cálculos e de um software como o MS Project. Quando da execução do projeto, teremos exigências de outras habilidades de tecnologia da informação que se farão necessárias certamente. E quanto à psicologia? Que habilidades e conhecimentos são necessários ao gerente? Por definição o gerente, ao contrário do que muitos pensam não é o papel mais importante do projeto e sim o de maior responsabilidade, pois precisa defender seu orçamento, seu cronograma, seu escopo e ainda tem que liderar e motivar sua equipe. Deste modo, as qualidades de boa comunicação, observação, liderança, empatia (talvez uma das mais importantes), gestão de conflitos, negociação, entendimento de perspectivas e interesses de cada membro da equipe são essenciais, afinal, além da técnica e do conhecimento, projetos envolvem pessoas diferentes, com visões e expectativas únicas. Alinhar todas estas expectativas com a visão de atingir o objetivo do projeto é uma das mais importantes responsabilidades do gerente.

Sob a perspectiva da multidisciplinaridade, o gerente de projetos parece um ser mais complexo do que simplesmente aquele profissional que fica controlando cronograma, enviando e-mails e cobrando o pessoal, certo? É isso mesmo. Cada vez mais o gerente de projetos necessita ter conhecimentos distintos para fazer frente às exigências da arte de gerenciar projetos. A diferenciação, com conhecimentos que vão além da disciplina gerenciar projetos, é o que certamente fará a diferença neste concorrido mercado de trabalho.


* Diretor da SoftDesign e Presidente da UNACORP S/A, consultor e gerente de projetos, com mais de 17 anos de experiência em TI. Atuou em diversos projetos para clientes como PROCERGS, Fundação Carlos Chagas, PT Inovação Brasil – Grupo Portugal Telecom, Hospital de Clínicas de Porto Alegre e CNP. Membro do grupo de melhoria de processos da SoftDesign. Graduando em Ciências Contábeis pela UFRGS, é também Técnico em Processamento de Dados pela URI – Universidade Regional Integrada.
Read More

MPS.Br Nível G

Por Carlos A. H. Poitevin*

Continuando a seqüência de artigos abordando as questões básicas sobre o MPS.Br, vou escrever especificamente sobre o nível G e o que significa estar neste nível de maturidade.

O nível G também é denominado de Parcialmente Gerenciado. Um processo é denominado gerenciado quando ele é planejado, executado, medido e controlado. Os processos do nível G são parcialmente gerenciados porque as execuções dos processos são planejadas, executadas e controladas. As medições ainda são feitas de forma incipiente neste nível. Os produtos de trabalho gerados nas execuções, como por exemplo, planos de projetos e documentos de especificação de casos de uso, não sofrem um controle mais formal. Outra característica é que a organização ainda não precisa implementar os processos de Gerência de Configuração, Medição, Garantia da Qualidade, Gerência de Portfólio de Projetos e Aquisição que fariam com que ela pudesse ser considerada como Gerenciada.

O nível G é composto pelas áreas de processo de Gerência de Projetos e Gerência de Requisitos.

Segundo [SOFTEX, 2009a], o propósito do processo Gerência de Projetos é estabelecer e manter planos que definem as atividades, recursos e responsabilidades do projeto, bem como prover informações sobre o andamento do projeto que permitam a realização de correções quando houver desvios significativos no desempenho do projeto.

Na Softdesign a Gerência de Projetos teve avanços significativos no planejamento das atividades, no acompanhamento do andamento do projeto através do cronograma, no entendimento e na execução das tarefas executadas nos marcos e nas negociações com o cliente referentes a mudanças de escopo, prazo e custo.

O propósito do processo Gerência de Requisitos é gerenciar os requisitos do produto e dos componentes do produto do projeto e identificar inconsistências entre os requisitos, os planos do projeto e os produtos de trabalho do projeto. [SOFTEX, 2009a]

A Gerência de Requisitos, apesar de ser um processo de simples definição, representou uma mudança bastante interessante para a empresa. Apesar de já fazermos os levantamentos das necessidades do cliente e do software, ainda faltava estabelecer formalmente o compromisso entre o cliente e a empresa sobre a compreensão e correção dos requisitos fornecidos. A forma de tratar a mudança dos mesmos também foi outro ponto que trouxe mais transparência ao processo, pois foi possível medir e avaliar os impactos dessas mudanças. O estabelecimento da rastreabilidade bidirecional ajudou nesta avaliação de impacto e no desenvolvimento e na aplicação de testes.

Outro grande benefício foi o estabelecimento de uma cultura para melhoria de processos. Hoje a empresa possui um grupo de melhoria, denominado GEPS (Grupo de Engenharia de Processos de Software) que trabalha de forma estruturada e atua criticamente na definição dos processos e ferramentas utilizados.

Finalmente, para a Softdesign a obtenção do nível de G do MPS.Br significa dar mais um passo na sua visão de ser um centro de excelência em consultoria e desenvolvimento de sistemas, para seus colaboradores a qualificação e valorização das suas carreiras e para os seus clientes o compromisso com a qualidade dos produtos adquiridos.

* Carlos Poitevin é Bacharel em Informática pela PUC-RS, Especialista em Melhoria de Processos pela UFLA-MG, Certificado na área de testes CBTS-ALATS e CTFL-ISTQB. Responsável pela coordenação da área de Metodolgia Infraestrutura e Pesquisa da SoftDesign.


Referências Bibliográficas
[SOFTEX, 2009a] - ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO – SOFTEX. MPS.BR – Guia Geral:2009, maio 2009. Disponível em www.softex.br

Para saber mais:
(Chrissis, 2003) Chrissis,M.B., Konrad,M, Shrum,S. CMMI: Guidelines for Process Integration and Product Improvement, Addison-Wesley, 2003
Read More

Estimativa de tamanho de software

Por Karina Hartmann*

O que é estimativa?

A estimativa é avaliação ou cálculo aproximado de algo. Ela se difere de uma mensuração porque esta última obtém uma medida exata, enquanto a estimativa obtém uma aproximação. Estimativas são realizadas quando não possuímos os dados necessários para mensurar.

No caso de software, só é possível mensurar o software já construído. Durante a análise dos requisitos ainda não possuímos todos os dados necessários para obter uma medida, então podemos apenas estimar.


Porque estimar tamanho de software?

Digamos que você vai iniciar um projeto de desenvolvimento de software hoje. Como você define quanto tempo vai precisar trabalhar para que o software esteja pronto? Como você estima quando vai poder entregar o software para o cliente? Como você define quanto deveria custar esse software?

Estimamos o tamanho do software para responder essas e outras perguntas. Todo projeto de desenvolvimento de software demanda um investimento, iniciar um projeto sem ter idéia do investimento necessário é certeza de insucesso.

Para iniciarmos um projeto e poder planejá-lo e monitorá-lo precisaremos de informações que são derivadas do tamanho do software:
  • Custo (para defini-lo é preciso saber qual o esforço).

  • Tempo (é a duração do trabalho em dias).

  • Esforço (é quantidade de trabalho em horas, só poderá ser estimado sabendo-se qual o tamanho do software a ser construído. Tamanho do software * produtividade = esforço).

E quanto ao erro?

No início deste post lembramos que a diferença entre estimativa e mensuração é que a primeira é apenas uma aproximação, com base em dados incompletos ou ainda não confiáveis.

A figura abaixo, conhecida como ‘funil de incerteza’ demonstra a aproximação da estimativa conforme avançamos no ciclo de desenvolvimento do software. O que esse gráfico nos mostra é a variação da estimativa em função do tempo no projeto: Durante a especificação dos requisitos, quando ainda não temos requisitos estáveis ou não conhecemos todos os requisitos, nossas estimativas vão estar até quatro vezes maiores ou menores que o correto. Ao passo que aumentamos a certeza sobre requisitos, arquitetura, etc, mais e mais a estimativa se aproxima do tamanho real.



O aumento da certeza durante o projeto pode fazer necessário o re-planejamento (modificar o que foi planejado a partir das novas informações, modificando as variáveis: custo, escopo/qualidade ou prazo) ou a gerência de mudança (resposta controlada a uma mudança necessária, como a inclusão de uma funcionalidade). A gerência de mudança normalmente inicia um novo ciclo de planejamento e faz uma nova estimativa do tamanho do software.

Melhorar as nossas estimativas também depende da qualidade do levantamento de requisitos e da apuração do método. O processo de desenvolvimento de software precisa ser capaz de retroalimentar o método de estimativa.

Voltando para aquele projeto que você está hipoteticamente iniciando hoje: quando você finalizar o desenvolvimento, deve obter métricas atualizadas da execução do projeto e utilizá-las para saber o quanto sua estimativa foi precisa, melhorar seu método e atualizar dados como a taxa de produtividade.

Concluindo, é importante entender que a estimativa de tamanho de software, apesar de não ser exata, nos fornece dados imprescindíveis para decidir pela execução de um projeto e também é a base para planejar e monitorar projetos de desenvolvimento de software.

No próximo post vou introduzir algumas técnicas de medição de software. Aguardem!

*Gerente de projetos da Fábrica de Software da SoftDesign, participante do grupo de melhoria de processos, é responsável pelas medições de novos projetos. Cursando Matemática Aplicada à Informática na ULBRA Canoas, é também Técnica em Informática pela ULBRA.
Read More

Uma Visão Geral sobre o MPS.Br

Por Carlos A. H. Poitevin*

Durante o ano de 2009 trabalhamos na implementação do nível G de maturidade do MPS.Br®, este é o assunto deste meu primeiro post aqui no blog e tem por função tornar mais claro o que é o MPS.Br. Então, vamos começar caracterizando-o.

O MPS.BR é um programa para Melhoria de Processo do Software Brasileiro coordenado pela Associação para Promoção da Excelência do Software Brasileiro (SOFTEX), contando com apoio do Ministério da Ciência e Tecnologia (MCT), da Financiadora de Estudos e Projetos (FINEP) e do Banco Interamericano de Desenvolvimento (BID). [Softex, 2007a]

O MPS.BR está dividido em três (3) componentes (figura abaixo): Modelo de Referência (MR-MPS), Método de Avaliação (MA-MPS) e Modelo de Negócio (MN-MPS). Cada componente é descrito por meio de guias e/ou de documentos do MPS.BR. [Softex, 2007a]

A base técnica para a construção e aprimoramento deste modelo de melhoria e avaliação de processo de software é composta pelas normas NBR ISO/IEC 12207 – Processo de Ciclo de Vida de Software, pelas emendas 1 e 2 da norma internacional ISO/IEC 12207 e pela ISO/IEC 15504 – Avaliação de Processo. Uma avaliação MPS.BR é realizada utilizando o processo e método de avaliação MA-MPS descritos no guia de avaliação. Uma avaliação MPS.BR verifica a conformidade de uma organização/unidade organizacional aos processos do MR-MPS. [Softex, 2007a]

O CMMI® é um modelo de melhoria de processos desenvolvido pelo Departamento de Defesa dos Estados Unidos que também compõem a base técnica para o MR-MPS.



O Modelo de Referência MR-MPS define níveis de maturidade que são uma combinação entre processos e sua capacidade [Softex, 2007a].

Os níveis de maturidade estabelecem patamares de evolução de processos, caracterizando estágios de melhoria da implementação de processos na organização. O nível de maturidade em que se encontra uma organização permite prever o seu desempenho futuro ao executar um ou mais processos. O MR-MPS define sete níveis de maturidade: A (Em Otimização), B (Gerenciado Quantitativamente), C (Definido), D (Largamente Definido), E (Parcialmente Definido), F (Gerenciado) e G (Parcialmente Gerenciado). A escala de maturidade se inicia no nível G e progride até o nível A. Para cada um destes sete níveis de maturidade é atribuído um perfil de processos que indicam onde a organização deve colocar o esforço de melhoria. O progresso e o alcance de um determinado nível de maturidade do MR-MPS se obtém quando são atendidos os propósitos e todos os resultados esperados dos respectivos processos e dos atributos de processo estabelecidos para aquele nível [Softex, 2007a].

Como citado anteriormente, o MPS.Br tem relação direta com o CMMi. Este último é um modelo mundialmente difundido.

Ambos possuem praticamente as mesmas áreas de processos mas diferem na quantidade de níveis de maturidade. Enquanto que o modelo americano possui cinco níveis, numerados de 1 a 5, o MPS.Br possui sete níveis rotulados a partir do G até o A. Isto se deve a estratégia de se tornar a evolução das empresas de forma mais suave, uma vez que a quantidade de processos para serem implementados é menor em cada nível. Outra forma de tornar o modelo mais atrativo para as empresas brasileiras é em relação ao custo de implementação e avaliação que ficam diluídos com mais níveis de maturidade. O programa ainda conta com incentivos governamentais que fomentam a formação de grupos de empresas onde os gastos com consultoria e desenvolvimento das melhorias de processo são rateadas entre estas organizações.

Abaixo é apresentada uma imagem que mostra a divisão dos níveis de maturidade do MPS.Br e a sua correspondência com o CMMi.



Eu não pretendo esgotar o tema neste artigo, apenas quero familiarizar os demais com a preparação para a obtenção do nível G. Nos posts que se seguirem irei apresentar mais conceitos sobre os modelos de melhoria de processos, normas de qualidade, testes e soluções desenvolvidas para atender as exigências do MPS.Br.


* Carlos Poitevin é Bacharel em Informática pela PUC-RS, Especialista em Melhoria de Processos pela UFLA-MG, Certificado na área de testes CBTS-ALATS e CTFL-ISTQB. Responsável pela coordenação da área de Metodolgia Infraestrutura e Pesquisa da SoftDesign.
Read More

Quem Somos

A SoftDesign está no mercado desde 1997, em busca constante pela qualidade, aperfeiçoamento técnico e humanização das relações de trabalho, pois uma empresa que produz soluções em Tecnologia da Informação precisa ter um cuidado que vai além dos sistemas produzidos.

Com atuação em Porto Alegre e São Paulo, contamos com profissionais altamente qualificados e oferecemos, entre outros serviços: soluções em tecnologia da informação (TI), elaboração de sistemas, fábrica de software, consultoria e outsourcing, visando proporcionar soluções às necessidades de nossos clientes.

Nos últimos anos, a SoftDesign fez importantes investimentos, como a aquisição da sede da empresa, treinamento e certificação dos colaboradores e melhoria de processos. O projeto de treinamento e capacitação de colaboradores soma mais de 60 horas de treinamento formal por profissional/ano. Estes investimentos em qualificação resultaram em um grande número de profissionais certificados: hoje, mais de 50% dos profissionais que atuam na SoftDesign possuem certificação. Com o investimento em melhoria de processos a empresa conquistou o nível G de maturidade do modelo MPS.BR no ano de 2009, trazendo maior segurança para nossos clientes.

Uma empresa de tecnologia precisa ter o olhar à frente do seu tempo, prezando sempre por qualificação e comprometimento. Por isto, não abrimos mão de uma importante característica: qualidade dos serviços prestados.
Read More