Você está na página 1de 27

ENGENHARIA DE SOFTWARE

AULA 02

Prof. José Carlos Correia Lima da Silva Filho


E-mail: jose.lima@estacio.br
ENGENHARIA DE SOFTWARE
Tema

FUNDAMENTOS DE SOFTWARE E
GERENCIAMENTO DE PROJETOS
ENGENHARIA DE SOFTWARE

Atividade
Em grupos, pesquisem na internet um caso de um software que
tenha fracassado. Identifiquem qual foi o seu principal problema e
indiquem como a engenharia de software poderia ter evitado o
insucesso.

Próxima aula, cada grupo deve apresentar o caso.


ENGENHARIA DE SOFTWARE
Situação-problema

Se você deseja aprender um novo idioma


e de vez em quando assiste algumas
aulas na internet, ou faz algumas leituras
esporádicas, isso pode ser considerado
um projeto pessoal?
ENGENHARIA DE SOFTWARE
Situação-problema

Suponha agora que você tenha


planejado estudar duas horas por dia,
três vezes na semana durante 18 meses,
e após esse período irá fazer uma viagem
de 30 dias para exercitar a conversação.
Isso pode ser considerado um projeto
pessoal?
ENGENHARIA DE SOFTWARE

O que é um Projeto

“Um esforço temporário com a


finalidade de criar um produto/serviço
ou resultado exclusivo/único”
PMBOK® Guide
ENGENHARIA DE SOFTWARE

O que é um Projeto

Projeto

Escopo Tempo/Cronograma Custo


ENGENHARIA DE SOFTWARE

Escopo do Projeto

O trabalho que precisa ser realizado para entregar um produto, serviço ou resultado com as
características e funções especificadas.

Tempo do Projeto
O tempo do projeto é o período utilizado na concepção, construção até a entrega /
encerramento do projeto.

Custo do Projeto
Gastos com os recursos necessários para execução do projeto.
ENGENHARIA DE SOFTWARE

O que é restrição do projeto?

As restrições do projeto podem ser definidas como


limitações que comprometem a execução de um
trabalho.

São situações impostas por alguém ou por um


contexto que podem afetar o desempenho e até o
resultado de um projeto.

Normalmente, as principais restrições de um projeto


são o prazo, escopo e custos.
ENGENHARIA DE SOFTWARE

Restrição tripla

Como foi descrito, as triplas restrições do


gerenciamento de projetos estão intimamente ligadas
entre si e ao alterar uma delas, o resultado de um
trabalho poderá ser afetado. Por exemplo, quando o
cliente resolve aumentar o escopo do projeto é
possível que os recursos disponíveis e prazos iniciais
fiquem comprometidos.
ENGENHARIA DE SOFTWARE

Gerenciamento de projetos é a aplicação de conhecimentos,


habilidades, ferramentas e técnicas adequadas às atividades do
projeto, para atender aos seus requisitos. [PMI 2012, p. 5]

Áreas de conhecimento

As dez áreas de conhecimento caracterizam os principais


aspectos envolvidos em um projeto e no seu gerenciamento:

• Integração • Recursos humanos


• Escopo • Comunicações
• Tempo • Riscos
• Custos • Aquisições
• Qualidade • Partes interessadas
ENGENHARIA DE SOFTWARE

Segundo o PMBOK existem cinco grupos de processos:

Iniciação: Esse grupo reúne os processos iniciais aplicados em qualquer novo projeto ou nova fase de
um projeto existente. Ele tem o objetivo de levantar as informações necessárias para que seja
autorizado o início do projeto.

Planejamento: Após a autorização para iniciar o projeto ou fase, o gerente começará a planejar tudo
em detalhes. Esse é sem dúvidas o grupo que mais possui processos. Quanto mais detalhes forem
levantados sobre o projeto, menores serão os riscos de imprevistos ao longo da sua execução.

Execução: Depois de tudo planejado é hora de colocar a mão na massa! O grupo de processos de
execução será responsável por fazer com que o trabalho seja realizado, satisfazendo assim os
requisitos do projeto.
ENGENHARIA DE SOFTWARE

Segundo o PMBOK existem cinco grupos de processos:

Monitoração e Controle: Ao mesmo tempo em que a execução acontece, é necessário monitorar


diversas variáveis para garantir que nada fuja do planejado. E quando acontecer, é preciso tomar
algumas ações para recuperar o controle e manter o foco no objetivo.

Encerramento: Ao fim, é necessário oficializar o término do projeto ou fase. Assim como poderá se
garantir que tudo o que foi combinado, foi entregue, e que o cliente ficou satisfeito com o resultado
recebido.
ENGENHARIA DE SOFTWARE

Após a quinta edição, a prevalência global de


metodologias e práticas ágeis, especialmente em áreas
como o desenvolvimento de software e o
gerenciamento de projetos, levou finalmente o PMI a
incluir informações tanto de abordagens tradicionais
quanto de práticas ágeis na sexta edição, e fazer uma
parceria com a Agile Alliance para criar um novo Agile
Practice Guide (2017) que complementa o Guia
PMBOK.

[1] Vídeo "PMBOK x ÁGIL qual a diferença" disponível em:


https://www.youtube.com/watch?v=zFH4PNDZV0M
ENGENHARIA DE SOFTWARE

O que é um risco?

• De modo simplificado pode-se pensar no risco como a


probabilidade de que alguma circunstância adversa
aconteça.

• Os riscos podem ameaçar o projeto, o software que está


sendo desenvolvido ou a organização.

15
ENGENHARIA DE SOFTWARE

Gerenciamento de riscos

• O que é o gerenciamento de riscos?

Identificar riscos e traçar planos para minimizar seus efeitos sobre o


projeto.

• Processos de gerenciamento de riscos


– Identificação de riscos
– Análise de riscos
– Planejamento de riscos
– Monitoramento de riscos

16
ENGENHARIA DE SOFTWARE

Processos de gerenciamento de riscos

17
ENGENHARIA DE SOFTWARE
Identificação dos riscos

• Consiste em descobrir os possíveis riscos existentes no projeto.

• Estratégias para identificação:


– Brainstorming;
– Experiência de um gerente.

• Tipos de riscos
– Quanto a tecnologia
– Quanto ao pessoal
– Organizacionais
– Quanto a ferramentas
– Quanto aos requisitos
– Quanto a estimativa
18
ENGENHARIA DE SOFTWARE

Exemplo:

Tipos de
Riscos possíveis
riscos
Componentes do software que deviam ser reutilizados contêm
Tecnologia
defeitos que limitam sua funcionalidade.

Pessoal O treinamento necessário para o pessoal não está disponível.

Organizaciona Problemas financeiros organizacionais forçam reduções no


l orçamento.

Ferramentas O código gerado pelas ferramentas CASE é ineficiente.

Os clientes não compreendem o impacto das mudanças nos


Requisitos
requisitos.
Estimativa O tempo requerido para desenvolver o software é subestimado.

19
ENGENHARIA DE SOFTWARE
Análise de riscos

– Após identificado, cada risco deve ser analisado levando-se em


conta:
• Probabilidade de ocorrência;
• Seriedade do risco (impacto).

– A probabilidade do risco pode ser determinada como muito baixa(menor que


10%), baixa(10-25%), moderada(25-50%), alta(50-75%) ou muito alta(maior que
75%).

– Os efeitos do risco podem ser classificados como: catastróficos, sérios, toleráveis


ou insignificantes.
20
ENGENHARIA DE SOFTWARE
Análise de riscos
• Os resultados obtidos devem ser apresentados em um tabela ordenada de
acordo com a seriedade do risco.
Exemplo:

Risco Probabilidade Efeitos


Problemas financeiros organizacionais
forçam reduções no orçamento do Baixo Catastróficos
projeto
Componentes de software que
deviam ser reutilizados contêm Moderada Sérios
defeitos em sua funcionalidade
O tamanho do software é
Alta Toleráveis
subestimado

• Atualização contínua.

21
ENGENHARIA DE SOFTWARE

Planejamento de riscos

• O processo de planejamento de riscos consiste em definir estratégias


para gerenciar cada um dos riscos mais importantes que foram
identificados.

• Tipos de estratégias:
– Estratégias preventivas: Visa evitar que um determinado risco ocorra.

– Estratégias de minimização: Visa diminuir o impacto do risco será reduzido.

– Planos de contingência: Visa se preparar para, caso um risco ocorra, saber lidar
com o caso.

22
ENGENHARIA DE SOFTWARE

Exemplo:

Risco Estratégia

Substitua componentes potencialmente defeituosos


Componentes
por componentes comprados e que tenham
defeituosos (1)
confiabilidade reconhecida.
Reorganize a equipe de maneira que haja mais
Doenças de pessoas da
sobreposição de trabalho e, portanto, as pessoas
equipe (2)
compreendam as tarefas umas das outras.
Prepare um documento informativo para a alta
Problemas financeiros gerência, mostrando como o projeto presta uma
organizacionais (3) contribuição muito importante para os objetivos da
empresa.

1. Estratégia preventiva
2. Estratégia de minimização
3. Estratégia de contingência

23
ENGENHARIA DE SOFTWARE

Monitoramento de riscos

• O monitoramento de riscos é o processo de manter a rastreabilidade dos


riscos identificados, monitorar riscos residuais e identificar novos riscos,
assegurar a execução dos planos de risco e avaliar a sua efetividade na
redução dos riscos.

• Dentre as ações que podem ser adotadas nessa etapa estão:


– Escolha de estratégias alternativas;
– Implementação de um plano de contingência;
– Tomada de ações corretivas;
– Replanejamento do projeto.

24
ENGENHARIA DE SOFTWARE

• O gerenciamento de riscos é particularmente importante para projetos


de software, devido às incertezas inerentes que a maioria do projetos
enfrenta.

• O processo de gerenciamento, como todos os outros planejamentos de


projeto, é um processo iterativo, que continua ao longo do projeto.

• À medida que novas informações sobre os riscos tornam-se disponíveis,


eles têm de ser reavaliados e novas prioridades devem ser
estabelecidas.

25
ENGENHARIA DE SOFTWARE
Atividade

Em grupos, os alunos deverão identificar uma lista


com 5 riscos para o desenvolvimento de um aplicativo iOS e
Android, realizar a análise de cada um deles e planejar as
respostas aos riscos.

Os trabalhos deverão ser entregues ao professor por e-mail:


jose.lima@hotmail.com

Atividade Autônoma Aura:

https://forms.office.com/Pages/ResponsePage.aspx?id=RKhJ2uPir0
CGpsOBnXBPSQTQoCrJ9m5Kra8EaTJQ-
EdUNEVMVElVREJENFFHMElUVDVNOU5VSlM2SyQlQCN0PWcu
ENGENHARIA DE SOFTWARE
Aprenda +

- Vídeo "PMBOK® Guide 6a Edição Explicado com Ricardo Vargas" disponível


em: https://www.youtube.com/watch?v=rvDnS_wWwJs

- LIMA, Fabiana. Gerenciamento do tempo em projetos de software usando


PMBOK. Disponível em: https://www.devmedia.com.br/gerenciamento-do-
tempo-em-projetos-de-software-usando-pmbok/32920

- MONTES, Eduardo. Gerenciamento dos riscos: O que é, objetivo e


processos. Disponível em:
https://escritoriodeprojetos.com.br/gerenciamento-dos-riscos-do-projeto

Você também pode gostar