Santa Luzia2015

VINICIUS DE SOUZA FONSECA

SISTEMA DE ENSINO PRESENCIAL CONECTADOANALISE E DESENVOLVIMENTO DE SISTEMAS

GESTÃO DO PROCESSO DE DESENVOLVIMENTO I

Santa Luzia2015

GESTÃO DO PROCESSO DE DESENVOLVIMENTO I

Trabalho de Gestão do Processo de Desenvolvimento I. apresentado à Universidade Norte do Paraná - UNOPAR, como requisito parcial para a obtenção de média semestral nas disciplinas Projeto Orientado a Objetos, Engenharia e Projeto de Software, Programação para Web II.

VINICIUS DE SOUZA FONSECA

SUMÁRIO

1 INTRODUÇÃO......................................................................................................3

2 DESAFIO 1...........................................................................................................4

2.1 Gerenciamento de riscos do projeto.................................................................4

2.1.1 Planejar o gerenciamento dos riscos............................................................4

2.1.2 Identificar os riscos........................................................................................4

2.1.3 Realizar a análise qualitativa dos riscos........................................................5

2.1.4 Realizar a análise quantitativa dos riscos......................................................5

2.1.5 Planejar respostas aos riscos........................................................................5

2.1.6 Controlar os riscos.........................................................................................5

2.2 GERENCIAMENTO DO ESCOPO DO PROJETO...........................................6

2.2.1 Principais tópicos...........................................................................................7

2.2.2 Opinião pessoal.............................................................................................8

2.3 fornecedores.....................................................................................................8

2.4 Partes Interessadas..........................................................................................9

3 Desafio 2............................................................................................................11

3.1.1 Decisões de projeto de arquitetura..............................................................11

3.1.2 Organização de sistema..............................................................................11

3.1.2.1 Modelo de repositório..................................................................................11

3.1.2.2 Modelo cliente-servidor...............................................................................11

3.1.2.3 Modelo de máquina abstrata (em camadas)...............................................12

3.1.3 Estilos de decomposição modular...............................................................12

3.1.4 Modelos de objetos.....................................................................................12

3.1.4.1 Decomposição Orientada a Objeto.............................................................12

3.1.4.2 Pipelining orientado a funções....................................................................13

3.1.5 Arquiteturas de referência...........................................................................13

3.1.5.1 Controle centralizado...................................................................................14

3.1.5.2 Sistemas orientados a eventos...................................................................14

4 Desafio 3............................................................................................................15

4.1.1 Programação para Web II...........................................................................15

4.1.1.1 Comparação de frameworks para desenvolvimento web (Java).................15

4.1.1.2 Relacione os custos/benefícios de usar frameworks no desenvolvimento

Web 16

4.1.1.3 Programação Java Web (plataforma de desenvolvimento).........................17

5 CONCLUSÃO.....................................................................................................18

REFERÊNCIAS.........................................................................................................19

1 INTRODUÇÃO

Na vida cotidiana sempre convivemos com riscos. Podemos por

exemplo: ser assaltados, contrair doenças ou sofrer um acidente de carro. Para

esses casos há soluções simples como: ter o veículo segurado, vacinar-se ou andar

com cinto de segurança. Dentro de um projeto de desenvolvimento de um sistema

não é diferente.

Corre-se o risco de indesejáveis surpresas. Há situações em que

poderá incidir um risco grave e que poderá significar o fracasso do próprio projeto.

A Gerência de Riscos está presente em várias metodologias de

Gestão de Projetos. Neste trabalho será escolhido como base o modelo de

Gerenciamento de Riscos do PMBOK (Project Management Body of Knowledge)

desenvolvido pelo PMI (Project Managemanent Institute).

O fator de maior peso na escolha do PMBOK como o modelo a ser

detalhado é o fato de existir uma disciplina ou grupo de processos que se dedica ao

estudo do risco.

3

2 DESAFIO 1

2.1 GERENCIAMENTO DE RISCOS DO PROJETO

O risco do projeto é um evento ou condição incerta que, se ocorrer,

terá um efeito positivo ou negativo sobre pelo menos um objetivo do projeto, como

tempo, custo, escopo ou qualidade.

Um risco pode ter uma ou mais causas e, se ocorrer, um ou mais

impactos.

2.1.1 Planejar o gerenciamento dos riscos

Indica como conduzir as atividades de gerenciamento dos riscos de

um projeto.

Riscos mais comuns tem consequências que impactam o

escopo, cronograma, custo, e/ou qualidade.

A causa pode ser um requisito, premissa, restrição, ambiente

e/ou condição que tenha efeito sobre os itens acima.

2.1.2 Identificar os riscos

Identificar os riscos é o processo de determinação dos riscos que

podem afetar o projeto e de documentação de suas características. O principal

benefício desse processo é a documentação dos riscos existentes e o conhecimento

e a capacidade que ele fornece à equipe do projeto de antecipar os eventos.

2.1.3 Realizar a análise qualitativa dos riscos

A classificação relativa ou a lista de prioridades dos riscos do

projeto. Riscos agrupados por categorias. Causas dos riscos. Lista de riscos que

exigem resposta a curto prazo. Lista de riscos para análise e resposta adicionais.

Lista de observação de riscos de baixa prioridade. Tendências dos resultados da

análise qualitativa de riscos.

4

2.1.4 Realizar a análise quantitativa dos riscos

É realizada nos riscos que foram priorizados pelo processo

Análise qualitativa dos riscos por afetarem potencial e significativamente as

demandas conflitantes do projeto, analisa o efeito desses eventos de risco e lhes

atribui uma classificação numérica.

Apresenta uma abordagem quantitativa para a tomada de

decisões na presença da incerteza.

Usa técnicas como a simulação de Monte Carlo e a análise da

árvore de decisão.

2.1.5 Planejar respostas aos riscos

O planejamento de respostas a riscos é o processo de desenvolver

opções e determinar ações para aumentar as oportunidades e reduzir as ameaças

aos objetivos do projeto.

As respostas a riscos planejadas precisam ser adequadas à

importância do risco, econômicas ao enfrentar o desafio, rápidas, realistas dentro do

contexto do projeto, acordadas por todas as partes envolvidas e ser de propriedade

de uma pessoa específica.

É frequentemente necessário selecionar a melhor resposta a

riscos a partir de diversas opções.

2.1.6 Controlar os riscos

Controlar os riscos é o processo de implementação de planos de

respostas aos riscos, acompanhamento dos riscos identificados, monitoramento dos

riscos residuais, identificação de novos riscos e avaliação da eficácia do processo de

riscos durante todo o projeto. O principal benefício desse processo é a melhoria do

grau de eficiência da abordagem dos riscos no decorrer de todo o ciclo de vida do

projeto a fim de otimizar continuamente as respostas aos riscos.

2.2 GERENCIAMENTO DO ESCOPO DO PROJETO

O capítulo 5 aborda o tema gerenciamento do escopo do projeto,

5

que são os processos necessários para garantir que o projeto atenda aos requisitos

básicos para que o projeto possa ser terminado com sucesso. Com isto, podemos

definir os limites do projeto mostrando para o cliente o que ele pode ou não esperar

como resultado dos trabalhos do projeto.

Devemos lembrar que para iniciarmos o gerenciamento do escopo

do projeto, devemos ter já prontos o project charter e a declaração do escopo

preliminar do projeto, pois a partir destes, iremos nos aprofundar no projeto e

iniciarmos o plano de gerenciamento do escopo do projeto, detalhando os trabalhos.

Dentre os processos, estão descritos a estrutura necessária para o

desenvolvimento do planejamento do escopo, da definição do escopo, da criação da

EAP, da verificação do escopo (onde o projeto sofre as verificações para uma

entrega) e do controle do escopo (onde o projeto sofre mudanças).

Em cada um deles o capítulo 5 do PMBOK nos mostra quais os

componentes necessários para serem utilizados como forma de entrada de

informações para estes processos e destes, quais as suas origens, e por vezes

fazendo referências a outros capítulos que teriam maiores informações. Também

nos mostra como deve ser o processamento das informações provenientes destas

entradas para que o resultado destes processamentos sejam as saídas

demonstradas em cada um deles, nos quais descrevo abaixo:

- No processo de planejamento do escopo onde a saída é o plano de

gerenciamento do escopo do projeto, o capítulo aponta as entradas e dá diretrizes

para extrair estas informações onde podemos notar que destas, até mesmo as

condições de mercado poderiam afetar a forma como deveria ser gerenciado o

escopo do projeto. Na saída deste item, teremos a informação necessária de como o

escopo do projeto será definido, documentado, verificado, gerenciado e controlado

pela equipe de gerenciamento de projetos.

- No processo de definição do escopo descrevemos mais

detalhadamente o escopo do projeto, pois, ao planejar temos uma visão mais

abrangente do projeto, tendo como saída a declaração do escopo do projeto, a

6

atualização do escopo do projeto, assim como o processamento das mudanças

aprovadas.

- No processo de criação da EAP, identificamos as entregas através

da decomposição total dos trabalhos do projeto em componentes menores para que

seja possível o gerenciamento de uma forma mais fácil. Neste processo, também é

importante o dicionário da EAP, onde descrevemos o que é e como deve ser feito

cada entrega.

- No processo de verificação do escopo temos um controle das

entregas terminadas para que estas possam ser aceitas ou sofrerem solicitações de

mudanças e/ou correções.

- No processo de controle do escopo é implementado o controle do

impacto das mudanças sobre o escopo do projeto, e é responsável por atualizações

nos documentos gerados pelos outros processos, como a declaração do escopo, a

EAP e seu dicionário e o plano de gerenciamento do escopo do projeto.

2.2.1 Principais tópicos

§ Planejamento do escopo – como podemos gerenciar de forma

efetiva para obter o sucesso do projeto.

· Saída: Plano de gerenciamento do projeto

§ Definição do escopo – definição detalhada do escopo do projeto

· Saídas – Declaração de escopo do projeto

§ Criar EAP – definição dos entregáveis do projeto

· Saídas – EAP e dicionário de EAP

§ Verificação do escopo – validação das entregas com o escopo

definido

· Saídas - entregas aceitas ou solicitações de mudanças e/ou

correções

§ Controle do escopo – gerenciamento das solicitações de

mudanças

7

· Saídas – atualizações do plano de gerenciamento do projeto, da

declarações de escopo do projeto e da EAP

2.2.2 Opinião pessoal

O gerenciamento do escopo do projeto é fundamental principalmente

na área de tecnologia da informação para ajudar na documentação dos projetos.

Ainda existem muitos projetos do tipo “eternos”, que por não terem sido

documentados o seu escopo, estes nunca acabaram.

Porém, estes processos devem ser muito bem dosados devido ao

seu alto número de documentação gerada, que pode criar um ambiente

demasiadamente burocrático. Para garantir a dose certa, o gerente de projetos deve

possuir o feeling necessário para desenvolver as informações dos documentos de

acordo com o cliente e o projeto a ser desenvolvido.

Particularmente tinha muitas dúvidas em relação sobre como

controlar o escopo de projetos devido a quantidade de solicitações feitas pelos

usuários, que no meu caso são os gerentes e diretores da empresa onde trabalho.

Para isso a EAP foi fundamental onde já a utilizei para demonstrar o status atual do

projeto que estou trabalhando. A visualização das tarefas fica muito simples e ajuda

até mesmo a demonstrar as dimensões do projeto.

2.3 FORNECEDORES

O PMBoK diz que esta área inclui os processos necessários para

comprar ou adquirir produtos, serviços ou resultados externos à sua equipe do

projeto. Veja que em um projeto, nem sempre será possível desenvolver seus

produtos, ferramentas e serviços, sendo necessária a compra ou aquisição dos

mesmos. Os objetivos desta área são: Aumentar a eficiência em

compras/aquisições; Fazer o melhor uso dos recursos internos e externos; Acelerar

o cronograma – Podemos utilizá-los para terceirizar um serviço ou comprar algo

pronto do que desenvolver internamente no projeto; Gerenciar/melhorar os custos –

Procurar a melhor forma de obter um melhor ROI; Reduzir os riscos relacionados, já

8

que são grandes fonte de riscos; Existem apenas 4 processos nesta área:

Iniciação Planejamento

Execução

Monitoramento e Controle

Encerramento

2.4 PARTES INTERESSADAS

São todas as pessoas e organizações envolvidas no projeto, ou

cujos interesses podem ser positiva ou negativamente afetados pela realização ou

pelos resultados do projeto. As partes interessadas também podem exercer

influência sobre o projeto e sobre os membros da equipe do projeto. [PMI 2008, p.

23]

Desde a iniciação do projeto, a equipe de gerenciamento precisa

identificar as partes interessadas internas e externas. Ao longo do planejamento e

da execução do projeto, o gerente do projeto e sua equipe devem gerenciar as

diferentes necessidades, preocupações e expectativas das partes interessadas, bem

como a influência destas no projeto, para garantir um resultado bem sucedido.

Alguns exemplos de possíveis partes interessadas podem incluir:

Patrocinador (Sponsor): pessoa ou grupo que fornece os recursos

financeiros para a realização do projeto, e que também provê o aval estratégico e

político que viabiliza e promove o projeto e o defende;

A equipe do projeto, que inclui o gerente do projeto, a equipe de

gerenciamento do projeto, e outros membros da equipe que executam trabalho no

projeto mas não estão necessariamente envolvidos com o gerenciamento:

Clientes e usuários;

Presidente, donos e executivos;

Acionistas e investidores;

Gerentes funcionais;

9

Escritório de projetos (Project Management Office - PMO),

gerentes e comitês de portfólios e de programas;

Fornecedores e parceiros comerciais;

Concorrentes;

Governo, em suas diversas esferas e poderes;

Organismos de regulação e fiscalização internos e externos,

incluindo auditorias, agências, conselhos, sindicatos e associações institucionais,

profissionais e oficiais;

Organizações não governamentais (ONG);

Comunidades, vizinhança e população abrangida pelas ações e

resultados do projeto.

Outros elementos importantes que influenciam projetos são as

culturas e estilos organizacionais, bem como os fatores ambientais da empresa, do

mercado, da sociedade e da localização geopolítica onde o projeto acontece.

10

3 DESAFIO 2

3.1.1 Decisões de projeto de arquitetura

Projeto de arquitetura é um processo criativo cujas atividades

diferem radicalmente dependendo do tipo de sistema que está sendo desenvolvido.

Contudo, uma série de decisões comuns afetam todos os processos

de projeto.

3.1.2 Organização de sistema

Reflete a estratégia básica que é usada para estruturar um sistema.

Três estilos de organizações são amplamente usados:

O estilo de repositório de dados compartilhados;

Estilo de serviços e servidores compartilhados;

Estilo de máquina abstrata ou em camadas.

3.1.2.1 Modelo de repositório

Os subsistemas devem trocar dados. Isso pode ser feito de duas

maneiras:

Os dados compartilhados são mantidos em um banco de dados

central ou repositório e podem ser acessados por todos os subsistemas;

Cada subsistema mantém seu próprio banco de dados e passa

dados explicitamente para outros subsistemas.

Quando grandes quantidades de dados são compartilhadas, o

modelo de repositório de compartilhamento é o mais usado.

3.1.2.2 Modelo cliente-servidor

É um modelo distribuído de sistema que mostra como dado e

processamento são distribuídos por uma variedade de componentes.

Estabelece servidores independentes que fornecem serviços

11

específicos, tais como impressão, gerenciamento de dados, etc.

Estabelece clientes que acessam esses serviços.

É uma rede que permite aos clientes acessar os servidores.

3.1.2.3 Modelo de máquina abstrata (em camadas)

Usado para modelar o interfaceamento dos subsistemas.

Organiza o sistema em um conjunto de camadas (ou máquinas

abstratas), cada uma dss quais fornecendo um conjunto de serviços.

Apoia o desenvolvimento incremental dos subsistemas em camadas

diferentes. Quando uma camada de interface muda, somente a camada adjacente é

afetada.

Contudo, é frequentemente artificial estruturar sistemas dessa

maneira.

3.1.3 Estilos de decomposição modular

Estilos de decomposição de subsistemas em módulos.

Não há distinção rígida entre organização de sistema e

decomposição modular.

3.1.4 Modelos de objetos

Estruturar o sistema em um conjunto de objetos fracamente

acoplados com interfaces bem definidas.

A decomposição orientada a objetos está relacionada à identificação

de classes de objetos, aos seus atributos e às suas operações.

Quando implementados, os objetos são criados a partir dessas

classes e um tipo de controle é usado para coordenar as operações de objetos.

3.1.4.1 Decomposição Orientada a Objeto

Estruturar o sistema em um conjunto de objetos fracamente

acoplados com interfaces bem definidas.

12

A decomposição orientada a objetos está relacionada à identificação

de classes de objetos, aos seus atributos e às suas operações.

Quando implementados, os objetos são criados a partir dessas

classes e um tipo de controle é usado para coordenar as operações de objetos.

3.1.4.2 Pipelining orientado a funções

Transformações funcionais processam suas entradas para produzir

saídas.

Pode ser chamado de estilo de duto (pipe) e filtro (como no shell

UNIX)

Variações dessa abordagem são muito comuns. Quando as

transformações são sequenciais, isso é um modelo sequência em lotes, que é

extensivamente usado em sistemas de processamento de dados.

Não é realmente adequado para sistemas interativos.

3.1.5 Arquiteturas de referência

Os modelos de arquitetura podem ser específicos para algum

domínio de aplicação.

Existe dois tipos de modelos de domínio específico

Modelos genéricos que são abstrações de uma série de sistemas

reais que englobam as características principais desses sistemas. Abordados no

Capítulo 13.

Modelos de referência são mais abstratos, é um modelo idealizado.

Fornece um meio de informação sobre essa classe de sistema e sobre comparação

de arquiteturas diferentes.

Os modelos genéricos são geralmente modelos bottom-up. Os

modelos de referência são modelos top-down.

Os modelos de referência são derivados de um estudo de domínio

de aplicação ao invés de sistemas existentes.

Pode ser usado como base para a implementação de sistemas, ou

comparar sistemas diferentes. Atua como um padrão contra o qual os sistemas

podem ser avaliados.

13

O modelo OSI é um modelo de camadas para sistemas de

comunicação.

3.1.5.1 Controle centralizado

Um subsistema de controle é responsável pelo gerenciamento da

execução de outros subsistemas.

Modelo chamada-retorno

É o modelo de subrotina top-down onde o controle inicia no topo de

uma hierarquia de subrotina, e se move para baixo da hierarquia. É aplicável a

sistemas seqüenciais.

Modelo de gerenciador

É aplicável a sistemas concorrentes. Um componente de sistema

controla a parada, o início e a coordenação de outros processos de sistema. Pode

ser implementado em sistemas seqüenciais como uma declaração ‘Case’.

3.1.5.2 Sistemas orientados a eventos

Dirigidos por eventos gerados externamente onde o timing dos

eventos está fora do controle dos subsistemas que processam o evento.

Dois modelos dirigidos a eventos principais

Modelos de broadcast. Um evento é transmitido a todos os

subsistemas. Qualquer subsistema programado para manipular esse evento pode

responder a ele.

Modelos orientados a interrupções. Usado em sistemas de tempo

real onde as interrupções são detectadas por um tratador de interrupções e

passadas por algum outro componente para processamento.

Outros modelos dirigidos a eventos incluem sistemas de planilhas e

de produção.

14

4 DESAFIO 3

4.1.1 Programação para Web II

4.1.1.1 Comparação de frameworks para desenvolvimento web (Java).

O mercado de frameworks Java é imenso. Há muitas opções boas

disponíveis no mercado e muitos pontos a considerar na adoção ou estudo de algum

novo framework.

O Struts com certeza é o framework com maior unanimidade no

mercado, em especial por causa de sua versão 1.x. A versão 2.0 não tem tanta força

mas é um dos mais importantes.

Um dos frameworks mais usados hoje é o JavaServer Faces - JSF.

Seu grande apelo é ser o framework oficial do Java EE para Web, enquanto que

todos os outros são de terceiros. O JSF tem ainda muitas características diferentes

do Struts ou do VRaptor que vimos nesse curso.

Em especial, o JSF é dito um framework component-based,

enquanto que Struts (1 e 2) e VRaptor são ditos request-based ou action-based. A

ideia principal de um framework de componentes é abstrair muitos dos conceitos da

Web e do protocolo HTTP provendo uma forma de programação mais parecida com

programação para Desktop. O JSF tem componentes visuais ricos já prontos,

funciona através de tratamento de eventos e é stateful (ao contrário da Web "normal"

onde tudo é stateless)

Mas o JSF não é único framework baseado em componentes. Há

outras opções (menos famosas) como o Google Web Toolkit - GWT ou o Apache

Wicket. Da mesma forma, há outros frameworks request-based além de Struts e

VRaptor, como o Stripes ou o Spring MVC.

Quando falamos de frameworks voltados para persistência e bancos

de dados, felizmente, não há tanta dúvida quanto no mundo dos frameworks Web. O

Hibernate é praticamente unanimidade no mercado Java, principalmente se usado

como implementação da JPA. Há outras possibilidades, como o Toplink, o

15

EclipseLink, o OpenJPA, o DataNucleus, o JDO, o iBatis etc. Mas o Hibernate é o

mais importante.

4.1.1.2 Relacione os custos/benefícios de usar frameworks no

desenvolvimento Web

Se o framework estiver pronto, os benefícios são claros em termos de:

Redução de custos Redução de time-to-market

Motivos:

Maximização de re-uso (análise, design, código, testes) Desenvolvedores se concentram em adicionar valor em vez de

reinventar a roda Menos manutenção Fatoração de aspectos comuns a várias aplicações Uso de herança permite corrigir todas as aplicações com a troca

de uma classe-mãe Mas cuidado com o "Fragile Base Class Problem" onde a troca da

classe-mãe quebra as filhas Estabilização melhor do código (menos defeitos) devido ao uso

em várias aplicações

Outras vantagens Melhor consistência e compatibilidade entre aplicações Alavancagem do conhecimento de especialistas Framework oferece uma forma de empacotar o conhecimento de

especialistas sobre domínios de problemas Assim, não se perde o conhecimento com a saída de especialistas

e o conhecimento pode ser usado/estudado sem a presença do especialista Resultado: criação de patrimônio estratégico da empresa

(Strategic Asset Building)

Desvantagens Construir um framework é complexo Re-uso não vem sozinho: deve ser planejado É mais complexo e demora mais fazer uma aplicação tendo que

construir um framework em vez de fazer a aplicação do zero Benefícios são realizados em longo prazo Quem pode pensar em longo prazo quando se está competindo

"On Internet time"? Uma empresa aeroespacial demorou anos para fazer frameworks

e começou a ter retorno na quarta missão Precisa modificar o processo de desenvolvimento e criar novos

16

incentivos Vencer o "Not Made Here Syndrome" "The most profoundly elegant framework will never be reused

unless the cost of understanding it and using its abstractions is lower than the programmer's perceived cost of writing them from scratch" (Booch, Dr Dobb's Journal, 1994)

4.1.1.3 Programação Java Web (plataforma de desenvolvimento)

17

5 CONCLUSÃO

Responde-se aos objetivos sem, no entanto, justificá-los.

18

REFERÊNCIAS

Sommerville, Ian. Engenharia de Software - 8ª Edição.

Um guia do conhecimento em gerenciamento de projetos (Guia PMBOK) Quinta Edição.

19