Escola Regional de Informática - 2006Bandeirantes - Paraná

Título: Gerência de Projetos de Sofware

Autoras:Profa Dra. Elisa Hatsue Moriya Huzita – emhuzita@din.uem.brProfa. Dra. Tania Fatima Calvi Tait – tait@din.uem.br

Universidade Estadual de Maringá Departamento de InformáticaGrupo de Estudos em Engenharia de Software Distribuído

1

Capítulo 4 – Gerência de Projetos de Sofware

4.1 – Visão da Gerência de Projetos

A gerência de projetos como disciplina surgiu na década de 50, principalmente na indústria de construção. Segundo Cleland & Ireland (2002), mais recentemente a gerência de projetos pode ser encontrada na área de materiais bélicos e desenvolvimento de sistemas.Entretanto, a gerência de projetos pode ser encontrada em vários projetos idealizados e concretizados ao longo da História, apoiada em conceitos como início, desenvolvimento e fim do projeto; custos; cronograma de execução; desempenho; e as funções da administração (planejar, organizar, motivar, controlar e liderar).Por várias décadas, a administração forneceu as bases para a gerência de projetos pautada nas suas funções clássicas, até o momento em que os estudos comprovaram a existência de outras atividades, por exemplo, disseminação da informação e apoio aos funcionários, realizadas pelos gerentes, as quais extrapolam as atividades puramente técnicas .Este mini-curso tem por objetivo apresentar uma visão geral da gerência de projetos (GP) tratando dos principais conceitos da área de GP bem como de elementos considerados relevantes para que o gerente de projetos possa planejar, acompanhar os projetos e tomar decisões. Para tanto, aqui são trazidas informações atualizadas sobre o papel do gerente enquanto líder até questões técnicas.

4.1.1. O papel do gerente de projetos na visão de líder

O gerente de projetos deve atuar como um líder do projeto e não apenas como um gerente. Essa forma de atuação implica em mudanças de comportamento por parte do gerente de projetos, as quais vão ao encontro da visão atual sobre a liderança de projetos. Líder não é aquele que “chicoteia”, mas aquele que exerce o papel de motivador, no qual cada pessoa envolvida no trabalho desenvolve as atividades como parte integrante do projeto.A liderança e seus aspectos, se aprendida ou é nata ao ser humano, são temas amplamente discutidos nas áreas de administração e psicologia.O que se deve ter em mente é que a diferença entre um gerente de projetos e um líder está na forma de atuação, enquanto o primeiro se preocupa basicamente com questões técnicas e imediatas, o segundo se preocupa com a abrangência do projeto, com as pessoas envolvidas (desde desenvolvedores até clientes) e realmente vivencia o projeto.Estudos (Laudon & Laudon, 2004) têm demonstrado que os gerentes não exercitam apenas as funções clássicas da administração (planejar, organizar, controlar, controlar), mas que essas funções são limitantes para descrever tudo o que os gerentes realizam. Mintszberg in Laudon & Laudon (2004), classifica as atividades gerenciais em 3 grandes atividades: papéis interpessoais, papéis informativos e papéis decisórios. Os papéis interpessoais são marcados pela representação externa que o gerente realiza, pelo contato com funcionários, na motivação e apoio. Atua como um canal de ligação na organização. No papel informativo, o gerente é disseminador de informação e porta-voz da organização. No papel decisório, toma decisões, aloca pessoal, distribui recursos, negocia e faz a mediação nos conflitos.

2

O processo decisório pode ser facilitado para o gerente de projeto se os sistemas de informação da empresa fornecerem informações adequadas e em tempo hábil. Para tanto já existem sistemas de informação em nível executivo, sendo desenvolvidos de acordo com o perfil dos tomadores de decisão. Exemplos de tais sistemas podem ser encontrados na área de saúde pública cujas informações geradas possibilitam a tomada de decisão com respeito à políticas públicas a serem implementadas.

4.1.2. Gerência de projetos e o desenvolvimento de software

O gerenciamento de um projeto é o processo de tomar decisões que envolvem o uso de recursos, tanto materiais como humanos, para realizar atividades, temporárias, com o objetivo de fornecer um resultado. A essência do gerenciamento de um projeto é o planejamento e a execução das atividades de seu ciclo de vida. Com isso, almeja-se que ao término do projeto, um produto de qualidade seja fornecido.Um gerenciamento de projetos atua em duas frentes: planejamento e controle de projetos.No planejamento de projetos faz-se necessário a adoção de medidas que visem possibilitar a execução adequada dos projetos. Para tanto, elementos como a alocação de pessoas; gerenciamento de riscos, a utilização de métricas e o gerenciamento de custos são preocupações do gerente de projetos. No tocante ao controle, as atividades especificadas no planejamento devem ser monitoradas para que o projeto alcance os objetivos estabelecidos quer seja em termos de funcionalidade como de qualidade.A produção (ou construção) de software é um empreendimento complexo e por si só se configura como um projeto uma vez que pode-se estabelecer um início e um fim programados, antes de ser colocado em execução, o que o insere no contexto de gerenciamento de projetos. O atual panorama de desenvolvimento de software envolve projetos cada vez mais complexos e prazos de entrega cada vez menores. Constantes requisições para redução de custos também são feitas, e o desenvolvimento pode, muitas vezes, ser realizado por corporações geograficamente distribuídas, o que implica no envolvimento de pessoas que cooperem, para que se possam atingir as metas estabelecidas. Neste caso, a complexidade da tarefa de planejamento aumenta e o controle exercido deve ser realizado tanto local como globalmente. Portanto, manter o controle sobre a produção do software e coordenar equipes tornam-se tarefas extremamente importantes e complexas. Planejar e organizar as atividades, controlar e verificar se as atividades estão sendo executadas de acordo com o planejado, dentre outros, são elementos importantes no gerenciamento de projeto e desmerecê-los pode contribuir para o fracasso dos projetos.No desenvolvimento de software, as atividades podem ser divididas em técnicas e organizacionais. As atividades técnicas envolvem desde as metodologias de desenvolvimento utilizadas até a infra-estrutura de rede adotada para a comunicação. As atividades organizacionais vão desde o atendimento às necessidades da organização, estabelecida em sua missão até o relacionamento com os recursos humanos envolvidos.A existência da parte técnica e organizacional mostra a complexidade de fatores com os quais o gerente de projetos de software deve estar envolvido para o sucesso do projeto, tanto na estimativa de custos como na mediação de conflitos.

3

Desta forma, a gerência de projetos de software, é uma área que engloba, além do planejamento e controle citados, a estimativa de esforço humano utilizado, os custos do projeto, a medição de software e o gerenciamento de riscos. Não se pode deixar de citar a relevância do cronograma do projeto, cujo gerenciamento contribui para o bom acompanhamento da execução das atividades previstas no projeto bem como para o cumprimento dos prazos estabelecidos.Note que para que o gerenciamento de projetos seja efetivo, o gerente de projetos não deve se esquecer que: (i) o desenvolvimento de software é um empreendimento intensamente humano; (ii) deve sempre encorajar uma comunicação ampla com o cliente para minimizar o risco de construir uma solução elegante para o problema errado; (iii) deve utilizar um processo adequado, empregando métodos e ferramentas de forma competente; e (iv) deve planejar e organizar o projeto de modo a levar a equipe ao sucesso (Pressman, 2002).

4.1.3. Estimativas em projetos de software

A gerência de projetos engloba a atividade de planejamento que consiste em realizar estimativas de custos nos projetos. Ao estabelecer as atividades do projeto a serem realizadas, deve-se estimar, também, o esforço, recursos e tempo necessários para o desenvolvimento do projeto. A estimativa possui riscos inerentes e ela pode ser realizada com maior grau de certeza quanto mais experiência se tem, quanto maior é o acesso às informações históricas e quanto maior for o empenho em efetuar previsões quantitativas mesmo que se tenha apenas dados qualitativos. As estimativas devem tentar definir cenários correspondentes ao melhor e ao pior casos, de modo que o comportamento do projeto possa ser delimitado. Muitas vezes, é interessante que ao invés de estimar o projeto como um todo o mesmo seja decomposto em partes menores e assim facilitar o gerenciamento dos mesmos. No tocante a recursos, é interessante que se inclua, além dos recursos humanos necessários, também recursos de ambiente e de projeto. Este último encontra um grande apoio na reutilização de componentes de software.A precisão da estimativa de um projeto de software depende de alguns fatores: (i) o grau com que o planejador (gerente) estimou adequadamente o tamanho do produto a ser construído; (ii) a aptidão para traduzir a estimativa de tamanho em esforço humano, tempo transcorrido e dinheiro ( em função da disponibilidade de métricas confiáveis de projetos anteriores); (iii) o grau com que o plano de projeto reflete a capacidade da equipe de projeto e (iv) a estabilidade dos requisitos do produto e do ambiente que apoia o esforço de engenharia de software (Pressman, 2002). Para Cleland & Ireland (2002), gerenciar custos em projetos requer uma abordagem disciplinada quanto à estimativa, ao orçamento e ao controle das despesas. O processo se inicia na fase de planejamento, entretanto os custos devem ser monitorados durante o desenvolvimento do projeto, para aplicação de ações corretivas, caso seja necessário.Várias técnicas são apresentadas para auxiliar na estimativa de custos, entre elas, destaca-se o COCOMO II (Sommerville, 2003) inclusive com ferramentas automatizadas para elaborar a estimativa.Entretanto, independente da técnica ou ferramenta utilizada, é necessário estabelecer o esforço humano, o tempo gasto e o custo necessário para realizar uma atividade.Especificamente, na área de desenvolvimento de software, onde ocorre a combinação da área técnica e organizacional, torna-se fundamental estabelecer estimativas de custos tanto nos itens de hardware como de software.

4

Sommerville (2003) nos apresenta os custos que devem ser estimados pelo gerente de projeto de software:

Custos de hardware e software; Custos de viagem e treinamento; Custos relativos ao esforço humano empregado.

Cada um destes 3 tipos de custos apresenta elementos que devem ser considerados como, por exemplo, a manutenção do software, a necessidade de material de apoio (ferramentas adicionais, livros etc), a comunicação, o pessoal de apoio, entre outros.No tocante ao esforço humano envolvido algumas medidas indicam como realizar a estimativa. A medida utilizada inicialmente foi a contagem de linhas de código.A contagem do número de unidades produzidas dividida pelo número de pessoas-hora, bastante utilizada, não considera aspectos relevantes como complexidade do software e as várias soluções que podem ser adotadas para seu desenvolvimento. Mesmo com as duas formas de medidas mais comumente utilizadas, como as medidas relacionadas ao tamanho e as relacionadas as funções, a medida da produtividade do engenheiro de software não é tão simples de se estimar. Nas medidas relacionadas ao tamanho, usa-se a contagem de linhas de código produzidas ou o número de instruções de código, as quais podem ser modificadas devido à complexidade do software a ser desenvolvido. As medidas relacionadas às funções se preocupam com a funcionalidade geral do software e mostra as operações de entrada e saída, interação com usuário, interfaces internas e arquivos. Para se chegar ao valor final, o desenvolvedor deve ainda fazer um ajuste nos valores de acordo com um conjunto de 14 perguntas cujas respostas são ponderadas de 0 a 5 e que têm o objetivo de efetuar os ajustes necessários, considerando-se a complexidade associada ao projeto sendo desenvolvido. Na linha de estimativa de custo e esforço têm-se os modelos COCOMO II e Putnam (Pressman, 2002; Sommerville, 2003), ambos se preocupam com a realização de cálculos que fornecem estimativas ao longo da existência do projeto de software. Um resumo dos tipos de estimativas pode ser visualizado na tabela 4.1 abaixo.

5

Tabela 4.1. Resumo dos Tipos de Estimativas. Estimativa Linhas de Código

(LOC)*Pontos por Função* Estimativa

de EsforçoCOCOMO Modelo de

PutnamBaseada em

Contagem de linhas de código

Pontos por função para o cálculo das estimativas de custo e esforço

Esforço humano -pessoas por período de tempo

Classe de projeto de software

Projeto de desenvolvimento de software

Fórmula Esforço = total de LOC/produtividade em LOC (pessoas-mês)

Esforço = Total de FP da função/produtividade em FP por pessoas –mês

Pessoas necessárias para realizar a tarefa com base na experiência do gerente

* verificar detalhamento abaixo

K = L**3/Ck**3 td**4), onde L = linhas de código; Ck = constante que indica o estado da tecnologia presente que reflete as restrições de throughput que dificultam o desenvolvimento;Td = tempo em anos.Total custo = pessoas-ano

* LOC e Pontos por função são utilizadas para medição de software

O desenvolvimento da área de software mostrou que utilizar apenas estimativas por linhas de código se torna insuficiente, uma vez que a estimativa de custos se torna uma tarefa complexa na medida em que envolve vários fatores que podem fugir ao controle do gerenciamento do projeto, pois conforme afirma Sommerville (2003): “A estimativa de preço do software precisa levar em conta considerações mais amplas sobre questões organizacionais, econômicas, políticas e de negócios”.Na seqüência é apresentada uma visão do modelo COCOMO II, considerado um dos modelos mais utilizados na atualidade.

O Modelo COCOMO II

O Modelo COCOMO (Constructive Cost Model) foi desenvolvido por Barry Boehm para estimar custos. O seu aperfeiçoamento levou a existência de algumas versões e a uma ferramenta disponível na Internet. A versão mais recente trabalha com 3 níveis , considerando elementos como prototipação, componentes e Linguagens de 4ª. Geração. Os níveis são: nível inicial de prototipação; nível inicial de projeto e nível pós-arquitetura. O nível inicial de prototipação é baseado em uma estimativa de pontos de objeto considerado, que é dividida por um número-padrão para a produtividade estimada, conforme consta na Tabela 2. Segundo Sommerville (2003) a produtividade do programador depende de sua experiência e capacitação das ferramentas CASE para apoiar o desenvolvimento. A fórmula final para o cálculo do esforço é:

PM=(NOP x (1 - % reuso/100))/PRODOnde, PM (person-month) = esforço medido em pessoas por mês;

6

NOP (Number of object points) = número de pontos de objetoPROD = produtividade, conforme mostra a tabela 4.2, abaixo

Tabela 4.2.ProdutividadeExperiência e capacitação do desenvolvedor

Muito baixa Baixa Normal Alta Muito Alta

Maturidade e capacitação de CASE

Muito baixa Baixa Normal Alta Muito Alta

PROD (NOP/mês) 4 7 13 25 50

No nível inicial do projeto as estimativas são baseadas em pontos por função, que são, então, convertidas para o número de linhas de código. A produtividade vai depender do número de módulos gerados (Sommerville, 2003). A fórmula para esse nível é:

PMm = (ASLOC x (AT/100))/ATPROD

PM = esforço requeridoASLOC = número de linhas de código-fonte geradas automaticamente;ATPROD = nível de produtividade para este tipo de produção de código;AT = percentagem de código total do sistema automaticamente gerado

O nível pós-arquitetura utiliza mais recursos para a estimativa, como a capacidade de pessoal e as características definidas para o projeto e o produto.A fórmula adotada é:ESOLC = ASLOC x (AA + SU + 0,4DM + 0,3IM)/100Onde:ESLOC = número equivalente de linhas de código;ASLOC = número de linhas de código reutilizável;DM = percentual do projeto modificado;IM = percentagem do esforço original de integração requerido para integrar o software reutilizado;SU = fator de entendimento do software, varia de 10 a 50 ) desde códigos orientados a objetos até códigos não estruturados;AA = fator que reflete os custos de avaliação inicial para decidir se o software pode ser utilizado valor varia de 0 a 8)

É interessante que se tenha uma noção do funcionamento do COCOMO, entretanto, existem ferramentas para auxiliar no cálculo das estimativas e não há necessidade de se realizar esses cálculos manualmente. Inclusive, a ferramenta COCOMO apresenta uma série de perguntas a serem respondidas pelo gerente de projetos, as quais associadas a padrões previamente estabelecidos possibilitam a estimativa dos custos do projeto.Maiores detalhes sobre o COCOMO podem ser encontrados em Sommerville (2003) e (..., 2005).Um aspecto relevante no modelo COCOMO é a apresentação de elementos que devem ser considerados para o cálculo do custo do projeto, divididas em atributos do produto; atributos do computador; atributos do pessoal e atributos do projeto.A seguir na tabela 4.3, é apresentada uma síntese desses elementos.

7

Tabela 4.3. Elementos considerados para a estimativa de custos do projeto.Atributos do produto

ConfiabilidadeComplexidade dos módulos do sistemaExtensão da documentaçãoTamanho do banco de dados utilizadoPercentagem requerida de componentes reusáveis

Atributos do computadorRestrições de tempo de execuçãoRestrições de memóriaVolatilidade da plataforma de desenvolvimento

Atributos de pessoalCapacitação de analistas de projetoContinuidade de pessoalExperiência do programador no domínio do projetoCapacitação do programadorExperiência do analista no Domínio do projetoExperiência na linguagem e na ferramenta

Atributo de projetoUso de ferramentas de softwareRedução do cronograma de desenvolvimentoExtensão do trabalho em vários locais

(Fonte: adaptado de Sommerville, 2003)

4.1.4. Métricas

Vamos iniciar a abordagem sobre as métricas e medição de software, a partir de algumas definições sobre o significado de métrica. Para Pressmann (2002), métrica de processo e de projeto de software são medidas quantitativas que permitem aos desenvolvedores ter idéia da eficácia do processo de software e dos projetos que são conduzidos usando o processo. Dados básicos de qualidade e de produtividade são coletados e analisados comparados com medidas anteriores e avaliados para determinar se ocorreram melhorias de qualidade e produtividade. Métricas são também usas para detectar áreas problema de modo que soluções possam ser desenvolvidas.Enquanto Sommerville (2003) considera que uma métrica de software é qualquer tipo de medição que se refira a um sistema de software, processo ou documentação relacionada.Métricas de software podem ser categorizadas em medidas diretas e medidas indiretas. Medidas diretas do processo de engenharia de software e incluem custo e esforço aplicados. Medidas diretas do produto incluem linhas de código produzidas, velocidade de execução, defeitos relatados durante um certo período. Medidas indiretas do produto incluem funcionalidade, qualidade, complexidade, eficiência, confiabilidade, manutenibilidade.O primeiro tipo de medição na área de software foi a contagem de linhas de código. Entretanto, com o aumento da complexidade do software e outros aspectos que foram incorporados ao seu desenvolvimento essa medida isolada não contribui para a medição.

8

Uma das classificações utilizadas para as métricas é dividi-las em métricas ligadas ao processo, ao projeto e métricas ligadas ao produto.Assim, tem-se que as métricas ligadas ao processo são relacionadas à melhoria da qualidade do processo, compreendendo os processos existentes e propondo melhorias quando for necessário. Um dos exemplos de modelos que se volta para a melhoria de processo é o Modelo de Maturidade de Capacitação da SEI - CMM (referência...).As métricas ligadas ao projeto são usadas para minimizar o cronograma de desenvolvimento e também para avaliar a qualidade do produto durante a sua evolução. No primeiro caso, dados históricos de projeto são tomados como base para estimativas de esforço e de tempo. No segundo caso, pode-se modificar a abordagem técnica para aperfeiçoar a qualidade.As métricas ligadas aos produtos se preocupam com as características do próprio software tais como número de linhas de código; complexidade ciclomática etc. O produto é medido para aumentar a sua qualidade.Com o surgimento do paradigma “orientação a objetos”, são elaboradas, também, métricas específicas para serem utilizadas nessa forma de desenvolvimento de software visto que, inicialmente, as métricas foram concebidas dentro da programação estruturada.Na medição de produtos existem duas formas básicas: métricas dinâmicas e métricas estáticas. As métricas dinâmicas são coletadas por medições feitas de um programa em execução e as métricas estáticas são coletadas por medições feitas das representações do sistema, como projeto, programa ou documentação (Sommerville, 2003). Outra classificação apresenta as métricas como diretas ou indiretas (Pressmann, 2002). As métricas diretas no software envolvem o custo e o esforço aplicado. As linhas de código produzidas; a velocidade de execução; o tamanho da memória e os defeitos registrados ao longo de certo espaço de tempo. As métricas indiretas estão preocupadas com características como: funcionalidade, qualidade, complexidade, eficiência, confiabilidade, manutenibilidade, entre outras.Vários tipos de métricas foram desenvolvidos ao longo do tempo tendo sido classificadas em métricas orientadas a tamanho e orientadas a função. Entretanto, ainda permanecem as dificuldades sobre o quê e como medir em engenharia de software.De acordo com Pressmann (2002), o software é medido por:

Indicar a qualidade do produto; Avaliar a produtividade das pessoas que produzem o produto; Formar uma linha básica para estimativas; Ajudar a justificar os pedidos de novas ferramentas ou treinamento adicional.

Para se ter uma idéia geral dos tipos de métricas foram elaboradas as tabelas 4.4, 4.5, 4.6 e 4.7 com a divisão dos tipos de métricas em métricas de complexidade do software e métricas de complexidade do produto (Pressman, 1995; Sommerville, 2003 e Herbert & Price, 1995). As métricas de complexidade de software são subdivididas em: (1) Análise do Fluxo de Controle (tabela 4.4); (2) Análise do Fluxo de Dados (tabela 4.5) e (3) Análise do Tamanho e Volume do Programa Fonte (tabela 4.6). As métricas que medem a complexidade relacionada ao fluxo de controle baseiam-se na representação dom modelo através de um grafo de fluxo de controle1.

1 Grafo de Fluxo de Controle – GFC – indica as estruturas de controle utilizadas na programação.

9

Tabela 4.4. Métricas de Complexidade de Software – Análise do Fluxo de Controle.Tipo de métrica Número

ciclomático-McCabe

Métrica de NPath-Nejmeh

Métrica de Escopo (Harrison & Magel)

Métrica Expressões Regulares (Magel)

Baseada em Teoria dos grafos Na métrica Número ciclomático

Na métrica Número ciclomático

No fluxo de controle do programa

Fórmula NC = a – n + 2, onde a = nr. De arcos,n = nr. De nodos no GFC

O número de caminhos de execução é contabilizado considerando-se apenas uma interação entre os laços

A complexidade é determinada a partir da análise da abrangência do escopo das estruturas de controle do programa.

A complexidade é medida utilizando o conceito de expressões regulares que podem ser utilizadas para determinar as possíveis sequências de execução em um programa. Etapas:1. representar as seqüências de execução de GFC;2. contar os operandos, parâmetros e operadores da expressão resultante.. (ab) * - repetição da execução da seqüência ab;(a+b): execução de a ou b;Ab – execução de a seguida de b.

Um dos problemas detectados ao se trabalhar com as estruturas de controle em alguns tipos de métricas é a falta de fazer uma distinção entre as estruturas de controle, tratando-as da mesma forma.

Tabela 4.5. Métricas de Complexidade de Software – Análise do Fluxo de DadosTipo de Métrica Complexidade de Variáveis de

Controle -MClureMétrica de Oviedo

Baseada em São analisadas as variáveis referenciadas nas comparações, assim como o número de comparações no programa.

Contabilização do número de arcos no GFC. A complexidade é relativa ao fluxo de controle.

Fórmula Cm = C + V, onde:C = nr. De comparações do módulo; V = nr. De variáveis distintas referenciadas nas comparações

A complexidade do fluxo de dados do programa é medida considerando a relação existente entre as definições e usos de variáveis. A métrica contabiliza o uso de variáveis.

10

Tabela 4.6. Métricas de Complexidade de Software – Análise do Tamanho e Volume do Programa Fonte.Tipo de Métrica Contagem das Linhas de Código Software Science - HalsteadBaseada em Linhas de código do programa fonte Contagem de operandos e operadoresFórmula Unidade de medida: LOC (Lines of

Code)Para programas maiores, a medida é em milhares de linhas de código (KLOC)

Programas que utilizam muitas fórmulas, com grande manipulação de dados possui um grande valor de complexidade associado ao fluxo de dados.Programas que utilizam muitas comparações possuem grande valor de complexidade relacionado ao fluxo de controle.

Um dos grandes problemas da métrica contagem de linhas de código é a inexistência de uma escala de valores, o que existe são sugestões de variação do tamanho para indicar se o programa é simples ou complexo, não considerando a estrutura lógica do programa.

Tabela 4.7. Métricas de Complexidade do ProjetoTipo de Métrica Métrica de Yin & Winchester Métrica de Henry & KafuraObjetivo Sistema Design Quality Metrics (DQM) Usada na avaliação do Núcleo do Sistema

Operacional UnixFórmula N i = nr. De módulos do nível 0 ao i. Complexidade = tamanho * (fan-in * fan-

out), onde:Fan-in = nr. De fluxos locais terminado nesse módulo;Fan-out = nr. De fluxos locais originando-se nesse módulo.Utilizam métricas linhas de código.

Forma de avaliação

Feita a partir da análise do diagrama de chamada entre os módulos

Baseia-se nos caminhos possíveis de fluxo de informação através de um módulo.

A métrica de Yin & Winchester apresenta como problema o fato de considerar apenas as relações entre os módulos. A Métrica de Henry & Kafura apresenta problemas relativos a determinação da complexidade do software, quando módulos maiores com altos valores de fan-out possuem maior complexidade do que um módulo pequeno com o mesmo fan-out.As métricas apresentadas até o momento estão associadas à programação estruturada, no entanto, já existem métricas voltadas a orientação a objetos, como pode ser encontrado em PFleeger (2004). As dificuldades na medição com relação a orientação a objetos envolve a medição de características como: baixo acoplamento e grande coesão e a complexidade do projeto. Algumas métricas para orientação a objetos têm sido apresentadas como: contagem de número de cenários e scripts nos casos de uso; número de classes principais; número de classes de suporte; número médio de classes de suporte por classe principal; número de subsistemas.Um dos conjuntos de métricas de software OO mais amplamente referenciados foi proposto por Chidamber e Kemerer, frequentemente conhecido como métricas CK. A sequencia de métricas CK define 6 métricas de software orientadas a classe, que focalizam a classe e a hierarquia de classes., a sequencia de métricas também desenvolve métricas para avaliara as colaborações entre classes e a coesão dos métodos de uma classe. Uma ampliação dessa sequencia de métricas foi proposta por Lorenz e Kids focando tamanho ( contagem de atributos e operações de uma classes), herança; coesão e acoplamento e reuso.

11

Segundo Pressman (2002), as métricas de software fornecem uma maneira quantitativa de avaliar a qualidade de atributos internos do produto habilitando assim o engenheiro de software a avaliar a qualidade antes do produto ser construído. As métricas fornecem uma visão aprofundada necessária para criar modelos efetivos de análise e projeto, código e testes rigorosos.As métricas para os modelos de análise focalizam a função os dados e o comportamento. As métricas de pontos por função fornece meios quantitativos para avaliação do modelo de análise. As métricas para projeto consideram aspectos da arquitetura, projeto em nível de componentes e projeto de interface. As métricas definidas para análise e projeto podem oferecem os subsídios necessários para o projeto e execução de casos de teste.

4.1.5. Gerenciamento de Riscos

Em todo projeto existe o risco e na área de desenvolvimento de software esta preocupação se torna uma constante para os gerentes de projetos. Em uma definição sucinta, risco é a probabilidade de que algum evento impacte negativamente as metas do projeto, que constituem a referência para a medição dos riscos no projeto (Cleland & Ireland, 2002). Os riscos são categorizados em riscos internos e riscos externos. O risco interno é mais facilmente controlado, pois pode ser reduzido pela adoção de medidas diretas. O risco externo foge ao controle do gerente de projetos, pois reflete a existência de interferências externas. Entretanto, os riscos, tanto internos como externos podem ser previstos, o que possibilita a adoção de medidas que minimizem seu impacto no projeto.Os riscos podem estar ligados ao projeto, ao produto e aos negócios organizacionais. Na gerência de projetos existe uma subárea chamada gerenciamento de riscos, a qual se preocupa com o controle dos riscos nos projetos, tratando-os em 4 estágios básicos: Identificação de riscos;

Trata-se da identificação dos possíveis riscos, o que pode ser realizado utilizando-se um checklist considerando por exemplo, tamanho do produto, impacto no negócio, tecnologia para construção, tamanho e experiência da equipe.

Análise de riscos;São avaliadas a ocorrência dos riscos, seu tipo e as conseqüências de sua ocorrência;

Planejamento de riscos;É realizado o planejamento para controlar os riscos, evita-los ou minimizá-los, dependendo do caso;

Monitoramento de riscos;Os riscos são constantemente avaliados.

Na identificação dos riscos devem ser mapeados todos os envolvidos no projetos desde os desenvolvedores até os stakeholders. A identificação torna-se fundamental para o controle e monitoramento dos riscos.A tabela 4.8, abaixo, mostra os possíveis riscos em software.

12

Tabela 4.8. Riscos em software.Risco Tipo de Risco DescriçãoRotatividade de pessoal Projeto O pessoal experiente deixará o

projeto antes do términoMudança no gerenciamento Projeto Haverá uma mudança no

gerenciamento organizacional, com a definição de prioridades diferentes.

Indisponiblidade de hardware Projeto O hardware essencial ao projeto não será entregue dentro do prazo.

Alteração nos requisitos Projeto e produto Haverá mais número de mudanças nos requisitos do que o previsto.

Atrasos na especificação Projeto e produto As especificações são interfaces essenciais não estavam disponíveis dentro do prazo.

Tamanho subestimado Projeto e produto O tamanho do sistema foi subestimado.

Baixo desempenho de ferramentas CASE

Produto As ferramentas CASE que apóiam o projeto não apresentam desempenho conforme o previsto.

Mudança na tecnologia Negócios A tecnologia básica sobre a qual o sistema está sendo construído foi superada por nova tecnologia.

Concorrência com o produto Negócios Um produto concorrente foi lançado no mercado, antes que o sistema fosse concluído.

Fonte: Sommerville, 2003

Os riscos, também podem ser classificados em toleráveis e catastróficos, dependendo dos efeitos que causam na organização e no software.Laudon & Laudon (2005) defendem a criação de um ambiente de controle para os software, entretanto, a preocupação dos autores é com o software já em operação e não com o software em desenvolvimento.Algumas pesquisas na área de gerenciamento de riscos apresentam ferramentas de apoio ao gerenciamento de riscos, como, por exemplo, a ferramenta No-risk (Pradlanik &, 2005), cujo objetivo é contribuir com o gerente de projetos para o controle dos riscos no desenvolvimento de software.

13

4. 2 – Gerenciamento de Recursos Humanos em Projetos

Neste tópico é realizada uma abordagem sobre os recursos humanos e sua relevância no GP, cuja seleção adequada pode implicar no bom andamento do projeto ou em seu fracasso. Apresenta-se, também, um mecanismo de apoio ao gerenciamento de recursos humanos em um ambiente de desenvolvimento distribuído, mostrando opções quanto a indivíduos que apresentem o perfil necessário à execução de atividades e que possam ser alocados para tal. Dessa forma, são oferecidos ao gerente de projetos subsídios para uma adequada tomada de decisão e para melhorar o planejamento de projetos.

4.2.1. Grupos de Trabalho

A importância da avaliação da cultura da equipe do projeto vem sendo destacada na nova forma de administrar centrada na valorização das pessoas. Segundo Ireland & Cleland (2002), a cultura inclui a totalidade de conhecimento, crenças, arte, moral, lei, costume e outras capacidades e atitudes expressas pelas pessoas em um projeto. Indo além, os autores afirmam que:

“As pessoas são responsáveis por fazer um projeto funcionar e a cultura de um projeto interliga os membros da equipe, dando a eles um sentido e um conjunto de princípios e padrões para viver e trabalhar por eles em suas responsabilidades no projeto.” (Cleland & Ireland, 2002, p: 66).

Ao tratar de ambiente distribuído de software a situação dos grupos de trabalhos e a cultura existente se tornam desafios ainda maiores, pois, como afirmam Enami et al (2006), para grupos dispersos em locais geográficos distintos que trabalham em um mesmo projeto deve-se considerar a questão cultural; a língua oficial e outros elementos, os quais podem influenciar nos acordos estabelecidos, na forma de concretizar os contratos e consequentemente no sucesso dos projetos. Algumas técnicas são apresentadas aos líderes de projeto visando a coesão dos grupos de trabalho para o fortalecimento do mesmo e o alcance do objetivo do projeto.Um grupo de trabalho que atua na linha do consenso e não na linha do controle torna a equipe se mais coesa, ocasiona menor rotatividade e cria sentimento de identidade de grupo.Uma liderança que, também atua nesse sentido possui mais capacitação para gerenciar os conflitos que surgem no desenvolvimento dos projetos.

4.2.2. Divisão do trabalho

Uma adequada divisão do trabalho se torna fundamental para que o projeto consiga cumprir o cronograma proposto. A própria complexidade dos projetos diminui com a divisão das tarefas em tarefas menores, distribuídas para as pessoas de acordo com suas habilidades e conhecimentos.Quatro formas de equipe são encontradas: convencional; democrática; centralizada e hierárquica e são organizadas de acordo com a necessidade e/ou forma de estruturação da empresa. No entanto, na atualidade busca-se organizar as equipes de uma forma mais democrática visando a participação de todos em busca do mesmo objetivo.Após a divisão das tarefas, parte-se para a elaboração do cronograma do projeto, o qual deve refletir as necessidades de todos os envolvidos. Para a elaboração do cronograma

14

também existem alguns recursos como as redes PERT-CPM2, as quais buscam apresentar uma seqüência lógica do planejamento com as interdependências das tarefas.

4.2.3. Seleção de Recursos Humanos

O gerenciamento de recursos humanos ainda necessita de mais estudos devido às limitações da atual tecnologia disponível para coordenação de atividades. Ainda não se têm disponíveis mecanismos que ofereçam suporte na tomada de decisão referente à seleção de indivíduos para as atividades de projeto (Reis, 2003).

Especificamente na área de gerenciamento de projetos de software, a seleção de recursos humanos não tem sido tratada de forma adequada nas ferramentas de gerenciamento de projetos, cuja preocupação maior se volta para custos e prazos. Existem na literatura projetos e algumas técnicas preocupadas com os recursos humanos nos projetos, entretanto, esses projetos não fornecem implementações que automatizem o processo de escolha dos indivíduos, principalmente no tocante às características como habilidades e conhecimento.Nessa linha Huzita et al (2005) e Lima (2004) propõem um mecanismo de apoio à seleção de recursos humanos, que possibilita ao gerente de projetos alocar o pessoal necessário de acordo com suas habilidades e conhecimentos necessário ao projeto. Este mecanismo funcionará integrado à DIMANAGER, que será descrita sucintamente no item 4.4.Nesse mecanismo, o termo conhecimento limita-se aos treinamentos dos quais o candidato participou ou ministrou, e às informações sobre conceitos que ele obteve por outros meios, e que o fizeram descrever o conceito de forma correta no questionário aplicado durante o desenvolvimento da pesquisa. No tocante à disponibilidade, foi ]]relacionada à possibilidade do indivíduo ter em sua agenda horas suficientes para a execução de determinada atividade, no período em que ela deve ser executada. Em relação à habilidade, a avaliação do candidato foi realizada considerando-se a quantidade de projetos de software em que o indivíduo utilizou um conhecimento equivalente à habilidade. Para participação em projetos foi considerada a realização de tarefas pelo indivíduo, em quaisquer das fases de desenvolvimento (análise, projeto, codificação e teste).O modelo de mecanismo desenvolvido em Lima (2004) apresenta como diferencial em relação aos projetos e ferramentas encontrados o fato de estar pautado nos processos de melhoria e no modelo de capacitação (PSP – Personal Software Process, TSP- Team Software Process, PCMM – Personal Capability Maturity Model) definidos pelo SEI. As atividades são o ponto de partida para que o gerente de projetos realize a seleção de um indivíduo, uma vez que, um indivíduo será selecionado para a execução de determinada atividade Os conhecimentos e habilidades necessários, essenciais na avaliação de um desenvolvedor de software, foram mapeados para as atividades da MDSODI e mantida uma aderência com a DIMANAGER e o contexto do ambiente DiSEN. É considerado também, o grau atribuído às características conhecimento e habilidade dos indivíduos que estão sendo avaliados. Além das características consideradas neste mecanismo, outros como os aspectos administrativos e psicológicos do processo de seleção, e também, a atitude do indivíduo são importantes. Estes últimos não foram considerados nesta primeira versão do mecanismo.

2 PERT – Program Evaluation and Review TechnicCPM – Critical Path Method

15

Os processos e modelos de melhoria e capacitação (PSP, TSP e PCMMM) foram ofereceram subsídios para definir fatores importantes a serem considerados para o estabelecimento dos conhecimentos e habilidades necessárias na seleção de candidatos. Com base nestes fatores, conhecimentos e habilidades a serem relacionados às atividades.Supondo, por exemplo, que estamos interessados em identificar um possível relacionamento que se poderia se estabelecer entre os fatores de produção identificados no PSP com TSP e PCMM e ainda com uma atividade. Poderíamos então, tomar como base o fator: quantidade de defeitos encontrados e a estimativa que o indivíduo tem sobre o seu próprio processo de trabalho (PSP), podem implicar diretamente na disposição/possibilidade de assumir atividades (TSP) e também na necessidade de eventuais treinamentos (PCMM) na seleção de um candidato à atividade de implementação.Essa relação pode ser mapeada aos conhecimentos e habilidades necessários. Para o exemplo sendo considerado, pode-se identificar como sendo necessário os conhecimentos e habilidades em linguagem de programação ou orientação a objetos, para os quais o indivíduo deve receber treinamento temporário, caso isso tenha sido constatado, a partir da avaliação feita pelo gerente de projetos. No tocante à atividade implementação, pode-se considerar que é necessário que o indivíduo implemente a solução utilizando uma linguagem de programação. E, a priori, quanto maior for o conhecimento de um indivíduo em determinada linguagem, menor será sua chance de produzir erros na utilização da linguagem, o que pode por exemplo resultar em uma produtividade maior do que um indivíduo que tenha um conhecimento ou habilidade menor na mesma linguagem de programação.Os valores atribuídos ao conhecimento e habilidades apresentados pelo candidato são utilizados na execução de regras fuzzy, definidas adequadamente, e, gerarão informações para a classificação no diferentes níveis se tiver sido identificado mais de um candidato. A partir da aplicação do conjunto de regras, as melhores opções são retornadas e um relatório é apresentado. O resultado oferecido ao gerente de projetos, utilizando o mecanismo, apresenta informações com as possíveis opções de pessoas que tenham o perfil mais adequado à atividade escolhida pelo gerente. As tecnologias escolhidas para a implementação do mecanismo são: JADE (Java Agent Development) (Bellifemine, 2002 apud Lima, 2004), JESS (Java Expert Systems Shell) (Sandia, 2003 apud Lima, 2004) e toolkit FuzzyJ (NRC-IIT, 2002 apud Lima, 2004). Elas foram selecionadas, também, de acordo com alguns requisitos definidos no ambiente DiSEN. O primeiro deles, é a utilização do padrão FIPA para a construção de agentes de software. O segundo, é a determinação da linguagem de programação JavaTM

como linguagem padrão para o desenvolvimento do ambiente. O terceiro é a necessidade da integração dos agentes de software com a utilização da lógica fuzzy. A Teoria de Lógica Fuzzy, , foi utilizada para a quantificação nos níveis referentes aos conhecimentos e às habilidades. A seguir, apresenta-se, o funcionamento do modelo de mecanismo projetado, que em sua prototipação considerou a utilização de 2 agentes conforme pode ser observado na descrição abaixo:1) o gerente de projetos requisita a seleção de candidatos para uma das atividades.2) o método selecionar ativa o agente de seleção que recebe como entrada a atividade escolhida e suas especificações.3) o agente de seleção verifica qual é a regra fuzzy a ser utilizada para a atividade escolhida.

16

4) para cada nó do ambiente, configurado previamente no mecanismo, é disparado um agente de busca para avaliar todos os indivíduos presentes no repositório daquele respectivo nó.5) após ser disparado, o agente de busca realiza a varredura dos dados no repositório (através do método Selecionar) e aplica a regra fuzzy para selecionar os melhores candidatos.6) os melhores candidatos com suas informações são então encaminhados ao agente de seleção, para que possam ser adicionadas às demais, oriundas de outros nós.7) após receber a resposta de todos os agentes de busca o agente de seleção reúne todos os indivíduos apresentados, eliminando redundâncias para a apresentação do relatório.8) finalmente, os resultados são estruturados no relatório que é exibido ao gerente, para que ele possa decidir pela melhor opção para realizar a alocação.O mecanismo não realiza, no momento, automaticamente, a escolha do candidato para o gerente, mas oferecerá a ele, em forma de relatório, informações sobre as melhores opções para a alocação dos recursos humanos em determinada atividade. Assim, eles auxiliam o gerente de projetos na tomada de decisão para a alocação dos recursos humanos.Com a utilização deste mecanismo, o gerente pode observar os resultados e identificar, quando for o caso, necessidade de um replanejamento nas atividades do projeto. Um exemplo é a situação em que não se consegue encontrar uma interseção adequada entre as horas disponíveis dos indivíduos e a dos períodos em que as atividades devem ser realizadas.

17

4.3 – Modelos de Gerenciamento de Projetos

Um modelo de gerenciamento de projeto determina a forma como o gerenciamento deve ser realizado, representando os elementos que compõem o GP para um controle efetivo do gerente de projetos.Alguns modelos têm sido apresentados, entretanto modelos de gerenciamento de projetos para ambiente distribuído de software ainda são incipientes e estão em desenvolvimento (Enami et al, 2005), a despeito desse tipo de desenvolvimento estar se configurando uma realidade devido às inovações tecnológicas que possibilitam o compartilhamento de informações.Nesta seção são apresentados alguns modelos preocupados com o gerenciamento de projetos e uma análise comparativa entre os mesmos. São apresentados, também, elementos necessários para um modelo de gerenciamento de projetos, com base em pesquisas realizadas.

4.3.1. Modelos de gerenciamento de projetos

Os modelos CMMI e o gerenciamento de projetos do PMBOK bem como uma comparação entre eles são apresentados a seguir. .

I. Modelo CMMI (Capability Maturity Model Integration)

O Modelo CMMI (SEI, 2005) avalia a capacidade das organizações desenvolvedoras de software e é composto por 5 níveis de maturidade: Inicial; Gerenciado; Definido; Gerenciado e Otimizado. Cada nível serve de base para o próximo nível. Os níveis são seqüenciais. A seguir tem-se uma descrição de cada nível:Nível 1 – Inicial Os processos das organizações que se encontram no nível 1, são normalmente ad hoc e caóticos. Não há padronização nem documentação adequada. O sucesso depende da competência e do heroísmo das pessoas. Os produtos e serviços funcionam, mas excedem o orçamento e o cronograma dos projetos. Projetos são abandonados em momentos de crise e o sucesso do passado não se repete, pois, não realizam registros históricos.Nível 2- Gerenciado Os projetos, neste tipo de organização, têm seus requisitos gerenciados e seus processos planejados, executados, medidos e controlados. Os projetos são executados e gerenciados de acordo com planos devidamente documentados. Os produtos são revisados com os stakeholders e controlados. Os produtos e serviços de trabalho satisfazem os requisitos, padrões e objetivos especificados para eles.Nível 3 – Definido

A organização que chega neste nível atingiu os objetivos das áreas de processos assinaladas para os níveis 2 e 3. Os processos são bem caracterizados e definidos. São descritos em padrões, procedimentos, ferramentas e métodos. No nível 3, os processos são descritos em mais detalhes e com mais rigor do que no nível 2. Ocorre o inter-relacionamento entre processo, produtos e serviços.

18

Nível 4 – GerenciadoA organização que se enquadra neste nível alcançou os objetivos específicos das áreas

de processos assinaladas para os níveis anteriores (1,2 e 3) e os objetivos genéricos dos níveis 2 e 3. No nível 4 são estabelecidos processos para obter medições quantitativas. Medidas detalhadas de desempenho do processo são coletadas, analisadas estatisticamente e armazenadas para dar suporte, futuramente, a decisões. Nível 5 – OtimizadoNeste nível, os processos são continuamente melhorados. A organização que se enquadra no nível 5 já alcançou as exigências dos níveis anteriores.

II. Modelo PMBOK

O Modelo Processual da PMI (Project Management Institute) (PMBOK, 2004) divide a gerência de projetos em 9 áreas de conhecimento:(1) Gerência de Integração do Projeto: possui processos para garantir que as diversas partes sejam coordenadas adequadamente. Engloba os processos: desenvolver o termo de abertura do projeto; desenvolver a declaração do escopo preliminar do projeto; desenvolver o plano de gerenciamento do projeto; orientar e gerenciar a execução do projeto; monitorar e controlar o trabalho dom projeto; controlar a integração de mudanças e encerrar o projeto.

(2) Gerência do escopo; possui processos para delimitar o projeto. Consiste nos processos: planejamento do escopo; definição do escopo; criação da Estrutura Analítica do Projeto (EAP); verificação do escopo e controle do escopo.

(3) Gerência do tempo: possui recursos para assegurar que o projeto será implementado dentro do prazo previsto. Engloba os processos: definição das atividades; definição da seqüência das atividades; estimativa de recursos nas atividades; definição da seqüência das atividades; estimativas de recursos nas atividades; estimativa de duração das atividades; desenvolvimento do cronograma e controle do cronograma.

(4) Gerência de Custos: relaciona os custos associados ao projeto a partir dos processos: estimativa de custos; elaboração do orçamento e controle de custos.

(5) Gerência da qualidade: possui os recursos necessários para garantir e satisfazer as necessidades definidas no escopo. Os processos são: planejamento da qualidade; realização da garantia da qualidade e realização do controle da qualidade.

(6) Gerência de recursos humanos: possui os processos para o uso mais efetivo das pessoas envolvidas no projeto. Engloba os processos: planejamento de recursos humanos; contratação e mobilização da equipe do projeto; organizar a equipe do projeto e gerenciar a equipe do projeto.

(7) Gerência de comunicação: possui os processos necessários para garantir a geração, coleta, distribuição, armazenamento e o controle das informações do projeto. Fornece ligações entre pessoas, idéias e informações que são necessárias para o sucesso do projeto. Consiste nos processos: planejamento das comunicações, distribuição das informações, relatório de desempenho e gerenciamento das partes interessadas.

(8) Gerência de riscos: possui os processos para identificação, análise e resposta aos riscos do projeto, a partir dos processos: planejamento do gerenciamento de riscos; identificação de riscos; análise qualitativa de riscos; análise quantitativa de riscos; planejamento a respostas a riscos e monitoramento e controle de riscos.

(9) Gerência de aquisição: possui os processos necessários para a obtenção de bens e serviços externos. Consiste nos processo: planejar compras e aquisições; planejar contratações; solicitar respostas de fornecedores; selecionar fornecedores; administração de contrato e encerramento do contrato.

19

Segundo Enani et al (2005) o modelo processual da PMI é o padrão mundial para a gerência de projetos e pode ser utilizado para todos os tipos de projetos e, não somente para os projetos de software.

III. Comparação entre os modelos de gerenciamento de projetos

Os modelos de gerenciamento de projetos apresentados possuem algumas características peculiares. O Modelo PMI é utilizado para qualquer tipo de projeto enquanto o modelo CMMI é utilizado como referência para projetos de software, indicando o grau de maturidade das organizações. Entretanto, ambos são referenciados e utilizados pela comunidade da área de informática como parâmetros para o desenvolvimento de projetos de software.De modo geral, os dois tipos de modelos primam pelo envolvimento de todas as pessoas relacionadas ao projeto, desde os desenvolvedores até os stakeholders.Na tabela 4.9, abaixo, é apresentada uma breve comparação entre os dois modelos citados.

Tabela 4.9. Comparação entre os modelos de gerenciamento de projetos.Modelos PMI CMMIObjetivos Auxiliar no gerenciamento

de projetosAuxiliar no acompanhamento do desempenho da organização, avalia a capacidade e a maturidade da organização

Uso Usado para todos os tipos de projetos

Usado para projetos de software

Características Divisão em gerências Divisão em níveis Envolvidos Participantes do projeto Participantes do projeto

4.3.2. Características para um modelo de gerenciamento de projetos de software

Um modelo de gerenciamento de projetos de software (MGPS) torna-se necessário para auxiliar no planejamento e acompanhamento dos projetos. Especificamente na área de software deve-se atentar para as novas formas de desenvolvimento como o desenvolvimento de software em ambiente distribuído.Algumas características tornam-se necessárias para um modelo de gerenciamento de projetos de software: O modelo deve ser baseado nos modelos já propostos como forma de utilização dos

métodos e recursos já disponíveis, como os modelos PMI e CMMI, aceitos e utilizados pela comunidade de software;

Estar inserido no contexto organizacional, a partir do comprometimento com a missão da organização e suas metas;

Possuir a visão de integração de aspectos técnicos e organizacionais intrínsecos ao desenvolvimento de software;

Considerar todos os envolvidos no desenvolvimento de um projeto de software, tanto internamente como externo às organizações;

Adequar ferramentas automatizadas que facilitem o planejamento e o acompanhamento dos projetos de software.

20

A utilização de modelos já aceitos, como o PMI e o CMMI, viabiliza um melhor aproveitamento das técnicas disponíveis. No caso do PMI, por exemplo, a divisão em 9 gerências chama a atenção para a cobertura de vários processos existentes na organização que vai desde a especificação de requisitos até o gerenciamento dos riscos. São processos que ocorrem, também, na área de software. No tocante ao CMMI, a busca da identificação do posicionamento das organizações faz com que os processos sejam repensados e reorganizados para um aprimoramento das práticas organizacionais.O comprometimento com a missão da organização e as metas organizacionais denota a integração que deve ocorrer entre o desenvolvimento de software e o todo da organização para que todos caminhem em sintonia e no mesmo rumo.A organização está inserida em um ambiente complexo e não pode se fechar em si mesma, pois sofre reflexos das situações que ocorrem em seu entorno. A partir do momento em que se vê como uma organização aberta, deve-se estar atenta aos relacionamentos que existem e que podem influenciar no sucesso ou no fracasso dos projetos de software.O desenvolvimento de software traz consigo uma série de necessidades, as quais chamamos técnicas e organizacionais, pois, ao mesmo tempo se preocupa com a tecnologia utilizada, com recursos humanos, com o comprometimento e motivação do pessoal, entre outros, que são considerados pelos gerentes de projetos.Um modelo de gerenciamento de projeto de software deve utilizar de ferramentas automatizadas que auxiliem o gerente de projetos no planejamento e no acompanhamento dos projetos, com vistas a facilitar essas atividades e possibilitar o armazenamento desse controle.

21

4.4 – Uma Ferramenta de Gerenciamento de Projetos de Software

Um modelo de gerenciamento de projetos de software para ser viavelmente aplicado necessita do apoio de uma ferramenta de apoio à realização das atividades inerentes às funções do gerente de projetos.Aqui é apresentada a ferramenta DIMANAGER (Pedras, 2003), desenvolvida com o intuito de colaborar com o gerenciamento de projetos em ambientes de desenvolvimento distribuído de software. Esta ferramenta está inserida no contexto do ambiente DiSEN (Distributed Software Engineering Environment) (Huzita, 1999; Pascutti, 2002) considerando também a metodologia MDSODI (Metodologia par Desenvolvimento de Software Distribuído (Gravena,2000) e que se encontram em mais detalhes no item 4.5. As ferramentas de apoio ao gerenciamento de desenvolvimento de Software Distribuído devem proporcionar, segundo Pressman (2002), estimativas de custo, esforço e duração do projeto de software, assim como a definição de uma estrutura de divisão de trabalho, o planejamento de uma programação viável de projeto e acompanhamento em base contínua dos mesmos. A indicação da produtividade no desenvolvimento de software e da qualidade do produto são pontos de fundamental importância. As ferramentas de apoio ao gerenciamento do produto devem ainda, ser capazes de identificar os requisitos iniciais da proposta do cliente até o trabalho de desenvolvimento do software que implementará esses requisitos em um sistema a ser entregue.

A DIMANAGER deve gerenciar esta área operacional do projeto, com a finalidade de abranger o desenvolvimento de software distribuído, agilizando a produção, mantendo grupos de trabalho dispersos geograficamente, e gerenciando o desenvolvimento do software, com o planejamento dos objetivos, a organização e controle das atividades e, a coordenação das equipes de trabalho.

Arquitetura da ferramenta DIMANAGEROs requisitos funcionais da DIMANAGER são: planejar e acompanhar o projeto. Algumas funcionalidades, apresentadas no trabalho de Gomes et al. (2001), tais como: um calendário de atividades e o cadastro de usuários, capaz de apoiar e orientar o levantamento e a análise de dados incorporados ao ambiente de software instanciados pela Estação Taba contribuíram para identificar e elaborar o cadastro de usuários, participantes e cronograma à ferramenta DIMANAGER, pois fazem parte do gerenciamento das atividades desenvolvidas.Além destas funcionalidades outras informações foram consideradas para a definição do planejamento do projeto, tais como: identificação das atividades dentro do projeto: identificar as atividades, obedecendo

as fases estabelecidas no processo de desenvolvimento de software de acordo com a metodologia MDSODI que são: requisitos, análise, projeto, implementação e testes.

identificação das métricas: estabelecer métricas que deverão ser analisadas para o acompanhamento do projeto devem ser escolhidas com base na necessidade de cada projeto. Os estudos sobre métricas são complexos e dentre as técnicas de estimativas disponibilizadas para o desenvolvimento de software podem ser citadas, segundo Pressman (2002): estimativas de linhas de código (LOC), estimativas de pontos-por-função (FP) ou estimativas do esforço. Neste trabalho adotaremos a estimativa do esforço definida através do número de homens por hora de atividade (humano-hora);

22

definição dos participantes: a identificação dos participantes com atribuição de funções e habilidades é de extrema importância, pois dela depende o bom andamento do projeto. Cada participante, embora tenha uma determinada função pode participar do projeto em várias atividades de acordo com seus conhecimentos e habilidades sendo também um elo de ligação entre os setores envolvidos no projeto. Todo participante deve ser cadastrado no sistema como usuário, desta forma ele terá acesso ao projeto como participante do mesmo.

elaboração do cronograma de atividades: o cronograma contém o planejamento das atividades no projeto e deve: estabelecer a atividade, o esforço (que informa o número de homens por hora de atividade = homem/hora), data inicial e data final prevista para cada atividade, e o estado em que a atividade se encontra que pode ser: em andamento, parado, suspenso, em planejamento ou encerrado. Os membros envolvidos na elaboração do projeto devem ser selecionados de acordo com o conhecimento de cada um. Para a distribuição de atividades em cada fase do projeto a função, o conhecimento e a habilidade de cada participante deve ser levado em consideração para que o mesmo desempenhe a atividade estabelecida de forma eficaz e eficiente.

Cada participante deve documentar as atividades executadas durante o decorrer dos trabalhos gerando o acompanhamento do projeto. O registro da execução da atividade deve conter a identificação do participante, a fase do projeto, a atividade em desenvolvimento, a data da execução, a hora inicial e final da mesma assim como o estado em que se encontra a atividade.De acordo com Pressman (2002) a programação do projeto de software não é, de fato, diferente de qualquer projeto de engenharia. Um conjunto de tarefas de projeto é identificado. Interdependências entre as tarefas são estabelecidas e o esforço associado a cada tarefa é estimado. Pessoas assim como outros recursos são atribuídos e uma “rede de tarefas” é criada. Desta forma, para que a atividade estabelecida no cronograma seja bem definida o Gerente de Projeto solicita a participação do Coordenador de Cronograma, para que juntos possam estabelecer o cronograma de atividadesO Acompanhamento do Projeto é a parte mais importante da ferramenta DIMANAGER. O Gerente de Projeto pode solicitar a participação dos Coordenadores de Participantes e de Atividades para analisar os resultados obtidos. Baseado nos participantes, atividades e métricas já definidas (humano-hora), o Gerente de Projeto visualiza resultados referentes às atividades desenvolvidas por cada participante, analisa o desempenho de cada um, e verifica se o projeto está evoluindo dentro do prazo estabelecido.Tendo como base as informações do Acompanhamento o projeto recupera todas as informações referentes ao Projeto tais como: Projeto, Fase, Atividade, Cronograma, Participante, Função, Participação, Situação e Lista de Problemas.

Apresentação da ferramenta DIMANAGERDurante o planejamento e a organização do projeto o gerente deve ser cuidadoso com as informações que serão colocadas no projeto.A ferramenta DIMANAGER foi desenvolvida buscando facilitar o planejamento e o acompanhamento realizados pelo gerente de projetos.A primeira janela disponível na DIMANAGER disponibiliza ao gerente três áreas de atuação: Conheça a DIMANAGER; Serviços; e Usuários.A primeira opção “Conheça a DIMANAGER”, é uma janela contendo uma descrição da ferramenta. Apresenta os conceitos, sua estrutura e finalidade e permite ao usuário ter uma noção do que a DIMANAGER pode oferecer.

23

Na opção “Serviços”, o gerente deve cadastrar as informações que comporão o projeto, como por exemplo, as atividades estabelecidas para cada fase de desenvolvimento, de acordo com a metodologia MDSODI, os grupos de trabalho e suas respectivas atividades, a identificação de possíveis problemas e suas soluções, o cronograma de atividades e as metas a serem cumpridas em cada atividade.A terceira opção, “Usuários”, disponibiliza ao gerente do projeto o cadastro dos usuários que participarão no desenvolvimento do projeto.Qualquer usuário poderá conhecer a DIMANAGER através da primeira opção. Na descrição da DIMANAGER encontra-se um resumo de suas características e de sua essência.Ao iniciar um novo projeto, o gerente de projeto deve primeiramente, definir o projeto, escolhendo a opção “Serviços” e em seguida, “Planeje seu Projeto”, conforme Figura 4.1.

Figura 4.1 – Planeje seu Projeto

O projeto o gerente deve especificar detalhadamente as informações do projeto a ser cadastrado, com uma linguagem clara e de fácil compreensão, facilitando o conhecimento do mesmo (Figura 4.2). Neste momento, deve ser informado o responsável pelo projeto em andamento. O responsável pelo projeto é o primeiro usuário a ser cadastrado, e, já deve estar registrado no sistema. Na fase do planejamento de um novo projeto, informações como: estado, lista de problemas, grupo, atividades, cronograma, participação e situação devem ser informados.

24

Figura 4.2 – Cadastro Novo Projeto

O participante selecionado para desenvolver uma atividade no projeto em planejamento, deve ser cadastrado na DIMANAGER como um usuário.Os usuários da ferramenta serão cadastrados logo após a definição dos grupos de trabalho, sendo atribuídas as permissões de acesso de acordo com as atividades de cada um, mas os coordenadores do projeto podem ser cadastrados no primeiro momento, devendo planejar e acompanhar o projeto em conjunto com o gerente .O gerente do projeto deve cadastrar os usuários com as seguintes informações: nome completo, número de identificação, o setor em que o usuário trabalha, sua função, o endereço de correio para correspondência eletrônica, conforme Figura 4.3. As senhas devem ser mantidas em rigoroso sigilo e o usuário é o único responsável por ela.

25

Figura 4.3 – Usuários

Cada usuário tem um nível de acesso, podendo ser classificado como: gerente ou participante. O gerente ou coordenador de área tem um nível mais amplo de permissões de acesso, e o usuário classificado como participante poderá trabalhar somente na atividade definida para ele.O passo seguinte deve ser a definição e o cadastramento das atividades. As atividades devem ser especificadas de acordo com cada fase do projeto. A DIMANAGER fixou estas fases com base na metodologia MDSODI: definir requisitos, analisar, projetar, implementar e testar. A Figura 4.4 ilustra o cadastramento da atividade.

26

Figura 4.4 - Atividade

O gerente de projeto em conjunto com o coordenador de atividades deve estabelecer as atividades após escolher a fase a ser detalhada. As atividades de cada fase devem ser descritas de forma clara e precisa para que os participantes do projeto possam entender e desenvolver o projeto dentro do objetivo especificado. Um código de identificação da atividade assim como sua descrição são necessários para poder relacionar cada atividade com o cronograma e os participantes.De acordo com Maximiano (2002), a preparação de uma lista de atividades pode ser considerada como sendo a primeira parte do planejamento. A definição das atividades necessárias para realizar o projeto começa com o planejamento do produto, que é o resultado do projeto. Depois de preparar a lista, deve-se identificar a seqüência em que as atividades serão realizadas, permitindo desta forma, estabelecer as prioridades e o encadeamento das mesmas. A etapa seguinte é a definição dos estados em que cada atividade deve ser classificada. O cadastramento dos estados deve ser informado através da janela que exige a identificação do estado e a descrição do mesmo. O gerente de projeto deve escolher os estados, os quais podem ser: em andamento, parado, suspenso, em planejamento e encerrado. O gerente de projeto deve ser capaz de identificar problemas que podem ocorrer no desenvolvimento do projeto. Todo projeto envolve riscos e a gerência deve identificá-los durante a iniciação do projeto e, em seguida, no seu planejamento (Cleland e Ireland, 2002). Os problemas, ou riscos, podem ser classificados em duas áreas: problemas técnicos e problemas organizacionais.Tait (2000) informa que, muitas vezes, os problemas considerados técnicos, fogem ao controle das organizações e representam um desafio a ser encarado com bom senso,

27

acompanhando a evolução crescente da TI (Tecnologia de Informação), sem, no entanto, desprezar sua experiência e potencialidade. Neste aspecto, deve-se questionar a tecnologia existente e, a seguir, registrar quaisquer ocorrências que possam falhar e a probabilidade de fracasso. Estes problemas devem ser registrados, para que o gerente possa resolver o problema de maneira que o usuário não perceba a falha do sistema. Estes problemas podem ser cadastrados no início do projeto, já que algumas falhas de comunicação podem ocorrer e são conhecidas. Os problemas técnicos podem ser classificados também como problemas internos e dizem respeito à entrega dos resultados desejados (Cleland e Ireland, 2002).Quanto aos problemas organizacionais, podem ser classificados como problemas internos ou ainda externos. Englobam recursos humanos, negócios e metas, culminando em uma postura administrativa que considere todos os elementos que, ignorados, podem levar ao insucesso (Tait, 2000).Normalmente, não se tem muito controle sobre os problemas externos, que podem receber a influência de acordos e contratos com terceiros. Os problemas externos podem ser resolvidos de acordo com a influência do gerente de projeto junto a outros gerentes de projetos, gerentes funcionais, distribuidores e entidades contratantes. Quanto aos problemas internos é necessário identificar as falhas no cronograma na medida em que se executa o planejamento. Cleland e Ireland (2002) relacionam uma lista para a identificação de problemas que podem ser previstos e cadastrados para se evitar discussões e perda de tempo se os mesmos ocorrerem, conforme segue: Checklist para áreas de risco do projeto; Lições aprendidas com projetos anteriores; Listas de recursos disponíveis; Registros de treinamento de recursos para habilidades aplicáveis; Revisão dos planos do projeto por especialistas; Revisões dos planos pela alta administração; Auditoria de capacidade para gerência de projetos organizacionais.É claro que nem sempre os mesmos problemas ocorrem em projetos distintos, pois algumas medidas podem ser tomadas para que se evitem transtornos. Se os problemas são cadastrados, fica fácil resolvê-los quando ocorrerem novamente e deve-se considerar que estas informações não serão perdidas em futuros projetos.O cronograma do projeto só poderá ser definido após a especificação de todas as etapas anteriores. O cronograma de atividades consiste em decidir quando as atividades acontecem e quais são os participantes que devem executar a atividade descrita. A figura 4.5 mostra como deve ser cadastrado o cronograma de atividades.

28

Figura 4.5 - Cronograma

Maximiano (2002) coloca que o retrato do cronograma se baseia em decisões do planejamento e a preparação do mesmo na duração das atividades. A duração das atividades é determinada pela quantidade de recursos previstos assim como a participação de serviços e produtos fornecidos por terceiros. Em teoria, quanto maior a quantidade de pessoas e recursos alocados ao projeto, maior velocidade no ciclo de vida do mesmo.Na descrição do cronograma, cada atividade identificada será programada de acordo com o esforço necessário para sua execução (horas/participante); o resultado que se espera alcançar, a data inicial e final e o estado em que se encontra a atividade.Por se tratar de uma ferramenta de gerenciamento de desenvolvimento de software distribuído, optou-se pela definição de grupos de trabalho, visando maior rapidez no desenvolvimento do software. Os grupos de trabalho podem ser definidos baseando-se na atividade desenvolvida ou na localização geográfica dos participantes em que ocorre o desenvolvimento.O acompanhamento através dos grupos de trabalho deve ser analisado pelo gerente de projeto de maneira a tornar mais prático e ágil o desenvolvimento do projeto.O usuário tornar-se-á um participante quando o gerente de projeto ou coordenador de participantes cadastrá-lo no projeto, o que deve ocorrer após a definição do cronograma e dos grupos de trabalho. O ideal é que as duas etapas – cronograma e participantes – sejam estabelecidas em conjunto, de maneira a determinar a duração das atividades de acordo com os recursos humanos alocados para cada uma, conforme Figura 4.6.

29

Figura 4.6 - Participantes

A escolha dos participantes é importante e requer cuidados, pois, o desenvolvimento das atividades terá um melhor ou pior desempenho de acordo com o conhecimento e habilidade de cada um.Os participantes devem pertencer a um grupo de trabalho que será definido pela atividade ou pela localização geográfica dos mesmos.O cadastro dos participantes requer a definição da fase; da atividade; do participante (que já deve ter sido cadastrado como um usuário); o grupo a que pertence; a data inicial e final, o esforço necessário para o desempenho daquela atividade (horas/participante); e o estado que se encontra o desenvolvimento da atividade do participante envolvido.A situação de cada atividade deve ser mantida atualizada para um melhor acompanhamento delas.O acompanhamento da situação é importante para que o gerente de projeto verifique se está ocorrendo algum problema durante o processo de desenvolvimento. É importante também verificar quais problemas (queda de conexão, afastamento de participantes, recursos financeiros escassos, entre outros) estão ocorrendo e as soluções encontradas para a resolução dos mesmos. Os coordenadores do projeto são elementos de fundamental importância, pois devem ajudar o gerente a detectar as falhas corrigindo-as ou levando para o gerente resolver as questões mais importantes de forma que o usuário que está desenvolvendo o projeto não perceba o problema e continue a trabalhar de forma normal.A execução das atividades se baseia no processo de planejamento. Os planos evoluem à medida que a execução avança, sendo detalhados e modificados, para incorporar novas decisões e para implementar ações corretivas (Maximiano, (2002).O processo de acompanhamento e controle é a contrapartida do processo de planejamento que deve acompanhar o cumprimento do cronograma, os grupos, participantes e problemas.

30

Maximiano (2002) enfatiza que acompanhar tem como funções: assegurar que os objetivos sejam alcançados ou preservar um padrão de desempenho; mostrar a eventual necessidade de modificar a atividade ou até o resultado esperado; verificar se a atividade está sendo realizada.O objetivo do acompanhamento é disponibilizar ao gerente informações sobre o escopo e o prazo do projeto. Quanto ao escopo, questionamentos devem ser feitos, quanto à realização ou não do projeto, se o projeto fornecerá o resultado esperado, e se há modificações solicitadas pelos clientes ou outros participantes do projeto. O acompanhamento do prazo tem como foco a duração prevista do projeto, as datas previstas para o início e fim de cada fase, e as datas previstas para início e fim das atividades e, deve levantar questões como: as datas previstas estão sendo respeitadas? O projeto está caminhando conforme o cronograma, atrasado ou adiantado? É necessário refazer a programação? Quais as conseqüências caso seja necessário reprogramar o cronograma?O acompanhamento do projeto envolve atitudes administrativas que vão influenciar no desempenho do projeto. Estas atitudes devem ser executadas sempre em tempo hábil para não prejudicar o projeto.O acompanhamento do cronograma mostra ao gerente até três níveis de controle: geral (Figura 4.7), detalhado e uma fase específica. Maximiano (2002) é bastante realista quando expõe que os cronogramas vão sendo redesenhados conforme as atividades são realizadas. A antecipação ou atraso de datas deve ser registrado no cronograma, para que a equipe possa acompanhar o progresso do projeto e tomar as decisões necessárias.

Figura 4.7 – Acompanhar Cronograma – Geral

A atualização das datas de execução de cada atividade é atualizada no cronograma e as horas trabalhadas são acumuladas, possibilitando a visualização de sua realização.É importante saber que ao planejar um projeto os problemas internos e externos, já mencionados, irão influenciar no desempenho do projeto. Por isto é que a fase de

31

planejamento é considerada a mais importante e a mais crítica. Após o início dos trabalhos de desenvolvimento do projeto, o gerente deve se preocupar em acompanhar a evolução do mesmo garantindo a menor variação possível.Ao atualizar as datas de execução de cada atividade é possível visualizar o desempenho do grupo de trabalho em três níveis de acompanhamento: geral, detalhado e um grupo específico. O acompanhamento das atividades executadas de cada participante está disponível ao gerente nos níveis: geral, por atividade e por participante, conforme Figura 4.8.

Figura 4.8– Acompanhar Participante – Por Atividade

Para acompanhar o participante o gerente deve informar o nome do usuário participante. A atualização das datas de execução de cada atividade, para cada participante, é atualizada no cronograma de participações e as horas trabalhadas são acumuladas, possibilitando a visualização de sua realização, assim como o estado em que se encontra cada atividade.Desta forma, Cleland e Ireland (2002) colocam que com o objetivo de avaliar-se corretamente o progresso do projeto, algumas condições e entendimentos são necessários, tais como:

os componentes das equipes devem compreender e estar comprometidos com a importância do processo de monitoração, avaliação e controle do projeto;

Informações obtidas através da opção “Acompanhar Projeto” são necessárias para a medição do progresso do projeto;

As atividades de cada fase são as unidades básicas do projeto em torno do qual o progresso do projeto pode ser medido e avaliado;

Informações usadas para fins de controle do projeto devem ser relevantes, precisas e acessíveis à demarcação de tendências no uso de recursos do projeto;

A medição dos resultados do projeto deve iniciar com uma avaliação do estado de todas as atividades existentes no projeto;

32

Informações coletadas e compiladas a respeito do estado do projeto devem ser ajustadas através do julgamento feito pelos componentes da equipe: gerente, coordenadores e executivos envolvidos no projeto.

Neste contexto, a situação do projeto, envolvendo os problemas encontrados e solucionados torna-se bastante útil. A situação do projeto pode ser obtida através de consulta própria, onde será visualizada a posição geral, detalhada e específica por atividade. Alguns problemas que ocorrem no desenvolvimento do projeto podem ser previstos e informados ao sistema, possibilitando ao gerente do projeto reduzir suas conseqüências mediante ações diretas, como o desenvolvimento de planos de contingências. Alguns problemas externos podem estar fora do alcance do gerente, quando depender de ações de terceiros.Os problemas ocorridos no desenvolvimento do projeto podem ser acompanhados através de: uma visão geral (problemas técnicos e organizacionais, problemas técnicos, problemas organizacionais e problemas especificados por fase).Cleland e Ireland (2002) colocam que ocorrências de risco constituem os efeitos potenciais adversos ao projeto, sendo ideal a sua identificação durante o início do projeto e, em seguida, no seu planejamento.O gerente do projeto deve ter alguns atributos básicos para poder gerenciar um projeto com sucesso, sendo elas: ter conhecimento através de aprendizado e experiência; ter e demonstrar habilidades, ou seja, capacidade de usar o conhecimento de forma eficaz e eficiente na execução ou desempenho como gerente de projeto; e, ter atitudes apropriadas, com sentimentos positivos e mente aberta em relação a um fato ou situação.

33

4.5 Gerenciamento de projetos de software em ambiente de desenvolvimento distribuído de software

O número de empresas que estão distribuindo seus processos de desenvolvimento de software ao redor do mundo visando ganho de produtividade, redução de custos e melhorias na qualidade do produto, é cada vez mais significativo (Prikladnicki & Audy, 2004). Desta foram, tem-se criado um cenário onde projetos de software são desenvolvidos com equipes distribuídas, caracterizando assim o desenvolvimento distribuído de software. Isto tem causado impacto, não só no mercado em si, mas na forma como os produtos são entregues aos clientes. Assim, faz-se necessário oferecer ao desenvolvedor de software recursos adequados que o apoie na tarefa de desenvolver software e, por conseqüência, o gerenciamento de projetos, incluindo também a equipe de desenvolvimento.Ambientes de desenvolvimento de software buscam combinar técnicas, métodos e ferramentas para apoiar o engenheiro de software na construção de produtos de software, abrangendo todas as atividades inerentes ao processo, tais como a gerência, desenvolvimento e controle da qualidade.Em um ambiente de desenvolvimento distribuído de software, o gerente de projetos lida com a diversidade cultural, o que leva a necessidade de aperfeiçoamento de métodos de seleção de pessoal, treinamento e motivação.A equipe está dispersa geograficamente e ao mesmo tempo compartilha um projeto. Em seu espaço geográfico os membros da equipe possuem características ligadas à sua cultura, a forma de organização de seu local de trabalho, de sua cidade e país. Todos esses fatores podem influenciar na maneira como as pessoas se comportam e se relacionam diante da resolução dos problemas e dos conflitos que possam surgir.Carmel (1999), propõe um conjunto de forças centrípetas para a formação de equipes globais: infra-estrutura de comunicação, arquitetura de produto, construção da equipe, técnicas de gerência, tecnologia de colaboração e metodologia de desenvolvimento.Inspirados no trabalho de Carmel (1999), Steinmacher et al (2005) formalizam a proposta apresentada em Pascutti (2002) evidenciando as características necessárias a um ambiente de desenvolvimento distribuído de software. Segundo Steinmacher et al (2005) as características necessárias são: infra-estrutura de comunicação, gerência de projetos e processos, gerência de recursos, gerência de artefatos, suporte à persistência de dados, tecnologia de colaboração e metodologia de desenvolvimento. Na literatura, encontram-se vários esforços em direção à construção de ambientes de desenvolvimento tais como: GENESIS (Aversano et al, 2003), Odyssey Share (Werner , et al, 2003); Gossip (Babak, 2000). Encontra-se em construção no Departamento de Informática da Universidade Estadual de Maringá, o ambiente DiSEN ( Distributed Software Engineering Environment), descrito na subseção a seguir e que atende às características supra citadas.

O Ambiente DiSEN

O DiSEN é um ambiente de desenvolvimento de software distribuído incorporando a tecnologia de agentes segundo o padrão da FIPA ( Foundation for Intelligent Physical Agents). Tem como objetivo fornecer o suporte necessário para o desenvolvimento distribuído de software; a equipe poderá estar em locais geográficos distintos e trabalhando de forma cooperativa com uma metodologia para desenvolvimento de software distribuído.

34

A arquitetura do DiSEN é constituída pelas seguintes camadas: uma camada dinâmica: que permitirá, por exemplo, que sejam adicionados,

excluídos, configurados ou modificados componentes de software e serviços de forma dinâmica, isto é, em tempo de execução;

uma camada de aplicação: que oferecerá suporte às metodologias de desenvolvimento de software como por exemplo a MDSODI ( Metodologia para desenvolvimento de software distribuído, que se encontra descrita na subseçao a seguir), o repositório para armazenamento de artefatos e informações necessárias ao ambiente e os gerenciadores de workspace, objetos e agentes. É nesta camada que será tratada a comunicação da ferramenta DIMANAGER pelo Gerenciador de Objetos;

uma camada da infra-estrutura: que define o alicerce da arquitetura e proverá suporte às tarefas de persistência, nomeação e concorrência além de incorporar o canal de comunicação.

Em Pascutti (2002) e Steinmacher et al (2005) podem ser encontrados mais detalhes a respeito dos elementos constituintes do ambiente e que mostram a aderência às características necessárias a ambientes distribuídos de desenvolvimento de software.A seguir, será sucintamente descrita a metodologia MDSODI.

A metodologia MDSODI (Metodologia para Desenvolvimento de Software Distribuído)

A metodologia MDSODI leva em consideração algumas características apresentadas em sistemas distribuídos, tais como: paralelismo/concorrência, comunicação, sincronização e distribuição, durante todo o projeto, desde a fase inicial até a fase final.Em se tratando de sistemas distribuídos, os produtos de software desenvolvidos são cada vez mais complexos. Esta metodologia surgiu para facilitar o desenvolvimento do projeto por etapas que buscou aliar este conceito a um processo de desenvolvimento de software que propiciasse a utilização de objetos distribuídos, assim como, o desenvolvimento de componentes de software reusáveis. As fases do processo de desenvolvimento de software da MDSODI estabelecidos por Gravena (2000) são: Requisitos: esta fase tem como objetivo principal, a partir das necessidades do

usuário, identificar as funcionalidades necessárias para o desenvolvimento do sistema de forma adequada e eficiente.

Análise: esta fase consiste em analisar os requisitos descritos na fase anterior, refinar a estrutura verificando quais são realmente importantes e quais precisam ser acrescentados.

Projeto: nesta fase molda-se o sistema incluindo também os requisitos não funcionais e outras considerações não identificadas nas fases anteriores, como por exemplo: linguagem de programação, interface com o usuário, reuso de componentes, entre outras.

Implementação: esta fase tem como objetivo principal a construção/implementação do sistema, tendo como base aspectos identificados nas fases de requisitos, análise e projeto. Outros aspectos não identificados nas fases anteriores são identificados nesta fase de implementação. Deve-se verificar os aspectos identificados no projeto no que se refere a implementação (linguagem de programação utilizada e geração de código). As interfaces entre os subsistemas identificados na fase de projeto também devem ser definidas. Os aspectos da arquitetura devem ser considerados,

35

acrescentando-se a divisão dos subsistemas de projeto, suas interfaces e dependências entre os mesmos. Testes: Gravena (2000) destaca a importância dessa fase em processo de

desenvolvimento de software a fim de se atingir um produto de qualidade.Além da metodologia MDSODI acima descrita, fazem parte do ambiente DiSEN com o intuito de oferecer o apoio necessário ao desenvolvimento distribuído de software:

um mecanismo para gerenciamento de recursos humanos (Lima, 2004) descrita no item 4.2;

uma ferramenta para gerenciamento de projetos, mais notadamente para o acompanhamento de projetos, denominada DIMANAGER (Pedras, 2003) e descrita no item 4.4;

uma ferramenta para oferecer apoio à MDSODI na fase de requisitos, denominada REQUISITE (Batista, 2003);

um modelo de interoperabilidade a fim de possibilitar que desenvolvedores trabalhando em locais distintos e usando ferramentas distintas possam Ter o mesmo entendimento do artefato sendo produzido;

um modelo de cooperação denominado SAC (Pozza, 2005) para oferecer o apoio ao trabalho cooperativo;

Note que todos estes recursos colaboram para que se possa realizar o gerenciamento de projetos de forma efetiva em ambientes de desenvolvimento distribuído. Ainda, não se deve perder de vista que a consideração das diferenças de local deve direcionar o tipo de treinamento que será realizado tendo em vista um melhor aproveitamento do pessoal. Até cuidados com fuso horário diferenciado deve ser tomado para viabilizar um maior rendimento dos envolvidos.A motivação exige um esforço adicional da liderança no caso de ambiente distribuído de software, pois esta deve perceber as diferenças existentes entre os membros do grupo, percebendo as necessidades e os anseios de cada grupo.

36

Referências Bibliográficas

AVERSANO, L.; CIMITILLE, ª; LUCIA, ª; STEFANUCCI, S.; VILANN, M.L. Workflow Management in the GENESIS Environment. Research Center on Software technology, Department of Engineering, University of Sannio, 2003.

BABAK, F. ª Gossip: Na Awarenes Engine for Increasing Product Awareness in Distributed Development Projects. In International Conference on Advance Information Systems Engineering, Stockholm, 2000. Proceedings... p. 264-278.

BATISTA, S. M. Uma Ferramenta de Apoio à Fase de Requisitos da MDSODI no Contexto do Ambiente DiSEN. Dissertação de Mestrado em Informática. Maringá: Universidade Estadual de Maringá/Universidade Federal do Paraná, 2003.

CARMEL, E. Global Software Teams: Collaborating Across Borders and Time-Zone. EUA: Prentice-Hall, 1999, 269 p.

CLELAND, David I.; IRELAND, Lewis R. “Project Manager’s Portable Handbook”. McGraw-Hill, New York: 2000.

ENANI, L. M.; HUZITA, E. H. M.; TAIT, T. F. C. A project management model to a distributed software engineering environment. In Proceedings of ICEIS 2006 – International Conference on Information Systems, Cyprus, 2006.

HERBERT, J. S & PRICE, A.M.A. Métodos para Avaliação da Qualidade de Software. JAI95 – VIV Jornada de Atualização em Informática, VX Congresso da Sociedade Brasileira de Computação, Canela: 1995.

HUZITA, E. H. M. “Suporte à reutilização em ambientes distribuídos de desenvolvimento de software”, em desenvolvimento na Universidade Estadual de Maringá, com apoio financeiro do CnpQ, 2004.

HUZITA, E. H. M.; PEDRAS, M. E. V.; SANTIAGO, G. P.; TAIT, T. F. C. DIMANAGER: A Tool for Distributed Software Development Management. In Proceedings ICEIS 2004– International Conference on Enterprise Informations Systems, Porto. vol.3, pp. 659-662, 2004.

HUZITA, E.H.M.; LIMA, F.; TAIT, T. F. C. Um Mecanismo de Suporte ao Gerenciamento de Recursos Humanos no Desenvolvimento Distribuído de Software. In: XI Congreso Argentino de Ciências de la Computación, 17-21 October 2005 Concordia-Entre Rios-Argentina, 2005.

LAUDON, K. & LAUDON, J. Sistemas de Informações Gerenciais – Administrando a empresa digital. Tradução: Arlete S. Marques, São Paulo: Prentice Hall, 2004.

LIMA, F. Mecanismo de Apoio ao Gerenciamento de Recursos Humanos no Contexto de um Ambiente Distribuído de Software. Dissertação (Mestrado em Ciência da Computação) - Departamento de Informática. Maringá-Pr: Universidade Estadual de Maringá, 2004.

MAXIMIANO, A. C. A. Administração de Projetos. 2a. Edição. São Paulo: Editora Atlas S.A., 2002.OLSON J.S.; OLSON, G.M. Culture Surprises in Remote Software Development

Teams. Queue, January, 2004.PEDRAS, M. E. V. Uma Ferramenta de Apoio ao Gerenciamento de Desenvolvimento

de Software Distribuído. Maringá-Pr, 95 f. Dissertação de Mestrado em Informática. Universidade Estadual de Maringá/Universidade Federal do Paraná, 2003.

37

PFLEEGER, S. L. Software Engineering- Theory and Practice. 2nd edition, São Paulo: Prentice Hall, 2004.

PMI, A Guide to the Project Management Body of Knowledge- PMBOK. Project Management Institute. Pennsylvania-EUA: 2000.

POZZA, Rogério. Proposta de um Modelo para Cooperação baseado no Gerenciamento de Workspace no ambiente DiSEN. Dissertação (Mestrado em Ciência da Computação) - Departamento de Informática. Maringá-Pr: Universidade Estadual de Maringá, 2005.

POWELL, A. et al., Virtual Teams: A Review of Current Literature and Directions for Future Research. The DATABASE for Advances in Information Systems, Winter, 2000.

PRESSMAN, R. Engenharia de Software. 5a. Ed. Rio de Janeiro: McGraw-Hill, 2002.

PRIKLADNICKI, R.; AUDY, J.. MuNDDoS: Um Modelo de Referência para Desenvolvimento Distribuído de Software. In: 18 SBES - Simpósio Brasileiro de Engenharia de Software, 2004, Brasília. Proceedings... 2004.

REIS C. A. L. Uma abordagem flexível para execução de processos de software evolutivos. Tese (Doutorado) – Programa de pós-graduação em Ciência da

computação, Instituto de informática, Universidade Federal do Rio Grande do Sul. Porto Alegre: 2003, 267 p.

SEI, CMMI, CMU/SEI-2002-TR-011-Capability Maturity Model Integration, version 1.1, Staged Representation. Available from: http://www.sei.cmu.edu/ [Accessed 15 Apr 2005].

SOMMERVILLE, I. Engenharia de Software. 6. Ed., São Paulo: Addson Wesley, 2003.STEINMACHER, Igor; Wiese, Igor; Pozza, Rogério; Huzita, Elisa, H. M.; Amorim,

Éderson & Pascutti, Márcia. Uma proposta de arquitetura para ambientes de desenvolvimento distribuído de software. In: XI Congreso Argentino de Ciências de la Computación, 17-21 October 2005 Concordia-Entre Rios-Argentina, 2005.

TAIT, T. F. C. Um Modelo de Arquitetura de Sistemas de Informação para o Setor Público – um estudo em empresas estatais de informática. Tese (doutorado). Engenharia de Produção, Universidade Federal de Santa Catarina, 2000.

WERNER, C.; MANGAN, M.; MURTA, L.; PINHEIRO, R.; MATTOSO, M.; BRAGA, R.; BORGES, M. OdysseyShare: an Environment for Collaborative Component-Based Development. In: IEEE International Conference on Information Reuse and Integration, Las Vegas. 2003. Proceedings... v. 1. p. 61-68.

38