Gerência de Processos

COPIN - Bimestre Junho/Julho 2004

Conteúdo

Professor

Alunos

Ementa

Programa

Plano de Atividades

Bibliografia

Notas de Aulas

Artigos

Avaliação

URLs Adicionais

Professor: Francilene Procópio Garcia [Volta para Conteúdo]

E-mail para todos os participantes

Alunos [Volta para Conteúdo]

Aluno	Notas (Prova, Sem, Doc) / Média Ponderada	Artigos Sugeridos	Seminário
Afrânio Mangueira	8,0 8,0 8,5 / 8,2	Driving Force 1	Tema A
Cecir Almeida farias	5,0 7,5 8,5 / 7,0	Driving Force 1	Tema F
Daniel Aguiar	8,5 7,5 8,5 / 8,2	Driving Force 1	Tema F
Danilo Ferreira	8,5 8,0 8,5 / 8,3	Driving Force 2	Tema D
Ecivaldo Matos	8,0 8,0 8,5 / 8,2	Driving Force 2	Tema A
Elthon Oliveira	7,0 8,5 9,0 / 8,2	Driving Force 3 – Até pg 8	Tema E
Emanuela Cartaxo	7,0 7,5 8,5 / 7,7	Key XPM Concepts (rules 1-4)	Tema F
Fábio Luiz Leite	8,0 8,0 8,5 / 8,2	Key XPM Concepts (rules 1-4)	Tema D
Flávio Ronison	8,5 8,5 8,5 / 8,5	Key XPM Concepts (rules 1-4)	Tema C
Gustavo Mendes	7,5 8,5 8,5 / 8,2	Key XPM Concepts (rules 5-7)	Tema C
Jailton Cruz	4,0 8,5 9,0 / 7,2	Key XPM Concepts (rules 5-7)	Tema B
Nelson Nóbrega	7,5 8,5 9,0 / 8,3	Key XPM Concepts (rules 8-11)	Tema B
Rogério Silva Jr.	8,5 8,5 9,0 / 8,7	Key XPM Concepts (rules 8-11)	Tema E
Verlaynne	7,5 8,5 9,0 / 8,3		Tema B

Questões para trabalhar sobre e-Project:

Esquema Aqui.

Temas dos Seminários:

1. Construção de uma metodologia para desenvolvimento de SI, em ambientes turbulentos. Baseado em SCRUM (http://www.controlchaos.com/) Aqui mais material.
2. Construção de uma metodologia Just-in-time, centrada em pessoas. Baseado no método Crystal. “Whatever your project's situation with respect to the sweet spots that enable light methodologies, in the end, you have no choice: you will have to discover your own best, local way of working. It is unlikely that any methodology written in a book will suit your project straight out of the box. You can find your own efficient way of working by working in increments, watching for where invention and communication are insufficient or have hit diminishing returns for your project, identifying where you are with respect to the sweet spots, and being inventive about how to get your process barely sufficient. Then you will have your own, appropriate just-light-enough methodology -- “Just-in-time methodology construction” e “Selecting a project's methodology”. (http://crystalmethodologies.org/ ) Aqui mais material.
3. Como analisar ROI em TI? Quais implicações das técnicas de cálculo de ROI sobre o processo de desenvolvimento? Aqui mais material.
4. Desenvolver software aberto é muito diferente? Como gerenciar equipes virtuais e gerar bons resultados?
5. Construção de uma metodologia para desenvolvimento de software embarcado em dispositivos móveis.Aqui material.
6. Práticas para “Análise de Risco”. O que deve ser pensado e praticado para minimizar os riscos em projetos de software?

Ementa [Volta para Conteúdo]

Motivação. Problema complexo. Processo de software. Gestão de projeto. Riscos vs. Benefícios. Métricas de software.

Programa [Volta para Conteúdo]

1. Problemas: gerenciando sua complexidade

1. Problemas simples vs. complexos

2. Gestão processo de software: onde estamos?

3. Adaptação vs. otimização

4. Problemas complicados vs. complexos

5. Ciclos de vida

6. Ciclo adaptativo

2. Processo de software

1. Fatores críticos

2. Contexto do negócio

3. Medindo o esforço

4. Grau de inovação

5. Tipo de Aplicação vs. Tipo de desenvolvimento

6. Problemas vs. causas

7. Complexidade técnica vs. gerencial

8. Abordagens para implantação

3. Gestão de projetos

1. Engenharia vs. Produção

2. Ciclo de vida

3. Planejamento iterativo e interativo

a. Escalonamento do esforço

b. Estimativas

c. Iterações

4. Artefatos

5. Arquitetura

6. Atividades chaves

7. Pontos de controle (custo, tempo, qualidade e escopo)

4. Riscos e Benefícios

1. Gestão de riscos: Fatores críticos

2. Custos: Diretos e Indiretos

3. Viabilidade do negócio: Medição do TCO

5. Métricas de software

1. Métricas chaves

2. Métricas OO

3. Análise do produto

Plano de Atividades [Volta para Conteúdo]

Data	Atividades
	Apresentação da disciplina e sua URL: http://www.dsc.ufpb.br/~garcia/cursos/ger_processos/index.htm Parte I: · Problemas: Gerenciando sua complexidade [slides]
08/06	Motivação [artigo] [chaos_report98] [estudos chaos rep] [questões]
15-17-22/06	Parte II: Processo de software [Artigo] [slides]
01 / 07	Trabalhar as questões sobre Artigo e-Project. Esquema Aqui.
22/07	Parte II: Processo de software [Artigo]
22/07	Parte II: Processo de software [slides]
27/07	Parte III: Gestão de projetos [slides] [slides]
29/07	Parte IV: Riscos e Benefícios [slides]
3/08	Parte IV: Riscos e Benefícios [artigo] + Dinâmica Artigo
5/08	Artigo para discussão [artigo]
10/08	Parte V: Métricas de software [slides] [artigo]
12/08	Seminário – Tema A
12/08	Seminário – Tema D
17/08	Seminário – Tema B
17/08	Seminário – Tema C
19/08	Seminário – Tema E
19/08	Seminário – Tema F
20/08	Avaliação escrita

Bibliografia [Volta para Conteúdo]

· Software Project Management: A Unified Framework. Walker Royce. Addison Wesley, 1998.

· Software Engineering: Project Management. Richard H. Thayer. IEEE Computer Society, 1997.

· Managing the Software Process. Watts Humphrey. Addison Wesley, 1989.

· Practical Software Metrics for Project Management and Process Improvement. Robert Grady. Prentice Hall, 1992.

· Controlling Software Development. Lawrence H. Putnam and Ware Myers. IEEE Computer Society, 1996.

· Software Engineering Risk Management. Dale Karolak. IEEE Computer Society, 1996.

· Artigos diversos.

Notas de Aulas [Volta para Conteúdo]

Disponíveis em http://www.dsc.ufpb.br/~garcia/cursos/ger_processos/notas/

Artigos [Volta para Conteúdo]

Disponíveis em http://www.dsc.ufpb.br/~garcia/cursos/ger_processos/artigos/

Material dos Seminários [Volta para Conteúdo]

Tema A

Tema D

Tema E

Tema F

Avaliação [Volta para Conteúdo]

A avaliação será feita através da realização de seminários individuais e de uma prova final.

URLs Adicionais [Volta para Conteúdo]

1. Um método que tem atraído muita atenção é o XP - eXtreme Programming, difundido por Kent Beck. As raízes deste método vêm da comunidade Smalltalk. XP procura colocar em prátrica quatro valores: comunicação, feedback, simplicidade e coragem. Links: http://www.xprogramming.com/; http://www.extremeprogramming.org/; www.egroups.com/group/extremeprogramming

1. A Família Crystal. Alistar acredita que diferentes projetos de software requerem diferentes tipos de metodologias. De forma que ele sugere a família Crystal - um conjunto de abordagens centradas nas pessoas, explorando ao máximo as iterações e suas revisões. Link: members.aol.com/acockburn

1. Código Aberto. "Open Source" trata-se hoje de um estilo de software - não deve ser confundido com um processo. Porém, existem condutas diferenciadas para se gerenciar tarefas numa comunidades destas e, muitas destas condutas são aplicadas também em projetos que não visam o código aberto. Em particular, códigos abertos são gerados por equipes distribuídas geograficamente, e os testes são concorrentes, onde muitas pessoas enviam dicas de como os criadores podem achar e eliminar bugs. Links: www.tuxedo.org/~esr/writings/cathedral-bazaar

1. Desenvolvimento Adaptativo. Este tipo de metodologia, apresentada no livro de Jim Highsmith - Adaptive Software Development (Dorset House, 1999), não oferece uma prática detalhada como XP, mas sugere uma base fundamental sobre a importância de se tratar desenvolvimento de software na forma de processos adaptativos.

1. Scrum. Este método apresenta uma conduta que busca pela estabilização dos requisitos através de uma subdivisão do projeto em "sprints" de 30 dias cada. Cada sprint deve definir uma dada funcionalidade que deve ser obtida em 30 dias. Todo o processo deve apresentar um planejamento iterativo. Links: http://www.controlchaos.com/ e jeffsutherland.com/scrum/index.html.

1. Desenvolvimento Orientado à Funcionalidade. (Feature Driven Development) FDD foi desenvolvido já a algum tempo por Peter Coad, guro de OO. Como outras metodologias adaptativas, foca na entrega de pequenas iterações com a presença de alguma funcionalidade tangível - em geral, ocorrem ao longo de duas semanas. FDD apresenta cinco processos: três deles (desenvolver um modelo, construir uma lista de funcionalidades e planejar cada uma delas) são realizados no início de cada projeto. Os dois últimos (projeto d ecada funcionalidade e sua construção) são completados dentro de cada iteração. Mais informações: Coad's Java Modeling in Color with UML (Prentice Hall, 1999).

1. Outros métodos são discutidos/apresentados em vários papers sobre "light methods". Links: www.bell-labs.com/cgi-user/OrgPatterns/OrgPatterns e www.computer.org/software/so2000/s4toc.htm