Relatório final projeto de extensão ADS: o que muda

O que muda no relatório final em Análise e Desenvolvimento de Sistemas

Quando a disciplina de extensão pertence ao curso de Análise e Desenvolvimento de Sistemas, o relatório precisa deixar claro o vínculo entre a ação realizada e o uso responsável de conhecimentos de tecnologia. A diferença não está em criar um relatório completamente diferente do roteiro acadêmico. O que muda é o tipo de atividade, resultado e evidência que faz sentido apresentar para uma ação ligada a sistemas, processos digitais, capacitação tecnológica ou organização de informação.

Em Análise e Desenvolvimento de Sistemas, uma descrição como "foi criado um sistema" é insuficiente para explicar a contribuição da ação. É mais útil registrar qual problema da comunidade foi abordado, qual solução foi desenvolvida ou demonstrada, quem participou, como a entrega foi utilizada e que documentação ficou disponível para continuidade.

O relatório também precisa respeitar os limites da atuação do estudante. Uma solução tecnológica pode envolver dados pessoais, contas de usuário, informações institucionais ou acesso a sistemas existentes. O fato de uma ferramenta tecnicamente permitir determinada operação não significa que o estudante deva executá-la. A documentação deve registrar apenas o que realmente ocorreu e o que estava autorizado.

O roteiro oficial da disciplina continua sendo a referência para saber quais campos precisam ser preenchidos, como devem ser apresentados e quais procedimentos acadêmicos se aplicam ao período letivo. Este guia trata das particularidades de uma ação de Análise e Desenvolvimento de Sistemas, não substitui as orientações disponíveis no ambiente acadêmico.

• Dê destaque ao problema tecnológico ou informacional enfrentado pela comunidade.
• Explique a entrega de forma verificável, sem transformar o relatório em documentação técnica desnecessariamente extensa.
• Mostre como a solução pode continuar sendo utilizada ou compreendida depois da participação do estudante.
• Evite registrar dados pessoais, credenciais ou informações sensíveis apenas para tentar fortalecer as evidências.

O que conta como resultado em ADS — e o que apenas parece resultado

Em uma ação de Análise e Desenvolvimento de Sistemas, resultado é aquilo que efetivamente mudou, foi produzido, organizado, demonstrado ou disponibilizado como consequência da atividade. Pode ser uma capacitação realizada, um material de orientação, um protótipo documentado, uma estrutura de dados organizada, uma melhoria de processo ou outra entrega compatível com o objetivo da ação.

Um ponto importante é diferenciar produto técnico de resultado da extensão. O código existir, por si só, não explica o benefício ou a utilização da ação. Da mesma forma, uma tela bonita, um repositório criado ou uma apresentação feita podem ser partes da execução, mas precisam ser relacionados ao problema que a atividade buscou enfrentar.

Um resultado especialmente relevante em tecnologia é aquele que não desaparece quando o estudante deixa de participar. A lógica é simples: se somente o estudante sabe operar, corrigir ou explicar a solução, a entrega pode ficar dependente de uma pessoa que não estará permanentemente disponível. Capacitação, documentação e instruções de uso podem reduzir essa dependência.

Exemplo fictício: uma estudante desenvolve, como parte de uma ação extensionista, um pequeno protótipo para organizar inscrições de uma atividade comunitária. O resultado não seria apenas "o protótipo foi programado". Poderia envolver o protótipo demonstrado, um guia de utilização entregue à instituição e uma orientação para que os responsáveis compreendessem o fluxo básico.

Também não é adequado transformar intenção em resultado. Dizer que "a comunidade terá mais segurança digital" ou "o sistema vai melhorar a gestão" apresenta uma expectativa, não uma constatação. O relatório deve separar o que foi planejado, o que foi efetivamente realizado e aquilo que ainda dependeria de continuidade.

• Resultado: entrega ou mudança efetivamente decorrente da ação.
• Atividade: aquilo que o estudante fez para chegar ao resultado.
• Artefato: material, protótipo, documentação ou recurso produzido durante a execução.
• Expectativa: benefício previsto que ainda não pode ser tratado como resultado observado.

Evidências que fazem sentido — e as que podem expor pessoas

Em Análise e Desenvolvimento de Sistemas, evidências podem mostrar a realização de uma capacitação, a apresentação de um protótipo, a existência de documentação ou uma etapa de organização da solução. A evidência deve ajudar a demonstrar que a atividade descrita realmente aconteceu, sem exigir a exposição desnecessária das pessoas envolvidas.

Uma captura de tela pode parecer uma evidência conveniente, mas pode conter nome completo, e-mail, telefone, matrícula, CPF, endereço, dados de acesso ou informações internas. Antes de anexar qualquer registro, é necessário verificar o que aparece na imagem e se existe necessidade de mostrar aquela informação.

Também merece cuidado a publicação de credenciais, tokens, chaves de API, endereços internos, dados de usuários e informações de sistemas que não deveriam ser divulgadas. Uma evidência tecnicamente detalhada pode ser inadequada justamente porque revela mais do que o necessário.

Quando uma fotografia é usada, contexto importa. A imagem deve ter relação clara com a ação e não precisa identificar individualmente cada participante. Para orientações específicas sobre registros fotográficos, consulte a página de [evidências do projeto de extensão](/relatorio-final/evidencias) e o conteúdo sobre [como tirar fotos para projeto de extensão com ética e contexto](/como-tirar-fotos-projeto-extensao).

O mesmo princípio vale para o material técnico: documente o suficiente para demonstrar a entrega, mas não transforme o relatório acadêmico em um depósito de informações internas da instituição atendida.

• Prefira evidências contextualizadas, com data, atividade ou etapa identificável quando isso fizer sentido.
• Revise capturas de tela antes de anexá-las.
• Não publique senhas, tokens, chaves, dados pessoais ou informações internas desnecessárias.
• Se uma pessoa puder ser identificada, considere se a identificação é realmente necessária para demonstrar a ação.

Como descrever a ação sem ultrapassar o limite profissional do curso

O estudante de Análise e Desenvolvimento de Sistemas pode participar de atividades de desenvolvimento, documentação, organização de informações, capacitação e outras tarefas compatíveis com a proposta acadêmica. Isso não significa que qualquer problema tecnológico de uma instituição deva ser resolvido pelo estudante, nem que o relatório deva apresentar uma intervenção acadêmica como se fosse prestação profissional completa.

Uma boa descrição informa o que foi feito, com quais recursos e para qual finalidade, sem atribuir ao estudante responsabilidades que não estavam sob seu controle. Se uma infraestrutura, servidor, serviço de nuvem ou sistema institucional foi administrado por outra pessoa, o relatório não deve sugerir que o estudante realizou essa administração.

O mesmo cuidado vale para segurança da informação. Identificar uma vulnerabilidade durante uma atividade não autoriza automaticamente testes invasivos, coleta de dados ou acesso a sistemas. O relatório deve registrar somente procedimentos efetivamente autorizados e realizados.

O princípio que organiza esta página é a continuidade. Sempre que possível, a entrega deve sobreviver à saída do estudante: uma orientação clara, um material de capacitação, uma documentação compreensível ou um protótipo acompanhado de explicações pode ser mais útil para continuidade do que uma solução que dependa exclusivamente de quem a desenvolveu.

Para entender a estrutura geral da atividade antes de chegar ao relatório, veja o guia [como fazer projeto de extensão: passo a passo prático](/como-fazer-projeto-de-extensao).

Como ligar a ação às competências do curso sem inventar

O relatório de Análise e Desenvolvimento de Sistemas pode relacionar a experiência a competências técnicas e organizacionais trabalhadas no curso, mas essa relação precisa nascer da atividade que realmente aconteceu. Não é necessário listar todas as tecnologias estudadas na graduação para demonstrar vínculo acadêmico.

Se a ação envolveu levantamento de necessidades, por exemplo, o texto pode explicar como essa etapa ajudou a compreender o problema antes da elaboração da solução. Se houve prototipação, pode-se relacionar a atividade à representação de uma interface ou fluxo. Se houve documentação, é possível explicar como ela contribuiu para a compreensão e continuidade da entrega.

Também é possível mencionar programação, banco de dados, análise de requisitos, modelagem, testes, documentação, experiência do usuário ou organização de processos quando esses elementos realmente fizeram parte da atividade. O relatório não deve incluir uma tecnologia apenas porque ela aparece na grade curricular.

Evite frases como "a atividade comprovou domínio completo de desenvolvimento de software" quando a ação envolveu apenas uma etapa pequena. O relatório acadêmico ganha precisão quando descreve a competência mobilizada em uma situação concreta, em vez de transformar uma atividade pontual em uma declaração ampla sobre domínio profissional.

No conteúdo sobre [exemplo de projeto de extensão ADS: guia comentado](/cursos/analise-e-desenvolvimento-de-sistemas/exemplo), o foco pode ser usado para entender como conectar uma ação ao curso sem inventar elementos que não fizeram parte da experiência.

Como escrever a percepção sem cair no genérico

A percepção do estudante ganha força quando mostra uma aprendizagem específica provocada pela atividade. Em vez de escrever que "foi uma experiência muito importante" ou que "aprendeu bastante", explique o que mudou na sua compreensão depois de lidar com um problema real.

Em Análise e Desenvolvimento de Sistemas, uma percepção pode surgir da diferença entre desenvolver para um exercício acadêmico e desenvolver considerando usuários, limitações de infraestrutura, capacidade de manutenção, clareza da documentação ou proteção de dados. O ponto não é declarar que uma dessas situações é melhor, mas registrar o que a experiência concreta revelou.

Exemplo fictício: "Durante a atividade, percebi que uma solução tecnicamente funcional ainda pode ser difícil de manter quando as instruções ficam apenas com quem desenvolveu o protótipo. Por isso, passei a considerar a documentação e a orientação dos usuários como parte da própria entrega." Essa percepção é específica porque relaciona uma observação da ação a uma consequência para a forma de trabalhar.

A percepção também pode registrar uma limitação encontrada. Se uma funcionalidade não pôde ser implantada por falta de infraestrutura ou autorização, isso pode gerar uma aprendizagem sobre requisitos e dependências. Reconhecer uma limitação real é mais consistente do que apresentar uma execução perfeita que não corresponde ao que aconteceu.

Para aprofundar especificamente esse campo, consulte [percepção das atividades extensionistas: como escrever a sua](/relatorio-final/percepcao).

Erros que mais prejudicam o relatório em ADS

Um erro frequente é escrever o relatório como se ele fosse uma documentação de software. O relatório precisa registrar a experiência extensionista; portanto, detalhes como arquitetura, código e configuração só entram quando ajudam a explicar a ação, o resultado ou a aprendizagem.

Outro problema é confundir tecnologia com impacto. Informar que foi usado determinado framework, banco de dados ou editor não demonstra, sozinho, que a ação alcançou seu objetivo. A tecnologia deve aparecer vinculada ao que ela permitiu realizar na atividade.

Também é problemático apresentar uma solução como definitiva quando ela era apenas um protótipo. Termos como "sistema implantado", "base de produção" ou "solução em funcionamento" devem corresponder ao que efetivamente ocorreu.

No campo das evidências, o excesso também pode prejudicar. Uma pasta cheia de capturas de tela não necessariamente documenta melhor a ação, especialmente quando contém informações pessoais ou internas. O ideal é selecionar registros que tenham relação direta com o que está sendo afirmado.

Por fim, não atribua ao estudante responsabilidades que pertenciam à instituição, a profissionais contratados ou a outros participantes. Se o estudante auxiliou em uma etapa, descreva essa etapa. Se apenas apresentou uma possibilidade, não registre como implementação concluída.

• Descrever código em excesso e explicar a ação de menos.
• Confundir ferramenta utilizada com resultado alcançado.
• Apresentar protótipo como sistema definitivo.
• Usar capturas de tela com dados pessoais ou informações internas.
• Atribuir ao estudante tarefas que ele não executou.
• Transformar expectativa futura em resultado já obtido.

Exemplo fictício de duas seções do relatório

Os textos abaixo são exemplos fictícios. Eles não representam uma atividade real, não devem ser apresentados como relato de experiência e precisam ser adaptados ao que efetivamente aconteceu em cada projeto.

Exemplo fictício — resultado da ação: "Ao final da atividade, foi disponibilizado um protótipo de formulário digital para organizar o recebimento de inscrições de uma iniciativa comunitária. A entrega foi acompanhada de uma orientação sobre o fluxo de preenchimento e de um documento explicando os passos básicos para utilização. O protótipo não foi apresentado como sistema definitivo, pois sua continuidade dependeria de decisões e infraestrutura da instituição."

Exemplo fictício — percepção: "A atividade mostrou que uma solução funcional não é suficiente quando somente a pessoa que a desenvolveu consegue compreender seu funcionamento. Durante a experiência, percebi a importância de registrar decisões, explicar o fluxo para os usuários e considerar desde o início como outra pessoa poderá manter ou adaptar a entrega."

A diferença entre esses dois trechos é intencional. O primeiro descreve uma entrega e seus limites; o segundo registra uma aprendizagem decorrente da experiência. Para preencher os campos reais, consulte as páginas específicas sobre [resultado da ação](/relatorio-final/resultado-da-acao), [conclusão](/relatorio-final/conclusao), [durante a ação](/relatorio-final/durante-a-acao) e [percepção](/relatorio-final/percepcao), sem copiar o exemplo como se fosse uma experiência própria.

Checklist final e próximos passos

Antes de concluir o relatório, faça uma revisão específica para o contexto de Análise e Desenvolvimento de Sistemas. A pergunta central é se alguém que leia o documento consegue entender qual problema tecnológico ou informacional foi enfrentado, o que o estudante realmente fez, qual entrega resultou disso e quais limites existiram.

Depois, confira o roteiro oficial disponível no ambiente acadêmico. Os campos, instruções e critérios da disciplina podem variar conforme a instituição, o curso, a matriz curricular e o período letivo. Este conteúdo não substitui essa orientação.

Também vale revisar as evidências com atenção especial à privacidade. Uma evidência deve demonstrar a atividade sem expor pessoas, credenciais ou informações institucionais além do necessário.

Como próximo passo, organize a documentação enquanto a experiência ainda está recente: registre o que foi feito, guarde materiais que possam comprovar a execução de forma segura, identifique as entregas e anote limitações que realmente ocorreram. Depois, use essas informações para preencher cada campo do roteiro, em vez de tentar reconstruir a experiência apenas no momento da entrega.

• O texto descreve uma atividade que realmente aconteceu?
• A entrega está separada da expectativa de benefício futuro?
• O papel do estudante está descrito sem exagero?
• A solução está documentada o suficiente para não depender apenas do estudante?
• As evidências evitam dados pessoais, credenciais e informações internas desnecessárias?
• As tecnologias mencionadas foram realmente utilizadas na ação?
• A relação com Análise e Desenvolvimento de Sistemas aparece de forma concreta?
• Os campos e instruções foram conferidos no roteiro oficial da disciplina?