Aulas

Alguns pontos importantes sobre a disciplina :

Equipes
Desenvolvimento
- deve ser feito utilizando pelo menos uma linguagem OO
- a plataforma pode ser
  - desktop
  - móvel
    - Aplicações Android
      - Recomendada a utilização do Acessibility Scanner para verificar a aplicação
        
        https://play.google.com/store/apps/details?id=com.google.android.apps.accessibility.auditorhttps://play.google.com/….
  - Web
    - deve ser gerado pelo menos um teste de usabilidade em página de principal funcionalidade da aplicação, com Usabila, UsabilityHub, TryMyUI ou equivalente,
    - Teste de Interface
    - as páginas devem ser passadas por um validador de HTML
  - embarcado
    - existe a disponibilidade para empréstimo de alguns kits de Arduino
  - Ou combinações
- 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
    - recomendável utilizar swagger / yaml
      - ex. https://github.com/Swagger2Markup/swagger2markup
    - esse tipo de documentação deve ser publicado juntamente com a aplicação, somente os pontos principais indicados no documento
  - 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
  - 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%
- 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
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
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
Os professores são os “Clientes”
Cada equipe será o “Cliente” de um outra equipe
A equipe escolhe as metodologias de Desenvolvimento e Gerenciamento que serão utilizadas
Respeitar critérios de Segurança / Privacidade / Legislação
- Segurança/Privacidade
- ex. Lei Geral de Proteção a Dados - LGPD - 13.709 / 2018
Os blogs dos trabalhos anteriores e documentos são uma ótima fonte de informação se bem utilizados
- https://glybif.blogspot.com.br/2016/12/como-ir-bem-em-pds.htmlhttps://glybif.blogspot.com.br/…. {WA}
- https://projetothewalkingpet.blogspot.com/2018/12/dificuldades-e-licoes-aprendidas.htmlhttps://projetothewalkingpet.blogspot.com/…. {WA}
- https://projetoa6pgpgrupo101010.blogspot.com/ {WA}
- https://pgppain.blogspot.com/2019/03/19-coisas-que-voce-precisa-saber-sobre.htmlhttps://pgppain.blogspot.com/…. {WA}
- https://pgppain.blogspot.com/2019/03/nos-estamos-atrasados.htmlhttps://pgppain.blogspot.com/…. {WA}
- https://ginquestapp.wordpress.com/category/dicas-de-sobrevivencia/https://ginquestapp.wordpress.com/…. {WA}
Durante todo o projeto os seguintes itens devem ser considerados :-)
- http://www.implementingscrum.com/2006/09/11/the-classic-story-of-the-pig-and-chicken/http://www.implementingscrum.com/…. {WA}
- http://jkolb.com.br/wp-content/uploads/2013/09/project_sw.jpghttp://jkolb.com.br/…./project_sw.jpg {WA}
- http://www.thenewsriver.com/featured/dr-apj-abdul-kalam-best-motivational-quotehttp://www.thenewsriver.com/…. {WA}
- https://www.linkedin.com/feed/update/urn:li:activity:6460600769258225664/https://www.linkedin.com/…. {WA}
- https://www.nngroup.com/articles/computer-skill-levels/https://www.nngroup.com/…./computer-skill-levels {WA}
- https://www.tecmundo.com.br/seguranca-de-dados/113939-medicina-producao-cachaca-entenda-criminosos.htmhttps://www.tecmundo.com.br/…. {WA}
- https://g1.globo.com/economia/tecnologia/blog/altieres-rohr/post/2019/07/26/receita-de-ataque-expoe-limitacoes-e-amadorismo-de-hackers-que-acessaram-mensagens-do-telegram.ghtmlhttps://g1.globo.com/…. {WA}
- http://www.drcamilo.odo.br/parabolas/parabola_028.htmhttp://www.drcamilo.odo.br/…./parabola_028.htm {WA}
- Wald
  - https://www.ibm.com/blogs/digital-transformation/br-pt/nao-adianta-termos-bons-dados-se-nao-fizermos-boas-perguntas/https://www.ibm.com/…. {WA}
  - https://engenharia360.com/exercicio-guerra-matematica/https://engenharia360.com/…. {WA}
- https://www.javacodegeeks.com/2012/11/20-kick-ass-programming-quotes.htmlhttps://www.javacodegeeks.com/…. {WA}
  - os itens 4,6,12,13 são bem interessantes
- YouTube Motivação para Projetos⇓ ⇗
- Cuidado com “macacos”
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
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
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
      - Graficos obrigatórios : Todos Commits por Autor {WA}, Atividade por Autor {WA}, Atividade por Dia da Semana {WA} e Atividade por Hora do dia {WA}
    - 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)
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.
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
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
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
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
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
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
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

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

Nome	Tamanho	Data
Regras_PDS.pdf	176631	2021-05-09

de en es fr