Aula 00 - Introdução a Engenharia de Software.pdf

MSc, Adler Diniz de Souza, PMP

Processo de desenvolvimento e Ciclo de vida de software

Introdução

Processo de software

Métodos, Ferramentas e Procedimentos

Benefícios com a adoção de processos de software

Modelos de ciclo de vida

Cascata

Prototipagem

Programação exploratória

Descartável

Transformação formal

Modelos Evolutivos

Modelo Incremental

Modelo Espiral

2

Acúmulo

de trabalho

Abandono de

planos e

procedimentos

Sucesso depende muito do

esforço heróico das pessoasPouca

repetibilidade

Produto funciona, mas

com defeitos; prazo e

custo maiores; e menos

funcionalidade

Clientes e

funcionários

insatisfeitos

adaptado do ESI, 1998

Situação atual da maioria das empresas

Demanda por Melhor Qualidade!melhor qualidade inclui:

menor prazos, custos, defeitos, insatisfações,

mais qualidade dos produtos, previsibilidade,

produtividade, competitividade,

e melhores resultados de negócio (ROI)

3

O que é um processo?

Solicitações para

construção de

produto ou

realização de

serviços de software

Produto ou serviço

de software

realizado e entregue

ao cliente

Empresa

Processos

AD

B CE

4

É o que as pessoas fazem,utilizando procedimentos, métodos e ferramentas,

para adquirir, desenvolver, manter e melhorarsoftware e produtos associados

Objetivos

Recursos e Infraestrutura

Entradas Saídasatividades

Processo:

Processo de Software

Uma notação de processo comumente

representa:

Quais atividades são executadas no processo e suas

interdependências?

Quem realiza as atividades?

Por que as atividades são feitas?

Quando as atividades são feitas?

Como as atividades são feitas?

Quais as entradas que as atividades devem ter?

Quais saídas elas produzem?

Como é possível medir o desempenho?

Critérios de entrada e saída

Informações narrativas

É desejável que uma notação de processo

seja:

Flexível

Simples

Fácil de entender e treinar

Possuir ferramentais para suporte

5

6

O Processo de Software

MÉTODOS:

Abordagens estruturadas para desenvolvimento de software que incluem modelos de sistema, notações, regras, recomendações de projeto e orientações de uso

Os métodos mostram os detalhes de como

construir o software

7


FERRAMENTAS: dão suporte

automatizado aos métodos.

Existem atualmente ferramentas para sustentar cada um dos métodos

Quando as ferramentas são integradas, é estabelecido um sistema de suporte ao desenvolvimento de software chamado CASE -Computer Aided Software Engineering

8


PROCEDIMENTOS: constituem o elo de

ligação entre os métodos e ferramentas

Seqüência em que os métodos serão aplicados

Produtos que se exige que sejam entregues

Controles que ajudam assegurar a qualidade e coordenar as alterações

Marcos de referência que possibilitam administrar o progresso do software.

Visão Macro do Processo

Cada caixa representa uma FASE do Ciclo de vida do projeto

9

Processo de uma Fábrica de SoftwareIdentificação dos papéis relacionados as atividades

Identificação das atividades, dos artefatos de entrada e saídaDescrição da atividade

10

Desvantagens da adoção de Processos...Existem ??

Problemas com Adoção de ProcessosBurocraciaResistência

Aumento da carga de trabalhoA empresa tem que sobreviver..

Resultados imediatos(resultados – confiança – comprometimento)

...

11

Maior

previsibilidade

dos resultados

Melhor ambiente de

trabalho e satisfação

das pessoas

Melhor habilidade para

gerenciar complexidade

Maior visibilidade da

execução dos

projetos

Maior

produtividade

Melhor qualidade

do produto

adaptado do ESI, 1998

Benefícios com a adoção de processos

12

Introdução





Cascata

Prototipagem


Descartável


Modelos Evolutivos

Modelo Incremental

Modelo Espiral

13

14

Modelos de Ciclo de Vida

Existem vários modelos de processo de software(ou paradigmas de engenharia de software)

Cada um representa uma tentativa de colocar ordem no processo de desenvolvimento de software

Pode-se citar os seguintes modelos de processo de software

15

Modelos de Ciclo de Vida


Cascata

Prototipagem


Descartável


Modelos Evolutivos

Modelo Incremental

Modelo Espiral

O Modelo Cascata

16

Derivado de modelos existentes de outras engenharias (1970)

Sua estrutura é composta de várias fases que são executadas de forma sistemática e seqüencial

Análise e definição de requisitos

Projeto de sistema e software

Implementação e teste de unidade

Integração e teste de sistema

Operação e manutenção

Na prática, existe uma interação entre as fases e cada fase pode levar a modificações nas fases anteriores

Modelo Cascata

1717

Modelo Cascata

Implementação

Manutenção

Teste

Projeto

Análise

18

Modelo Cascata

Implementação

Manutenção

Teste

Projeto

Análise

19

Análise de Requisitos de Software

O principal objetivo desta fase é identificar,

coletar e detalhar os requisitos de software

Principais atividades:

Identificação e aprovação do fornecedor de requisitos;

Identificação e detalhamento dos requisitos do cliente,

requisitos funcionais e não funcionais;

Manter comunicação contínua com o cliente;

Validação interna e externa (com o cliente) dos

requisitos

Saídas:

Documento de requisitos ou Documento de Visão ou

Documentos de Caso de Uso;

Requisitos de Software

[2]

[Courage & Baxter]

Requisito de Software: Definição

Um requisito descreve uma condição oucapacidade que o sistema deve estar emconformidade [Unified Process]

Pode ser derivado das necessidades dos usuários,ou estabelecido em um contrato, padrão,especificação ou outro documento impostoformalmente [IEEE]

Pode estar explícito ou implícito

O que o software deve fazer??O que o cliente deseja??Quais as restrições??Quais os componentes??Quem vai utilizar o software??

Descrição e especificação de um software ou sistema


Funcionais e não-funcionaisRequisitos e não-requisitosEssencial, importante, desejável, ...Usuário, sistema, dadoSistema, software,...Interno, externoComplexo, simples, ...Volátil, estável, ..Alocado .....Produto, processo .....

Requisitos de Software: Classificação

Descrevem a funcionalidade do produto ou serviço do software/sistema

Requisitos funcionaisRequisitos Funcionais

Requisitos funcionais do usuário podem ser sentenças de alto nível sobre o que o sistema deve fazer

Propostas Técnicas e Comerciais, Manuais de procedimentos, etc.

Requisitos funcionais do sistema devem descrever os serviços do sistema em detalhes

Documento de requisitos refinado, arquitetura do software, etc.

Requisitos Funcionais

Restringem os requisitos funcionais

Requisitos de produto

Requisitos organizacionais

Requisitos externos

Requisitos Não-funcionais

Requisitos de Produto

Requisitos que especificam que o produto entregue tem que se comportar de um modo particular

Ex: Velocidade de execução, confiabilidade, usabilidade, etc.

Requisitos Organizacionais

Requisitos que são uma consequência de políticas e procedimentos organizacionais.

Ex: Padrões de processos usados, requisitos de implementação etc.

Requisitos Externos

Requisitos que surgem de fatores que são externos ao sistema e ao processo de desenvolvimento.

Ex:Requisitos legislativos, exigência de interoperabilidade etc.

Somerville 2003

Requisitos Não-Funcionais: Classificação

Requisitos não

funcionais

Requisitos do

produto

Requisitos

organizacionais

Requisitos

organizacionais

Requisitos de

eficiênciaRequisitos de

confiança

Requisitos de

portabilidade

Requisitos

éticosRequisitos

Legislativos

Requisitos de

interoperabilida

de

Requisitos de

usabilidade

Requisitos de

desempenhoRequisitos de

espaçoRequisitos de

privacidade

Requisitos de

segurança

Requisitos de

entregaRequisitos de

implementação

Requisitos de

padrões

O QUE

FuncionalidadeRestrições

Confiabilidade

Usabilidade

Eficiência

Manutenibilidade

Portabilidade

ISO/IEC 9126 / NBR 1359


FUNCIONALIDADE - Satisfaz as necessidades?

SUBCARACTERÍSTICA PERGUNTA CHAVE

• Adequação Propõe-se a fazer o que é apropriado?

• Acurácia Faz o que foi proposto de forma correta?

• Interoperabilidade É capaz de interagir com os sistemas

especificados?

• Conformidade Está de acordo com as normas, leis, etc.?

• Segurança de Acesso Evita acesso não autorizado a programas

e dados?

ISO/IEC 9126 / NBR 1359


CONFIABILIDADE - É imune a falhas?

SUBCARACTERÍSTICA PERGUNTA CHAVE

• Maturidade Com que freqüência apresenta falhas por

defeitos no software?

• Tolerância a Falhas Ocorrendo falhas, como ele reage?

• Recuperação É capaz de recuperar dados em caso de falhas?

ISO/IEC 9126 / NBR 1359


Software para Controle de Estoque

Funcionalidade

Confiabilidade

Usabilidade

Eficiência

Manutenibilidade

Portabilidade

Características Selecionadas

Software Embutido em Satélite



Atributos de um requisito:Capacidade de verificação – Pode ser verificado se o software atende aquele requisito ou não;

Prioridade – Utilizado para negociação no caso de recursos limitados;

Identificador único – Possibilita a sua inclusão no controle da gerência de configuração e gerenciado através do ciclo de vida do software;

Exercício: (Identificar os requisitos do sistema desta clínica médica através de uma breve descrição do cliente)

Eu possuo uma clínica médica e atendo meus pacientes a mais de 15 anos..Poxa, eu tenho atendido tanta gente que atualmente tenho esta sala aquisomente para guardar as fichas de meus pacientes..

As coisas que quero controlar me parecem bastante simples.. Não querodiminuir o trabalho de minha secretária quanto ao agendamento dasconsultas, ela deve apenas cadastrar os novos pacientes.... Quero com estesistema poder controlar as consultas de tal forma que o paciente entre nomeu consultório e eu já possa ter lido todo o seu histórico.. Isto é, outrasvezes que ele esteve na clínica, qual a doença que ele tinha, os sintomas, osmedicamentos que foram ministrados, etc.. Aliás não me interessa omedicamento, eu quero saber é o seu princípio ativo.. É que existem hojetantas opções de remédios ...

Ah, as crianças!!... eu tenho atendido muitas delas.!!. quero tratá-las comoum paciente normal, mas preciso saber quem é o responsável por ela etambém quero acompanhar sua taxa de crescimento e peso....

Acho que fazer isso tudo funcionar melhor vai ser bastante simples.. Antesque eu me esqueça, também preciso manter os endereços de meuspacientes, para poder enviar um cartão de natal, ou um "feliz aniversário" ...

Declaração deve ser precisa

Requisitos ambíguos podem ser interpretados de forma diferente por pessoas diferentes (exemplo: desenvolvedores e clientes)

EXEMPLO: O software deve ter visualizadores apropriados para leitura dos documentos

Considere o termo ‘visualizadores apropriados’

Intenção do usuário - visualizadores de propósito especial para cada tipo de documento diferente

Interpretação do desenvolvedor - um visualizador textual que mostra o conteúdo do documento

Problemas: Imprecisão dos Requisitos

Problemas: Imprecisão dos Requisitos

Modelo Cascata

Implementação

Manutenção

Teste

Projeto

Análise

37

Projeto

Nesta fase faz-se a tradução dos requisitos do

software para um conjunto de representações

gráficas que podem ser avaliadas quanto à

qualidade, antes que a codificação se inicie

Se concentra em 4 atributos do programa:– Estrutura de Dados,

– Arquitetura de Software,

– Detalhes Procedimentais e

– Caracterização de Interfaces

Exemplos de Diagramas...

Diagrama de Caso de Uso

39

ud Use Case Model

Vendedor

Manter produtos

Manter Clientes

Manter Produtos

Genéricos

Efefuar venda

Efetuar pagamento

cartão de dédito

Efetuar pagamento

Cartão de Crédito

Efetuar pagamento

Cheque

Manter Produtos

Controlados

«extend»

«extend»

«extend»

«include»

«include»

Diagrama de Classe

40

Modelo Cascata

Implementação

Manutenção

Teste

Projeto

Análise

41

Implementação

Esta fase faz a tradução das representações

gráficas do projeto para uma linguagem

“artificial” resultando em instruções executáveis

pelo computador

É normalmente a fase onde concentra-se o maior

percentual de trabalho

Saídas:

Código fonte, Scripts de banco de dados, documentos de

testes, manuais

Modelo Cascata

Implementação

Manutenção

Teste

Projeto

Análise

43

Testes

Essa fase concentra-se:

nos aspectos lógicos internos do software,

garantindo que todas as instruções tenham sido

testadas

nos aspectos funcionais externos, para descobrir

erros e garantir que a entrada definida produza

resultados que concordem com os esperados.

Modelo Cascata

Implementação

Manutenção

Teste

Projeto

Análise

45

Manutenção

Provavelmente o software deverá sofrer mudanças

depois que for entregue ao cliente

Causas das mudanças:

erros, adaptação do software para acomodar mudanças

em seu ambiente externo e exigência do cliente para

acréscimos funcionais e de desempenho

Todo bom software evoluí!!

VantagensOferece uma maneira de tornar o processo mais visível, fixando pontos específicos para a escrita de relatórios.

Problemas Boa parte do sistema não estará disponível até um ponto adiantado no cronograma do projeto:

é geralmente difícil convencer o usuário de que é preciso paciência

Dificuldade de acomodação das mudanças depois que o projeto está em andamento

Portanto, esse modelo é apenas apropriado quando os requisitos são bem entendidos

Modelo Cascata

47

O Modelo de Desenvolvimento Prototipagem

48

Introdução





Cascata

Prototipagem


Descartável


Modelos Evolutivos

Modelo Incremental

Modelo Espiral

49

Desenvolvimento da primeira versão do sistema o mais rápido possível;

O escopo não é claramente definido: a especificação é feita de forma intercalada ao desenvolvimento;

Após o desenvolvimento de cada uma das versões do sistema ele é mostrado aos usuários para comentários;

Modificações sucessivas até que o sistema seja considerado adequado;

Principal diferença dos outros modelos é a ausência da noção de programa correto;

Usado com sucesso para o desenvolvimento de sistemas de IA.


50

Objetivo é entender os requisitos do sistema. Ele deve iniciar com os requisitos vagamente entendidos;

Como na programação exploratória, a primeira fase prevê o desenvolvimento de um programa (protótipo) para o usuário experimentar;

O protótipo então é descartado e o software deve ser reimplementado na fase seguinte usando algum outro modelo de ciclo de vida (ex: cascata);

Usado com sucesso para prototipagem de partes do sistema (ex: Interface Gráfica e Aspectos de arquitetura).

Prototipagem descartável

51

Prototipagem descartável

Vantagens:

Pode ser utilizada para identificação dos requisitosdos projetos

Desvantagens:

Expectativas do cliente com relação a prazo e custo;

Possibilidade de reutilização do protótipo

Falta de qualidade, falta de padronização

O Modelo de Transformação Formal

53

Utilizado para desenvolvimento de sistemas críticos;

Utiliza uma especificação formal (definição matemática, não ambígua) do software, que é desenvolvida e posteriormente transformadaem um programa através de regras que preservam a corretude da especificação;


54

Requirementsdefinition

Formalspecification

Formaltransformation

Integration andsystem testing


55

Problemas

Necessidade de habilidades especializadas e treinamento para aplicar as técnicas de transformação

Dificuldade para especificar formalmente alguns aspectos do sistema tais como a interface com o usuário

Aplicabilidade

Sistemas críticos, especialmente aqueles onde a segurança é um fator crítico


56

Modelos Iterativos

57

Requisitos de sistema SEMPRE evoluem durante o curso de um projeto. Assim a iteração do processo sempre faz parte do desenvolvimento de grandes sistemas

Iterações podem ser aplicadas a quaisquer dos modelos de de ciclo de vida

Duas abordagens (relacionadas)

Desenvolvimento espiral

Desenvolvimento incremental

Modelos Iterativos

58

O processo é representado como uma espiral em vez de uma seqüência de atividades

Cada volta na espiral representa uma fase no processo

Não há fases fixas como especificação ou projetovoltas na espiral são escolhidas dependendo do que é requerido

Acrescenta aspectos gerenciais ao processo de desenvolvimento de software.

análise de riscos em intervalos regulares do processo de desenvolvimento de software;

planejamento;

controle;

tomada de decisão.

Desenvolvimento Espiral

59

Definição dos objetivos, alternativas e restrições

Objetivos específicos para a fase são identificados, alternativas para realizar os objetivos e restrições são encontradas.

Avaliação e redução de risco

Os riscos principais são identificados, analisados e buscam-se meios para reduzir estes riscos

Desenvolvimento e validação

Um modelo apropriado para o desenvolvimento é escolhido, o qual pode ser qualquer um dos modelos de ciclo de vida

Planejamento

O projeto é revisto e a próxima fase da espiral é planejada


60

Riskanalysis

Riskanalysis

Riskanalysis

Riskanalysis Proto-

type 1

Prototype 2

Prototype 3Opera-tionalprotoype

Concept ofOperation

Simulations, models, benchmarks

S/Wrequirements

Requirementvalidation

DesignV&V

Productdesign Detailed

design

Code

Unit test

IntegrationtestAcceptance

testService Develop, verifynext-level product

Evaluate alternativesidentify, resolve risks

Determine objectivesalternatives and

constraints

Plan next phase

Integrationand test plan

Developmentplan

Requirements planLife-cycle plan

REVIEW


61

Em vez de entregar o sistema como um todo, o desenvolvimento e a entrega são divididos em incrementos. Com cada incremento entregando parte da funcionalidade requerida.

Requisitos dos usuários são priorizados e os requisitos de mais alta prioridade são incluídos nas iterações iniciais

Uma vez que o desenvolvimento de um incremento é iniciado, os requisitos são "congelados". Embora outros requisitos possam continuar a evoluir para incrementos posteriores


62

Desenvolvimento Incremental

63

Valida te

increment

Develop systemincrement

Design systemarchitecture

Integrateincrement

Valida te

system

Define outline requirements

Assign requirements to increments

System incomplete

Finalsystem


64

R1 R2 R3 R5

R6 R7 R8 R9

R10 R11 R12

Escopo

R2 R3 R5 R6

Release 1

R1 R7

Release 2

R10 R11 R12

Release 3

R8 R9

Release 4 (Final)

Software 1.0 Software 2.0 Software 3.0

Software 4.0Alterações

AlteraçõesAlterações

Exemplo

Modelo Iterativo e Incremental

65

A funcionalidade do sistema está disponível mais cedo, pois ela é entregue a partir dos incrementos

Incrementos iniciais agem com um protótipo para ajudar a elicitar requisitos para incrementos finais

Diminui o risco de falha do projeto como um todo

Os serviços do sistema de prioridade mais alta tendem a receber mais testes


66

67

Conclusão

Para escolha de um Modelo de Ciclo de

Software adequado, deve-se levar em

consideração:

natureza do projeto e da aplicação

métodos e ferramentas a serem usados

controles e produtos que precisam ser entregues

MSc, Adler Diniz de Souza, PMP

Processo de desenvolvimento e Ciclo de vida de software

68

Exercícios 1 de 2

Escolha qual modelo de ciclo vida você optaria para o desenvolvimento dos seguintes projetos/soluções/situações:

1. Um software para um cliente que não sabe definir qual o escopo do projeto dele.

2. Um software de gestão empresarial para uma grande rede de empresas varejistas;

3. Um software de controle de tráfego aéreo;

4. Um software de reconhecimento de íris para acesso a locais restritos;

5. Um software de otimização de rotas para uma empresa transportadora, utilizando Algoritmo Genético;

69

Exercício 2 de 2

Destaque as vantagens e desvantagens de cada modelo de ciclo de vida:

1. Modelo Cascata;

2. Modelo Prototipagem Descartável;

3. Modelo Programação Exploratória;

4. Modelo Iterativo e Incremental

5. Modelo Espiral;

70

Fim da aula

Documents

Aula 00 - Introdução a Engenharia de Software.pdf