Projeto de Software

Projeto: esforço temporário, prazo á cumprir, criado para agregar valor para o cliente,
empresa... Não é tarefa rotineira.

Gestão de projetos inclui:

 Identificar necessidade, (requisitos)

 Estabelecer objetivos
 Balanceamento de tempo, custo e qualidade.

Formação de equipe de projeto

 Determinar o numero de pessoas do grupo (7-9 pessoas)

 Atribuição: habilidades técnicas e interpessoais
 Plano de comunicação

Por que os projetos falham?

 Fatores externos
 Fatores internos das corporações
 Fatores internos do projeto (tecnologias, cronograma...)

Problemas na gestão de projetos

 Planejamento inadequado
 Falha na comunicação
 Experiência em gestão

Modelo cascata (fases do projeto)

 Levantamento de requisitos
 Projeto de software
 Implementação do sistema
 Teste
 Operação e manutenção

PMBOK = guia de boas praticas que oferece uma visão geral sobre o
gerenciamento de software

Estruturado em 5 processos: iniciação, planejamento, execução, monitoramento,

controle e encerramento

COBIT
 Separa a governança da gestão, atender as necessidades do stakerholder, envolver
toda a organização, aplicar um único framework integrado.

Manifesto ágil

 Prioridade ao satisfazer o cliente, mudanças de requisitos são bem vindas

 Entregar software funcionando frequentemente, simplicidade é essencial
 Orientada a pessoas;

Extreme Programming

 Rápido desenvolvimento; requisitos se alteram com frequência

 Comunicação, simplicidade (fazer só o que foi pedido, simples e fácil de ser
entendido), feedback, coragem.
 Gerente de projeto: responsável pelos assuntos administrativos, ligação com o
cliente
 Coach: responsável técnico pelo projeto
 Analista de teste: ajuda o cliente a escrever os tests e fornece o feedback.
 Redator: ajuda a equipe a documentar
 Dev: realiza a analise, projeto e codificação do sistema.

Refatoracao: simplificar o código, deixalo mais simples

Metodologia scrum

A metodologia Scrum recebeu esse nome tendo-se como base as regras estabelecidas
nas partidas de Rugby. Ela foi desenvolvida por Jeff Sutherland, na década de 1990.

 No framework scrum tem: product owner, Scrum Master, dev team

 Dev team: responsáveis por entregar o incrementos, funcionais, 5 a 8 pessoas
 Product Owner: define as prioridades do backlog, é voz do cliente, tira duvida
 Scrum máster: promove o srum, mantei o time focado
 Sprint: dividir o software/produto por etapas, tem que ter duração mínima de
uma semana e o máximo 1 mês. Prazo de máxima de 8 horas por dia. Apartir do
Sprint o cliente ver o que esta sendo desenvolvido.
  Backlog do produto: é tudo que presica ser entregue no produto por
inteiro(pedaço do produto, design, diagrama...)
 Backlog da Sprint: dividir o projeto em etapa
 Incrementos: entregas ao final de cada Sprint
 Pesquisar o guia do scrum.


MÉTODO DE DESENVOLVIMENTO DE SISTEMAS DINÂMICOS (DSDM)

A tendência é que novas metodologias sejam criadas para suprir as demandas que vão
surgindo, com isso, a DSDM surge com o intuito de atender a restrições relacionadas ao
prazo. A sua ideia principal é dar agilidade ao processo por meio do uso de protótipos
que vão sendo incrementados à medida que o projeto avança. Conforme Pressman et al.
(2016), a metodologia apresenta o uso de iterações em que o trabalho dedicado é
referente apenas às funcionalidades do ciclo. Posteriormente, é possível inserir mais
especificações após o entendimento dos requisitos de negócio.

MODELAGEM ÁGIL

Conforme Ambler (2002 apud Pressman, 2016), a modelagem ágil atende aos valores
do Manifesto Ágil, para isso, são listados alguns princípios considerados básicos e
suplementares, os quais podem ser vistos abaixo:

Modelar com um objetivo, pois quando se tem um objetivo, fica mais simples a decisão
acerca das notações, dos softwares e dos detalhes que precisarão ser utilizados.

Usar modelos diversos. (Entende-se que cada modelo pode contribuir de alguma
maneira para o projeto.) Além disso, sob esse ponto de vista, a filosofia da modelagem
ágil defende que os pontos fortes e fracos das ferramentas que serão utilizadas devem
ser elencados.

Construir modelos que agregam valor em vez de mudanças constantes de ação dentro do
projeto.

Trazer, por meio da modelagem, informações relevantes.

Gestão de riscos

O pmbok apresenta seis processos:

 Planejamento: ocorre no inicio, e passa por atualizações ao longo do

desenvolvimento do projeto, o plano de gerenciamento deve possuir:
metodologia papeis e responsabilidades, orçamento,...
  Identificação dos riscos: processo critico, ocorre de forma interativa, visto que
só reconhece riscos que conhecemos.
 Analise qualitativa: avalia a probalidade de ocorrência e impacto
 Resposta aos riscos: alternativas, estratégias e acordar acoes para lidar com os
riscos
 Controle dos riscos: controlar, verificar a eficiência e eficácia

Risco: algo que deva ser evitado, chance pequena ou grande de um dano,

Tipos de riscos:

 Estimativa: não conseguir prever algo

 Organizacional: dependência de por exemplo alguém que não faz parte da
equipe
 Pessoal: relacionamentos
 Requisitos
 Tecnologias: refere-se as ferramentas que agente usa

Gestão de qualidade

Normas nacionais e internacionais:

 NBR 13596: versão nacional da ISO 9126 falando sobre a qualidade de produtos
de software, fazendo parte da família ISO 9000.
 NBR ISO 9001: padronização para a garantia da qualidade em projetos,
desenvolvimento, instalação e processos – Sistema de qualidade.
 NBR ISO 9000-3: utilização da Isso 9000 no processo de desenvolvimento de
software, ou seja, gestão e garantia da qualidade.
 ISO 15498: é um guia que traz diretrizes para avaliação dos produtos de
software, criado a partir da Isso 9126.
 ISO 12119: desenvolvido para os softwares genéricos, vendidos em prateleiras,
em que a empresa se adequa ao produto e não o produto à empresa; normas que
determinam as características de qualidade de pacotes de software.
 IEEE P1061: Standard for Software Quality Metrics Methodology - normativas
para tratar métodos de padronizar a qualidade de software, incluindo algumas
formas de medição.
 CMMI Capability Maturity Model Integration: Modelo da SEI (Instituto de
Engenharia de Software do Departamento de Defesa dos USA): não se enquadra
nas normas ISS, porém é amplamente aceita para a avaliação da qualidade dos
processos de desenvolvimento do software;
  SPICE Isso 15504 ou apenas SPICE: melhora os processos de desenvolvimento
de software, semelhante a ISO 12207, referente à parte de ciclo de vida de
Software.

PDCA:

 Plan = planejar – Estabelece metas e define os métodos necessários para se obter

os objetivos do processo.
 Do = fazer – Executa, difundi, treina, educa as tarefas e coletas os dados.
 Check = verificar – Faz a verificação dos resultados.
 Act = agir – Realiza ações corretivas utilizando-se de padronizações,
treinamentos e documentos dos processos.

GERENCIAMENTO DA QUALIDADE TOTAL (GQT)

 A utilização do gerenciamento da qualidade total (GQT) visa à conscientização

da qualidade em todos os processos de uma empresa, incluindo os stakeholders
externos (fornecedores, distribuidores e parceiros); o uso do seis Sigma (6σ),
que se refere à eliminação de defeitos por um conjunto de boas práticas
sistêmicas na melhoria de processos (DMAIC - definir, medir, analisar, melhorar
e controlar)

Evolução da qualidade:

 1991 CMM – modelo de maturidade em capacitação

 1996 UML
 2001 Manifesto ágil
 2002 Processos ágeis

Medidas: indicação quantitativa de extensão, capacidade ou tamanho de algum atributo

de um produto.

Métricas: medida do grau a um sistema possui , serve para controle e o predicao.

 Deve ter propriedade matematcos

 Modificar o valor da métrica de acordo com seu resultado
 Cada métrica deve se validade me uma grande diversidade de contexto.

Indicador: uma métrica ou combinação que fornecem informações sobre o processo de

software.

Documentação: regiustra as etapas do processo, tomadas de decisão, histórico, e

atualizar a cada modificação.
  Termo de abertura
 Eap
 Cronograma
 Requisitos funcionais
 Riscos
 Qualidade
 Tempo
 Custo
 Comunicado

Para Pressman (2016, p. 93), a filosofia ágil “enfatiza a satisfação do cliente e a

entrega prévia incremental de software, pequenas equipes de projeto altamente
motivadas, métodos informais, mínimos artefatos de engenharia de software e total
simplicidade de desenvolvimento. ”

 As metodologias tradicionais se preocupavam mais com os processos do que

o clientes, deferente da ágil.

Papeis da metodologia Scrum:

Product Owner : dono do produto, ele deve saber todos os detalhes do produto

 Cria os requisitos iniciais gerais do projeto e mantém o projeto em andamento.

  Nomeia as pessoas adequadas para os papéis de Scrum Master e Time Scrum.
 Fornece os recursos financeiros para o inicio do projeto e durante o seu
andamento.
 Determina a visão do projeto.
 Avalia a viabilidade e garante a entrega do produto ou serviço.
 Garante a transparência e a clareza dos itens do backlog priorizado do produto.
 Decide o conteúdo mínimo para release comercial.
 Fornece os critérios de aceitação para as estórias de usuário a serem
desenvolvidas em uma Sprint.
 Inspeciona as entregas.

Scrum máster : garantir que todas as cerimônias e estratégias do Scrum estejam sendo
executadas no projeto e de forma correta

 Garante que os processos do Scrum sejam corretamente seguidos por todos os

membros do time, incluindo o Dono do Produto.
 Assegura que o desenvolvimento do produto ou serviço está ocorrendo sem
problemas e que os membros do Time Scrum têm todas as ferramentas
necessárias para a realização do trabalho.
 Supervisiona a Reunião de Planejamento da release e agenda as outras reuniões.

Gerente de projetos: é a pessoa designada pela organização executora para liderar a

equipe responsável por alcançar os objetivos do projeto. Os relacionamentos de
subordinação do gerente do projeto baseiam-se na estrutura da organização e na
governança do projeto

STAKEHOLDERS: É um termo coletivo que inclui, clientes, usuários e

patrocinadores. Interage frequentemente com o Dono do Produto, Scrum Master e com
o Time Scrum para fornecer inputs e facilitar a criação das entregas do projeto.

TIME SCRUM

 Assume a responsabilidade coletiva e garante que as entregas do projeto sejam

criadas de acordo com os requisitos.
 Garante ao Dono do Produto e ao Scrum Master que o trabalho alocado está
sendo realizado de acordo com o plano.

A comunicação começa na interação entre a equipe do projeto e o cliente, ou seja, não

se reserva apenas de forma interna, e sim com todos os envolvidos. Então, identificar os
requisitos é um processo que deve ser executado de forma muito clara, pois, imagine
documentar um requisito de forma incorreta seguindo uma metodologia tradicional;
você, talvez, só descubra o engano no final do projeto, no momento em que pensava que
tudo estava finalizado.
De acordo com o Guia PMBOK (PMI, 2017, p. 360), a “comunicação é a troca de
informações, intencional ou involuntária. As informações trocadas podem estar em
forma de ideias, instruções ou emoções”. O guia apresenta alguns mecanismos por meio
dos quais as informações são trocadas:

 Em forma escrita: podendo ser utilizados meios físicos (como cartas, notas) ou
eletrônicos (e-mails, publicações).
 Em forma falada: podendo ser presencial (reuniões) ou remoto (reuniões
remotas, videoconferências).
 Formais ou informais: por meio de documentos formais ou em mídia social.
 Por meio de gestos: tom de voz e expressões faciais.
 Por meio de mídias: imagens, ações ou mesmo pela escolha de palavras.
 Escolha de palavras: aquelas que melhor se adequem à ocasião, como o uso de
termos técnicos em reuniões em que nem todos os presentes conhecem o
contexto.

Termo de abertura do projeto: é um documento que apresenta, na maioria das vezes,

todas as informações sobre o projeto, abrangendo desde objetivos, a premissas, situação
atual, justificativa do projeto e critérios de sucesso, em que metas podem ser
apresentadas. Uma Estrutura Analítica do Projeto (EAP) também já pode ser inserida.
Por meio da representação gráfica, é possível mostrar às pessoas como o seu
gerenciamento de projeto acontecerá.

Plano de Gerenciamento do Projeto: geralmente, esse documento apresenta outros

componentes do projeto, como escopo, qualidade, recursos. Então, ele apresenta uma
lista de marcos, ou seja, etapas mais importantes do projeto, por exemplo: a aprovação
do próprio Termo de Abertura pode ser vista como um marco, pois é um momento
importante, assim como alguma entrega também pode ser considerado um marco. Na
realidade, acaba tudo sendo muito subjetivo, já que depende das prioridades do projeto.