PDS - Prática de Desenvolvimento de Sistemas


Aulas    

Alguns pontos importantes sobre a disciplina :

  1. Equipes
  2. Desenvolvimento
    • deve ser feito utilizando pelo menos uma linguagem OO
    • a plataforma pode ser
    • para aplicações que necessitem de servidor web/serviços na internet
      • considerando a disponibilidade pelos grandes provedores de cotas gratuitas (AWS - Amazon Web Services, Azure, Google, Oracle Cloud, Heroku etc.)
        • ver convênios em IFSP
      • a aplicação deverá ficar disponível 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 analise 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 essa API deve ser documentada seguindo padrões OpenAPI
      • Bibliotecas javascript, css e similares de terceiros não devem ser incluídas diretamente no projeto. É recomendável a utilização de um CDN
    • 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%
    • pode ser uma evolução de um projeto já existente open source ou um projeto anterior já desenvolvido na escola
    • deve ter Testes automatizados
    • um processo de Integração Contínua ajuda no desenvolvimento
    • deve utilizar um sistema de Log
      • ex: commons-logging, log4j, slf4j, log4php, log4net, logcat etc.
    • deve seguir o “Coding Convention” da linguagem ou o especificado pela equipe
    • utilizar ferramentas de Análise Estática para avaliar o código
    • criar um blog para o projeto
      • com feed RSS ou Atom
      • deve indicar quem publicou, e não utilizar um usuário genérico
      • utilizar um tema/formato onde as publicações são apresentadas diretamente (sem necessidade de clicar para expandir)
      • 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 para permitir a visualização
      • 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.).
    • criar um canal no YouTube
      • todos 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 PDS
      • vídeo com a proposta inicial - aproximadamente 5 minutos
      • vídeo com apresentação da aplicação entregue - aproximadamente 10 minutos
      • vídeo com apresentação final do projeto - aproximadamente 10 minutos
      • devem ser criados e publicados vídeos com o Gource com o desenvolvimento desde o inicio do projeto
        • a cada bimestre
        • em todas entregas e apresentações feitas
        • 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 bimestre
      • qualquer outro vídeo que a equipe crie para o projeto deve ser publicado nesse canal
    • criar o arquivo equipe.yaml no repositório e enviar um e-mail para os professores para atualizarem página blog
      • caso as URLs não entrem na página depois do envio informar os professores pessoalmente
    • o repositório Subversion da escola deve ser utilizado
      • ~a URL será disponibilizada em sala de aula~
      • a URL está disponível como material de aula no SUAP
      • 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) professores
        • 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 dos projetos anteriores está disponível para consulta nesse repositório
      • cada commit no repositório deverá ter um comentário referente as modificações
      • 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)
      • na raiz do repositório existe um arquivo .txt com regras que devem ser seguidas
  3. O tema e o escopo deve ser aprovado pelos professores
    • um documento de aproximadamente cinco páginas sobre a ideia, objetivos e tecnologias a serem utilizados
    • uma apresentação de 10 minutos, seguida de perguntas/comentários dos professores e alunos da turma
    • até a data dessa apresentação
      • a equipe deve enviar para os professores um e-mail contendo :
        • um arquivo no formato htpasswd com logins no formato spPRONTUARIO (letras minusculas)
        • 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
      • o PDF do documento e um PDF com os slides da apresentação devem ser colocados no repositório Subversion
  4. O projeto deve ser feito durante as aulas e fora da escola
    • Todas semanas, até a entrega da versão final revisada, deve ser feito um resumo das atividades desenvolvidas e publicado no blog do projeto
    • Indicar as atividades desenvolvidas por cada componente da equipe
  5. Os professores são os “Clientes”
  6. Cada equipe será o “Cliente” de um outra equipe
  7. A equipe escolhe as metodologias de Desenvolvimento e Gerenciamento que serão utilizadas
  8. Respeitar critérios de Segurança / Privacidade / Legislação
  9. Os blogs dos trabalhos anteriores e documentos são uma ótima fonte de informação se bem utilizados
  10. Durante todo o projeto os seguintes itens devem ser considerados :-)
  11. No segundo bimestre, deverá ser apresentada uma prova de conceito da aplicação, onde:
    • 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)
    • Esta prova de conceito deverá abranger recursos que serão utilizados pelo projeto, desde o cliente até o servidor de banco de dados
    • Deverá ter o texto em duas línguas para demonstrar internacionalizaçã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 (máximo de 5 páginas) identificando as tecnologias utilizadas e como elas serão utilizadas no projeto (diagrama de arquitetura)
    • Deverá ser gerado um vídeo do Gource, representando o desenvolvimento até esta data
    • Deverá ser feita uma apresentação de até 15 minutos para a sala
  12. Deverá ser feita uma apresentação para os outros professores e alunos
    • A ordem de apresentação será definida por sorteio
    • no 3o Bimestre
      • A equipe deve fazer uma apresentação de no máximo 45 minutos, seguida de perguntas dos professores
        • mínimo de 15 minutos para demonstrar a aplicação
      • pode ser utilizado vídeo, mas a aplicação deve ser demonstrada em funcionamento também
      • A aplicação deverá possuir um bom conjunto de dados para demonstrar corretamente a funcionalidade
    • no 4o Bimestre
      • A equipe deve fazer uma apresentação de no máximo 20 minutos
        • apresentar os ajustes efetuados
    • O calendário que tem as datas de apresentação é definido no plano de aulas e disponivel no SUAP
  13. Os seguintes itens devem ser entregues (pelo menos uma semana antes da apresentação da primeira equipe) :
    • Documentos (formato PDF)
      • Relatório com desenvolvimento durante o ano
        • introdução
        • problema a ser solucionado
        • justificativa
        • objetivos do projeto
        • revisão da literatura com os assuntos tratados no trabalho
          • não misturar o desenvolvimento feito pela equipe com os estudos feitos
      • não incluir pesquisa sobre temas das disciplinas do curso, somente temas relacionados ao dominio do problema a ser solucionado
        • histórico das atividades, incluindo informações sobre a gestão do projeto
        • reuniões
        • desenvolvimentos de código, dados
        • escolhas
        • descartes (mudanças de rumo durante o projeto)
        • levantamentos
        • problemas ocorridos no desenvolvimento / gerenciamento
        • protocolos
        • modelos de dados, classes, índices de banco de dados 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 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
          • etc.
        • relatório de estatísticas gerado com StatSVN
        • links do projeto
          • Controle de versão
          • Vídeos
          • Blog
          • aplicação web se for publicada na internet
          • etc.
        • Anexos / Apêndices :
          • todas as publicações semanais
          • cronogramas
          • documento de aprovação (item 3)
          • planos de teste
          • análise de cobertura dos Testes
          • execução de pelo menos uma ferramenta de Análise Estática no código
        • etc.
      • Manual de Usuário do projeto desenvolvido
      • Manual Técnico do projeto desenvolvido
      • Os dados qualitativos e quantitativos sobre o projeto (métricas, estatísticas, análises) devem ser efetivamente coerentes com a realidade.
      • O documento deve ser completo e permitir impressão completa se necessário
        • com todas as páginas na sequencia correta sem necessidade de montagem manual
      • Devem seguir o Guia de Padronização do IFSP (cópia em anexo na página Textos) e as normas da ABNT
    • Vídeos
      • Demonstrativo da aplicação em funcionamento
      • criado com o Gource demonstrando como foi o desenvolvimento do projeto no repositório Subversion
        • Alterando os userid do repositório por nomes dos participantes
      • entregar também um arquivo bat / cmd / script contendo os comandos utilizados para criação do vídeo
    • Código fonte e links ou configurações bibliotecas para desenvolvimento
    • Scripts de criação de base de dados (quando necessário)
    • Material da apresentação inicial para aprovação em PDF (item 3)
  14. 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
    • Os professores podem criar projetos no overleaf e compartilhar com a equipe para que a equipe possa utilizar os recursos de histórico mesmo com conta gratuita.
  15. Após as apresentações no final do 3o Bimestre, cada equipe deve fazer sua própria avaliação dos outros projetos e entregar um relatório
    • apontar problemas
    • possíveis melhorias
    • cada equipe deve receber os relatórios, avaliar e implementar as melhorias possíveis durante o 4o Bimestre
    • Os relatórios devem ser colocados no Subversion
  16. Após a apresentação e avaliação, deverá ser entregue uma nova versão revisada
    • Incluir a versão PDF da apresentação e qualquer outro material que tenha sido utilizado na apresentação
    • Caso a equipe opte por gravar sua própria apresentação, o vídeo deve ser enviado para o Youtube
  17. Para cada entrega ou apresentação feita, no mesmo dia:
    • Os arquivos PDF correspondentes devem ser colocados no repositório Subversion da escola
    • Sempre que houver uma nova entrega de documento PDF, deverá ser entregue também um documento mostrando as diferenças (gerado pelo latexdiff)
    • Vídeos correspondentes devem ser publicados no canal do YouTube
  18. Todos emails enviados para os professores devem indicar claramente quem enviou (pessoa), qual equipe e turma
    • os emails devem ser enviados com cópia para ambos professores
  19. Além da documentação e da execução da aplicação, serão avaliados os modelos estáticos e dinâmicos da aplicação, bem com a relação entre modelos, aplicação e objetivos do projeto
  20. A divisão das atividades desempenhadas por cada elemento da equipe deve ser documentada no trabalho. A avaliação pode ser individualizada, conforme as atividades desempenhadas por cada aluno ao longo do projeto
  21. Avisos no decorrer do semestre podem ser publicados via canal Telegram IFSP-SPO-Projetos
  22. Informações do Departamento e do Campus estão disponíveis em :

Prazos

  • Seguir as datas do plano de Aula do SUAP, os bimestres aqui são uma indicação aproximada
  • 1o Bimestre
    • Pesquisar projetos anteriores tanto do curso técnico integrado (AXXXX*) como do curso superior (SXXXXYY) que se encontram no repositório Subversion
      • Análise e Avaliação de dois projetos anteriores que utilizem preferencialmente o mesmo tipo de tecnologia que será utilizada no projeto da equipe
        • detalhar quais pontos compatíveis levaram a escolha dos dois projetos analisados
        • gerar documento indicando problemas e melhorias
        • verificar os logs de commits do Subversion
        • o mesmo projeto não poderá ser utilizado pelas equipes mais de uma vez para análise
        • indicar o que aprenderam com o projeto, que cuidados devem tomar a partir da leitura dos outros projetos
          • tanto os dois analisados e documentados como outros que tenham lido antes de fazer a escolha final dos dois projetos
        • fazer analise critica, não acreditar no que esta só no documento
          • verificar se o que esta no documento bate com a realidade que pode ser observada pelo blog, commits, arquivos do repositório
    • Pesquisas sobre tecnologias, ferramentas etc.
    • Apresentação da proposta e Aprovação do projeto (item 3)
    • Análise e Avaliação das propostas apresentadas pelas outras equipes da turma
      • detalhar possiveis problemas, sugestões de recursos a serem implementados
  • 2o Bimestre
    • Apresentação da Prova de Conceito
    • Apresentação parcial para sala, 20 minutos
    • Verificação de documentação (eletrônica)
    • Verificação de códigos
  • 3o Bimestre
    • Entrega e apresentação da 1a versão
    • Análise dos projetos dos outras equipes e entrega de relatório
      • criticas, sugestões, pontos negativos, positivos etc.
      • iniciar a avaliação logo após a apresentação de cada equipe
      • Relatório entregue somente em PDF no Subversion
        • /Documentos/Analise_Outros_Projetos/Resumo.pdf
        • Documento com uma analise geral de todos os outros projetos
      • /Documentos/Analise_Outros_Projetos/XX_Nome_do_Projeto.pdf
        • XX - Ordem de apresentação (01,02,03, …)
        • Detalhamento do projeto Nome_do_Projeto
  • 4o Bimestre
    • Verificação de todas as Análises feitas pelas outras equipes
    • Complementação e correções do projeto
    • Apresentação resumida (25 minutos) e entrega Atualizada (a entrega de todas equipes deve ser feita no primeiro dia de apresentações)
      • versões anteriores devolvidas pelos professores devem ser apresentadas (não serão recolhidas) juntamente com essa entrega final
  • Uma semana antes do término de cada bimestre, as equipes deverão preencher a planilha de avaliação da equipe (planilha de notas), 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
  • Todos prazos são considerados como Provas / Avaliações
  • Em 2021 foi criado um documento PDF (anexado nessa página) com detalhamento das definições da disciplina, caso existam dúvidas ou inconsistencias entre esta página e o documento PDF converse com seu(s) professor(es).

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

Downloads

NomeTamanhoData
Regras_PDS.pdf 176631 2021-05-09

de     en     es     fr