PI1A5 - Projeto Integrado I

Aulas

Alguns pontos importantes sobre a disciplina:

O projeto deve ser desenvolvido em Equipes
- As equipes devem se registrar no moodle da disciplina
O tema e o escopo devem ser aprovados pelos professores
- A aplicação proposta deve mapear, tratar e controlar processos
  - Não serão aceitas propostas que contemplem apenas cadastros e consultas
- O projeto deve ter como objetivo uma questão real de uso, num cenário existente
- Deve ser desenvolvido um documento com aproximadamente 5 páginas sobre a ideia, objetivos e tecnologias a serem utilizadas
  - Esse documento deve contemplar uma análise comparativa de outras aplicações de uso similar, bem como possíveis integrações e parcerias com outras aplicações.
- Para cada projeto deve ser criado
  - Um blog
    - Com feed RSS ou Atom
    - Deve indicar quem publicou e não utilizar um usuário genérico
    - O template do blog deve ser tal que permita a visualização direta das publicações, sem necessidade de clicar em um “ver mais” ou um ícone
    - As publicações semanais no blog devem conter um relatório gerencial de andamento do projeto, com identificação do desempenho e das tarefas individuais (ex. reuniões de milestones, project checkpoint, sprint review etc.).
  - Um canal no YouTube
    - Todos os vídeos gerados durante o desenvolvimento e apresentações devem ser publicados nesse canal
    - Todos os vídeos publicados devem ter na descrição e nas tags IFSP, SPO e PI1A5
    - A cada entrega/apresentação deve ser publicado um vídeo do Gource com o desenvolvimento desde o início do projeto
      - Alterar os userid do repositório por nomes dos participantes
      - Colocar uma imagem distinta e especifica para cada usuário
      - Utilizar opção –key
      - Utilizar as opções de caption para registrar as principais mudanças feitas no repositório
      - Os vídeos devem ter no máximo 1 minuto para cada mês contemplado
      - Deve ser entregue no repositório um arquivo de script (bat/cmd/sh) contendo os comandos utilizados para criação do vídeo
    - Qualquer outro vídeo que a equipe crie para o projeto deve ser publicado nesse canal
- Será feita uma apresentação de 10 minutos, seguida de perguntas/comentários dos professores e alunos da turma
- Até a data da apresentação da proposta, a equipe deve enviar para os professores um e-mail contendo
  - Uma linha (texto simples) com os logins dos participantes da equipe no formato estabelecido no arquivo acessos.txt localizado na raiz do repositório
    - O login é spPRONTUARIO (letras minusculas) a senha é a que já é utilizada para acesso a rede sem fio da ESCOLA
    - A senha pode ser verificada no site http://central.spo.ifsp.edu.br/
- Após a criação da pasta no repositório Subversion um arquivo equipe.yaml deve ser criado com os dados da equipe e projeto de acordo com modelo no repositório
Com base na proposta aprovada, deve ser desenhado o projeto a ser desenvolvido
- Para o desenho do projeto, deve ser definido o planejamento de projeto, incluindo
  - Metodologias de gestão de projeto e de desenvolvimento utilizadas
  - Organização da equipe (papeis, atividades, responsabilidades)
  - Gestão de tempo (exemplos: cronograma, diagrama de Gantt, formato de sprints etc.)
- O desenho do projeto deve considerar os seguintes fatores
  - Introdução contendo: contextualização, problematização, objetivos, justificativa, análise de concorrência refinada
  - Revisão bibliográfica pertinente ao projeto a ser desenvolvido
  - Arquitetura da solução apresentada
    - Inclusive arquitetura de comunicação entre as camadas
  - Definição do escopo a ser desenvolvido para a completude do projeto
    - Incluindo entregáveis de modelagem (exemplos: Casos de Uso / Diagrama de Requisitos / Histórias de usuário / Product Backlog etc.)
    - Considerando fases de entrega (prova de conceito, produto mínimo viável - MVP - e produto pronto PI2A6 - Projeto Integrado II)
  - Viabilidade financeira de mantenimento da aplicação
    - Considerar o caso real sem a utilização das cotas gratuitas que podem utilizar na disciplina
    - Considerando inclusive o uso da aplicação após o término da disciplina
  - Necessidade de escalabilidade (inclusive considerando referenciais de desempenho da aplicação)
  - Critérios de Segurança / Privacidade / Legislação
  - Tecnologias a serem utilizadas
  - Manutenibilidade da aplicação desenvolvida
    - Ferramentas compatíveis com as tecnologias escolhidas para Testes automatizados e Análise Estática
    - Devem ser definidos sistemas de log para toda a aplicação
    - Um processo de Integração Contínua
    - Especificação do “Coding Convention” (seja o próprio da linguagem, ou um criado/adaptado pela equipe)
    - Design Patterns pertinentes à aplicação
- Todo o desenho do projeto deve ser entregue em documento para os professores da disciplina
- Deverá ser feita uma apresentação de até 30 minutos, seguida de perguntas/comentários dos professores e alunos da turma
Com base no design proposto para a aplicação, deverá ser apresentada uma prova de conceito da aplicação
- Deverá estar disponível na internet, utilizando os ambientes definitivos de execução, já com os requisitos de publicação da aplicação final (HTTPS, por exemplo), quando for o caso
- Deverá abranger recursos que serão utilizados pelo projeto, desde o cliente até os servidores (banco de dados, DNS, aplicação, arquivos etc.)
- Deverá ter o texto em duas línguas para demonstrar internacionalização
  - Ter o suporte a internacionalização não implica necessariamente na tradução para um novo idioma, mas sim na utilização de mecanismos que permitam a inclusão de um novo idioma a partir de configurações / arquivos de tradução, se que seja necessário a modificação dos arquivos fontes.
  - A aplicação deve ser única, e deve ter os recursos textuais e não-textuais definidos em arquivos apropriados
  - não utilizar recursos de tradução automática diretamente na aplicação
- Deverá ser feito um vídeo de aproximadamente 3 minutos demonstrando a aderência desta prova de conceito com a aplicação final
- Deverá ser entregue um relatório identificando, com base no design aprovado, o processo de desenvolvimento da prova de conceito e as decisões tomadas
- Deverá ser feita uma apresentação de até 15 minutos para a turma
No final do semestre, em data definida no plano de aulas, deve ser entregue um documento final contemplando todo o desenvolvimento do semestre, até um MVP da aplicação
- O documento final deve ser uma evolução do documento já entregue, e adicionalmente conter:
  - Histórico das atividades, incluindo informações sobre a gestão do projeto
  - Reuniões
  - Desenvolvimentos de código, dados
    - Inclusive documentação sobre os índices criados nas bases de dados
  - Escolhas
  - Descartes (mudanças de rumo durante o projeto)
  - Levantamentos
  - Problemas ocorridos no desenvolvimento / gerenciamento
  - Protocolos
  - Modelagem do sistema (dados, classes etc.)
    - estimativas de volumes de dados (registros/linhas e espaço ocupado)
    - indicações dos indices das tabelas (individuais e compostos, ASC/DESC)
  - Contribuições efetuadas aos projetos de código aberto utilizados
  - Tabela com evolução das métricas do projeto aplicáveis (medir uma vez por mês - caso o projeto tenha módulos distintos (servidor, cliente etc.), registrar os números separados e totais)
    - Reuniões
    - Publicações de blog
    - Requisitos
    - Tamanho do projeto
    - Arquivos
    - Classes
    - Interfaces
    - Linhas
    - Métodos
    - Atributos
    - Testes unitários
      - Classes de testes
      - Quantidade de testes
      - Percentual de cobertura
    - Commits
    - Entidades de banco de dados
    - Imagens
    - Sons
    - Vídeos gerados
    - Outros que forem pertinentes à aplicação
  - Relatório de estatísticas gerado com StatSVN
    - no caso de utilização de git também gerar relatórios com ferramentas equivalentes como gitstats
  - Links do projeto (com QR-Code)
    - Controle de versão
    - Vídeos
    - Blog
    - URL (se for publicada na internet)
    - Outros links pertinentes
  - Anexos / Apêndices:
    - Todas as publicações semanais no blog
    - Atas de reuniões
    - Cronogramas
  - deve ser coerente
    - não faz sentido colocar itens somente de acordo com essa lista se não fizerem sentido no seu contexto (ex. se não fez contribuição para projeto de código aberto não precisa indicar que não houve contribuição)
    - não criar seções com nomes extamente dos itens solicitado nas regras, mas nomes que façam sentido no contexto do documento
    - respeitar a ordem cronológica de desenvolvimento (começo/meio/fim)
- Todos os processos da aplicação devem ser definidos e alguns já implementados na aplicação (MVP)
- Toda a estrutura de testes automatizados deve estar integrada ao desenvolvimento
- O relatório deve ser entregue em formato PDF
- Deverá ser feita uma apresentação de até 30 minutos para a turma, com no mínimo 10 minutos para apresentar o MVP desenvolvido
  - A aplicação deverá possuir um bom conjunto de dados reais para demonstrar corretamente as funcionalidades
Sobre a aplicação a ser projetada
- Deve ser feita considerando o uso de pelo menos uma linguagem OO. Outros paradigmas (como funcional e/ou lógico, por exemplo) podem ser utilizados, se pertinentes ao projeto.
- A plataforma pode ser
  - Desktop
  - Móvel
    - Para Android utilizar Acessibility Scanner para verificar a aplicação
  - Web
    - Deve ser gerado pelo menos um teste de usabilidade nas páginas de principal funcionalidade da aplicação, com Usabila, UsabilityHub, TryMyUI ou equivalente
    - Devem ser realizados Testes de Interface
    - As páginas devem ser passadas por um validador de HTML
    - Utilizar a ferramenta Lighthouse para verificação da aplicação
  - Embarcada
    - Existe a disponibilidade para empréstimo de alguns kits de Arduino na escola
  - Combinações dos anteriores
- As aplicações que necessitem de servidor web/serviços na internet devem ficar disponíveis em um servidor acessível na Internet
  - Utilizando um hostname em vez de somente IP
    - pode ser um domínio gratuito (dynamic dns)
  - Utilizando HTTPS para acesso
    - TLS
    - Utilizar um certificado gratuito Let’s Encrypt ou similar
    - Pode utilizar um serviço gratuito como CloudFare, CloudFront etc.
      - Nesse caso, documentar a configuração utilizada
    - Deve ter nota mínima A em https://www.ssllabs.com/ssltest/
  - Deve ser feita análise das respostas HTTP utilizando https://securityheaders.io
    - Deve se obter a melhor nota possível e justificar
  - Se a aplicação possui uma API para integração entre os módulos deve ser documentada seguindo padrões OpenAPI
    - Recomendável utilizar swagger (json ou yaml)
      - ex. https://github.com/Swagger2Markup/swagger2markup
  - Bibliotecas JavaScript, CSS e similares de terceiros não devem ser incluídas diretamente no projeto. Devem ser utilizados CDNs
- A interface da aplicação deve ser internacionalizada, de acordo com os preceitos e técnicas do W3C ou da tecnologia utilizada
  - https://www.w3.org/International/quicktips/index.pthttps://www.w3.org/…./index.pt
  - https://developer.android.com/training/basics/supporting-devices/languages.htmlhttps://developer.android.com/…./languages.html
- O número de projetos de jogos em cada turma deve ser inferior a 50%
- O projeto proposto pode ser uma evolução de um projeto já existente open source ou um projeto anterior já desenvolvido na escola
Todas as apresentações do semestre seguirão regras comuns
- Todos os documentos entregues e apresentações feitas devem ser colocados antes da entrega/apresentação em formato PDF no repositório Subversion
  - Cada PDF deve permitir a impressão direta, com todas as páginas na sequencia correta e sem a necessidade de montagem manual
- Todas as apresentações devem ser avaliadas por todas as equipes, em relatório entregue no repositório
  - Os relatórios devem apontar problemas e sugerir melhorias nos projetos das outras equipes
  - Esses relatórios devem ser considerados nas correções das etapas seguintes
  - Analogamente, os professores também avaliarão a qualidade das avaliações das outras equipes feitas por cada equipe
  - Cada equipe deve receber os relatórios, avaliar e implementar as melhorias possíveis
- Após cada apresentação/entrega, todas as equipes deverão preencher uma planilha de auto-avaliação, com todos os membros atribuindo uma nota e uma justificativa de nota para cada membro da equipe, seguindo o modelo disponível em Projetos e Apresentações, e entregar no repositório em UM arquivo no formato PDF corretamente formatado para visualização
Regras da disciplina
- O repositório Subversion da escola deve ser utilizado para a documentação, e (github|gitlab) pode ser utilizado para o desenvolvimento da aplicação.
  - A URL será disponibilizada em sala de aula
  - O código de projetos de disciplinas correlatas está disponível para consulta nesse repositório
  - Cada commit no repositório deverá ter um comentário referente às modificações
  - Na raiz do repositório existe um arquivo .txt com regras que devem ser seguidas
  - A cada entrega deve ser feita uma tag no(s) repositório(s) indicando a data e tipo de entrega (ex. 2020-02-10-Prova-de-Conceito)
  - No caso da utilização do (github|gitlab) para o desenvolvimento da aplicação
    - Criar uma organização e todos participantes devem ser owners, no gitlab utilizar o recurso equivalente de grupo
    - o(s) repositório(s) devem ser públicos
    - A cada entrega uma cópia do código que for desenvolvido no repositório externo deve ser atualizado no Subversion
    - Devem atualizar o repositório da escola com a versão atualizada do repositório externo, pelo menos uma vez a cada 15 dias
    - No final da disciplina o repositório da escola deve estar atualizado com a versão final dos arquivos
- O(s) professor(es) é(são) o(s) “Cliente(s)” das equipes
  - Todas as decisões de projeto e de mudança de escopo devem ser validadas pelo(s) cliente(s).
- A equipe escolhe as metodologias de Desenvolvimento e Gerenciamento que serão utilizadas
- Os blogs dos trabalhos e documentos são uma ótima fonte de informação se bem utilizados
- Durante todo o projeto os seguintes itens devem ser considerados :-)
- Deve ser utilizado LaTeX para a construção dos documentos (modelo de uso e algumas instruções constam também na página Textos)
  - Todos os códigos de marcação da documentação (LaTeX) e imagens utilizadas devem ter suas versões controladas no repositório Subversion
  - Modelo de Documento LaTeX no Overleaf
  - Todos os documentos entregues devem respeitar as regras e normas da ABNT para trabalhos acadêmicos e o Guia de Formatação do IFSP (cópia em anexo na página Textos)
- As informações constantes no documento modelo (Modelo de Documento LaTeX no Overleaf) devem ser seguidas
  - Leia com cuidado as informações contantes no modelo
  - Evite os erros já conhecidos
  - Faça o processo de revisão antes da entrega do documento
- Sempre que houver uma nova entrega de documento PDF, deverá ser entregue também um documento mostrando as diferenças gerado pelo latexdiff
- Todos os emails enviados para os professores devem indicar claramente quem enviou (pessoa), qual equipe e turma
  - Os emails devem ser enviados com cópia para todos os professores da disciplina naquele semestre
- A divisão das atividades desempenhadas por cada elemento da equipe deve ser documentada no trabalho. A avaliação será individualizada, conforme as atividades desempenhadas por cada aluno ao longo do projeto
  - Todos os membros da equipe devem escrever código e todos devem estar aptos a explicar qualquer parte técnica da aplicação.
- Todos os alunos devem fazer parte do grupo do Telegram indicado no Moodle e na mensagem enviada via SUAP antes do início das aulas
- Questionamentos genéricos sobre a disciplina devem ser feitos no grupo do Telegram de forma que todos alunos tenham acesso às respostas
- Avisos no decorrer do semestre podem ser publicados via canal Telegram IFSP-SPO-Projetos
  - https://t.me/joinchat/AAAAAET-oEt6v2nyhgx2CQ - QRCode
- Informações do Departamento e do Campus estão disponíveis em :
  - https://t.me/ifsp_spo_dit_avisos
- Todos as entregas de documentos e apresentações são consideradas como Avaliações

Na página da disciplina PDS - Prática de Desenvolvimento de Sistemas existe um documento PDF que pode ajudar a escalrecer dúvidas sobre algumas atividades
Ver mais informações em : Projetos e Apresentações
Os documentos devem ser entregues no repositório Subversion e também submetidos conforme orientação dos professores nas aulas

de en es fr