Projeto em Computação II

Período 2003.2

Prof. Jacques Sauvé

Aulas: segunda-feira 16-18 e quinta-feira 14-16, sala RE08

Notas dos alunos

Lista de discussão

Mail dos clientes: mail dos clientes: castro@pacto4.com.br, vitruvio@dsc.ufcg.edu.br, joseana@dsc.ufcg.edu.br, baptista@dsc.ufcg.edu.br, fubica@dsc.ufcg.edu.br, nazareno@dsc.ufcg.edu.br, elizeu@dsc.ufcg.edu.br, vicenteuol@uol.com.br, carlos-galvao@uol.com.br, ulrich@dsc.ufcg.edu.br, eliane@dsc.ufcg.edu.br, danielps@dsc.ufcg.edu.br, carolina@dsc.ufcg.edu.br

Objetivos da disciplina

As disciplinas de Projeto em Computação (I e II) têm como objetivos familiarizar o aluno com o desenvolvimento de software relativamente grande que exija a utilização de um processo de desenvolvimento. É também objetivo das disciplinas familiarizar o aluno com técnicas de gerência de projetos de desenvolvimento. Busca-se uma aproximação do desenvolvimento completo de um produto real de software, desde sua concepção até sua implantação, ou alternativamente, busca-se uma aproximação de atividades reais de desenvolvimento em que um produto existente sofre manutenção e evolução.

Ementa da disciplina

Desenvolvimento de um projeto prático em computação sob orientação de um professor. Definição do problema. Análise de requisitos. Estudo de viabilidade. Análise do domínio do problema. Projeto arquitetural. Projeto de baixo nível. Implementação. Testes. Cronograma de execução. Proposta de bibliografia. Produção de relatórios de acompanhamento sobre o trabalho.

[O Professor da disciplina acrescenta ainda: definição do processo de desenvolvimento, considerações de implantação, técnicas de acompanhamento de projeto].

Participantes

O que faremos na primeira aula

• Explicar o modus operandi da disciplina
• Explicar quem é gerente e quando (em qual iteração). Usar mesa-redonda na ordem alfabética de nome
• Explicar datas das iterações
• Explicar o que deve entrar na home page
• Explicar a forma de avaliação dos alunos
• Revisão do que cada time está fazendo, como andam as coisas, quem é o cliente, quais foram as dificuldades, como remediar, ...
• Tirar dúvidas sobre XP1
• Falar do programa xp1pm

O que faremos na segunda aula

• Aula de Test-Driven Programming

O que faremos em outras aulas

• Cada equipe que deve participar da aula deve fazer sua reunião de acompanhamento, liderada pelo gerente de desenvolvimento
• Quando o planejamento estiver pronto, chamar o professor para discussão rápida
• O professor avalia a home page do projeto onde constam os artefatos de acompanhamento
• O professor pode executar o sistema, rodar os testes de unidade e de aceitação. Deve ser possível fazer isso em sala de aula, pela rede.
• O professor dá uma nota ao gerente
• O professor dá uma nota à equipe
• Cada aluno se avalia em termos e esforço e capacidade de planejar e cumprir o planejado para a última iteração
• Cada aluno avalia o gerente no cumprimento de suas atribuições
• Cada gerente avalia os membros do time em termos e esforço e capacidade de planejar para a última iteração

O que faremos na última aula

• Avaliação da última iteração, normalmente
• Demo do sistema final
• Discussão do que o relatório final deve conter
  • Ver o que deve ter no relatório final aqui
  • Data de entrega
  • O código fonte do projeto deve ser entregue (se não houver problema legal) para produção de um CD da disciplina. A entrega deve ser via mail para o professor da disciplina (indicando um link para download, se for grande).

Modus Operandi da Disciplina

• O processo de desenvolvimento adotado é XP1. Se você não quiser usar XP1, fale comigo. Quero ver seu processo.
• Cada pessoa do grupo será "gerente de desenvolvimento" durante uma iteração. A ordem dos gerentes segue a ordem alfabética dos nomes (completos) dos alunos, de forma circular.
• Há uma iteração a cada 2 semanas. Iterações são de tempo fixo. O botão de escopo podem ser manipulado, mas não o botão de tempo.
• A primeira iteração é de 1 semana e serve para levantar os User Stories e fazer o plano de releases. Todas as demais iterações são de 2 semanas.
• As reuniões de acompanhamento semanal de cada time devem ocorrer durante as aulas da disciplina. Metade das equipes (a turma Yin) terá reunião de acompanhamento durante a primeira aula da semana e metade das equipes (a turma Yang) na segunda aula da semana. Iterações iniciam e terminam nessas reuniões de acomanhamento (a cada 2 reuniões). Ao planejar, cuidado com feriados!
  • Datas de final de iteração dos times (Yin na primeira aula da semana, Yang na segunda aula)
    • 17/11: plano de releases
    • 01/12: iteração 1
    • 15/12: iteração 2
    • 16/02: iteração 3
    • 01/03: iteração 4
    • 15/3: iteração 5
    • 29/3: iteração 6
    • 12/4: iteração 7
  • Para quem quer fazer mestrado e quer terminar antes do fim de fevereiro, as datas de final de iterações são um pouco diferentes. As datas abaixo são do início da semana. A data exata é segunda ou quinta dependendo do grupo.
    • 1/12: iteração 1
    • 15/12: iteração 2
    • 5/1: iteração 3 (iteração curta devido ao Natal)
    • 19/1: iteração 4
    • 2/2: iteração 5
    • 16/2: iteração 6
    • 23/2: iteração 7 (iteração curta porque sou uma mãe)
• O relatório final deve ser entregue dia 19/4, via e-mail. 5% de penalidade por dia de atraso.
• O professor vai participar de todas as reuniões de acompanhamento.
• Antes de chegar à reunião de acompanhamento, o gerente deve ter certeza que a home page da disciplina esteja atualizada.

A Home Page

A home page não tem que ser bonita mas tem que conter o que precisa e ser fácil navegar. Eu preciso ver o seguinte:

• Título do Projeto
• Nomes e mail dos membros da equipe
• Nome e mail do cliente
• Breve descrição do projeto, com ênfase no business case
• Um link para User Stories
• Um link para o Plano de releases
• Um link para a Tabela de planejamento e de progresso, incluindo o que segue. Podem usar XPlanner.
  • Identificação da tarefa (a descrição das Tarefas pode estar em outra tabela para manter os dados normalizados)
  • Estimativa de tempo em horas
  • Pessoa responsável pela realização da tarefa
  • Número de horas já empregadas na tarefa
  • Estimativa do percentual da tarefa já concluído
  • Quem fez o Test Review
• Um link para o Big Chart

A Home Page tem que estar atualizada antes de cada reunião com o Professor.

Forma de avaliação dos alunos

• A avaliação será de acordo com a tabela abaixo.
• Lembre que é obrigatório assistir as aulas pois é aí que vamos discutir a situação de cada projeto e recolher as notas que os alunos dão uns aos outros. Não aceito receber notas por email. Tem que aparecer nas aulas.

Seu trabalho

• Estude bem o processo que você vai usar. Todo mundo tem que entender o processo bem.
• Defina bem como o processo é gerenciado. No caso de XP1, a informação está aqui.
• Desempenhar seu papel de gerente
• Desempenhar seu papel de desenvolvedor
• Defina alguns aspectos operacionais do processo:
  • Como gerar o Big Chart
  • Como/onde será feita a integração (em que máquina? como evitar duas integrações simultâneas?)
• Planejar o semestre (o que será feito, milestones, qual o cronograma)
  • Coloque isso imediatamente na home page pois examinaremos isso na segunda semana de aula
  • Se você não sabe como fazer isso, veja o planejamento de release de XP1
• Do it!
  • Faça as iterações
  • No cumprimento de um milestone (um release), marquem uma demo comigo
  • Não deixem de atualizar a home page a semanalmente com toda a informação descrita acima
• No final do semestre, me entregar uma cópia completa (zipada) de tudo que você fez, incluindo código, home page, documentos, artefatos, relatório final.

O que se espera dos alunos

• Aceitar responsabilidades em quantidade aproximadamente igual entre os alunos da equipe
• Manter a home page do projeto
• Participar de todas as reuniões de acompanhamento da equipe
• Participar de todas as reuniões de acompanhamento da disciplina
• Liderar a equipe de desenvolvimento quando for sua vez
• Participar da elaboração do relatório final

O que se espera do gerente

• Dedicar pelo menos 2 ou 3 horas por semana pensando na gerência do projeto, mesmo que você tenha outras atribuições de programador
  • As horas que você "perde" fazendo isso se compensam facilmente pelo controle que você vai obter sobre o desenvolvimento
  • Se não fizer isso, o projeto se torna frouxo e vai demorar mais tempo para ser terminado
• Ter certeza que cada pessoa do time tenha tarefas alocadas
• Conversar com cada membro do time, pelo menos 1 vez por dia sobre o andamento das tarefas. Bastam alguns minutos
• Manter o Big Chart e a tabela de acompanhamento atualizados
• Identificar problemas com o cumprimento dos milestones o mais rapidamente possível e bolar planos de recuperação
• Liderar a reunião semanal de acompanhamento (1 hora, no máximo)
• Manter a home page do projeto atualizada
• Ver detalhes no processo XP1

Informação importante para o aluno

• Nesta disciplina, quero que você aprenda a usar e controlar o processo
• Quero ver progresso ocorrendo, não cessariamente muito software sendo desenvolvido
• A produtividade (fazer muito) é menos importante do que fazer o que está sendo feito de forma controlada
• Portanto: não prometa tanto e cumpra o prometido
  • Claro que no mundo real, temos que ter agressividade ao elaborar cronogramas
  • Nesta disciplina, podemos ter promessas mais simples de cumprir
• Porém, quero ver progresso toda semana, o que significa constância no trabalho

O trabalho do professor da disciplina

• Dar aulas iniciais sobre gerência de desenvolvimento
  • Aula sobre processo de desenvolvimento, acompanhamento, cronogramas, riscos, etc.
• Fazer a avaliação contínua dos alunos
  • Com exceção da avaliação do relatório final, avalio olhando sua home page. e durante as reuniões em sala de aula
  • A home page não tem que ser bonita mas tem que conter o que precisa e ser fácil navegar

O que se espera do professor da disciplina

• Ajudar os alunos na elaboração de um processo de desenvolvimento
• Ajudar nas reuniões de acompanhamento
• Disponibilizar pelo menos 6 horas por semana para que os alunos possam contactar o professor
• Ajudar a disponibilizar laboratório para execução do projeto. A máquina "diabinho" com Linux está disponível para desenvolvimento.
• Assegurar-se, periodicamente, que esteja havendo progresso no projeto
• Participar das reuniões de acompanhamento da disciplina
• Assistir as apresentações finais das equipes
• Preencher o formulário final de avaliação

O que se espera dos orientadores de projetos

Prezado orientador,

Tentei manter suas obrigações a um nível mínimo. O mais importante é que você sirva de cliente (ou facilite o acesso ao mesmo).

Se você discordar de suas atribuições, favor me contatar imediatamente.

• Atribuições obrigatórias:
  • Assegurar-se que o objetivo do projeto de desenvolvimento esteja claramente definido
  • Assumir a posição de cliente ou fazer com que um cliente seja claramente identificado
    • O cliente define a funcionalidade a ser implementada
    • O cliente verifica o cumprimento da qualidade do resultado (funcionalidade, defeitos, prazo)
  • Facilitar o acesso ao cliente, se você não for o cliente
  • Definir como será o acompanhamento dado à equipe por você
    • Disponibilizar pelo menos 1 hora por semana para que os alunos possam contatá-lo
    • Cuidado! O processo XP1 pode exigir mais disponibilidade (embora talvez não exija mais tempo)
  • Assegurar-se, periodicamente, que esteja havendo progresso no projeto (veja como fazer isso aqui)
  • Assistir às apresentações finais das equipes
  • Preencher o formulário final de avaliação, algumas vezes durante a disciplina
• Atribuições opcionais
  • Ajudar os alunos na elaboração de um processo de desenvolvimento (o professor da disciplina poderá ajudar)
  • Ajudar nas primeiras reuniões de acompanhamento até se certificar que os alunos possam assumir a liderança (o professor da disciplina poderá ajudar)
  • Ajudar a disponibilizar laboratório para a execução do projeto (o professor da disciplina poderá ajudar)
  • Assegurar-se que os alunos dediquem tempo suficiente à disciplina

Mail a enviar para os clientes no início do semestre

Caros,
Você está recebendo este mail por ser "cliente" de alguma equipe da disciplina de Projeto 2.
Eu gostaria de lembrar aos clientes que:
- Todas as equipes adotaram processos de desenvolvimento semelhantes que fazem certas exigências ao cliente.
- Detalhes do papel do cliente podem ser obtidos aqui (http://jacques.dsc.ufcg.edu.br/projetos/common/xp1/xp1.html)
- O processo XP1 define um papel claro para o cliente. Você deve estar familiarizado com este papel, para maximizar as chances de sucesso de sua equipe. No link acima, leia o que você precisa assumir como responsabilidade. Se não conseguir assumi-la por algum motivo, avise sua equipe e a mim para que possamos providenciar uma alteração no processo de desenvolvimento.
- Em particular, o cliente deve elaborar "User Stories" e confeccionar "testes de aceitação".
Às vezes, temos clientes que não preparam bons testes de aceitação e depois reclamam que o software sendo desenvolvido não atende suas necessidades.
Claro que isso vai acontecer! Sem testes de aceitação bem pensados, você não receberá um bom software.
- Como cliente, você *não* precisa acompanhar o uso correto do processo de desenvolvimento por sua equipe. Como professor da disciplina, eu farei isso.
- Sua equipe tem reunião semanal de acompanhamento. Sua participação na reunião será bem-vinda.

Links importantes

• O processo de desenvolvimento XP1

Acesso a laboratórios

Fale com seu professor orientador e/ou com o professor da disciplina.

Alerta final!

Tirem backup de tudo, freqüentemente! Não venham chorar porque perderam artefatos!! Se você usar anjinho como repositório CVS, o backup é garantido!

The Planning Game