análise e projeto de sistemas setembrino soares ferreira jr. 01 - introdução

06/05/201006/05/2010 01 - Introdução01 - Introdução 11

Universidade Federal do ParanáUniversidade Federal do Paraná Setor de Ciências Exatas Setor de Ciências Exatas

Departamento de InformáticaDepartamento de Informática

ESPECIALIZAÇÃO EM INFORMÁTICAESPECIALIZAÇÃO EM INFORMÁTICA

Análise e Projeto de Análise e Projeto de SistemasSistemas

Setembrino Soares Ferreira Jr.Setembrino Soares Ferreira Jr.

01 - Introdução01 - Introdução


Conteúdos1. Considerações iniciais2. Conceitos básicos3. Engenharia de software3.1. Princípios3.2. Paradigmas3.3. Interação da engenharia de software com outras áreas4. Considerações finais5. Exercícios Bibliografia


1. Considerações iniciais

Sistemas (“sistemas de software”) Papel cada vez mais importante Funcionamento correto ou incorreto = vida ou morte

Espaçonaves, aeronaves, trens, carros, reatores nucleares, equipamentos hospitalares, contas bancárias (segurança de acesso, movimentação correta), ...

Aplicações TÊM DE SER totalmente confiáveis!

Cumprir requisitos integralmente Requisitos intransigentes Restrições de integridade Vasto conhecimento sobre a aplicação

Interações software x ambiente adequadas


1. Considerações iniciais (cont.)

Construir (bons) produtos de software envolve:

Compreender a complexidade dos produtos (cresc.) Gerenciar equipes multidisciplinares Obter informações precisas sobre os produtos a serem desenvolvidos Comunicação adequada Sincronizar e controlar atividades

Paralelas Diversos profissionais Diversas equipes


1. Considerações iniciais (cont.)

Atividades essenciais (do início do desenvolvimento):

Extração de requisitos (características do produto a ser desenvolvido)

Complexa Baseada na comunicação entre equipes

Representação adequada de requisitos Abstrações representativas das diferentes propriedades do sistema Notações formais / semiformais

Planejamento e acompanhamento de atividades do projeto

Controle do processo de desenvolvimento


2. Conceitos básicos Sistema

- do latim systema, reunião, grupo;

“Conjunto de princípios reunidos de modo a formar um corpo de doutrina”;

“Conjunto de partes coordenadas que concorrem para o atingimento de um resultado (conjunto de objetivos) ou para formar um conjunto”;

“Conjunto de elementos, concretos ou abstratos, entre os quais se pode encontrar alguma relação”;

“Conjunto, identificável e coerente, de elementos que interagem coesivamente, onde cada elemento pode ser um sistema”;

(...)


2. Conceitos básicos (cont.)

Existe uma relação estrutural entre as partes componentes de um sistema

Sistema x universo: fronteira conceitual Elementos internos

Entidade relativamente autônoma e identificável Fortes interações entre si

Elementos externos Fracas interações com elementos internos: devem ser fracas o suficiente para que possamos desprezá-las



Exemplo 1:Ecossistema de certa espécie de inseto

que passa toda a sua vida em uma única árvore de determinada espécie.

Fronteira conceitual Inseto (fisiologia, anatomia, hábitos reprodutivos, ciclo de vida, etc.) Árvore Fauna que habita a árvore Caracterização do habitat da árvore (clima, solo, vegetação na vizinhança, etc.)



Exemplo 2:Ecossistema floresta amazônica.

Fronteira conceitual ?



Exemplo 2:Ecossistema floresta amazônica.

Fronteira conceitual ? Flora Fauna Ocupação humana na floresta e em volta dela Utilização humana da floresta Aspectos climáticos, atmosféricos, etc. Etc.



Em sistemas de software, determinar a fronteira conceitual adequada

É um passo decisivo no processo de concepção do sistema Permite separar componentes pertencentes

Ao sistema Informações devem ser estudadas em detalhes

Ao ambiente externo Interesse: interações com o sistema



Exemplo 3:Sistema de reservas de passagens

aéreas de uma determinada companhia. Fronteira conceitual ?



Exemplo 3:Sistema de reservas de passagens

aéreas de uma determinada companhia. Fronteira conceitual ?

Companhia Dados sobre vôos: disponibilidades, reservas, cancelamentos, etc.)

Se o sistema de software incluir reservas de hotéis, locação de carros, ofertas de pacotes turísticos, etc., a fronteira conceitual terá de ser ampliada para contemplar informações sobre ?

Hotéis, locadoras de carros, agências de turismo, etc.



Produtos de software Sistemas de software entregues ao usuário com a documentação que descreve como instalá-lo e usá-lo

Categorias de produtos de software Sistemas genéricos: produzidos e vendidos no mercado Sistemas específicos: produzidos sob encomenda especialmente para um determinado cliente

Composição dos produtos de software Instruções (programas de computador) Estruturas de dados (manipuladas pelas instruções) Documentos (descrevem operações e uso do produto)



Processo de desenvolvimento de software

Conjunto de atividades e resultados associados, com o objetivo de construir um produto de software Desenvolvimento

Especificação de funcionalidades e restrições relativas à operacionalidade do software Produção do software conforme as especificações

Validação Avaliação da aderência do software às necessidades do usuário

Manutenção Correções, adaptações e ampliações para corrigir erros pós-entrega Atender novos requisitos / mudanças na tecnologia



No processo de desenvolvimento de software, modelos de processos (paradigmas) especificam:

Quais atividades devem ser executadas Qual a ordem de execução das atividades

Produtos de software podem ser construídos utilizando-se diferentes modelos de processos

Alguns modelos são mais adequados que outros = f(tipo da aplicação) A escolha de um determinado modelo deve ser feita = f(produto a desenvolver)


3. Engenharia de software Décadas de 60 e 70, desafio era desenvolver hardware que reduzisse custos de:

Processamento Armazenagem de dados

Década de 80, f(avanços na microeletrônica):

Aumento do poder computacional Custo cada vez menor

Processo de desenvolvimento e software: Cronogramas não eram cumpridos Custos excediam previsões Requisitos não eram cumpridos Etc.


3. Engenharia de software (cont.)

Desafio atual (há ± 3 décadas): Melhorar a qualidade Reduzir o custo do software Introduzir disciplina no desenvolvimento

Engenharia de software Uma disciplina que reúne metodologias, métodos e ferramentas a serem utilizadas, desde a percepção do problema até o momento em que o sistema desenvolvido deixa de ser operacional, visando resolver problemas inerentes ao processo de desenvolvimento e ao produto de software.



Objetivos da engenharia de software Auxiliar no processo de produção de software Processo para gerar produtos de alta qualidade Mais rapidamente Custo cada vez menor

Problemas a tratar, f(atributos do processo e do produto de software)

Complexidade, visibilidade, aceitabilidade, confiabilidade, alterabilidade, segurança, etc. Controle de tráfego aéreo / ferroviário: confiabilidade Controladores embutidos em eletrodomésticos (lavadoras de roupas / videocassetes): desempenho



Engenharia de software Herda da engenharia o conceito de disciplina na produção de software Adota metodologias, com métodos que utilizam ferramentas automatizadas Métodos focalizam:

Funções do sistema Objetos do sistema Eventos do funcionamento do sistema


3.1. E. S. - Princípios Referem-se:

Ao processo Ao produto final Descrevem propriedades gerais dos processos e produtos Processo correto => produto correto Produto almejado => escolha do processo

(~ estratégia <=> estrutura organizacional) Princípios são insuficientes. Há a necessidade de:

Metodologias Métodos Ferramentas


3.1. E. S. - Princípios (cont.)

Formalidade Abstração Decomposição Generalização Flexibilização



Formalidade Desenvolvimento de software = atividade criativa Tende a ser imprecisa (não estruturada) Enfoque formal: produtos mais confiáveis, com custo controlado e melhor desempenho Não deve restringir a criatividade Projeto como seqüência de passos precisos Passos segundo metodologia e algum método formal, informal ou semiformal Adequar formalidade à necessidade (ex.: barco p/ rio x oceano) Efeitos: manutenção, reutilização, portabilidade e entendimento do software



Abstração Processo de identificação de aspectos importantes de um determinado fenômeno, ignorando-se os detalhes Podem existir diferentes abstrações, f(visões e objetivos diferentes) Ex.: telefone sem fio

P/ o usuário: manual c/ efeitos do acionamento dos diversos botões P/ o técnico de manutenção: manual c/ informações de componentes

Ex.: programas Abstrações das funcionalidades do sistema

Ex.: linguagens de programação Foco do programador no problema, não na máquina



Decomposição Para lidar com a complexidade:

Subdividir atividades do processo Atribuí-las a especialistas de diferentes áreas Várias formas (ex.: tempo) Ex.: controle de qualidade do processo, controle de qualidade do produto, especificação do projeto, implementação e manutenção

Decomposição = separação de preocupações Pode-se decompor o produto

Permite o trabalho em paralelo Permite a reutilização de componentes por outros componentes ou sistemas



Generalização Solução de um problema potencialmente pode ser reutilizada Determinado componente pode ser utilizado em diversos pontos do mesmo sistema, ao invés de várias soluções especializadas Solução pode demorar mais (mais custosa) Avaliar custo e eficiência para decidir Conseqüência principal: portabilidade



Flexibilização Envolve processo e produto

Produto se altera = f(entendimento de requisitos) Processo ocorre passo a passo, de forma incremental

Princípio necessário ao processo para que o produto possa ser modificado com facilidade Processo deve ter flexibilidade para permitir

A reutilização de componentes A portabilidade do produto para diferentes plataformas computacionais


3.2. E. S. - Paradigmas

Modelos de processo de desenvolvimento que proporcionam:

Ao gerente: Controle do processo de desenvolvimento de sistemas de software.

Ao desenvolvedor: Obtenção de base para produzir, de maneira eficiente e eficaz, software que satisfaça os requisitos preestabelecidos.

Objetivo: Diminuir os problemas inerentes ao processo de desenvolvimento de software


3.2. E. S. - Paradigmas (cont.)

Existem vários. Escolha de acordo com:

Natureza do projeto e do produto Métodos e ferramentas Controles e produtos intermediários desejados

Três mais utilizados: Ciclo de vida clássico Evolutivo Espiral



3.2.1. Ciclo de vida clássico Método sistemático e seqüencial O resultado de uma fase é entrada de outra Fases se sucedem linearmente (=> “cascata”) Fases estruturadas como um conjunto de atividades que podem ser executadas

por pessoas diferentes simultaneamente



3.2.1. Ciclo de vida clássico (cont.)Análise e

Especificação de Requisitos

Projeto

Implementação e teste unitário

Integração e teste do sistema

Operação e manutenção

Os cinco passos



3.2.1. Ciclo de vida clássico (cont.) Decomposição = f(complexidade da aplicação)

aplicações simples e bem entendidas menos formalidade

aplicações maiores e mais complexas maior decomposição do processo melhor controle garantia dos resultados

Exemplos - aplicações p/usuários não especialistas: fase p/projetar material especial

de treinamento + treinamento p/entrada em operação

especialistas: manuais técnicos / telefonemas / S.A.U.



3.2.1. Ciclo de vida clássico (cont.) Análise e especificação de requisitos

Via consultas aos usuários Identificar serviços, metas, restrições <=>

qualidade = f(funcionalidade, desempenho, facilidade de uso, portabilidade, ...)

Especificar quais os requisitos, não como alcançá-los

Os requisitos especificados não devem restringir o desenvolvedor no projeto e implementação

Resultado da fase: documento de especificação de requisitos, que deve ser

analisado e confirmado pelos usuários usado pelos desenvolvedores p/obtenção do produto




(cont.) Documento de especificação de requisitos

instrumento de comunicação entre muitos indivíduos inteligível, preciso, completo, consistente e

s/ambigüidades facilmente modificável = f(natureza evolutiva do

software) conciliar interesses dos usuários e do desenvolvedor

texto em linguagem natural versão preliminar do manual do usuário



3.2.1. Ciclo de vida clássico (cont.) Análise e especificação de requisitos (cont.)

Outro resultado da fase: plano de projeto usar princípios: abstração, decomposição e

generalização Documento de especificação de requisitos

funcionais: o que o produto deve fazer não funcionais:

confiabilidade - disponibilidade, integridade, segurança acurácia dos resultados desempenho problemas de ihc restrições físicas e operacionais questões de portabilidade ...




(cont.) Documento de especificação de requisitos

de desenvolvimento e manutenção procedimentos de controle de qualidade procedimentos de teste prioridades de funções mudanças prováveis etc.



3.2.1. Ciclo de vida clássico (cont.) Projeto

Representação das funções do sistema em forma que possa ser transformada em um ou mais programas executáveis

Produto é decomposto em partes tratáveis: documento de especificação de projeto

descrição da arquitetura do software o que cada parte deve fazer relação entre as partes



3.2.1. Ciclo de vida clássico (cont.) Projeto (cont.)

Projeto preliminar x detalhado Preliminar: estrutura de relações: usa,

é_composto_de, herda_de, ... Detalhado: especificação das interfaces Preliminar: decomposição lógica (alto nível) Detalhado: decomposição física do programa em

unidades de programação Preliminar: principais estruturas de dados Detalhado: algoritmos para cada módulo



3.2.1. Ciclo de vida clássico (cont.) Implementação e teste unitário

Transformação do projeto em programas (ou unidades de programas)

Resultado: Coleção de programas implementados e testados,

conforme os padrões da organização, se houverem comentários nomenclatura número máximo de linhas por componente, ...

Teste unitário: verifica se cada unidade satisfaz suas especificações, normalmente conforme padrões

planos e critérios de testes, critério de completude, gerenciamento de casos de teste, respeito a padrões, ...



3.2.1. Ciclo de vida clássico (cont.) Integração e teste do sistema

Programas são integrados e testados como sistema

Freqüentemente não é feito de uma só vez, mas progressivamente, em conjuntos cada vez maiores, a partir de pequenos subsistemas, até que o sistema inteiro seja construído



3.2.1. Ciclo de vida clássico (cont.) Operação e manutenção

Fase mais longa do ciclo de vida Entrega em dois estágios

grupo selecionado de usuários (feedback / alterações, caso necessário)

oficial Manutenção

Atividade posterior à entrega do sistema aos usuários Corretiva: correção de erros remanescentes Adaptativa: adaptação a mudanças do ambiente Evolutiva: mudanças nos requisitos, adição de

características e qualidades ao software



3.2.1. Ciclo de vida clássico (cont.) Outras atividades

Paradigma clássico dividido em fases Algumas atividades devem ser feitas

antes do início do ciclo de vida durante todo o ciclo de vida

Estudo de viabilidade Estágio crítico para o sucesso do projeto Envolve custos e benefícios Limitado por tempo (sob pressão) Poucos recursos investidos Identificar soluções alternativas, c/custos e datas de

entrega Conteúdo: problema, soluções (c/benef. esp., recursos

nec. e datas de entrega



3.2.1. Ciclo de vida clássico (cont.) Outras atividades (cont.)

Documentação Produtos ou resultados da maioria das fases são

documentos Mudança de fases depende destes documentos Seguir padrões da organização p/sua elaboração

Verificação Ocorre no teste unitário e do sistema Também em outras fases Processo de controle de qualidade via revisões e

inspeções Descoberta e remoção de erros deve ocorrer o

quanto antes (antes da entrega do produto)



3.2.1. Ciclo de vida clássico (cont.) Outras atividades (cont.)

Gerenciamento Meta: controlar o processo de desenvolvimento Adaptação do ciclo de vida ao processo: rigidez /

profundidade variáveis Políticas: armazenagem, acesso e modificação de

produtos / resultados intermediários; critérios de construção de versões diferentes e autorizações para acesso aos componentes de entrada e saída do banco de dados



3.2.1. Ciclo de vida clássico (cont.) Contribuições geradas

Processo sujeito a disciplina, planejamento e gerenciamento

Implementações postergadas até o entendimento completo dos objetivos

Problemas Rigidez (o desenvolvimento não é linear, é iterativo!) Objetivo continua sendo a linearidade =>

Previsibilidade Facilidade de monitoramento

Planejamento orientado para data de entrega única, que pode ser bastante longa (“congelamento?”)



3.2.2. O paradigma evolutivo Base

Desenvolvimento e implementação de produto inicial

Comentários e críticas dos usuários Refinamento através de múltiplas versões Desenvolvimento e validação paralelas (rápido

feedback) Dois tipos

Desenvolvimento exploratório Protótipo descartável



3.2.2. O paradigma evolutivo (cont.) Desenvolvimento exploratório

Objetivo: trabalhar junto do usuário para descobrir os requisitos

Incremental, até o produto final ser obtido Adoção: dificuldade (ou impossibilidade) de

obter especificação detalhada de requisitos a priori

Início Partes mais bem entendidas

Evolução Novas características adicionadas (sugeridas

pelo usuário)



3.2.2. O paradigma evolutivo (cont.)

Descrição

Atividades Paralelas

Desenvolvimento

Validação

Versão inicial

Versão intermediári

a

Versão final

Desenvolvimento exploratório



3.2.2. O paradigma evolutivo (cont.) Protótipo descartável

Objetivo: melhor definir requisitos do usuário/sistema

Fazer experimentos c/requisitos não bem entendidos

Envolve projeto, implementação e teste (não formais / completos)

Adoção Usuário define objetivos / não define E-P-S Desenvolvedor incerto sobre

Eficiência de algoritmo Adaptação da aplicação a sistema operacional Forma de IHC



3.2.2. O paradigma evolutivo (cont.) Protótipo descartável (cont.)

Possibilita criar modelo do software a construir Desenvolvedor pode perceber reações do usuário e obter

sugestões para mudança / inovação Usuário pode relacionar protótipo com requisitos

Operacionalização Versão preliminar da especificação de requisitos Construção do protótipo descartável Uso pelos usuários => ok’s, alterações, sobras, faltas, etc. Modificação do protótipo / uso pelos usuários Repetir ciclo enquanto novas informações valerem $ e

tempo Especificação de requisitos definitiva = f(modificações) Desenvolvimento



3.2.2. O paradigma evolutivo (cont.) Protótipo descartável (cont.)

Análise de requisitos

Análise de requisitos

Projeto

Implementação

Teste

Projeto Implementação Teste

Protótipo descartável



3.2.2. O paradigma evolutivo (cont.) Mais efetivo do que o ciclo de vida clássico Problemas (perspectivas de engenharia e gerenciamento)

Processo não visível, rápido, documentação de cada versão não compensatória, mas necessária para medição de progresso

Estruturação de produto pobre (corrompida pelas mudanças) => evolução difícil e custosa

Protótipo a descartar construído artificialmente => qualidade e alterabilidade? / Pressão dos usuários p/ transformar protótipo em produto final s/reconstrução

Escolhas inapropriadas (dos desenvolvedores) podem tornar-se parte integrante do sistema



3.2.2. O paradigma evolutivo (cont.) Vantagem

Abordagem leva a testes mais efetivos“Testar cada versão é mais fácil que o sistema

todo ao final do desenvolvimento”

Aplicabilidade prática Sistemas pequenos

Mudanças = redesenvolvimento total



3.2.3. O paradigma espiral (ou de BOEHM, 1991)

Engloba as melhores características do ciclo de vida clássico e do paradigma evolutivo

Inclui análise de risco“Riscos são circunstâncias adversas que podem

atrapalhar o processo de desenvolvimento e a qualidade do produto a ser desenvolvido”

Prevê a eliminação de problemas de alto risco Planejamento e projeto cuidadosos Tratamento de problemas triviais e não triviais de

formas diferentes



3.2.3. O paradigma espiral (cont.) Atividades organizadas como uma espiral de

muitos ciclos (ciclo = fase de desenvolvimento) 1o.: estudo de viabilidade + operacionalidade

(funcionalidades e características do sistema e do ambiente em que será desenvolvido)

2o.: definição dos requisitos 3o.: projeto ... Não existem fases fixas Durante o planejamento decide-se como estruturar

o processo de desenvolvimento em fases



3.2.3. O paradigma espiral (cont.) Atividades principais

Definição dos objetivos, alternativas e restrições Objetivos para a fase de desenvolvimento

Ex.: desempenho e funcionalidade Alternativas para atingir os objetivos Restrições do processo e do produto Esboço de plano inicial Identificação de riscos de projeto Planejamento de estratégias alternativas = f(riscos)

Ex.: desenvolvimento x compra de produto

Análise de risco Análise cuidadosa + atitudes p/ cada risco, visando

redução Ex.: requisitos c/problemas => desenvolvimento de

protótipo



3.2.3. O paradigma espiral (cont.) Atividades principais (cont.)

Desenvolvimento e validação Avaliados os riscos, escolher um paradigma de

desenvolvimento Ex.: Predominância de riscos de interface com o usuário

=> escolha do paradigma de prototipagem evolutiva Planejamento

Revisar o projeto Decidir por percorrer ou não mais um ciclo na espiral Para o caso de decisão positiva

Planejar a próxima fase do desenvolvimento do projeto Para o caso de decisão negativa (grandes riscos, p. ex.)

Descontinuar o projeto



3.2.3. O paradigma espiral (cont.) Diferença mais importante dos outros dois

Análise de risco Entendimento e reação do desenvolvedor aos

riscos a cada ciclo Mecanismo de redução de risco / manutenção

do desenvolvimento sistemático = prototipagem

Incorporação de componente iterativo => refletir o mundo mais realisticamente

Exige especialização em análise de risco Riscos podem ser diminuídos / sanados através de

informações que diminuam a incerteza do desenvto.



3.2.3. O paradigma espiral (cont.)

Análise de risco

Protótipo 1

Operacionalidade do software

Plano de requisitos

Plano do ciclo de vida

Análise de risco

Protótipo 2

Análise de risco

Análise de risco

Análise de risco

Protótipo operacion

alProtótip

o 3

Simulações, modelos

Validação dos requisitos

Requisitos de software

Plano de desenvolvimen

toCódigo

Projeto detalhado

Definição dos objetivos,

alternativas e restrições

Revisão

PlanejamentoIntegração e

plano de teste

Validação do projeto e

verificação

Projeto do software

Teste unitário

Teste de integração

Implantação

Teste de aceitação

Desenvolvimento e validação


3.3. E. S. - Interações da E. S. com outras áreas

Teoria da computação Desenvolvimento de modelos úteis para a E. S.

Autômatos de estados finitos: especificação de sistemas operacionais, I. H. C. e processadores p/tais especificações

Semântica formal Permite raciocinar sobre as propriedades dos

sistemas Importância cresce com o tamanho e a

complexidade dos sistemas Ex.: Sistema de controle de linhas de trens determina que

deve existir, em qualquer parte dos trilhos de uma linha, no máximo, um trem => semântica formal permite a produção de prova de que o software sempre terá este comportamento


3.3. E. S. - Interações da E. S. com outras áreas (cont.)

Linguagens de programação Grande influência no alcance dos objetivos da

E. S. Objetivos da E. S. influenciam o

desenvolvimento das L. P. Inclusão de características modulares Compilação independente Separação entre especificação e implementação Desenvolvimento de “pacotes”: separação entre a

interface e a implementação Bibliotecas de componentes para o desenvolvimento

de sistemas independentes



Compiladores Desenvolvimento modular Dois componentes

Análise da linguagem Geração do código

Decomposição permite a reutilização do segundo componente no desenvolvimento de outros compiladores

Técnica usada na construção de compiladores da família GNU

Atende a diferentes arquiteturas e L. P. de alto nível Escrita do menor número de linhas de código

viável = f(reutilização), conceito da E. S.



Sistemas operacionais Ferramentas p/o gerenciamento da

configuração Manutenção / controle das relações entre

componentes e versões do sistema de software Ex.: UNIX

Vantagem sobre antecessores Organização como um conjunto de programas

simples Podem ser combinados com grande flexibilidade Interface comum: arquivos texto



Bancos de dados Linguagens de consulta permitem o uso dos

dados sem se preocupar com sua representação interna

B. D. pode ser alterado para melhorar o desempenho do sistema sem mudanças na aplicação

Podem ser usados como componentes de sistemas: resolvem muitos problemas de acesso concorrente, por múltiplos usuários, a grandes volumes de dados



Sistemas multiagentes Sistemas complexos Desenvolvimento envolve a decomposição do

produto / separação de preocupações Ex.: Sistema para o processamento de textos

pode ser decomposto em Análise sintática Análise semântica Análise pragmática Etc.



Sistemas especialistas Sistemas modulares Dois componentes distintos

Fatos conhecidos pelo sistema Regras para processar os fatos

Ex.: Regra p/decidir determinada ação Conhecimento é dado pelo usuário Princípios gerais de como aplicar o

conhecimento a qualquer problema são fornecidos pelo próprio sistema



Ciência do gerenciamento Estimativas de projeto Cronograma Planejamento de recursos humanos Decomposição e atribuição de tarefas Acompanhamento de projetos Contratação e atribuição da tarefa certa à

pessoa certa



Engenharia de sistemas Estuda sistemas complexos Hipótese: certas leis governam qualquer

sistema complexo / composto de componentes com relações complexas

Software é componente de um sistema maior => sujeito às técnicas da engenharia de sistemas


4. Considerações finais Paradigmas podem ser combinados

Pontos fortes de cada um utilizados em um único projeto

Paradigma espiral faz isso diretamente, combinando

Prototipagem + elementos do ciclo de vida clássico Em paradigma evolutivo

Qualquer paradigma pode servir como alicerce no qual outros se integram

Processo sempre começa com determinação dos objetivos, alternativas e restrições (obtenção de requisitos preliminar)

Depois disso, adotar qualquer caminho


4. Considerações finais (cont.)

Ex.: Para sistema completamente especificado no

início Ciclo de vida clássico

Para sistema com requisitos não muito claros Protótipo para definir requisitos Usado como guia, desenvolvedor pode adotar passos do

ciclo de vida clássico (projeto, implementação e teste)ou Alternativamente, protótipo pode evoluir para um

sistema, retornando ao paradigma do ciclo de vida clássico para teste

A natureza da aplicação é que vai determinar o paradigma a ser utilizado, e a combinação de paradigmas só tende a beneficiar o processo como um todo.


5. Exercícios1) O gerente geral de uma cadeia de lojas de presentes

acredita que o único objetivo da construção de um protótipo é entender os requisitos do usuário e que depois esse protótipo será descartado. Portanto, ele acha bobagem gastar tempo e recursos em algo que será desprezado mais tarde. Considerando essa relutância, resolva as seguintes questões:

(a) Compare brevemente o protótipo descartável com o desenvolvimento evolutivo, de forma que o gerente compreenda o que um protótipo pode significar.

(b) O gerente pensa em implementar o sistema, implantá-lo em uma loja e, depois, se obtiver sucesso, instalá-lo nas outras cinco lojas da cadeia. Diga qual método de prototipagem deve ser usado e justifique sua escolha.


5. Exercícios2) Qual a importância do software?

3) O que é software legado?

4) Cite 3 (três) tipos de software. Pesquise e descreva cada um deles.

5) Quais as diferenças dos modelos cascata e espiral?

6) Quais as atividades do modelo tradicional?

7) Descreva o modelo de prototipação.


Bibliografia

CARVALHO, A. M. B. R.; CHIOSSI, T. C. S. Introdução à Engenharia de Software. Campinas: Editora da Unicamp, 2001.

análise e projeto de sistemas setembrino soares ferreira jr. 01 - introdução

Documents