Vous êtes sur la page 1sur 28

03/09/2015

Histria

Modelo Cascata

A primeira descrio do modelo cascata foi


citada em 1970 por Wiston W. Royce em um
artigo, entretanto no foi usado o termo
cascata. Royce apresentou este modelo como
um exemplo falho e no funcional.

Jder Hartmann
Cssio Guilherme Eckstein

Conceitos
Este modelo de desenvolvimento sugere uma
abordagem sequencial e sistemtica para o
desenvolvimento de software. Possui seis fases
que funcionam como uma cascata, visto
como um modelo com um grande risco e
convite a falhas, quando no desenvolvido da
forma correta.

Fases
Analise: determinar as necessidades ou
condies do cliente para a criao de um novo
produto ou projeto.

Projeto: quando os dados da anlise so

transformados para representar os requisitos


de uma forma que permita a codificao do
produto.

Implementao: desenvolvimento,

demonstrao e integraao do software. a


codificao do software.

03/09/2015

Fases

Testes: deteco de erros e bugs.

Implantao: tornando o software pronto para

execuo.

Manuteno: modificao do software

verificando existencia de erros e aprimorando


sua performance.

Utilizao

Vantagens

Requisitos bem determinados.

Desenvolvimento claramente definido.

Adaptaes ou aperfeioamentos.

Fase seguinte somente se inicia quando o

Projetos simples ou com pouca

funcionalidades.

cliente valida a fase anterior.

Maior foco no planejamento.

Caso no haja problema no desenvolvimento,

facil definio do prazo de entrega.

03/09/2015

Questo
Existe algum tipo de devantagem nesse
modelo de desenvolvimento? Se sim, diga
qual?

Resposta
No fornece feedback entre as fases e no
permite a atualizao ou redefinio das fases
anteriores.

No suporta modificaes nos requisitos.

No permite a reutilizao.

Se ocorrer um atraso todo o processo

afectado.

Cliente somente pode utilizar o software

quando ele estiver totalmente pronto.

03/09/2015

Modelo Cascata

Ricardo Marchesan

VISO GERAL
Foi proposto por Royce em 1970;
Mais rgido e menos administrativo;
Orientado para documentao;
Diferentes etapas de desenvolvimento seguem
uma sequencia;
Atividades semelhantes esto em uma mesma
tarefa;
Uma tarefa s pode ser comeada assim que a
anterior for terminada;

DEFINIO
Se aplia a softwares em que todos os requisitos
so bem conhecidos;
Modelo simples de se controlar;
Segue uma ordem cronolgica;
Fcil de ser gerenciada;
O resultado final pode demorar para ser
apresentado.

VISO GERAL
S se pode avanar para uma prxima tarefa se
o cliente validar a anterior;
O cliente participa ativamente do processo de
criao do software.

03/09/2015

ATIVIDADES
Anlise e definio dos requisitos;
Projeto do sistema;
Implementao;
Teste do sistema;
Manuteno;

Questo
Para que finalidade de software este modelo
adequado.

PRS E CONTRAS
Torna o desenvolvimento estruturado;
As atividades so fundamentais e esto na
ordem correta;
O cliente sempre saber como est o
desenvolvimento;
No preve a manuteno;
Se atrasar em uma atividade todo o projeto
atrasado;
No permite reutilizao.

Resposta
Para softwares aos quais se sabe exatamente o
que ele deve fazer, que no ter alteraes no
decorrer do percurso.

03/09/2015

Definio

Modelo em
Espiral
Naiara Correa
Engenharia de Software

O modelo de processo de software em


espiral, foi proposto por Barry W. Boehm
em 1986.
um modelo baseado em anlise de
risco e planejamento, que so realizados
durante toda a evoluo Pode tambm
ser usado como um guia para os demais
modelos.

Viso geral

O modelo em espiral evolucionrio e


iterativo e seu desenvolvimento
baseado em loops. Cada loop representa
uma fase do processo de software. A
evoluo se d a cada loop.

03/09/2015

Funcionamento das atividades

Vantagens e Desvantagens

dividido em 4 setores:
Definio de Objetivos
Avaliao e reduo de riscos
Desenvolvimento e validao
Planejamento

Vantagens: possvel acomodar as


principais caractersticas dos demais
modelos; foca em opes de reuso de
software; elimina erros e reduz riscos;
entre outros.
Desvantagens: Exige grande experincia
na avaliao dos riscos; diferenas entre
o prottipo e o sistema final; entre outros.

Pergunta

Resposta

Em que setores dividido o modelo em


espiral?

Definio de Objetivos
Avaliao e reduo de riscos
Desenvolvimento e validao
Planejamento

03/09/2015

Modelo baseado
em componentes
CBSE - Component-Based Software Enginnering
Nomes: Lucas Werschedet Rodrigues | Guilherme Girardi
Disciplina: Engenharia de Software

Definio CBSE:
Componentes independentes: deve haver clara separao entre a
interface do componente e sua implementao de maneira que possa ser
substituda sem mudana no sistema;
Padres de componentes: definem como as interfaces de componentes
especificadas e como devem se comunicar;
Middleware: apoio de software para integrao dos componentes;
Processo de desenvolvimento voltado CBSE: 1) Requisitos do
usurio so desenvolvido em linhas gerais Os stakeholders so
encorajados a serem flexveis; 2) Requisitos so modificados no incio do
processo. 3) Busca adicional dos componentes e uma atividade de
refinamento de projeto depois que a arquitetura do sistema foi projetada.
4) O desenvolvimento um processo de composio no qual os
componentes descobertos so integrados.

Histria:
Surgiu final da dcada de 1990 como uma abordagem baseada
em reuso para desenvolvimento de software;
Classes de objetos muito detalhadas e especficas;
Necessrio conhecimento do cdigo fonte;
Difcil propagar a ideia de que os objetos eram componentes
reusveis;
CBSE um processo de definio, implementao e integrao de
componentes independentes no firmemente acoplados ao
sistema;
Entrega de software melhores e mais rpidos (melhor que
reimplementao);

Componente e suas caractersticas:


Componente uma unidade de software independente que pode ser
composta por outros componentes para criar um software;
Padronizado: CBSE deve estar de acordo com um modelo padronizado de
componente;
Independente: possibilidade de implantar sem necessidade de usar outros
componentes especficos;
Passvel de composio: fornecer acesso externo s informaes sobre si
prprio;
Implantvel: dever ser capaz de operar como uma entidade independente;
Documentado: componentes precisam ser completamente documentados de
maneira que os usurios possam decidir se eles atendem ou no s suas
necessidades.

03/09/2015

Problemas:
Confiabilidade de componentes: como saber se um componente
confivel? (falhas no documentadas, comportamente no
esperado, componente caixa-preta pode ser um cavalo de Tria);
Certificao de componentes: proposta de avaliadores
independentes devem certificar componentes para assegurar se
estes so confiveis (como isto funcionaria?certificador x
responsabilidades);
Previso de propriedade emergente: quando os componentes
so integrados, o sistema resultante pode gerar propriedades
indesejveis que limitam seu uso;
Compromisso de requisitos: no momento esse processo
intuitivo;

Questes:

Vantagens:
Reutilizao de cdigo, considerado um dos principais pontos deste
processo.
Grande reduo do tempo de desenvolvimento.
Aumento de produtividade.
Reduo de custo do projeto.
Facilidade de manuteno e evoluo.

Respostas das Questes:

1. Porque importante que os componentes sejam


baseados
em
um
modelo
padronizado
de
componente?

1. No s no modelo baseado em componentes, mas como em outros, a


padronizao importante para a legibilidade do cdigo. Componentes
que no seguem um padro costumam desorganizar e baixar a
produtividade dos programadores.

2. Porque muito difcil validar um componente reusvel


sem seu cdigo-fonte?

2. Sem o cdigo-fonte voc fica impossibilitado de saber como o


processamento funciona, desta forma, no h maneiras de evolu-lo, voc
fica a merc das atualizaes deste componente.

03/09/2015

Fabrcio Pedroso Nunes


Thalesson Bressan

Nesse modelo o(s) cliente(s) definem as funes do


sistema e tambm a sua prioridade, e conforme a
prioridade as funes so implementadas e entregues. As
demais
funes
so incrementadas
conforme
a
necessidade dos clientes.
Aps um incremento ser identificado, as funes deste
devero
ser
detalhadas
e
consequentemente
desenvolvidas. Durante o desenvolvimento poder haver
anlise de requisitos para os incrementos posteriores.
O incremento pode ser entregue ao cliente de forma
antecipada para que o mesmo utilize este incremento,
ajudando a compreender suas necessidades para
incrementos posteriores, os incrementos posteriores
assim que concludos so integrados aos j existentes
para que o sistema melhore sucessivamente.

O modelo de processo incremental aplica


sequncias lineares (como no modelo cascata),
nesse modelo o projeto cresce medida que o
tempo for avanando.
Cada uma das sequencias lineares gera um
incremento do software.
Esses incrementos so entregveis e prontos
para o cliente.

1.
2.
3.
4.
5.
6.
7.

Definir os requisitos iniciais;


Atribuir requisitos aos incrementos;
Projetar a arquitetura do sistema;
Desenvolver o incremento do sistema;
Validar Incremento;
Integrar incremento;
Validar sistema;

03/09/2015

Os clientes podem usar os incrementos iniciais


como "prottipos" e identificar requisitos para
incrementos posteriores;
O cliente no depende que o sistema fique
pronto por completo para poder obter utiliz-lo.
O primeiro incremento permite que eles possam
usar o software imediatamente;
Os servios mais importantes recebem a maioria
dos testes. Isso significa que a probabilidade de
os clientes encontrarem falhas de software nas
partes mais importantes do sistema menor;

Dificuldade de identificar requisitos comuns do


sistema que seja necessrio a todos os incrementos;
Usurios ficam relutantes em experimentar um novo
sistema incompleto. Portanto, difcil obter
feedbacks teis dos clientes;
Na abordagem incremental, no h especificao
completa do sistema at que o ltimo incremento
seja especificado, o que requer uma nova forma de
contrato na qual os grandes clientes, como agncias
governamentais, podem achar difcil de se adaptar;

03/09/2015

Prototipao
Fabricio Brenner

PrototipaoDefinio
Prototipao uma abordagem baseada em uma viso evolutiva do
desenvolvimento de software. Envolve a produo de verses iniciais
(prottipos) de um sistema futuro com o qual possvel realizar
verificaes e experimentos, com o intuito de avaliar algumas de suas
caractersticas antes que o sistema venha realmente a ser construdo,
de forma definitiva.

PrototipaoQuando Utilizar?
Quando os requisitos funcionais, e recursos no so identificados,
detalhadamente.
Quando desenvolvedor encontra-se inseguro sobre algum ponto
do software, entre eles, eficincia de um algoritmo, adaptabilidade
de um SO, forma como ocorrer a interao homem mquina,
entre outros.
Para projetar interface de usurio.
Para execues de alguns testes especficos.

PrototipaoComo utilizar?
Embora possa ser usada como processo isolado, a prototipao
mais comumente utilizada como tcnica passvel de ser implementada
em outros modelos de processos, como cascada. A prototipao
auxilia a ver com maior clareza, o que ser construdo.

PrototipaoParadigma

PrototipaoProblemas

Os interessados enxergam o que parece ser uma versao operacional do


software, ignorando que o proto tipo e mantido de forma nao organizada e
que, na pressa de fazer com que ele se torne operacional, nao se
considera a qualidade global do software, nem sua manutencao a longo
prazo
O engenheiro de software, com frequencia, assume compromissos de
implementacao para conseguir que o proto tipo entre em operacao
rapidamente. Um sistema operacional ou linguagem de programacao
inapropriados podem ser utilizados simplesmente porque se encontram a
disposicao e sao conhecidos.

PrototipaoConcluso
O segredo do paradigma de prototipao e definir as regras do jogo
logo no incio, isso significa que todos os envolvidos devem concordar
que o proto tipo e construdo para servir como um mecanismo para
definicao de requisitos, e portanto, sera descartado (pelo menos
parcialmente) e o software final eser arquitetado visando qualidade.

Prototipao
A Prototipao pode ser implementada nos demais processos, ou
somente deve ser utilizada como processo isolado? Se for o caso,
porque ela implementada nos demais processos?

Prototipao
Resposta:
Sim, ela pode, e principalmente usada como implementao dos
demais processos.
Ele implementada, pois sozinha pode-se tornar um processo muito
raso, mas utilizada em conjunto com um processo mais complexo,
como cascata por exemplo, ela se torna uma ferramenta muito til para
o entendimento funcional e de requisitos gerais do software, que as
vezes podem ser mal expostos pelo cliente, ou at desconhecidos pelo
mesmo.

PrototipaoReferncias
Wiki: https://pt.wikipedia.org/wiki/Prototipa%C3%A7%C3%A3o
Bibliografia: Engenharia de software - Roger S. Pressman.

03/09/2015

Engenharia de
Software
Prototipao
Clayton Tolotti, Daniel Matheus Kuhn

Prototipao:
Um prottipo uma verso inicial de
um sistema de software, que utilizada
para mostrar conceitos, experimentar
opes de projeto e, em geral, para
conhecer mais sobre os problemas e
suas possveis solues.

Prototipao:

Prototipao:

Modelos existentes

Modelos existentes

Prottipo em papel
Modelo executvel em PC retratando a
interface homem-mquina capacitando o
cliente a compreender a forma de interao
com o software;

Prottipo de trabalho que implemente um


subconjunto dos requisitos indicados
Programa existente (pacote) que permita
representar todas ou parte das funes
desejadas para o software a construir

03/09/2015

Prototipao:

Prototipao:

Benefcios:

Benefcios:

Equvocos entre usurio de software e


desenvolvedor so identificados.
Um sistema funcionando est disponvel nos
primeiros estgios de desenvolvimento.
O prottipo pode ser usado para treinamento
do usurio e testes de sistema.

Prototipao:

Melhoria da qualidade do projeto.


Melhoria na facilidade de manuteno.
Reduo no esforo de desenvolvimento.

Prototipao:

03/09/2015

Prototipao:

Prototipao:

Pergunta???

Resposta:

Em que ocasies aconselhasse o uso de


prototipao,e qual as vantagens que
proporciona ao projeto?

Em casos onde a comunicao pode no ser


clara entre usurio e desenvolvedor.
Onde h uma manuteno constante do
software.
Necessidade de entrega rpida do software
ao cliente.

03/09/2015

DESCRIO
RATIONAL UNIFIED PROCESS (RUP)

um modelo genrico moderno de processo de software que apresenta


o desenvolvimento de software como uma atividade de quatro fases.

Projetado utilizando trabalhos baseados em UML (linguagem grfica


utilizada no desenvolvimento orientado a objetos) e processos
associados, por ser um modelo hbrido, traz elementos de outros
modelos genricos de processo, utiliza-se de iteraes, com boas
prticas de especificao e projeto.

Engenharia de Software
Mateus Castro, Lucas Altmann, Paulo Henrique Tramontina.

VISO GERAL

RUP, no apresenta apenas uma perspectiva, podendo ser descrito por


trs:
Perspectiva esttica: concentra-se nas atividades do processo;
Perspectiva dinmica: foca nas fases, e o tempo utilizado por elas;
Perspectiva prtica: busca se basear em boas prticas da engenharia
de software.
As fases do RUP sao estreitamente relacionadas ao negcio, e no to
tecnicamente, como no modelo em cascata, no qual as fases so
equalizadas com as atividades do processo.
Possui a inovao de possuir fases/atividades (dinmicas) e
workflows(estticos) e tambm possui como parte do processo a
implantao de software em um ambiente do usurio.

ATIVIDADES
So quatro fases dinmicas e com metas.
1. Concepo:
Na fase inicial, se busca estabelecer o caso de negcio do sistema,
identificando/definindo todas as interaes do processo, analisando, se elas
iro contribuir para o sistema como um todo, do ponto de vista do negcio.

2. Elaborao:
Nessa fase, o problema principal deve ser compreendido, assim se
estabelecendo o framework da arquitetura, o plano do projeto e identificando
possveis riscos no projeto, tendo em vista obter um modelo de requisitos para
o sistema (conjunto de casos de uso da UML, descrio da arquitetura, plano
de desenvolvimento do software).

03/09/2015

ATIVIDADES
3. Construo:
Nesse ponto se envolve as prticas, de projeto, programao e
testes do sistema, tudo desenvolvido em paralelo e integrado, ao fim
dessa fase o sistema de software deve estar funcionando e com
documentao pronta para ser entregue aos usurios.

WORKFLOWS

Os workflows so estticos e so atividades tcnicas que no so


associadas a uma nica fase, mas podem ser utilizadas durante todo
o desenvolvimento para alcanar as metas especficas.

Embora, claro que alguns workflows se encaixam no


desenvolvimento inicial, como modelagem de negcios e requisitos,
enquanto outros em fases finais como teste, e implantao, no geral
em uma perspectiva prtica, todos os workflows so relacionados
como ativos durante toda a fase de desenvolvimento, sempre se
baseando em boas prticas da engenharia de software.

Teste - Processo iterativo que feito em conjunto com a


implementao, seguindo da concluso da mesma.
Implantao - Um release do produto e criado, distribudo aos
usurios e instalado em seu local de trabalho.

4. Transio:
Se concentra na transferncia do sistema da comunidade atual
do software(desenvolvimento) para a comunidade de funcionamento real
(usurios). Essa fase, geralmente vista como cara e problemtica, um
ponto positivo, pois planejada para se obter bons resultado para o
negcio e ao fim dela se ter um sistema documentando e operando
corretamente.

WORKFLOWS

So seis workflows centrais :

Modelagem de negcios
- Os processos de negcio so
modelados por meio de casos de uso de negcios.
Requisitos - Atores que interagem com o sistema so identificados
e casos de uso so desenvolvidos para modelar os requisitos do
sistema.
Anlise e projeto - Um modelo de projeto criado e documentado
com modelos de arquitetura, modelos de componentes, modelos de
objetos e modelos de sequncia.
Implementao - Os componentes do sistema so implementados
e estruturados em subsistemas de implementacao. A gerao de
cdigo a partir de modelos de projeto ajuda a acelerar esse
processo.

E trs de apoio :

Gerenciamento de configurao e Mudanas.


Gerenciamento de projeto - Incluir gerenciar as tecnologias,
ferramentas, pessoas, requisitos, riscos entre outros elementos
envolvidos no projeto do sistema.
Meio ambiente - Esse workflow tem como foco a disponibilizao
de ferramentas apropriadas para a equipe desenvolver o software.

03/09/2015

VANTAGENS E DESVANTAGENS

Pode ser considerado uma desvantagem o fato de ser um modelo


pesado, preferencialmente utilizado por equipes grandes
experientes.

Como a execuo das atividades se mostra um tanto iterativa, quanto


incremental tambm por se mostrar de difcil entendimento a uma
equipe sem experincia, portanto RUP no pode ser dito como um
modelo adequado para todos os tipos de desenvolvimento.

PERGUNTA

Na
perspectiva
prtica,
RUP
tem
um
desenvolvimento com varias atividades executadas
conjuntamente, tendo assim a necessidade de se
basear em boas prticas da engenharia de
software, quais poderiam ser elas?

VANTAGENS E DESVANTAGENS

Em contrapartida, essa mesma caracterstica de possuir


varias perspectivas, quando bem implementado, se torna
um modelo muito vantajoso, pois o processo no se
desenvolve estritamente amarrado a pontos especificos,
posibilitando uma boa visualizao e planejamento do
negcio como um todo, por consequncia se obtem
sucesso no sistema.

RESPOSTA
Desenvolver o software, planejando os passos com base nas
prioridades do cliente.
Gerenciar os requisitos, sempre documentando as solicitaes do
cliente e analisando seus impactos antes de efetua-las.
Modelar o software visualmente, atravs de modelos grficos da
UML, aproveitando assim o diferencial de se ter vises estticas e
dinmicas do software, utilizando arquiteturas baseadas em
componentes.
Utilizar sistema de gerenciamento de mudanas, procedimentos, e
tambm de configuraes, presando pela manuteno da qualidade
do software.