Implantao de Processos de Desenvolvimento de Software aspectos

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

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

BACKGROUND Fonte: http: //www. snoopy. com.

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)

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

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 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)

CONCEITO DE PROJETO DE SOFTWARE engenharia e gerenciamento se comunicam

ENGENHARIA DE SOFTWARE O velho problema dos requisitos. . .

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

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. . .

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

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

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

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

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

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

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

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

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)

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

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.

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

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

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

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)

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)

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

BIBLIOGRAFIA PHILLIPS, J. PMP Project Management Professional study guide. Emeryville: Mc. Graw-Hill, 2004. WOLTON, D. If faut sauver la communication. Revista FAMECOS, Porto Alegre, n. 27, p. 15 -17, ago. 2005. Disponível em: <http: //www. pucrs. br/famecos/pos/revfamecos/27/27_dominiquewolton. pdf>. Acesso em: 17 nov. 2006.

OBRIGADO Johnny Virgil johnnyvirgilbr@gmail. com