Processos de Software
Herbert Rausch Fernandes
Última atualização: 23/03/2015
Por que Engenharia de
Software
Fonte: Google Images
FAQ[1]
Fonte: SOMMERVILLE, IAN.Engenharia de Software. 9ª edição.
FAQ[2]
Fonte: SOMMERVILLE, IAN.Engenharia de Software. 9ª edição.
FAQ[2]
Fonte: SOMMERVILLE, IAN.Engenharia de Software. 9ª edição.
NO SILVER BULLETS [Frederick P. Brooks, Jr] -
Não há bala de prata
Texto completo em: http://www.cs.nott.ac.uk/~cah/G51ISS/Documents/NoSilverBullet.html
Atributos de um BOM
software
Fonte: SOMMERVILLE, IAN.Engenharia de Software. 9ª edição.
Fundamentos da Engenharia
de Software
1. Processo de desenvolvimento gerenciado e
compreendido.
2. Confiança e desempenho.
3. Gerenciar as especificações e requisitos do software.
4. Quando possível, você deve reusar software que já foi
desenvolvido.
Softwares falham
Fonte: PRESSMAN, Roger.Engenharia de Software: Uma abordagem Profissional. 7ª edição.
...e evoluem
Fonte: PRESSMAN, Roger.Engenharia de Software: Uma abordagem Profissional. 7ª edição.
●
●
●
●
infinito, e além.
...e evoluem
Fonte: SOMMERVILLE, IAN.Engenharia de Software. 9ª edição.
Processo
Processo é um conjunto de atividades, ações e tarefas
realizadas com atores/papéis definidos para atingir um
objetivo.
Inscrição
vestibular
Prova
Aprovação
Documentação
Matrícula
Lançamento no
sistema Q-Acadêmico
Candidato
Registro Escolar
Processo
Uma atividade de processo pode-se desmembrar em outro
processo. Exemplo, subprocesso “Matrícula”:
Pegar senha na
fila
Entregar
documentação
Preencher
Formulário
Assinar
Formulário
Entregar
FormulárioCandidato
Processo de Software[1]
Comunicação
Planejamento
Modelagem
Construção
Entrega
5 atividades genéricas.
Processo de Software[2]
Fonte: PRESSMAN, Roger.Engenharia de Software: Uma abordagem Profissional. 7ª edição.
Atividade Guarda-Chuva[1]
Atividades de apoio
Atividades que são aplicadas ao longo do projeto.
Acompanhamento
de projeto
Gerenciamento
de riscos
QualidadeRevisões Métricas
ReusoControle de versão
Atividade Guarda-Chuva[2]
Atividades de apoio
1. Controle e acompanhamento do projeto.
○ Avaliação do progresso do projeto em relação ao plano de projeto.
2. Administração de riscos.
○ Avaliação dos riscos que podem afetar os resultados.
3. Garantia da qualidade de software.
○ Definição e condução de atividades que garantem a qualidade.
4. Revisões técnicas.
○ Avaliação de artefatos tentando identificar e eliminar erros antes que
propaguem.
Atividade Guarda-Chuva[2]
Atividades de apoio
5. Medição.
○ Definição e coleta de medidas (do processo, do projeto, do produto).
6. Gerenciamento da configuração de software.
○ Gerenciamento das mudanças do software ao longo do processo.
7. Gerenciamento de reusabilidade.
○ Definição de critérios para o reúso de artefatos.
Adaptação de um Modelo de
Processo
● Modelo de processo é um “molde” que pode, e deve,
ser adaptado de acordo com o projeto.
● Processos precisam de métricas de qualidade.
Modelo Cascata[1]
Fonte: SOMMERVILLE, IAN.Engenharia de Software. 9ª edição.
Modelo Cascata[2]
● Dificuldade de acomodação de mudanças.
● Dificuldade em responder mudanças.
● Só é apropriado quando:
○ os requisitos são bem entendidos, e;
○ as mudanças durante o processo de projeto serão
limitadas.
● Poucos sistemas de negócio possuem requisitos
estáveis.
Modelo Incremental[1]
Fonte: SOMMERVILLE, IAN.Engenharia de Software. 9ª edição.
Modelo Incremental[2]
Fonte: PRESSMAN, Roger.Engenharia de Software: Uma abordagem Profissional. 7ª edição.
Modelo Incremental[3]
● O custo para acomodar mudanças nos requisitos do cliente é
reduzido.
● Redução na quantidade de análise e documentação.
● Feedback do cliente facilitada.
○ Os clientes podem:
■ comentar demonstrações do software e
■ ver quanto foi implementado.
● Baixa visibilidade do processo.
○ Gerentes precisam de entregas regulares para medir o
progresso.
○ Se as entregas são rápidas, o custo para produzir
documentação que refletem as versões do sistema não é
viável.
Modelo Incremental[4]
● Os requisitos do usuário são priorizados.
● Os requisitos de mais alta prioridade são incluídos nos
primeiros incrementos.
● O sistema tende a degradar com novos incrementos.
○ Necessário investimento de tempo e dinheiro para a
refatoração do sistemas.
Prototipação
Fonte: SOMMERVILLE, IAN.Engenharia de Software. 9ª edição.
Prototipação
● É comumente utilizada pelos outros modelos de
processo.
● Auxiliam para elucidar requisitos que não são bem
entendidos.
● Os protótipos são avaliados pelos clientes, que
fornecerão o feedback.
● Os protótipos devem ser descartados.
“Resista à pressão de estender um protótipo grosseiro a um produto
final. Quase sempre como resultado, a qualidade fica comprometida”
[Pressman, 2011].
Modelo Espiral
Fonte: SOMMERVILLE, IAN.Engenharia de Software. 9ª edição.
Modelo Espiral
● Definição de objetivos.
○ Identifica-se o objetivo de cada fase
● Avaliação e redução de riscos.
○ Avaliação dos riscos e execução de atividades para
reduzir os principais riscos.
● Desenvolvimento e validação.
○ Escolha do modelo de desenvolvimento
● Planejamento.
○ Revisão do projeto e planeja o próximo loop da
espiral
Modelo Espiral
● Cada loop na espiral representa uma fase do processo.
● Os loops na espiral são escolhidos de acordo com a
necessidade.
● Os riscos são avaliados explicitamente e resolvidos no
decorrer do processo.
● Os custos são sempre revistos no planejamento.
○ Essa abordagem não é ideal quanto os custos de
desenvolvimento são fixos
Exercícios

[CEFETMG][ESw] Aula 2 - Processos de software

  • 1.
    Processos de Software HerbertRausch Fernandes Última atualização: 23/03/2015
  • 2.
    Por que Engenhariade Software Fonte: Google Images
  • 3.
  • 4.
  • 5.
    FAQ[2] Fonte: SOMMERVILLE, IAN.Engenhariade Software. 9ª edição. NO SILVER BULLETS [Frederick P. Brooks, Jr] - Não há bala de prata Texto completo em: http://www.cs.nott.ac.uk/~cah/G51ISS/Documents/NoSilverBullet.html
  • 6.
    Atributos de umBOM software Fonte: SOMMERVILLE, IAN.Engenharia de Software. 9ª edição.
  • 7.
    Fundamentos da Engenharia deSoftware 1. Processo de desenvolvimento gerenciado e compreendido. 2. Confiança e desempenho. 3. Gerenciar as especificações e requisitos do software. 4. Quando possível, você deve reusar software que já foi desenvolvido.
  • 8.
    Softwares falham Fonte: PRESSMAN,Roger.Engenharia de Software: Uma abordagem Profissional. 7ª edição.
  • 9.
    ...e evoluem Fonte: PRESSMAN,Roger.Engenharia de Software: Uma abordagem Profissional. 7ª edição. ● ● ● ● infinito, e além.
  • 10.
    ...e evoluem Fonte: SOMMERVILLE,IAN.Engenharia de Software. 9ª edição.
  • 11.
    Processo Processo é umconjunto de atividades, ações e tarefas realizadas com atores/papéis definidos para atingir um objetivo. Inscrição vestibular Prova Aprovação Documentação Matrícula Lançamento no sistema Q-Acadêmico Candidato Registro Escolar
  • 12.
    Processo Uma atividade deprocesso pode-se desmembrar em outro processo. Exemplo, subprocesso “Matrícula”: Pegar senha na fila Entregar documentação Preencher Formulário Assinar Formulário Entregar FormulárioCandidato
  • 13.
  • 14.
    Processo de Software[2] Fonte:PRESSMAN, Roger.Engenharia de Software: Uma abordagem Profissional. 7ª edição.
  • 15.
    Atividade Guarda-Chuva[1] Atividades deapoio Atividades que são aplicadas ao longo do projeto. Acompanhamento de projeto Gerenciamento de riscos QualidadeRevisões Métricas ReusoControle de versão
  • 16.
    Atividade Guarda-Chuva[2] Atividades deapoio 1. Controle e acompanhamento do projeto. ○ Avaliação do progresso do projeto em relação ao plano de projeto. 2. Administração de riscos. ○ Avaliação dos riscos que podem afetar os resultados. 3. Garantia da qualidade de software. ○ Definição e condução de atividades que garantem a qualidade. 4. Revisões técnicas. ○ Avaliação de artefatos tentando identificar e eliminar erros antes que propaguem.
  • 17.
    Atividade Guarda-Chuva[2] Atividades deapoio 5. Medição. ○ Definição e coleta de medidas (do processo, do projeto, do produto). 6. Gerenciamento da configuração de software. ○ Gerenciamento das mudanças do software ao longo do processo. 7. Gerenciamento de reusabilidade. ○ Definição de critérios para o reúso de artefatos.
  • 18.
    Adaptação de umModelo de Processo ● Modelo de processo é um “molde” que pode, e deve, ser adaptado de acordo com o projeto. ● Processos precisam de métricas de qualidade.
  • 19.
    Modelo Cascata[1] Fonte: SOMMERVILLE,IAN.Engenharia de Software. 9ª edição.
  • 20.
    Modelo Cascata[2] ● Dificuldadede acomodação de mudanças. ● Dificuldade em responder mudanças. ● Só é apropriado quando: ○ os requisitos são bem entendidos, e; ○ as mudanças durante o processo de projeto serão limitadas. ● Poucos sistemas de negócio possuem requisitos estáveis.
  • 21.
    Modelo Incremental[1] Fonte: SOMMERVILLE,IAN.Engenharia de Software. 9ª edição.
  • 22.
    Modelo Incremental[2] Fonte: PRESSMAN,Roger.Engenharia de Software: Uma abordagem Profissional. 7ª edição.
  • 23.
    Modelo Incremental[3] ● Ocusto para acomodar mudanças nos requisitos do cliente é reduzido. ● Redução na quantidade de análise e documentação. ● Feedback do cliente facilitada. ○ Os clientes podem: ■ comentar demonstrações do software e ■ ver quanto foi implementado. ● Baixa visibilidade do processo. ○ Gerentes precisam de entregas regulares para medir o progresso. ○ Se as entregas são rápidas, o custo para produzir documentação que refletem as versões do sistema não é viável.
  • 24.
    Modelo Incremental[4] ● Osrequisitos do usuário são priorizados. ● Os requisitos de mais alta prioridade são incluídos nos primeiros incrementos. ● O sistema tende a degradar com novos incrementos. ○ Necessário investimento de tempo e dinheiro para a refatoração do sistemas.
  • 25.
  • 26.
    Prototipação ● É comumenteutilizada pelos outros modelos de processo. ● Auxiliam para elucidar requisitos que não são bem entendidos. ● Os protótipos são avaliados pelos clientes, que fornecerão o feedback. ● Os protótipos devem ser descartados. “Resista à pressão de estender um protótipo grosseiro a um produto final. Quase sempre como resultado, a qualidade fica comprometida” [Pressman, 2011].
  • 27.
    Modelo Espiral Fonte: SOMMERVILLE,IAN.Engenharia de Software. 9ª edição.
  • 28.
    Modelo Espiral ● Definiçãode objetivos. ○ Identifica-se o objetivo de cada fase ● Avaliação e redução de riscos. ○ Avaliação dos riscos e execução de atividades para reduzir os principais riscos. ● Desenvolvimento e validação. ○ Escolha do modelo de desenvolvimento ● Planejamento. ○ Revisão do projeto e planeja o próximo loop da espiral
  • 29.
    Modelo Espiral ● Cadaloop na espiral representa uma fase do processo. ● Os loops na espiral são escolhidos de acordo com a necessidade. ● Os riscos são avaliados explicitamente e resolvidos no decorrer do processo. ● Os custos são sempre revistos no planejamento. ○ Essa abordagem não é ideal quanto os custos de desenvolvimento são fixos
  • 30.