PI1A5 - Projeto Integrado I


Aulas    

Alguns pontos importantes sobre a disciplina:

  1. O projeto deve ser desenvolvido em Equipes
    • As equipes devem se registrar no moodle da disciplina
  2. 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
  3. 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
  4. 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
  5. 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
  6. 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
      • 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
      • 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
    • 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
  7. 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
  8. Regras da disciplina

de     en     es     fr