O que você achou do blogger?

segunda-feira, 29 de outubro de 2012

Planejamanto de projetos de softwares:Obejto e Restriçoes

FASES DOS PROJETOS
Todo projeto é divido em fases e possui uma estrutura de ciclo de vida semelhante. Por menor que seja, um projeto possui uma fase de início, uma fase intermediária e uma fase de término. O número de fases depende da complexidade do projeto e de sua área de aplicação. O conjunto de todas as fases do projeto constitui seu ciclo de vida.
Ao final de cada fase o Gerente de Projetos, o patrocinador (spansor) e os outros envolvidos têm a oportunidade de determinar se o projeto deve prosseguir para a próxima fase e detectar e corrigir os erros a um custo aceitável.
Cada fase gera um deliverable. Um deliverable é qualquer item ou resultado tangível e mensurável que deve ser produzido para se alcançar o objetivo do projeto ou de parte do projeto.
De forma geral e simplória, o Gerente de Projetos deve ter em mente as fases: PLANEJAMENTO, EXECUÇÃO e FINALIZAÇÃO.
Este artigo se propõe a esclarecer o “COMO” da fase de PLANEJAMENTO.
OBJETIVOS DO PLANEJAMENTO DE PROJETOS
O planejamento do projeto é responsável pela quantificação do tempo e orçamento que um projeto custará, reduzindo, assim, as incertezas relativas aos riscos e custos. Nesta etapa o planejamento das atividades é detalhado, os produtos a serem gerados são especificados, os índices de controles são definidos e o cronograma detalhado juntamente da WBS. São estabelecidos os marcos principais do projeto, conforme critérios gerais (entrega de produtos finais) ou específicos (encerramento de uma fase ou um marco financeiro, por exemplo, data de faturamento).
A finalidade do planejamento do projeto é criar um Plano do Projeto que possa ser utilizado para guiar tanto a Execução quanto o Controle do Projeto.
A seguir tentarei descrever um CASE EXEMPLO dos processos para a fase de PLANEJAMENTO.
PROCESSO DO PLANEJAMENTO DE PROJETOS (empresa fictícia)
1) TOMAR CIÊNCIA DAS INFORMAÇÕES GERAIS DO PROJETO:
PASSO-A-PASSO:
1.1) O Gerente do Projeto deve convocar* reunião, via e-mail, com o representante da Equipe de Negócios responsável pela relação comercial do projeto, para receber as seguintes informações que deverão ser formalizadas em Ata de Reunião.
  •   Visão do cliente quanto ao objetivo, necessidades e expectativas sobre o escopo do projeto;
  •   Recursos mínimos previstos para o projeto (rh, infra-estrutura, hardware e software);
  •   Questões políticas, problemas, objetivos implícitos sobre o cliente e produto proposto;
  •   Cópias das documentações dadas como aceitas pelo cliente (versão final), bem como cópia do edital de licitação e termo de sigilo caso tenham sido emitidos.
* Poderão ser convocadas também para a reunião outras pessoas de acordo com a complexidade do mesmo e as novidades técnicas inerentes ao trabalho, que justifiquem, a critério do Gerente do Projeto, estas participações.
2) DEFINIR O ESCOPO DO PROJETO:
PASSO-A-PASSO:
2.1) O Gerente do Projeto deve registrar as informações que confirmem as necessidades do projeto e desenvolver um entendimento comum do escopo entre as partes envolvidas e interessadas:
  • Descrição do escopo do produto: Incluem características do produto, serviço ou resultado para cuja criação o projeto foi idealizado. Essas características terão normalmente menos detalhes nas fases iniciais e mais detalhes nas fases posteriores, conforme as características do produto forem progressivamente elaboradas.
  • Limites do projeto: Declara de forma explícita, o que está excluído do projeto, para evitar que uma parte interessada possa supor que um produto, serviço ou resultado específico é um componente do projeto.
  • Objetivos do projeto: Incluem os critérios mensuráveis do sucesso do projeto, podendo ser objetivos técnicos, de negócios, custo, cronograma e qualidade. Podem incluir metas de custo, cronograma e qualidade.
  • Lista de fatores essenciais para o sucesso da implementação: Descreve os fatores críticos de sucesso do projeto.
  • Premissas do projeto: Lista e descreve as premissas específicas do projeto e o impacto potencial dessas premissas, se não forem confirmadas. Frequentemente, as equipes de projetos identificam, documentam e validam as premissas como parte do seu processo de planejamento. As premissas listadas na declaração do escopo detalhada do projeto são normalmente consideradas possíveis riscos ao projeto.
  • Restrições do projeto: Lista e descreve as restrições específicas do projeto que limitam as opções da equipe. Por exemplo, um orçamento predefinido ou datas impostas (marcos do cronograma) divulgadas pelo cliente ou pela organização executora. Quando um projeto for realizado sob contrato, em geral as cláusulas contratuais se constituirão em restrições.
  • Entregas do projeto (Subprodutos): Incluem o produto ou serviço do projeto, como resultados auxiliares, como documentação e relatórios de gerenciamento de projetos.
2.2) Uma vez definido e documentado o escopo, o Gerente de Projetos está apto a iniciar o ciclo de aprovações do escopo, conforme os seguintes procedimentos:
2.1.1) Definir Aprovadores de Escopo: Responsável (eis) pelas aprovações de escopo, podendo ser o responsável funcional pelo projeto e/ou o Patrocinador.
2.1.2) Solicitar Aprovação: Requerer a formalização da aprovação do escopo definido.
2.1.3) Fechar Escopo: Formalizar o que deve ser realizado no projeto, servindo de base para futuras decisões no projeto.
3) DEFINIR A ESTRUTURA ANALÍTICA DE TRABALHO DO PROJETO:
PASSO-A-PASSO:
3.1) O Gerente do Projeto deve reunir com a equipe do projeto, para dar início à elaboração da WBS.
  • A WBS pode ser criada totalmente nova ou reutilizar partes de outra WBS ou de modelos (templates) da organização.
  • Nesta hora os participantes devem consultar os documentos de alto nível que guiaram o escopo do projeto assim como entrevistas do cliente, de forma a identificar os subprodutos de cada fase.
3.2) O grupo deve iniciar colocando no primeiro nível (nível 0) da WBS o nome do projeto.
* Como exemplo, utilizaremos uma WBS de projeto de software.

3.3) Em seguida, colocar no segundo nível (nível 1, também chamado de primeiro nível de decomposição) as fases que estabelecem o ciclo de vida do projeto. Por exemplo:

Listar as atividades e tarefas dentro de cada componente principal, subdividindo cada componente até ter um nível de detalhe suficiente para suportar o plano.

O que é considerado um nível de detalhe suficiente? Tome em consideração estes fatores:
i. Para cada subproduto (deliverable), verificar se as estimativas de custo e tempo, assim como a identificação de riscos, podem ser desenvolvidos neste nível de detalhe e se é possível atribuir a responsabilidade para a execução do mesmo. Se a resposta for negativa, decompor o elemento da WBS em componentes menores até que possa responder essas questões, visando o melhor desenvolvimento dos processos de Gerenciamento de Projeto (Planejar, Executar, Controlar e Encerrar).
ii. Uma boa heurística a seguir é a regra do 8-80: exige-se que um pacote de trabalho ocupe entre 8 e 80 horas de duração, a variação é de acordo com o ciclo de acompanhamento, de modo que seja possível identificar: Um código de identificação único; um subproduto específico e verificável; um único responsável pela sua entrega.
iii. Se você não tem informações suficientes para criar uma WBS para todas as fases do projeto, você pode usar a técnica de Planejamento em ondas sucessivas ou Elaboração progressiva, ou do inglês, Rolling Wave Planning (RWP). Neste caso, você terá que construir uma WBS bem definida da primeira fase do projeto e quando esta fase estiver quase completa, você terá informações suficientes para construí uma WBS mais completa para a fase seguinte. Então você continuara este processo até o final do projeto.

Comentário:O planejamento do projeto é responsável pela quantificação do tempo e orçamento que um projeto custará, reduzindo, assim, as incertezas relativas aos riscos e custos.Uma boa heurística a seguir é a regra do 8-80: exige-se que um pacote de trabalho ocupe entre 8 e 80 horas de duração, a variação é de acordo com o ciclo de acompanhamento, de modo que seja possível identificar

segunda-feira, 1 de outubro de 2012

Método orientado a objetos

As técnicas orientadas a objeto permitem que o software seja construído de objetos que tenham um comportamento especifico. Os próprios objetos podem ser construídos a partir de outros, os quais, por sua vez, podem ainda ser construídos de outros.
A análise de sistemas no mundo orientado a objeto é feita analisando-se os objetos e os eventos que interagem com esses objetos. O projeto de software é feito reusando-se classes de objetos existentes e quando necessário, construindo-se novas classes.
Técnicas orientadas a objeto podem ser usadas para simplificar o projeto de sistemas complexos. O sistema pode ser visualizado como uma coleção de objetos, estando cada um dos objetos em um determinado estado. Os objetos são construídos a partir de outros objetos.
A análise e o projeto orientados a objeto modelam o mundo em termos de objetos que tem propriedades e comportamentos e eventos que disparam operações que mudam o estado dos objetos. Os objetos interagem com outros objetos.
A modelagem e o projeto orientados a objeto são os paradigmas que devem integrar todas as ferramentas e técnicas poderosas para a criação de software. Estratégia de desenvolvimento baseada no conceito de que o sistema deve ser construído a partir de componentes reutilizáveis, chamados de objetos.

Conceitos
Entre as idéias fundamentais básicas para a tecnologia orientada a objeto incluem-se:
  • Objetos;
  • Classes;
  • Métodos;
  • Herança;
  • Encapsulamento;
  • Objeto
  • Um objeto pode ser real ou abstrato.
  • Os objetos possuem informações (contém dados) e desempenham ações (possuem funcionalidade).
  • Qualquer coisa à qual um conceito ou tipo de objeto se aplica – uma instância de um conceito ou tipo de objeto.
  • Um objeto é uma instância de uma classe.
  • Encapsulamento
    O ato de empacotar ao mesmo tempo dados e objetos é denominado encapsulamento. O objeto esconde seus dados de outros objetos e permite que os dados sejam acessados por intermédio de seus próprios métodos. Isso é chamado de ocultação de informações (information hiding).
  • O encapsulamento protege os dados do objeto do uso arbitrário e não-intencional.
  • O encapsulamento é o resultado (ou ato) de ocultar do usuário os detalhes da implementação de um objeto.
  • O encapsulamento é importante porque separa a maneira como um objeto se comporta da maneira como ele é implementado.
  • A definição de como implementar os conhecimentos ou ações de uma classe, sem informar como isto é feito.
  • Classe
    O termo classe refere-se à implementação de software de um tipo de objeto. Um tipo de objeto especifica uma família de objetos sem estipular como o tipo e o objeto são implementados. Os tipos de objetos são especificados durante a análise OO. Os tipos de objetos são implementados como módulos enquanto na linguagem orientada a objeto, os tipos de objetos são classificados como classes.
  • Uma classe é uma implementação de um tipo de objeto.
  • Uma classe especifica uma estrutura de dados e os métodos operacionais permissíveis que se aplicam a cada um de seus objetos.
  • Uma classe pode ter sua própria estrutura de dados e métodos, bem como herda - lá de sua superclasse.
    Herança
    É comum haver similaridades entre diferentes classes. Frequentemente, duas ou mais classes irão compartilhar os mesmos atributos e/ou métodos. Como nenhum de nós deseja reescrever várias vezes o mesmo código, seria interessante se algum mecanismo pudesse tirar proveito dessas similaridades. A herança é esse mecanismo. Por intermédio da herança, é possível modelar relacionamentos do tipo "é" ou "é semelhante", o que nos permite reutilizar rotinas e dados já existentes.
    Uma subclasse herda as propriedades de sua classe-mãe; uma subclasse herda as propriedades das subclasses e assim por diante. Uma subclasse pode herdar a estrutura de dados e os métodos, ou alguns dos métodos, de sua superclasse. Ela também tem métodos e às vezes, tipos de dados próprios.

     Conclusão:
    O método orientado a objeto é um recurso atualmente muito utilizado e simples na Informática, o método orientado a objeto funcionam a partir de outros objetos, a análise de sistemas que são orientado a objeto é feita a partir de outros  objetos e que interagem com esses objetos e assim virso verses.
    O método orientado a objeto ele contribui muito para uma boa estrutura e qualidade que se pode ser utilizados.