Fábrica de Software

Inovação & Tecnologia


Ganhe produtividade e reduza os custos


A Fábrica de Software da XTI poderá ser contratada para atender suas necessidades. Nossa equipe está preparada para adaptar a sua forma de trabalhar, agregando conhecimento e qualidade em seus projetos de Tecnologia da Informação.

Entre em contato com nossos consultores para saber como a Fábrica de Software da XTI pode alavancar os negócios da sua empresa.


Como desenvolvemos Softwares


Nossa Fábrica de Software, em conformidade com o modelo de qualidade MPS.Br, oferece um ambiente de desenvolvimento altamente flexível, controlado e, principalmente, orientado ao negócio da empresa.

Em um modelo de atendimento, seja ele, interno ou externo, adotamos uma estratégia de colaboração profissional onde as equipes são capazes de: definir qual será metodologia de desenvolvimento de software; quais métricas e artefatos necessários; perfis funcionais e as respectivas atividades a serem desempenhadas; sobre o plano de processos contendo a descrição das atividades; padronização e controle de qualidade; e quais serão as ferramentas de apoio necessárias aos ciclos dos projetos.

Para o desenvolvimento de software, assim como as atividades de manutenção corretiva, evolutiva e adaptativa, utilizamos tanto o Scrum como o RUP para o controle do ciclo de construção do produto, em conjunto com os padrões de Gerenciamento de Projetos definida pelo PMI (Project Manager Institute) - Guia PMBOK.


RUP - Processo Unificado da Rational


Utilizamos o RUP em projetos onde se exige maior quantidade de artefatos para apoiar o desenvolvimento orientado a objetos. Este processo mostra como o sistema será construído na fase de implementação, gerando o modelo do projeto e, opcionalmente, o modelo de análise que é utilizado para garantir a robustez. O RUP define perfeitamente quem é responsável pelo que, como as coisas deverão ser feitas e quando devem ser realizadas, descrevendo todas as metas de desenvolvimento especificamente para que sejam alcançadas.

O RUP organiza o desenvolvimento de software em quatro fases, onde são tratadas questões sobre planejamento, levantamento de requisitos, análise, implementação, teste e implantação do software. Cada fase tem um papel fundamental para que o objetivo seja cumprido, distribuídos entre vários profissionais como o Analista de sistema, Projetista, Projetista de testes, entre outros.


Metodologia Scrum


O Scrum pode ser considerado como um conjunto de valores, princípios e práticas que fornecem a base para que a sua organização adicione suas práticas particulares de engenharia e gestão e que sejam relevantes para a realidade da sua empresa.

Utilizamos como a metodologia de desenvolvimento ágil de software em nossa Fábrica, em geral, esta metodologia funciona da seguinte forma:

  • 1. O produto é definido: quais são os seus requisitos? O que realmente o cliente quer? O responsável por esta tarefa é o que chamamos de Proprietário do Produto (Product Owner).
  • 2. O Proprietário do Produto define quais são as funcionalidades do programa que mais importam, criando assim o que chamamos de Product Backlog.
  • 3. Com as prioridades definidas, uma pessoa é definida para ser o ScrumMaster, uma espécie de coordenador do projeto. O ScrumMaster, junto com o Proprietário do Produto e o Time de desenvolvimento definem o que chamamos de Sprints.
  • 4. Cada Sprint possui uma parte de todo o Product Backlog, e devem ser trabalhados de acordo com as prioridades definidas no Product Backlog. Os Sprints devem ser preparados de uma forma de que durem de 2 a 4 semanas, e que no final de cada período tenham um produto apresentável para o cliente.
  • 5. Os Sprints vão sendo feitos até o Product Backlog acabar e o Proprietário do Produto definir que o projeto está pronto. Mas isso não quer dizer que novas funcionalidades não podem ser incluídas: basta ir adicionando no Product Backlog e realizando outros Sprints.


Integração Contínua


Integração Contínua é uma pratica de desenvolvimento de software onde os membros de um time integram seu trabalho frequentemente, geralmente cada pessoa integra pelo menos diariamente – podendo haver multiplas integrações por dia. Cada integração é verificada por um build automatizado (incluindo testes) para detectar erros de integração o mais rápido possível. Muitos times acham que essa abordagem leva a uma significante redução nos problemas de integração e permite que um time desenvolva software coeso mais rapidamente.

Basicamente, a grande vantagem da integração contínua está no feedback instantâneo. Isso funciona da seguinte forma: a cada commit no repositório, o build é feito automáticamente, com todos os testes sendo executados de forma automática e falhas sendo detectadas. Se algum commit não compilar ou quebrar qualquer um dos testes, a equipe toma conhecimento instantâneamente. A equipe pode então corrigir o problema o mais rápido possível, o que é fundamental para não introduzir erros ao criar novas funcionalidades, refatorar, etc. Integração contínua é mais uma forma de trazer segurança em relação a mudanças: você pode fazer modificações sem medo, pois será avisado caso algo saia do esperado.


Fábrica de testes


Nosso processo de qualidade passa por verificações automáticas ou manuais, que independente da forma em que serão executadas, o objetivo é determinar se o produto entregue atingiu suas especificações e funcionou corretamente no ambiente para o qual foi projetado. Dessa forma as falhas identificadas retornarão ao ciclo de desenvolvimento, sendo corrigidas antes da entrega final.

Quando falamos em testes de software devemos sempre lembrar que estes são divididos em diversos tipos, de acordo com seu objetivo particular, esses são os testes feitos pela fabrica.

  • Teste De Configuração: Testa se o software funciona no hardware a ser instalado.
  • Teste De Instalação: Testa se o software instala como planejado, em diferentes hardwares e sob diferentes condições, como pouco espaço de memória, interrupções de rede, interrupções na instalação etc.
  • Teste De Integridade: Testa a resistência do software à falhas (robustez).
  • Teste De Segurança: Testa se o sistema e os dados são acessados de maneira segura, apenas pelo autor das ações.
  • Teste Funcional: Testa os requisitos funcionais, as funções e os casos de uso. “A aplicação faz o que deveria fazer?”
  • Teste De Unidade: Testa um componente isolado ou classe do sistema.
  • Teste De Integração: Testa se um ou mais componentes combinados funcionam de maneira satisfatória. Há quem diga que o teste de integração é composto por vários testes de unidade.
  • Teste De Volume: Testa o comportamento do sistema operando com o volume “normal” de dados e transações envolvendo o banco de dados durante um longo período de tempo.
  • Teste de carga: Testa o software sob as condições normais de uso. Ex.: tempo de resposta, número de transações por minuto, usuários simultâneos etc.
  • Teste de stress: Testa o software sob condições extremas de uso. Grande volume de transações e usuários simultâneos. Picos excessivos de carga em curtos períodos de tempo.
  • Teste de estabilidade: Testa se o sistema se mantém funcionando de maneira satisfatória após um período de uso.
  • Teste De Usabilidade: Teste focado na experiência do usuário, consistência da interface, layout, acesso às funcionalidades etc.
  • Teste De Regressão: Reteste de um sistema ou componente para verificar se alguma modificação recente causou algum efeito indesejado, além de, certificar se o sistema ainda atende os requisitos.
  • Teste de manutenção: Testa se a mudança de ambiente não interferiu no funcionamento do sistema.


Aferição e métrica


Nossa equipe é composta por profissionais certificados em Análise de Pontos de Função.

Caso necessário, independente da linguagem, da metodologia de desenvolvimento, a métrica será aplicada com objetivo de estimar o tamanho do software, podendo utilizar para estivar prazo e custos do projetos.

Se sua empresa não possuir seu próprio modelo de metricas, adotaresmos a mensuração de software segundo a técnica de Análise de Pontos de Função (APF), em conformidade com o Counting Practices Manual - CPM, versão 4.3.1, publicado pelo International Function Points Users Group - IFPUG, e práticas para medição de requisitos não funcionais adotadas no Roteiro de Métricas de Software do SISP, versões 1.0 e 2.0, publicado pela Secretaria de Logística e Tecnologia da Informação - SLTI.