Projeto De Extensão Ii Análise E Desenvolvimento De Sistemas

Projeto de extensão II no curso de ADS: como funciona na prática

A maioria dos alunos chega na segunda versão do projeto de extensão achando que vai ser mais do mesmo. Só que não é. O primeiro semestre costuma ser mais focado em levantar requisitos e entender o problema. O segundo semestre já exige algo diferente: entregar software rodando, mesmo que simples, para a comunidade parceira. Isso muda completamente a dinâmica. O problema real que eu vejo todo ano é o mesmo. A comunidade parceira tem uma necessidade real, mas a descrição inicial deles nunca serve como especificação técnica. Eu trabalho com uma associação de bairro no interior de Minas Gerais que precisava de um sistema de cadastro de voluntários há anos. Na extensão I, passamos quatro meses só conversando com os voluntários e mapeando fluxos. Na extensão II, quando entregamos a primeira versão, percebemos que o sistema havia sido construído em cima de um suposto — eles iam precisar de integração com WhatsApp para avisos, algo que nunca mencionaram porque não sabiam que era possível. A solução foi rápida e simples: abrimos uma API de envio de mensagens via WhatsApp Business usando a biblioteca oficial do Meta, mas só para notificações unidirecionais. Não tentamos fazer atendimento automatizado. O escopo ficou contido. Se alguém pedir uma funcionalidade que exige integração bidirecional complexa, sugiro encaminhar para um terceiro semestre ou para outra disciplina com mais horas. Projeto de extensão não é lugar para MVPs ambiciosos demais.

Projeto de extensão ii análise e desenvolvimento de sistemas: roteiro técnico

Vou explicar a metodologia que costumo aplicar quando lidero esses grupos, baseada em experiências em múltiplas instituições. O fluxo não é linear, mas segue padrões que reduzem bastante o retrabalho. O primeiro passo é o levantamento de restrições técnicas junto à equipe. Antes de escrever qualquer linha de código, você precisa saber o que o servidor da comunidade suporta, se há conexão estável, se eles têm orçamento para hospedagem ou se tudo vai rodar localmente. Isso define a stack inteira. Um sistema web robusto em Node.js com banco PostgreSQL pode ser uma péssima escolha se o parceiro não tiver um técnico que saiba dar manutenção. Neste caso, PHP com MySQL rodando no mesmo servidor local é muito mais sustentável a longo prazo. O segundo passo é a definição do escopo mínimo viável. Eu costumo usar a técnica de dividir funcionalidades em três camadas: essenciais, desejáveis e futuramente desejáveis. As essenciais precisam estar funcionando no dia da entrega final. As demais só entram se sobrar tempo. Já vi grupos inteiros falharem porque tentaram implementar relatório em PDF, dashboard analítico e módulo de login social tudo ao mesmo tempo.

O terceiro passo é o desenvolvimento iterativo com testes de usabilidade quinzenais. Não adianta desenvolver três meses inteiros sem mostrar nada para o parceiro. A cada duas semanas, leve uma versão funcional para a comunidade testarem. Mesmo que seja um protótipo com interface feia. O feedback deles nessa fase evita que você termine o semestre com um sistema que ninguém usa.

Pitfalls comuns que poucos mencionam

Um erro recorrente é subestimar a curva de aprendizado do parceiro. Desenvolvedores novatos frequentemente criam interfaces com jargões técnicos que o usuário final não compreende. O resultado é um sistema tecnicamente perfeito que fica engavetado por não conseguir ser operado por quem realmente precisa usar. Recomendo fazer pelo menos uma sessão de treinamento gravada em vídeo antes da entrega, com demonstrações passo a passo das funções principais. Outro ponto negligenciado é a documentação técnica. Muitos alunos entendem extensão como desenvolvimento puro e acabam entregando apenas o código. O regulamento da maioria das universidades exige relatório técnico, manual de usuário e documentação do código-fonte. Sem isso, a banca reprova independentemente da qualidade do software. Eu costumo reservar duas semanas do cronograma exclusivamente para documentação, antes da apresentação final.

Sobre avaliação e entregas

O projeto de extensão ii análise e desenvolvimento de sistemas geralmente segue a carga horária definida pela coordenação do curso, com encontros semanais obrigatórios e produção acumulada ao longo do semestre. A avaliação combina três critérios: a qualidade técnica do produto entregue, a capacidade de comunicação com a comunidade e a documentação produzida. Não existe um padrão único porque cada instituição organiza de um jeito diferente. Verifique o regulamento interno do seu campus no início do semestre. Perder o prazo de entrega de documentação costuma ser mais penalizado do que entregar um sistema com bugs menores. Uma informação útil: alguns programas de extensão oferecem templates de documento e planilhas de acompanhamento no portal da extensão universitária. Não custa verificar. Economiza horas de formatação desnecessária.

Ferramentas que funcionam (e quais evitar)

Para versionamento, Git com GitHub ou GitLab funciona bem. Use branches por funcionalidade e pull requests revisados. Para controle de tarefas, o Trello ou até uma planilha compartilhada resolve nos primeiros semestres. Ferramentas mais pesadas como Jira só valem a pena se o grupo tiver mais de seis pessoas e projetos de larga escala. Evite depender de serviços pagos de terceiros sem planejamento de custo. Uma vez, um grupo integrou um gateway de pagamento gratuito na versão de teste e esqueceu que a API tinha limite de requisições. Na apresentação final, o sistema travou durante a demonstração. Sempre tenha um plano B local ou offline para funcionalidades críticas.

Conclusão prática

Projeto de extensão ii análise e desenvolvimento de sistemas não é sobre construir o produto mais sofisticado. É sobre resolver um problema real com as ferramentas certas, dentro das restrições que o parceiro possui. A tecnologia vem em segundo plano. O relacionamento com a comunidade e a capacidade de adaptar o escopo conforme o feedback são o que faz a diferença entre um projeto memorável e um que fica esquecido na gaveta depois da banca. Se você estiver no segundo semestre e ainda não mapeou as limitações técnicas do parceiro, pare tudo e faça isso antes de abrir a IDE. O resto vem depois.