Processo de Desenvolvimento de

Prof. Marcos Sousa (Marcão)

Processo de Desenvolvimento de

Software

EMENTA

Objetivos específicos

• Conhecer a necessidade de se adotar um processo de desenvolvimento de software;

• Identificar qual modelo se adapta para cada tipo de software;

• Descrever as fases do processo de desenvolvimento;

Objetivo Geral

Conhecer e utilizar ferramentas que auxiliem no desenvolvimento de um software com base nas metodologias e padrões vigentes.

Processo de Desenvolvimento de Software: Analises iniciais, ciclo de vida de um processo, modelos de processos de desenvolvimento, padrões de processos, processo unificado; Ferramentas: RUP, PRAXIS.

CONTEÚDOS

3

UNIDADE 1 – Conceitos Gerais de Processo de Desenvolvimento de Software (PDS)

• O que é? Para que serve?

• Problemas mais comuns.

UNIDADE 2 – Atividades em PDS

• Análise econômica e de requisitos.

• Especificação do Software.

• Desenho ou Arquitetura do Sistema de Software

• Codificação (Implementação)

• Teste do Produto

UNIDADE 3: Suporte e Manutenção de software

• Documentação.

• Suporte e Treinamento

• Melhoria Continua

UNIDADE 4: Introdução aos padrões de PDS

• CMM/CMMI

• SPICE

• ISSO 12207

• MPS/BR

UNIDADE 5 – Modelagem de PDS

• Processo Cascata (Water Fall) ou TOP DOWN.

• Processo Iterativo.

• Processo Ágil.

UNIDADE 6 – Processo Unificado

• Fases do Processo

• Ciclo de vida do processo

UNIDADE 7 - Ferramentas de PDS

• RUP (Rational Unified Process)

• PRAXIS

BIBLIOGRAFIA

PAULA FILHO, Wilson de Pádua. Engenharia de Software: Fundamentos, Métodos e Padrões. Terceira Edição. Rio de Janeiro: LTC Editora. 2009 SOMMERVILLE, Ian. Engenharia de software. Oitava Edição, Rio de Janeiro: Pearson Education. 2007

GUSTAFSON, Davis A. Engenharia de software. Primeira Edição, Rio de Janeiro: Artmed Editora. 2003

VAMOS BRINCAR UM POUCO?

5

EXERCÍCIO DO DESENHO

VAMOS CONVERSAR?

7

SOFTWARE

DEFINIÇÃO DE SOFTWARE

• Software é uma sequência de instruções escritas para serem interpretadas por um computador com o objetivo de executar tarefas específicas. Também pode ser definido como

os programas que comandam o funcionamento de um computador.

• Software é a parte programável de um sistema de informática.

9

DEFINIÇÃO DE SOFTWARE

SOFTWARE

DEFINIÇÃO DE SOFTWARE

SOFTWARE

11

SOFTWARE

SOFTWARE

13

SOFTWARE

SOFTWARE

15

SOFTWARE

SOFTWARE

17

SOFTWARE

Problemas

• As estimativas de custo e prazo são, frequentemente, imprecisas;

• Orçamentos excessivos;

• Prazos extrapolados;

• Vaga indicação de produtividade e falta de precisão da eficácia das ferramentas;

• Prazo político.

• A qualidade de software é inadequada;

• Erros causam insatisfação e desconfiança no cliente;

• Importância da realização de testes de software sistemáticos e completos;

• Software de difícil manutenção.

SOFTWARE

19

Causas dos problemas no desenvolvimento de software

• Gerenciamento de requisitos deficiente

• Comunicação ambígua e imprecisa

• Arquiteturas frágeis

• Alta complexidade

• Inconsistências não detectadas entre requisitos, modelos, projeto e implementações

• Testes insuficientes

• Acompanhamento subjetivo do status do projeto

• Propagação de mudanças de forma

SOFTWARE

ALGUMAS CAUSAS DA CRISE DO SOFTWARE

21

1. CARATERÍSTICAS PRÓPRIAS DO SOFTWARE

• O software é um elemento de sistema lógico.

• O software não se desgasta, mas se deteriora com o tempo.

2. FALHAS DAS PESSOAS RESPONSÁVEIS PELO DESENVOLVIMENTO DE SOFTWARE

• Gerentes sem nenhum background em software

• Profissionais da área de software têm pouco treinamento formal em novas técnicas para o desenvolvimento de software

• Resistência a mudanças

ALGUMAS CAUSAS DA CRISE DO SOFTWARE

3. QUALIFICAÇÃO DAS PESSSOAS QUE UTILIZAM O SOFTWARE

• Falta de treinamento adequado

• Falta da percepção de utilidade

• Usabilidade

23 Para o desenvolvimento de um software devem também ser

considerados:

• Plataforma de hardware

• Comunicação

• Documentação

• Base de dados

• Processos manuais e processos automatizados

TODOS ESSES ELEMENTOS, INCLUINDO O SOFTWARE, IMPACTAM NO DESEMPENHO DO SISTEMA

SOFTWARE

ALGUMAS CAUSAS DA CRISE DO SOFTWARE

FATORES QUE AGRAVAM O PROBLEMA (MITOS DO SOFTWARE)

ALGUMAS CAUSAS DA CRISE DO SOFTWARE

25

SOFTWARE

27

29

PROCESSO DE DESENVOLVIMENTO DE SOFTWARE

DEFINIÇÃO:

Conjunto de atividades relacionadas que levam a produção de um produto de software

(SOMMERVILLE, 2007)

O processo de software é visto por uma sequência de atividades que produzem uma variedade de

documentos, resultando em um programa

31

CONCEITOS GERAIS DE PROJETOS

ÁREAS PESQUISADAS

ÁREA QUE UTILIZA METODOLOGIA DE GP

33

TECNOLOGIA DA INFORMAÇÃO – 67,4%

ENGENHARIA – 34,3%

FREQUENCIA COM QUE ALCANÇAS OS RESULTADOS

NA MAORIA DAS VEZES- 59%

SEMPRE – 2%

POUCAS VEZES -35%

NUNCA – 3%

metas de prazo, custo,

qualidade e satisfação do cliente

PROJETOS

35

Projeto é um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo.

– Temporário: por possuir início e fim definidos.

– Exclusivo: por entregar resultados únicos e singulares.

– Elaboração progressiva: integra a definição de temporário e exclusivo, por se desenvolver em etapas e continuar por incrementos.

– Por sua natureza exclusiva normalmente agrega incertezas.

DEFINIÇÃO

GERENCIAMENTO DE PROJETOS

O gerenciamento de um projeto normalmente inclui, mas não se limita a:

• Identificação dos requisitos;

• Abordagem das diferentes necessidades, preocupações e expectativas das partes interessadas no planejamento e execução do projeto;

• Estabelecimento, manutenção e execução de comunicações ativas, eficazes e colaborativas entre as partes interessadas;

• Gerenciamento das partes interessadas visando o atendimento aos requisitos do projeto e a criação das suas entregas;

• Equilíbrio das restrições conflitantes do projeto que incluem, mas não se limitam, a:

• Escopo

• Qualidade

• Cronograma

VAMOS CONVERSAR?

37

QUAIS OS PASSOS PARA A CONSTRUÇÃO DE UMA CASA?

QUAIS OS PASSOS PARA UMA VIAGEM A LUA?

E PARA O DESENVOLVIMENTO DE UM

SOFTWARE?

CICLO DE VIDA DO PROJETO

DEFINIÇÃO:

Ciclo de vida do projeto é a série de fases pelas quais um projeto passa, do início ao término. As fases são geralmente sequenciais e os seus nomes e números são determinados pelas necessidades de gerenciamento e controle da(s) organização(ões) envolvida(s) no projeto, a natureza do projeto em si e sua área de aplicação.

CICLO DE VIDA GENÉRICO

• Início do projeto

• Organização e preparação

CICLO DE VIDA DO PROJETO

39

Relação dos riscos e custos de mudança ao longo do tempo do projeto

CICLO DE VIDA DO PROJETO

DEVER DE CASA

41

LEVANTAR O PROCESSO DE DESENVOLVIMENTO DE SOFTWARE DA EMPRESA EM QUE VOCÊ

TRABALHA E FAZER UM RESUMO

RESUMO

• Processo de desenvolvimento

• Conjunto de fases, cada qual com uma finalidade, que descrevem passo a

passo, formalmente, o que devem ser feito para desenvolver um sistema.

• Cria um padrão, para todos seguirem

• Melhora a comunicação entre as

partes interessadas

43

PROCESSOS DE SOFTWARE

ETAPAS DO PROCESSO DE SOFTWARE

• ESPECIFICAÇÃO – Define o software a ser desenvolvido e suas restrições

• PROJETO E IMPLEMENTAÇÃO – Onde o software é projetado e codificado

• VALIDAÇÃO – É verificado se atende as especificações e as executa corretamente

• EVOLUÇÃO – O software é modificado para refletir a mudança de requisitos do cliente e do mercado

ESPECIFICAÇÃO

45

REQUISITOS

O que são requisitos?

• Um requisito é uma característica do sistema ou a descrição de algo que o sistema é capaz de realizar, para atingir seus objetivos.

• São objetivos e/ou restrições, listados por clientes e usuários,

de definem as funções e características de um sistema.

REQUISITOS

47

CLASSIFICAÇÃO

• Requisito de usuário (abstratos- nível alto)

– Descrição dos serviços esperados do sistema e restrições sobre as quais ele deve operar

– “O sistema deve bloquear a venda para clientes negativados pelo SPC”.

– Descreve os requisitos funcionais e não-funcionais para entendimento de pessoa não-técnico;

– Se possível especificar apenas o comportamento externo do sistema;

– Não usar palavras técnicas, notações formais.

REQUISITOS

CLASSIFICAÇÃO

• Requisito de Sistema (detalhado)

– Definição estruturada e detalhada dos serviços e restrições operacionais;

– “Ao digitar o CPF do cliente o sistema deve acessar o site da Receita Federal e verificar qual o status do cliente”;

– Os requisitos do usuário podem demandar requisitos de sistema:

– Tamanho do sistema pode influenciar na tecnologia;

– O sistema pode precisar interagir com sistemas já

49

CLASSIFICAÇÃO Funcionais

• Declarações de serviços que o sistema deve fornecer e como deve se comportar.

• Pode estabelecer o que o sistema NÃO deve fazer

• Descrevem explicitamente as funcionalidades e serviços do sistema

• Documenta como o sistema deve reagir a entradas específicas como deve se comportar.

REQUISITOS

REQUISITOS

Exemplos de requisitos funcionais

• O usuário pode pesquisar todos os dados financeiros dos clientes;

• O sistema deve oferecer telas apropriadas para o usuário ler documentos armazenados ;

• Cada pedido deve ser associado a um identificador único número e tem data de validade;

• Sistema deve relacionar os alunos aprovados;

• Sistema deve permitir incluir e excluir fornecedores.

51

CLASSIFICAÇÃO

Não Funcionais

• Definem propriedades e restrições do sistema Exemplos: segurança, desempenho, espaço em disco.

• Podem ser do sistema todo ou de partes do sistema

• Requisitos não-funcionais podem ser mais críticos que requisitos funcionais.

– Se não satisfaz, o sistema é inútil

REQUISITOS

EXEMPLOS DE REQUISITOS NÃO FUNCIONAIS

• A impressão do boleto deve ser em no máximo 10 segundos;

• as dimensões dos relatórios devem ser configuráveis;

• A interface do usuário deve ser implementada como simples HTML;

• Todos os documentos entregues devem seguir o padrão de relatórios XYZ-00;

• Informações pessoais do usuário não podem ser vistas

REQUISITOS

53

REQUISITOS

OUTRAS CONSIDERAÇÕES SOBRE OS REQUISITOS

• Requisitos explícito

• Descritos em um documento oficial

• Requisitos normativos

• Decorrentes de leis, regulamentos, padrões ou outras normas

• Requisitos implícitos

• Expectativas dos clientes e usuários, que são esperadas mas não documentadas

• Requisitos devem ter:

• Completude - Todas os serviços devem estar definidos

• Consistência - Os requisitos não devem ter definições contraditórias

REQUISITOS

55

(SOMMERVILLE, 2007)

ATIVIDADES DO PROCESSO DE REQUISITO

ATIVIDADES DO PROCESSO DE REQUISITO

1. Estudo de viabilidade

• Viabilidade técnica e econômica;

• Saída: Relatório de viabilidade.

2. Elicitação e análise dos requisitos

• Levantar os requisitos: entender o problema, identificar os requisitos.

• Saída: modelo do sistema 3. Especificação de requisitos

• É a atividade de escrever o que foi identificado na etapa anterior

• Saída: requisitos do usuário e do sistema 4. Validação de requisitos

ESTUDO DE VIABILIDADE

57

Concepção

Semente Necessidade, ideia

O que é o sistema? – definições iniciais É viável? Vale a pena?

• Estudo ou Análise de Viabilidade Benefício deve superar o Custo?

Empresa

Negócio a que se destina

ESTUDO DE VIABILIDADE

ANÁLISE DE

VIABILIDADE Entrada:

1. Conjunto preliminar de requisitos de negócio 2. Esboço da Descrição do Software

3. Como apóia a área de negócios

ESTUDO DE VIABILIDADE

59

• O SW contribui para os objetivos da organização?

Beneficia os interessados?

– Viabilidade Operacional

• O SW pode ser implementado com TI atual?

– Viabilidade Técnica (serviços disponíveis – telecom)

• Restrições de custo serão atendidas?

– Viabilidade econômica

• Restrições de prazo serão atendidas?

– Cronograma

ELICITAÇÃO DE REQUISITOS

OBJETIVO DA FASE DE LEVANTAMENTO

• Investigação do ambiente

• Entender o domínio do problema (escopo);

• Entender o funcionamento do “sistema” atual;

• Fornecem entendimento acerca do que o usuário quer;

• Identificação do problema

• Definir com clareza o que precisa ser construído;

• Definir com clareza o que NÃO precisa ser construído;

• Identificação de soluções alternativas (é preciso? Isso já não

existe? Não pode ser feito de outra maneira?)

61

ELICITAÇÃO DE REQUISITOS

ELICITAÇÃO DE REQUISITOS

63

ELICITAÇÃO DE REQUISITOS

ELICITAÇÃO DE REQUISITOS

Dificuldades neste processo:

• Os stackholders costumam não saber o que querem. Desconhecimento da tecnologia, do negócio. Maturidade do uso é importante.

• Conflito entre os níveis de conhecimento entre analista e stakeholders.

Problemas do conhecimento implícito. Importante é ouvir.

• Fatores políticos podem aumentar ou suprimir demandas. Ouvir outros stakeholders é fundamental.

65

ELICITAÇÃO DE REQUISITOS

COMO IDENTIFICAR OS REQUISITOS?

1. ENTREVISTAS

2. QUESTIONÁRIOS

3. CONSTRUÇÃO DE CENÁRIOS 4. ETNOGRAFIA

5. CASOS DE USO

• Instrumento mais comum

• Fechadas (questionário) ou abertas (um roteiro é muito importante)

• Podem ser Individual ou pequeno grupo

• Permite observar postura corporal. “Olhar nos olhos”.

• Ajudar a identificar requisitos/processos ocultos (vantagem para o analista interno a organização)

• É cara, pois toma tempo das pessoas Dicas:

• Esteja aberto a novas idéias. Quem entende do negócio é o usuário.

ENTREVISTAS

Quando usar?

– Muitos usuários e há necessidade de uma análise estatística.

– Falta de tempo dos envolvidos para entrevistas.

– Usuários estão geograficamente distantes (pesquisa de satisfação na Estácio)

Evitar: perguntas abertas.

– O que você do procedimento atual... ?

Focar: perguntas direcionadas ao que se deseja saber. Exp:

Considera o procedimento atual

– ( ) Ruim ( ) Satisfatório ( ) Ótimo

QUESTIONÁRIO

67

Reuniões onde participam todos os envolvidos

Objetivo: permitir que todos expressem suas ideias de forma a obter o consenso.

• Todos expressão de forma desorganizada Organizam- se as idéias

• Identifica-se conflitos entre áreas

• Visões diferentes do requisito nas empresas.

BRAINSTORM

CENÁRIOS

69

• Técnica complementar da entrevista

• Cria-se a partir das entrevistas cenários baseados no mundo real.

• Um cenário pode ser descrito em texto, diagramas, telas, etc.

CENÁRIOS - EXEMPLO

ETNOGRAFIA

71

• Técnica baseada na observação (na prática?)

• Propõe uma imersão nas atividades diárias para entender as relações reais

• Ajuda a identificar principalmente de dois tipos de requisitos:

• Derivados da forma como as pessoas trabalham

• Derivados da cooperação e conhecimento das atividades das outras pessoas (retrabalhos, informações sem necessidade)

É na verdade um modelo da UML, usado para: definir o escopo do sistema, identificar quem interage com o sistema (atores) identificar os requisitos (casos de uso), validar os requisitos com os usuários.

Não é em si uma técnica de levantamento de dados, mas o resultado produzido após.

E esse resultado, que é o modelo (desenho) pode ser usado para validar os requisitos com os usuários.

CASO DE USO (CUIDADO)

73

VALIDAÇÃO DOS REQUISITOS

• É o processo que verifica se o sistema faz o que o cliente solicitou

• Foco na identificação das falhas dos requisitos

• Inclue:

1. Verificação da validade

2. Verificação da consistência 3. Verificação de completude 4. Verificação de realismo

75

VALIDAÇÃO DOS REQUISITOS

DEVER DE CLASSE

PARA DESENVOLVER BEM ESTA ATIVIDADE VOCÊ DEVERÁ TER LIDO O TEXTO ENTREGUE NA ÚLTIMA AULA

TRABALHO FEITO EM DUPLAS

PRIMEIRA PARTE – 50 minutos

• IDENTIFICAR PELO MENOS 15 REQUISITOS FUNCIONAIS OU NÃO FUNCIONAIS

• DESCREVER DE FORMA CLARA CADA UM DOS REQUISITOS:

• EVITE AMBIGUIDADE;

• USE EXPRESSÕES QUE AJUDEM A IDENTIFICAR REQUISITOS OBRIGATÓRIOS E OS DESEJÁVEIS:

• DEVE, PODE, É NECESSÁRIO, É DESEJÁVEL, ETC.

• NÃO USE JARGÕES TÉCNICOS. O PÚBLICO É DE PROFISSIONAIS NÃO TÉCNICOS.

• SEMPRE QUE POSSÍVEL ACRESCENTE UMA JUSTIFICATIVA A CADA REQUISITO.

SEGUNDA PARTE – 20 minutos

• ENTREGUE O QUE ESCREVEU PARA OUTRA DUPLA

• ELA DEVERÁ SELECIONAR 8 REQUISITOS E EXPLICAR O QUE ELA ENTENDEU. ESCUTE!! E