PROCESSO DE SOFTWAREProf. Naan Cardoso

Temos muitos PROBLEMAS, a quem podemos recorrer?

ENGENHARIA

2

[IEEE] aplicação de uma abordagem:

▪ Sistemática parte do princípio de que existe um processo dedesenvolvimento definindo as atividades que deverão serexecutadas

▪Disciplinada processos definidos serão seguidos

▪Quantificável deve definir um conjunto de medidas a seremextraídas no processo

▪Desenvolvimento, operação e manutenção de software são fasesdo processo de software

3

Mas o que é umprocesso?

Ferramentas

Métodos

Processo

Foco na qualidade

4Fonte: Adaptado de [PRESMMAN, R., 1995]

▪O objetivo de qualquer engenharia é a busca pelaqualidade (não apenas ES)

▪Deve ser buscada em cada fase do processo dedesenvolvimento

▪Permite ao:▪ gerente (controle)

▪ desenvolvedor (referência)

5

Ferramentas

Métodos

Processo

Foco na qualidade

6Fonte: Adaptado de [PRESMMAN, R., 1995]

▪Detalhes de “COMO FAZER” para construir o software▪ Existem métodos para diferentes tarefas

▪Planejamento e estimativa do projeto▪ Análise de requisitos

▪Projeto de estrutura de dados▪ Codificação, teste e manutenção

7

Ferramentas

Métodos

Processo

Foco na qualidade

8Fonte: Adaptado de [PRESMMAN, R., 1995]

▪Proporcionam apoio automatizado ou semiautomatizadodos métodos

▪Cada tarefa pode ter uma ou mais ferramentas paraauxiliar

▪Para as ferramentas integradas (troca de informação)denominamos:

▪ Ferramentas CASE (Computer Aided Software Engineering), ou seja,Engenharia de Software auxiliada por computador

9

Ferramentas

Métodos

Processo

Foco na qualidade

10Fonte: Adaptado de [PRESMMAN, R., 1995]

▪ Esta é a camada mais importante, pois constitui o elo entre asferramentas e os métodos

▪ “Processo de Software “é um roteiro que ajuda a criar um resultadode alta qualidade e dentro do prazo estabelecido” [PRESSMAN,2011].

▪ Define a sequência que os métodos serão aplicados▪ Quais os responsáveis por cada tarefa

▪ Quando e como o software será entregue

▪ Possibilitam aos gerentes avaliar o progresso do desenvolvimento

11

Uma empresa pode usarmétodos e ferramentas e nãoseguir nenhum processo.

▪ Sequência de fases e atividades a serem desenvolvidas no transcorrerdo projeto.

▪ Também conhecido como Plano de Projeto ou Metodologia deDesenvolvimento de Sistemas.

✓ Objetivo do Ciclo de Vida de um Sistema?

✓ Definir as atividades a serem executadas em um projeto de desenvolvimentode sistemas.

✓ Introduzir consistência entre muitos projetos de desenvolvimento desistemas da mesma organização.

✓ Introduzir pontos de verificação para o controle gerencial de decisões.12

MODELOS DE PROCESSOS

13

Clássico / Tradicional / Cascata

Prototipação

Incremental

Evolutivo

Espiral

RAD

Orientado a Reuso

4ª geração...

▪ Independente do modelo, inclui-se as seguintes atividades:

▪Comunicação

▪Planejamento

▪Modelagem

▪Construção

▪ Implantação

14

▪Teoria: é quando você sabe o porquê de tudo, mas nadafunciona.

▪Prática: é quando tudo funciona, mas ninguém sabe o porque.

▪Em muitas empresas, alia-se a teoria à prática: nadafunciona e ninguém sabe por que.

15

▪Define as fases que conectam o início ao fim do projeto.

▪Uma fase pode vir a constituir um projeto:▪ Estudo de viabilidade

▪A transição entre fases envolve transferência técnica ou uma entrega.

▪ Normalmente uma fase só é iniciada quando a entrega (produto tangível e verificável) da fase anterior estiver completa, revisada e aprovada – mas a superposição entre fases pode ocorrer.

16

O que definem?

▪ Quais atividades técnicas devem ser executadas em cada fase

▪ Quando as entregas devem ser geradas e como serão revisadas

▪ Quem está envolvido em cada fase

▪ Como controlar e aprovar cada fase

17

Deve haver uma revisão ao final das fases para avaliar aentrega e o desempenho do projeto:

▪Avaliar se o projeto deve continuar na próxima fase

▪ Identificar e corrigir erros a um custo aceitável

18

Processos de

Iniciação

Processos

de Execução

Processos de

Planejamento

Processos de

Controle

Processos de

Encerramento

Fase de Projeto

Fase de Codificação

Processos de

Iniciação

Processos

de Execução

Processos de

Planejamento

Processos de

Controle

Processos de

Encerramento

19

▪ Custos e quantidade de pessoas é baixo no início do projeto, cresceno seu decorrer e volta a diminuir no final

▪ No início os riscos e as incertezas são elevados

▪ A influência das partes interessadas é maior no início do projeto

▪ Subprojetos devem ter seu ciclo de vida próprio

20

▪ Possuem influência no objetivo, resultados e ciclo de vida do projeto

▪ A influência pode ser positiva ou negativa, dependendo do benefícioou perda decorrente do projeto

▪ Possuem responsabilidades e autoridade

▪ As partes, ou o gerente, ignorar essas responsabilidades, prejudica oprojeto

21

▪ Marco - produto final de uma fase.

▪ Ponto de controle - produtos intermediários da fase ou de umasubfase.

▪ Pontos de controle visam garantir que o marco será concluído noprazo e qualidade esperada.

22

▪São conceitos diferentes▪ Projeto – fases do início ao fim do projeto.

▪ Produto – fases do início ao fim do produto.

▪Dificilmente coincidem.

▪Em software o projeto normalmente está associado aodesenvolvimento e não inclui a operação e manutenção.

23

▪ Também conhecido como Modelo em Cascata/Linear Sequencial

▪ É caracterizado por uma abordagem sequencial para o desenvolvimento dosoftware

▪ Cada atividade é uma fase distinta.

▪ Só após o seu total término é que a próxima atividade começa

▪ Grande ênfase para a documentação▪ Os serviços, restrições e objetivos do sistema são definidos por meio de consulta aos

usuários do sistema

24

◼ Investigação do sistema: Levantamento dos requisitos. “Qual oproblema?”

◼ Análise do sistema: “O que o sistema precisa fazer para resolver oproblema?”

◼ Projeto do sistema: “Como o sistema deverá agir para resolver oproblema?”

◼ Implementação do sistema: Fazer a solução funcionar. Criação ouaquisição dos componentes.

◼ Manutenção e revisão: assegurar a operação do sistema, de formaque continue a atender as necessidades do negócio.

Investigação dos sistemasEntender o problema

Análise dos sistemasEntender a solução

Criação do sistemaSelecionar e planejar a melhor solução

Implementação do sistemaPor a solução em prática

Manutenção e inspeção do sistemaAvaliar os resultados de uma solução

Fonte: Stair, 1999

25

26

27

Requisitos

Projeto

Implementar

Teste

Implantação

ManutençãoSoftware em produção

Como?

O que?

▪A especificação do sistema:

▪Deverá responder às perguntas:▪ Quais informações o sistema deverá prover?

▪ Quais informações o sistema NÃO deverá prover?

28

29

▪Análise detalhada dos requisitos levantados na atividadeanterior, definição do tempo estimado para entrega(cronograma de execução)

▪Uma especificação formal dos requisitos é produzida,representando todos os requisitos analisados

▪Definir mecanismo que permita a monitoração do projeto

▪ Será que o projeto irá atender as estimativas de TEMPO e CUSTO30

Ferramentas de auxílio (MS-Project, Open Project)

31

▪ Selecionar e planejar um sistema que satisfaça os requisitosnecessários para a solução do problema

▪ Estabelecer a arquitetura do sistema que envolve:▪ Identificar e descrever as abstrações fundamentais e suas relações

32

▪ O objetivo principal desta etapa é criar as estruturas físicas dedados, codificar e testar o sistema.

▪ Nesta fase é usual utilizar uma IDE (Integrated DevelopmentEnvironment), ou seja, ambiente integrado de desenvolvimento

▪ São feitos testes unitários que envolve a verificação de que cadaunidade atende sua especificação

▪ Transforma o que foi produzido durante o projeto em programa

33

▪ Alterações das especificações do projeto implementado

▪ Qualquer modificação que aconteça no sistema após aimplementação

▪ Manutenção envolve a correção de erros não detectados, além daampliação dos serviços do sistema à medida que novos requisitossão identificados

34

▪ Mais antigo e testado modelo de processo

▪ Enfoque sistemático e sequencial das tarefas

▪ Muitas melhorias e variações

35

▪ Dificilmente projetos reais seguem um fluxo sequencial

▪ Nem sempre é possível estabelecer, inicialmente, todos os requisitosnecessários, devido a incertezas tanto do cliente quanto do desenvolvedor.

▪ O cliente deve esperar até o final de todas as etapas para saber como seráo produto. Nem sempre ele consegue visualizar exatamente como será oproduto final.

▪ Resultado:▪ Clientes insatisfeitos

▪ Modificações no sistema▪ Aumento dos custos

▪ Possibilidade de introdução de erros

36

▪ Foi criado para evitar que o produto final não corresponda às expectativasdo cliente

▪ Caracteriza-se por criar, logo no início, uma versão simplificada dosoftware (protótipo)

▪ Processo de desenvolvimento baseado em um ciclo de realimentação deinformações, com alta participação do usuário

▪ Pouca ênfase é dada a documentação

37

▪O protótipo pode ser:

▪ Um protótipo em papel

▪ Um programa executável, mas que executa parte ou toda a função

desejada, mas que deverá sofrer melhoras na interface ou na

performance

▪ Um programa executável, mas que apenas demonstra a “cara” do

programa e sua interface com o usuário.

38

39

fim

início

construção

produto

refinamento

protótipo

avaliação

protótipo

construção

protótipo

projeto

rápido

obtenção

dos

requisitos

40

▪ Semelhante à fase de levantamento de requisitos e análise domodelo clássico

▪ Desenvolvedor e cliente definem os objetivos do software

41

▪ Realiza-se um projeto simplificado do sistema final

▪ Geralmente concetra-se nas partes visíveis ao usuário, ou seja:▪ as interfaces de diálogo e

▪ interfaces para entrada e saída de dados

▪ Implementação do projeto rápido

42

▪ O cliente utiliza o protótipo para avaliar se o que está sendodesenvolvido é o que ele espera

▪ O protótipo, portanto, serve para refinar os requisitos iniciaisestabelecidos

▪ Esse primeiro sistema deve servir apenas para avaliação e serposteriormente descartado

43

▪ Cliente e desenvolvedor verificam o que deve ser alterado naespecificação inicial

▪ Após esta etapa, as fases de 2 a 5 (projeto rápido até refinamento doprotótipo) podem ser repetidas diversas vezes, até que não sejamnecessários mais refinamentos

▪ Só então, realiza-se a sexta e última etapa, que consiste emimplementar o software final

44

45

▪ É apropriado quando o cliente define um conjunto de objetivosgerais, mas não identificou claramente requisitos de entrada, saída eprocessamento

▪ É apropriado quando o desenvolvedor não tem certeza da melhorabordagem de implementação, algoritmo ou interface e decidetestar antes de implementar o produto final

46

▪ O cliente pensa que o protótipo já está bom o suficiente e tentaforçar o seu uso como final, ou diminuir prazos.

▪ O desenvolvedor tenta gerar o software final a partir do protótipo,com o objetivo de acelerar o processo.▪ Introduzir erros

▪ Gerar conflitos internos

47

▪ O desenvolvedor “esquece” que as escolhas tomadas naprototipação não são as mais apropriadas e utiliza estruturas dedados inadequadas ou não tão eficientes.

▪ Solução:

▪ Deixar claro para o cliente, logo de início, o objetivo do protótipo

48

▪ O desenvolvimento e a entrega é dividida em incrementos com cadaincremento entregando parte da funcionalidade requerida.

▪ Os requisitos dos usuários são priorizados e os requisitos de maiorprioridade são incluídos em incrementos iniciais.

▪ Várias partes do sistema são desenvolvidas em paralelo, eintegradas quando completas.

49

50

▪ Enfoque para sistemas modulares ou baseado em subsistemas

▪ Utilizado como estratégia para projetos muito grandes

▪ Menores riscos de falha no projeto em geral.

▪ Os serviços do sistema de alta prioridade tendem a receber amaioria dos testes.

51

▪ É formado por múltiplos ciclos da abordagem cascata

▪ Ocorre sobreposição das fases da operação e manutenção do sistemaanterior com o novo desenvolvimento.

▪ Esta abordagem é adequada quando:

▪ É necessário alguma experiência do usuário para refinar e completar requisitos;

▪ Algumas partes da implementação podem depender da existência detecnologia ainda não disponível;

▪ Existem requisitos do usuário não bem conhecidos;

▪ Alguns requisitos são muito mais difíceis de serem implementados do queoutros, decidindo-se não implementá-lo para não atrasar o projeto.

52

Modelo Incremental

Construção do

incremento 1

Construção do

incremento 2

Requisitos

Modelo Evolutivo

…Requisitos

Construção do

incremento 1Construção do

incremento 2

Requisitos

53

▪ Processo é representado como um espiral ao invés de uma

sequência de atividades com retorno.

▪ Cada volta na espiral representa uma fase (iteração) no processo.

▪ Não existe um número de fases fixas – as voltas no espiral são

escolhidas de acordo com o que é requerido.

54

▪ Sua principal inovação é guiar o processo de desenvolvimento com base

em análise de riscos e planejamento que é realizado durante toda a evolução do

desenvolvimento.

▪ A identificação e o gerenciamento de riscos é hoje uma atividade importante no

desenvolvimento de software devido à:

▪ imaturidade da área

▪ falta de conhecimento

▪ técnicas

▪ ferramentas adequadas.

55

▪ Estágio 1: devem ser determinados objetivos, soluções alternativas erestrições.

▪ Estágio 2: devem ser analisados os riscos das decisões do estágioanterior. Durante este estágio podem ser construídos protótipos ourealizar-se simulações do software.

▪ Estágio 3: consiste nas atividades da fase de desenvolvimento,incluindo design, especificação, codificação e verificação.

56

▪ Estágio 4 compreende a revisão das etapas anteriores e o

planejamento da próxima fase

▪ No planejamento, dependendo dos resultados obtidos nos estágios

anteriores - decisões, análise de riscos e verificação, pode-se optar

por seguir o desenvolvimento num modelo:

▪ Cascata (linear)

▪ Evolutivo

57

Planejamento

Avaliação Implementação

LevantamentoInicial

deRequisitos

Análisede

Risco

Planejamento

Análise

Teste

Avaliação feita peloCliente

Projeto

Modelagem

58

▪ Estimativas (i.e. cronograma) tornam-se mais realísticas com o progresso do

trabalho, porque problemas importantes são descobertos antecipadamente.

▪ É mais versátil para lidar com mudanças (sempre inevitáveis) que

desenvolvimento de software geralmente exigem.

▪ Fácil de decidir quando testar

▪ Não faz distinção entre desenvolvimento e manutenção.

59

▪ Pode ser difícil convencer os clientes de que a abordagem é controlável.

▪ O modelo não é usado na mesma extensão que o linear e o de prototipação, e, por

isso, não foi “testado” o suficiente.

▪ Se um risco não for descoberto, inevitavelmente ocorrerão problemas.

▪ O modelo é relativamente novo e não tem sido amplamente utilizado.

▪ Bem aplicado em sistemas de larga escala. 60

▪ Modelo de processo de desenvolvimento de software iterativo e incremental que

enfatiza um ciclo de desenvolvimento extremamente curto (entre 60 e 90 dias).

▪ O termo foi registrado por James Martin em 1991 e tem substituído gradativamente

o termo de prototipação rápida que já foi muito utilizada no passado

61

62

▪ Enfatiza um ciclo de desenvolvimento extremamente curto (entre 60 e 90 dias)

▪ Cada função principal pode ser direcionada para a uma equipe separada e então

integrada a formar um todo

▪ Criação e reutilização de componentes

▪ Envolvimento maior do usuário

▪ Provável custo reduzido (tempo é dinheiro e também devido ao reuso) 63

▪ O envolvimento com o usuário tem que ser ativo

▪ Comprometimento da equipe do projeto

▪ Mais difícil de acompanhar o projeto (pois não existe os marcos clássicos)

▪ Menos eficientes

▪ Requisitos podem não se encaixar (conflitos entre desenvolvedores e clientes)

▪ Padronização (aparência diferente entre os módulos e componentes)

▪ Menos eficientes64

▪ Este modelo visa o desenvolvimento de sistemas tendo como base uma gama de

componentes reutilizáveis e sistemas disponíveis no mercado.

▪ Partes do software que não puderem ser comprados são desenvolvidos e

integrados a estes componentes.

65

Projeto de Sistema

com Reuso

Desenvolvimento e

Integração

Modificação de

RequisitosAnálise de

Componentes

Especificação de

Requisitos

Evolução do

Sistema

66

Critérios relacionados aos usuários / equipe

Experiência dos usuários no domínio da aplicação.

Facilidade dos usuários em expressar requisitos.

Experiência da equipe de desenvolvimento no domínio da aplicação.

Experiência da equipe de desenvolvimento em engenharia de

software. 67

Critérios relacionados ao problema

Grau de maturidade do domínio da aplicação

Complexidade do problema.

Frequência de mudanças nos requisitos.

Grau de magnitude das mudanças nos requisitos.

Grau de modularidade do problema.

68

Critérios relacionados ao produto

Tamanho da aplicação

Grau de complexidade da aplicação.

Grau de importância dos requisitos de interface.

69

Critérios relacionados aos recursos

Disponibilidade de recursos humanos.

Grau de acesso aos usuários.

70

Critérios relacionados ao desenvolvimento

Aplicável à necessidade de entrega de produtos intermediários.

Grau dos riscos técnicos.

Paradigma adotado

71

▪ Tendo em vista que o desenvolvimento de um software compreende várias fases,que vão desde a definição básica até o uso do software, e que, nesse processo,diversos modelos, métodos e procedimentos de construção podem ser utilizados,julgue os itens subsecutivos.

▪ O ciclo de vida de um software, entre outras características, está relacionado a queestágios?

Resp: concepção, projeto, criação e implementação.

72

▪ Tendo em vista que o desenvolvimento de um software compreendevárias fases, que vão desde a definição básica até o uso do software,e que, nesse processo, diversos modelos, métodos e procedimentosde construção podem ser utilizados, julgue os itens subsecutivos.

▪ No ciclo de vida da primeira versão do modelo em espiral, a etapade análise de riscos é realizada dentro da fase de desenvolvimento.

▪ Certo ou Errado?

Resp: Errado73

▪ Um analista desenvolve um software e identifica que os seus requisitosiniciais estão razoavelmente bem definidos, mas o escopo geral dodesenvolvimento não permite um processo puramente linear. Ele sabe queprecisa, em curtíssimo prazo, prover um conjunto limitado defuncionalidades do software para os usuários, que serão refinadas eexpandidas em versões futuras.

▪ Qual o modelo de ciclo de vida de desenvolvimento de software maisadequado a esse caso?

Resp: Incremental74