Para ir "bem" em PDS é simples, dedique-se, evite "perder" tempo e siga os requisitos do site do Ivan (http://dicas.ivanfm.com/aulas/pds). Isso que falei até aqui foi muito vago, então, além disso vou deixar alguns conselhos do que utilizar e fazer.
Para o primeiro bimestre
Não tenham medo de perguntar algo aos professores, eles NÃO mordem. Dependendo do que vocês irão perguntar, eles não vão dar a resposta direto, mas vão dar uma noção do que vocês devem procurar. Além do mais, eles também são os clientes.
Após o primeiro dia de aula já definam a equipe, definam quem será o gerente, criem o blog e o canal no YouTube, em seguida, informem aos professores o nome da equipe, os integrantes, link do canal e do blog. E lembrem-se de fazer uma publicação sobre a primeira semana, caso contrário perderão nota.
Façam reuniões constantemente para saber o desenvolvimento do projeto e o que pode mudar na divisão de tarefa.
Definam o mais rápido possível qual será o projeto, pois assim terão mais tempo para o desenvolver. Lembrando que o tema do projeto deve ser aprovado pelos professores antes de ser desenvolvido. Se interessarem-se pelo projeto da nossa equipe (equipe: GLYBIF, projeto: Cidade Ajuda), ficaremos felizes em ver o resultado.
A análise dos projetos anteriores pode ajudar vocês a decidirem o projeto, lembrando que os dois que vocês escolherem terão de fazer uma análise sobre eles. Mas tomem cuidado com o que vocês irão encontrar, pois pode ter coisas erradas, que logicamente não devem ser seguidas.
Para terem uma noção do que deve ter na documentação ou apresentação vejam sempre a versão mais recente.
Uma das melhores documentação da nossa sala foi a da equipe Robson, deem uma olhada. E o melhor código da sala acreditamos que seja o da nossa equipe (GLYBIF). O código por possuir análise estática, documentação do código (JavaDoc) e testes unitários, isso ao menos no site do Cidade Ajuda; a documentação por conta de estar bem completa e até foi elogiada pelos professores na apresentação dos ajustes. Obs: olhem a documentação do quarto bimestre e o código baixe o mais recente.
Não esqueçam de fazer o estudo de mercado no início do projeto, ou seja, depois de definir o projeto ou logo após a apresentação inicial.
Estudem um pouco sobre como funciona o controle de versão SVN - que é o utilizado pela escola. Ele é bem simples, então um simples estudo pode ajudar a não fazer bobagem. No Windows utilizamos TortoiseSVN e no Linux utilizamos RapidSVN.
Caso estejam com medo/receio de enviar algo para o repositório, vocês podem criar um repositório SVN no próprio computador de vocês, procure no Google para saber mais.
Sempre mandem as atualizações feitas (tanto na documentação como na programação) para o repositório. Não estamos dizendo que devem dar commits a cada linha, mas para que vocês tenham sempre o mais atualizado no repositório, para não ocorrer de integrantes da equipe estarem utilizando/modificando a versão desatualizada.
NÃO utilizem programas como Tortoise ou RapidSVN para enviar arquivos relacionados à programação. Utilizem a própria IDE (ambiente de desenvolvimento integrado), como o NetBeans para site/servidor ou o Android Studio para aplicativo móvel, pois assim evitarão de enviar arquivos indesejados (arquivos temporários).
Gerar o vídeo no Gource é fácil, consulte a documentação dele que está no GitHub (https://github.com/acaudwell/Gource/wiki) para entender seu funcionamento. Obs: Na documentação recomendam usar programas de captura de tela, como o Fraps, mas NÃO recomendamos. Utilizem a biblioteca ffmpeg para gerar o vídeo em MP4, CASO SE INTERESSEM EM TER ALGO FACILITADO, no nosso repositório, na pasta Vídeo, tem todo um código que gera o vídeo no Gource sem complicação, tem até um leia-me explicando como funciona e o que modificar; o único "problema" é que talvez ao gerar o Gource com o script destinado ao Windows dê problema de codificação - execute o script que vocês entenderão do estamos falando. Como o vídeo no Gource deve possuir legenda, o membro da equipe, Lorhan Sohaky, desenvolveu um algoritmo em linguagem C que pega o texto dos commits e os “transformam” em legendas. Obs: isso está na pasta Vídeo do repositório (olhe o LEIA-ME) e no GitHub dele (https://github.com/LorhanSohaky/LegendaAutomatica).
Caso o projeto tenha banco de dados vocês pode utilizar o programa brModelo para gerar o MER e o site DRAW.IO para gerar o DER.
Vocês podem utilizar o Google Drive para organizar algumas coisas e sincronizar o DER feito pelo DRAW com o seu drive.
O cronograma deve ser feito pelo gerente no começo do ano e no decorrer do ano deve enviar os cronogramas preenchidos. Vale lembrar que deve ter cronograma bimestral e um cronograma geral (ano inteiro).
Para o segundo bimestre
Não demorem a fazer a documentação, caso contrário, no terceiro bimestre terão de virar algumas noites para entregar uma documentação minimamente apresentável.
Para a documentação utilizem o LaTeX, com ele vocês podem fazer toda a documentação seguindo as normas ABNT sem problemas, pois precisam apenas se preocupar com o conteúdo e o LaTeX cuida do restante. Então, NÃO utilizem programas como o Microsoft Word ou LibreOffice Writer para fazer os textos, já que neles vocês podem acidentalmente desconfigurar o texto, ou seja, utilizar eles (mesmo que seja por conta de já entenderem como funcionam) só vai dar mais trabalho, pois provavelmente na apresentação do 3° bimestre vão reclamar da formatação - olhem as documentações de 2015, algumas possuem problemas de formatação. Existe um site em que várias pessoas podem editar o arquivo (documentação) ao mesmo tempo, chama-se Overleaf, o único problema é que a versão gratuita desse site tem um limite de tamanho do arquivo, ou seja, se a documentação ficar muito extensa pode ser que não consiga adicionar mais coisa, nesse caso você pode utilizar o programa TexMaker, este não tem limite, mas também não é possível fazer com que várias pessoas editem o texto simultaneamente. Vocês até podem utilizar esta ferramenta (LaTeX) para fazer a proposta inicial (documento+apresentação), o que será visto com bons olhos pelos professores. Curso LaTeX: https://www.youtube.com/playlist?list=PLa_2246N48_p9ndUHlO255uvKtSR8mshE; opinião de uma pessoa do meio cientifico sobre a utilização do LaTeX: https://www.youtube.com/watch?v=3WWXjuvhQ8Y.
Se o projeto envolver o desenvolvimento de um aplicativo para Android, tomem cuidado para não enviar arquivos temporários para o repositório, para isso não acontecer, basta editar um arquivo chamado .gitignore - no repositório do GLYBIF, no diretório "Projeto/CidadeAjuda" está o nosso aplicativo para Android, então podem tomar como exemplo.
Para aqueles que querem programar para Android, mas não tem ideia de como começar, tem um canal no Youtube com várias dicas, o nome dele é Thiengo Calopsita (https://www.youtube.com/user/thiengoCalopsita/playlists). Só não vão ficar apenas assistindo sem praticar, senão estarão apenas assistindo e não aprendendo.
Utilizem o TODO (do inglês to do) como lembrete do que vocês têm de arrumar, assim não tem como esquecer de editar aquele trecho, pois as IDEs indicam onde tem um TODO, acreditamos que os editores de LaTeX tenham esta funcionalidade também.
Se possível migrem para o Linux, ou seja, LARGUE o Windows. No Linux vocês conseguirão instalar mais facilmente os programas necessários (como Subversion, Gource e StatSVN) e um desempenho melhor. O pessoal que utilizou o Android Studio no Windows teve dificuldade para instalar, problemas para renomear pacotes e alguns erros. O Lorhan recomenda o uso do Xubuntu, mas vocês podem utilizar outros sistemas; o Ivan provavelmente irá falar para vocês utilizarem Linux, mais especificamente o Federa, pois é o que ele utiliza/gosta. É sério, torna-se MUITO mais fácil de gerenciar o projeto (não só a parte de programação, mas tudo de modo geral). Recomendamos que vejam o canal Diolinux caso tenham interesse no Linux (https://www.youtube.com/user/Diolinux/videos).
Se vocês estiverem muito apegados ao seu sistema operacional fraco de baixo nível e performance (A.K.A Windows), ou precisarem de alguma coisa que está em sua máquina pessoal, utilizem o TeamViewer. É uma ferramenta que será muito útil ao decorrer do ano, poupando bastante tempo, e principalmente não será necessário instalar o Android Studio todos os dias em que tiverem aula de PDS.
Documentem o código, pois será um dos itens avaliados pelos professores e facilita a compreensão do código. Podem tomar como exemplo o site Cidade Ajuda.
Aproveitem as férias para se dedicarem ao projeto, para não terem de passar dias sem dormir para entregar o projeto.
Façam as métricas todo final de mês, caso contrário terão um pouco mais de trabalho, já que terão de descobrir o número do último commit de um determinado mês e fazer checkout.
Para o terceiro bimestre
Conosco ocorreu a demissão de um integrante da equipe. Vale lembrar que isso não é uma regra, pois em anos anteriores os professores sortearam quais membros sairiam da equipe e até teve vezes em que nenhum membro trocou de equipe.
No 3° bimestre terá a entrega da documentação e a entrega da preview do aplicativo (documentação impressa e o aplicativo em um CD) para os professores. Fizemos um script, SOMENTE para Linux, que baixa os vídeos do YouTube, baixa o repositório (ckeckout), gera o StatSVN e organiza os arquivos - o código está localizado no diretório “ArquivosDeControle/CD”. Quanto a documentação, imprimam com pelo menos 3 dias de antecedência para não ter imprevistos.
Tentem criar o CD antes da data de entrega, dizemos isso, pois a nossa equipe deixou para fazer no dia e foi algo insano.
Na apresentação do 3° bimestre os professores deram mais enfoque a documentação e a usabilidade da aplicação, ou seja, se seu código não estiver muito bom não preocupam-se tanto.
Para saber se sua documentação está "boa" para a entrega do 3° bimestre, você pode tomar como base que a sua documentação deverá conter cerca de 100 páginas.
Se vocês utilizaram o LaTeX para a documentação, vocês também pode utilizá-lo para fazer a apresentação - os professores vão gostar se vocês utilizarem.
Tenha um PLANO B para apresentação, ou seja, tenham os arquivos e aplicativo em mais de um dispositivo (pen drive e celular), além disso, caso a aplicação necessite de internet, gravem um vídeo demonstrativo da aplicação.
Provavelmente os professores já recomendaram isso, mas vale lembrar. Todos os integrantes devem ter uma noção do que está escrito na documentação, então aproveitem isso para fazer um revisão dela para corrigir possíveis erros, como de ortografia. Mostrem a documentação a outra(s) pessoa(s) para que vocês possam saber se a documentação está boa, visto que uma das cópias da documentação será entregue a um professor que não conhece nada do projeto.
Deem MUITA atenção a análise dos outros projetos, pois não basta analisar a apresentação, mas também o código e a documentação. Então, não deixem para fazer em cima da hora. A análise dos outros projetos feitas pela nossa sala não estão completas, então não baseiem-se fielmente à elas.
Deem MUITA atenção ao que os professores falaram na apresentação (sugerimos até que gravem em áudio se os professores deixarem) e a análise que as outras equipes fizeram do projeto de vocês, pois isso irá influenciar nas modificações do quarto bimestre.
Na documentação, na parte das reuniões falem o que foi discutido e o resultado. Não utilizem o Wikipédia como fonte, pois mesmo que ela explique algo corretamente, ainda é superficial. Então, vocês podem pegar as fontes bibliográficas do Wikipédia e estudar sobre o assunto. Quando colocarem QRCode, coloquem a URL em baixo. Utilizem referência do tipo “conforme Imagem 1” e não “conforme imagem abaixo”. Talvez as partes mais complicadas (para o desenvolvedor/documentador) sejam o manual técnico e os casos de uso.
Tomem cuidado com as métricas, deem preferência em utilizar métrica acumulativa, ou seja, se em Janeiro foram criadas 5 classes e em Fevereiro mais 3, não coloque que em Fevereiro tinham 3 classes, mas sim 8 (5+3) classes.
As análises estatística e diagrama de classe podem ser feitas com plugins na própria IDE, ou seja, não é necessário ser desenhista para fazer o diagrama de classes. Assim, em poucos minutos vocês conseguem gerá-las. Para análise estática utilizamos FindBugs e para diagrama de classes com easyUML.
Se precisarem de DNS, vocês pode utilizar o que é fornecido gratuitamente pelo NoIp (https://www.noip.com/).
Podem utilizar o Firebase como banco de dados destinado a aplicativos Android, já que possui uma fácil implementação para utilizar no Android.
Caso precisem de um certificado SSL para o site (caso seja desenvolvido um site), vocês podem utilizar o servidor web Nginx - que por padrão roda na porta 80 - e o programa de certificação Let's Encrypt. Lembrando que o programa de certificação só certifica os sites que possuem DNS e que estão rodando na porta 80.
Para o quarto bimestre
Não se esqueçam de fazer o vídeo final, que deve ter no máximo 10 minutos. Preparem-se para apresentar o projeto para os professores e um convidado. Imprimam uma cópia da documentação e gravem o CD - como ocorreu no terceiro bimestre -, entregue estes itens na data de entrega final.
Se vocês seguiram as dicas dadas até aqui, não terão muitos problemas, então agora é corrigir os erros, fazer as melhorias sugeridas pelos professores e pelas outras equipes, entregar uma única cópia da documentação final impressa, apresentar as modificações e agora só resta - como diz nosso professor André Cipoli - “correr para o abraço da galera”!
Por: Lorhan Sohaky
