PI1A5 - Projeto Integrado I


Aulas    

Alguns pontos importantes sobre a disciplina:

  1. O projeto deve ser desenvolvido em Equipes
  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
      • URLs relacionadas ao projeto (blog, YouTube etc.)
      • 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)
      • Viabilidade financeira de mantenimento da aplicação
        • 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 em 2 vias
    • Deverá ser feita uma apresentação de até 15 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
    • 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, em duas vias
    • 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.)
      • 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
      • 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
    • Alguns processos já devem estar definidos e implementados na aplicação
    • Toda a estrutura de testes automatizados deve estar integrada ao desenvolvimento
    • O relatório deve ser entregue impresso, em 3 vias
    • Deverá ser feita uma apresentação de até 30 minutos para a turma, com no mínimo 10 minutos para apresentar o MVP desenvolvido
  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
      • 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 durante o 4o Bimestre
    • Após cada apresentação, 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 equipe, seguindo o modelo 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
    • O repositório Subversion da escola deve ser utilizado para a documentação, e o github pode ser utilizado para o desenvolvimento da aplicação.
      • A URL será disponibilizada em sala de aula
      • Caso se opte por um projeto de código aberto poderá ser utilizado um repositório de controle de versão público externo após aprovação pelo(s) professor(es)
        • Devem atualizar o repositório da escola pelo menos uma vez a cada 15 dias, com a versão atualizada do repositório externo
        • No final do projeto a versão final deverá ser colocada no repositório da escola
      • 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 para o desenvolvimento da aplicação
        • Criar uma organização e todos participantes devem ser owners
        • o(s) repositório(s) devem ser públicos
        • Se o gitlab ou outro repositório público vier a ter recurso equivalente ao de organização que permita o mesmo tipo de acesso pode ser negociado com os professores a utilização desse outro ambiente
        • A cada entrega uma cópia do código que for desenvolvido no repositório externo deve ser atualizado no Subversion
    • 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
      • 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)
      • Pode ser feita impressão frente/verso
        • Existem ajustes que devem ser feitos na formatação ao imprimir frente/verso
      • CD ou DVD contendo todos os itens anteriores
        • Lembrem que um CD ou DVD tem muito espaço livre, não deixem os seus arquivos compactados.
        • Todos os vídeos que foram enviados para o YouTube em uma pasta Videos
        • Deve ser colocado em um envelope de papel colado na contra capa do documento
        • Somente uma das vias da documentação deverá incluir o CD / DVD
        • Alternativamente, pode ser entregue um pen-drive, desde que devidamente afixado no documento.
      • É importante que o CD/DVD/pen-drive seja afixado de modo que : - o professor possa retirá-lo para utilizar normalmente e recolocar no trabalho. - os trabalhos sejam empilhados sem dificuldades.
    • 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.
    • Avisos no decorrer do semestre podem ser publicados via canal Telegram IFSP-SPO-Projetos
    • Todos prazos são considerados como Provas / Avaliações

Ver mais informações em : Projetos e Apresentações


de     en     es     fr