• Nenhum resultado encontrado

INTRODUÇÃO A ANÁLISE DE SISTEMAS

N/A
N/A
Protected

Academic year: 2021

Share "INTRODUÇÃO A ANÁLISE DE SISTEMAS"

Copied!
65
0
0

Texto

(1)
(2)

PROGRAMAR É DIVERTIDO !

DESENVOLVER SOFTWARE

COM QUALIDADE É DIFÍCIL !

(3)

Ambientes de Desenvolvimento de Software

Empresas que têm o software como atividade

fim

.

_ Analista programador autônomo

1 Coitado autonomo

_ Pequena Software House

1 Proprietários

Alguns Analistas/Programadores

_ Média Software House

1 Gerente de Desenvolvimento

Alguns Líderes de Equipe/Analista

Vários Analistas/Programdores

Vários Programadores

_ Grande Software House

1 Diretor de Desenvovimento

Alguns Líderes de projeto

Alguns Lideres de Equipe

Poucos Analistas de Negócio

Vários Analistade de Sistemas

Vários Programadores

(4)

Ambientes de Desenvolvimento de Software

Empresas que têm o software como atividade

meio

.

_ Funcionário faz tudo de pequenas empresas.

1 Coitadinho

_ Analista/Programador de médias empresas.

1 Coitado

_ Equipe de desenvolvimento de médias empresa.

1 encarregado do desenvolvimento

Alguns analistas/programadores

Alguns programadores

_ Gerência de Desenvolvimento de Grande Empresas.

1 Gerente de Desenvolvimento

Alguns Lideres de projeto

Alguns Lideres de Equipe

Alguns Analistas de Negócio

(5)

Parque de Softwares de uma empresa

Softwares Legados

Software de Terceiros

Novos Softwares

Em desenvolvimento

(6)
(7)

Gap semântico

Distância entre o problema no mundo real e o modelo abstrato(software) construído;

Quanto menor for a Gap Semântico:

_mais rápida será a construção da solução;

_menos retrabalho será feito.

_menos desgaste haverá da equipe desenvolvedora com o

cliente.

_ menos atraso na entrega haverá

_ menos dinheiro será desperdiçado.

Portanto, diminuir o gap semântico tornou-se um dos objetivos da Engenharia de

Software;

(8)
(9)
(10)
(11)
(12)
(13)
(14)
(15)
(16)
(17)
(18)

Levantamento de requisitos

Análise de Custos

Analise de Riscos

Estimativas

Análise e projeto de Sistemas

Projeto de Interfaces

Implementação

Verificação e Validação(testes)

Implantação

Gerência de

Configuração(Manutenção)

• Gerência de Projeto

• Qualidade de

Software

A Engenharia de Software é uma disciplina dos cursos de informática que se ocupa de todos os

aspectos da produção de software, desde os estágios iniciais de especificação do sistema até a

manutenção desse sistema, depois que ele entrou em operação.

(19)

Ciclo de Vida do Software

O ciclo de vida de um software descreve as fases pelas quais o

software passa desde a sua concepção até ficar sem uso algum.

Para se padronizar o desenvolvimento de software e se ter uma

forma documentada de iteração da equipe de desenvolvimento do

software e o cliente, foram criados modelos de ciclo de vida, ou

processo de software.

Estes modelos definem as etapas do desenvolvimento, assim

como os artefatos(documentos e desenhos) que devem ser

produzidos para permitir a validação

de uma etapa antes de

passar à próxima etapa.

(20)

Ciclo de Vida do Software

Os modelos de ciclo de vida têm dois propósitos principais:

1 – Reduzir o Gap Semântico

2 – Detectar erros, provindos do Gap Semântico, nas fases

iniciais do projeto.

As fases do ciclo de vida de um software variam com o processo

que é utilizado para desenvolver o software.

(21)

PROCESSO

PROJETO

É uma sequência coordenada e

padronizada de atividades, com o

objetivo de ser repetido para produzir

várias vezes o mesmo resultado.

É o planejamento de atividades não

padronizadas que serão executadas

para atingir um resultado único.

As pessoas desempenham as

mesmas tarefas a cada ciclo do

processo.

A equipe planeja e executa o projeto.

O controle de produtividade é

estabelecido em torno de metas de

produção.

Enfrenta escopos que podem ser

desconhecidos.

Ex: Desenvolvimento de um novo

carro.

(22)

PROCESSO DE SOFTWARE

É o roteiro ou sequência de passos, que devem ser executados

para se criar um software.

Existem diferentes processos padronizados.

Empresas adequam um determinado processo à sua necessidade.

O processo fornece uma estabilidade, controle e organização no desenvolvimento de

um software.

Sem um processo definido a atividade de criação de um software se torna caótica.

Existem vários mecanismos para avaliar a qualidade de um processo de software e

e maturidade deste processo.

(23)

PADRONIZAÇÃO

Definição do padrão.

Reconhecimento do

padrão.

(24)

ISO é a sigla de International Organization for Standardization, ouOrganização

Internacional para Padronização, em português.

A ISO é uma entidade de padronização e normatização, e foi criada em Genebra,

na Suiça, em 1947.

A sigla padrão no mundo é ISO, em grego isos significa "igual”.

A ISO tem como objetivo principal aprovar normas internacionais em todos os campos

técnicos, como normas técnicas, normas de procedimentos e processos, e etc.

No Brasil, a ISO é representada pela

(25)
(26)

O Instituto de Engenheiros Eletricistas e Eletrônicos ou IEEE

(pronuncia-se I-3-E)

é uma organização profissional sem fins lucrativos, fundada nos Estados Unidos,

em 1963.

É a maior (em número de instituições, não em popularidade) organização

profissional do mundo.

O IEEE tem filiais em muitas partes do mundo, sendo seus sócios engenheiros

eletricistas, engenheiros da computação, cientistas da computação, profissionais

de telecomunicações, dentre outros.

Sua

meta

é

promover

conhecimento

no

campo

da

engenharia

elétrica, eletrônica e computação.

(27)

A Comissão Eletrotécnica Internacional (em inglês: International Electrotechnical

Commission, IEC) é uma organização internacional de padronização de tecnologias

elétricas, eletrônicas e relacionadas. Alguns dos seus padrões são desenvolvidos

juntamente com a Organização Internacional para Padronização (ISO).

(28)

A norma internacional ISO/IEC 12207 tem como

objetivo principal estabelecer uma estrutura comum

para

os

processos

de

ciclo

de

vida

e

de

desenvolvimento

de

softwares

visando

ajudar

as

organizações

a

compreenderem

todos

os

componentes

presentes

na

aquisição

e

fornecimento de software e, assim, conseguirem

firmar contratos e executarem projetos de forma mais

eficaz.

(29)

A norma brasileira NBR ISO/IEC 9126 é uma norma ISO para qualidade de

produto de software, ela define um conjunto de parâmetros com o objetivo de

padronizar a avaliação da qualidade de software.

A norma 9126 foca na qualidade do produto de software, propondo Atributos

de Qualidade, distribuídos em seis características principais, com cada uma

(30)

A Engenharia de Software é a aplicação de uma

abordagem

sistemática,

disciplinada

e

quantificável para o desenvolvimento, operação

e manutenção do software, isto é, a aplicação

de engenharia ao software(IEEE,IEE93).

(31)
(32)

A Associação para Promoção da Excelência do Software Brasileiro (Softex)

executa, desde 1996, iniciativas de apoio, desenvolvimento, promoção e

fomento para impulsionar a Indústria Brasileira de Software e Serviços de TI.

O MPS.BR é um programa mobilizador que foi criado em 2003 pela Softex

para melhorar a capacidade de desenvolvimento de software nas empresas

brasileiras. A iniciativa foi responsável pelo desenvolvimento do Modelo de

Referência para Melhoria do Processo de Software Brasileiro (MPS-SW), que

levou em consideração normas e modelos internacionalmente reconhecidos,

(33)

O CMMI (Capability Maturity Model - Integration ou Modelo de Maturidade em

Capacitação - Integração) é um modelo de referência que contém práticas

necessárias à maturidade de processos.

O CMMI foi baseado nas melhores práticas para desenvolvimento e

manutenção de produtos.

Há uma ênfase tanto em engenharia de sistemas, quanto em engenharia de

software, e há uma integração necessária para o desenvolvimento e a

manutenção.

Desenvolvido pelo SEI (Software Engineering Institute) da Universidade

Carnegie Mellon, o CMMI é uma evolução do CMM e procura estabelecer um

modelo único para o processo de melhoria corporativo, integrando diferentes

modelos e disciplinas.

(34)

Processo de Desenvolvimento de Software Interativo

É

um processo que prioriza a interação da equipe de desenvolvimento de

software com os usuários.

(35)

Processo de Desenvolvimento de Software Iterativo

É um processo no qual a desenvolvimento do software e realizado por meio da

repetição de um conjunto de passos.

(36)

ARCABOUÇO DE PROCESSO

O arcabouço de processo estabelece atividades que devem ser realizadas em

qualquer processo de software.

Pressman define 5 atividades genéricas que definem o arcabouço de um

processo de software.

1 – COMUNICAÇÃO: Interação com o usuário/cliente

2 – PLANEJAMENTO: Define as técnicas

que serão realizadas, os riscos

prováveis, os recursos necessários, os produtos do trabalho a ser produzido e

um cronograma.

3 – MODELAGEM: Criação de modelos para esclarecer os requisits e reduzir o

Gap Semântico.

(37)

Modelo Prescritivo de Processo de Software

Um Modelo Prescritivo de Processo de Software é um conjunto de elementos

que inclui ações de engenharia de software, produtos de trabalho e

mecanismos que garantam a qualidade e controle de modificações em cada

projeto de desenvolvimento de um software (PRESSMAN, 2010).

Não considere um modelo prescritivo de processo como estático, mas sim

um processo dinâmico e adaptável ao desenvolvimento do software.

Modelos prescritivos devem ser adaptados ao pessoal, ao problema e ao

projeto.

(38)

Modelo Prescritivo de Processo de Software

1 Modelo em Cascata

2 Modelos Incrementais

2.1 Modelo Incremental

2.2 RAD (Rapid Application Development)

3 Modelos Evolucionários

3.1 Prototipagem

3.2 Modelo Espiral

4 Modelos Especializados de Processo

4.1 Desenvolvimento Baseado em Componentes

4.2 Modelos de Metodos Formais

4.3 Desenvolvimento de Software Orientado a Aspectos

(39)

1 Modelo em Cascata

Também conhecido como Ciclo de Vida Clássico, é ideal para problemas nos quais

os requisitos são bem definidos.

Implementa uma abordagem sistemática e sequencial, isto é, uma nova atividade

só pode ser iniciada quando a anterior estiver totalmente concluída, conforme figura

abaixo:

(40)

1 Modelo em Cascata

Vantagens:

Torna o processo de desenvolvimento estruturado;

Tem uma ordem sequencial de fases;

Permite que os desenvolvedores descrevam o que deve ser realizado;

Fácil gerenciamento;

Todas as atividades identificadas nas fases do modelo são fundamentais e estão na

ordem certa;

(41)

1 Modelo em Cascata

Desvantagens:

Não fornece feedback entre as fases e não permite a atualização ou redefinição

das fases anteriores;

Só há uma etapa para o levantamento de requisitos e não permite a modificação de

requisitos;

Propicia pouca interação da equipe com o cliente(usuário);

É excessivamente sincronizado;

Se ocorrer um atraso, todo o processo é afetado;

O cliente só pode ver o produto funcionando quando este estiver completamente

pronto;

(42)

2 Modelos Incrementais

Há muitas situações em que os requisitos iniciais do software são razoavelmente

bem definidos, mas não é possível se definir o escopo total do projeto. Nessa

situação não é adequado seguir um processo puramente linear.

O modelo incremental normalmente, é escolhido quando há uma necessidade de

entrega rápida de algumas funcionalidades do software, mesmo que sejam

limitadas.

Posteriormente, as funcionalidades que foram entregues serão refinadas e

expandidas em versões seguintes;

(43)

2-1Modelo Incremental

O software é dividido em incrementos

Desenvolve-se pequenas parte do software em um curto prazo;

(44)

2-1Modelo Incremental

Exemplo

Um software de processamento de texto:

1º Incremento: Entregar a gestão básica de arquivos, edição e

produção de documentos.

2º Incremento: Capacidades de edição e de produção de

documentos mais sofisticados.

(45)

2-1Modelo Incremental

O 1º Incremento do modelo incremental é chamado de núcleo

do produto: requisitos básicos são satisfeitos.

Nos próximos incrementos é feita a revisão e incorporação de

características suplementares.

O objetivo do modelo é oferecer ao usuário um produto

operacional a cada incremento, versões simplificadas do

produto final, mas que oferecem capacidades que servem ao

usuário.

(46)

2-1Modelo Incremental

Quando usar:

Quando não há mão-de-obra disponível para uma implementação

completa.

Quando o cliente não aceita esperar muito para começar a utilizar o

software.

Quando não é possível especificar completamente todos os requisitos

Para gerir riscos técnicos.

Exemplo: um sistema exige um hardware novo que ainda está em

desenvolvimento. Os primeiros incrementos podem ser planejados de

(47)

2.1 Modelo Incremental

Vantagens:

Versões do software são fornecidas ao cliente após cada iteração do

modelo incremental;

O Modelo Incremental inclui o uso do software pelo usuário para que as

mudanças sejam feitas de acordo com o mesmo;

Melhor gerenciamento de riscos, porque você pode confirmar o resultado

com o cliente depois de cada versão do sistema.

Riscos críticos são resolvidos antes que grandes investimentos sejam

realizados;

Permite verificar se o software está sendo construído conforme a

expectativa do cliente. Caso não esteja, a correção pode ser feita na

próxima versão do software;

(48)

2.1 Modelo Incremental

Desvantagens:

Podem surgir problemas relativos à arquitetura do sistema, porque nem

todos os requisitos são levantados no início do ciclo de vida do software.

Cada incremento deve ser relativamente pequeno. Se for muito grande

este modelo se aproxima do modelo em cascata

O escopo completo do software pode não ser levantado no início do

projeto.

(49)

2.2 Modelo Incremental RAD(Rapid Application Development)

Processo incremental com trabalho de equipes de desenvolvimento em paralelo.

(50)

2.2 Modelo Incremental RAD(Rapid Application Development)

Na construção enfatiza o uso de componentes de software

preexistentes e a aplicação da geração automática de código.

Prevê a entrega de um software completo em um período curto

de tempo( 60 a 90 dias)

Vantagens:

(51)

2.2 Modelo Incremental RAD(Rapid Application Development)

Desvantagens:

Para projeto muito grandes e que ainda podem sofrer aumento de escopo é

necessário ter corpo técnico que possibilite formar várias equipes.

Se desenvolvedores e clientes não estiverem comprometidos com as

atividades no seu determinado tempo, o projeto RAD falhará.

Se o sistemas não for adequadamente modularizado o processo pode

falhar.

(52)

3 MODELOS EVOLUCIONÁRIOS

O software evolui com o passar do tempo.

Os requisitos podem mudar durante a construção do software.

Os prazos reduzidos podem tornar impossível entregar um

software completo mas pode-se entregar uma versão reduzida

e deixar para definir as extensões do software posteriormente.

Os modelos evolucionários foram criados para acomodar as

mudanças dos requisitos e do escopo de um software.

(53)

3.1 PROTOTIPAGEM

Utiliza-se protótipos para auxiliar na identificação dos requisitos

de software porque, nem sempre, os requisitos de entrada, de

processamento e de saída são bem definidos;

Os protótipos produzidos devem focar os interesses do cliente

como, por exemplo, a interface de páginas, estrutura de

(54)

Os protótipos podem ser:

1. Um modelo em papel ou em um software de desenho no

qual o usuário tenha a visão da interação

humano-computador e quantas interações ocorrerá.

2.

Um

protótipo

de

trabalho

que

implementa

algumas

funcionalidades exigidas pelo software e que a equipe de

desenvolvimento ainda não saiba como construir.

3. Um programa existente que executa parte ou toda a função

desejada, mas que tem outras características que serão

(55)
(56)

3.1 PROTOTIPAGEM

Vantagens:

Facilita a definição de requisitos.

Reduz os riscos e incertezas do desenvolvimento.

A experiência de produzir o protótipo pode reduzir o custo das

etapas seguintes.

(57)

3.1 PROTOTIPAGEM

Desvantagem:

O cliente precisa estar ciente de que o produto deverá

ser refeito, uma vez que foi construído apenas um

(58)

3.2 Modelo Espiral

É um Modelo Evolucionário que combina a natureza iterativa da

Prototipagem com os aspectos controlados e sistemáticos do Modelo em

Cascata.

Possibilita o desenvolvimento rápido de versões cada vez mais completas.

As versões iniciais podem ser um modelo de papel ou protótipo. As últimas

são cada vez mais completas do sistema submetido à engenharia.

(59)

3.2 Modelo Espiral

No modelo espiral cada giro na espiral (iniciando a partir do centro e

avançando para fora) representa uma nova fase do processo.

Este modelo introduz a análise de riscos antes de se começar uma nova

fase do projeto.

(60)

3.2 Modelo Espiral

Vantagens:

Aceita mudanças na definição do software ao longo

do seu desenvolvimento.

São feitas muitas análises de riscos.

É indicado para softwares grandes.

(61)

3.2 Modelo Espiral

Desvantagens:

O escopo completo do software não é levantado no início do

projeto.

Pode ser difícil convencer o cliente que o modelo será

controlável.

(62)

Desenvolvimento Interativo

No desenvolvimento de software interativo o cliente(usuário) participa ativamente da

construção do software, reunindo-se frequentemente com a equipe de desenvolvedores.

Normalmente é utilizado junto com os modelos incrementais e evolucionários.

O aprendizado ocorre simultaneamente tanto para o desenvolvedor, quanto para o usuário do

sistema.

(63)

Desenvolvimento Interativo

Vantagens:

Baseia-se fortemente na participação e uma boa comunicação entre desenvolvedores e

usuários.

Há um grande envolvimento do usuário e do cliente. Isto leva superação rápida dos

mal-entendidos entre os desenvolvedores e usuários.

Porque há resultados mais rápidos e "tangíveis", os usuários também serão capazes de dar

um melhor feedback;

Os resultados mostrados permitirão que os usuários tenham confiança em um bom resultado

final;

A cada ciclo do sistema, os usuários e clientes poderão utilizar o sistema diretamente. Eles

são os "testadores" no processo de desenvolvimento e eles estarão interagindo com o

sistema durante o desenvolvimento;

Os riscos podem ser melhor administrados por pequenos pedaços do sistema a serem

desenvolvidos em pequenos espaços de tempo;

(64)

Desenvolvimento Interativo

Desvantagens:

Durante o processo de desenvolvimento necessita-se adaptar e refinar o sistema, com isso

pode ser que no final o software fique totalmente diferente da ideia original;

Durante o construção do software podem aparecer muitos requisitos novos, aumentando

constantemente o escopo do software.

Gerentes que estão acostumados com a forma linear do desenvolvimento de um software

podem ter alguns problemas ao trabalharem com uma forma mais flexível;

(65)

Desenvolvimento Ágil

Processos de desenvolvimento de software com características evolucionárias e

muito interativo.

Valorizam a interação entre pessoas. Não valorizam documentação escrita.

É o processo que está na moda.

Exemplos: Programação Extrema e Scrum.

Referências

Documentos relacionados

Nesta reunião, o ScrumMaster trabalha junto com o Proprietário do Produto e a Equipe de Desenvolvimento para definir qual a carga de tempo que cada funcionalidade do Product

Esse conjunto de função consiste naquelas funções não diretamente relacionada à definição, ao gerenciamento, ao desenvolvimento e ao teste de software, mas que não

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

• Gerar nos alunos de Análise e desenvolvimento de software a capacidade de analisa, documentar e especificar sistemas computacionais de informação.. Estes devem fazer uso

• O ciclo de vida iterativo e incremental pode ser visto como uma generalização da abordagem em cascata: o software é desenvolvimento em incrementos e cada incremento é desenvolvido

• Deve-se avaliar o conjunto de requisitos essenciais para a definição do Documento de Visão do software e este deve incluir o escopo do projeto e suas limitações, bem como

• Depois de determinar os custos e benefícios para uma possível solução, você pode realizar a análise de custo- benefício.. Estudo

• Requisitos são tipicamente utilizados como informações fundamentais para a fase de projeto de um produto ou serviço, especificando as propriedades e funções necessárias