- Proper citations are a hallmark of any solidly written report, and are often useful in other forms of publications. Citation and Style Guides (2015) refers to several style guides; pick a suitable style and use it consistently. Especially see its section "How to cite sources".
- For citations, submit a working link to a freely-readable copy if available, and also submit a working link to a URL based on digital object identifiers (DOIs) if available. Here is an example citation using Vancouver system format:
- Mann ZÁ. Allocation of virtual machines in cloud data centers — A survey of problem models and optimization algorithms. ACM Comput Surv. 2015;48(1):11. doi:10.1145/2797211.
- The citation's title hyperlinks to a freely-readable resource http://www.cs.bme.hu/~mann/publications/Preprints/Mann_VM_Allocation_Survey.pdf. Unfortunately, these versions are often preliminary or ephemeral or both, so it's better to also include a DOI to the final, stable version even if it's not freely readable, as shown in How to share a link to an article with your students and collaborators (2015). The DOI reference in the above citation hyperlinks to http://dx.doi.org/10.1145/2797211.
- If your publication uses an active format such as PDF or HTML, URLs should be clickable.
- See Web of Science Journal Title Abbreviations for a list of reasonably-standard journal-title abbreviations.
- Simon Peyton Jones's Research skills (2015) contains a brief and pleasant section about how to write a good research paper.
- Roy Levin and David D. Redell's An Evaluation of the Ninth SOSP Submissions –or– How (and How Not) to Write a Good Systems Paper (1983) points out common problems in technical papers, and gives suggestions for how to fix them.
- The UNC Writing Center's Scientific Reports (2012) describes how to write and organize a scientific research report.
- David A. McMurrey's Online Technical Writing (2013) contains many examples and much discussion of technical writing. For example, it has a chapter on recommendation and feasibility reports that contains several sample reports.
- George Gopen and Judith Swan's The Science of Scientific Writing (1990) briefly summarizes some of the science behind writing clear writing for scientific audiences.
- William Strunk, Jr.'s The Elements of Style (1918) is the classic style guide for American English writing. It excels at showing how to omit needless words.
- The USENIX Templates for Conference Papers provides LaTeX and DOC templates for computer science research papers. The USENIX templates use a two-column format with 10-point font for most of the text, on an 8½"×11" page. LaTeX typically generates higher-quality output for technical papers. An example of the output format and an example student paper are available.
- The Cabrillo Tidepool Study's Scientific Report Rubric (1997) is the sort of thing we use when evaluating your report.
- Simon Peyton Jones's Research skills (2015) has a section "How to give a good research talk" almost makes it look easy and covers the essentials. He's brave enough to point you to a video of himself, giving the talk.
- Michael Ernst's Giving a technical presentation (giving a scientific talk) (2014) contains workable and up-to-date advice for giving computer science talks.
- Mark D. Hill's Oral Presentation Advice (1997) briefly describes how to give a good talk. It contains a summary of David Patterson's classic How to Give a Bad Talk (1983).
- Judith P. Rhodes et al.'s Scientifically Speaking: Tips for Preparing Scientific Talks and Using Visual Aids (2005) contains advice and observations on preparing and delivering a scientific talk. Its advice on poster presentations is also valuable, though you can skip it if you are not making a poster.
- The Science and Engineering Library (SEL) has a learning center with equipment with which you can rehearse your presentation. Reserve a time slot by visiting the circulation desk in Boelter 8270.
- Caroline McCullen's Student Presentation Rubric (1997) is the sort of thing we use when evaluating your presentation.
Original source: http://web.cs.ucla.edu/classes/spring16/cs188-3/comm.html
Eventualmente, na execução de projetos, podemos nos deparar com a necessidade de documentar ações e decisões por meio de relatórios técnicos ou ainda, realizar apresentações para discutir os resultados alcançados até então. Neste contexto, considere seguir estes guidelines para apoiar a construção do seu relatório técnico ou ajudar a planejar a sua apresentação oral.
O formato do relatório técnico deverá seguir o modelo da Sociedade Brasileira de Computação (SBC), em tamanho A4, contendo ao menos 10 páginas de conteúdo. Descrições Word e Latex deste modelo podem ser obtidas no portal da SBC, seguindo a referência para Eventos e Modelo para publicação de artigos (https://tinyurl.com/h24v37f).
Todos os relatórios técnicos devem ser escritos em português ou inglês. Os trabalhos devem conter uma folha de rosto em que constam exclusivamente:
- Título do trabalho
- Nome dos(as) alunos(as)
- Email de contato dos(as) alunos(as)
- Resumo em português ou em inglês
- Palavras-chave
- Link para o repositório (i.e. github, gitlab, bitbucket) do projeto contendo todos os aretaftos produzidos.
O conteúdo do trabalho deve iniciar na segunda página e deve ser descrito de forma clara e objetiva, incluindo, não limitado a, os seguintes itens ou tópicos:
- Introdução: Contendo a contextualização do domínio do negócio ao qual o projeto está inserido, o problema e motivação (mercadológica, digamos assim) para o investimento no projeto (você vão fazer uma venda do projeto pra mim, então, tem que estar claro que existe uma oportunidade aqui) e apresentação da proposta. É importante estar clara a
- Caracterização do Problema: contendo o planejamento no padrão Goal-Question-Metric desenvolvido pelo time.
- Fundamentação Teórica: Contendo todos os aspectos do estado da arte que fundamentam as escolhas e caminhos seguidos na execução do projeto.
- Estado Atual do Trabalho: contendo, mas não limitado a:
- Gerência de Configuração e Ambiente: Descrição das ferramentas e ambientes de desenvolvimento utilizados, com os respectivos links (i.e. ferramentas de desenvolvimento, linguagens, bancos de dados, bibliotecas, frameworks, repositórios de gerenciamento de versões e mudanças, servidores de implantação, entre outras).
- Características da aplicação: Elicitação das características da aplicação, suas funcionalidades, diferenciais, etc.
- Visão de Análise e Projeto (Arquitetura): Análise e Projeto do sistema a ser desenvolvido. podem ser utilizados especificações de casos de uso (para os mais 15% mais complexos) e diagramas para apoiar o projeto.
- Visão de Implantação: Visão e instruções de implantação do sistema. Um release notes com os erros, falhas e faltas conhecidos também é bem visto. Site onde ele está implantado e/ou um vídeo de demonstração promovendo o produto (pode estar no youtube ou outro serviço semelhante).
- Visão de Uso: Guia de uso da solução do ponto de vista de todos os stakeholders identificados.
- Descrição e Avaliação dos Resultados: contendo, mas não limitado a:
- Contribuições: rationale do time em relação ao projeto, lições aprendidas.
- Revisão do Projeto: Descrição do processo de desenvolvimento, principais problemas e tomadas de decisão em relação ao projeto. Atribuição das atividades e técnicas de gerenciamento, monitoramento e controle.
- Revisão Individual: Lições aprendidas do ponto de vista individual dos membros do time em relação a execução do projeto em si.
- Comparação com Trabalhos Relacionados: se pertinente, é desejável.