Exemplo de projeto de extensão ADS: guia comentado

1. O problema observado: por que esta ação

Antes de escrever o exemplo, um aviso importante: todos os nomes, locais, números e situações apresentados nesta página são fictícios. Eles servem apenas para mostrar como uma proposta de extensão em Análise e Desenvolvimento de Sistemas pode ser registrada sem transformar uma situação inventada em relato de uma atividade que realmente aconteceu.

TRECHO DO EXEMPLO — "A Associação Comunitária Caminhos do Sol, localizada no fictício bairro Jardim das Palmeiras, utiliza planilhas e arquivos digitais para registrar inscrições, contatos e atividades realizadas. Em conversa inicial com uma representante da associação, foi relatada dificuldade para localizar versões atualizadas dos arquivos e para organizar os procedimentos de cadastro. A ação proposta será uma oficina de organização de arquivos digitais, acompanhada de um pequeno protótipo documentado para demonstrar uma forma estruturada de registrar atendimentos, sem utilizar dados pessoais reais."

COMENTÁRIO — O trecho começa pelo problema observado, não pela tecnologia. Isso é importante em um projeto de Análise e Desenvolvimento de Sistemas porque a solução técnica precisa responder a uma necessidade identificada. O exemplo não afirma que a associação realmente existe nem que os problemas foram comprovados por pesquisa formal: são elementos fictícios criados para demonstrar a escrita.

Também há uma escolha deliberada de escopo. Em vez de prometer um sistema completo que dependeria do estudante para manutenção, a proposta combina capacitação, material de apoio e um protótipo documentado. O protótipo demonstra uma possibilidade sem criar a expectativa de que a associação ficará dependente de uma aplicação que o estudante precisará hospedar, corrigir ou manter depois da disciplina.

• O problema deve aparecer antes da ferramenta escolhida.
• O exemplo fictício precisa continuar identificado como fictício.
• Evite colocar dados pessoais reais em protótipos, capturas de tela ou planilhas usadas como demonstração.

2. Público, local e aproximação

TRECHO DO EXEMPLO — "O público da ação será formado por seis integrantes voluntários da Associação Comunitária Caminhos do Sol, no fictício bairro Jardim das Palmeiras. O contato inicial será feito por mensagem enviada à associação, seguida de uma conversa para verificar se a oficina é pertinente à rotina dos participantes. A atividade ocorrerá em uma sala disponibilizada pela associação, caso o espaço esteja disponível. Se o local não puder receber a atividade, será combinada uma alternativa adequada com os participantes."

COMENTÁRIO — O objetivo desta seção é deixar claro quem participa, onde a ação acontece e como houve aproximação com o público. Como os números do exemplo são inventados, eles não devem ser copiados para um projeto real. No seu trabalho, substitua essas informações pelo que efetivamente ocorreu e pelo que o roteiro da disciplina solicitar.

Em uma ação de Análise e Desenvolvimento de Sistemas, vale especificar o perfil do público em relação à atividade tecnológica. Não é necessário transformar a seção em um levantamento demográfico extenso. É mais útil explicar, por exemplo, que os participantes utilizam arquivos digitais no cotidiano da instituição, mas precisam de uma forma mais organizada de nomear, armazenar e localizar documentos.

A aproximação também deve ser compatível com o que realmente foi feito. Se o estudante conversou com uma pessoa responsável pelo local, registre isso. Se houve apenas uma troca de mensagens para combinar a oficina, não descreva uma reunião presencial que não aconteceu.

3. Objetivo geral e objetivos específicos

TRECHO DO EXEMPLO — "Objetivo geral: contribuir para a organização das rotinas digitais da Associação Comunitária Caminhos do Sol por meio de uma oficina prática sobre organização de arquivos e de um protótipo didático documentado, sem utilização de dados pessoais reais."

TRECHO DO EXEMPLO — "Objetivos específicos: apresentar uma estrutura simples de pastas e nomes de arquivos; demonstrar procedimentos para identificar versões de documentos; orientar os participantes sobre cuidados básicos ao compartilhar arquivos; produzir um material de consulta para uso posterior; desenvolver um protótipo fictício de cadastro que permita demonstrar campos e fluxos sem armazenar informações pessoais dos participantes."

COMENTÁRIO — Os objetivos específicos transformam a intenção geral em entregas observáveis. Para um projeto de Análise e Desenvolvimento de Sistemas, é útil que os objetivos técnicos estejam ligados ao problema apresentado, em vez de listar tecnologias apenas porque fazem parte do curso.

Também é importante não prometer mais do que a ação consegue entregar. "Criar um sistema completo para a associação" seria uma formulação muito mais ampla e poderia criar dependência de manutenção. No exemplo, o protótipo tem função demonstrativa e o conhecimento principal fica registrado em material que pode ser consultado depois.

• Objetivo geral: uma finalidade central, ligada ao problema.
• Objetivos específicos: ações ou entregas concretas que ajudam a alcançar essa finalidade.
• Tecnologia deve aparecer como meio da ação, não como objetivo isolado.

4. A justificativa ligada à formação em tecnologia

TRECHO DO EXEMPLO — "A ação está relacionada à formação em Análise e Desenvolvimento de Sistemas porque envolve levantamento de uma necessidade, organização de informações, definição de requisitos simples, elaboração de uma solução demonstrativa e documentação de procedimentos. A proposta também permite discutir aspectos de usabilidade, organização de dados e cuidados no tratamento de informações pessoais. A escolha por uma oficina acompanhada de protótipo documentado busca produzir uma contribuição que continue útil mesmo após o encerramento da participação do estudante."

COMENTÁRIO — A justificativa não precisa dizer apenas que a atividade "tem relação com tecnologia". Ela deve mostrar quais conhecimentos de Análise e Desenvolvimento de Sistemas aparecem na ação. Neste caso, levantamento de necessidades, requisitos, organização de dados, documentação e usabilidade são conexões mais concretas.

O cuidado com dados pessoais também faz parte da escolha técnica. Um protótipo de extensão não precisa utilizar nomes, telefones, endereços ou outros dados reais para demonstrar uma estrutura de cadastro. Dados fictícios ou registros anonimizados, quando adequados ao objetivo e ao roteiro, reduzem a exposição desnecessária de informações.

5. Metodologia: sequência, materiais e execução

TRECHO DO EXEMPLO — "A ação será organizada em cinco etapas. Primeiro, será realizada uma conversa inicial para identificar as principais dificuldades de organização dos arquivos. Depois, será preparada uma estrutura de pastas e um padrão simples de nomenclatura. Na terceira etapa, será realizada uma oficina prática, utilizando computador, projetor e arquivos fictícios. Em seguida, será apresentado um protótipo didático de cadastro, preenchido somente com dados inventados. Por fim, será entregue um guia curto com os procedimentos demonstrados durante a oficina."

COMENTÁRIO — A metodologia responde ao que foi feito, em que ordem e com quais materiais. Em um exemplo de Análise e Desenvolvimento de Sistemas, vale deixar visível a parte de análise antes da implementação: primeiro se entende a necessidade, depois se define a solução demonstrativa.

Os materiais também precisam corresponder à atividade. Se houver apresentação, guia, formulário, protótipo ou roteiro de oficina, registre o que realmente foi utilizado. Não é necessário inventar uma arquitetura complexa para tornar o projeto mais técnico.

A escolha por arquivos fictícios no exemplo é intencional. Se uma atividade real exigir demonstração de cadastro, o estudante deve verificar quais informações podem ser utilizadas e evitar coletar ou divulgar dados pessoais sem necessidade. O projeto deve ser pensado para que a utilidade da ação não dependa de conservar uma base de dados pessoal criada pelo estudante.

• Etapa 1: identificar a necessidade.
• Etapa 2: organizar a solução ou procedimento.
• Etapa 3: realizar a atividade prática.
• Etapa 4: demonstrar o protótipo com dados fictícios.
• Etapa 5: registrar e entregar o material de consulta.

6. Um cronograma compatível com a disciplina

TRECHO DO EXEMPLO — "Semana 1: contato inicial e definição do problema. Semana 2: levantamento das necessidades e preparação do roteiro. Semana 3: elaboração dos materiais e do protótipo demonstrativo. Semana 4: realização da oficina. Semana 5: coleta das percepções dos participantes e organização das evidências. Semana 6: revisão dos registros e preparação da documentação final."

COMENTÁRIO — Este cronograma é apenas um exemplo fictício. Não significa que uma disciplina de extensão precise durar seis semanas. Prazos, etapas, quantidade de horas e campos obrigatórios variam conforme o curso, a matriz curricular e o período letivo. Para saber o que precisa ser cumprido no seu caso, consulte o roteiro oficial disponibilizado no ambiente acadêmico.

A utilidade do cronograma está em distribuir trabalho de forma plausível. Em uma ação de Análise e Desenvolvimento de Sistemas, reservar tempo para entender o problema, preparar materiais, testar a demonstração e organizar evidências evita concentrar toda a execução na etapa final.

Também vale prever uma etapa de encerramento. Um protótipo ou oficina não deve ser tratado como se estivesse concluído no momento em que a apresentação termina; ainda há registros a organizar, percepções a consolidar e documentação a revisar.

7. Evidências: o que registrar e o que evitar

TRECHO DO EXEMPLO — "Foram previstos como registros da ação: fotografia do espaço durante a oficina, quando autorizada; lista de presença ou outro registro de participação exigido pelo roteiro; cópia do material utilizado na capacitação; versão demonstrativa do protótipo; e registro escrito das principais dúvidas apresentadas pelos participantes. Não serão produzidas fotografias de documentos contendo dados pessoais nem capturas de tela com informações reais de usuários."

COMENTÁRIO — Evidência não significa produzir o maior número possível de fotos ou arquivos. O registro deve ajudar a demonstrar que determinada atividade aconteceu e permitir relacioná-la ao projeto. A forma exata de comprovação depende do roteiro da disciplina e das orientações da instituição.

Em tecnologia, existe um cuidado adicional: uma tela de sistema pode revelar nome, telefone, e-mail, documento, endereço ou outros dados. Não fotografe nem publique esse conteúdo apenas para criar uma evidência visual. Se uma captura for necessária para demonstrar o protótipo, use dados fictícios e remova informações que não sejam necessárias.

Também não se deve fabricar evidência. Uma imagem encenada não deve ser apresentada como registro espontâneo de uma atividade que não aconteceu. Quando o roteiro exigir comprovação, produza registros durante a execução real e respeite as orientações de autorização e privacidade.

• Registre atividades reais e identificáveis.
• Use dados fictícios em telas e protótipos demonstrativos.
• Não fotografe documentos pessoais apenas para preencher uma exigência.
• Confira no roteiro quais evidências são efetivamente solicitadas.

8. Resultado da ação sem inflar o que aconteceu

TRECHO DO EXEMPLO — "Ao final da atividade, os participantes foram convidados a reorganizar uma pequena coleção de arquivos fictícios utilizando o padrão apresentado na oficina. No exercício proposto, os participantes conseguiram identificar a pasta correspondente a cada tipo de documento e aplicar a convenção de nomes apresentada. As principais dúvidas registradas envolveram controle de versões e compartilhamento de arquivos. O material de consulta foi entregue ao grupo para uso posterior."

COMENTÁRIO — O resultado é descrito a partir do que foi observado ou registrado, não de uma promessa ampla. Em vez de afirmar que a associação "melhorou sua gestão digital", o exemplo informa qual exercício foi realizado e quais dúvidas apareceram. Isso torna a descrição mais verificável.

Se o estudante quiser medir a ação, pode definir um indicador compatível com a atividade. Neste exemplo fictício, seria possível comparar o desempenho no exercício proposto antes e depois da explicação, desde que esse procedimento realmente tivesse sido aplicado. Também seria possível registrar quantos participantes concluíram uma tarefa específica. O importante é não transformar uma impressão em estatística.

Expressões como "todos aprenderam", "a organização ficou muito mais eficiente" ou "o problema foi resolvido" exigem evidências que nem sempre existem. Uma documentação acadêmica mais sólida separa aquilo que foi observado daquilo que seria apenas uma expectativa.

9. O que o estudante aprende ao escrever o projeto

TRECHO DO EXEMPLO — "A elaboração da ação permitiu perceber que uma solução tecnológica precisa começar pela compreensão do uso que será feito dela. Durante o planejamento, foi necessário separar requisitos realmente necessários de funcionalidades que poderiam aumentar a complexidade sem contribuir para o problema identificado. A preparação do protótipo também mostrou a importância de documentar os fluxos e de utilizar dados fictícios na demonstração."

COMENTÁRIO — A percepção do estudante não deve repetir o resultado da ação. Aqui, o foco está no aprendizado decorrente do planejamento e da execução. Para quem cursa Análise e Desenvolvimento de Sistemas, essa reflexão pode abordar levantamento de requisitos, comunicação com usuários, escolha de escopo, documentação, usabilidade, proteção de dados e limites de uma solução.

Uma boa percepção também pode registrar uma dificuldade concreta. Por exemplo, o estudante pode perceber que uma funcionalidade inicialmente imaginada não era necessária para o problema encontrado. Essa constatação mostra reflexão sobre o processo sem precisar transformar a experiência em uma narrativa de sucesso absoluto.

10. Como adaptar o exemplo ao seu roteiro

TRECHO DO EXEMPLO — "Este projeto fictício foi organizado com contexto, público, objetivos, justificativa, metodologia, cronograma, evidências, resultados e percepção do estudante. Para a versão acadêmica, cada seção será ajustada ao roteiro oficial da disciplina, preservando somente as informações que correspondem à atividade realmente realizada."

COMENTÁRIO — Não copie nomes, quantidades, datas, local ou resultados deste exemplo para o seu projeto como se fossem seus. O objetivo é observar a lógica da escrita: apresentar uma necessidade concreta, explicar por que a ação tem relação com Análise e Desenvolvimento de Sistemas, descrever uma execução possível e registrar evidências compatíveis com o que aconteceu.

O roteiro da sua instituição tem prioridade. Ele pode solicitar campos diferentes, ordem diferente ou informações adicionais. Exigências de horas, prazos, campos obrigatórios e formato de entrega variam por curso, matriz e período letivo; consulte sempre o ambiente acadêmico do aluno.

Para entender a estrutura mais ampla de um projeto, consulte as páginas sobre projeto de extensão e como fazer projeto de extensão. Aqui, o foco é mais estreito: mostrar, por meio de uma única situação fictícia, como cada parte pode ser preenchida quando o curso é Análise e Desenvolvimento de Sistemas.

O ponto central do exemplo é a escolha de uma entrega que continue útil sem depender do estudante. Uma capacitação, um material de consulta e um protótipo documentado podem cumprir essa função melhor do que uma aplicação improvisada que exigiria hospedagem, correções e manutenção depois do encerramento da disciplina.