ENGENHARIA DE SOFTWARE
Prof. Jason
NOTAS DE AULA 1
1- O PRODUTO
Os Softwares são programas executados em computadores, porém com a finalidade de serem comercializados.
1.1 CARACTERÍSTICAS DO SOFTWARE:
a) O software é desenvolvido, mas não é manufaturado no sentido clássico.
b) O Software não se desgasta
c) O Software é desenvolvido por encomenda
1.2 APLICAÇÕES DO SOFTWARE
O software pode ser dividido nas seguintes aplicações:
Software de sistemas
É uma coleção de programas desenvolvidos para servir outros programas.
Ex. Compiladores(C++, Delphi,...) , protocolos para Internet, etc.
Software de tempo real
Monitora, analisa e controla eventos do mundo real à medida que eles ocorrem.
Ex. Softwares de automação para auto forno e laminadores.
Software Comercial
As aplicações desta área reestruturam dados existentes de modo a facilitar operações comerciais e de gestão de negócios.
Ex. software para folha de pagamento , controle de estoque, etc.
Software Embutido
Reside situado nas memórias ROM e é usado para controlar sistemas eletrônicos.
Ex. Controle de teclado para fornos de microondas, Controle de teclado para celulares, etc.
Software para computadores pessoais
São desenvolvidos para atuarem como ferramentas adicionais nos PC´s.
Ex. Processadores de texto, Software para criação de planilhas, Software para multimídia etc.
Software para Web
Utiliza instruções executáveis (código em Java, html,etc.) para criação de páginas na Internet.
Software com inteligência artificial
São desenvolvidos para resolver problemas complexos que não são possíveis de computação ou análises convencionais.
Ex. Softwares meteorológicos e para sondas espaciais.
Softwares científicos e para engenharia
São caracterizados por algoritmos que possuem matemática mais complexa.
Ex. Softwares para predição de sinal de telefonia celular (Software Ray-Tracing).
________________________________________
########
NOTAS DE AULA 2
1.3- SOFTWARE: UMA CRISE NO HORIZONTE
Muitos observadores da indústria do software caracterizam os problemas associados com os softwares atuais (bugs e falhas espetaculares) como uma crise. Uma das causas desta crise é o aumento da complexidade do software.
COMPLEXIDADE DO SOFTWARE
À medida que os computadores se tornaram mais sofisticados, em termos de hardware, também seus usuários e os softwares passaram a ser mais complexo.
Uma das técnicas para se vencer esta complexidade é construir programas pequenos (blocos) livres de erros e depois reuni-los (programação estruturada).
2- O PROCESSO
Outra estratégia para vencer a complexidade é utilizar modelos para o desenvolvimento dos softwares, assunto abordado a seguir.
2.1 -CICLO DE VIDA DO SOFTWARE
O ciclo de vida do software é um gráfico que contém várias etapas que devem ser seguidas para gerar um produto final melhor.
Primeira etapa: Análise
Nesta fase defina-se a melhor maneira de executar a tarefa e que recursos serão necessários.
Ex. Números de programadores, linguagem de programação, hardware, etc.
Segunda etapa : Projeto
Nesta fase determinam-se os Lay-outs das telas e características do software. Nesta etapa realizam-se reuniões com o cliente para eventuais críticas e sugestões ao projeto.
Terceira etapa: Código
Existe por todo o resto do ciclo de desenvolvimento e continua quando se faz alterações no código após a entrega.
Quarta etapa: Teste
O objetivo desta fase é testar o produto em relação aos requisitos concordados na especificação (Fase de projeto).
Quinta etapa: Manutenção
Quando o produto está pronto inicia-se a fase de manutenção. 80% do esforço e dinheiro são gastos nesta fase, principalmente nas soluções de bugs. Nesta etapa é aconselhável possuir uma boa documentação do software.
CRÍTICAS AO CICLO DE VIDA DO SOFTWARE
Este modelo é o mais antigo e usado, todavia, existem críticas, que são:
1-Os projetos reais raramente seguem o fluxo seqüencial que o modelo propõe.
2- Em geral é difícil para o cliente estabelecer todos os requisitos na fase inicial(Segunda etapa :Projeto).
3- Uma versão executável do projeto só vai ficar disponível no final do projeto.
##########
NOTAS DE AULA 3
2.2 MODELO DA PROTOTIPAGEM
É usado quando o cliente e o desenvolvedor não possuem noção dos detalhes do software que será produzido. Estes detalhes são:
Interface do software (Telas)
Adaptabilidade ao sistema operacional (Windows, Linux,...)
Insegurança em relação ao algoritmo
ETAPAS
1) Neste modelo o cliente e o desenvolvedor encontram-se e definem os objetivos gerais do projeto.
2) Um “software rápido” é então desenvolvido.
3) O protótipo é avaliado pelo cliente e usado para refinar os requesitos do software.
4) Interações ocorrem à medida que o protótipo é ajustado para satisfazer a necessidade do cliente.
CRÍTICAS A PROTOTIPAGEM
1- O protótipo funciona precariamente, portanto um questionamento rigoroso por parte do cliente em relação à qualidade do produto poderá ser realizada.
2- Um sistema operacional ou uma linguagem de programação poderá ser usada para demonstrar uma possibilidade, porém se não houver cuidado pode se tornar parte integral do sistema.
CONCLUSÃO
Apesar dos problemas, é importante definir as regras do jogo no início (protótipo). Depois o protótipo é descartado. Assim o software real é submetido à engenharia com o objetivo de buscar a qualidade.
_________________________________
######
NOTAS DE AULA 4
2.3- MODELO RAD (Rapid Application Development)
O modelo RAD é uma adaptação de alta velocidade do modelo seqüencial linear (ciclo de vida do software), no qual o desenvolvimento acelerado é conseguido com o uso de construção baseada em componentes reusáveis de programas existentes ou na criação destes componentes.
VANTAGENS
1- Na fase de teste, como uma grande parte dos componentes já foi testada, obtém-se um tempo total de teste reduzido.
2- Cada segmento do aplicativo pode ser desenvolvido por uma equipe RAD distinta e depois integrada para formar um todo.
DESVANTAGEM
O uso do modelo RAD é adequado quando o software faz uso de uma nova tecnologia ou quando exige um alto grau de interoperabilidade com o aplicativo.
_________________________________
######
NOTAS DE AULA 5
2.3 MODELO INCREMENTAL
Neste modelo os primeiros incrementos, que seguem como base o modelo seqüencial, são versões simplificadas do produto final.
Na fase de projeto, um plano é desenvolvido para o próximo incremento.
Ao contrário do modelo RAD, este não necessita que o software seja desenvolvido com objetos (componentes). Possuindo um uso mais geral.
É útil quando não há mão de obra disponível para uma implementação completa, visando o prazo comercial de entrega ou o sistema exigir um hardware novo, ainda em desenvolvimento.
O Primeiro incremento pode ser desenvolvido com menos pessoal, se o produto for bem recebido, então pessoal extra pode ser adicionado.
Exemplo de desenvolvimento de um software de processamento de texto utilizando o modelo incremental:
1)O software de processamento de texto no primeiro incremento poderia efetuar as funções de gestão de arquivos e edição de texto.
2) No segundo incremento, verificação gramatical e no terceiro incremento, capacidade avançada de disposição de páginas.
_________________________________
######
NOTAS DE AULA 6
2.5 MODELO ESPIRAL
Apresentado em 1988 em um congresso internacional por Boehm, B. , o modelo espiral é utilizado para sistemas de grande porte. Este paradigma mantém a abordagem sugerida pelo ciclo de vida do software clássico, mas incorpora uma estrutura interativa.
O primeiro circuito em torno da espiral gera versões mais simples do software. Na extremidade da espiral obtém-se versões mais sofisticadas.
Como as linhas de uma espiral são sempre contínuas, o desenvolvimento do software através de suas muitas versões, também não sofre descontinuidade, sendo projetado para um processo interativo, isto é, o software uma vez iniciado o seu desenvolvimento “não para” mais de ser desenvolvido.
Por ser um modelo novo, é necessário que este seja mais testado para verificar sua eficácia.
_________________________________
######
NOTAS DE AULA 7
3 CONCEITOS DE GESTÃO DE PRODUTOS
Nesta seção serão apresentados os conceitos e princípios básicos da gestão de projetos de software.
3.1 DEFINIÇÃO DE GESTÃO DO PRODUTO
É o termo que envolve o planejamento, controle de pessoal, controle de processo (modelos de desenvolvimento) e controle do produto (eventos que ocorrem à medida que o software evolui de um conceito preliminar para uma implementação operacional).
3.2. PESSOAL
Um estudo publicado por Curtis, B. et al., “A Field Study of the Software Design Process for Large Systems” , para a revista científica IEEE Trans. Software Engineering, vol. SC-31, em November 1988, demonstra que os vice presidentes de engenharia de 3 importantes empresas de tecnologia, consideram o item de maior importância para um projeto bem sucedido é obter um Pessoal competente.
3.2.1. OS PARTICIPANTES
O processo do software é composto por participantes classificados nas categorias :
1- Gerente Seniors
Definem o aspecto do negócio como empresa, legalmente estabelecida.
Realizam os contratos com o cliente, participação em concorrência, propaganda nos meios de comunicação, compra e aluguel dos escritórios e máquinas.
2- Gerente de Projetos
Planejam, motivam (encorajando os profissionais a produzir melhor e serem criativos), organizam (permitindo que o conceito inicial seja traduzido em um produto final) e controlam os profissionais que desenvolvem o software.
3- Profissionais
Fornecem as aptidões técnicas que são necessárias para o projeto.
4- Clientes
Especificam os requisitos para o software
5- Usuários Finais
Interagem com o software depois que este é liberado para o uso.
3.2.3 A EQUIPE DO SOFTWARE
A responsabilidade da organização dos profissionais (Programadores) é do gerente de projeto.
GERENTE SENIOR -> GERENTE DE PROJETO -> PROFFISIONAIS
Mantei em 1981 ( Mantei M., “The effect of programming team structures on programming tasks”, CACM, vol.24) sugere três tipos de organizações de equipe :
1- Democrática Descentralizada
Não possui líder permanente, sendo substituídos periodicamente. A comunicação entre os membros da equipe é horizontal.
2- Controlada Descentralizada
Possui um líder definido e líderes secundários (responsáveis por sub tarefas)
3- Controlada Centralizada
Possui um engenheiro sênior que planeja e revê todas as atividades técnicas das equipes.
Um engenheiro de retaguarda que apóia o engenheiro sênior nas suas atividades e pode substituí-lo , com perda mínima da continuidade do projeto.
3.2.4 CONCLUSÃO
Como resultado da pesquisa de Mantei [1981], obtém-se:
1- A estrutura Democrática Descentralizada resulta em moral elevada e satisfação no trabalho.
2- A estrutura Democrática Descentralizada é adequada para tratar problemas mais difíceis.
3- Quando a modularização é alta, a estrutura Controlada Centralizada ou a Controlada Descentralizada funcionarão bem.
4- As estruturas Controlada Descentralizada e Controlada Centralizada produzem menos falhas.
_______________________________
######
NOTAS DE AULA 8
3.3. O PRODUTO
Um gerente de projeto no início do desenvolvimento do software se depara com um dilema de um plano organizado, mas não há informação sólida disponível. Assim sendo a primeira atividade de gestão será o escopo do software.
3.3.1 O ESCOPO DO SOFTWARE
O escopo do software é definido pelas seguintes questões:
A) Contexto
Define com o software se encaixa no contexto maior (de um sistema maior ou de negócio) e suas restrições.
B) Objetivos da Informação
Que objetos de dados são necessários como entrada e saída de dados.
C) Função e Desempenho
Quais são as funções que o software desempenha para transformar os dados de entrada em dados de saída (usa modelos matemáticos ou acesso a banco de dados).
######
________________________________
NOTAS DE AULA 9
4- Métricas Orientadas ao Tamanho
4.1 Introdução
Medidas do Software
A medição é comum no mundo da Engenharia.
Mede-se Energia, Peso, Temperatura, ...
Infelizmente a medição no mundo da Engenharia de Software, apresentam dificuldades, sendo alvo de muitas controvérsias.
4.2 Medidas do Software
O Software é medido por muitas razões :
1- Indicar a qualidade do produto
2- Avaliar a produtividade das pessoas
3- Formar uma linha básica para estimativa (Custo, número de pessoas que trabalham no desenvolvimento do software,...)
4.3 Tabela de Métricas de tamanho
A partir dos dados brutos da tabela, um conjunto de métricas de qualidade e produtividade podem ser obtidos.
Medidas podem ser computadas levando em conta todos os projetos de uma empresa,e assim, obter métricas mais precisas
4.4 Formulações
Produtividade = K Linhas de Código / Pessoa Mês
obs: 12K Linhas de Código = 12000 Linhas de Código
Custo = US$ / K Linhas de Código
Qualidade = Defeitos / K Linhas de Código
4.5 Críticas aos Modelos Baseados em Linhas de Código (LOC Lines Of Code )
Os Cientístas a favor afirmam que este modelo é simples e é o parâmetro básico para os outros modelos.
Os Cientístas Contra, afirmam que as medidas usando como base Linhas de Código são dependentes da linguagem de Programação e penalizam os programas bem projetados (mais curtos).
Exercício
Calcule a Produtividade, a Qualidade e o Custo para o caso do programa do Laminador
######
________________________________
NOTAS DE AULA 10
VANTAGENS :
•Independentes da linguagem
######
________________________________
NOTAS DE AULA 10
CASE
O termo CASE (Computer- Aided Software Engineering) significa engenharia de software auxiliada por computador. Antigamente, os Ambiente de desenvolvimento de Sistemas (ADS’s) desenvolviam software para outras áreas, mas não se utilizavam de software para fazer o seu trabalho. Com a necessidade de produtividade e qualidade, os ADS’s foram obrigados a desenvolver também software para uso próprio.
Novas linguagens de computador (como as de quarta geração) devem ser projetadas para o analista, e não para o programador. Devem permitir que ele gere telas, relatórios, diálogos e banco de dados, e percorra os banco de dados e atualize-os com técnicas não-procedurais e diferentes daquelas de programação. Devem permitir que ele traduza seus projetos estruturados, construídos preferivelmente em um terminal gráfico, diretamente para código. Não será mais apropriado referir-se a essas como linguagens; devemos chamá-las de ferramentas CASE.
Existem dois tipos de ambientes CASE:
Lower CASE: ambientes mais simples, provêm suporte à codificação, teste,
depuração e manutenção do código.
Upper CASE: são ambientes mais complexos, automatizam diversas tarefas de análise e de projetos de sistemas e são capazes de gerar código automaticamente, a partir das especificações dadas.
Blocos de construção para o CASE
Arquitetura de ambiente
Plataforma de Hardware
Sistema Operacional
Serviços de Portabilidade
Estrutura de Integração
Ferramentas CASE
Blocos de construção para o CASE
A arquitetura de ambiente, composta pela plataforma de hardware e pelo suporte
do sistema operacional, são bases para o CASE.
Os serviços de portabilidade constitui uma ponte entre ferramentas CASE, suas estruturas de integração e a arquitetura de ambiente, permitindo que as ferramentas e a sua estrutura de integração migrem através de diferentes plataformas de hardware e sistemas operacionais sem manutenção adaptativa.
Estrutura de integração é uma coleção de
programas especializados que possibilitam que as ferramentas se comuniquem ,
criem um banco de dados de projetos, exibam a mesma aparência e transmitam a
mesma sensação ao usuário final.
Classificação das Ferramentas CASE
Fase de análise e projeto
Fase de programação
Fase de teste
Documentação
Fase de manutenção
Ferramentas para metodologias alternativas
Ferramentas Diagramáticas
Fase de análise de projeto
Ferramentas de Coleta: algumas utilizam questionário, outras entrevistas, fornecendo perguntas aos usuários. É importante que elas funcionem em rede de computadores, como são vários usuários devem registrar quem forneceu que informações e a quem elas estão disponíveis para análise ;
Ferramentas de Organização das Informações coletadas: técnicas de coleta apresentam como produto final um texto contendo informações sobre o sistema, essas ferramentas ajudam a análise destes textos permitindo que o analista gere um novo texto com informações corretas e completas;
Ferramentas de transformação de textos em diagramas: possuem técnicas de linguagem natural que permitem essa transformação;
Fase de Programação
Ferramentas de Interface: algumas geram a interface a partir de descrições feitas por um projetista, outras permitem a criação interativa da interfaces. Linguagens, como Delphi e VB, trazem essas ferramentas embutidas;
Ferramentas de Controle de consistência na entrada de dados: Uma ferramenta para essa tarefa pode ser gerada a partir de especificações armazenadas junto dos arquivos de dados, pelo projetista .
Geradores de aplicações: geram um código fonte automaticamente, entretanto, geram apenas aplicações de um certo tipo;
Fase de teste
Existem ferramentas que testam a definição de variáveis, se as operações realizadas sobre estas são compatíveis, se não há mudança de tipos de variáveis, se elas são usadas em algum lugar do programa e se elas se comportam realmente como variáveis ou como constantes.
Há também ferramentas que geram dados de entrada durante o teste funcional dos módulos e algumas verificam se as saídas do módulo correspondem as entradas fornecidas.
As interfaces também podem ser testadas, como por exemplo pode ser verificado se é possível entrar e sair dos menus.
Pode fazer teste de integração verificando a
compatibilidade entre os módulos ( as saídas de uns com as entradas de outros).
Documentação
As ferramentas de produção de documentos e de editoração eletrônica dão apoio a quase todos os aspectos de engenharia de software. As ferramentas de documentação geralmente estão ligadas a outras ferramentas CASE, usando-se uma ponte de dados implementada pelo fornecedor da ferramenta técnica. Essas ferramentas podem ser:
Gerador de manuais e Gerador de help
Fase de Manutenção
Engenharia reversa: é permitida a documentação de programas antigos não documentados. As ferramentas capta o código fonte como entrada e gera modelos gráficos de análises de projetos estruturados e outras informações;
Reengenharia: extraídas as informações de análise e projeto a partir de um código já existente, as ferramentas permitirão a reconstrução rápida do sistema no novo ambiente. Essas ferramentas oferecem significativas promessas mas são poucas as ferramentas de qualidade industrial encontradas em uso.
Gerenciador de Links: permite ligar todos os elementos e informações de todas as fases de desenvolvimento.
Ferramentas Diagramáticas
A diagramação interativa com as ferramentas CASE tem grandes vantagens: acelera significativamente o processo, reforça os padrões, possibilita ao computador executar várias checagens do que está sendo criado, permite automatizar o processo de documentação.
Alguns requisitos devem ser estabelecidos para o bom funcionamento dessas ferramentas, tais como: possibilitar a inclusão de objetos gráficos,de texto nos objetos, a movimentação, eliminação, alinhamento e união dos objetos, além de operações de COPY e PASTE, e outras.
Vantagens do CASE
Maior qualidade dos produtos finais;
Maior produtividade;
Mais tempo para a tomada de decisão;
Maior flexibilidade para mudanças;
Menos programação;
Melhor documentação;
Manutenção mais fácil e ágil.
Bibliografia:
PRESSMAN, Roger . Engenharia de Software.
MARTIN, James & McCLURE, Carma. Técnicas Estruturadas e CASE.
www.dcc.fua.br/~tem/newsmamail/case2.html
www.cos.ufrj.br/~randrade/case1.html
Revista Developers, junho 1998.
PROGRAMAÇÃO ORIENTADA A OBJETO
Introdução
Existem no mercado muitos livros e outras referências bibliográficas apresentando os conceitos da Tecnologia de Objetos e os benefícios de sua utilização. Além disso, a grande maioria dos softwares comerciais, especialmente os do ambiente Windows, já incorporam características orientadas a objetos. Porém, ainda percebe-se muito ceticismo na comunidade de profissionais de desenvolvimento de sistemas organizacionais. Em parte pela falta de cultura na utilização de metodologias, e muitas vezes por não acreditarem que é possível aplicar os conceitos OO em suas empresas.
São comuns casos em que se aplica análise baseada em objetos para especificação do sistema, mas a implementação é feita em um ambiente que não suporta a orientação a objetos. Em outros casos, parte-se de uma definição tradicional de sistema e o software é construído com uso de algum mecanismo de orientação a objetos, porém sem respeitar uma arquitetura verdadeiramente orientada a objetos. Em ambas as situações, não se obtêm todos os benefícios associados à Tecnologia de Objetos, e as iniciativas acabam sendo consideradas frustrantes ou pouco vantajosas.
A fim de se alcançar tais benefícios, é necessária a aplicação da orientação a objetos em todo o ciclo de desenvolvimento do sistema. Para tanto, obviamente, é preciso um completo entendimento da tecnologia e a obtenção de respostas para questões não abordadas pela bibliografia disponível.
######
________________________________
NOTAS DE AULA 11
Programação Orientada a Objetos
Programação orientada a objetos (POO) é uma metodologia de programação adequada ao desenvolvimento de sistemas de grande porte, provendo modularidade e reusabilidade. A POO introduz uma abordagem na qual o programador visualiza seu programa em execução como uma coleção de objetos cooperantes que se comunicam através de mensagens. Existem alguns aspectos importantes na definição de POO:
Usa objetos, e não funções ou procedimentos como seu bloco lógico fundamental de construção de programas
Objetos comunicam-se através de mensagens
Programação orientada a objetos dá ênfase à estrutura de dados, adicionando funcionalidade ou capacidade de processamento a estas estruturas. Em linguagens tradicionais, a importância maior é atribuída a processos, e sua implementação em subprogramas. Em uma linguagem como Pascal, procedimentos ativos agem sobre dados passivos que foram passados a eles. Em linguagens orientadas a objetos, ao invés de passar dados a procedimentos, requisita-se que objetos realizem operações neles próprios.
Alguns aspectos são fundamentais na definição de programação orientada a objetos, que serão devidamente investigados neste trabalho:
Abstração de dados
Objetos
Mensagens
Classes
Herança
Polimorfismo
Objetos
Na visão de uma linguagem imperativa tradicional (Pascal, C, COBOL, etc.), os objetos aparecem como uma única entidade autônoma que combina a representação da informação (estruturas de dados) e sua manipulação (procedimentos), uma vez que possuem capacidade de processamento e armazenam um estado local. Pode-se dizer que um objeto é composto de:
Propriedades: são as informações, estruturas de dados que representam o estado interno do objeto. Em geral, não são acessíveis aos demais objetos.
Comportamento: conjunto de operações, chamados de métodos, que agem sobre as propriedades. Os métodos são ativados (disparados) quando o objeto recebe uma mensagem solicitando sua execução. Embora não seja obrigatório, em geral uma mensagem recebe o mesmo nome do método que ela dispara. O conjunto de mensagens que um objeto está apto a receber está definido na sua interface.
Identidade: é uma propriedade que diferencia um objeto de outro; ou seja, seu nome.
Enquanto que os conceitos de dados e procedimentos são freqüentemente tratados separadamente nas linguagens de programação tradicionais, em POO eles são reunidos em uma única entidade: o objeto.
No mundo real não é difícil a identificação de objetos (em termos de sistemas, objetos são todas as entidades que podem ser modeladas, não apenas os nossos conhecidos objetos inanimados). Como exemplo, em uma empresa pode-se identificar claramente objetos da classe empregado.
Um empregado possui uma identidade própria, seu nome: José da Silva. Possui também propriedades como: endereço, idade, dependentes, salário, cargo, entre outras. O comportamento pode ser determinado por operações como: aumentar salário, listar dependentes e alterar cargo. As propriedades somente podem ser manipuladas através das operações definidas na interface do objeto, de modo que a forma de armazenamento das propriedades e a implementação das operações são desconhecidas pelas outras entidades externas (encapsulamento de informações).
Benefícios proporcionados pelos objetos:
Uma vez que objetos utilizam o princípio da abstração de dados, o encapsulamento de informação proporciona dois benefícios principais para o desenvolvimento de sistemas:
Modularidade: o código fonte para um objeto pode ser escrito e mantido independentemente da código fonte de outros objetos. Além disso, um objeto pode ser facilmente migrado para outros sistemas.
Ocultamento de informação: um objeto tem uma interface pública que os outros objetos podem utilizar para estabelecer comunicação com ele. Mas, o objeto mantém informações e métodos privados que podem ser alterados a qualquer hora sem afetar os outros objetos que dependem dele. Ou seja, não é necessário saber como o objeto é implementado para poder utilizá-lo.
Mensagens
Um objeto sozinho não é muito útil e geralmente ele aparece como um componente de um grande programa que contem muitos outros objetos. Através da interação destes objetos pode-se obter uma grande funcionalidade e comportamentos mais complexos.
Objetos de software interagem e comunicam-se com os outros através de mensagens. Quando o objeto A deseja que o objeto B execute um de seus métodos, o objeto A envia uma mensagem ao objeto B. Algumas vezes o objeto receptor precisa de mais informação para que ele saiba exatamente o que deve fazer; esta informação é transmitida juntamente com a mensagem através de parâmetros.
Uma mensagem é formada por três componentes básicos:
o objeto a quem a mensagem é endereçada (receptor)
o nome do método que se deseja executar
os parâmetros (se existirem) necessários ao método
Classe
"É a definição dos atributos e funções de um tipo de objeto. Cada objeto individual é então criado com base no que está definido na classe. Por exemplo, homo sapiens é um classe de mamífero; cada ser humano individual é um objeto dessa classe."
Objetos de estrutura e comportamento idênticos são descritos como pertencendo a uma classe, de tal forma que a descrição de suas propriedades pode ser feita de uma só vez, de forma concisa, independente do número de objetos idênticos em termos de estrutura e comportamento que possam existir em uma aplicação. A noção de um objeto é equivalente ao conceito de uma variável em programação convencional, pois especifica uma área de armazenamento, enquanto que a classe é vista como um tipo abstrato de dados, uma vez que representa a definição de um tipo.
Cada objeto criado a partir de uma classe é denominado de instância dessa classe. Uma classe provê toda a informação necessária para construir e utilizar objetos de um tipo, cada instância pertence a uma classe e uma classe pode possuir múltiplas instâncias. Devido ao fato de todas as instâncias de uma classe compartilharem as mesmas operações, qualquer diferença de respostas a mensagens aceitas por elas, é determinada pelos valores das variáveis de instância.
A existência de classes proporciona um ganho em reusabilidade. pois o código das operações e a especificação da estrutura de um número potencialmente infinito de objetos estão definidos em um único local, a classe. Cada vez que um novo objeto é instanciado ou que uma mensagem é enviada, a definição da classe é reutilizada. Caso não existissem classes, para cada novo objeto criado, seria preciso uma definição completa do objeto.
Benefícios proporcionados pelas classes:
O maior benefício proporcionado pela utilização das classes é a reusabilidade de código, uma vez que todos os objetos instanciados a partir dela incorporam as suas propriedades e seu comportamento.
Métodos
Um método implementa algum aspecto do comportamento do objeto. Comportamento é a forma como um objeto age e reage, em termos das suas trocas de estado e troca de mensagens.
Um método é uma função ou procedimento que é definido na classe e tipicamente pode acessar o estado interno de um objeto da classe para realizar alguma operação. Pode ser pensado como sendo um procedimento cujo primeiro parâmetro é o objeto no qual deve trabalhar. Este objeto é chamado receptor. Abaixo é apresentada uma notação possível para o envio de uma mensagem (invocação do método)
Construtores são usados para criar e inicializar objetos novos. Tipicamente, a inicialização é baseada em valores passados como parâmetros para o construtor. Destrutores são usados para destruir objetos. Quando um destrutor é invocado, as ações definidas pelo usuário são executadas, e então a área de memória alocada para o objeto é liberada. Em algumas linguagens, como C++, o construtor é chamado automaticamente quando um objeto é declarado. Em outras, como Object Pascal, é necessário chamar explicitamente o construtor antes de poder utilizá-lo.
Um exemplo de utilização de construtores e destrutores seria gerenciar a quantidade de objetos de uma determinada classe que já foram criados até o momento. No construtor pode-se colocar código para incrementar uma variável e no destrutor o código para decrementá-la.
Herança
O conceito de herança é fundamental na técnica de orientação a objetos. A herança permite criar um novo tipo de objeto - uma nova classe - a partir de outra já existente.
A nova classe mantém os atributos e a funcionalidade da classe da qual deriva; por isso, dizemos que ela "herda" as características daquela classe. Ao mesmo tempo, ela pode receber atributos e funções especiais não encontrados na classe original. Voltando ao exemplo da janela de um programa Windows, esse tipo de objeto poderia se chamar Janela. Ao criarmos um tipo de objeto para funcionar como caixa de diálogo é uma janela com atributos especiais, como a exibição de botões e opções.
O novo tipo poderia
se chamar JanelaDiálogo e herdaria as características da classe Janela,
recebendo também os atributos exclusivos de uma caixa de diálogo.
Uma das vantagens da herança é a facilidade de localizar erros de programação.
Por exemplo, caso um objeto derivado de outro apresente um erro de
funcionamento; se o objeto original funcionava corretamente, é claro que o erro
está na parte do código que implementa as novas características do objeto
derivado. A herança permite, também, reaproveitar o código escrito
anteriormente, adaptando-o às novas necessidades.
Isso é muito importante porque os custos de desenvolvimento de software são
muitos elevados. A mão-de-obra altamente especializada é cara; o processo é
demorado e sujeito a ocorrências inesperadas.
Polimorfismo
Polimorfismo refere-se à capacidade de dois ou mais objetos responderem à mesma mensagem, cada um a seu próprio modo. A utilização da herança torna-se fácil com o polimorfismo. Desde que não é necessário escrever um método com nome diferente para responder a cada mensagem, o código é mais fácil de entender. Por exemplo, sem polimorfismo, para inserir um novo empregado, seria necessário o seguinte código:
Colaborador1.InsereColaborador
Gerente1.InsereGerente
Presidente1.InserePresidente
Neste caso, Colaborador1, Gerente1 e Presidente1 são objetos das respectivamente das classes Colaborador, Gerente e Presidente. Com o polimorfismo, não é necessário ter um método diferente para cada tipo de objeto. Pode-se simplesmente escrever o seguinte:
Colaborador.Insere
Gerente.Insere
Presidente.Insere
Neste exemplo, os três diferente empregados têm três diferentes métodos para ser inseridos, embora o tenha sido utilizado o método com o mesmo nome. No código para esses empregados, seria necessário escrever três métodos diferentes: um para cada tipo de empregado. O mais importante a ser observado é que as três rotinas compartilham o mesmo nome.
Outra forma simples de polimorfismo permite a existência de vários métodos com o mesmo nome, definidos na mesma classe, que se diferenciam pelo tipo ou número de parâmetros suportados. Isto é conhecido como polimorfismo paramétrico, ou sobrecarga de operadores ("overloading"). Neste caso, uma mensagem poderia ser enviada a um objeto com parâmetros de tipos diferentes (uma vez inteiro, outra real, por exemplo), ou com número variável de parâmetros. O nome da mensagem seria o mesmo, porém o método invocado seria escolhido de acordo com os parâmetros enviados.
Benefícios proporcionados pelo polimorfismo
Legibilidade do código: a utilização do mesmo nome de método para vários objetos torna o código de mais fácil leitura e assimilação, facilitando muito a expansão e manutenção dos sistemas.
Código de menor tamanho: o código mais claro torna-se também mais enxuto e elegante. Pode-se resolver os mesmos problemas da programação convencional com um código de tamanho reduzido.
Relações entre Objeto, Classe e Herança
Objetos, classes e o mecanismo de herança permitem a definição de hierarquias de abstrações, que facilitam o entendimento e o gerenciamento da complexidade dos sistemas estudados. Isto porque classes agrupam objetos com características iguais, enquanto herança estrutura classes semelhantes.
Pode-se dizer que a grande vantagem do paradigma de objetos é a possibilidade de expressar diretamente este poder de modelagem conceitual numa linguagem de programação orientada a objetos. Assim, o modelo conceitual proposto durante a etapa de análise não se perde nas etapas de projeto e implementação. O que em geral ocorre é a sua extensão.
Avaliação da POO
A grande vantagem do paradigma de objetos é o seu caráter unificador: trata todas as etapas do desenvolvimento de sistemas e ambientes sob uma única abordagem. Nesse sentido, podemos ter análise, projeto, programação, banco de dados e ambientes orientados a objetos, eliminando as diferenças de "impedância" entre eles.
Vantagens da POO
A POO tem alcançado tanta popularidade devido às vantagens que ela traz. Entre elas podemos citar:
Reusabilidade de código
Escalabilidade de aplicações
Mantenabilidade
A reusabilidade de código é, sem dúvida, reconhecida como a maior vantagem da utilização de POO, pois permite que programas sejam escritos mais rapidamente. Todas as empresas sofrem de deficiência em seus sistemas informatizados para obter maior agilidade e prestar melhores serviços a seus clientes. Um levantamento feito na AT&T, a gigante das telecomunicações nos EUA, identificou uma deficiência da ordem de bilhões de linhas de código. Uma vez que a demanda está sempre aumentando, procura-se maneiras de desenvolver sistemas mais rapidamente, o que está gerando uma série de novas metodologias e técnicas de construção de sistemas (por exemplo, ferramentas CASE). A POO, através da reusabilidade de código, traz uma contribuição imensa nesta área, possibilitando o desenvolvimento de novos sistemas utilizando-se muito código já existente. A maior contribuição para reusabilidade de código é apresentada pela herança.
Escalabilidade pode ser vista como a capacidade de uma aplicação crescer facilmente sem aumentar demasiadamente a sua complexidade ou comprometer o seu desempenho. A POO é adequada ao desenvolvimento de grandes sistemas uma vez que pode-se construir e ampliar um sistema agrupando objetos e fazendo-os trocar mensagens entre si. Esta visão de sistema é uniforme, seja para pequenos ou grandes sistemas (logicamente, deve-se guardar as devidas proporções).
O encapsulamento proporciona ocultamento e proteção da informação. Acessos a objetos somente podem ser realizados através das mensagens que ele está habilitado a receber. Nenhum objeto pode manipular diretamente o estado interno de outro objeto. De modo que, se houver necessidade de alterar as propriedades de um objeto ou a implementação de algum método, os outros objetos não sofrerão nenhum impacto, desde que a interface permaneça idêntica. Isto diminui em grande parte os esforços despendidos em manutenção. Além disso, para utilizar um objeto, o programador não necessita conhecer a fundo a sua implementação.
O polimorfismo torna o programa mais enxuto, claro e fácil de compreender. Sem polimorfismo, seriam necessárias listas enormes de métodos com nomes diferentes mas comportamento similar. Na programação, a escolha de um entre os vários métodos seria realizada por estruturas de múltipla escolha (case) muito grandes. Em termos de manutenção, isto significa que o programa será mais facilmente entendido e alterado.
A herança também torna a manutenção mais fácil. Se uma aplicação precisa de alguma funcionalidade adicional, não é necessário alterar o código atual. Simplesmente cria-se uma nova geração de uma classe, herdando o comportamento antigo e adiciona-se novo comportamento ou redefine-se o comportamento antigo.
Desvantagens da POO
Apesar de das inúmeras vantagens, a POO tem também algumas desvantagens, que incluem:
Apropriação
Fragilidade
Linearidade de desenvolvimento
A apropriação é apresentada tanto como uma vantagem como uma desvantagem, porque a POO nem sempre soluciona os problemas elegantemente. Enquanto que a mente humana parece classificar objetos em categorias (classes) e agrupar essas classes em relacionamentos de herança, o que ela realmente faz não é tão simples. Em vez disso, objetos com características mais ou menos similares, e não precisamente definidas, são reunidos em uma classificação. A POO requer definições precisas de classes; definições flexíveis e imprecisas não são suportadas. Na mente humana, essas classificações podem mudar com o tempo. Os critérios para classificar objetos podem mudar significativamente. A apropriação utilizada na POO torna-a muito rígida para trabalhar com situações dinâmicas e imprecisas.
Além disso, algumas vezes não é possível decompor problemas do mundo real em uma hierarquia de classes. Negócios e pessoas têm freqüentemente regras de operações sobre objetos que desafiam uma hierarquia limpa e uma decomposição orientada a objetos. O paradigma de objetos não trata bem de problemas que requerem limites nebulosos e regras dinâmicas para a classificação de objetos.
Isto leva ao próximo problema com POO: fragilidade. Desde que uma hierarquia orientada a objetos requer definições precisas, se os relacionamentos fundamentais entre as classes chave mudam, o projeto original orientada a objetos é perdido. Torna-se necessário reanalisar os relacionamentos entre os objetos principais e reprojetar uma nove hierarquia de classes. Se existir uma falha fundamental na hierarquia de classes, o problema não é facilmente consertado. A mente humana adapta-se continuamente, e geralmente adequadamente, a situações novas. Ela encontra maneiras de classificar objetos no ambiente automaticamente. Enquanto a nossa mente tem essa capacidade, os ambientes POO não são tão bem equipados.
Em virtude dessa fragilidade, a POO requer análise e projeto frontal para assegurar que a solução é adequada. Com isto existe uma tendência em criar uma abordagem linear de desenvolvimento, em vez de cíclica. Infelizmente, alguns problemas são "perversos", o que significa que não se sabe como resolver um problema até efetivamente resolvê-lo. Tais problemas desafiam até mesmo os melhores projetistas e analistas de sistemas. Utilizar a abordagem de Desenvolvimento Rápido de Aplicações (RAD - Rapid Application Development, é utilizada pelo Delphi, SQL-Windows e outros ambientes de desenvolvimento para Windows adequados à prototipagem) com ciclos entre o projeto do protótipo, construção e realimentação do usuário é algumas vezes uma boa maneira de resolver problemas "perversos". Entretanto, a POO necessita de um projeto cuidadoso da hierarquia de classes, o que pode elevar os custos da sua utilização em um ambiente RAD.
Bibliografia:
BIO, Sérgio Rodrigues. Sistemas de Informação: um Enfoque Gerencial. Editora Atlas, 1985.
COAD, Peter; YOURDON, Edward. Análise Baseada em Objetos. Editora Campus, 1992.
COAD, Peter; YOURDON, Edward. Projeto Baseado em Objetos. Editora Campus, 1993.
COUGO, Paulo Sérgio. Modelagem Conceitual e Projeto de Banco de Dados. Editora Campus, 1997.
JONES, Meilir. O Que Todo Programador Deveria Saber Sobre Projeto Orientado a Objeto. Makron Books, 1997.
PRESSMAN, Roger S. Engenharia de Software. Makron Books do Brasil, 1995.
RUMBAUGH, James; BLAHA, Michael; PREMERLANI, William; EDDY, Frederick; LORESEN, Willian. Modelagem e Projetos Baseados em Objetos. Editora Campus, 1994.
INTERNET - ITEI – Istituto de Tecnologia Emergentee de Informação
__________________________________________________
Ferramentas de Gerenciamento de Projeto
Esta seção apresenta uma descrição sucinta de algumas ferramentas de
gerenciamento de projeto, sendo estas aplicadas no escopo de qualquer projeto (ou seja,
não são específicas para projeto de software). Este estudo foi efetuado visando analisar
as principais características das ferramentas existentes atualmente e, conseqüentemente,
embasar a proposta apresentada. Vale ressaltar que esta lista refere-se apenas a um
pequeno conjunto de ferramentas, existindo ainda diversas outras disponíveis.
3.6.1 FastTrack
O FastTrack é um software de gerenciamento de projetos, cuja interface é
ilustrada na Figura 14. Este software foi desenvolvido pela AEC software. O FastTrack
6.04a é a última versão do sistema, tendo sido desenvolvido em 1999, sendo que, para a
análise foi utilizada uma versão demo cuja única limitação é a não possibilidade de
salvar um projeto em disco.
O FastTrack tem como objetivo manter o histórico de projetos, atividades,
tarefas e prazos finais. No seu nível mais básico, o FastTrack é simplesmente um
gráfico de linha ao longo do qual são colocadas barras de atividade para representar os
começos e fins destas atividades, sendo este gráfico conhecido como Gráfico de Gantt.
Desta forma, o FastTrack automatiza a construção do gráfico de Gantt, refletindo
o começo e encerramento de atividades de forma gráfica.
Quando uma determinada linha/atividade é alterada no gráfico, automaticamente, dados como o custo de cada atividade e o valor total do projeto são alterados. Pode-se escolher entre 17 tipos diferentes de barras de atividade para denotar informações diferentes.
A qualquer instante é possível mudar o gráfico de Gantt para ver um maior ou
menor período de tempo, mudança estas disponibilizadas através das unidades para
exibição, que podem ser: tempo em horas, dias, semanas, meses, trimestre, ou anos, no
exemplo acima (Figura 14), pode-se notar que o software está usando o período em
semanas.
Em um primeiro instante as entradas de informações são textuais, ou seja, o
nome da tarefa, data de início, data de fim entre outras informações são incluídas na
base, após serem inseridas, pode-se trabalhar com as datas de início e fim das tarefas
diretamente no Gráfico de Gantt. Cada tarefa contém uma barra que representa o
período da atividade, podendo também esboçar as atividades em níveis diferentes, ou
seja, estruturar tarefas de forma hierárquica.
3.6.2 Task Manager
O Task Manager é um software de gerenciamento de projetos, podendo sua
interface ser visualizada na Figura 15. Este software foi desenvolvido pela Orbisoft,
cujo site encontra-se em http://www.orbisoft.com. A versão pesquisada foi desenvolvida
em 2000 e, atualmente, encontra-se na versão 1.00.729, sendo que, para a análise foi
utilizada uma versão demo, sem nenhuma restrição
O Task Manager 2000 foi especialmente projetado para ajudar a organizar e
administrar todos os trabalhos e tarefas de maneira simples, seguindo o padrão dos
wizards. Pode ser usado pessoalmente ou em um ambiente de equipe, podendo
administrar pessoal e compartilhar tarefas, trabalhos, e projetos. Este compartilhamento
é efetuado através da disponibilização do banco de dados em um único computador na
rede, através do qual os outros elementos da equipe acessam este computador para
usufruir as informações pertinentes a um determinado projeto.
Este software permite adquirir uma visão rápida de todas as tarefas, controlar
prazos finais, equilibrar automaticamente as cargas de trabalho, previsões de gargalos
de trabalho e tempos. Além disso, o Task Manager 2000 calcula automaticamente o
custo total de desenvolvimento do projeto, com base nos custos de cada pessoa, alocada
para participar do projeto.
Possui uma interface de fácil manuseio, mas é deficiente na parte de
relatórios/gráficos, onde possui alguns gráficos não parametrizados (não se tem opções
de escolher datas, o software demonstra sempre os últimos 5 anos) sobre alocação de
trabalho, custo/mês, tarefas/mês, entre outros. Não aborda gráficos significativos, como
por exemplo, o Gráfico de Gantt ou Gráfico de PERT, gráficos típicos de gerenciamento
de projetos, outro ponto negativo é sua lentidão para troca entre janelas. Possui um help
online, para dirimir qualquer dúvida sobre a aplicação .
3.6.3 Delegator
O Delegator é mais um software de gerenciamento de projetos, cuja interface
pode ser visualizada na Figura 16. Este software foi desenvolvido pela Madrigal Soft
Tools Inc, com sede no Canadá, sendo o seu site encontrado em
http://www.madrigalsoft.com. A versão pesquisada foi desenvolvida em 2000 e,
atualmente, encontra-se na versão 3.0, sendo que, para a análise foi utilizada uma
versão demo, sendo limitada para uso de apenas um usuário.
Delegator foi desenvolvido especialmente para gerentes e demais pessoas que
coordenam e administram as atividades de outras pessoas. O Delegator ajuda a localizar
as diversas tarefas dadas as pessoas, cargas de trabalho do pessoal, comunicar
prioridades, desempenho de pessoal com o passar do tempo e administrar projetos
incluindo muitas tarefas e envolvendo várias pessoas.
Como uma de suas características pode-se destacar o gráfico de Gantt que é
utilizado para visualizar as tarefas, referenciando os recursos humanos alocados, sendo
distribuídas por períodos de tempo podendo-se visualizar o gráfico por período de dias,
semanas, meses ou trimestre. Além disso, pode-se destacar o help on-line que auxilia no
entendimento da ferramenta.
Como ponto principal do software pode-se ressaltar os três planos do
cronograma que são dispostos no gráfico de Gantt, conforme pode ser visualizado na
Figura 16, ou seja, a barra em amarelo refere -se as datas do plano inicial traçado pelo
gerente para uma determinada tarefa, a barra vermelha refere-se ao plano mais recente
traçado pelo gerente, e por fim a barra de cor azul, faz referência ao cronograma
realmente traçado pela pessoa ou grupo responsável pela tarefa. Através destes três
planos é possível fazer um comparativo do andamento das tarefas, da concepção até a
conclusão da atividade.
Através desta ferramenta é possível gerar relatórios referentes ao histórico de
uma determinada pessoa, histórico de um grupo de pessoas, histórico de um projeto ou
de vários projetos, além de listar tarefas, entre outros. Todos os relatórios são
parametrizados por datas a serem definidas pelo usuário, tornando assim, uma
ferramenta de trabalho mais flexível.
Como pontos negativos se pode ressaltar a falta de interatividade do gráfico de
Gantt, pois as tarefas dispostas no gráfico só podem receber entradas de dados de
maneira textual. Além disto, pode-se destacar a falta de dependência entre as tarefas de
um projeto, ou seja, não se pode vincular uma tarefa a outra (estabelecer relação de
precedência).
3.6.4 Alexys Team
Alexsys Team é um sistema de administração de equipe para Windows que
organiza o trabalho de uma equipe ou organização. Através da utilização desta
ferramenta, em uma organização, os gerentes podem administrar o trabalho do grupo de
forma que:
· o grupo pode nomear tarefas coletivamente entre eles, ou seja, formar grupos
para executarem uma tarefa;
· os sócios da organização podem interagir e podem tomar decisões;
· o grupo pode descobrir quando uma tarefa não está procedendo dentro do
planejado.
Na instalação desta ferramenta são implantados dois bancos de dados: um banco
de dados novo e um banco de dados de amostra. O banco de dados novo permite aos
gerentes da organização registrar o trabalho de seus subordinados, enquanto o banco de
dados de amostra provê exemplos de como a ferramenta pode ser usada, através do qual
o usuário poderá se embasar para implementar o seu banco de dados.
O Alexys Team pode ser visualizado na Figura 17.
As informações pertinentes às atividades são previamente cadastradas em tabelas
anexas, para posteriormente serem referenciadas dentro da estrutura das atividades, ou
seja, cada item da estrutura de uma atividade, possui várias opções pré-definidas para
preenchimento, tornando o trabalho mais fácil e rápido. Além d isto, é possível passar as
informações de uma tarefa via e-mail para outra pessoa envolvida no projeto.
Como ponto positivo se pode destacar a flexibilidade de configuração do
ambiente de trabalho (cores do ambiente, informações a serem dispostas na tela, ordem
de disposição destas informações, fontes dos textos), ou seja, através de alguns
comandos simples é possível adaptar a área de trabalho ao estilo do usuário.
Outro ponto positivo a ser ressaltado é a possibilidade da criação de gráficos e
relatórios, ou seja, pode-se montar um gráfico ou relatório com qualquer informação
que esteja armazenada no banco de dados do sistema, tornando a ferramenta mais
flexível. Além disso, pode-se optar por vários estilos de gráficos para visualização
destas informações, por exemplo, gráfico de pizza, gráfico de linha, gráfico 3D, gráfico
de área entre outros. Podendo-se também salvar os gráficos e os relatórios em arquivos
anexos para futuras comparações.
Como ponto negativo se pode ressaltar a falta de um gráfico para gerenciamento
de tarefas e cronograma, como por exemplo, gráfico de Gantt e/ou gráfico de PERT,
pois através destes gráficos é possível melhor visualizar a distribuição das tarefas com
relação ao tempo do projeto, tarefas estas que só são listadas textualmente.
3.6.5 MS-Project
MS-Project é uma ferramenta para gerenciamento, organização e controle de
projetos. Para análise foi utilizada a versão 98 completa. A interface do Ms -Project pode
ser visualizada na Figura 18.
Figura 18: Interface MS-Project
A principal função do Ms-Project é gerenciar as tarefas em função do tempo.
Utiliza o gráfico de Gantt como o principal gráfico para visualizar tarefas. Através das
linhas pode-se inserir e modificar as descrições, durações, datas de início, datas de
término e outras informações sobre as tarefas. As barras estão preparadas para exibir
graficamente as durações das tarefas em uma escala de tempo.
Para um modo diferente de visualização das tarefas pode-se utilizar o gráfico de
PERT, que possui maior ênfase nas interdependências entre as tarefas.
O software disponibiliza um gráfico de recursos, sendo possível através deste verificar se não há alguém super alocado, ou seja, se algum recurso é atribuído para trabalhar mais horasem determinado período de tempo do que está disponível em seu calendário, podendo
assim, manter bem distribuídas as tarefas entre os seus funcionários.
Este software implementa a funcionalidade de efetuar previsões e evitar
problemas de agendamento antes que eles ocorram, considerando as tarefas que
ameaçam “estourar” o orçamento e/ou conflitos de agendamento que possam ultrapassar
o prazo do projeto.
Pode-se utilizar a linha de base (baseline) que contém estimativas originais de
custos, recursos e agendamento. Ao comparar as estimativas de sua linha de base com
as estimativas “atuais”, pode-se efetuar as alterações necessárias no plano do projeto.
O software possui recurso de hyperlink, onde o navegador da web é iniciado
localizando o endereço web especificado. Pode-se publicar informações do projeto em
estudo em formato HTML e seus gráficos em formato GIF.
Para receber e enviar mensagens do grupo de trabalho, os integrantes da equipe
usam caixa de entrada eletrônica. A caixa de entrada é utilizada pelo gerente do grupo
de trabalho para receber e armazenar respostas às mensagens de atribuição, atualização
e status que são enviados aos integrantes da equipe. Essas caixas de entrada devem estar
conectadas através de correio eletrônico, da Web ou rede interna (intranet ou web
interna). O grupo de trabalho poderá usar mensagens especiais de atribuição,
atualização e status do MS-Project para:
· Atribuir tarefas
· Aceitar ou recusar uma atribuição de tarefa
· Solicitar e submeter relatórios de status
· Enviar e receber atualizações de tarefas
Outro ponto positivo do MS-Project é a flexibilidade na geração de relatórios,
que compreendem um conjunto predefinido de informações detalhadas sobre o projeto,
o MS-Project possui mais de 20 relatórios predefinidos.
3.6.6 SuperProject
SuperProject é uma ferramenta destinada ao gerenciamento de projetos,
produzida pela Computer Associates, cuja interface pode ser visualizada na Figura 19.
O software pesquisado refere-se a versão 4.0, e não possui nenhuma restrição a sua
utilização.
O SuperProject é constituído de dois módulos. Um denominado Application
Program Interface que constitui o módulo principal do programa, onde encontra -se a
interface para o gerenciamento de projetos. O segundo módulo, denominado CARealizer
contem um linguagem de desenvolvimento para criar macros e aplicações.
Este software permite o gerenciamento de recursos, custo e tempo de projetos,
através de gráfico de Gantt e gráfico de PERT. Possui também a possibilidade do
usuário iniciar a criação de um projeto a partir de um template disponível. Quanto aos
relatórios, o SuperProject mostrou-se bastante versátil na construção dos mesmos.
No que se refere as variáveis utilizadas, o SuperProject não demonstrou
nenhuma restrição. Ou seja, pode-se configurar a unidade de tempo que se deseja
trabalhar (hora, dia, mês,...), o calendário (dia e hora) de cada recurso vinculado ao
projeto, dentre outros.
O SuperProject trabalha com diferentes visões do projeto, permitindo que se
visualize os recursos utilizados, ou os custos envolvidos, ou detalhamento das tarefas,
dentre outros.
Como item que o difere dos demais, está sua capacidade de trabalhar com
inclusão de outros projetos ou construir links com projetos externos. A diferença reside
no fato que se optando pela inclusão, o sistema anexará todo o projeto selecionado
como parte integrante de um mesmo projeto. No segundo caso, é permitida a inserção
de um link (vincular duas tarefas) entre projetos distintos. No entanto, esta operação é
permitida somente para projetos residentes em uma mesma máquina.
3.7 Análise Comparativa das Ferramentas de Gerenciamento de Projetos
Com base nas ferramentas de gerenciamento de projeto apresentadas, constatouse
que a maioria destas ferramentas trabalha com o gráfico de Gantt, sendo o gráfico de
PERT implementado em menor escala.
O recurso de baseline é implementado por
apenas duas das ferramentas: MS-Project e Delegator.
no que tange os relatórios pode-se destacar a flexibilidade do MS-Project que
oferece inúmeros relatórios aos usuários, sendo que, o software Alexys Team também
oferece bastantes opções neste item.
Vale ressaltar que todas as ferramentas apresentam um help para auxílio ao
“uso” da ferramenta, no entanto, destaca-se que o MS-Project expande o help para o
esclarecimento de conceitos vinculados ao gerenciamento de projeto.
Com relação ao suporte de trabalho em grupo ou projeto sendo desenvolvido de
forma distribuída apenas duas ferramentas apresentam algum suporte com este fim.
Sendo uma delas o MS-Project que permite salvar o projeto em HTML para
disponibilizar na Web e tem suporte a trabalho em equipe (utilizando recurso de e-mail,
sem uma visão distribuída). A outra ferramenta é o Alexys Team que visa o
gerenciamento do trabalho em equipe, mas assim como o MS-Project, considerando que
a aplicação não está sendo desenvolvida de maneira distribuída.
3.8 Considerações Finais
O gerenciamento de projetos é uma tarefa complexa que envolve a análise de
diversos fatores, tais como tempo, recursos e tarefa. Diversos são os instrumentos
existentes para auxiliar ao gerente dentre eles pode-se citar os gráficos de PERT e
Gantt, bem como, as ferramentas apresentadas.
O sucesso do projeto está fortemente atrelado ao efetivo gerenciamento do
processo tornando, portanto, indispensável o uso dos instrumentos citados pelo gerente.
Sendo que o principal objetivo de um gerenciamento de projeto é a busca pela
qualidade do produto e produtividade da empresa/pessoal, e considerando a frase citada
________________________________________________________________
“Bem-aventurados os misericordiosos, porque eles alcançarão misericórdia; Bem-aventurados os limpos de coração, porque eles verão a Deus;”
Mateus 5: 7 e 8