├── demoday ├── TEMPLATE_POSTER_PORTIFOLIO.pdf ├── TEMPLATE_POSTER_PORTIFOLIO.pptx ├── locais_publicacao.md ├── guia_poster.md └── Avaliacao_Poster_DemoDay.md ├── LICENSE ├── directions ├── portfolio-directions-jogosdigitais.md ├── portfolio-directions-iot.md ├── portfolio-directions-ia.md ├── portfolio-directions-webapp.md ├── portfolio-directions-mobile.md └── portfolio-directions-GERAL.md ├── disciplina-portfolio.md ├── RFC ├── diretrizes-avaliacao-professores.md ├── modelo-de-RFC.md └── normas.md └── README.md /demoday/TEMPLATE_POSTER_PORTIFOLIO.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/CatolicaSC-Portfolio/The-Portfolio-Playbook-I/HEAD/demoday/TEMPLATE_POSTER_PORTIFOLIO.pdf -------------------------------------------------------------------------------- /demoday/TEMPLATE_POSTER_PORTIFOLIO.pptx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/CatolicaSC-Portfolio/The-Portfolio-Playbook-I/HEAD/demoday/TEMPLATE_POSTER_PORTIFOLIO.pptx -------------------------------------------------------------------------------- /demoday/locais_publicacao.md: -------------------------------------------------------------------------------- 1 | ## Locais para Publicar o APP 2 | 3 | ### 🌐 Sobre 4 | Os principais provedores de nuvem oferecem algum nível de serviço gratuito para testes e deploy de projetos. 5 | Esta lista pode ser utilizada como referência para publicar os projetos desenvolvidos no **Portfólio**. 6 | 7 | --- 8 | 9 | ### 🔑 Principais Players com Nível Gratuito 10 | - [Amazon AWS](https://aws.amazon.com/free/) 11 | - [Google Cloud](https://cloud.google.com/free) 12 | - [IBM Cloud](https://www.ibm.com/cloud/free) 13 | - [Microsoft Azure](https://azure.microsoft.com/free) 14 | - [Vultr](https://www.vultr.com/) 15 | 16 | --- 17 | 18 | ### 🎓 Benefícios para Estudantes 19 | - Ao se inscrever no [GitHub for Students](https://education.github.com/pack), a **Microsoft** oferece **US$ 100** em créditos no Azure **sem precisar informar cartão de crédito**. 20 | - Outras ofertas interessantes estão disponíveis no [GitHub Student Developer Pack Offers](https://education.github.com/pack/offers). 21 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | This is free and unencumbered software released into the public domain. 2 | 3 | Anyone is free to copy, modify, publish, use, compile, sell, or 4 | distribute this software, either in source code form or as a compiled 5 | binary, for any purpose, commercial or non-commercial, and by any 6 | means. 7 | 8 | In jurisdictions that recognize copyright laws, the author or authors 9 | of this software dedicate any and all copyright interest in the 10 | software to the public domain. We make this dedication for the benefit 11 | of the public at large and to the detriment of our heirs and 12 | successors. We intend this dedication to be an overt act of 13 | relinquishment in perpetuity of all present and future rights to this 14 | software under copyright law. 15 | 16 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, 17 | EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF 18 | MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. 19 | IN NO EVENT SHALL THE AUTHORS BE LIABLE FOR ANY CLAIM, DAMAGES OR 20 | OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, 21 | ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR 22 | OTHER DEALINGS IN THE SOFTWARE. 23 | 24 | For more information, please refer to 25 | -------------------------------------------------------------------------------- /demoday/guia_poster.md: -------------------------------------------------------------------------------- 1 | # Guia para o Pôster – Poster + Demo Day 2 | 3 | ## 🎯 Participação no Poster + Demo Day 4 | Para que o projeto seja habilitado a participar do evento final, é necessário: 5 | - Atender aos requisitos mínimos da **linha de projeto escolhida**. 6 | - Estar **funcional** e **acessível ao público** (deploy ou entrega testável). 7 | - Conter **documentação clara e organizada**. 8 | 9 | --- 10 | 11 | ## 📐 Formato do Pôster 12 | - **Tamanho**: A0 (841 x 1189 mm). 13 | - **Orientação**: Retrato (vertical). 14 | - **Padrão visual**: Coerente, com cores, margens e disposição de elementos harmoniosos. 15 | 16 | --- 17 | 18 | ## 📋 Elementos Obrigatórios 19 | - Logomarca da **Católica SC**. 20 | - **Título** do projeto. 21 | - **Nome e e-mail** do integrante. 22 | - **QR Code** para acesso à solução em ambiente produtivo. 23 | - **Contexto / Problema**. 24 | - **Solução proposta**. 25 | - **Arquitetura** (diagrama ou representação visual). 26 | - **Referências** (bibliográficas, técnicas, links relevantes). 27 | - **Template** : Cabeçalho, rodapé e padrões de cores devem seguir o [TEMPLATE AQUI](https://github.com/CatolicaSC-Portfolio/The-Portfolio-Playbook-I/blob/main/demoday/TEMPLATE_POSTER_PORTIFOLIO.pptx) 28 | -- Exemplo de Poster (Não necessáriamente seu poster deve conter essa quantidade de texto, os textos são orientações!) [EXEMPLO](https://github.com/CatolicaSC-Portfolio/The-Portfolio-Playbook-I/blob/main/demoday/TEMPLATE_POSTER_PORTIFOLIO.pdf) 29 | 30 | --- 31 | 32 | ## ✍️ Padronização de Texto 33 | - **Fonte**: Tamanho mínimo de 20 pontos, preferencialmente Arial ou equivalentes. 34 | - **Cores**: Utilizar combinações com bom contraste e legibilidade. 35 | - **Conteúdo**: Evitar excesso de texto – priorizar **imagens, diagramas e tópicos**. 36 | 37 | --- 38 | 39 | ## 💡 Boas Práticas Visuais 40 | - O pôster deve ser **autoexplicativo**, permitindo compreensão mesmo sem a presença do autor. 41 | - Utilizar **imagens e gráficos em alta resolução**. 42 | - É permitido e **fortemente recomendado** o uso de QR Codes para: 43 | - Link para o repositório do projeto. 44 | - Vídeo de demonstração. 45 | - Documentação complementar. 46 | 47 | --- 48 | 49 | ## ✅ Checklist do Pôster 50 | - [ ] Formato e dimensões corretos. 51 | - [ ] Elementos obrigatórios inseridos. 52 | - [ ] Texto legível e com bom contraste. 53 | - [ ] Uso adequado de imagens e diagramas. 54 | - [ ] QR Code funcional e apontando para conteúdo relevante. 55 | - [ ] Revisão final para garantir que o pôster seja autoexplicativo. 56 | 57 | --- 58 | 59 | > **Dica:** Teste o QR Code antes do evento e verifique a impressão em tamanho real para garantir legibilidade e qualidade visual. 60 | -------------------------------------------------------------------------------- /directions/portfolio-directions-jogosdigitais.md: -------------------------------------------------------------------------------- 1 | # Linha de Projeto – Jogos Digitais 2 | 3 | ### O que é obrigatório atender 4 | - O jogo deve ser jogável do início ao fim, com ao menos uma fase ou loop completo funcional. 5 | - Build funcional distribuída (ex.: executável standalone, WebGL hospedado, APK, ou link para plataforma de testes). 6 | - Código-fonte acessível em repositório público ou privado com acesso autorizado. 7 | - Documentação com foco em game design: visão geral do jogo, objetivo principal, loop central de gameplay, mecânicas implementadas e tecnologias utilizadas. 8 | - Apresentação de elementos mínimos de jogabilidade: personagem/jogador controlável, regras, objetivo, vitória/derrota. 9 | - Interface minimamente navegável (menus, HUD, feedbacks visuais ou sonoros). 10 | - Arte e som podem ser placeholders, mas precisam representar a intenção do design. 11 | 12 | --- 13 | 14 | ## O que é desejável atender 15 | - Documento de Game Design (GDD) estruturado com gameplay loop, core mechanics, sistemas e feedbacks planejados. GDD Completo. 16 | - Design visual e sonoro consistente com a proposta do jogo. 17 | - Implementação de feedback tátil, visual e/ou sonoro (game feel). 18 | - Uso de engine consolidada no mercado (Unity, Unreal, Godot, etc.) ou criação da própria engine. 19 | - Build publicada em plataforma de acesso público (ex.: Itch.io, Steam em acesso antecipado, Google Play em beta) com o jogo completo - todas as fases, todo o conteúdo. 20 | - Suporte a diferentes resoluções e dispositivos (caso multiplataforma). 21 | 22 | --- 23 | 24 | ## O que é um diferencial 25 | - Implementação de sistemas de progressão, IA, física personalizada, multiplayer ou mecânicas emergentes. 26 | - Playtests com público externo e iteração baseada em feedback real. 27 | - Experiência polida com foco em imersão, ritmo e curva de dificuldade. 28 | - Design original de arte, som e narrativa integrada ao gameplay. 29 | - Lançamento efetivo em loja/plataforma ou marketing ativo. 30 | 31 | --- 32 | 33 | ## O que deve ser evitado 34 | - Cópia direta de tutoriais sem personalização. 35 | - Mecânicas desconexas ou sem clareza no objetivo do jogador. 36 | - Bugs que comprometem a experiência de jogo (ex.: quedas de FPS, travamentos, impossibilidade de completar a fase). 37 | - Interface poluída ou ausente, dificultando navegação ou entendimento. 38 | 39 | --- 40 | 41 | ## O que não pode ter 42 | - Projeto com apenas mockups ou trailer sem jogabilidade funcional. 43 | - Plágio de jogos existentes com assets e código copiados sem modificação. 44 | - Experiência de jogo inexistente ou sem interação (ex.: apenas uma cutscene, apenas menus). 45 | - Falta completa de regras ou condições de jogo. 46 | - Quebra do ciclo de jogo: sem condição de vitória/derrota, ou sem ações significativas do jogador. 47 | 48 | --- 49 | 50 | ## Régua de Avaliação 51 | - **Aprovado**: o jogo está funcional, apresenta ao menos um loop básico completo, com documentação coerente. 52 | - **Destaque**: além dos requisitos básicos, o projeto possui gameplay consistente, polimento, diferencial técnico ou criativo, e evidência de iteração com base em testes. 53 | - **Reprovado**: não apresenta jogabilidade mínima funcional, plágio evidente ou quebra de critérios obrigatórios. 54 | -------------------------------------------------------------------------------- /disciplina-portfolio.md: -------------------------------------------------------------------------------- 1 | # Disciplina de Portfólio – Católica SC 2 | 3 | Esta disciplina busca preparar os alunos para entregas reais, incentivando excelência técnica, inovação e responsabilidade profissional. 4 | 5 | ## Visão Geral 6 | 7 | A disciplina de Portfólio tem como objetivo consolidar a experiência dos alunos em análise, projeto, desenvolvimento e entrega de produtos reais, alinhados com boas práticas de engenharia de software. A avaliação final será feita por meio de Poster + Demo Day, substituindo o modelo tradicional de banca. 8 | 9 | Os alunos deverão apresentar publicamente: 10 | - Um poster técnico, com destaque para requisitos, arquitetura e decisões críticas do projeto. 11 | - Uma demonstração funcional do sistema em ambiente produtivo ou equivalente. 12 | 13 | ## Estilos de Projeto 14 | 15 | Cada projeto deve se enquadrar em uma das seguintes linhas, com critérios específicos para habilitação à apresentação final (a ser definido em documento específico): 16 | 1. [Web Apps](https://github.com/CatolicaSC-Portfolio/The-Portfolio-Playbook-II/blob/working/Linhas/web.md) 17 | 2. [Aplicações Mobile](https://github.com/CatolicaSC-Portfolio/The-Portfolio-Playbook-II/blob/working/Linhas/mobile.md) 18 | 3. [Jogos Digitais](https://github.com/CatolicaSC-Portfolio/The-Portfolio-Playbook-II/blob/working/Linhas/jogos.md) 19 | 4. [Projetos com IA](https://github.com/CatolicaSC-Portfolio/The-Portfolio-Playbook-II/blob/working/Linhas/ia.md) 20 | 5. [Projetos IoT](https://github.com/CatolicaSC-Portfolio/The-Portfolio-Playbook-II/blob/working/Linhas/iot.md) 21 | 22 | ## Participação no Poster + Demo Day 23 | 24 | Para participar do evento final, o projeto deve: 25 | - Atender aos requisitos mínimos do estilo escolhido. 26 | - Estar funcional e acessível ao público (deploy ou entrega testável). 27 | - Conter documentação clara e organizada. 28 | 29 | ## Destaques e Premiação 30 | 31 | Os projetos que mais se destacarem no Poster + Demo Day — seja pela inovação, qualidade técnica, impacto ou apresentação — receberão um convite especial para participar de uma Noite de Destaques. 32 | Nessa ocasião, os autores terão a oportunidade de apresentar suas soluções para uma banca técnica convidada, formada por professores, profissionais do mercado e especialistas da área. 33 | O evento será um momento único para compartilhar conquistas, trocar experiências e ampliar a visibilidade do trabalho, podendo integrar também a Semana Acadêmica da Católica SC. 34 | 35 | ## Requisitos de Entrega 36 | 37 | - Link para repositório GitHub (público). 38 | - Poster digital em PDF. 39 | - Link de acesso à aplicação/produto. 40 | - Documentação de arquitetura e requisitos. 41 | - Atendimento dos reqisitos defindos para cada uma das linhas 42 | 43 | # Links Importantes 44 | - [Portfolio I](https://github.com/CatolicaSC-Portfolio/The-Portfolio-Playbook-I/tree/main) 45 | - [Avaliação](https://github.com/CatolicaSC-Portfolio/The-Portfolio-Playbook-II/blob/main/AvaliacaoPoster_DemoDay.md) 46 | - [Guia do Poster](https://github.com/CatolicaSC-Portfolio/The-Portfolio-Playbook-II/blob/main/guia_poster.md) 47 | - [Locais para Publicação](https://github.com/CatolicaSC-Portfolio/The-Portfolio-Playbook-II/blob/main/locais_publicacao.md) 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60 | --- 61 | -------------------------------------------------------------------------------- /directions/portfolio-directions-iot.md: -------------------------------------------------------------------------------- 1 | # Linha de Projeto – Projetos IoT (Internet das Coisas) 2 | 3 | ## O que é obrigatório atender 4 | Requisitos mínimos e obrigatórios para habilitação ao Poster + Demo Day. 5 | 6 | - Além dos descritivos exigidos no RFC, é obrigatório apresentar especificações do escopo do projeto contendo: 7 | - Requisitos da aplicação IoT, que podem ser representados por **Diagrama Hierárquico de Requisitos (SySML)** e **Diagrama de Arquitetura** (C4 Model ou modelo em camadas contendo: camada de sensores/atuadores, camada de rede, camada de processamento de dados e camada de aplicação). 8 | - Tais diagramas devem ser descritos e fundamentados. 9 | - Implementação dos requisitos em consonância com a arquitetura aplicada ao domínio do problema abordado. 10 | - Código-fonte no repositório do projeto, assim como os artefatos de especificação. 11 | - Não restringir a implementação embarcada: é necessário incluir a **internet** como meio de comunicação. 12 | - Mesmo que simplificada, é fundamental a **interação via web/mobile** (camada de aplicação) como parte da aplicação IoT, seja: 13 | - Interação direta (ex.: manipular configuração de dispositivo); 14 | - Interação indireta (ex.: consumo de dados oriundos da aplicação IoT). 15 | 16 | --- 17 | 18 | ## O que é desejável atender 19 | Melhora a qualidade do projeto. Fortemente recomendado, mas não elimina se ausente. 20 | 21 | - Especificação esquemática de hardware, portas (lógica/digital), conectividade, componentes e restrições (**Diagramas de Blocos e Blocos Internos, SySML**). 22 | - Escolha de protocolos de comunicação aderentes ao escopo do projeto. 23 | - Por exemplo, ao invés de utilizar o protocolo HTTP como padrão, identificar outro que melhor satisfaça os requisitos da aplicação. 24 | 25 | --- 26 | 27 | ## O que é um diferencial 28 | Características que elevam o nível do projeto e podem gerar destaque e convites. 29 | 30 | - Camada de Aplicação contendo a utilização da aplicação IoT via aplicação Web ou Mobile. 31 | - Utilização de dados oriundos da aplicação IoT em uma camada adicional contendo análise de dados e dashboards ou algum modelo de aprendizagem de máquina (predição/classificação). 32 | - Camada de segurança com a implementação de ao menos uma prática de cibersegurança (conforme demanda do escopo do projeto). 33 | - Integração com sistema externo à aplicação IoT. 34 | 35 | --- 36 | 37 | ## O que deve ser evitado 38 | Más práticas que reduzem a percepção de qualidade, mesmo em projetos funcionais. 39 | 40 | - Plataformas IoT com camadas prontas para utilização. 41 | - Representar/simular comportamentos via utilização de LEDs, quando da falta de componentes. 42 | 43 | --- 44 | 45 | ## O que não pode ter 46 | Erros graves que causam desclassificação ou reprovação direta. 47 | 48 | - Apenas a simulação dos requisitos em detrimento da implementação. 49 | - Aplicações IoT com escopo simplista, por exemplo: acender uma lâmpada, ligar um ar-condicionado, entre outros dessa natureza. 50 | - Utilizar escopo de projetos prontos. 51 | - Apenas a implementação embarcada. 52 | 53 | --- 54 | 55 | ## Régua de Avaliação 56 | Define os níveis de qualidade do projeto, critérios de aprovação e acesso aos eventos de destaque. 57 | 58 | - **Aprovado para apresentação**: Banner, projeto com escopo contendo os requisitos mínimos e obrigatórios 59 | = Itens *“obrigatório atender”* (têm que ter) + *“desejável atender”*. 60 | - **Aprovado com Diferencial**: Banner, convite para Banca Técnica/Seminário e Artigo, projeto que contempla os itens *“obrigatório atender”* + *“desejável atender”* e ao menos **+1** dos itens *“é um diferencial”*, **e** não pode ter *“deve ser evitado”*. 61 | - Caso contrário, o projeto **não será aprovado**. 62 | -------------------------------------------------------------------------------- /directions/portfolio-directions-ia.md: -------------------------------------------------------------------------------- 1 | # Linha de Projeto – Projetos com Inteligência Artificial (IA) 2 | 3 | ## O que é obrigatório atender 4 | Requisitos mínimos e obrigatórios para habilitação ao Poster + Demo Day. 5 | 6 | - Deve aplicar, de maneira fundamentada, uma ou mais abordagens de IA em um problema real no domínio do tema escolhido. As abordagens aceitas incluem, mas não se limitam a: 7 | - **IA clássica híbrida com Rede Neural Artificial**: Sistemas Especialistas ou Otimização (exemplos de técnicas aceitas: GA+ANN, FIS+ANN); 8 | - **Aprendizagem de Máquina (ML/DL)**: Modelos para Classificação, Regressão ou Clustering, Reconhecimento de Padrões em imagens, sons ou sinais, Visão Computacional, Detecção de Anomalias, Processamento de Linguagem Natural, Sistemas de Recomendação (para ML serão aceitos técnicas Ensembles, tais como: Baggin, Boosting, Stacking. Para DL serão aceitos técnicas FNN, MLP, CNN, RNN, GAN, etc.); 9 | - **Modelos Generativos**: NLP Generativa, Transformer, RAG, Fine-tuning de modelos LLMs; 10 | - Deve apresentar propósito prático e funcional (ser parte integrante de uma aplicação); 11 | - Caso a solução da proposta requeira dados, deve fazer uso de base de dados real ou sintética, desde que acompanhada de justificativas devidamente embasadas. Caso não seja necessário de dados, a decisão deve ser justificada; 12 | - Deve contemplar o pipeline funcional de IA, incluindo etapas como extração/geração de dados, pré-processamento (método científico, matemática, estatística), modelo IA, pós-processamento (visualização, testes, validação e implantação do modelo); 13 | - Deve considerar aspectos de responsabilidade ética, incluindo a privacidade de dados (como previsto na LGPD) e o cumprimento de normas ou legislações específicas da área de aplicação, como, por exemplo, na área da saúde; 14 | 15 | --- 16 | 17 | ## O que é desejável atender 18 | Melhora a qualidade do projeto. Fortemente recomendado, mas não elimina se ausente. 19 | 20 | - Possuir interface (web ou app) para interação com a IA; 21 | - Ter modelo de arquitetura para acomodar o pipeline da solução; 22 | - Apresentar métricas de desempenho e análise dos resultados; 23 | - Realizar validação do modelo com técnica adequada (k-fold, holdout, etc.); 24 | - Apresentar justificativa clara para escolha do algoritmo/modelo; 25 | - Possuir infraestrutura de IA em nuvem (AWS, Azure, etc.). 26 | 27 | --- 28 | 29 | ## O que é um diferencial 30 | Características que elevam o nível do projeto e podem gerar destaque e convites. 31 | 32 | - Desenvolvimento de modelo próprio (em vez de apenas usar um pré-treinado); 33 | - Avaliação com usuários reais ou especialistas do domínio; 34 | - Resultados publicados em eventos, hackathons ou desafios externos; 35 | 36 | --- 37 | 38 | ## O que deve ser evitado 39 | Más práticas que reduzem a percepção de qualidade, mesmo em projetos funcionais. 40 | 41 | - Uso de IA sem aplicação real; 42 | - Base de dados genérica não relacionada ao problema; 43 | - Ausência de testes ou evidência de funcionamento; 44 | 45 | --- 46 | 47 | ## O que não pode ter 48 | Erros graves que causam desclassificação ou reprovação direta. 49 | 50 | - Plágio de código ou conteúdo copiado de notebooks da internet sem adaptação ou compreensão; 51 | - Modelo com resultados aleatórios ou não replicáveis; 52 | - Código hardcoded, low-code/no-code ou sem modularização; 53 | - Base de dados inválida, falsa ou não autorizada; 54 | - Utilizar dataset pronto como dados da solução; 55 | - Violação ética: uso indevido de dados sensíveis, práticas discriminatórias, deepfakes não autorizados, etc.; 56 | 57 | --- 58 | 59 | ## Régua de Avaliação 60 | - **Aprovado**: Apresentar uma aplicação funcional de uma abordagem de Inteligência Artificial a um problema real, apresenta pipeline funcional (dados, modelo, pré e pós-processamento), documentação técnica coerente e demonstra resultados replicáveis. A aplicação resolve um problema real com escopo bem definido. 61 | - **Destaque**: Além dos critérios básicos, o projeto demonstra diferencial técnico ou criativo, como desenvolvimento de modelo próprio, uso de arquitetura robusta, ou validação rigorosa (ex.: cross-validation, análise de métricas). Disponibilidade da IA para testes com usuários no dia da apresentação. 62 | - **Reprovado**: não apresenta, quebra ou não cumpre os critérios obrigatórios. 63 | -------------------------------------------------------------------------------- /RFC/diretrizes-avaliacao-professores.md: -------------------------------------------------------------------------------- 1 | # Recomendações para Avaliação das Propostas de Portfólio 2 | 3 | Caro Professor/a, no início do semestre 2024-1, foi definido na reunião de colegiado do curso que a disciplina de Portfólio seria dividida em duas fases: Portfólio I (sétimo período) e Portfólio II (período seguinte). Para tanto, foram organizados um conjunto de diretrizes e um RFC para que cada estudante da 7a. fase possa apresentar seu projeto de portfólio e as especificações do domínio de problema. Ao concluir o RFC, os estudantes buscarão três Professores para avaliar o projeto proposto. 4 | 5 | Antes de iniciar a avaliação verifique o conteúdo nestes links: 6 | 7 | - [Processo de Escolha de Tema e Aprovação para Projeto de Portfólio](https://github.com/CatolicaSC-Portfolio/The-Portfolio-Playbook-I/tree/main) 8 | - [Modelo de RFC para Estruturação do Tema](https://github.com/CatolicaSC-Portfolio/The-Portfolio-Playbook-I/blob/main/modelo-de-RFC.md) 9 | - [Portfólio Directions](https://github.com/CatolicaSC-Portfolio/The-Portfolio-Playbook-I/blob/main/portfolio-directions.md) 10 | 11 | ## Pontos a serem observados na avaliação 12 | 13 | 1. **Apresentação do Projeto** 14 | - Clareza da escrita, justificativa e objetivos (Seções 1 e 2 do RFC). 15 | - Contexto alinhado a um problema real e relevante. 16 | 17 | 2. **Descrição e Requisitos** 18 | - Especificação técnica (Seção 3.1) consistente com o escopo descrito nas Seções 2.1 e 2.2. 19 | - Adequação aos **requisitos obrigatórios da linha de projeto** (Web Apps, Mobile, Jogos Digitais, IA, IoT). 20 | 21 | 3. **Arquitetura** 22 | - Avaliar se a arquitetura (Seção 3.2) é factível e cobre os requisitos definidos. 23 | - Uso adequado de diagramas (UML, C4 Model, etc.). 24 | 25 | 4. **Tecnologias** 26 | - Escolhas tecnológicas (Seção 3.3) compatíveis com o escopo e alinhadas ao **Portfólio Directions**. 27 | 28 | 5. **Segurança e Conformidade** 29 | - Considerações de segurança (Seção 3.4) e aderência a normas e legislações aplicáveis(Seção 3.5)(ex.: **LGPD**, **WCAG**, **HIPAA** se relevante). 30 | 31 | 32 | 33 | ## Registro da Avaliação 34 | 35 | - Cada professor atribuirá **uma nota única** de 0 a 10 (intervalos de 0,5) e assinará no próprio RFC. 36 | - Espaço para comentários e recomendações deverá ser utilizado para ajustes e observações. 37 | - Notas **abaixo de 7** indicam necessidade de ajustes obrigatórios antes da continuação. 38 | 39 | ## Anexo - Escala 40 | 41 | Pontuação de 0 a 10 (com intervalos de 0,5) 42 | Em qualquer nota pode ser indicado ajustes obrigatório ou sugestões. Abaixo de 7 indica necessidade de ajustes obrigatórios antes da continuação do projeto. 43 | 44 | | Nota | Interpretação | Critério principal | 45 | |-------|------------------------------------------|-------------------------------------------------------------------------------------| 46 | | **10** | **Excepcional** | Clareza, profundidade e originalidade acima da média. Inspira confiança e excelência. | 47 | | **9** | **Excelente** | Alta qualidade, bem escrita, clara e coerente. Atende completamente às diretrizes. | 48 | | **8.5** | **Muito Boa** | Pequenos ajustes possíveis. Proposta madura, com justificativa e objetivos claros. | 49 | | **8** | **Boa** | Viável e bem escrita, mas com margem para melhorias pontuais. | 50 | | **7.5** | **Aprovada** | Viável. Atende aos requisitos mínimos com consistência razoável. | 51 | | **7** | **Limite para aprovação** | Atenção! Proposta superficial ou com lacunas críticas. Recomendável revisão. | 52 | | **6 e 6.5** | **Revisar** | RFC com potencial, mas com estrutura ou justificativa insuficiente. | 53 | | ** Abaixo de 6** | **Reapresentar** | Reprovada nesta etapa. Tema desalinhado, incoerente ou inviável. | 54 | 55 | 56 | 57 | ## Critérios Orientadores 58 | 59 | - **Contexto** – Motivação clara e conectada a um problema real. 60 | - **Justificativa** – Fundamentação sólida do “porquê” da proposta. 61 | - **Objetivos** – Claros, mensuráveis e realistas. 62 | - **Tema** – Bem definido e enquadrado em uma linha de projeto. 63 | - **Problemas a Resolver** – Identificação concreta e relevante. 64 | - **Adequação ao Modelo** – Segue o [modelo de RFC](https://github.com/CatolicaSC-Portfolio/The-Portfolio-Playbook-I/blob/main/modelo-de-RFC.md)? 65 | - **Escrita e Estrutura** – Texto coeso, organizado e bem escrito. 66 | 67 | 68 | 69 | 70 | 71 | **Bom Trabalho!** 72 | 73 | -------------------------------------------------------------------------------- /directions/portfolio-directions-webapp.md: -------------------------------------------------------------------------------- 1 | # Linha de Projeto – Web Apps 2 | 3 | ## O que é obrigatório atender 4 | Requisitos mínimos e obrigatórios para habilitação ao Poster + Demo Day. 5 | 6 | - O sistema deve estar hospedado em ambiente acessível publicamente (ex.: AWS, GCP, Azure, Hostinger, servidor institucional). 7 | - Deve conter funcionalidades completas e reais, conforme o escopo definido no RFC. 8 | - Interface funcional, navegável e com usabilidade básica. 9 | - Arquitetura de software definida conforme o RFC (ex.: MVC, arquitetura em camadas, client-server). 10 | - Organização modular do código (componentes reutilizáveis, separação de responsabilidades). 11 | - Código-fonte disponível em repositório com histórico de commits. 12 | - Implementação de pipeline CI/CD (ex.: GitHub Actions, GitLab CI). 13 | - Documentação mínima contendo: 14 | - requisitos funcionais; 15 | - casos de uso ou user stories; 16 | - diagrama de arquitetura - utilizando diagramas C4 ou equivalente; 17 | - instruções de deploy. 18 | - Cobertura de testes unitários com TDD: 19 | - 75% no backend; 20 | - 25% no frontend. 21 | - Aplicação de ferramenta de análise estática de código e segurança (ex.: SonarQube, SonarCloud, CodeClimate). 22 | - Uso de ferramenta de monitoramento ou observabilidade (ex.: NewRelic, Datadog, Zabbix, Prometheus, Grafana). 23 | - O sistema deve contemplar **ao menos três fluxos de negócio completos**. 24 | 25 | --- 26 | 27 | ## O que é desejável atender 28 | Fortemente recomendado para elevar a qualidade do projeto, mas não obrigatório. 29 | 30 | - Uso de frameworks modernos (React, Vue, Angular, etc.) com boas práticas de desenvolvimento. 31 | - Integração com APIs externas (REST, GraphQL). 32 | - Uso de banco de dados com persistência real (SQL/NoSQL). 33 | - Responsividade (design adaptável a diferentes tamanhos de tela). 34 | - Aplicação de testes de integração. 35 | - Adoção de práticas de segurança (ex.: HTTPS, validação de entradas). 36 | - Estratégias de cache (ex.: Nginx, Redis, Memcached). 37 | - Uso de containerização (ex.: Docker, Podman). 38 | 39 | --- 40 | 41 | ## O que é um diferencial 42 | Aspectos que elevam o nível do projeto e podem gerar destaque e convites. 43 | 44 | - Autenticação robusta (OAuth2, login social com Google ou Facebook, autenticação multifator). 45 | - Dashboards com visualizações de dados (gráficos, relatórios dinâmicos). 46 | - Implementação de camada de segurança (ex.: JWT, proteção contra XSS/CSRF). 47 | - Suporte multilíngue. 48 | - Design System ou biblioteca de componentes personalizados. 49 | - Testes de usabilidade com usuários reais e feedback documentado. 50 | - Uso de domínio próprio (ex.: www.nomeprojeto.com). 51 | - Processamento assíncrono com mensageria (ex.: Kafka, RabbitMQ). 52 | - Infraestrutura como código (IaC) — ex.: Terraform. 53 | 54 | --- 55 | 56 | ## O que deve ser evitado 57 | Más práticas que reduzem a qualidade e a legibilidade do projeto. 58 | 59 | - Estilo visual inconsistente ou não responsivo. 60 | - Interface genérica ou desorganizada. 61 | - Ausência de feedback ao usuário (ex.: carregamento, erros, confirmações). 62 | - Uso de bibliotecas, templates ou temas prontos sem personalização. 63 | - Falta de modularidade (ex.: todo o código concentrado em um único arquivo). 64 | - Vibecoding (código improvisado, sem planejamento). 65 | - Uso de ferramentas de documentação como Notion ou Obsidian (não aceitas para entrega oficial). 66 | - Hospedagem exclusivamente em plataformas otimizadas apenas para frontend (ex.: Vercel, Netlify, Firebase, Render), **sem backend desenvolvido pelo grupo**. 67 | - Plataformas que automatizam totalmente backend, banco de dados e APIs sem gestão da arquitetura (no-code disfarçado de desenvolvimento). 68 | - Serviços de cloud que ocultam infraestrutura e automação de deploy (com integração direta via GitHub e SSL automático) **sem domínio técnico sobre o ambiente.** 69 | 70 | --- 71 | 72 | ## O que não pode ter 73 | Erros graves que causam desclassificação ou reprovação direta. 74 | 75 | - Projeto não acessível (link quebrado, servidor fora do ar). 76 | - Código copiado ou plagiado (repositórios, tutoriais, templates). 77 | - Interface inoperante (botões, menus ou links não funcionam). 78 | - Violação de segurança básica (dados sensíveis expostos, permissões abertas, etc.). 79 | - Ausência de documentação mínima. 80 | - Deploy manual via SSH ou FTP. 81 | - Uso de processo em cascata (sem práticas iterativas ou integração contínua). 82 | - Plataformas no-code (ex.: Bubble.io, Webflow, Carrd, Thunkable, Bravo Studio, HubSpot CMS). 83 | - Banco de dados em disco local (ex.: H2, SQLite). 84 | 85 | --- 86 | 87 | ## Temas a evitar 88 | - Soluções que utilizam IA apenas via prompt, sem integração efetiva ou arquitetura própria. 89 | - Sistemas genéricos de gestão de listas (livros, filmes, músicas, etc.), similares a Goodreads. 90 | 91 | --- 92 | 93 | ## Temas impedidos 94 | - Sistema de cardápio online / QR Code. 95 | - Sistema de controle de estoque. 96 | - Sistema de tele-entrega. 97 | - Sistema de gestão financeira (com ou sem IA). 98 | -------------------------------------------------------------------------------- /directions/portfolio-directions-mobile.md: -------------------------------------------------------------------------------- 1 | # Linha de Projeto – Aplicações Mobile 2 | 3 | ## O que é obrigatório atender 4 | Requisitos mínimos e obrigatórios para habilitação ao Poster + Demo Day. 5 | 6 | - O aplicativo deve estar disponível em ambiente produtivo, acessível para instalação e testes (ex.: APK instalável, publicado no Google Play, TestFlight ou hospedado em plataforma de testes como Firebase App Distribution). 7 | - Deve conter **funcionalidades reais e completas**, alinhadas ao escopo apresentado no RFC. 8 | - Deve adotar uma **arquitetura mobile compatível** (ex.: MVC, MVVM, Clean Architecture). 9 | - Código-fonte disponível em **repositório versionado**, com histórico de commits e boa organização de branches. 10 | - Interface **funcional e navegável**, testável em dispositivo real, com **QR Code no pôster** para acesso rápido à instalação. 11 | - Documentação mínima contendo: 12 | - requisitos funcionais; 13 | - casos de uso ou user stories; 14 | - estrutura de navegação da aplicação; 15 | - diagrama de arquitetura; 16 | - instruções de deploy ou instalação. 17 | - Deve contemplar **ao menos três fluxos de uso completos**, que demonstrem o valor e a coerência do produto. 18 | - Cobertura de testes unitários com TDD: 19 | - 75% no backend; 20 | - 25% no frontend. 21 | - Aplicação de **ferramentas de análise estática e qualidade de código** (ex.: SonarQube, SonarCloud, CodeClimate). 22 | - Uso de **monitoramento e analytics** para acompanhamento de métricas (ex.: Firebase Analytics, App Center, Datadog). 23 | 24 | --- 25 | 26 | ## O que é desejável atender 27 | Fortemente recomendado para elevar a qualidade e robustez técnica do projeto, mas não obrigatório. 28 | 29 | - Publicação em loja oficial (Google Play / App Store). 30 | - Integração com serviços externos (ex.: APIs REST, Firebase, mapas, notificações push). 31 | - Pipeline de **integração e entrega contínua (CI/CD)** (ex.: GitHub Actions, Codemagic, Bitrise). 32 | - Aplicação de testes automatizados (unitários ou instrumentados). 33 | - **Responsividade e adaptação** a diferentes tamanhos de tela e dispositivos. 34 | - Implementação de **boas práticas de UX/UI** (ex.: Material Design, coerência visual, acessibilidade). 35 | - Persistência de dados local ou remota (ex.: SQLite, Firebase, Supabase, RealmDB). 36 | - Aplicação de testes de integração. 37 | 38 | 39 | --- 40 | 41 | ## O que é um diferencial 42 | Aspectos que demonstram maturidade técnica, refinamento de produto e potencial de destaque. 43 | 44 | - Autenticação robusta (login social, OAuth2, biometria, autenticação multifator). 45 | - Sistema de métricas de uso e comportamento de usuários integrado (analytics, telemetria). 46 | - Interface multilíngue e suporte a internacionalização. 47 | - Arquitetura modular ou baseada em micro frontends (apps complexos e escaláveis). 48 | - Testes com usuários reais, prototipagem validada e feedback documentado. 49 | - Design System próprio ou biblioteca de componentes reutilizáveis. 50 | - Uso de **Infraestrutura como Código (IaC)** ou automação de deploy mobile (ex.: Fastlane, Terraform). 51 | - Integração com mensageria e notificações assíncronas (ex.: Firebase Cloud Messaging, RabbitMQ, Kafka). 52 | 53 | --- 54 | 55 | ## O que deve ser evitado 56 | Más práticas que reduzem a qualidade técnica, a experiência do usuário e a credibilidade do projeto. 57 | 58 | - Aplicativos com apenas **telas estáticas** (mockups ou navegação simulada). 59 | - Falta de testes básicos que causem falhas críticas (crashes, travamentos). 60 | - Interface desorganizada, inconsistente ou mal adaptada a diferentes resoluções. 61 | - Funcionalidades genéricas sem propósito claro (ex.: lista de tarefas sem contexto de aplicação). 62 | - Ausência de feedback ao usuário em ações importantes (carregamentos, erros, confirmações). 63 | - Dependência excessiva de templates prontos, sem personalização ou autoria. 64 | 65 | --- 66 | 67 | ## O que não pode ter 68 | Erros graves que causam desclassificação ou reprovação direta. 69 | 70 | - Plágio de aplicativos existentes sem modificações significativas. 71 | - Reutilização de templates prontos sem personalização ou compreensão técnica. 72 | - Código não modularizado (ex.: toda a lógica concentrada em um único arquivo). 73 | - Aplicações que não executam ou não apresentam funcionalidades ativas. 74 | - Violação de diretrizes da plataforma (ex.: uso indevido de permissões, coleta de dados sem consentimento, falta de política de privacidade). 75 | - Deploy ou distribuição sem controle de versão e rastreabilidade. 76 | - Aplicações que dependem exclusivamente de **plataformas no-code ou low-code**. 77 | 78 | --- 79 | 80 | ## Temas a evitar 81 | - Aplicativos que apenas replicam funcionalidades genéricas (ex.: lista de tarefas, agenda, controle de hábitos). 82 | - Aplicativos que usam **IA via prompt** sem integração real ou arquitetura própria. 83 | - Aplicativos de catálogo simples (ex.: listagem de produtos, serviços ou pessoas sem interação ou lógica de negócio). 84 | - Aplicativos que simulam redes sociais sem proposta inovadora. 85 | - Aplicativos de “portfólio pessoal” ou “currículo digital” sem recursos interativos ou contexto técnico. 86 | 87 | --- 88 | 89 | ## Temas impedidos 90 | - Aplicativos de cardápio online / QR Code. 91 | - Aplicativos de controle de estoque. 92 | - Aplicativos de delivery / tele-entrega. 93 | - Aplicativos financeiros genéricos (com ou sem IA). 94 | - Aplicativos de lista de compras ou tarefas sem diferencial técnico. 95 | -------------------------------------------------------------------------------- /RFC/modelo-de-RFC.md: -------------------------------------------------------------------------------- 1 | # Capa 2 | 3 | - **Título do Projeto**: [Título claro e conciso que reflete a essência do produto ou ferramenta]. 4 | - **Nome do Estudante**: [Nome completo do estudante]. 5 | - **Curso**: Engenharia de Software. 6 | - **Data de Entrega**: [Data]. 7 | 8 | # Resumo 9 | 10 | Breve descrição do conteúdo do documento, incluindo o propósito do projeto e os principais pontos de discussão. 11 | 12 | ## 1. Introdução 13 | 14 | - **Contexto**: Breve descrição do contexto que envolve o projeto. 15 | - **Justificativa**: Explicação da relevância do projeto para o campo da engenharia de software. 16 | - **Objetivos**: Descrição do objetivo principal do projeto e de quaisquer objetivos secundários. 17 | 18 | ## 2. Descrição do Projeto 19 | 20 | * **Linha de Projeto**: Indique a categoria do projeto (Web Apps, Aplicações Mobile, Jogos Digitais, Projetos com IA ou Projetos IoT), conforme definido no regulamento. 21 | * **Tema do Projeto**: Descreva de forma clara e objetiva o produto, serviço ou ferramenta a ser desenvolvido. 22 | * **Propósito e Uso Prático**: Explique qual problema real será resolvido e como a solução será utilizada na prática. 23 | * **Público-Alvo**: Defina o perfil dos usuários ou clientes potenciais que se beneficiarão da solução. 24 | * **Problemas a Resolver**: Liste de forma objetiva os principais problemas ou necessidades que o projeto pretende atender. 25 | * **Diferenciação/Ineditismo**: Destaque o que torna a proposta única em relação a soluções existentes, mesmo quando o tema é semelhante a outros projetos. 26 | * **Limitações**: Especifique o que o projeto **não** abrangerá, evitando expectativas incorretas. 27 | * **Normas e Legislações Aplicáveis**: Liste normas, leis e diretrizes relevantes ao contexto do projeto (ex.: LGPD, HIPAA, WCAG, ESRB/PEGI), indicando como serão observadas. 28 | * **Métricas de Sucesso**: Apresente critérios iniciais para medir o desempenho e a efetividade do projeto (ex.: tempo de resposta, número de usuários atendidos, taxa de acerto do modelo de IA). 29 | 30 | ## 3. Especificação Técnica 31 | 32 | Descrição detalhada da proposta, contemplando requisitos, arquitetura, tecnologias, segurança e aderência aos critérios obrigatórios da linha de projeto escolhida. 33 | 34 | ### 3.1. Requisitos de Software 35 | - **Requisitos Funcionais (RF)**: Liste de forma clara as funcionalidades que o sistema deverá oferecer. 36 | - **Requisitos Não-Funcionais (RNF)**: Inclua requisitos de desempenho, segurança, usabilidade, escalabilidade, disponibilidade, entre outros. 37 | - **Representação dos Requisitos**: Inclua um Diagrama de Casos de Uso (UML) ou outra representação visual que facilite o entendimento. 38 | - **Aderência aos Requisitos da Linha de Projeto**: Indique como cada requisito está alinhado aos itens “Obrigatório Atender” definidos para a linha de projeto (Web, Mobile, Jogos, IA ou IoT). 39 | 40 | ### 3.2. Considerações de Design 41 | - **Visão Inicial da Arquitetura**: Apresente os principais componentes e suas interações. 42 | - **Padrões de Arquitetura**: Informe padrões adotados (ex.: [MVC](https://en.wikipedia.org/wiki/Model–view–controller), [Microserviços](https://microservices.io/), [MVVM](https://en.wikipedia.org/wiki/Model–view–viewmodel), Arquitetura em Camadas). 43 | - **Modelos C4**: Utilize os quatro níveis ([C4 Model](https://c4model.com/)) quando aplicável. 44 | - **Mockups das Telas Principais**: Apresente protótipos visuais das telas mais relevantes, mostrando navegação, disposição de elementos e principais interações do usuário. Esses mockups podem ser feitos em ferramentas como Figma, Adobe XD ou similares, e devem refletir a identidade visual e usabilidade prevista para o produto. 45 | - **Decisões e Alternativas Consideradas**: Justifique escolhas de design, documentando alternativas avaliadas. 46 | - **Critérios de Escalabilidade, Resiliência e Segurança**: Descreva como a solução será projetada para suportar crescimento, lidar com falhas e manter segurança. 47 | 48 | ### 3.3. Stack Tecnológica 49 | - **Linguagens de Programação**: Liste e justifique as escolhas. 50 | - **Frameworks e Bibliotecas**: Detalhe e justifique a seleção. 51 | - **Ferramentas de Desenvolvimento e Gestão**: Inclua IDEs, sistemas de versionamento, plataformas de integração contínua, monitoramento, entre outros. 52 | - **Licenciamento**: Indique as licenças dos softwares e bibliotecas utilizados ([MIT](https://opensource.org/licenses/MIT), [GPL](https://www.gnu.org/licenses/gpl-3.0.html), [Apache](https://www.apache.org/licenses/), [Creative Commons](https://creativecommons.org/licenses/)). 53 | 54 | ### 3.4. Considerações de Segurança 55 | - **Riscos Identificados**: Liste ameaças potenciais (ex.: injeção de código, vazamento de dados, falhas de autenticação). 56 | - **Medidas de Mitigação**: Explique as ações planejadas para minimizar riscos (ex.: criptografia, controle de acesso, validação de entrada). 57 | - **Normas e Boas Práticas Seguidas**: Cite padrões como [OWASP Top 10](https://owasp.org/www-project-top-ten/), [ISO/IEC 27001](https://www.iso.org/isoiec-27001-information-security.html), [LGPD](https://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/L13709.htm) ou outros aplicáveis. 58 | - **Responsabilidade Ética**: Para projetos de IA ou manipulação de dados sensíveis, descreva como serão tratados vieses, privacidade e uso responsável ([UNESCO – Ética em IA](https://unesdoc.unesco.org/ark:/48223/pf0000380455), [OECD AI Principles](https://oecd.ai/en/ai-principles)). 59 | 60 | ### 3.5. Conformidade e Normas Aplicáveis 61 | - Relacione todas as legislações, regulamentações e normas técnicas aplicáveis ao projeto, descrevendo brevemente como serão atendidas. 62 | - Exemplos: 63 | - [LGPD – Lei Geral de Proteção de Dados](https://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/L13709.htm) 64 | - Coletar apenas dados necessários (nome, contato, dados do imóvel). 65 | - Evitar dados sensíveis desnecessários. 66 | - Solicitar consentimento explícito e exibir política de privacidade clara. 67 | - Permitir acesso, correção e exclusão de dados pelo usuário. 68 | - ... 69 | 70 | ## 4. Próximos Passos 71 | 72 | - Descrição dos passos seguintes após a conclusão do documento, com uma visão geral do cronograma para Portfólio I e II. 73 | - Definição de Marcos: Estabelecer datas para entregas intermediárias e checkpoints. 74 | 75 | 76 | ## 5. Referências 77 | 78 | Listagem de todas as fontes de pesquisa, frameworks, bibliotecas e ferramentas que serão utilizadas. 79 | 80 | ## 6. Apêndices (Opcionais) 81 | 82 | Informações complementares, dados de suporte ou discussões detalhadas fora do corpo principal. 83 | ## 7. Avaliações de Professores 84 | 85 | Adicionar três páginas no final do RFC para que os Professores escolhidos possam fazer suas considerações e assinatura: 86 | - Considerações Professor/a: 87 | - Considerações Professor/a: 88 | - Considerações Professor/a: 89 | -------------------------------------------------------------------------------- /RFC/normas.md: -------------------------------------------------------------------------------- 1 | # Normas e Regulamentações Aplicáveis aos Projetos de Portfólio 2 | ## 1. Introdução 3 | No desenvolvimento de produtos viáveis e alinhados às expectativas do mercado, não basta entregar uma solução tecnicamente funcional — é essencial que o projeto esteja em conformidade com leis, normas e boas práticas aplicáveis ao seu contexto. Ignorar esses aspectos pode comprometer a viabilidade do produto, gerar riscos legais, dificultar a publicação em lojas e, em casos mais graves, inviabilizar seu uso real por clientes ou empresas. 4 | 5 | Para a disciplina de Portfólio, observar essas normas faz parte do esforço de desenvolvimento profissional: garante que o trabalho não apenas demonstre domínio técnico, mas também maturidade na entrega, considerando segurança, privacidade, acessibilidade, ética e regulamentações específicas de cada domínio. 6 | 7 | A relação a seguir apresenta normas essenciais (Core) e complementares que servem como referência para os alunos. Elas devem ser consultadas e aplicadas conforme a natureza e a área de atuação do projeto, seja ele um aplicativo, jogo, sistema web, solução de inteligência artificial ou produto IoT. 8 | 9 | ## 2. Normas e Regulamentações 10 | 11 | | Categoria | Norma / Lei | Aplicação Prática no Portfólio | Link de Referência | 12 | | ------------------ | ----------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | 13 | | **Core** | **Proteção de dados e confidencialidade – LGPD** (Lei nº 13.709/2018) | Garante o tratamento adequado de dados pessoais e sensíveis, incluindo consentimento, minimização de dados e segurança da informação. Aplica-se a qualquer projeto que manipule dados de usuários. | [LGPD – Lei 13.709/2018](https://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/L13709.htm) | 14 | | **Core** | **Uso de software de terceiros** (Licenças MIT, GPL, Apache, Creative Commons etc.) | Respeitar licenças de uso, atribuir créditos e cumprir restrições de modificação/distribuição. Importante para projetos que reutilizem bibliotecas, APIs ou assets. | [Licença MIT](https://opensource.org/licenses/MIT) \| [GPL](https://www.gnu.org/licenses/gpl-3.0.html) \| [Apache](https://www.apache.org/licenses/) \| [Creative Commons](https://creativecommons.org/licenses/) | 15 | | **Core** | **Saúde – HIPAA** (Health Insurance Portability and Accountability Act) | Normas de segurança, privacidade e portabilidade para dados de saúde. Relevante para projetos com usuários, clínicas ou hospitais dos EUA. | [HIPAA Overview](https://www.hhs.gov/hipaa/index.html) | 16 | | **Core** | **Jogos – ESRB / PEGI** (Classificação indicativa) | Determina a classificação etária e conteúdo permitido em jogos digitais. Relevante para definir público-alvo e evitar conteúdo inapropriado. | [ESRB](https://www.esrb.org/) \| [PEGI](https://pegi.info/) | 17 | | **Complementares** | **OECD AI Principles** | Diretrizes internacionais para uso responsável, transparente e seguro de IA. Aplicável em projetos de IA e sistemas de recomendação. | [OECD AI Principles](https://oecd.ai/en/ai-principles) | 18 | | **Complementares** | **Proteção contra discriminação e uso ético de IA** (LGPD + Princípios UNESCO) | Evitar vieses algorítmicos, práticas discriminatórias e decisões automatizadas injustas. | [LGPD – Art. 6º, IX](https://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/L13709.htm) \| [UNESCO – Ética em IA](https://unesdoc.unesco.org/ark:/48223/pf0000380455) | 19 | | **Complementares** | **Boas práticas de desenvolvimento seguro** (OWASP, ISO/IEC 27001, 27002) | Proteção contra falhas de segurança como injeção de código, vazamento de dados e autenticação fraca. | [OWASP Top 10](https://owasp.org/www-project-top-ten/) \| [ISO/IEC 27001](https://www.iso.org/isoiec-27001-information-security.html) | 20 | | **Complementares** | **Prontuário eletrônico e registros médicos** (Lei nº 13.787/2018) | Regras para digitalização, guarda e confidencialidade de registros médicos no Brasil. Aplica-se a projetos de saúde nacionais. | [Lei 13.787/2018](https://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/L13787.htm) | 21 | 22 | ## 3. Como aplicar no desenvolvimento do Portfólio 23 | 1. Identificar normas aplicáveis desde a fase de ideação e RFC, conforme o tipo de projeto e seu público-alvo. 24 | 2. Documentar medidas de conformidade no repositório e no pôster, explicando como requisitos legais foram atendidos. 25 | 3. Garantir segurança e privacidade por meio de arquitetura adequada, criptografia, controle de acesso e anonimização de dados sensíveis. 26 | 4. Respeitar licenças e direitos autorais de qualquer recurso externo utilizado. 27 | 5. Incorporar boas práticas e acessibilidade como parte do esforço de qualidade, não como complemento opcional. 28 | 29 | ## 4. Benefícios de seguir essas diretrizes 30 | - Aumenta a credibilidade do projeto perante banca e mercado. 31 | - Facilita publicação e uso real da solução. 32 | - Reduz riscos legais e de segurança. 33 | - Demonstra profissionalismo e maturidade técnica. 34 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # 📘 Portfólio – Católica SC 2 | 3 | O **Portfólio** é o eixo integrador dos projetos autorais desenvolvidos pelos estudantes da Católica SC. 4 | Seu objetivo é conduzir o aluno desde a **concepção da ideia original** até a **entrega de um produto funcional**, ético e alinhado às boas práticas da engenharia de software. 5 | Essa trajetória consolida as competências técnicas e profissionais adquiridas ao longo do curso. 6 | 7 | A jornada se estende por **três disciplinas** distribuídas nos dois últimos semestres: 8 | 9 | - **7º semestre:** PAC 7 — Construção do Documento do Projeto (RFC) 10 | - **8º semestre:** PAC 8 e Disciplina Portfólio — Desenvolvimento, Documentação e Apresentação Pública 11 | 12 | --- 13 | 14 | ## 🎯 7º Semestre — PAC 7 (Construção do Documento do Projeto - RFC) 15 | 16 | A disciplina **PAC 7** tem como foco a **definição e aprovação do tema do projeto de portfólio**, formalizada por meio de um documento **RFC (Request for Comments)**. 17 | Essa etapa marca o início da trajetória de desenvolvimento e estabelece as bases conceituais e técnicas do trabalho que será desenvolvido nos semestres seguintes. 18 | 19 | ### 📍 Etapas Principais 20 | 21 | #### 1. Escolha do Tema 22 | - O estudante deve selecionar um tema de projeto que reflita seus interesses e competências, alinhado às áreas do curso. 23 | - O tema deve seguir as diretrizes do [Portfólio Directions](https://github.com/CatolicaSC-Portfolio/The-Portfolio-Playbook-I/blob/main/directions/portfolio-directions-GERAL.md), que define trilhas, tecnologias e boas práticas. 24 | - O projeto é **individual**, permitindo a expressão das habilidades e identidade profissional de cada estudante. 25 | 26 | #### 2. Linhas de Projeto Disponíveis 27 | 28 | O estudante deverá escolher uma das **cinco linhas oficiais de projeto**, que determinam os critérios técnicos, ferramentas e expectativas de entrega: 29 | 30 | 1. [**Web Apps**](https://github.com/CatolicaSC-Portfolio/The-Portfolio-Playbook-I/blob/main/directions/portfolio-directions-webapp.md) 31 | Aplicações web completas, com interface navegável, arquitetura definida e deploy público. 32 | 33 | 2. [**Aplicações Mobile**](https://github.com/CatolicaSC-Portfolio/The-Portfolio-Playbook-I/blob/main/directions/portfolio-directions-mobile.md) 34 | Aplicativos nativos ou híbridos, com usabilidade e entrega funcional em dispositivo real. 35 | 36 | 3. [**Jogos Digitais**](https://github.com/CatolicaSC-Portfolio/The-Portfolio-Playbook-I/blob/main/directions/portfolio-directions-jogosdigitais.md) 37 | Jogos autorais com gameplay funcional, loop básico, documentação de design e build jogável. 38 | 39 | 4. [**Projetos com IA**](https://github.com/CatolicaSC-Portfolio/The-Portfolio-Playbook-I/blob/main/directions/portfolio-directions-ia.md) 40 | Soluções que apliquem de forma fundamentada técnicas de Inteligência Artificial em problemas reais. 41 | 42 | 5. [**Projetos IoT** ](https://github.com/CatolicaSC-Portfolio/The-Portfolio-Playbook-I/blob/main/directions/portfolio-directions-iot.md) 43 | Soluções envolvendo dispositivos conectados, sensores, atuadores e comunicação em rede. 44 | 45 | > A escolha da linha deve ser registrada na RFC e orientará a estrutura técnica, os requisitos e os critérios de avaliação do projeto. 46 | 47 | #### 3. Elaboração do Documento RFC 48 | - O RFC é o documento que estrutura a proposta inicial do projeto. 49 | - Ele apresenta o problema, a solução proposta, o público-alvo, o escopo e os principais requisitos funcionais e técnicos. 50 | - O modelo oficial pode ser acessado [aqui](https://github.com/CatolicaSC-Portfolio/The-Portfolio-Playbook-I/blob/main/RFC/modelo-de-RFC.md). 51 | 52 | #### 4. Avaliação e Aprovação 53 | - Cada aluno deve buscar **três professores avaliadores**, apresentar a RFC impressa e coletar notas e feedbacks. 54 | - As observações e notas devem constar na versão final do documento entregue ao professor da disciplina. 55 | - Após a aprovação, o aluno está apto a iniciar o desenvolvimento do projeto. 56 | 57 | #### 5. Início da Construção 58 | Com a RFC aprovada, o estudante inicia a execução do projeto, aplicando o feedback recebido e ajustando o escopo conforme as orientações dos professores. 59 | 60 | --- 61 | 62 | ### 🎓 Objetivo da Etapa 63 | Garantir que cada estudante inicie seu projeto com uma base sólida, viável e bem estruturada, conectando teoria, prática e propósito. 64 | 65 | ### 🧭 Documentos de Apoio 66 | - [Modelo de RFC](https://github.com/CatolicaSC-Portfolio/The-Portfolio-Playbook-I/blob/main/RFC/modelo-de-RFC.md) 67 | - [Recomendação para Avaliação dos Professores](https://github.com/CatolicaSC-Portfolio/The-Portfolio-Playbook-I/blob/main/RFC/diretrizes-avaliacao-professores.md) 68 | - [Normas e Regulamentações](https://github.com/CatolicaSC-Portfolio/The-Portfolio-Playbook-I/blob/main/RFC/normas.md) 69 | - [Pré-análise de RFC com GPT de Apoio](https://chat.openai.com/g/g-6863c3a91e1881919572856ff853bf1f-pre-analise-de-projetos-rfc-da-catolica) 70 | 71 | --- 72 | 73 | ## 🚀 8º Semestre — PAC 8 e Disciplina de Portfólio 74 | 75 | No último semestre, o estudante avança da etapa de planejamento para a **consolidação e entrega final** do seu projeto. 76 | O foco é a **execução, documentação e apresentação pública** no evento **Poster + Demo Day**, que substitui o modelo tradicional de banca. 77 | 78 | ### 🎯 Objetivos 79 | - Consolidar o projeto desenvolvido, garantindo qualidade técnica, inovação e responsabilidade profissional. 80 | - Apresentar publicamente um produto funcional em ambiente produtivo. 81 | 82 | ### 📦 Requisitos de Entrega 83 | Para habilitar-se à apresentação final, o projeto deve conter: 84 | - Repositório público no GitHub (com histórico de commits). 85 | - Poster digital (PDF) com QR Code de acesso à aplicação. 86 | - Link funcional da aplicação, jogo, app, IA ou solução IoT. 87 | - Documentação de arquitetura, requisitos e decisões técnicas. 88 | - Cumprimento dos critérios obrigatórios da linha de projeto escolhida. 89 | - Há outros requisitros em [Directions](https://github.com/CatolicaSC-Portfolio/The-Portfolio-Playbook-I/blob/main/directions/portfolio-directions-GERAL.md). 90 | 91 | --- 92 | 93 | ## 🧩 Poster + Demo Day 94 | 95 | ### 📢 Apresentação 96 | O evento é o ápice do Portfólio, reunindo estudantes, professores e comunidade acadêmica. 97 | Os alunos apresentam: 98 | 99 | - Um **pôster técnico** (formato A0, orientação vertical, fonte mínima 20 pt, cores de alto contraste) contendo: 100 | - Título, autores e e-mails. 101 | - Contexto, problema e solução proposta. 102 | - Arquitetura e decisões técnicas. 103 | - QR Code para acesso à aplicação. 104 | 105 | - Uma **demonstração funcional** do sistema em ambiente produtivo. 106 | 107 | ### 🧮 Avaliação 108 | - Cada projeto será avaliado por 109 | - **Três professores**, com formulário Likert e comentários qualitativos. 110 | - Uma **quarta nota** será o resultado da média de todas as notas recebidas da comunidade durante o Demoday 111 | - A **nota final (0–10)** é a média das 4 notas recebidas. 112 | comunidade acadêmica poderá atribuir **menções especiais** (como “Trabalho Escolhido pela Comunidade”). 113 | 114 | --- 115 | 116 | ## 🏆 Trabalhos em Destaque 117 | Os projetos que mais se destacarem em **inovação**, **qualidade técnica** e **impacto** serão convidados para uma **Banca Técnica Especial**. Esses trabalhos receberão **menção de destaque**. 118 | 119 | --- 120 | 121 | 122 | ## 🔗 Referências e Guias 123 | 124 | - [Guia de Avaliação do Demo Day](https://github.com/CatolicaSC-Portfolio/The-Portfolio-Playbook-I/blob/main/demoday/Avaliacao_Poster_DemoDay.md). 125 | - [Guia para Poster](https://github.com/CatolicaSC-Portfolio/The-Portfolio-Playbook-I/blob/main/demoday/guia_poster.md). 126 | - [Locais para publicação](https://github.com/CatolicaSC-Portfolio/The-Portfolio-Playbook-I/blob/main/demoday/locais_publicacao.md). 127 | --- 128 | 129 | **Versão revisada e integrada (PAC 7 + PAC 8 + Portfólio)** 130 | Católica SC — Núcleo de Engenharia de Software 131 | Atualização: Novembro / 2025 132 | -------------------------------------------------------------------------------- /demoday/Avaliacao_Poster_DemoDay.md: -------------------------------------------------------------------------------- 1 | # Avaliação – Poster + Demo Day 2 | 3 | A avaliação final será realizada durante o Poster + Demo Day, considerando as notas atribuídas pelos professores e pela comunidade acadêmica. 4 | 5 | A avaliação busca reconhecer o aprendizado, a aplicação prática de competências e a capacidade de apresentar soluções de forma crítica e integrada. 6 | Mais do que mensurar desempenho, o processo visa promover reflexão, autonomia técnica e evolução contínua dos estudantes. 7 | 8 | ## 🔑 Formato de Avaliação 9 | - Cada trabalho será avaliado por: 10 | - Três professores, com formulário Likert e comentários qualitativos. 11 | - Uma quarta nota será o resultado da média de todas as notas recebidas da comunidade durante o Demoday 12 | - A média das notas atribuídas resultará em uma **única nota final** (0 a 10). 13 | - A avaliação será registrada em **formulário ou aplicativo**, utilizando **escala Likert** para cada critério e espaço para comentários qualitativos. 14 | - Professores receberão antecipadamente: 15 | - Lista de trabalhos. 16 | - Links para repositórios e documentações. 17 | 18 | --- 19 | 20 | ## 🎯 Escala Likert (descritores de referência) 21 | 22 | | Nível | Descrição | Significado prático | 23 | |:------|:-----------|:--------------------| 24 | | **1** | Insuficiente | Não atende aos critérios mínimos; demonstra falhas conceituais ou técnicas. | 25 | | **2** | Básico | Atende parcialmente; há lacunas significativas na execução ou fundamentação. | 26 | | **3** | Adequado | Cumpre o esperado de forma satisfatória, com coerência e funcionalidade. | 27 | | **4** | Avançado | Supera expectativas em alguns aspectos, evidenciando domínio técnico e clareza conceitual. | 28 | | **5** | Excelência | Demonstra maturidade técnica e conceitual, originalidade e integração plena entre teoria e prática. | 29 | 30 | --- 31 | 32 | ## ✅ Critérios de Avaliação 33 | 34 | ### 1. Relevância e Complexidade 35 | 36 | Relevância, escopo claro e originalidade: projeto resolve problema real, tem funcionalidades bem definidas e evita copiar tutoriais, garantindo propósito próprio e aplicação prática. 37 | 38 | *Detalhamento:* 39 | 40 | * **Problema real** – o projeto aborda uma necessidade concreta e significativa. 41 | *Exemplos:* gestão de filas hospitalares, automação de processos contábeis, monitoramento ambiental. 42 | *Implicação:* temas genéricos ou sem aplicação prática reduzem a nota. 43 | 44 | * **Escopo e funcionalidades** – bem definidos, com metas alcançáveis e coerentes. 45 | *Exemplo:* sistema de reservas com login, listagem e cancelamento, evitando excesso de funcionalidades não implementadas. 46 | 47 | * **Originalidade e propósito** – evita replicar tutoriais ou modelos prontos. 48 | *Exemplo:* projeto inspirado em app conhecido, mas com proposta diferente ou contexto local. 49 | *Implicação:* cópias diretas sem personalização podem levar à desclassificação. 50 | 51 | --- 52 | 53 | ### 2. Documentação 54 | 55 | Documentação completa, organizada e rastreável: inclui motivação, requisitos, arquitetura, instruções, registro claro de decisões técnicas e materiais coerentes, legíveis e fáceis de entender. 56 | 57 | *Detalhamento:* 58 | 59 | * **Repositório completo** – inclui motivação, requisitos, modelagem, arquitetura e instruções de uso. 60 | *Exemplo:* README com diagrama de arquitetura, instruções de execução e histórico de decisões. 61 | 62 | * **Registro de decisões** – documentação de escolhas técnicas e mudanças. 63 | *Exemplo:* uso de RFCs, ADRs ou issues no GitHub. 64 | *Implicação:* ausência de registro indica falta de método de engenharia. 65 | 66 | * **Clareza e organização** – textos, diagramas e instruções de fácil compreensão. 67 | *Exemplo:* diagramas legíveis e coerentes com o código-fonte. 68 | 69 | --- 70 | 71 | ### 3. Qualidade Técnica do Código 72 | 73 | Código bem estruturado, modular e legível, com boas práticas, testes automatizados e histórico de commits claro que evidencie evolução contínua e responsabilidade técnica. 74 | 75 | *Detalhamento:* 76 | 77 | * **Estrutura e modularização** – código organizado por camadas e responsabilidades. 78 | *Exemplo:* controller, service, repository, separação de frontend e backend. 79 | 80 | * **Boas práticas** – uso consistente de padrões da linguagem e estilo de código. 81 | *Exemplo:* linters, convenções de nomes, tratamento de erros. 82 | 83 | * **Testes automatizados** – presença de testes unitários e/ou de integração. 84 | *Exemplo:* Jest, PyTest, JUnit, Postman/Newman. 85 | *Implicação:* ausência total de testes compromete a confiabilidade. 86 | 87 | * **Histórico de commits** – progresso contínuo e colaborativo. 88 | *Exemplo:* commits frequentes e mensagens descritivas. 89 | 90 | --- 91 | 92 | ### 4. Infraestrutura e Engenharia 93 | 94 | Engenharia madura: versionamento consistente, CI/CD funcional, monitoramento básico, práticas de segurança aplicadas e deploy automatizado com uso de ferramentas DevOps modernas. 95 | 96 | *Detalhamento:* 97 | 98 | * **Versionamento** – controle de branches e issues. 99 | *Exemplos:* GitHub, GitLab, Bitbucket. 100 | 101 | * **CI/CD (Integração e Entrega Contínua)** – pipeline automatizado de build, testes ou deploy. 102 | *Exemplos:* GitHub Actions, GitLab CI, Jenkins, Vercel, Netlify. 103 | *Implicação:* ausência de automação indica baixa maturidade de engenharia. 104 | 105 | * **Monitoramento e observabilidade** – logs e métricas básicas configuradas. 106 | *Exemplos:* Grafana, CloudWatch, Logtail, Railway Insights. 107 | 108 | * **Segurança** – uso de variáveis de ambiente, HTTPS, autenticação segura. 109 | *Exemplos:* JWT, OAuth2, proteção contra XSS/CSRF. 110 | 111 | * **Práticas DevOps** – deploy documentado, uso de containers ou scripts automatizados. 112 | *Exemplos:* Docker, Docker Compose, AWS, GCP, Azure. 113 | 114 | --- 115 | 116 | ### 5. Ética, Integridade e Autoria 117 | 118 | Autoria real, sem plágio, com uso ético e responsável de dados; violações como cópias, falsificações ou mau uso implicam reprovação imediata. 119 | 120 | *Detalhamento:* 121 | 122 | * **Autoria genuína** – o projeto é resultado do trabalho original do acdêmico, sem cópias de código, design ou texto. 123 | * **Uso ético de dados** – respeita princípios de privacidade, LGPD e boas práticas de pesquisa. 124 | *Implicação:* plágio, falsificação de resultados ou uso indevido de dados resultam em reprovação imediata. 125 | 126 | --- 127 | 128 | ### 6. Apresentação no Evento (Poster + Demo Day) 129 | 130 | Apresentação clara, demonstração funcional, domínio técnico nas respostas e pôster autoexplicativo com identidade consistente; falhas visuais ou operacionais reduzem impacto. 131 | 132 | *Detalhamento:* 133 | 134 | * **Clareza e narrativa** – explicação direta do problema, solução e resultados. 135 | *Exemplo:* storytelling com foco no impacto da solução. 136 | 137 | * **Demonstração funcional** – sistema acessível e operante em ambiente produtivo. 138 | *Exemplo:* link público via Vercel, Firebase ou servidor institucional. 139 | 140 | * **Domínio técnico** – equipe demonstra segurança ao responder perguntas. 141 | *Exemplo:* justificar escolha de arquitetura, linguagem, bibliotecas e métricas. 142 | 143 | * **Pôster técnico** – conteúdo autoexplicativo, com QR Code funcional e identidade visual coerente. 144 | *Implicação:* pôster incompleto ou ilegível reduz percepção de profissionalismo. 145 | 146 | --- 147 | 148 | ## ⭐ Participação da Comunidade Acadêmica 149 | 150 | - A comunidade acadêmica também avaliará os projetos, atribuindo notas de **originalidade** e **clareza de apresentação**. 151 | - A nota da comunidade será incorporada à média final com peso menor, valorizando o engajamento e a comunicação científica. 152 | 153 | --- 154 | 155 | ## 📏 Escala Final 156 | 157 | - **Nota Final:** média ponderada das avaliações (0 a 10), considerando professores e comunidade. 158 | - A avaliação privilegia **aprendizado, consistência, originalidade e ética profissional** como pilares de excelência. 159 | -------------------------------------------------------------------------------- /directions/portfolio-directions-GERAL.md: -------------------------------------------------------------------------------- 1 | # Direcionamentos para Portfólio. 2 | 3 | Atente para o portfolio directions de cada linha 4 | 5 | 1. [**Projetos de Web Apps**](https://github.com/CatolicaSC-Portfolio/The-Portfolio-Playbook-I/blob/main/directions/portfolio-directions-webapp.md) 6 | Aplicações web completas, com interface navegável, arquitetura definida e deploy público. 7 | 8 | 2. [**Projetos de Aplicações Mobile**](https://github.com/CatolicaSC-Portfolio/The-Portfolio-Playbook-I/blob/main/directions/portfolio-directions-mobile.md) 9 | Aplicativos nativos ou híbridos, com usabilidade e entrega funcional em dispositivo real. 10 | 11 | 3. [**Projetos de Jogos Digitais**](https://github.com/CatolicaSC-Portfolio/The-Portfolio-Playbook-I/blob/main/directions/portfolio-directions-jogosdigitais.md) 12 | Jogos autorais com gameplay funcional, loop básico, documentação de design e build jogável. 13 | 14 | 4. [**Projetos com IA**](https://github.com/CatolicaSC-Portfolio/The-Portfolio-Playbook-I/blob/main/directions/portfolio-directions-ia.md) 15 | Soluções que apliquem de forma fundamentada técnicas de Inteligência Artificial em problemas reais. 16 | 17 | 5. [**Projetos de IoT** ](https://github.com/CatolicaSC-Portfolio/The-Portfolio-Playbook-I/blob/main/directions/portfolio-directions-iot.md) 18 | Soluções envolvendo dispositivos conectados, sensores, atuadores e comunicação em rede. 19 | 20 | 21 | A tabela abaixo procura direcionar as decisões dos projetos. 22 | 23 | | Quadrante | Nome | Ação | Descrição | 24 | |--------------|----------------------------------------------------------------------|-------------|--------------------------------------------------------------------------------------------------------| 25 | | Ferramenta | Deploy via acesso ssh/ftp | 🚫 Não Usar | Método tradicional de deploy, considerado inseguro e menos eficiente em comparação com práticas modernas de CI/CD. | 26 | | Processo | Processo em cascata | 🚫 Não Usar | Modelo tradicional de desenvolvimento de software considerado rígido e menos adaptável às mudanças. | 27 | | Processo | eXtreme Go Horse | 🚫 Não Usar | Metodologia de desenvolvimento não convencional e não recomendada, focada na velocidade em detrimento da qualidade. | 28 | | Stack | Plataformas de No Code: Bubble.io, Webflow, Carrd, Thunkable, Bravo Studio, HubSpot CMS. (...) | 🚫 Não Usar | Permitem desenvolvimento rápido sem código, mas podem limitar a customização e escalabilidade. | 29 | | Stack | Banco em disco: H2, SQLite | 🚫 Não Usar | Soluções leves de armazenamento de dados, úteis para desenvolvimento e testes, mas limitadas para produção. | 30 | | Tema | Sistema de cardápio online/QRCode | 🚫 Não Usar | Soluções simples para restaurantes, mas com muitas alternativas disponíveis no mercado. | 31 | | Tema | Sistema de controle de estoque | 🚫 Não Usar | Soluções simples, mas com muitas alternativas disponíveis no mercado. | 32 | | Tema | Sistema de Tele-entrega | 🚫 Não Usar | Serviços de entrega são populares, mas altamente competitivos e regulados. | 33 | | Tema | Sistema de Gestão Financeira com ou sem IA | 🚫 Não Usar | Tema recorrente e já excessivamente explorado | 34 | | Tema | Soluções que utilizam IA com prompt sem incorporar efetivamente IA | 🚫 Não Usar | Tema recorrente e já excessivamente explorado | 35 | | Ferramenta | Notepad++ | ⚠️ Evitar | Editor de texto leve, popular entre desenvolvedores, mas com limitações para projetos complexos. | 36 | | Ferramenta | Documentação: Notion, Obsidian | ⚠️ Evitar | Ferramentas versáteis para notas e documentação, mas menos integradas ao fluxo de desenvolvimento. | 37 | | Processo | Scrum | ⚠️ Evitar | Metodologia ágil popular que, apesar de sua eficácia, pode não ser ideal para todos os projetos. Não indicada para projetos individuais. | 38 | | Stack | Plataforma otimizada para front-end, principalmente se não desenvolver backend (Vercel, Netlify, Firabase, Render) | ⚠️ Evitar | Soluções específicas para front-end podem limitar o controle sobre o frontend e a customização. | 39 | | Stack |Plataforma que oferece banco de dados, autenticação, storage e APIs automáticas, sem gestão ou conrtole sobre arquitetura | ⚠️ Evitar | Soluções específicas para persistencia de dados podem limitar o controle sobre o backend e a customização. | 40 | | Stack | Plataformas de cloud hosting que automatizam o deploy e a execução de aplicações web e APIs integração direta ao GitHub, SSL automático e infraestrutura escalável | ⚠️ Evitar | Soluções específicas para hospedaagem que limitam o controle sobre o backend e a customização. | 41 | | Stack | Linguagem: PHP | ⚠️ Evitar | Linguagem amplamente usada para desenvolvimento web, mas que enfrenta críticas quanto a modernidade e segurança. | 42 | | Tema | Sistema de gestão de listas de livros, filmes, músicas, etc. (similares a goodread) | ⚠️ Evitar | Projetos como sistemas de gestão de listas são comuns, mas enfrentam alta concorrência e desafios de inovação. | 43 | | Tema | Sistema de gestão de ecommerce/lojas virtuais | ⚠️ Evitar | Projetos de lojas virtuais são comuns, mas enfrentam alta concorrência e desafios de inovação. | 44 | | Ferramenta | Ferramentas de monitoramento de performance e observabilidade - Ex: Zabbix, Prometheus, Grafana | ✅ Preferir | Opções open-source para monitoramento, com necessidade de configuração e manutenção. | 45 | | Ferramenta | SonarQube, SonarCloud, CodeClimate | ✅ Preferir | Ferramentas de análise de código que ajudam a manter a qualidade e segurança do código. | 46 | | Ferramenta | Modelagem C4 | ✅ Preferir | Método de modelagem visual para sistemas de software que promove uma compreensão clara da arquitetura.| 47 | | Ferramenta | Ferramentas de monitoramento de performance e observabilidade - Ex: Dynatrace, New Relic e Datadog | ✅ Preferir | Essenciais para monitorar, diagnosticar e otimizar aplicações. | 48 | | Ferramenta | Issues/Tarefas: Trello, GitHub Project, Azure Devops | ✅ Preferir | Ferramentas que facilitam o gerenciamento de projetos e colaboração. | 49 | | Processo | Kanban | ✅ Preferir | Sistema visual para gerenciar trabalho conforme ele avança através de processos, promovendo flexibilidade e eficiência. | 50 | | Stack | Cloud (AWS, Heroku, Azure, Google Cloud, Magalu Cloud, ...) | ✅ Preferir | Serviços em nuvem oferecem escalabilidade, desempenho e flexibilidade. | 51 | | Stack | Docker | ✅ Preferir | Ferramenta essencial para a criação, deploy e execução de aplicações em containers, promovendo portabilidade e consistência. | 52 | | Stack | Terraform | ✅ Preferir | Ferramenta de infraestrutura como código que automatiza o provisionamento de infraestrutura em vários provedores de nuvem. | 53 | | Stack | Dados: PostgreSQL, MySQL, Oracle Database e Microsoft SQL Server. | ✅ Preferir | Bancos de dados relacionais robustos para aplicações de todos os tamanhos. | 54 | | Stack | Linguagem: Java, C#, Python, C++, Javascript, Typescript | ✅ Preferir | Linguagens fundamentais com amplo suporte, comunidades ativas e ecossistemas ricos. | 55 | | Tema | Solução que utilizem apis de LLMs públicas/comerciais | ✅ Preferir | Uso de APIs de linguagem de máquina oferece oportunidades para inovação em diversos campos. | 56 | | Tema | Sistema de gestão de processos (ERP, Contábil, Comercial, ...) | ✅ Preferir | Ferramentas essenciais para a automação e eficiência de processos empresariais. | 57 | | Processo | Aplicar SOLID e Clean Code | ✅ Preferir | SOLID - https://bit.ly/3tbawbD e Clean Code - https://bit.ly/3E7AaDx | 58 | | Stack | Dados: Redis e Memcached | ✅ Preferir | Sistemas de armazenamento em memória para cache e sessões, essenciais para aplicações de alta performance. | 59 | | Processo | Utilizar MCP (Model Context Protocol) com protocolo enter aplicações e modelos LLM | ✅ Preferir | Assunto pouco explorado.| 60 | | Ferramenta | Documentação em Wiki junto com repositório (Wiki do Github, GitLabs, ...) | 🔑 Obrigatório | Facilita o acesso e a colaboração na documentação de projetos. | 61 | | Ferramenta | Deploy via CI/CD (Github Actions, Jenkins, ...) | 🔑 Obrigatório | Automatiza o processo de deploy, melhorando a eficiência e a confiabilidade. | 62 | | Processo | TDD | 🔑 Obrigatório | Prática de escrever testes antes do código, garantindo qualidade e reduzindo bugs. 63 | | Stack | Dados: InfluxDB e TimescaleDB. | 🔍 Explorar | Bancos de dados de séries temporais, úteis para análise de dados em tempo real. | 64 | | Stack | Dados: Elasticsearch | 🔍 Explorar | Motor de busca e análise, ideal para pesquisa de texto e análise de grandes volumes de dados. | 65 | | Stack | Linguagem: Rust, Go, Elixir, Dart | 🔍 Explorar | Linguagens modernas oferecendo segurança, performance e concorrência para diversos tipos de projetos.| 66 | | Tema | Ferramentas de apoio a Engenharia de Software | 🔍 Explorar | Área em crescimento, com potencial para inovação em ferramentas e processos de desenvolvimento. | 67 | | Tema | Desenvolvimento de Jogos | 🔍 Explorar | Campo com grande potencial criativo e técnico, mas que requer habilidades especializadas e ferramentas dedicadas. | 68 | | Tema | Desenvolvimento de ferramentas para IA | 🔍 Explorar | Área promissora com demanda crescente por soluções inovadoras em inteligência artificial. | 69 | | Tema | Apps Mobile | 🔍 Explorar | O desenvolvimento de apps mobile é crucial, mas pode ser desafiador sem as plataformas e ferramentas adequadas. | 70 | --------------------------------------------------------------------------------