HIST�RIA DOS COMPUTADORES

							ENGENHARIA DE
  SOFTWARE


   FIC - FACICOMP

PROF. FABRÍCIA PIRES
   PRODUTOS DE SOFTWARE
MODELO ARTESANAL
     Os desenvolvedores de software
      não são bons estimadores por:
1. Não saberem exatamente o que é estimativa;
2. Não fazerem previsões adequadas para
   contrabalançar o efeito de distorções (previsão
   de problemas);
3. Não saberem lidar com os problemas políticos
   que dificultam o processo de estimativa;
4. Não basearem as estimativas em
   desempenhos passados.
         Objetivo do projetista
Construir um modelo ou representação
que será produzido posteriormente.
É necessário:
– Intuição e julgamento;           -> decisão!
– Experiência;                     -> como adquirir?
– Princípios para orientar a maneira de se desenvolver;
                                   -> conhecimento
– Critérios para julgar a qualidade do que esta ficando pronto.
                            -> sinceridade!
 A importância do projeto de
          software
Qual será o maior objetivo de se fazer um
projeto um software?



            QUALIDADE!!
Causas dos problemas levantados:
a falta de experiência dos profissionais na condução de
projetos de software;

a falta de treinamento no que diz respeito ao uso de
técnicas e métodos formais para o desenvolvimento de
software;

a “cultura de programação” que ainda é difundida e
facilmente aceita por estudantes e profissionais de
Ciências da Computação;

a incrível "resistência" às mudanças (particularmente, no
que diz respeito ao uso de novas técnicas de
desenvolvimento de software).
MODELOS DE PROJETOS
Todos recebem condições para melhorar
        nos seguintes aspectos:
Criatividade: O engenheiro consegue expandir a
sua mente para o que pode ser feito, não ao que ele
está acostumado a fazer e, empiricamente, acha
que é o melhor;
Fazer planos: Cada engenheiro é levado a planejar
seus projetos e até o seu dia-a-dia para aproveitar
melhor o pouco tempo que é dado para o
desenvolvimento de algum software;
Gerenciar Planos: Procurar cumprir o que foi
estabelecido;
Reduzir defeitos: O engenheiro procura, a cada fase
do processo de software, fazer prevenção e
correção de erros para manter um projeto de
qualidade até seu final.
      Conceito de processo
  Processo é um conjunto de passos
  parcialmente ordenados, constituídos por
  atividades,     métodos,   praticas    e
  transformações, usado para atingir uma
  meta.
  Um processo é uma receita que é seguida
  por um projeto.
Projeto(abstrato) -> Processo(receita) -> Produto
            Processos
O processo é o instrumento capaz de
responder a qualquer momento:

O que é feito? (Produto)
Como é feito? (Passos)
Por quem é feito? (Agente)
O que usa? (Insumos)
O que Produz? (resultados)
         O que é um Projeto?
    Um projeto é um esforço temporário
    empreendido para criar um produto ou serviço.

     Projetar: estimar a criação de um sistema

    As principais características dos projetos:
–    Temporários: início e fim definidos.
–    Planejados, executado e controlado.
–    Entregam produtos ou serviços.
–    Desenvolvidos em etapas .
–    Realizados por pessoas.
–    Recursos limitados.
           Planejamento e Gerenciamento de
                  Projeto de Software
1. Definição das atividades
2. Estimativas e Métricas
     –   Dimensionamento do software
     –   Cálculo do esforço
3.   Análise dos Riscos
4.   Definição Equipe
5.   Alocação de tarefas
6.   Cronograma
7.   Orçamento
            Planejamento
Planejamento do projeto é uma atividade
contínua, desde a concepção inicial do software
até sua entrega.
Os planos devem ser revisados regularmente, à
medida que novas informações se tornam
disponíveis. Caso seja necessário, o plano deve
ser atualizado.
O plano de projeto é um documento que
descreve as atividades, os recursos e o
cronograma usados para o desenvolvimento do
software.
 Planejamento e gerenciamento




1.   Planejamento
     Previsão de atividades, recursos, custos e prazos
     Estimativas do produto e processo
2.   Gerenciamento
     Controle de acordo com o que foi planejado
     Verificação da qualidade do produto e do processo
           Dificuldades
O software é intangível
Não há um processo de software padrão
A ES não possui a mesma tradição e status de outras
engenharias – civil, mecânica e elétrica.
Grandes projetos de software são freqüentemente
únicos.
                     Aspectos comuns
Técnicas de planejamento e gerenciamento são
amplamente aplicadas em diversas áreas
Planejamento e gerenciamento são atividades comuns
em outras engenharias
MODELO BÁSICO
Planejamento
 Gerenciamento e Avaliação
Gerenciamento do Processo
 Os prazos estão sendo cumpridos?
 Os custos estão dentro do orçamento?
 A equipe obedece à alocação de tarefas?
 As ferramentas estão adequadas?
 As atividades estão sendo realizadas com
 planejadas?
     Avaliação do produto

Os modelos, protótipos e documentos
estão sendo produzidos com qualidade?

O software produzido tem qualidade?
Modelo de Gantt
Linha de tempo
Alocação pessoa-atividade
PMI - PROJECT MANAGEMENT
         INSTITUTE
É uma associação de profissionais de
gerenciamento de projetos
PMBOK PMBoK – Project management
Body of Knowledge;

Um guia que descreve a somatória de
conhecimento e as melhores práticas
dentro da profissão de gerenciamento de
projetos.
          Mitos e realidades
Mito 1. "Se a equipe dispõe de um manual repleto de
padrões e procedimentos de desenvolvimento de
software, então a equipe está apta a encaminhar bem o
desenvolvimento.“

Realidade 1. Isto verdadeiramente não é o suficiente...
é preciso que a equipe aplique efetivamente os
conhecimentos apresentados no manual... é necessário
que o que conste no dado manual reflita a moderna
prática de desenvolvimento de software e que este seja
exaustivo com relação a todos os problemas de
desenvolvimento que poderão aparecer no percurso...
        Mitos e realidades
Mito 2. "A equipe tem ferramentas de
desenvolvimento de software de última geração,
uma vez que eles dispõem de computadores de
última geração.“

Realidade 2. Ter à sua disposição o último
modelo de computador (seja ele um mainframe,
estação de trabalho ou PC) pode ser bastante
confortável para o desenvolvedor do software,
mas não oferece nenhuma garantia quanto à
qualidade do software desenvolvido.
          Mitos e realidades
Mito 3. "Se o desenvolvimento do software estiver
atrasado, basta aumentar a equipe para honrar o prazo
de desenvolvimento."

Realidade 3. Isto também dificilmente vai ocorrer na
realidade... alguém disse um dia que "... acrescentar
pessoas em um projeto atrasado vai torná-lo ainda mais
atrasado...". De fato, a introdução de novos profissionais
numa equipe em fase de condução de um projeto vai
requerer uma etapa de treinamento dos novos
elementos da equipe; para isto, serão utilizados
elementos que estão envolvidos diretamente no
desenvolvimento, o que vai, conseqüentemente, implicar
em maiores atrasos no cronograma.
Mitos do Cliente
           Mitos e realidades
Mito 4. "Uma descrição breve e geral dos requisitos do
software é o suficiente para iniciar o seu projeto... maiores
detalhes podem ser definidos posteriormente."

Realidade 4. Este é um dos problemas que podem
conduzir um projeto ao fracasso, o cliente deve procurar
definir o mais precisamente possível todos os requisitos
importantes para o software: funções, desempenho,
interfaces, restrições de projeto e critérios de validação são
alguns dos pontos determinantes do sucesso de um
projeto.
          Mitos e realidades
 Mito 5. "Os requisitos de projeto mudam continuamente
durante o seu desenvolvimento, mas isto não representa
um problema, uma vez que o software é flexível e
poderá suportar facilmente as alterações."

Realidade 5. É verdade que o software é flexível (pelo
menos mais flexível do que a maioria dos produtos
manufaturados). Entretanto, não existe software, por
mais flexível que suporte alterações de requisitos
significativas com adicional zero em relação ao custo de
desenvolvimento.
Mitos do Profissional
        Mitos e realidades
Mito 6. "Após a edição do programa e a sua
colocação em funcionamento, o trabalho está
terminado."

Realidade 6. O que ocorre na realidade é
completamente diferente disto. Segundo dados
obtidos a partir de experiências anteriores, 50 a
70% do esforço de desenvolvimento de um
software é despendido após a sua entrega ao
cliente (manutenção).
        Mitos e realidades
Mito 7. "Enquanto o programa não entrar em
funcionamento, é impossível avaliar a sua
qualidade."

Realidade 7. Na realidade, a preocupação com
a garantia do software deve fazer parte de todas
as etapas do desenvolvimento, sendo que, ao
fim de cada uma destas etapas, os documentos
de projeto devem ser revisados observando
critérios de qualidade.
        Mitos e realidades
Mito 8. "O produto a ser entregue no final do
projeto é o programa funcionando."

Realidade 8. O programa em funcionamento é
uma das componentes do software...além do
software,   um    bom   projeto  deve  ser
caracterizado pela produção de um conjunto
importante de documentos.
       Mitos e realidades
Mito 9. “Dê a uma pessoa técnicas e um bom
livro de programação e você terá um
programador”.

Realidade 9. Programar é um exercício
intelectual e exige além de conhecimentos e
habilidades, o dom de abstração e muito
raciocínio lógico.
        Mitos e realidades
Mito 10. “Um projeto bem sucedido é um
programa funcionando corretamente.“

Realidade 10. sim! Um programa funcionando
corretamente é um sinal de que seus projetos
deram certo, entretanto empresas de software
sobrevivem de marketing e da satisfação dos
clientes.