Implantação de Processos de Desenvolvimento de Software

Apresentação em tema: "Implantação de Processos de Desenvolvimento de Software"— Transcrição da apresentação:

1 Implantação de Processos de Desenvolvimento de Software
aspectos gerenciais Johnny Virgil

2 SUMÁRIO BACKGROUND META 1: CONCEITO DE PROJETO DE SOFTWARE META 2: ENGENHARIA DE SOFTWARE META 3: GERENCIAMENTO DE PROJETOS DE SOFTWARE BIBLIOGRAFIA

3 BACKGROUND Fonte:

4 CONCEITO DE PROJETO DE SOFTWARE
O conjunto de atividades de trabalho, ambas técnicas e gerenciais, necessárias para satisfazer os termos e condições de um acordo de projeto. Um projeto de software deve ter datas específicas para iniciar e terminar, objetivos e restrições bem definidas, responsabilidades estabelecidas, um orçamento e um cronograma. Um projeto de software pode existir por si só ou pode ser parte de um projeto maior. Em alguns casos, um projeto de software pode abarcar apenas uma parte do ciclo de desenvolvimento de software. Em outros casos, um projeto de software pode durar vários anos e consistir de inúmeros subprojetos, cada qual sendo, por si só, um projeto de software bem definido. (IEEE, 1998, p. 2, tradução nossa)

5 atividades gerenciais ► gerenciamento de projetos
CONCEITO DE PROJETO DE SOFTWARE atividades gerenciais ► gerenciamento de projetos engenharia de software ◄ atividades técnicas

6 CONCEITO DE PROJETO DE SOFTWARE
Um projeto de software tem duas dimensões principais: a engenharia e o gerenciamento de projetos. A dimensão da engenharia trata da construção do sistema e foca tópicos tais como como implementar, testar, codificar, e assim por diante. A dimensão do gerenciamento de projetos trata de planejar e controlar adequadamente as atividades de engenharia para satisfazer os objetivos do projeto em relação a custos, cronograma e qualidade. (JALOTE, 2002, tradução nossa)

7 CONCEITO DE PROJETO DE SOFTWARE
engenharia e gerenciamento se comunicam

8 O velho problema dos requisitos...
ENGENHARIA DE SOFTWARE O velho problema dos requisitos...

9 ENGENHARIA DE SOFTWARE
Como o cliente explicou o que queria... ...os clientes não têm conhecimento do jargão técnico. fluxos de dados, protótipos, casos de uso...

10 ENGENHARIA DE SOFTWARE
Como o líder do projeto entendeu... ...o pessoal técnico tem dificuldade de compreender o jargão do cliente. consultores de produto, generalistas...

11 ENGENHARIA DE SOFTWARE
Como o analista projetou... ...os analistas têm tendência artística. excesso de esmero, desprezo pela programação

12 ENGENHARIA DE SOFTWARE
Como o programador codificou... ...os programadores se preocupam apenas com a tecnologia. despreocupação com o negócio, visão centrada no código

13 ENGENHARIA DE SOFTWARE
Como o consultor de negócio descreveu... ...os consultores de negócio teorizam. falta de vínculo com a parte técnica

14 ENGENHARIA DE SOFTWARE
Como o projeto foi documentado... ...existe uma aversão intrínseca à documentação. esquecimento de que existe um usuário, subestimação das dificuldades, falta de padrões

15 ENGENHARIA DE SOFTWARE
O que o assistente técnico instalou... ...os assistentes técnicos têm a tendência de resolver os problemas por si mesmos. subestimação dos detalhes, proativismo

16 ENGENHARIA DE SOFTWARE
Como o cliente foi cobrado... ...o cliente é cobrado sem uma relação concreta com o que foi feito. a tecnologia como força estratégica

17 ENGENHARIA DE SOFTWARE
Como foi dada a manutenção no sistema... ...criar é mais fácil que dar manutenção. desprezo pela manutenção, desinteresse pela evolução compatível

18 ENGENHARIA DE SOFTWARE
O que o cliente queria... ...as coisas mais simples podem ser mal entendidas. duvidar sempre da simplicidade dos pedidos

19 ENGENHARIA DE SOFTWARE
“uma das maneiras de dominar a comunicação é tornar conscientes, tanto para aqueles que falam quanto para aqueles que recebem, as categorias de emissão e recepção” (BOURDIEU, 1992, p. 38, tradução nossa)

20 GERENCIAMENTO DE PROJETOS DE SOFTWARE
Idéias Coisas Pessoas FIGURA 1 – A tríade do gerenciamento de projetos Fonte: Adaptado de Balzert (1998).

21 Por que criar um processo formal para gerenciamento de projetos
GERENCIAMENTO DE PROJETOS DE SOFTWARE Por que criar um processo formal para gerenciamento de projetos de software? ... para criar um processo que melhora o processo já existente na empresa (empresas não se recriam; transformam-se) ... para criar registros monitoráveis ... para planejar, executar e finalizar Projeto de Bentham de 1791.

22 GERENCIAMENTO DE PROJETOS DE SOFTWARE
Aspectos Gerenciais (1 de 3) 1 Idéias Pensamento conceitual Planejamento Análise de problemas

23 GERENCIAMENTO DE PROJETOS DE SOFTWARE
Aspectos Gerenciais (2 de 3) 2 Coisas Administração Organização Tomada de decisões

24 GERENCIAMENTO DE PROJETOS DE SOFTWARE
Aspectos Gerenciais (3 de 3) 3 Pessoas Liderança Recrutamento Gerenciamento Controle Comunicação

25 GERENCIAMENTO DE PROJETOS DE SOFTWARE
Comunicar, nos dias de hoje, não é somente transmitir uma informação, é também levar em conta o receptor. A informação é fundamental, mas não há informação sem liberdade de consciência e de expressão. Mas a comunicação permanece o mais complicado, pois ela obriga uma apropriação. A comunicação é, todavia, a relação entre um emissor, uma mensagem e um receptor. Comunicar não é apenas produzir e distribuir a informação, é também estar sensível às condições nas quais o receptor a recebe, aceita, recusa, remodela em função de suas escolhas filosóficas, políticas, culturais. A comunicação trata do receptor. (WOLTON, 2005, p. 16, grifo nosso, tradução nossa)

26 (PHILLIPS, 2004, tradução nossa)
GERENCIAMENTO DE PROJETOS DE SOFTWARE Qual é habilidade mais importante que um gerente de projeto tem? A comunicação. Gerentes de projeto gastam por volta de noventa por cento do seu tempo comunicando. Pense sobre isto: reuniões, chamadas telefônicas, memorandos, mensagens eletrônicas, relatórios, apresentações, e a lista segue. Gerentes de projeto gastam a maior parte do seu dia comunicando notícias, idéias e conhecimento. Um gerente de projetos é um comunicador. (PHILLIPS, 2004, tradução nossa)

27 BIBLIOGRAFIA BALZERT, H. Lehrbuch der Software-Technik. Heidelberg: Spektrum, v. 2. BOURDIEU, P. Thinking about limits. Theory, Culture & Society, London, v. 9, n. 1, p , 1992. IEEE. IEEE Std : IEEE standard for software project management plans. New York, 1998a. JALOTE, P. Software project management in practice. Boston: Addison-Wesley, 2002.

28 BIBLIOGRAFIA PHILLIPS, J. PMP Project Management Professional study guide. Emeryville: McGraw-Hill, 2004. WOLTON, D. If faut sauver la communication. Revista FAMECOS, Porto Alegre, n. 27, p , ago Disponível em: < Acesso em: 17 nov

29 OBRIGADO Johnny Virgil