Olá leitores

Hoje em dia, existem muitas pequenas empresas de tecnologia ( entenda como software, hardware, mídia digital etc. ) e departamentos de TI, onde princípios de um bom gerenciamento técnico de suas “atividades” são completamente deixados de lado.

O fluxo de trabalho de empresas pequenas ou departamentos de T.I. geralmente não estão relacionadas à projetos ( temporais - inicio - meio - fim ), e sim manutenções constantes em projetos que surgiram apenas de uma idéia e em seguida ja sua implementação, tornando-se Franksteins . Existem exceções sem dúvida, e essas conseguem destaque diante das outras que possuem processos mal definidos em relação ao desenvolvimento de seus produtos ou serviços.

Uma empresa de tecnologia de pequeno porte ou um departamento de TI, não precisa necessariamente seguir todas as etapas do PMBOK para realizar seus projetos, mas podem extrair algumas para melhorar muito esse cenário.

Já cansei de ouvir colegas de profissão dizer que a empresa em que trabalha não possui sequer uma documentação decente em relação aos sistemas existentes, muitos deles na verdade afirmam que não existem nenhuma documentação, controle, processo de qualidade,etc. Resumindo, esses departamentos ou empresas são fabricas de Xarxixo, que criam “profissionais” que acham que para desenvolver um software ou sistema , basta sentar o rabo na cadeira e começar a programar. Para isso que existe metodologias de desenvolvimento.

Papeis são completamente ignorados nessas entidades. O analista de sistemas é obrigado muitas vezes a trocar bolinha de mouse. Isso não existe quando metodologias são incorporadas à empresa. No RUP, o analista de sistemas não desenvolve, o analista de negócios não faz analise do sistema, o desenvolvedor não faz análise do sistema nem de negócio.

O conhecimento do negócio nessa visão, fica na mão do analista/programador/servecafézinho, que é aquele sujeito que desenvolveu tudo sozinho, sem nenhuma documentação e que quando resolver sair da empresa, da uma bela preocupação para o empregador, pois esta na cabeça desse sujeito todas as regras do sistema e POG�s ( programação orientada a gambiarra ).

Quem se da mal nisso tudo é o seu sucessor, que é obrigado a desvendar os misteriosos algoritmos para fazer algo funcionar corretamente, e que muitas vezes, chega à conclusão de que é mais fácil apagar tudo e refazer do que “dar manutenção”. Mas existem soluções para se evitar isso, como o RUP.

O RUP é apoiado e utilizado por empresas reconhecidas e embora a sua aplicação seja trabalhosa, vale a pena pela organização, maior facilidade de manutenção/integração de novos módulos e rastreabilidade.

O workflow no cenário RUP inicia-se no analista de negócios. É ele é quem realiza o levantamento das necessidades do cliente e transforma essas necessidades em casos de uso de negocio.

Define também uma lista de requisitos e as classifica. A partir deste ponto esses requisitos passam para o analista de sistemas para a definição de escopo do sistema e etc.

Vamos focar no papel “analista de negócios”, mas especificamente no levantamento de requisitos do sistema, pois caso essa etapa seja feita de forma errada, é possível que o restante também seja (se o analista de sistemas e gerente do projeto forem umas topeiras e não enxergarem o erro).

Existem diversas formas de classificar os requisitos. O RUP define-as como Funcional e Não Funcional.

Um requisito funcional descreve as funcionalidades de um sistema não levando em consideração restrições físicas, e um requisito não funcional o contrário.

Exemplo:
Um cliente X precisa de um software que cadastre os seus empregados.
No caso de uso - cadastrar cliente.
Tipo de requisito - Funcional

Para este software que cadastra o cliente funcionar, será necessário um 486 com 32mb de RAM
No caso de uso - Não é possível a descrição
Tipo de requisito - Não Funcional

Os requisitos não funcionais não podem ser descritos com casos de uso. Em alguns casos isso é possível, mas especificamente para isso, o RUP dispõe da “especificação suplementar”, que é aonde requisitos não funcionais podem ser detalhados utilizando as classificações abaixo descritas, também conhecidas como FURPS (acrônimo):

• Funcionalidade
• Usabilidade
• Confiabilidade
• Desempenho
• Suportabilidade

Abaixo segue o link onde cada tópico desse pode ser descrito com maiores detalhes.

http://www.wthreex.com/rup/process/workflow/requirem/co_req.htm

Um simples levantamento de requisitos já pode ajudar em muito na documentação e na garantia de que o sistema não perderá o seu foco. Ajuda a evitar o que aconteceu na ilustração abaixo

[ ] ‘ sss

| | | | | | | | | | | | |

Hoje vou comentar um pouco sobre escopo e integração em projetos. Essas duas atividades são extremamente importantes para o sucesso de um bom projeto.

Vamos lá…

Integração

A  área   de   integração  na   gestão   de   projetos,   esta   diretamente relacionada à parte de levantamento de requisitos de um projeto e é utilizado no momento em que processos individuais precisam interagir entre si.

Por   isso,  no  inicio do projeto,  é  importante o gerente detalhar como será o desenvolvimento do mesmo e a sua  integração. É preciso definir   como   as   partes   irão   se   relacionar,   e   em  que   pontos   serão aplicados   maiores   esforços   de   forma   que   o   resultado   final   seja alcançado com sucesso.

Cabe ao gerente do projeto administrar possíveis mudanças, ser capaz de resolver conflitos e gerenciar fatores externos que venham a influenciar   o   andamento   do   projeto,   sempre   procurando  manter   os processos do projeto  integrados.  Esta etapa da gerencia de projetos define alguns produtos como descrito abaixo:

• Termo de abertura do projeto. (Autorização formal para o inicio)
• Declaração   preliminar   do   escopo   do   projeto.   (O   que   será abordado   ou   não   no   projeto.  Declaração   do   escopo   em  nível macro)
• Plano para o gerenciamento do projeto. (Documentação das ações que deverão ser tomadas para a execução do projeto como um todo)
• Controle de mudanças. (Gerenciar mudanças no projeto)
• Controle do trabalho do projeto. (Controle dos processos usados para iniciar, planejar, executar e encerrar o projeto)
• Encerramento do projeto.  (Finalização de todos os processos do projeto, finalização formal do projeto)

Também garante a  integração com elementos externos normais da empresa, caso haja.

Em suma, gerencia de integração é importante para garantir que todas   as   etapas   e   elementos   de   um  projeto   estejam  integrados   e coordenados.

Escopo

Como descrito no Guia PmBok¹,   resumidamente,  a gerencia de escopo é importante para garantir que todos os processos que fazem parte do projeto estejam  incluídos,  e  somente eles,  para  terminar  o projeto com sucesso, ou seja, descreve o que o projeto irá entregar e o que não irá entregar.

Nesta etapa é realizado o planejamento do escopo, definição do escopo, criação da EAP (ou WBS), verificação do escopo e controle do escopo. A EAP é acompanhada de um dicionário que a descreve. Todos os processos desta etapa interagem com outras áreas de conhecimento  abordadas no projeto.

Na   engenharia   de   software,   por   exemplo,   existe   a  UML,   que descreve de forma bastante objetiva o escopo de um sistema através do diagrama de casos de uso, ou use case, aonde é descrito como os atores interagem com partes do sistema, fazendo esses, parte da definição do escopo do projeto em questão.

Grande parte dos projetos que fracassam, é porque a equipe não investiu tempo suficiente definindo o projeto e/ou houve uma falha no momento da definição e gerenciamento de escopo.

Tomando este fato como base, fica evidente a importância de um bom gerenciamento de escopo em um projeto, seja ele de qual natureza for.

EAP ( Estrutura Analítica do Projeto )

Uma EAP é uma visão do escopo através de um diagrama. Nele é possível visualizar os produtos que serão entregues e seus pacotes de trabalho ( detalhamento de baixo nível ).

Exemplificando com uma estrutura genérica,  um deliverable  (ou entrega)  pode ser  dividido em pacotes de  trabalho.  Estes pacotes de trabalho   podem  ser   divididos   em  atividades,   e   posteriormente   em tarefas.

Para isso, é preciso identificar as entregas do 1º e 2º nível. Após isso é possível identificar com maior facilidade as tarefas, aumentando o grau de especificação.  Quanto maior o grau de detalhamento da EAP, maior será a confiabilidade das informações.

Este grau de detalhamento pode ser  feito dividindo as entregas em departamentos, ciclos de vida do projeto ou linha do tempo.

Para   cada  método   de   separação,   seria   feito   um  refinamento partindo como base a forma escolhida e sucessivamente, detalhando o projeto através de ramificações no diagrama.

Abaixo um exemplo de EAP para uma entrega.  Tem como base uma construção civil.

Este seria um exemplo de representação de um pacote de trabalho apenas, o da estrutura.

Em projetos grandes essa estrutura aumenta muito, por isso temos diversos softwares que nos auxiliam na criação da EAP, como o MSProject por exemplo.

[ ] ’ss

 1-Guia PMBOK – Um guia do conjunto de conhecimentos em gerenciamento de projetos – Terceira  edição

| | | | | | | | | | | | |

Olá amigos

Hoje irei iniciar uma série de artigos sobre Gestão de Projetos e Projetos de Software. Antes de qualquer coisa, é necessário entendermos alguns conceitos básicos de gerência de projetos e de software. Um projeto de software pode ser desenvolvido focado na metodologia RUP, PMBOK ou ambas.

Aqui cito uma breve descrição do que é a metodologia RUP, extraído da Wikipedia:

“O RUP, abreviação de Rational Unified Process (ou Processo Unificado da Rational), é um processo proprietário de Engenharia de software criado pela Rational Software Corporation, adquirida pela IBM, ganhando um novo nome IRUP que agora é uma abreviação de IBM Rational Unified Process e tornando-se uma brand na área de Software, fornecendo técnicas a serem seguidas pelos membros da equipe de desenvolvimento de software com o objetivo de aumentar a sua produtividade.”

As disciplinas do RUP são:

· Modelagem de Negócios

· Requisitos

· Análise e Design

· Implementação

· Teste

· Implantação

· Ambiente

· Gerenciamento de Projeto

· Gerenciamento de Configuração e Mudança

Essa metodologia sugere um fluxo de trabalho, aonde todas essas disciplinas seguem uma seqüencia, de forma a se alcançar os objetivos finais que são prazos respeitados, qualidade do software e cliente satisfeito.

Já o PMBOK (Project Management Body of Knowledge) é o conjunto de conhecimentos, ou disciplinas do PMI. O PMI
é a maior instituição sem fins lucrativos de gerência de projetos. Uma pequena descrição retirada da Wikipedia logo abaixo:

“Estabelecido em 1969 e situado nos arredores da Filadélfia, Pensilvânia, Estados Unidos, o Project Management Institute (PMI) – Instituto de Gerenciamento de Projeto– foi fundado por cinco voluntários. A comunidade americana da Pensilvânia emitiu artigos de empresas para PMI que resultaram na concretização oficial da organização. Durante aquele mesmo ano, o primeiro Simpósio e Seminário PMI foi realizado em Atlanta, Geórgia, Estados Unidos, obtendo uma audiência de 83 pessoas.”

Desde aquela época, o PMI cresceu muito e tornou-se uma referência em relação a metodologias e boas práticas para Gerência de Projetos.

Existem outras instituições de Gerencia de Projetos que valem a pena ser citadas, como o “Project Management Association of Japan“ (PMAJ – Instituição japonesa de GP) e a “Association for Project Management” , sendo essa ultima bastante utilizada na Europa.

Todas elas possuem seus BOK’s para gerencia de projeto.

No PMBOK ,são nove as disciplinas descritas:

· Gerência de integração de projetos

· Gerência de escopo de projetos

· Gerência de tempo de projetos

· Gerência de custo de projetos

· Gerência de qualidade de projetos

· Gerência de recursos humanos de projetos

· Gerência de comunicações de projetos

· Gerência de riscos de projetos

· Gerência de aquisições de projetos

Em um projeto de software, essas disciplinas do PMBOK podem ser associadas às do RUP, quando necessário, pois uma pode complementar a outra.

No próximo artigo irei abordar alguns pontos interessantes de como a Gerência de Integração, Gerência de escopo de Projeto, Modelagem de Negócios e Requisitos podem trabalhar juntos.

| | | | | | | | | | | | |