Category: gestão de projetos de software

Gestão de projetos de software, apontamentos

Programa:
1. Project planning
• Software estimation and scheduling
• Development of a software development plan
2. Quality management
• Quality plan
• Reviews and inspections
• Software testing
• Configuration management and version control
3. Software project management
• Requirements management
• Project monitoring and control
• Risk analysis and management
• Team management
4. Software development processes
• Process models and process measurements

software project problems?
1. Excessive schedule pressure
2. Changing needs
3. Lack of technical specifications
4. Lack of a documented project plan
5. Excessive and secondary innovations
6. Unclear requirements
7. Lack of scientific methods
8. Defects discovered too late
9. Unethical behavior

Why do software projects fail?
• People begin programming before they understand the problema
• The team has an unrealistic idea about how much work is involved.
• Defects are injected early but discovered late.
• Programmers have poor habits – and they don’t feel accountable for their work.
• Introduce software quality from the very beginning of the project

Vision & Scope (identificar quais as necessidades, e convencer o cliente a comprar, construído pelo business manager)
1. Problem Statement
• Project background (qual é o problema)
• Stakeholders (clientes de um restaurante, usam o tablet..)
• Users (quem vai usufruir, o cliente, o dono do restaurante)
2. Vision of the Solution
• Vision statement (como vai ser resolvido, …)
• List of features (o que vai ter a app, menus, quantidades…)
• Features that will not be developed
• Risks
• Assumptions (existem poucas opções…)

Documents lifecycle (gestão das versões)

Project lifecycle


Phase1: Project Preparation
• Stage 1.1 – Project Setup & Software Concept
o Deliverable D1.1.1 – Vision & Scope
o Deliverable D1.1.2 – Milestone M1.1 Report
o Milestone M1.1 – Scope Review
• Stage 1.2 – Project Planning
o Deliverable D1.2.1 – Software Development Plan
o Deliverable D1.2.2 – Quality Assurance Plan
o Deliverable D1.2.3 – Milestone M1.2 Report
o Milestone M1.2 – Plan Review
Phase2: Project Execution
• Stage 2.1 –Requirements Specification
o Deliverable D2.1.1 – Software Requirements Specification
o Deliverable D2.1.2 – Risk Plan
o Deliverable D2.1.3 – Acceptance Test Plan
o Deliverable D2.1.4 – Milestone M2.1 Report
o Milestone M2.1 – Software Requirements Review
• Stage 2.2 – Software Development
o Deliverable D2.2.1 – Software Architecture & Design
o Deliverable D2.2.2 – Milestone M2.2 Report
o Milestone M2.2 – Design Review
• Stage 2.3 – Software Acceptance
o Deliverable D2.3.1 – Acceptance Test Report
o Deliverable D2.3.2 – Quality Assessment Report
o Deliverable D2.3.1 – Milestone M2.3 Report
o Milestone M2.3 – Acceptance Review
Phase3: Project Closeup
• Stage 3.1 – Software Delivery
o Deliverable D3.1.1 – Post-Mortem Analysis
o Milestone M3.1 – Closeup

Project Plan

(que trabalho existe para fazer/descrição, quem vai fazer)
Uma lista de tarefas/módulos, divisão do trabalho

Categorias dos processos

Engenharia
Software concept
Project planning

Project planning
WBS (work breakdown structure)
project estimation report (o que se vai fazer), tarefas pequenas, subdivididas,

Gestão
Project setup
Documents management
Change management
Meetings management

Ciclo de vida geral de um documento:

Qualidade
Milestone review

Quality assurance
Inspection
Reisk management
Testing
Deskcheck
Walkthrought

5. Estimation
Entra o gestor do projeto
Faz uso do vision and scope para construir o software develpment plan, onde surge a estimativa. Usando o modelo cascata, fazemos a estimativa completa
Estimativas vs espectativas no cliente (âmbito, custo, duração..)
Estimativa serve para negociar (custo e calendário), para prlanear o projeto, para controlar o projeto

Ou um work breakdown structure (WBS): é a subdivisão do trabalho em tarefas mais pequenas de trabalho, organizadas de forma hierárquica
Ou um product breakdown struture (PBS): é a subdivisão em tarefas mais pequenas; inclui o WBS; indicar um esforço para cada tarefa (o trabalho que foi efetivamente realizada)

Para isso é necessário:
• Saber os pressupostos de cada uma das tarefas
• Obter consenso dentro da equipa, discutir, conversar..
Tendo em consideração:
• O nível de confiança, o histórico/conhecimentos em tarefas semelhantes, experiência pessoal.
E as suposições? Cuidado com isto..
A estimativa é uma aproximação a uma “realidade”

Problemas relacionados com o estimar:
Complexidade dos sistemas VS trabalho repetitivo
Subestimar VS sobrestimar pode tornar o produto mais caro
Estimativas são objetivos de facto
Informação inadequada acerca das capacidades da organização
Requisitos pouco esclarecidos/claros
“Estimar com o que achamos que vamos conseguir fazer, sem preocupações com as horas que temos”

O que é estimado:
• o peso
• o esforço (horas)
• o calendário (uma unidade no calendário)
• o custo (euros)

O cone da incerteza
(quanto mais à frente for a fase do desenvolvimento melhor é a estimativa)


Técnicas como estimar:
“adivinhar” de forma estruturada
Experiência
Delphi groups
Analogias (olhar para projetos anteriores)
Bottom-up, estimar módulos mais pequenos, para cada componente
Ou o Planning poker
(existe um moderador, existe o dono do produto, e os que estimam)
1º o moderador lê a descrição dos requisitos, as linhas do WBS
2º o dono do produto responde às questões dos estimadores
3º cada um vai estimar com uma carta: 1 quer dizer uma hora, ou um ponto, … e coloca a carta virada para baixo (sem divulgar)
4º depois de todas as estimativas estarem indicadas, as cartas são voltadas para cima
5º só se a estimativa variar profundamente, os donos das cartas mais altas e mais baixas discutem as razões. Todos devem participar na discussão, dentro de um limite de tempo

E por fim quando se chegar ao consenso escreve-se a estimativa! O Project estimation report!
(não existe número 4.. e outras, existem poucas cartas reuniões mais rápidas, mais fácil chegar a um consenso, menos cartas mais consenso)
(mas e se uma tarefa durar mais tempo que a ultima carta 9?, dividir a tarefa em sub tarefas..)

6. Gestão da qualidade
Um produto com qualidade vai ao encontro das espectativas do cliente
Como obter a qualidade?
Os processos estão escritos
Manual da qualidade
Tem processos que seguem normas (certificações)
E os processos de qualidade:
O plano de qualidade é definido por projeto (seguindo o quality manual)

As tarefas de baixo:
são as tarefas extra, surgem no plano de qualidade rever os requisitos, rever o código, fazer testes ao código.. e por exemplo implicam um esforço, quanto mais critico é o software, mais esforço surge nesta parte e vai ter um custo maior do que escrever propriamente o código.

O plano de qualidade:
• Vão ter atributos (internamente[o que podemos fazer na empresa, o que interessa para a equipa, código fácil de compreender, é portável?, usar o mesmo código para outro sistema] e externamente[“não gastar bateria”, safety “ se alguém morrer por erros de código”], do ponto de vista do cliente, de fora da equipa)
o Exemplos de atributos (o que é mais importante para o projeto):

o As métricas?
 De produto: tempo de execução, números de bugs, número de linhas de código, satisfação do utilizador
 Do projeto: se mudaram os requisitos, requisitos estáveis, se seguiram os processos todos
 Ajudam a medir a qualidade (tem o produto no fim a qualidade que era desejada ou não?)
• Vão ter processos (revisões, testes, qual a arquitetura, testes de performance)
• Vão ter standarts (que convecções vão ser utilizadas para garantir qualidade interna)
• Vão ser definidas métricas

Surge então o documento: quality assurance plan (plano de garantia de qualidade)

quality assurance plan: serve para indicar o que queremos fazer, quais os objetivos de qualidade, como vamos medir, que atividades vão ser realizadas
quality assessment report: serve para medir, para saber se conseguimos atingir, colocar as não conformidades (alturas em que não se seguiu o plano)

7. Capítulo das revisões:
“quanto mais tarde for encontrado o problema, por exemplo erro no código, mais caro fica a revisão”
Servem para ser descritas no quality assurance plan

Três tipos de revisões
• Inspeções:
o São reuniões
o Os vários inspetores vão analisar código ou documentos, à procura de defeitos
o Objetivo de encontrar defeitos
o Por exemplo ao software requirements specifications (SRS) e test plans
o Tem fases:
 Planeamento: um documento (SRS e Vision and Scope e tudo o que estiver relacionado), o autor recolhe a informação e chama o moderador que organiza a reunião
 Preparação: antes da reunião cada um dos inspetores (que são todos) vai ler, e toma nota do que for suspeito
 Reunião: alguém vai ler o documento e vai explicando. Os outros fazem perguntas, e quem vai responder é quem lê. Se encontrarem defeitos o anotador toma notas. O autor está calado. Surge a discussão/debate.
 Rework: o autor vai corrigir de acordo com as anotações
 Follow-up: o moderador vai ver se as correções foram bem feitas.
 [moderador (pode pedir pelas notas, decide o que é para anotar ou não), leitor (lê o documento), inspetor (são todos menos o leitor), anotador]
 Surge o review report: com os defeitos, gravidade dos defeitos
O processo da inspecção:

Três tipos de revisões (continuação)
• Controlo documental (deskchecks):
o O autor distribui o que quer rever para que alguém faça revisões, para revisores

Três tipos de revisões (continuação)
• Reunião de orientação (walkthroughs):
o O autor chama os revisores, que leem o documento
o Os revisores leem o documento antes da reunião
o Mais informal

8. Os testes ao software
Testar um código pode ser só ler
Testar pode ser aplicar dados artificiais
Testar pode ser uma revisão manual do código
Testes não revelam a ausência de problemas
Teste revelam os problemas do código

Os software review: são análises estáticas, leitura do código
Os software testing: é uma analise dinâmica, não funcionais
São ambos complementares ( E )

Os testes:
• Testes unitários:
o Modulo individual, funções, método, objetos, classes..
o Procurar defeitos
o Escrevo um método e vou logo testar
• Testes de integração (integration test):
o Módulo está feito e vou juntar a outro módulo
o Ver como correm as coisas, integrando ambos
o E podem ser:
 Integração incremental: Juntar os dois, aos poucos
 Big bang : juntar tudo feito, por várias pessoas
• Teste de aceitação:
o Deve existir um plano de testes
o Quando a aplicação estiver terminada

Test plans (ATP, plano de testes):
• indica como vamos testar, deve ser feito aquando do SRS
• sumariar as atividades relacionados com os testes
• qual vai ser a sequência de testes
• deve ser feito logo no início quando ainda não existe código.
• Ajuda a focar na forma como vai ser escrito o código.
• Servem para verificar se todos os requisitos foram escritos.

O processo dos testes

Com a ajuda do SRS software requirements specification
Surge:
QAP quality assurance plan
ATP Acceptance Test Plan (descrição dos testes)
ATR Acceptance Test report

Os testes (continuação):
• Testes de usabilidade:
o Satisfação do participante com o produto
o Através de tarefas
o Pode ser quantitativa (nível de satisfação)
o Pode ser qualitativa

9. Estimativa
Esforço (pessoas-hora) VS Duração (hora)
No escalonamento devemos alocar recursos: as pessoas em cada uma das tarefas
Deve ser inscrita a informação do WBS (work breakdown structure)
Ter em conta o overhead
Saber a duração das tarefas
Identificar as dependências (entre tarefas)
Exemplo: finish-to-start. Uma revisão só começa depois do documento estar pronto
Diagrama de gantt, por exemplo:

Podem ser usados buffers no escalonamento
Os buffers são tempos mortos para resolver atrasos imprevistos

Project planning process: (estimate = escalonar)

10. Monitorização e controlo (Project Monitoring And Control)
Monitorizar, é saber se as tarefas estão a ser realizadas dentro do plano
Controlar, é controlar o âmbito, o calendário, reestimar
Controlar: dentro do prazo, se está dentro do orçamento, se estão a gastar ou não o orçamento, e se o trabalho está a ser seguido conforme o planeado

Métodos para controlar
• Burndown chart
o Projetos curtos
o Iteração de uma só vez
o Verificar todos os dias o trabalho que falta realizar

o Verde o real:
 indica o que falta fazer,
 linha verde abaixo, estamos adiantados, falta menos do que o previsto
 linha verde acima, estamos atrasados, por exemplo tínhamos planeado/estimado 80 horas mas deviam ser 100 horas
o cor de laranja planeado
 cor de laranja começa com o número máximo de horas que temos até esgotarmos e chegarmos a zero horas disponíveis, e data respetiva do âmbito do projeto
o este gráfico depende das estimativas
o não diz quanto trabalho foi feito
o serve para ajudar a prever quando vai terminar
o não funciona com tarefas muito grandes

• Earned Value Analysis (EVA)
o Permite avaliar o desempenho de uma equipa
o Relacionado com metodologias tradicionais
o Projetos grandes ou pequenos
o Comparar o custo, comparar o escalonamento e o âmbito
o Prever se o projeto consegue terminar a tempo
o Tudo o que é feito tem valor
o O valor é o esforço que se dedica a uma tarefa
o Budget cost of work (BCW)
 Cada tarefa é estimada em ternos de esforço, ou custo
o Actual cost of work (ACW)
 Custo para completar a tarefa
 Quanto tempo demoramos para completar uma tarefa
o Planned Value (PV)
 Somar as tarefas todas planeadas até agora
 Exemplo: se tinha uma tarefa de 5 horas + tarefa de 3 horas para terminar hoje, o plano seria ter 8 horas de ganho, é este o valor planeado
o Earned value (EV)
 É o que efetivamente ganhamos, por exemplo as tais 8 horas
o Actual cost (AC)
 Quanto custou, o que efetivamente custou: por exemplo se para a tarefa de 5 hora demorados 10, e se para a tarefa de 3 horas demoramos 6 então custou 16 horas

Análise ao gráfico:
• Linha azul (BAC)
o é as horas que temos para gastar
o qual é o orçamento para todo o trabalho
• Linha vermelha (PV)
o o que estamos a planear
o qual é o valor estimado do trabalho planeado que vai ser executado
o é o valor ganho
• linha amarela (EV)
o à medida que as tarefas vão sendo cumpridas
o para cima do atual cost (da verde): trabalhamos para além do que estava previsto, se calhar terminamos mais tarefas, pois existe um valor ganho mais elevado do que o valor planeado. Quer dizer que está a correr bem
o qual é o valor estimado do trabalho planeado realmente concretizado
• linha verde (AC)
o é o tempo que realmente se gastou
o qual foi o custo que aconteceu

11. Gestão do risco
O plano de risco é sobre algo que pode correr mal
Antecipar os problemas e dessa forma evitá-los
Planear para minimizar ou anular os efeitos do risco no projeto:
• Risco sobre o projeto:
o Se ficarmos doentes
• Risco sobre o produto:
o A framework pode correr mal por algum motivo
• Risco do negócio:
o produto muito bom, mas não vamos conseguir vender
• Risco da tecnologia, das pessoas, organizacional, ferramentas, requisitos, estimativa
• A gestão do risco tem como processos:
o Identificação do risco
 Quais são os riscos (de tecnologias, de pessoas, de organização, de requisitos, de estimativa)
 Existe uma reunião com todos os que vão participar
 Mas para saber o que é o risco, precisamos de saber PRIMEIRO o que é o sucesso do projeto (threshold of success) [smart]: com objetivos pequenos [short], mensuráveis [mensurable], alcançáveis (viável) [achivable], relevantes [relevant], e dentro do prazo [time bound]
 Risk statment: O que é que hoje é verdade e porque é que isso me preocupa (condição-> então existe a possibilidade -> de existir uma consequência)
o Análise do risco
 Qual a probabilidade dos riscos
 Qua é o impacto do risco (risk impact): catastrófico(5), sério(3), tolerável(1)
 Probabilidade do risco: baixa(1), moderada, alta. muito alta (5)
 E criar prioridades através do resultado da: probabilidade * impacto
 Ordenada do mais alto para o baixo
 Os mais importantes podem ser SÓ os catastróficos
o Planeamento do risco (risk statment)
 É a terceira fase
 Definir o que fazer sobre o risco que foi identificado
 Escolhemos lidar só com os mais altos por exemplo (mitigar estes) e colocar sobre observação os médios, e os outros ignorar
 Para os riscos elevados:
• Plano de prevenção (avoidance strategies): o que fazer para baixar a preocupação? O impacto do risco? Para se tornar um menor risco.. baixa a probabilidade
• Plano de minimização (minimization strategies): baixar o impacto do risco acontecer [outro elemento da equipa para substituir alguém]
• Plano de contingência (contigency plans): planos para lidar com o problema [negociar com o cliente o âmbito da aplicação]
o Monitorizar o risco
 Vamos monitorizar
 Regularmente verificar se existem alterações no risco

Processo de gestão do Risco

12. Requisitos do software
Primeiro perceber quais são as necessidades, através de entrevistas, perceber as regras se for um jogo, perceber o que o cliente quer
Vai ter casos de uso
Vai ter os requisitos funcionais: o que é que a aplicação vai fazer, uma descrição clara, descrição que vai ter que estar completa
Vai ter os requisitos não funcionais: ao nível do comportamento (ser fácil [definir o que é, um utilizador tem que terminar a operação ao fim de xx tempo ], ser rápido [demorar menos de dois segundos])
Fazer UI Mockups:
O SRS (software requirements specification) tem os casos de uso, requisitos…

Scope: Vision and Scope
Requirements : SRS (software requirements specification)
Design:

13. kickoff meeting
Gestor do projeto planeou tudo com o cliente e agora surge a primeira reunião entre a equipa e o cliente

14. software version control
Testar um módulo de cada vez
• Disadvantages of a test suite
o It’s a lot of extra programming
o However, a good test framework can help quite a lot
o You don’t have time to do all that extra work
o False! Experiments repeatedly show that test suites reduce debugging
time more than the amount spent building the test suite
• Advantages of a test suite
o Reduces total number of bugs in delivered code
o Makes code much more maintainable and refactorable
16. team management
As fases da formação de uma equipa:

17. processo de software
Ciclo de vida de um processo de software

Modelo em cascata:

Em cascata
Mapear a sequência de passos para desenvolver projetos

O modelo de processo
Qual o critério para começar
Qual o critério para terminar

Respostas de exame 1920_normal
[1] é conveniente ou mesmo obrigatório ter a equipa de desenvolvimento definida antes de iniciar a escrita do documento vision and scope? Porquê?
Não está. O VanS serve para definir o que vai ser feito, haver um entendimento entre o cliente e a empresa. Qual a visão e qual o problema a ser resolvido e o âmbito.
Não é preciso haver cliente. Isto é apenas definir o que é para ser feito, não é de todo obrigatório/necessário, talvez conveniente.
Mas para fazer o plano (escalonamento) SDP? Sim pela quantidade, mas não para especificar onde colocar cada um.

[2] indique um processo que tenha extrema importância num projeto critico, e que não foi levado muito a sério no caso do projeto que realizou em GPS. Deveria este processo ter sido abordado de outra forma em GPS?
O processo de risco: os riscos não eram muito elevados. Não eram processos críticos.
Ou deveríamos ter tido mais atenção porque a experiência da equipa não conseguiu abranger o número de riscos.
Riscos de estimativas.
Lidar com testes unitários.
Obter uma formação em como trabalhar em kotlin. Aumentar o budget para a qualidade para obter a formação.
Controlo dos documentos

[3] porque é que numa estimativa realizada com planning poker, quando as cartas apresentadas pelos vários participantes diferem, não se faz simplesmente uma média e passa-se rapidamente à tarefa seguinte? Explique então como se deve fazer.
Tem um grande interesse as cartas extremas (altas e baixas)
A média não interessa para nada.
É importante a discussão.
As cartas têm a ver com as horas. Muitas cartas muitas diferentes horas para distribuir. Para haver consenso mais rápido.
Técnica baseada em opiniões de peritos.

[4] defina um atributo externo e outro interno de qualidade para a unidade curricular de GPS. Explique porque são atributos de qualidade e porque os considera externo ou interno.
Externo: (visto pelo cliente/stakeholder) a complexidade para os alunos, a taxa de aprovação
Interno: (interessa para a equipa) reutilização do código, reutilização dos slides para o próximo ano

[5] uma vez que os testes de aceitação verificam o cumprimento de todos os requisitos, para que serve realizar testes unitários? É possível, no final de todos os testes, afirmar que o software não tem defeitos?
Os testes unitários servem para testar por exemplo, módulos individualmente.
Testar se cumpre o objetivo
Os testes unitários são usados dados artificiais
Isto não garante de forma alguma que o software não tem defeitos. Nunca se consegue testar todas as possibilidades
Os testes de aceitação têm acesso mais limitado, não conseguem cobrir tudo.

[6] imagine que está preparar-se para uma entrevista de emprego e está risco de não ser admitido. Escreva a preocupação na forma de um risk statment e descreva formas de mitigar o risco, por meio de:
a) uma ação de prevenção (avoidance)
b) uma ação de minimização (minimization)
c) e contingência
um risk statment é: O que é que hoje é verdade e porque é que isso me preocupa (condição-> então existe a possibilidade -> de existir uma consequência)
plano de risco: serve para prevenir as coisas, antecipar
risk statment: cv fraco E a empresa é exigente, consequência: não gostam do meu CV logo posso não ser contratado
probabilidade de acontecer: alta (3) porque a empresa é difícil
prevenção: melhorar o CV, cartas de referência (tem que se baixar a probabilidade)
minimização: vou ter outras entrevistas em empresas menos exigentes (baixa o impacto)
contingência: pensar no que vou fazer, trabalhar como freelancer, ou vou tirar um curso (quando não se consegue fazer nada, decide já)

[7] Observe o gráfico de EVA – Earned Value Analysis seguinte e as situações em que a equipa se encontrava, considerando apenas os valores relativos entre PV – Planned Value, EV – Earned Value e AC -Actual Cost. Em qual dos dias registados parece ter ocorrido um pronto importante de viragem no projeto? Explique o que se parece ter-se passado.

BAC
• é as horas que temos para gastar
• qual é o orçamento para todo o trabalho

PV
• o que estamos a planear
• qual é o valor estimado do trabalho planeado que vai ser executado
• é o valor ganho

EV
• à medida que as tarefas vão sendo cumpridas
• para cima do atual cost (da verde): trabalhamos para além do que estava previsto, se calhar terminamos mais tarefas, pois existe um valor ganho mais elevado do que o valor planeado. Quer dizer que está a correr bem
• qual é o valor estimado do trabalho planeado realmente concretizado
AC
• é o tempo que realmente se gastou
• qual foi o custo que aconteceu

Entre 15 e 22: trabalharam menos, do que tinham planeado e a partir daqui atrasou-se
Entre 22 e 29: não conseguiram alcançar os objetivos dessa semana, tiveram que compensar
Dia 22: a partir daqui atrasaram-se e nunca mais conseguiram alcançar até ao final
Acabou terminar o projeto com esforço maior do que estava previsto

[8] Explique como fez no seu projeto de GPS para desenhar a linha de Planned Value no gráfico de Earned Value Analysis. Por que motivo esta linha deveria estar o mais linear possível?
PV
O mais linear possível para ter o ritmo de trabalho constante. O mesmo número de horas todas as semanas.
Dividir o trabalho em tarefas mais pequenas
Estimar cada uma das tarefas
Distribuir ao longo das semanas
E tentar aproximar o número de horas por semana para que fosse sempre constante

[9] Considere o seguinte processo de Desenvolvimento de Software:
O arquiteto desenha, a partir do Software Requirements Specification (SRS), o Software Architecture and Desigh (SAD). Este documento é revisto e aprovado pela equipa. Depois, com base nos documentos SRS, SAD e Plano de Projeto, cada programador codifica um requisito, escreve os testes, e executa-os. Depois de concluído o módulo resultante é integrado com os restantes módulos já anteriormente criados. Depois de pronto, passa para o próximo requisito, até que todos os requisitos estejam concluídos.
Desenhe um diagrama deste processo, à semelhança do que usou nas aulas, como por exemplo o que consta da figura abaixo. Deve escrever os pressupostos que considerou e que não constam da descrição.

Tags : , ,