THE IMPLEMENTATION OF A SOFTWARE QUALITY PROCESS IN AN EDUCATIONAL TECHNOLOGY STARTUP: AN ANALYSIS FOCUSED ON DELIVERY EFFICIENCY AND CUSTOMER SATISFACTION
REGISTRO DOI: 10.5281/zenodo.10079926
Fabricio Almeida Batista1
João Vitor Hayden Araújo1
Stevão Whinter Marques de Andrade1
Pablo Augusto da Paz Elleres2
RESUMO
Neste estudo, destaca-se a transformação de um cenário sem práticas de qualidade para um ambiente enraizado em uma cultura de qualidade em uma startup de tecnologias educacionais. A implementação de um novo processo de qualidade de software teve como principal objetivo a melhoria da confiabilidade e eficiência no desenvolvimento. Ao longo do projeto, abordou-se a transição de um processo deficiente para a criação de um método mais sólido. A redução significativa de bugs relatados pelo cliente após a implementação do novo processo evidencia a obtenção de maior confiabilidade.
Este artigo explora a importância da cultura de qualidade, enfatizando a transição de práticas de desenvolvimento de software sem qualidade para um ambiente onde a qualidade é priorizada. Oferece ainda insights sobre como essa transição pode melhorar a eficiência de entregas e a satisfação do cliente, além de contribuir para o conhecimento acadêmico e profissional sobre a integração eficaz da qualidade de software em ambientes ágeis de desenvolvimento.
Palavras-chave: Startups, Qualidade de Software, Testes de Software, Desenvolvimento.
ABSTRACT
This study highlights the transformation from a scenario without quality practices to an environment rooted in a quality culture in an educational technology startup. The main objective of implementing a new software quality process was to improve reliability and efficiency in development. Throughout the project, the transition from a deficient process to the creation of a more solid method was addressed. The significant reduction in bugs reported by the client after the implementation of the new process shows that greater reliability was achieved.
This article explores the importance of quality culture, emphasizing the transition from non-quality software development practices to an environment where quality is prioritized. It also offers insights into how this transition can improve delivery efficiency and customer satisfaction, as well as contributing to academic and professional knowledge about the effective integration of quality into software development.
Keywords: Startups, Software Quality, Software Testing, Development.
1. INTRODUÇÃO
Ao observar o panorama em constante evolução das tecnologias, no ponto onde há a interseção com a educação, as startups de tecnologias educacionais emergem como importantes agentes transformadores. Essas empresas, com suas propostas inovadoras, vem desempenhando um papel vital na moldagem da paisagem educacional ao oferecer soluções lúdicas e criativas para as necessidades no que concerne ao aprendizado humano.
À medida que essas soluções tecnológicas ficam mais robustas, a qualidade e a confiabilidade nessas ferramentas emergem como elementos essenciais para garantir uma experiência educacional eficaz e gratificante. Nesse contexto, a presente pesquisa destaca a implementação da cultura de qualidade em uma startup que desenvolve um sistema de Planejamento dos Recursos de Empresa (ERP) para a gestão de escolas da rede estadual do Amazonas.
Na essência desta pesquisa está a busca por compreender como a introdução de práticas de qualidade transformou não apenas o processo de desenvolvimento, mas também a qualidade do produto final e, consequentemente, a satisfação do cliente. A transição de um cenário em que práticas de teste e automação eram escassas para um ambiente onde a cultura de qualidade é enfatizada abre as portas para uma avaliação abrangente dos benefícios tangíveis e intangíveis dessa mudança.
A implementação de uma cultura de qualidade não se trata apenas de uma abordagem técnica, mas sim de uma estratégia que pode impactar profundamente o sucesso de uma startup de tecnologias educacionais. O processo de transição para esta cultura, no entanto, não é isento de desafios. A ausência de práticas de qualidade em sistemas pode resultar em produtos defeituosos, prazos estendidos e insatisfação do cliente, todos os quais podem minar a reputação da startup no mercado altamente competitivo das tecnologias educacionais.
A motivação para realizar este estudo é clara: investigar o impacto da cultura de qualidade em startups de tecnologias educacionais, ajudando-as a compreender a importância dessa abordagem e os benefícios potenciais que ela pode proporcionar. Além disso, essa análise contribui tanto para o âmbito acadêmico quanto para o profissional, fornecendo insights valiosos sobre como a qualidade pode ser integrada de maneira eficaz em ambientes ágeis de desenvolvimento.
Este artigo aborda a transição de um ambiente sem práticas de qualidade para um ambiente enraizado em uma cultura de qualidade. Para isso, foi necessário analisar e comparar o impacto da implementação dessa cultura. Para analisar essa transição, foi realizada a comparação dos dados obtidos no passado com os dados coletados atualmente. Com isso, observam-se melhorias no processo de desenvolvimento, na qualidade do produto final e na experiência do cliente. Em segundo lugar, este artigo visa oferecer orientação prática para outras startups que desejam adotar uma cultura de qualidade, destacando as soluções envolvidas e as estratégias para uma transição bem-sucedida.
2.REFERENCIAL TEÓRICO
Nessa seção, serão abordados os aspectos cruciais relacionados à qualidade no desenvolvimento de software, apresentando esse panorama no contexto de uma Startup de Tecnologias Educacionais, Qualidade no processo de Desenvolvimento de software nesse nicho, bem como a Cultura de Qualidade de software.
2.1. Startup de Tecnologias Educacionais
A rápida evolução tecnológica nas últimas décadas tem transformado profundamente a sociedade e, consequentemente, a prática pedagógica. A integração das tecnologias digitais no contexto educacional tornou-se uma necessidade imperativa. A interseção entre tecnologia e educação, muitas vezes referida como EdTech(tecnologia educacional), tem se destacado
como um campo de pesquisa e prática que busca explorar e otimizar o uso da tecnologia no ensino e na aprendizagem (MEDEIROS; MEDEIROS, 2018).
Na contramão do cenário de constante evolução e demanda por soluções educacionais digitais eficazes, outra preocupação a que se deve atentar é a necessidade de garantir a qualidade no desenvolvimento dessas tecnologias, para isso deve ser aplicado diversos dos conceitos que serão citados neste artigo posteriormente.
2.2. Qualidade no Processo de Desenvolvimento de Software
A qualidade no processo de desenvolvimento de software é um tema crítico e fundamental para o sucesso de qualquer projeto de software. A satisfação do cliente, a minimização de custos e a entrega de valor são 3 dos principais pontos a se atentar. Para quantificar essa qualidade, é necessário considerar as necessidades do cliente e identificar características que garantam eficácia e confiabilidade no software. Segundo as palavras de Maldonado (2001), ao criar um software, é essencial considerar as necessidades do cliente e identificar as características que garantirão sua qualidade e eficácia. Estas características envolvem:
- Funcionalidade: Refere-se às ações e capacidades do sistema, determinando o que ele pode realizar.
- Confiabilidade: Define a capacidade do sistema de funcionar sem falhas em um ambiente ou período específico.
- Usabilidade: Está relacionada à experiência do usuário, focando na facilidade de aprendizado e uso do software.
- Eficiência: Diz respeito ao desempenho do software e à otimização dos recursos utilizados.
- Manutenibilidade: Envolve a capacidade de modificar e atualizar o software de forma eficaz ao longo do tempo.
- Portabilidade: Trata da adaptabilidade do software a diferentes ambientes e sistemas.
- Efetividade: Relaciona-se com a capacidade do software de ajudar os usuários a alcançar seus objetivos específicos.
- Produtividade: Refere-se à eficiência com que os recursos disponíveis podem ser utilizados pelos usuários.
- Segurança: Envolvem ações para proteger contra possíveis ameaças e garantir a segurança de pessoas, negócios e propriedades.
- Satisfação: É a capacidade do software de satisfazer e superar as expectativas do cliente (Maldonado, 2001).
A qualidade no processo de desenvolvimento de software não é um objetivo único, mas um compromisso contínuo com a excelência. É importante que todos os stakeholders, incluindo desenvolvedores, testadores, gerentes de projeto e clientes, mantenham-se empenhados para garantir que a qualidade seja uma prioridade desde o início do projeto até a
entrega do software final. É imprescindível que tais práticas tornem-se constantes até que estas transformem-se em parte da cultura daquele contexto organizacional.
2.3. Cultura de Qualidade de Software em Startups
A qualidade de software engloba a criação de produtos confiáveis e úteis, que não apenas atendem aos requisitos explícitos e implícitos dos usuários, mas também agregam valor tanto para a empresa desenvolvedora, reduzindo custos de manutenção e suporte, quanto para a comunidade de usuários, ao melhorar processos de negócios e aumentar a receita (Pressman, 2016, p. 415).
Ao trazer essa narrativa para o campo das startups, onde é possível observar ser um ambiente de incertezas, em que a entrega de um Mínimo Produto Viável (MVP) é o foco, é comum em times com pouca maturidade ou baixa experiência deixarem a qualidade de software de lado, abrindo espaço para o desenvolvimento e a tentativa demasiada de priorização de entregas. Isso ocorre devido à necessidade de fornecer produtos rapidamente para atender às demandas do mercado em constante mudança.
Esse fato é bem descrito por Silva (2021), que diz que nas startups, a velocidade de lançamento no mercado é fundamental, e, muitas vezes, a qualidade, que inclui principalmente os testes de um produto, é considerada dispensável nesse contexto. Além disso, a instabilidade característica das startups, onde partes do sistema podem ser alteradas ou descartadas a qualquer momento, leva à negligência da qualidade, pois os empreendedores muitas vezes também percebem os testes como um processo que consome tempo e recursos valiosos, prejudicando o ritmo de desenvolvimento. Entre várias startups no mercado, existem startups educacionais que buscam desenvolver soluções para a educação, como os ERPs educacionais.
2.4. ERPs Educacionais
Um ERP, ou Planejamento de Recursos Empresariais, é um sistema de software integrado que permite que organizações gerenciem eficientemente suas operações e recursos. Para o contexto educacional, existem os chamados ERPs educacionais, que também podem ser conhecidos por Sistemas de Gerenciamento Escolar. Estes, por sua vez, são sistemas informatizados projetados especificamente para atender às necessidades das instituições de ensino.
No cenário global atual, as instituições de ensino buscam se destacar em um mercado competitivo, exigindo uma gestão altamente eficiente. Com isso, é possível perceber que a organização de informações de uma instituição deve ser feita de maneira minuciosa e crítica, porém, o uso excessivo de papéis e documentos pode tornar esse processo demorado e propenso a erros, principalmente quando a escola já possui uma alta quantidade de dados para se armazenar (Nascimento; Da Silva; Moraes, 2016).
A transição para sistemas informatizados é essencial para agilizar a gestão e melhorar o acesso às informações, tornando a escola mais eficaz e inovadora.
3. MATERIAIS E MÉTODOS
Nesta seção, será detalhada a metodologia utilizada no decorrer deste estudo, proporcionando uma visão mais ampla do processo de pesquisa. Portanto, descreve-se os procedimentos necessários úteis para a implementação da cultura de qualidade no time de desenvolvimento. Para alcançar esse objetivo, foi utilizada uma abordagem quali-quantitativa.
3.1. Coleta de dados do Projeto
A coleta de dados foi conduzida em várias etapas, inicialmente com a identificação das fontes de informações relevantes. Estas fontes abrangeram documentos internos da empresa, incluindo o processo previamente iniciado pelo ex-Analista de Qualidade, e também relatórios provenientes do cliente ao testar as soluções em seu ambiente de desenvolvimento.
Essa ação foi executada de forma meticulosa ao longo de um período específico, aproximadamente durante dois meses de desenvolvimento das funcionalidades essenciais do sistema. Essa janela temporal foi deliberadamente selecionada para coincidir com a entrega de duas etapas cruciais do projeto.
Em resposta a uma fase de reestruturação do time, motivada por entregas de baixa qualidade e reclamações do cliente devido a erros em funções parcialmente entregues, a empresa contratou um novo Analista de Qualidade de Software, que também é autor deste artigo. O mesmo iria participar de uma jornada de trabalho de 8 horas por dia, diferente do outro Analista, com 4 horas por dia. O objetivo da empresa era mitigar os erros anteriores e capacitar o analista a implementar um processo aprimorado que possibilitasse a previsão de erros ou problemas, evitando entregas problemáticas ao cliente.
3.2. Processo inicial do time de desenvolvimento
O processo inicial era caracterizado por uma estrutura que começava com a definição dos requisitos, onde as funcionalidades desejadas pelo cliente para o software eram detalhadamente especificadas. Isso resultava na criação de um escopo de desenvolvimento, que orientava a equipe durante um período que geralmente variava de 10 a 15 dias para trabalhar nas solicitações do cliente.
Uma vez que o desenvolvimento estava completo, a fase de testes era conduzida de forma colaborativa. Tanto o Analista de Qualidade (QA) quanto o Product Owner (PO) desempenhavam papéis cruciais nesse processo. O QA realizava testes manuais assim que todo o escopo planejado era finalizado, identificando possíveis problemas, erros ou inconformidades no software. Enquanto isso, o PO garantia que as funcionalidades entregues estivessem alinhadas com as necessidades e expectativas do cliente.
É importante observar que o QA se concentrava principalmente em testes exploratórios3, agindo como o cliente, embora não validasse os requisitos essenciais para o funcionamento adequado da tela ou função do sistema.
Após a conclusão dos testes e a validação das funcionalidades pelo PO, o software estava pronto para ser entregue ao cliente. Em seguida, o cliente conduzia testes com seus próprios usuários finais e fornecia feedback ao time, identificando problemas, fazendo elogios e sugerindo melhorias.
Figura 01 – Processo padrão utilizado pela empresa
Fonte: Autores, 2023.
Este processo da Figura 01 ofereceu uma visão clara das etapas que precederam a introdução da cultura de qualidade de software, e essas informações serão de suma importância para analisar as melhorias subsequentes implementadas no projeto.
3.3. Análise das entregas parciais ao cliente
Durante a análise das entregas parciais ao cliente, foi realizado um estudo detalhado do desenvolvimento de uma função do sistema que consistia em um Create, Read, Update, Delete (CRUD) de escolas no sistema. Por estar no início do projeto, esse desenvolvimento foi feito durante a segunda rodada de desenvolvimento, testes e entrega, que também pode ser conhecida como segunda Sprint do projeto. Esse processo, que teve uma duração de duas semanas, revelou informações cruciais sobre a qualidade do software e a eficácia das práticas de validação. Abaixo está uma tabela que resume os principais resultados dessa análise:
Tabela 01. Bugs Reportados durante Sprint 02 de Desenvolvimento
Sprint 02 | Feature | Tempo de desenvolvimento | Bugs reportados pelo QA | Bugs reportados pelo Cliente (pós entrega) |
| Cadastro de Escolas | 2 semanas | 3 | 14 | |
| Edição de Escolas | 5 | 11 | ||
| Consulta de Escolas | 2 | 7 | ||
| Deletar Escolas | 5 | 10 |
Fonte: Autores, 2023.
Essa análise revelou uma discrepância significativa no número de bugs identificados pelo cliente após a entrega, em comparação com os bugs detectados pelo QA durante o desenvolvimento. Para melhor entendimento, é possível verificar na Figura 02 uma melhor perspectiva sobre o problema no processo atual.
Figura 02 – Bugs Reportados: Analista de Qualidade x Cliente
Fonte: Autores, 2023.
Essa diferença aponta para a necessidade de aprimorar a metodologia de validação utilizada anteriormente, a fim de identificar mais eficazmente problemas durante a fase de desenvolvimento. Melhorar a detecção de problemas durante o processo de validação é essencial para garantir a satisfação do cliente e a qualidade do produto entregue.
3.4. Reestruturação do processo do time de desenvolvimento
Ao analisar tanto o processo inicial da equipe de desenvolvimento, conforme mostrado na Figura 01, quanto os dados significativos apresentados na Tabela 01 com os bugs reportados, ficou evidente a necessidade de implementar melhorias substanciais para garantir a qualidade do software produzido. Nesta seção, aprofundaremos a reestruturação do processo adotado pela equipe e a integração da cultura de qualidade de software.
Figura 03 – Novo processo incluindo todos os envolvidos no projeto de maneira separada
Fonte: Autores, 2023.
Conforme evidenciado na Figura 03, concebemos um novo processo de desenvolvimento a ser aplicado pela equipe. Este novo processo descreve várias etapas que os membros da equipe devem seguir para assegurar a entrega bem-sucedida do produto desenvolvido. Essas etapas incluem uma abordagem mais abrangente de testes, uma revisão aprofundada dos métodos de validação, e um foco maior na prevenção de erros desde o início do ciclo de desenvolvimento. Isso representa uma mudança significativa na maneira como abordamos a qualidade do software e reflete nosso compromisso com a entrega de soluções confiáveis e eficientes aos nossos clientes.
3.4.1. Definição de Requisitos pelo PO
Nesta etapa crucial, o PO dá início ao processo reunindo-se com o cliente e outros membros da equipe, como desenvolvedores e analistas de teste (QA). Nesta fase, são especificadas minuciosamente todas as funcionalidades desejadas pelo cliente, incluindo regras de negócio e requisitos. É importante destacar que os requisitos são divididos em duas categorias: funcionais e não funcionais.
Requisitos Funcionais descrevem a funcionalidade ou os serviços que se espera que o sistema realize em benefício dos usuários (Paula Filho, 2000). Por exemplo, em um sistema de comércio eletrônico, um requisito funcional pode ser “o sistema deve permitir que os usuários adicionem produtos ao carrinho de compras”.
Requisitos Não Funcionais abordam as características que o sistema deve ter, como desempenho, segurança e usabilidade. Por exemplo, um requisito não funcional pode ser “o sistema deve suportar 1000 usuários simultâneos sem perda de desempenho” (Kolb, 2017). Se uma falha em cumprir um requisito funcional pode comprometer parte do sistema, uma falha em cumprir um requisito não funcional pode tornar todo o sistema inútil (Sommerville, 2008). Durante essa discussão, esses requisitos são detalhadamente documentados para garantir uma compreensão completa do que precisa ser construído. Essa etapa é essencial para estabelecer uma base sólida para o projeto e assegurar uma visão compartilhada dos objetivos e requisitos do software.
3.4.2. Fragmentação dos requisitos para criação de atividades para os desenvolvedores
Nesta etapa, o PO assume a responsabilidade de fragmentar as solicitações do cliente em múltiplas atividades menores. Essa abordagem de fatiamento (divisão) permite uma distribuição eficiente de tarefas dentro da equipe de desenvolvimento, resultando em uma estratégia mais granular para a execução do projeto.
As atividades criadas estarão disponíveis em um modelo de quadro, acessível a todos os desenvolvedores. Cada atividade terá uma descrição detalhada do que o cliente necessita, incluindo informações como o que deve ser exibido na tela, a disposição dos elementos, o design proposto e outros detalhes relevantes. Esse processo de fragmentação é fundamental para que a equipe de desenvolvimento possa abordar cada parte do projeto de maneira eficaz e organizada.
3.4.3. Escolha de Atividade pelos Desenvolvedores
Nesta etapa, os desenvolvedores têm a flexibilidade de escolher quais atividades desejam abordar. Essa abordagem oferece agilidade à equipe, permitindo que distribuam recursos de desenvolvimento de acordo com suas habilidades e disponibilidade. Essa escolha estratégica otimiza a eficiência do processo de desenvolvimento de software, garantindo que cada membro da equipe esteja envolvido nas atividades nas quais se sinta mais capacitado, resultando em um fluxo de trabalho mais produtivo e uma distribuição equilibrada das tarefas.
Isso também fomenta um ambiente de colaboração, onde os desenvolvedores têm voz ativa na seleção das atividades que melhor se encaixam em suas competências, contribuindo para uma entrega mais eficaz.
3.4.4. Desenvolvimento e Testes Unitários pelos Desenvolvedores
Com a atividade escolhida, os desenvolvedores começam a construir o código necessário para implementar a funcionalidade. Simultaneamente, devem ser realizados testes unitários4 rigorosos para garantir que o código desenvolvido funcione corretamente e atenda aos requisitos.
3.4.5. Criação de Casos de Teste pelo QA
O QA desempenha um papel fundamental nesta etapa do processo de desenvolvimento de software. Após receber a tarefa (task) do desenvolvedor (Dev), o QA inicia o processo de criação de casos de teste. Esta etapa é crucial para garantir a qualidade e confiabilidade do software.
O QA começa revisando os requisitos definidos para a atividade. Com base nesses requisitos, o Analista de Qualidade desenvolve casos de teste detalhados que abrangem diferentes cenários e funcionalidades do software. Cada caso de teste é como um roteiro que descreve passo a passo como verificar se o software atende aos requisitos estabelecidos.
Esses casos de teste não apenas cobrem a funcionalidade esperada, mas também consideram cenários de exceção, situações de uso real e casos de uso críticos. Isso garante que o software seja testado de maneira abrangente, abordando tanto os casos ideais quanto os possíveis desvios de funcionamento.
Além disso, os casos de teste criados pelo QA servem como documentação valiosa para futuras referências e para facilitar a comunicação entre a equipe de desenvolvimento e testes. Eles ajudam a garantir que todos os envolvidos tenham um entendimento claro das expectativas em relação ao software.
3.4.6. Testes Manuais e Automatizados pelo QA
Nesta etapa, o Analista de Qualidade coloca em prática os casos de teste previamente elaborados de acordo com cada requisito. O QA realiza então os testes manuais5, que é um dos métodos de identificação de bugs, para validar requisitos mais simples. Durante esses testes, o foco está na interação com o software, verificando a interface do usuário e observando problemas visíveis, erros evidentes e inconformidades imediatas.
Por outro lado, requisitos mais complexos e cenários que demandam testes repetitivos e de alta precisão são abordados por meio de testes automatizados. Aqui, são desenvolvidos scripts de teste que automatizam a interação com o software. Esses scripts executam ações predefinidas e verificam se o software responde conforme o esperado. Os testes automatizados economizam tempo e asseguram uma cobertura minuciosa dos casos de teste, sendo particularmente eficazes em cenários de regressão.
Essas abordagens de testes manuais e automatizados são complementares e desempenham um papel crítico na busca por problemas, erros ou inconformidades no software em desenvolvimento. A combinação de ambas ajuda a garantir a qualidade do software, assegurando que ele atenda aos requisitos estabelecidos nos casos de teste previamente criados. Os resultados desses testes são registrados e comunicados à equipe de desenvolvimento, possibilitando a correção de problemas e o aprimoramento contínuo do software.
3.4.7. Testes Exploratórios pelo QA
Após a conclusão dos testes automatizados, o QA entra na fase de testes exploratórios. Neste estágio, o foco muda para a exploração minuciosa do software além dos cenários definidos pelas regras de negócio e requisitos estabelecidos pelo Product Owner.
Os testes exploratórios são realizados de forma mais flexível, permitindo que o QA investigue o software de maneira mais aberta, buscando possíveis problemas que podem não ter sido cobertos nas fases anteriores. Isso envolve a interação com o software, experimentando diferentes caminhos e ações, e observando atentamente o seu comportamento.
Essa abordagem é valiosa para descobrir eventuais lacunas ou problemas não detectados anteriormente, bem como para identificar possíveis melhorias na usabilidade e na experiência do usuário. Os testes exploratórios complementam os testes baseados em casos de teste, contribuindo para a busca da qualidade abrangente do software.
3.4.8. Registro de Bug Encontrado
Durante o processo de testes, é comum que o QA identifique problemas, erros ou inconformidades no software. Quando isso ocorre, inicia-se a etapa de Registro de Bug encontrado. Nessa fase, o QA utiliza uma abordagem estruturada, muitas vezes baseada na metodologia Gherkin, para documentar detalhadamente o problema.
Essa metodologia é especialmente útil nesse contexto, pois permite descrever os bugs de maneira clara e precisa, incluindo informações sobre a ação que causou o problema, o comportamento esperado e o comportamento observado. Isso facilita a comunicação entre o QA e a equipe de desenvolvimento, garantindo que todos compreendam o problema e possam trabalhar na sua correção de forma eficiente.
Uma vez registrado, o bug é encaminhado para a equipe de desenvolvimento. Os desenvolvedores atuam na correção do problema, garantindo que a feature do sistema seja entregue com alta qualidade. A colaboração próxima entre QA e desenvolvedores desempenha um papel crucial nesse processo, permitindo a resolução ágil de problemas e a entrega de um software confiável e completo.
Em resumo, a etapa de Registro de Bug encontrado é fundamental para a identificação e correção de problemas, contribuindo para a qualidade do software e a satisfação do usuário final.
3.4.9. Validação com PO e outros envolvidos e Entrega ao Cliente
Nesta fase, após a conclusão dos testes, o software passa por uma etapa crítica de validação, na qual o PO e outros stakeholders têm a oportunidade de revisar e validar o trabalho realizado. Se todos os testes forem bem-sucedidos, a atividade é marcada como “Homologação” e submetida à validação pelo PO.
Além do PO, outros envolvidos, como representantes de áreas de negócios e usuários finais, podem participar dessa validação, proporcionando uma visão abrangente do software a partir de diferentes perspectivas.
Uma vez que o software tenha sido validado e aprovado pelos stakeholders, ele está pronto para ser entregue ao cliente, atendendo aos requisitos previamente definidos. Essa entrega é o culminar de um processo de desenvolvimento e teste cuidadosamente planejado e executado. Garante que o produto final atenda aos padrões de qualidade e satisfaça as expectativas dos stakeholders e, por fim, do cliente.
Essa etapa de validação e entrega é um marco significativo no processo, assegurando que o software seja entregue com qualidade e alinhado às expectativas dos stakeholders e, por fim, ao cliente. Essa etapa é fundamental para garantir o sucesso do projeto e a satisfação do cliente.
4. RESULTADOS E DISCUSSÕES
Nesta seção, serão explorados os resultados do novo processo de desenvolvimento e as melhorias alcançadas nas entregas de software. Os resultados serão analisados em detalhes, destacando o impacto nas qualidades do produto, na eficiência do processo e na satisfação do cliente. Essa análise proporcionará uma visão clara do progresso alcançado e das áreas que ainda carecem de aprimoramento.
4.1. Descrição dos Resultados
A análise dos resultados foi realizada ao longo de duas sprints, totalizando aproximadamente um mês. Durante esse período, foram testados dois CRUDs diferentes, sendo que ambos foram desenvolvidos com um esforço semelhante ao do CRUD de escolas, conforme demonstrado na Tabela 1. Na primeira sprint, concentraram-se os esforços no teste de um CRUD de alunos, enquanto na segunda sprint, o foco foi em um CRUD de turmas.
Tabela 02 – Resultados do Novo Processo aplicados às Sprints 07 e 08
| Feature | Tempo de desenvolvimento | Bugs reportados pelo QA | Bugs reportados pelo Cliente (pós entrega) | |
Sprint 07 | Cadastro de Alunos | 2 semanas | 13 | 2 |
| Edição de Alunos | 8 | 3 | ||
| Consulta de Alunos | 6 | 0 | ||
| Deletar Alunos | 8 | 0 | ||
Sprint 08 | Cadastro de Turmas | 2 semanas | 11 | 0 |
| Edição de Turmas | 6 | 1 | ||
| Consulta de Turmas | 8 | 2 | ||
| Deletar Turmas | 5 | 1 |
Fonte: Autores, 2023.
Os resultados impressionam. Sob o novo processo, é possível observar uma redução notável dos bugs reportados pelo cliente após a entrega. Especificamente, na primeira sprint de testes com o CRUD de Alunos, o número de bugs relatados foi substancialmente menor em comparação com o processo anterior. A segunda sprint, que focou no CRUD de Turmas, também apresentou uma grande melhoria na qualidade do software entregue.
Figura 04 – Resultado da Análise de Bugs na Sprint 07
Fonte: Autores, 2023.
Como pode ser visto na Figura 04, esses resultados destacam a eficiência do novo processo na prevenção de erros e na entrega de software mais confiável. Também na Figura 05, é perceptível que a redução no número de bugs relatados pelo cliente é um indicativo sólido de que a equipe está no caminho certo para atender às expectativas de qualidade e satisfação finais. Esta melhoria é um marco significativo na evolução do nosso processo de desenvolvimento.
Figura 05 – Resultado da Análise de Bugs na Sprint 08
Fonte: Autores, 2023.
4.2. Teste comparativo envolvendo a Sprint 02
No contínuo esforço para aprimorar o processo de desenvolvimento, um teste piloto do novo procedimento foi conduzido durante a Sprint 02. Nesse teste, o CRUD foi replicado exatamente como foi entregue na Sprint 02 em um ambiente de teste. A ideia era implementar o novo processo de teste e comparar seu desempenho com o método anterior, com o objetivo de avaliar as melhorias relacionadas à qualidade, conforme demonstrado na Tabela 01. Durante esse cenário, após os testes realizados pelo novo analista de qualidade, a versão corrigida foi submetida à revisão pelo cliente. Além disso, a participação de novos analistas do cliente foi solicitada para identificar possíveis bugs na plataforma.
Tabela 03. Bugs Reportados durante o piloto do novo processo na Sprint 02 de Desenvolvimento
Feature | Tempo de desenvolvimento | Bugs reportados pelo QA | Bugs reportados pelo Cliente | |
Sprint 02 (Nova versão) | Cadastro de Escolas | 2 semanas | 20 | 1 |
| Edição de Escolas | 18 | 2 | ||
| Consulta de Escolas | 12 | 0 | ||
| Deletar Escolas | 14 | 3 |
Fonte: Autores, 2023.
Os resultados foram notáveis: o cliente identificou uma quantidade significativamente menor de bugs, como evidenciado na Tabela 03. Isso representa um indicativo crucial de que as melhorias implementadas elevaram a qualidade do produto a um novo patamar, tornando-o mais confiável. Após os testes, foi realizada uma análise comparativa com os resultados, que pode ser verificada na Figura 06:
Figura 06 – Comparação dos dois processos utilizando a sprint 02
Fonte: Autores, 2023.
Para visualizar de forma mais clara o impacto das mudanças no processo de desenvolvimento, é apresentada a Figura 07, que ilustra a comparação entre o processo antigo e o novo. Este gráfico representa a melhoria nas taxas de detecção de bugs, refletindo o quanto o novo processo se destacou em relação ao método anterior. O gráfico demonstra de maneira inequívoca o avanço significativo alcançado, destacando o impacto positivo das melhorias implementadas na nova abordagem de desenvolvimento.
Figura 06 – Comparação dos dois processos utilizando a sprint 02
Fonte: Autores, 2023.
5. CONSIDERAÇÕES FINAIS
Neste estudo, a pesquisa empreendeu uma jornada de aprimoramento do processo de desenvolvimento de software em uma startup de tecnologias educacionais, com o firme propósito de elevar a qualidade e garantir a entrega de produtos altamente confiáveis. Ao longo das seções anteriores, foi detalhada a avaliação minuciosa do processo anterior, a concepção e implementação do novo procedimento com ênfase na excelência, e a análise comparativa dos resultados obtidos.
Este projeto representou um esforço dedicado à transformação e à evolução do ciclo de desenvolvimento. Como resultado, foi testemunhada uma mudança notável na qualidade do software e na eficiência do trabalho. Através de análises de tabelas e gráficos, pôde ser comprovado de maneira inequívoca que o novo processo reduziu significativamente o número de bugs relatados pelo cliente, um indicador sólido de que o produto é agora altamente confiável.
5.1. Pontos positivos e negativos:
No âmbito positivo, destacaram-se a redução significativa dos bugs reportados pelo cliente, o aumento da satisfação do cliente e a melhoria substancial da qualidade do software entregue. Entretanto, a transição não ocorreu sem desafios notáveis. A adaptação à dinâmica da equipe e a resolução dos erros existentes demandaram aproximadamente três semanas. Essa fase de adaptação, embora desafiadora, revelou-se crucial para a posterior eficácia do novo processo.
5.2. Trabalhos futuros
Sempre há espaço para aprimoramentos contínuos. Pode-se explorar a automação de testes, investigar novas técnicas de validação e expandir o novo processo para outras áreas do desenvolvimento. Além disso, considerar a aplicação bem-sucedida desse modelo em outros projetos da empresa, aproveitando os benefícios em qualidade e eficiência. A equipe também poderia explorar a possibilidade de oferecer consultoria para outras empresas que buscam aprimorar seus processos de desenvolvimento de software, compartilhando lições aprendidas e boas práticas. Espera-se que este trabalho inspire futuros projetos e contribua para a melhoria contínua no desenvolvimento de software.
REFERÊNCIAS
KOLB, J. J. Requisitos Funcionais e Requisitos Não-funcionais. Disponível em:<https://jkolb.com.br/requisitos-funcionais-e-requisitos-nao-funcionais/>. Acesso em: 28 out. 2023.
MALDONADO, 2001 – Qualidade de Software, Teoria e Prática. São Paulo: Pearson, 2001.
MEDEIROS, Matheus Ferreira; MEDEIROS, Alexsandro Melo. Educação e tecnologia: explorando o universo das plataformas digitais e startups na área da educação. In: Anais do V CONEDU-Congresso nacional de educação; Pernambuco: Realize. 2018.
NASCIMENTO, M. C. S. ; SILVA, R. R. ; MORAES, S. A. S. DESENVOLVIMENTO DO SISTEMA DE GERENCIAMENTO DE UNIDADE ESCOLAR– SIGUE. Revista Científica da Faculdade Atenas , v. 8, p. 1, 2016.
PAULA FILHO, Wilson de Pádua. Engenharia de Software: fundamentos, métodos e padrões. São Paulo: LTC Editora, 2000.
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de software: uma abordagem profissional. 8. ed. Porto Alegre: AMGH, 2016.
SILVA, Filipe Toyoshima. Estado da prática da manutenção de software no contexto de startups de software em early stage. 2021. 71 f., il. Trabalho de conclusão de curso (Bacharelado em Engenharia de Software) — Universidade de Brasília, Brasília, 2021.
SOMMERVILLE, Ian. Engenharia de Software: 8ªEdição. São Paulo: Ed. Pearson Addison Wesley, 2007.
3Teste exploratório é uma abordagem intuitiva de verificação de software, onde os testadores interagem diretamente com o sistema, sem um plano de teste prévio, para descobrir falhas e melhorar a usabilidade.
4Teste unitário é uma técnica de verificação de software que avalia individualmente as partes menores e mais básicas do código-fonte, como funções e métodos, para garantir que funcionem corretamente isoladamente.
5Teste manual é um método de verificação de software conduzido por humanos, onde os testadores executam testes seguindo instruções específicas para identificar falhas, erros e problemas de usabilidade.
1 Discentes do Curso Superior de Engenharia de Computação na Faculdade Metropolitana do Amazonas – FAMETRO. E-mail: fabricioalmeida.b@gmail.com / joaohayden@gmail.com / stevao.marques13@gmail.com
2 Docente do Curso Superior de Engenharia de Computação na Faculdade Metropolitana do Amazonas – FAMETRO. Mestre em Informática (Segurança de Sistemas). E-mail: pabloelleres22@gmail.com