Métodos de Desenvolvimento de Software

Plano de Ensino - 2025/2

Disciplina

Métodos de Desenvolvimento de Software

Carga Horária

60 horas

Professor

Carla Rocha

Créditos

04

Objetivos da Disciplina

Os métodos de desenvolvimento de software podem ser entendidos como conjuntos estruturados de boas práticas, repetíveis durante o processo de produção do software.

Principais objetivos:

  • Capacitar o aluno a compreender os diferentes métodos, ferramentas, procedimentos e complexidades do desenvolvimento de software.
  • Capacitar o aluno a aplicar/adaptar processos de desenvolvimento de software à resolução de problemas de software.
  • Capacitar os estudantes a construírem sistemas complexos, apresentando as habilidades técnicas e não técnicas necessárias para a construção de software no contexto atual da Indústria.

Ementa do Programa

  • Modelos de ciclo de vida e de processos
  • Processo Unificado
  • Métodos Ágeis de desenvolvimento de software
  • Outras abordagens de desenvolvimento de software
  • Ferramentas

Metodologia de Ensino

Princípio Fundamental

Uma estratégia eficaz de aprendizagem deve integrar conceitos teóricos com sua aplicação prática, seguindo o princípio de "aprender fazendo". Sem prática, não há aprendizado significativo.

Abordagens Utilizadas

Aprendizagem por experiência
Aprendizagem orientada a projetos
Processo de Onboarding
Práticas de comunidades Open Source

Formação das Equipes

Regras de Formação

  • Equipes ágeis de até 6 membros por time
  • Cada grupo escolhe 3 temas na ordem de preferência
  • A professora negocia e aloca os temas dentro das preferências

Canais de Comunicação

Formato das Aulas

A disciplina será realizada de forma presencial na sala Mocap. Serão disponibilizados tanto material assíncrono quanto aulas síncronas.

Aulas Assíncronas

  • Vídeos disponibilizados no YouTube - Canal YouTube
  • Leituras sugeridas na sprint - disponibilizadas no planejamento das aulas

Planejamento das Aulas

  • O planejamento das aulas semanais, discriminando se são assíncronas ou síncronas, e qual canal será atualizado, estará disponível no início da semana no link

Descrição do Programa

Processos de Desenvolvimento de Software

  • Modelos de Processo de Desenvolvimento de Software (ciclo de vida)
  • Atividades de Processo

Fundamentos do Extreme Programming

  • O manifesto Ágil
  • Os Quatro valores e as Quatro variáveis
  • Práticas ágeis
  • O jogo do planejamento
  • Releases Pequenas
  • A metáfora
  • Histórias do Usuário
  • Desenho simples
  • Testes (unitário, aceitação)
  • Refatoração
  • Programação em Pares
  • Desenvolvimento Coletivo

Fundamentos do Processo Unificado de Desenvolvimento de Software

  • Conceitos
  • Fases: Iniciação, Elaboração, Construção e Transição
  • Disciplinas (Modelagem de Negócio, Requisitos, Análise e Desenho, Implementação, Teste, Gerenciamento de Projeto, Gerência de Configuração e Mudanças, Implantação e Ambiente)

Avaliações e Critérios de Avaliação

A avaliação será feita por meio da avaliação individual do desempenho do aluno no ciclo de projeto. O objetivo do Projeto simula uma situação real de desenvolvimento. Os alunos de MDS irão se concentrar na execução metodologia de desenvolvimento através da especificação de requisitos, codificação e testes. Haverá duas avaliações formais das releases a serem desenvolvidas.

A nota final do aluno é calculada da seguinte forma:

Nota Final = (Provas) * 0,20 + (Critério de Avaliação Individual) * 0,40 + (Nota individual Release 1) * 0,2 + (Nota individual Release 2) * 0,2

Os critérios estão detalhados nesse documento:

Para o aluno satisfazer os seguintes requisitos para obter a aprovação na disciplina:

  • Aprovação se MF >= 5,0 e se Percentual de faltas (PF) for

PF <= 25%. Onde PF é dado pelo número de aulas com faltas registradas dividido pelo número de aulas ministradas.

  • Reprovação se MF < 5,0 ou se PF > 25%. Nessa situação, o aluno será considerado reprovado por nota ou por falta.

Os critérios avaliados individualmente no projeto estão destacados na tabela abaixo:

Evento da Avaliação Individual no Projeto
Código/Entrega
Documentação
Coerência - Documentos e Código
Critério Extra
Histórias e Planejamento da Release
Testes Automatizados e Cobertura de Código > 90%
Tracking
Wiki Atualizada
Software Implantado e Disponível para Uso
PA - pareamento
PA - reunião de planejamento da sprint
PA - planning poker
PA - sprint time box
PA - participação nas dailies
PA - review com o cliente
PA - retrospectiva na sprint
PA - user stories
PA - risco sustentável de trabalho
PA - código escrito com padrões
PA - plano de comunicação
PA - comunicação técnica nas issues
PA - pull requests educativos
PA - práticas de comunidades de software livre

Avisos

  • Também são considerados critérios de avaliação da participação: assiduidade; pontualidade; interesse; participação em sala.
  • Os documentos referentes à disciplina estarão disponíveis em: https://github.com/fga-eps-mds/Qualifying-Software-Engineers-Undergraduates-in-DevOps
  • Os projetos são avaliados continuamente.
  • A cobertura de código deverá ser 90%, excetuando a camada de apresentação.
  • O tamanho dos times deve respeitar o limite máximo de 6 membros.
  • As atividades do projeto deverão ser organizadas por meio de issues e milestones.
  • O código-fonte e demais artefatos elaborados deverão ser revisados utilizando pull/merge requests e issues.
  • As provas não são pré agendadas.

Datas das Releases 1 e 2

Entregáveis R1 e R2 Nos slides

  • Release 1 (major) - 01 a 03 de Outubro de 2025.
  • Release 2 (major) - 03-05 de Dezembro de 2025.

Bibliografia Básica

  • (OPENACCESS) Rocha, Carla. Como Acelerar o Aprendizado e Disseminar a Cultura de Inovação Ágil - https://rochacarla.github.io/Onboarding/
  • Beck, K., Programação Extrema (XP) Explicada, 1st ed. Bookman, 2004
  • Ken Schwaber e Jeff Sutherland - O Guia Definitivo para o Scrum: As Regras do Jogo - Disponível em português em https://scrumguides.org
  • Sommerville, I., Engenharia de Software. 8th ed., Pearson Addison Wesley, 2007.
  • Engenharia de Software Moderna
  • Alves, Isaque, Rocha, Carla. Qualifying Software Engineers Undergraduates in DevOps - Challenges of introducing technical and non-technical concepts in a project-oriented course - http://arxiv.org/abs/2102.06662
  • Jacobson, I., Booch G., Rumbaugh J., The Unified Software Development Process, 1st ed., Addison-Wesley, 1999.
  • [EBRARY] Lano, K., UML 2 Semantics and Applications, 1st ed., Wiley, 2009.
  • OPENACCESS Scrum e XP direto da sTrincheiras

Bibliografia Complementar

  • Pfleeger, S. L., Engenharia de Software: Teoria e Prática. 2nd ed., Prentice Hall, 2004.
  • Pressman, R. S., Engenharia de Software. 6th ed., McGraw-Hill, 2006.
  • Ambler, S., Agile Modeling: Effective Practices for eXtreme Programming and the Unified Process, 1st ed., Wiley, 2002
  • Jacobson, I., Booch G., Rumbaugh J., UML: Guia do Usuário, 2nd ed., Elsevier, 2005.
  • [OPEN ACCESS] Scrum e XP direto das Trincheiras. (http://www.infoq.com/br/minibooks/scrum-xp-from-the-trenches)



Projetos 2025/2

Confira abaixo a lista de projetos que serão desenvolvidos ao longo do 1º semestre de 2025 na disciplina.

Tema do semestre:

📊 “Como posso usar dados para dar inteligência?”

Diferente de outros semestres, as equipes não poderão propor temas próprios. Em vez disso, cada equipe deverá selecionar três opções de projeto em ordem de preferência. A alocação será feita com base nessas escolhas.

Como fazer boas apresentações Dicas de slides - https://www.ime.usp.br/~kon/ResearchStudents/dicasSlides.html



  1. Querido diário - Radar das tecnologias na educação nos municípios

O Querido Diário inaugura uma gigantesca (e em constante expansão!) fonte de dados integrada sobre os diários oficiais municipais. Uma empreitada monumental tendo em vista não apenas a grande quantidade de municípios e de sites governamentais, mas também a variedade de formatos de diários oficiais, já que não existe nenhuma regulamentação que os padronize.

Quase metade das matrículas na educação básica pública no Brasil está nos municípios, mas é muito difícil encontrar informações sobre o dia a dia da gestão dessas redes. Por isso, os diários oficiais se tornam uma fonte preciosa de informação — quando não são as únicas.

O problema é ter uma plataforma que faça uma análise de atos públicos relacionados à adoção de tecnologias no contexto educacional. Eles fizeram um relatório sobre o tema, mas os dados são estáticos. E a ideia é fazer uma plataforma que mostre esses dados de forma dinâmica.

Restrição arquitetura: a solução deve ser composta só de frontend (gitpage) e os dados são atualizados periodicamente por meio de robôs que serão executados por meio de github actions. A análise qualitativa deve ser feita por meio de agentes de IA.

https://queridodiario.ok.org.br/educacao/relatorio/3

https://github.com/okfn-brasil/querido-diario-nas-universidades

  1. Querido diário - Radar das tecnologias de investimento de IA nos municípios

O Querido Diário inaugura uma gigantesca (e em constante expansão!) fonte de dados integrada sobre os diários oficiais municipais. Uma empreitada monumental tendo em vista não apenas a grande quantidade de municípios e de sites governamentais, mas também a variedade de formatos de diários oficiais, já que não existe nenhuma regulamentação que os padronize.

Quase metade das matrículas na educação básica pública no Brasil está nos municípios, mas é muito difícil encontrar informações sobre o dia a dia da gestão dessas redes. Por isso, os diários oficiais se tornam uma fonte preciosa de informação — quando não são as únicas.

O problema das Temáticas integram uma série de análises sobre tecnologias na Educação municipal, a partir dos atos publicados nos diários oficiais coletados pelo Querido Diário. Elas jogam luz sobre temas que foram identificados nos Panoramas, que, por sua vez, são análises periódicas que captam tendências, inovações e práticas recorrentes nas redes.

A Temática #2 trata sobre inteligência artificial (IA) nas escolas municipais, especialmente sobre o uso dessa tecnologia na gestão e ambiente escolar.

Restrição arquitetura: a solução deve ser composta só de frontend (gitpage) e os dados são atualizados periodicamente por meio de robôs que serão executados por meio de github actions. A análise qualitativa deve ser feita por meio de agentes de IA.

https://queridodiario.ok.org.br/educacao/relatorio/4

https://github.com/okfn-brasil/querido-diario-nas-universidades

  1. Querido diário - Radar de investimento de saúde oncológico nos municípios

O Querido Diário inaugura uma gigantesca (e em constante expansão!) fonte de dados integrada sobre os diários oficiais municipais. Uma empreitada monumental tendo em vista não apenas a grande quantidade de municípios e de sites governamentais, mas também a variedade de formatos de diários oficiais, já que não existe nenhuma regulamentação que os padronize.

O problema a ser resolvido é o investimento de saúde oncológico nos municipios a partir dos dados do querido diario.

https://queridodiario.ok.org.br

  1. Censo escolar

A partir dos microdados relacionados ao censo escolar que são disponibilizados anualmente, fazer um portal de dados do censo escola, da educação basica. Enriquecer os metadados da base dado e implementar um RAG (Retrieval-augmented generation), para que possa encontrar informações a partir de uma interface conversacional, além de um dashboard com as principais visualizações de dados do censo.

Fonte de dados

https://www.gov.br/inep/pt-br/acesso-a-informacao/dados-abertos/microdados/censo-escolar

  1. É fake - minerador de notícias o projeto é fake minera reportagem de mais de 90 jornais para detecação automatizada de fake news. O objetivo desse projeto é implementar a mineracao de pelo menos mais 2 jornais e fazer uma aplicação que use esses dados e permita que o usuário explore as noticias.

https://github.com/aosfatos/check-up

  1. Colaboração no github

A partir dos dados dos usuários de um determinado conjunto de organizações no github, fazer uma plataforma para visualizar a colaboração entre os membros e o tipo de colaboração.

Similar ao projeto abaixo, mas focado nas pessoas: https://githubnext.com/projects/repo-visualization/

https://www.inf.usi.ch/lanza/Downloads/Lung2022a.pdf

  1. Colaboração github - metricas

Evoluir esse projeto para organizações no github, além de repositórios. Usar agentes de ia para explicar caracteristicas de colaboração e o que significam as métricas. Tipos de métricas: qte de issues abertas/fechadas, qte commits, tecnologias, qte PR, qualidade de código.

https://githubnext.com/projects/repo-visualization/#explore-for-yourself

  1. Dados abertos UnB

por incrivel que pareça, não há um portal para visualição dos dados abertos da unb. é sua vez (ate pode filtrar pela fcte). Objetivo é organizar os dados abertos da unb e fazer um portal para visualizacao dos dados. Vamos ver com o que é gasto na fcte?

Restricao arquitetural: o portal soh deve ter front (githpage), o banco vai ser em json, e toda a mineração e processamento dos dados é feito por meio de bots executados no pipeline action do github.

projeto maravilhoso!

https://dados.gov.br/dados/organizacoes/visualizar/fundacao-universidade-de-brasilia-unb

  1. Portal dos professores

Minerar dados dos professores (lattes, google scholar, sigaa), e gerar resumos do portfolio e atuação de cada professor. Visualização facil ;) não é um ambiente para avaliar professores, mas sim ter uma visão geral do que fazem, se fazem pesquisa (ultimo artigo publicado), que matérias dão ao longo do tempo (dao as mesmas materias ou variam). Agente de ia para fazer analise qualitativa e resumo dos dados dos profs

Restricao arquitetural: o portal soh deve ter front (githpage), o banco vai ser em json, e toda a mineração e processamento dos dados é feito por meio de bots executados no pipeline action do github.

  1. Portal com guia para escrita tecnica em software

Um dos principais problemas em um projeto de software é a falta de documentação. A ideia é varrer um repositório e fazer recomendacoes de documentos necessarios para garantir a qualidade do produto de software. Usar agente de ia para classificar a documentacao de acordo com o checklist de escrita técnica. Também deve haver uma area com material guiado (com animacoes) do passo a passo para fazer uma boa documentacao tecnica

Restricao arquitetural: o portal soh deve ter front (githpage), o banco vai ser em json, e toda a mineração e processamento dos dados é feito por meio de bots executados no pipeline action do github.