|
|
Reuniões
Uma
breve pauta com assuntos a serem discutidos na reunião estará
sempre disponível antes da realização da mesma; assim,
os participantes ficam cientes do que será abordado, amadurecem
idéias e, a priori, pensam em questionamentos/sugestões
a respeito, melhorando-se a produtividade. Após realização,
o que foi decidido durante a reunião citada será registrado
e ficará disponível para que as pessoas externas possam
acompanhar as atribuições da fábrica.
|
Data
|
Pauta
|
Decisões
|
|
29/04
|
-
|
-
Reuniões periódicas com todos os membros às
terças-feiras
- Encontros virtuais na lista de discussão
- Divisão das tarefas para construção do plano
da fábrica de software
|
|
06/05
|
-
Alocação de pessoas aos papéis
- Demonstração de ferramenta MVCASE
|
- Alocação efetuada e exposta no documento de JobDescriptions
- Familizarização com ferramenta MVCASE
- Criação de uma home page para fábrica
|
|
12/05
|
-
Acompanhamento
|
-
Elaboração de pauta da reunião de 13/05
- Publicação de documentos internos através
do Twiki
- Pré-requisito para próxima reunião: estudo
e maior conhecimento da abordagem em Componentes e da ferramenta
MVCase
|
|
13/05
|
-
Dúvidas e discussões a respeito da abordagem/ferramenta
de Eduardo
- Os grupos que desempenham as funções da Fábrica
deverão validar/sugerir o material que será gerado
por cada função de acordo com as responsabilidades
definidas no Job Description
- Definição detalhada dos artefatos comerciais, gerenciais
e técnicos, elucidando as ferramentas que deverão
ser usadas e possíveis treinamentos
- Estabelecimento de prazos na produção do Cronograma
Piloto (mês 2) e refinamento para o mês 1
|
-
Definição de 2 novos momentos no ciclo de desenvolvimento
da metodologia (Planejamento/Gerenciamento e Testes/validação)
· Definição das ferramentas e treinamento de
acordo com os perfis: Desenvolvimento: Jbuilder, CVS, Bugzilla,
Oracle ou outro SGBD, dependendo do porte das demandas; Análise:
MVCASE; Gerencial: Project
· Definição dos artefatos para todas as fases
- ver detalhes em abordagem.doc
· Ratificação da coleta dos dados via formulário
de Eduardo, a fim de contabilizar e registrar horas e recursos necessários
|
|
20/05
|
-
Checklist do cronograma
- Dificuldades em unificar a documentação gerada.
Padronizar ações das pessoas.
- Unificação do material produzido: Plano da Fábrica
e Plano de Processo
- Organização dos textos produzidos para os documentos
citados acima em Templates; sistematizar as entregas das pessoas
- Ressaltar a data de entrega de documentos presencialmente e Home
Page bem apresentada e atualizada(26/05)
- Definições e produção de artefatos
para Analista de Qualidade e Avaliação Interna da
Fábrica; alocar responsáveis
- Dúvidas sobre ferramental/metodologia. Algum treinamento
para afinar as pessoas???
- Fase Anterior - venda - Breno responsável pelos artefatos
- Utilização do TimeSheet sugerido por Eduardo; definir
periodicidade de entrega
- Validação do texto sobre Plano de Projeto
|
-
Definição de tarefas para TODOS da equipe
- Uso do TWIKI por todos para envio de documentos e socialização
de descobertas, lista de discussões para avisos e comunicação
rápida
- Finalização da organização do material
em dois documentos: PLANO DA FÁBRICA e PLANO DE PROCESSO
- Padronização na estrutura dos textos das etapas
(Vendas /Gerenciam.Planejamento /Desenvolvimento /Testes) que foi
proposta por Carlos Júnior, assim:
1. FASE; 1.1. Introdução; 1.2. Responsáveis
e Artefatos; 1.3. Fluxo de Atividades
- Discussão em torno das métricas para os Índices
de Avaliação Interna da Fábrica
- Uso do TimeSheet por todos os participantes e com periodicidade
de entrega semanal nas reuniões das terças-feiras
para o Gerente de Projeto em papel
- Treinamento das equipes de Eng. SW e Eng. Testador entre si. Cada
equipe deve identificar as necessidades para a função;
e devem se organizar para os ambientes de trabalho
|
|
27/05
|
-
Checklist do cronograma definido na última reunião
(atividades x responsáveis)
- Uso do TWIKI por todos da equipe para envio de documentos e socialização
de descobertas - Agendar treinamento
- Revisão final da organização do material
em dois documentos: PLANO DA FÁBRICA e PLANO DE PROCESSO
- Padronização na estrutura dos textos a serem gerados
no mês 2
- Discussão dos parâmetros e métricas para os
Índices de Avaliação Interna da Fábrica
- Treinamento das equipes de Eng. SW e Eng. Testador entre si. Identificar
necessidades e organizar-se entre si para os ambientes de trabalho
- Montamos a Fábrica! E os artefatos das etapas, como estão?
Já temos templates? Vamos colocá-los no TWIKI para
que todos leiam e entendam toda a Fábrica III?
- Entrega do TimeSheet por todos
- Continuamos com dificuldades em unificar e acompanhar a documentação
e conhecimentos gerados. Padronizar ações!
- Definição de novo cronograma semanal e cronograma
para a RFP piloto com Estabelecimento de prazos (mês 2)
|
-
Ratificação do uso do TWIKI por todos
- Colocação por TODOS da equipe do Time Sheet semanal
no TWIKI, aos domingos. Os participantes devem criar um time sheet
por mês e colorir semanas do mês em questão conforme
template definido por Carlos Júnior
- Colocação dos Planos de processo e da Fábrica
da ETAPA 1 (montagem) no TWIKI
- Definição da ESTRUTURA MÍNIMA de software
necessária para aguardar o PILOTO. 1.JBuilder 2.CVS e WinCVS
3.Bugzilla 4.JUnit 5.MVCase 6.Project 2000. Luiz Eduardo irá
organizar um servidor. Após o PILOTO, poderemos definir outros
softwares, para complementar o ambiente.
- Discussão em torno dos parâmetros e métricas
para os Índices de Avaliação Interna da Fábrica.
No mês 1, a avaliação será com aspectos
qualitativos; e nas outras etapas (Piloto e RFP cliente), usaremos
aspectos quantitativos. Definiu-se o estudo de um paper a fim de
avaliar estatisticamente o progresso de projetos de sw(ver artigo
sobre métricas em Links interessantes)
- Definição das tarefas de conclusão dos templates
para Plano de Processo
- Aspectos qualitativos para Avaliação Interna da
Montagem da Fábrica (mês 1): 1.Assiduidade dos componentes
2.Cumprimento de prazos 3.Objetividade nas reuniões e ações
4.Socialização e gerenciamento do conhecimento 5.Iniciativa
e busca dos participantes 6.Compatibilização dos horários
dos participantes 7.Conhecimento sobre o conteúdo Fábrica
de SW 8.Maturidade do processo definido para a Fábrica 9.Definição
do escopo da Fábrica(sem conhecer RFP) 10.Difícil
interação com o cliente
- Interação dos participantes com os softwares que
fazem parte da estrutura mínima (todos checarem todas as
ferramentas)
- Cada equipe(Eng. SW e Eng. Testador) deve identificar as necessidades
para a função; e se organizar para os ambientes de
trabalho de acordo com a RFP Piloto
|
|
03/06
|
-
Cobrança de que TODOS tenham disponibilizado o timesheet
no TWIKI;
- Discussão sobre a RFP, fechar escopo;
- De acordo com o nosso processo de desenvolvimento, listar as tarefas
a serem realizadas, atribuindo responsáveis e datas limites(datas
apenas para as atividades iniciais, as demais serão fechadas
após
cálculo das estimativas);
- Discussão sobre geração de métricas
de progresso(artigo Inspector);
- Padronizar ações quanto a ajustes nos documentos
(quem incorpora as sugestões?)
- Como armazenar as versões dos documentos? Adotar revision
history?
- Acompanhar andamento de instalação da estrutura
básica de software(lembrar do requisito de ferramentas free!!!
Que banco adotar? Postgresql?)
- Definir demais tecnologias a serem utilizadas(jsp? Se sim, em
que servidor? Tomcat?)
- Elaborar apresentação para mesa de compra
|
-
TODOS deverão disponibilizar timesheet no TWIKI semanalmente,
tendo como tolerância máxima a terça-feira ao
meio dia.
- No projeto piloto, atacaremos as seguintes funcionalidades da
RFP: Inserção, atualização e remoção
isoladas de professor, disciplina, sala e horário; Inserção,
atualização e remoção do conjunto professor,
disciplina, sala e horário, atendendo a restrições
de não alocar mais de uma disciplina para mesma sala no mesmo
horário ou de alocar um professor para ministrar duas disciplinas
no mesmo horário; Gerar mapa de alocação contendo
professores/disciplinas/salas/horários, possibilitando ver
a ementa da disciplina; Verificar controle de concorrência.
- Cada alteração sugerida nos documentos deverá
ser avaliada e, se for o caso, incorporada pelo autor ao mesmo.
Para manter histórico, deverá ser preenchido o revision
history (modificações, quem as fez e quando) - Caso
o pessoal do suporte não disponibilize estrutura para utilização
do Bugzilla e CVS, adota-se o seguinte: Eduardo criará um
sistema de controle de erros e para "substituir" o CVS,
utilizaremos o TWIKI
- O banco de dados a ser utilizado será o Postgresql e as
tecnologias a serem adotadas: Java, JDBC e JSP - para servidor web
Tomcat.
- Utilizaremos o padrão de codificação da Sun,
o Java Code Conventions.
- A apresentação para mesa de compra será feita
por Breno, havendo uma prévia da mesma para que sejam feitas
críticas e sugestões.
- Mônica comandará a elaboração do documento
contendo como será feita a coleta de métricas de progresso(baseado
no Inspector) e métricas para avaliar a qualidade do produto
final e o processo seguido.
- Breno questionará a Jones como será a precificação
- Efetuaram-se atribuições de responsabilidades para
geração de artefatos da fase comercial e planejamento.
- Sugeriu-se a utilização do MSN Messenger e o ICQ
para comunicação entre os membros
- Criação de um WBS com macro atividades: Fase comercial:
1ª semana; Fase de planejamento/gerenciamento: 1ª a 5ª
semana; Fase de desenvolvimento de componentes: 2ª a 4ª
semana; Fase de testes e validação: 5ª semana
|
|
10/06
|
-
Alocar atividade de atualização do plano da fábrica
de acordo com a RFP e incluir mudanças sugeridas por Eduardo
- Decidir como será apresentado, para o cliente, os artefatos
gerados através da MVCASE
- Discutir as métricas de progresso, produto e processo
- Cobrar utilização do revision history
- Revisar plano de processo, incorporando sugestões de Taci
e comentários de Joa
- Elaborar cronograma detalhado(WBS final)
- Verificar instalação da estrutura básica
de software
- Equipes devem se organizar para suprir as necessidades de treinamento
dos membros
- Cobrar timesheets
|
-
O documento do plano da fábrica deverá ser atualizado
de acordo com a RFP.
- Os digramas gerados pelo MVCASE terão as telas capturadas
e isso irá gerar um documento denominado "projeto de
componentes".
- Serão utilizadas apenas as três primeiras fases do
Inspector para o acompanhamento e controle da fábrica. Inicialmente,
no piloto, a avaliação do progresso das atividades
será feita semanalmente. Quando a fábrica estiver
em produção, a avaliação será
feita quinzenalmente.
- O documento de definição das métricas de
avaliação da fábrica passará a ser denominado
avaliação PPP (Progresso Processo Produto) e terá
como referência o Inspector.
- Além do histórico de modificações
nos documentos, deve existir a figura de um aprovador (que será
o primeiro autor do documento), que irá validar e incorporar
as sugestões de alteração nos documentos.
- Os criadores dos templates deverão incorporar o revision
history nos mesmos
- O plano de processo será revisado pelos autores das respectivas
partes, avaliando-se os comentários de Jones, Taciana e Vivianne
- Clarissa ira falar com André Santos para acompanhar a instalação
dos softwares.
- Definição do cronograma de trabalho
|
|
17/06
|
-
Avaliação PPP
- Acompanhamento e controle da equipe
- Estrutura mínima para desenvolvimento e testes
- Sistematização das equipes para treinamentos necessários
- Apresentação da WBS cronológica para que
todos saibam prazos e deadlines
- Feedback dos líderes com relação ao andamento
das equipes (indicar melhorias?)
- Sinalização de como será "o pulo do
gato" da Fábrica III, pois apesar de organizada, não
está evidenciado um GRANDE DIFERENCIAL DE MERCADO
|
-
Fábio colocou que o inspector faz a avaliação
do progresso. A avaliação do produto será feita
com base no Relatório de Testes e no Plano de Avaliação
da Fábrica. Taciana está desenvolvendo um template
para armazenar os resultados da avaliação do processo.
- Os participantes da reunião chegaram à conclusão
de que o cronograma de atividades está sendo cumprido. No
que diz respeito à equipe de Analistas de Sistemas, foi colocado
que alguns dos requisitos não funcionais presentes no tamplate
do Documento de Requisitos não foram colocados no documento
Proposta Técnica. Foi decidido que apenas os requisitos que
foram colocados na proposta técnica estariam presentes do
Documento de Requisitos do SI Alocação.
- Foi colocado por Luiz Eduardo que, devido às dificuldades
encontradas na configuração do servidor de aplicações
da Fábrica III, o mesmo ainda não estava pronto para
o uso. Este servidor deverá estar pronto ser utilizado na
quarta-feira (18/06) às 18:00.
- A equipe de Engenheiros de Testes deverá se reunir na quarta-feira
(26/06) às 9:00 para identificar as deficiências dos
membros dessa equipe e decidir quais treinamentos devem ser realizados.
As equipes de Analistas de Sistema e Engenheiros de Software já
iniciaram as suas atividades para execução do piloto.
- Vanessa irá enviar a apresentação do WBS
na quarta-feira (18/06) por e-mail para todos os membros da fábrica.
- Foi identificada a necessidade de se definir um líder para
a Equipe de Analistas. Todos membros desta equipe foram considerados
elegíveis ao cargo e participaram da votação.
Luiz Eduardo foi eleito o líder da equipe por três
votos a um.
- Todos os membros da equipe deverão estudar e pensar num
possível diferencial tecnológico para a Fábrica
III e apresentar esse possível diferencial na próxima
reunião.
- Foi colocado pela equipe de Analistas de Sistemas que a ferramenta
MVCase, por não implementar as operações de
copiar e colar e também por não possibilitar que a
modelagem de um sistema seja feita em vários arquivos separados
e depois composta em um único arquivo, impossibilita que
a fase de projeto de componentes seja realizada de forma distribuída
pelos membros da equipe de analistas de sistemas. Ficou decidido
que a ferramenta Rational Rose será utilizada doravante para
o desenvolvimento dos diagramas UML do projeto de componentes. A
ferramenta MVCase será utilizada para importar os digramas
desenvolvidos no Rational Rose e posterior geração
de código.
- Devido ao feriado, a próxima reunião da Fábrica
III será realizada no dia 26/06/2003 às 19:00 no antigo
C.E.S.A.R.
|
|
25/06
|
-
Problema no TWIKI
- Acompanhamento das equipes
- Definir "pulo do gato" da fábrica 3
- Fechar documento de Avaliação PPP
- Verificar decisões referentes a estrutura mínima
de testes
- Questionar necessidade de treinamentos
- Verificar WBS
|
-
Luiz Eduardo contactará o pessoal para providenciar a solução
dos problemas no TWIKI.
- Fábio ficou responsável por finalizar o documento
Avaliação PPP.
- Haverá reunião da equipe de testes para divisão
de tarefas e discussão das pendências restantes, tais
como: ferramenta a ser utilizada para testes de integração.
- A equipe de engenheiros de software deverá entregar todos
os testes de unidade automatizados para que os engenheiros de testes
os executem e verifiquem o funcionamento dos mesmos. Além
disso, estes últimos deverão realizar testes de integração
entre os componentes e gerar um relatório com tudo o que
foi observado durante ambas as execuções.
- As equipes se organizarão internamente para suprir necessidades
de treinamento dos membros.
- Convencionou-se que para próxima RFP a equipe de análise
deverá entregar para os engenheiros de software classes contendo
as assinaturas dos métodos, juntamente com os respectivos
comentários.
- Definição da estratégia para tentar dar o
"pulo do gato" .
- Luiz Eduardo deverá finalizar instalação
de CVS, como também do Bugzilla; caso contrário, Taciana
deverá criar uma lista exclusiva para reportar bugs.
- Coleta de informações a respeito do andamento do
projeto, definindo novas datas para realização de
algumas tarefas.
- Luiz Eduardo deverá repassar todos os artefatos produzidos
pelos analistas de sistemas(requisitos + .mdl) para que Vivianne
disponibilize os mesmos na home page da fábrica.
|
|
01/07
|
-
Analisar WBS
- Estabelecer política para utilização do Formulário
de Solicitação de Mudanças
- Verificar adequação do Formulário de Solicitação
de Mudanças para os bugs
- Acompanhar cronograma: problema no TWIKI, avaliação
PPP, atividades das equipes
- Questionar sobre diagramas de interação aos analistas
de sistemas
- Explicitar as tarefas do Analista de Qualidade
- Alocar novas datas para requisito 7
- Nome do sistema
|
-
Devido ao grande detalhamento do WBS, os gerentes de projeto estavam
tendo dificuldades para controlar quais atividades estavam sendo
executadas no prazo estipulado. Assim, caberá aos líderes
de equipe acompanhar quais atividades da sua equipe estão
cumprindo o cronograma previsto no WBS e informar o status periodicamente
aos gerentes de projetos; em caso de atraso, os líderes devem
informar um novo prazo para a referida atividade. Os gerentes de
projeto se encarregarão apenas de acompanhar o andamento
das macro-atividades.
- Membros da Fábrica 3 devem solicitar mudanças nos
projetos através do Formulário de Solicitação
de Mudanças, que deve ser enviado pelo solicitante a todos
os membros da fábrica através da lista. Ao receber
uma solicitação de mudança, o Analista de Qualidade
irá aprovar ou não a solicitação e,
uma vez aprovada, cadastrá-la no Formulário de Gerenciamento
de Mudanças. É também dever do Analista de
Qualidade realizar auditorias para acompanhar o andamento da execução
das mudanças.
- Luiz Eduardo colocou que não conseguiu instalar o Bugzila
devido a problemas encontrados durante a compilação
do mesmo. Ficou decidido que Taciana ficaria responsável
por criar uma lista, bem como definir um template para reportagem
de bugs. Os bugs reportados serão cadastrados no Formulário
de Gerenciamento de Mudanças pelo Analista de Qualidade.
- Luiz Eduardo afirmou que o problema no TWIKI se devia ao estouro
da quota de arquivos estabelecida. Foi decidido que, daqui por diante,
os arquivos da Fábrica 3 serão disponibilizados na
área pública de uma conta que será criada no
CIN. Serão colocados no TWIKI apenas os links para esses
arquivos.
- Fábio afirmou que o template para a Avaliação
PPP estava quase concluído e que estaria disponibilizando-o
através lista.
- Vanessa alertou para a necessidade de alguém mais experiente
na equipe de Engenheiros de Testes. Ficou decidido que Carlos Andreazza
deixa de ser Analista de Sistemas e passa a ser Engenheiro de Testes.
Para os próximos projetos da fábrica, Taciana passará
de Analista de Qualidade a Analista de Sistemas.
- Ficou decidido que não serão criados novos requisitos
para o SIAlocação. Os requisitos 5 e 6 serão
modificados de forma a permitir que todas as operações
relativas à alocação (realização,
consulta, alteração e remoção) sejam
realizadas diretamente no mapa de alocação, facilitando
a interação do usuário com o sistema.
· Ficou decidido que o sistema será chamado SIAlocacao.
Os documentos Proposta Comercial, Proposta Técnica e Documento
de Requisitos devem ser alterados de forma a retratar essa modificação.
Clarissa será responsável por essas alterações
após o recebimento das solicitações de mudanças
a serem enviados por Taciana.
|
|
28/07
|
-
|
-
Horário semanal -> engenheiros de software
|
|
Seg
|
Ter
|
Qua
|
Qui
|
Sex
|
| 08-10 |
Todos
|
|
Cara,
Clari,
Fábio, Luiz,
Vivi
|
|
|
| 10-12 |
Todos
|
|
Clari,
Luiz
|
|
Cara,
Vivi
|
| 19-21 |
|
|
|
Carlos,
Fábio,
Taci
|
|
| 21-23 |
|
|
|
Carlos,
Taci
|
|
|
|