Palmas - TO

2011






































XXXXXXXXXXXXX XXXXXX XXXXXXX XXXXXXXXX











SISTEMA DE ENSINO PRESENCIAL CONECTADO
TECNOLOGIA EM ANLISE E DESENVOLVIMENTO DE SISTEMAS
ATIVIDADE INTERDISCIPLINAR - INDIVIDUAL


Palmas - TO
2011




































ATIVIDADE INTERDISCIPLINAR - INDIVIDUAL
Trabalho apresentado ao Curso de Tecnologia em
Anlise e Desenvolvimento de Sistemas da Universidade
Norte do Paran UNOPAR

Professores: Polyanna Pacheco Gomes
Luis Claudio Perini
Roberto Y. Nishimura
Anderson E. N. Gonalves
XXXXXXXXXXXXX XXXXXX XXXXXXX XXXXXXXXX

















SUMRIO
1 INTRODUO ..................................................................................................... 3
2 DOCUMENTAO DE CASO DE USO CONTROLAR USURIO ...................... 4
2.1 ATORES .............................................................................................................. 4
2.2 DIAGRAMA DE CASO DE USO CONTROLAR USURIO .................................. 4
2.3 PR-CONDIO ................................................................................................. 4
2.4 PS-CONDIO ................................................................................................. 4
2.5 FLUXO DE EVENTOS PRINCIPAL ..................................................................... 4
2.6 FLUXO SECUNDRIO ........................................................................................ 5
3 TCNICA DE MODELAGEM ENTIDADE E RELACIONAMENTO ...................... 6
3.1 ENTIDADE ........................................................................................................... 6
3.2 RELACIONAMENTOS ......................................................................................... 6
3.3 ATRIBUTOS ......................................................................................................... 7
3.3.1 Classificao dos Atributos ........................................................................... 7
3.3.1.1 Atributo Simples ............................................................................................ 7
3.3.1.2 Atributo Composto ........................................................................................ 7
3.3.1.3 Atributo Multivalorado ................................................................................... 7
3.3.1.4 Atributo Determinante ................................................................................... 7
3.4 RELACIONAMENTO ENTRE ENTIDADES E CARDINALIDADE ........................ 8
3.4.1 Tipos de Relacionamento ............................................................................. 8
3.4.1.1 Relacionamento um-para-um ........................................................................ 8
3.4.1.2 Relacionamento um-para-muitos .................................................................. 9
3.4.1.3 Relacionamento muitos-para-muitos ............................................................. 9
3.4.2 Cardinalidade ................................................................................................ 9
3.5 ADMINISTRADOR DE BANCO DE DADOS ...................................................... 10
3.6 MODELO CONCEITUAL DE DADOS ................................................................ 10
3.7 MODELO LGICO DE DADOS ......................................................................... 10
3.8 MODELO FSICO DE DADOS ........................................................................... 10
4 DESENVOLVIMENTO DE PROJETO EM VISUAL STUDIO ............................. 11
4.1 VISUAL STUDIO 2008 EXPRESS EDITION ...................................................... 11
4.2 MICROSOFT .NET FRAMEWORK 3.5 .............................................................. 11
4.3 CASO DE USO .................................................................................................. 12
4.4 TELAS NO VISUAL STUDIO ............................................................................. 13

4.4.1 Tela Principal do Programa Para Controle de Locadora ............................. 13
4.4.2 Tela da Funo Cadastrar DVD .................................................................. 14
5 MODELOS DE PROCESSOS DE SOFTWARE ................................................ 17
5.1 MODELOS GEIS ............................................................................................. 17
5.1.1 Extreme Programming ................................................................................ 17
5.1.2 SCRUM ....................................................................................................... 19
5.1.2.1 Papis e Responsabilidades no SCRUM .................................................... 20
5.1.2.2 O Fluxo do SCRUM .................................................................................... 20
5.1.2.3 Vantagens do SCRUM ................................................................................ 22
5.1.3 Dynamic Systems Development Method (DSDM) ...................................... 22
5.1.3.1 Princpios, Tcnicas e Fases do DSDM ...................................................... 23
5.1.4 Feature-Driven Development ...................................................................... 25
5.1.5 Lean Development ...................................................................................... 28
5.2 MODELOS EVOLUCIONRIOS ........................................................................ 31
5.2.1 Modelo de Montagem de Componentes ..................................................... 31
5.2.2 Espiral ......................................................................................................... 31
5.2.3 Modelo de Desenvolvimento Concorrente .................................................. 34
5.2.4 Modelo de Prototipagem ............................................................................. 34
5.2.5 Modelo Incremental ..................................................................................... 36
6 CONCLUSO .................................................................................................... 37
REFERNCIAS ......................................................................................................... 38

3
1 INTRODUO
Neste trabalho estarei abordando as documentaes do Caso de
Uso Controlar Usurio; as tcnicas de modelagem e relacionamento, atributos e
suas classificaes e a cardinalidade, bem como os conceitos de modelos de
processos de software, dando nfase aos modelos geis e revolucionrios.



4
2 DOCUMENTAO DE CASO DE USO CONTROLAR USURIO
Documentao relativa ao Caso de Uso Controlar Usurio, partindo
do cenrio hipottico de cadastrar usurios de uma biblioteca.

2.1 ATORES
Bibliotecrio.

2.2 DIAGRAMA DE CASO DE USO CONTROLAR USURIO
O Caso de Uso Controlar Usurio iniciado pelo bibliotecrio e tem
como objetivo cadastrar o usurio atravs dos campos e serem preenchidos.

2.3 PR-CONDIO
O bibliotecrio deve estar cadastrado no sistema;
O bibliotecrio deve estar logado no sistema;
Para que o cadastro do usurio seja efetuado no sistema
necessrio que os fluxos principais sejam preenchidos corretamente.

2.4 PS-CONDIO
O cadastro do usurio ser realizado.

2.5 FLUXO DE EVENTOS PRINCIPAL
1. Depois de o bibliotecrio efetuar logon, ser exibida uma tela
principal, contendo opes administrativas;
2. Ao escolher a opo administrativa Cadastrar Usurio ser
exibido o ambiente com as seguintes caractersticas:

5
Cadastro de Usurio:
Nome Completo*
Data de Nascimento*
Sexo (M, F)*
C.P.F.*
R.G.
rgo Expedidor*
Estado*
Cidade*
CEP*
Bairro*
Logradouro (Rua, Quadra, Conjunto, etc...)*
Nmero*
Telefone
[Fluxo Secundrio]
Botes:
Voltar
Salvar

2.6 FLUXO SECUNDRIO
Caso no seja preenchido algum campo obrigatrio, ser visualizado
um alerta, com os devidos campos a serem preenchidos.



6
3 TCNICA DE MODELAGEM ENTIDADE E RELACIONAMENTO
3.1 ENTIDADE
Entidade aquele objeto existente no mundo real, com uma
identificao distinta e significado prprio. So as coisas que existem no negcio, ou
ainda, que descrevem o negcio em si. Se algo existe e proporciona algum interesse
em manter dados sobre ele, isto caracteriza como uma Entidade do negcio.
Desta forma, podemos dizer que uma entidade ser uma tabela em
nosso banco de dados. Na verdade quando identificamos todas as entidades,
estaremos definindo quais sero as tabelas que teremos que criar em nosso banco
de dados.
Jos Fulano de Tal, CPF n 333.333.333-33, uma entidade, uma
vez que s pode existir uma nica pessoa com o mesmo nome e CPF.
Em um banco de dados de uma empresa, por exemplo, so
entidades: Cliente, Funcionrio, Departamento, fornecedor, etc. Cada entidade
representa objetos com as mesmas caractersticas. Um banco de dados, portanto,
compreende uma coleo de conjuntos de entidades do mesmo tipo.

3.2 RELACIONAMENTOS
Geralmente so os verbos, um conjunto de associaes entre as
entidades, acontecimento que liga duas entidades existentes no mundo real. O
relacionamento pode ser binrio ou ternrio e representado atravs de um losango
internamente nomeado e ligado a entidades atravs de linhas, conforme abaixo:







DEPARTAMENTO

PESSOA
LOTAO


7
3.3 ATRIBUTOS
So propriedades (caractersticas) que identificam as entidades.
Uma entidade representada por um conjunto de atributos. Nome, endereo,
telefone e cidade, por exemplo, so atributos da entidade Clientes. Enquanto que
salrio, cargo e departamento so atributos da entidade funcionrios.
3.3.1 Classificao dos Atributos
Os atributos podem ser simples, composto, multivalorado ou
determinante.
3.3.1.1 Atributo Simples
No possui qualquer caracterstica especial: A maioria dos atributos
ser simples. Quando um atributo no composto, recebe um valor nico como
nome, por exemplo, e no um atributo chave, ento ele ser atributo simples.
3.3.1.2 Atributo Composto
O seu contedo formado por vrios itens menores. Ex.: Endereo.
Seu contedo poder ser dividido em vrios outros atributos, como: Rua, Nmero,
Complemento, Bairro, Cep e Cidade.
3.3.1.3 Atributo Multivalorado
O seu contedo formado por mais de um valor. Ex.: Telefone.
Uma pessoa poder ter mais de um nmero de telefone. indicado colocando-se
um asterisco precedendo o nome do atributo.
3.3.1.4 Atributo Determinante
Identifica de forma nica uma entidade, ou seja, no pode haver
dados repetidos. indicado sublinhando-se o nome do atributo. Exemplo: CNPJ,
CPF, Cdigo do fornecedor, Nmero da matrcula, etc. Os atributos determinantes
sero as chaves primrias no banco de dados e seu uso tem implicaes na
normalizao de dados.

8
3.4 RELACIONAMENTO ENTRE ENTIDADES E CARDINALIDADE
Relacionamento entre entidades o tipo de ocorrncia existente
entre entidades. O smbolo que representa o relacionamento no modelo E-R um
losango com o nome do relacionamento escrito no seu interior, como no exemplo a
seguir:




Em um modelo de entidade e relacionamento, nem todas as
entidades sero relacionadas, h casos em que no h relacionamento entre
entidades, nestes casos consideramos como entidades isoladas.

3.4.1 Tipos de Relacionamento
Existem trs tipos de relacionamento entre entidades:
1:1 um-para-um
1:N um-para-muitos
N:N ou N:M muitos-para-muitos
3.4.1.1 Relacionamento um-para-um
O relacionamento um-para-um usado quando uma entidade A se
relaciona com uma entidade B e vice-versa.
Este relacionamento representado pelo sinal: 1:1
Veja o exemplo:









PERTENCE


Gerente

Seo
Chefia

1 1

9
3.4.1.2 Relacionamento um-para-muitos
O relacionamento um-para-muitos usado quando uma entidade A
pode se relacionar com uma ou mais entidades B.
Este relacionamento representado pelo sinal: 1:N
Veja o exemplo:




3.4.1.3 Relacionamento muitos-para-muitos
O relacionamento muitos-para-muitos usado quando vrias
entidades A se relacionam com vrias entidades B.
Este relacionamento representado pelo sinal: N:N ou N:M
Veja o exemplo:





3.4.2 Cardinalidade
A cardinalidade um conceito importante para ajudar a definir o
relacionamento, ela define o nmero de ocorrncias em um relacionamento.
Para determinar a cardinalidade, deve-se fazer a pergunta relativa
ao relacionamento em ambas as direes.
Um departamento possui quantos empregados?
- no mnimo 1 e no mximo N.
Um empregado est alocado em quantos departamentos?
- no mnimo em 1 e no mximo em 1
Somando-se as cardinalidades, definimos o resultado final do
relacionamento, ou seja, 1:N.


Seo


Funcionrio
Trabalha

1 N

Fornecedor


Produto
Fornece

N N

10
3.5 ADMINISTRADOR DE BANCO DE DADOS
o controlador central dos dados e dos programas que iro acessar
o banco de dados e responsvel pelos projetos lgicos e fsicos, bem como pela
modelagem de dados.

3.6 MODELO CONCEITUAL DE DADOS
A modelagem conceitual baseia-se no mais alto nvel e deve ser
usada para envolver o cliente. Os exemplos de modelagem de dados vistos pelo
modelo conceitual so mais fceis de compreender, j que no h limitaes ou
aplicao de tecnologia especfica. O diagrama de dados que deve ser construdo
aqui se chama Diagrama de Entidade e Relacionamento, onde devero ser
identificados todas as entidades e os relacionamentos entre elas. Este diagrama a
chave para a compreenso do modelo conceitual de dados.

3.7 MODELO LGICO DE DADOS
Descreve as estruturas que estaro contidas no banco de dados (as
entidades), de acordo com as possibilidades permitidas pela abordagem, mas sem
considerar nenhuma caracterstica de um SGBD ou atributo. Neste modelo onde
comeamos a organizar melhor os dados que sero armazenados, identificamos os
tipos dos atributos e algumas regras bsicas que podem ser implementadas dentro
do prprio banco de dados. Nesta fase recomendado que sejam aplicadas as
formas normais atravs do Modelo Relacional Normalizado evitando maiores
problemas na fase do modelo fsico.

3.8 MODELO FSICO DE DADOS
No modelo fsico fazemos a modelagem fsica do modelo de banco
de dados. Levam-se em conta as limitaes impostas pelo SGBD escolhido e deve
ser criado sempre com base nos exemplos de modelagem de dados produzidos no
item anterior, modelo lgico.

11
4 DESENVOLVIMENTO DE PROJETO EM VISUAL STUDIO
Neste projeto utilizei o Visual Studio 2008 Express Edition e o .NET
Framework 3.5. para fazer os implementos num Sistema de Locadora na tela de
Cadastro de DVD.

4.1 VISUAL STUDIO 2008 EXPRESS EDITION
Oferece suporte para a criao de aplicativos utilizando o .NET
Framework 3.5. o programa faz a verificao, destaque e autocorreo de sintaxe,
sugerindo e aplicando retificaes em mais de 200 erros comuns de programao.
Podem-se criar aplicativos com bancos de dados por meio do SQL
Server 2005 Express, bem como adicionar imagens e sons aos projetos com grande
facilidade. Visual Basic Express 2008 conta com ferramentas de controle para
navegadores web, possibilitando assim o desenvolvimento de aplicaes para a
internet. A arquitetura das informaes do software foi elaborada para tornar a tarefa
de programao mais gil. As ferramentas so dispostas por cones ou sub menus,
garantindo um nmero menor de cliques para a localizao de uma opo,
reduzindo o tempo e tornando o processo de desenvolvimento mais dinmico.
Todos os projetos ficam disponveis em abas, tornando o
desenvolvimento das aplicaes mais gil. O menu direito de cada opo apresenta
as propriedades das funes de maneira completa, sendo possvel editar e
configurar estas opes. A nova funo Split permite que os desenvolvedores
visualizem as funes Design e Source paralelamente, tornando a manuteno
da pgina mais simples (um recurso semelhante ao encontrado no Adobe
PhotoShop CS3). Com isto, clicando em qualquer campo pode visualizar as tags e o
posicionamento utilizado em projetos web.

4.2 MICROSOFT .NET FRAMEWORK 3.5
O .NET Framework 3.5 (previamente conhecido como WinFX) o
novo modelo de programao para Windows. Ele combina o poder do .NET

12
Framework 2.0 com novas tecnologias para construo de aplicativos, possibilitando
novas experincias, comunicao integrada e sem fronteiras, alm de habilidades
para vrios processos corporativos.

4.3 CASO DE USO






13
4.4 TELAS NO VISUAL STUDIO
4.4.1 Tela Principal do Programa Para Controle de Locadora


Clicando no menu Project, depois escolhendo Add Windows Form..., cai na
seleo de template, clica em Windows Form para a criao de nova tela no
programa.
No canto esquerdo na aba Toolbox, dentro de Menus & Toolbars clica-se em
MenuStrip arraste no local dos menus no programa, digite o nome do menu na
caixa Type Here e Enter, e assim por diante at concluir todos os menus
necessrios.
Clica-se em cima do menu para adicionar opes internas dele, digitando o
nome na caixa Type Here.

14
4.4.2 Tela da Funo Cadastrar DVD


atravs da tela Properties Window que podemos definir as
propriedades dos controles que esto na nossa aplicao em tempo de
desenvolvimento.
As propriedades definem as caractersticas do controle, e variam de
controle para controle. Vamos ver o exemplo da Label. Clique sobre o Label1 que foi
inserido no formulrio e d uma olhada na Properties Window:
Name define o nome do controle. Atravs do nome, podemos fazer referncia
a esse controle por meio do cdigo. sempre bom colocarmos trs caracteres
inicias ao nome para que possamos lembrar no cdigo que tipo de controle ele
. Exemplo: lblMensagem .
BorderStyle define a borda que o controle ter. Por padro, ele no tem borda,
mas podemos definir um tipo para ele, mudando essa propriedade.

15
ForeColor define a cor da letra da Label.
Text define a mensagem que a Label ter.
Visible define se a Label estar visvel no formulrio (True) ou invisvel (False).
Enabled define se a Label estar ativada (True) ou desativada (False).
Um controle desativado fica com a cor mais clara. mais til no
caso de botes, pois quando esto nesse estado no recebem cliques.
Existem tambm os eventos, que so aes s quais os controles
respondem em tempo de execuo.
Os controles podem responder a eventos como clique de boto,
passagem do ponteiro sobre o controle, e muitos outros. Existem eventos que so
especficos para alguns controles. Podem-se conferir os eventos disponveis de um
controle clicando sobre o mesmo, indo at a Properties Window e clicando no boto
Events, que possui a figura de um raio. A finalidade dos eventos pode ser deduzida
pelo nome, em alguns casos, e sempre h uma descrio do evento selecionado
abaixo da lista. ComboBox, selecionando este controle vemos que a janela de
propriedades se re-configura e podemos mudar suas configuraes:
Name o nome do controle, nome que usaremos para referenci-lo quando
estivermos codificando. Aqui chamei de lblNome.
AutoCompleteMode define a forma como o Text do ComboBox sugere um item
a ser selecionado.
AutoCompleteSource a lista onde temos os valores que sero usados para a
sugesto de auto preenchimento.
BackColor a cor de fundo do formulrio, ou a cor da parede, e ForeColor a
cor das fonte ou das palavras que aqui escreveremos.
DataSource se temos uma fonte de dados como uma DataTable, podemos
usar aqui.
DisplayMember se usarmos a propriedade DataSource, como sugerido acima
com um DataTable, teremos vrias colunas na tabela, ento definimos qual das
colunas ser a informao que o usurio ir enxergar.
ValueMember como a DisplayMember define qual informao o usurio ve,
aqui definimos qual informao til ao sistema, por exemplo o IdUsuario. Ou
seja, o valor que aquela informao representa para o sistema.
Dock define se queremos o componente literalmente grudado em um ou mais
cantos.

16
Enabled define se este ComboBox esta habilitado ou no, ou seja, se o
usurio pode us-lo ou no.
Location define a posio Top (distncia do controle em relao a margen
superior do formulrio) e a posio Left (distncia do controle em relao a
margen esquerda do formulrio)
Text a informao selecionada. Tambm pode ser usado como se fosse um
TextBox.
DropDownStyle modo como o combo funciona, sendo uma lista somente
leitura, lista com TextBox, ou somente um TextBox.
Items lista de valores que o ComboBox disponibiliza ao usurio para seleo.
Size define a largura e a altura do controle.


17
5 MODELOS DE PROCESSOS DE SOFTWARE
5.1 MODELOS GEIS
Os mtodos geis diferem largamente no que diz respeito forma
de serem gerenciados. Alguns mtodos so suplementados com guias para
direcionar o gerenciamento do projeto, mas nem todos so aplicveis.
Uma caracterstica comum dos processos geis a capacidade de
funcionar em ambientes muito exigentes que tem um grande nmero de incertezas e
flutuaes (mudanas) que podem vir de vrias fontes como: equipe em processo de
formao que ainda no trabalhou junto em outros projetos, requisitos volteis, baixo
conhecimento do domnio de negcio pela equipe, adoo de novas tecnologias,
novas ferramentas, mudanas muito bruscas e rpidas no ambiente de negcios das
empresas: novos concorrentes, novos produtos, novos modelos de negcio.

5.1.1 Extreme Programming
Extreme Programming (XP) uma metodologia de desenvolvimento
de software, nascida nos Estados Unidos ao final da dcada de 90. Vem fazendo
sucesso em diversos pases, por ajudar a criar sistemas de melhor qualidade, que
so produzidos em menos tempo e de forma mais econmica que o habitual. Tais
objetivos so alcanados atravs de um pequeno conjunto de valores, princpios e
prticas, que diferem substancialmente da forma tradicional de se desenvolver
software.
O sucesso e popularidade adquiridos por XP se devem
principalmente aos relatos de bons resultados obtidos em projetos, a motivao dos
profissionais envolvidos com XP e tambm devido a sua natureza simples e objetiva
por se basear em prticas que j provaram sua eficincia no cenrio do
desenvolvimento de software. Essas prticas tm como objetivo entregar
funcionalidades de forma rpida e eficiente ao cliente. Alm disso, XP foi criado
considerando que mudanas so inevitveis e que devem ser incorporadas
constantemente.
Um projeto XP atravessa algumas fases durante o seu ciclo de vida.

18
Essas fases so compostas de vrias tarefas que so executadas. Abaixo ser dada
uma explicao das principais fases de um projeto XP de modo a se ter uma ideia de
como o projeto flui ao longo do tempo.
Um projeto XP passa pelas seguintes fases: explorao, planejamento inicial,
iteraes do release, produo, manuteno e morte.
A fase de explorao anterior construo do sistema. Nela,
investigaes de possveis solues so feitas e verifica-se a viabilidade de tais
solues. Os programadores elaboram possveis arquiteturas e tentam visualizar
como o sistema funcionar considerando o ambiente tecnolgico (hardware, rede,
software, performance, trfego) onde o sistema ir rodar. Com isso, os
programadores e os clientes vo ganhando confiana, e quando eles possurem
estrias suficientes, j podero comear a construir o primeiro release do sistema.
A fase de planejamento inicial deve ser usada para que os clientes
concordem em uma data para o lanamento do primeiro release. O planejamento
funciona da seguinte forma: os programadores, juntamente com o cliente, definem
as estrias (use case simplificados) a serem implementadas e as descrevem em
cartes. Os programadores assinalam uma certe dificuldade para cada estria e,
baseados na sua velocidade de implementao, dizem quantas estrias podem
implementar em uma iterao. Depois, os clientes escolhem as estrias de maior
valor para serem implementadas na iterao isso chamado planejamento
iterao. O processo ento se repete at terminar as iteraes do release. O tempo
para cada iterao deve ser de uma a trs semanas e para cada release de dois a
quatro meses.
Na fase das iteraes do release so escritos os casos de teste
funcionais e de unidade. Os programadores vo seguindo mais ou menos o seguinte
fluxo de atividades na seguinte ordem (em cada iterao): escrita dos casos de
testes; projeto e refatoramento; codificao; realizao dos testes; e integrao. A
medida que esse fluxo vai sendo seguido, o sistema vai sendo construdo segundo
os princpios, valores e prticas. Depois de terminado o primeiro release, j se ter
uma ideia melhor das tecnologias e do domnio do problema de modo que as
iteraes podero ser mais curtas nos releases subsequentes e j se podem fazer
estimativas mais confiveis com o que se aprendeu das iteraes passadas.
A fase de manuteno pode ser considerada como uma
caracterstica inerente a um projeto XP. Em XP voc est simultaneamente

19
produzindo funcionalidades, mantendo o sistema existente rodando, incorporando
novas pessoas na equipe e melhorando o cdigo. Mecanismos como: refatoramento,
introduo de novas tecnologias, e introduo de novas ideias de arquitetura podem
ser utilizados em um projeto XP. importante ressaltar que a manuteno dada em
um sistema que j est em produo deve ser feita com muita cautela, pois uma
alterao errada pode paralisar o funcionamento do sistema resultando em prejuzos
para o cliente.
A fase morte corresponde ao trmino de um projeto XP. Existem
duas razes para se chegar ao final de um projeto, uma boa e outra ruim. A boa
razo quando o cliente j est satisfeito com o sistema existente e no enxerga
nenhuma funcionalidade que possa vir a ser implementada no futuro. A m razo
para a morte em XP seria a de o projeto ter se tornado economicamente invivel,
devido a dificuldades de adicionar funcionalidades a um custo baixo e devido a uma
alta taxa de erros.

5.1.2 SCRUM
SCRUM um processo interativo e incremental para o
desenvolvimento de projetos e utilizado desde 1990. O seu objetivo entregar o
mximo de valor de negcio no menor tempo.

O SCRUM tem como foco o PDCA (Plan, Do, Check, Act),
resultando na melhoria contnua. Inicialmente, ele foi concebido para utilizao em
projetos de software, que possuem algumas caractersticas, tais como:
So empricos: complexos, caticos, com detalhes pouco
conhecidos.
Difcil estimativa de tempo de durao das atividades.
Os requisitos mudam constantemente

No SCRUM, existe uma lista com os requisitos identificados pelo
cliente chamada de Product Backlog. Esta lista alimentada continuamente pelo
cliente em conjunto com o Product Owner (definio mais adiante) e reflete os
trabalhos pendentes do time.

20

5.1.2.1 Papis e Responsabilidades no SCRUM
No SCRUM, os papis dos participantes em projetos so muito bem
definidos. Existem basicamente trs papis no SCRUM: PO (Product Owner),
SCRUM Master e o prprio time. A seguir sero detalhadas as caractersticas de
cada participante:
Product Owner:
Criar e compartilhar uma viso projeto
Tomar decises sobre os itens do product backlog
Indicar e priorizar itens de backlog
Validar a entrega no final do Sprint
Time:
Estimar os itens do backlog
Desenvolver
Auto-organizados para entregar o que o Product Owner quer
SCRUM Master:
Contato direto com o Product Owner
Cuidar do time
Disseminar o SCRUM
Garantir comunicao
Evitar impedimentos

5.1.2.2 O Fluxo do SCRUM
O SCRUM possui um fluxo de trabalho muito bem definido. Muitos
autores afirmam que esse simples fluxo a essncia desse framework e deve ser
seguido o mais prximo possvel da sua realidade.




21

Sprint Planning 1
Estimativas da prxima entrega
O PO participa
Sprint Planning 2
Planejamento dentro da equipe
O PO no precisa participar
Daily SCRUM
Reunio diria, que engloba:
O que fiz desde a ltima daily SCRUM?
O que espero fazer at a prxima daily SCRUM?
O que est impedindo o progresso?
Sprint Review
Entrega dos artefatos planejados para este sprint. Importante:
Presume-se que antes foi definido que este sprint teria algo
pronto a ser apresentado
Sprint Retrospective
Aprendizado, lies aprendidas, discutir sucessos e erros do
sprint
TIMEBOX: Conceito do SCRUM que obriga que eventos sejam
realizados periodicamente


22
5.1.2.3 Vantagens do SCRUM
Processo bem definido e com time boxing
Formao de profissionais auto gerenciveis
Maior envolvimento do cliente
Entregas frequentes
Desenvolvimento da equipe (liderana e auto-organizao)
Pessoas responsveis pelos seus atos: na Daily SCRUM o time
indica como est; seus impedimentos e, com o suporte do
SCRUM Master, torna-se responsvel pela sua entrega acordada.
Disseminao da prtica de retrospectivas ou lies aprendidas: o
que erramos no ltimo sprint e o que podemos melhorar nos
prximos sprints?
Foco no cliente: O time entende que sua tarefa uma parte em
um Sprint e veem valor agregado no que esto fazendo
O cliente tambm se torna responsvel nas alteraes de escopo

5.1.3 Dynamic Systems Development Method (DSDM)
A DSDM fornece uma framework para uma abordagem interativa e
incremental de desenvolvimento de Sistemas de Informao (SI). Desenvolveu-se
nos anos 90 na Inglaterra e foi aplicado pela primeira vez em 1995. Nesta altura
(Novembro de 2005), o Manual DSDM encontra-se na 4 verso. Esta metodologia
foi desenvolvida por um consrcio de vendedores e peritos no campo dos Sistemas
de Informao, no qual partilharam e combinaram as suas melhores tcnicas.
Assim, a DSDM surge como uma extenso do RAD (Rapid Application
Development), focada em projetos de Sistemas de Informao caracterizados por
prazos e oramentos apertados.
A DSDM aborda os problemas que frequentemente ocorrem no
desenvolvimento de informao que se prendem essencialmente com a falta de
tempo, com oramentos mais apertados ou com outro tipo de razes para que o
projeto falhe, tal como a falta de envolvimento dos encarregados do projeto ou dos
utilizadores finais.

23
5.1.3.1 Princpios, Tcnicas e Fases do DSDM
As ideias principais do DSDM podem ser observadas no conjunto de
princpios que foram definidos para nortear o mtodo:
O envolvimento ativo do usurio imperativo.
O time deve ter o poder para tomar decises.
O foco na entrega frequente de produtos.
O encaixe ao propsito do negcio o critrio essencial para
a aceitao das entregas.
O desenvolvimento iterativo e incremental necessrio para
convergir com preciso s solues do negcio.
Todas as mudanas durante o desenvolvimento so
reversveis.
Requisitos so alinhados em um alto nvel.
O teste integrado por todo o ciclo de vida.
Uma abordagem colaborativa e cooperativa entre as partes
envolvidas essencial.
possvel notar com esses princpios que o cliente e o negcio so
os pontos essenciais do mtodo, enquanto que os aspectos tcnicos, como a
programao, so pouco abordados, o que fica ainda mais evidente na descrio do
processo. Esse enfoque e o fato do DSDM ser visto como um arcabouo faz com
que existam solues para mescl-lo a outros mtodos, sendo possvel a utilizao
em conjunto, por exemplo, com o XP ou o RUP, mas ainda mantendo os princpios
definidos no DSDM.
Alm desses princpios, existem algumas tcnicas principais que so
usadas durante a execuo de um projeto usando DSDM:
Time-boxes: definio de um perodo fixo para a execuo do
projeto, colocando at datas de entrega. Com isso, caso haja
alguma funcionalidade que no possa ser implementada
durante o perodo estipulado, ela deve ser feita aps o
desenvolvimento em si (antes da fase de ps-projeto).
MoSCoW: regra bsica para a priorizao de requisitos
durante o perodo de desenvolvimento. A ideia fundamental

24
priorizar e implementar os requisitos que sejam
considerados principais, deixando os menos importantes para
depois.
Modelagem: no deve ser uma atividade burocrtica, sendo
usada para prover um melhor entendimento do problema e da
soluo.
Prototipao: forma de verificar a adequao dos requisitos e
facilitar as discusses com o cliente. O prottipo criado deve
evoluir juntamente com o projeto.
Teste: essa atividade deve ser executada sistematicamente e
de forma contnua durante o projeto.
Gerncia de configurao: essencial, visto que os produtos
so entregues com uma grande frequncia.
Em relao ao processo do DSDM, existem 5 fases bsicas (como
mostra a figura abaixo), antecedidas por uma fase de pr-projeto e precedidas pelo
ps-projeto. No pr-projeto, tem-se como objetivo definir se o projeto deve ou no
ser implementado, observando aspectos gerenciais bsicos, como questes
monetrias e um plano para o estudo de viabilidade. O estudo de viabilidade
em si feito na etapa seguinte, em que se verifica se o DSDM a soluo mais
adequada, alm das atividades tradicionais em um estudo desse tipo. Na etapa
seguinte, de estudo do negcio, so observados os processos que sero afetados e
as suas necessidades de informao, definindo o escopo do projeto.













Modelo Funcional

Implementao

Projeto e Construo

Estudo de
Viabilidade



Estudo do
Negcio


Ps-Projeto Pr-Projeto

25
Posteriormente iniciado o desenvolvimento em si, que executado
de forma interativa em cada uma das trs fases seguintes: modelagem funcional,
projeto e construo e implementao. Como a transio entre essas fases algo
bastante complicado, a deciso de quando e como isso deve acontecer acaba sendo
feita de projeto a projeto, podendo haver sobreposio e mescla entre elas. Alm
disso, a qualquer momento pode haver um refinamento do projeto, fazendo com que
se volte a fases anteriores para corrigir problemas, solucionar dvidas, etc.
Na primeira fase de desenvolvimento, que cuida do modelo
funcional, os requisitos (funcionais e no funcionais) so obtidos, montando uma
lista de prioridades e colocando-os no prottipo, documentando a maioria dessa
forma ao invs da textual. No entanto, o foco apenas a viso bsica dos requisitos,
uma vez que os detalhes deles sero desenvolvidos na fase de projeto e construo,
em que o objetivo obter o sistema testado. Na fase de feita a transio do sistema
do ambiente de desenvolvimento para o operacional, cuidando do treinamento e
outras tarefas que sejam necessrias.
Ao finalizar as etapas de desenvolvimento com um resultado
satisfatrio na realizao dos requisitos, chega-se a fase de ps-projeto. Nela feita
a manuteno do sistema, realizando as tarefas de alterao praticamente da
mesma forma que foi feito o desenvolvimento.

5.1.4 Feature-Driven Development
Feature-Driven Development (FDD) uma metodologia gil para o
processo de engenharia de software, que foi elaborada com foco na entrega
frequente de software funcionando para os clientes e na utilizao de boas prticas
durante o ciclo de seu desenvolvimento.
Uma caracterstica marcante da FDD o fato dela favorecer
fortemente o envolvimento de clientes (interno ou externo) ao processo de
planejamento e desenvolvimento do software.
Feature-Driven Development (FDD) um processo de
desenvolvimento de software iterativo e incremental. Diferentemente de outras
metodologias, a FDD no extremamente focada na programao ou no modelo,
mas sim utiliza o bom senso para abstrair o melhor dos dois mundos.

26
O ciclo de vida da FDD composto de 05 (cinco) prticas. So
elas:
Desenvolver um modelo abrangente: este processo abrange todo o
projeto, o que significa que ele ser executado uma nica vez no projeto.
Formar o time de modelagem: este time normalmente composto
por especialistas de negcio e programadores, sendo facilitados por um arquiteto
com experincia em modelagem.
Conduzir o Domain Walkthrough (Estudo dirigido sobre o domnio):
os especialistas de negcio apresentaro ao restante da equipe uma viso do
produto. Aps isso, realizaro apresentaes focadas em pequenas partes do
negcio.
Estudar documentao: Dependendo da complexidade da rea de
negcio apresentada, a equipe pode solicitar um intervalo para estudar a
documentao fornecida pelo especialista de negcio.
Desenvolver modelos de pequenos grupos: aps cada
apresentao (ou estudo), a equipe dividida em pequenos grupos, que elaboraro
uma proposta de modelo (sem detalhamento) para aquela parte especfica do
negcio que foi apresentada.
Desenvolver o modelo da equipe: as propostas so apresentadas e
uma delas, ou uma combinao delas, escolhida por consenso para ser o modelo
para aquela parte do negcio apresentada.
Refinar o modelo abrangente: o modelo escolhido incluso no
modelo abrangente do produto. Este modelo abrangente o resultado da juno de
todos os modelos escolhidos para cada parte do negcio apresentada.
Escrever notas: notas e observaes so includas no modelo
abrangente. As atividades vo se repetindo at que tenhamos um modelo
abrangente que cubra todas as partes de negcio previstas para o produto(ou
release).
Construir a lista de funcionalidades: este processo abrange todo o
projeto, o que significa que ele ser executado uma nica vez no projeto.
Formar o time da lista de funcionalidades: normalmente, este time
composto unicamente pelos programadores chefes que participaram do processo
anterior.
Construir a lista de funcionalidades: as partes do produto, que

27
foram identificadas e modeladas no processo anterior, so aqui identificadas como
reas de negcio. Dentro de cada rea de negcio, o time deve conseguir identificar
as atividades de negcio daquela rea especfica e, dentro destas atividades, as
funcionalidades que a compem.
Planejar por funcionalidades: este processo abrange todo o projeto,
o que significa que ele ser executado uma nica vez no projeto.
Formar o time de planejamento: normalmente este time composto
pelo gerente de projeto, gerente de desenvolvimento e programadores-chefes.
Determinar a sequncia do desenvolvimento: o time determina a
sequncia do desenvolvimento baseando-se nas dependncias entre elas, na carga
de trabalho da equipe de desenvolvimento e tambm na complexidade das
funcionalidades a serem implementadas.
Atribuir atividades de negcio aos programadores-chefes: cada
programador-chefe fica responsvel por um conjunto de atividades de negcio. Ele
ser o programador-chefe de todas as funcionalidades que compem suas
atividades.
Atribuir classes aos desenvolvedores: cada classe passar a ter
um dono. Este dono, que um programador, ser o responsvel por qualquer
manuteno necessria naquela classe. As classes so distribudas pelo time
levando em considerao a experincia, carga e sequncia de trabalho de cada
desenvolvedor.
Detalhar por funcionalidade: este processo ser executado uma
vez para cada funcionalidade.
Formar a(s) equipe(s) de funcionalidades: sabendo quais as
classes que sero envolvidas no desenvolvimento de determinada funcionalidade, o
programador-chefe convoca os desenvolvedores responsveis por cada classe
envolvida para fazer parte da equipe.
Conduzir Domain Walkthrough (Estudo dirigido sobre o domnio):
dependendo do nvel de complexidade da funcionalidade e de quo clara ela est
para a equipe, o programador-chefe pode convocar um especialista de negcio para
promover uma apresentao detalhada daquela funcionalidade para a equipe.
Estudar documentao relacionada: ainda dependendo do nvel de
entendimento do time, pode ser reservado um perodo para ser estudada
documentao de negcio e anotaes relacionadas quela funcionalidade.

28
Desenvolver diagrama(s) de sequncia: o time desenvolve o(s)
diagrama(s) de sequncia relacionado(s) quela funcionalidade.
Refinar o modelo abrangente: j com um maior entendimento do
negcio, o time se sente seguro em refinar o modelo abrangente, incluindo mtodos
e atributos nas classes envolvidas no desenvolvimento da funcionalidade.
Escrever prlogo de mtodos e classes: Com as informaes
geradas pelo(s) diagrama(s) de sequncia, cada programador responsvel por
criar os prlogos de suas classes. Isto inclui cabealhos de mtodos com tipagem de
parmetros, atributos e outros. Vale lembrar que apenas os prlogos so criados
aqui, nada de implementao deve ser realizado.
Inspeo de design: o programador-chefe da funcionalidade deve
convidar algum outro membro do time do projeto para avaliar o que foi feito em sua
classe durante este processo.
Desenvolver por funcionalidade: este processo ser executado
uma vez para cada funcionalidade.
Implementar classes e mtodos: cada desenvolvedor implementa
suas classes e mtodos de acordo com a viso abrangente e detalhamento
realizado nos processos anteriores.
Inspecionar cdigo: cada desenvolvedor deve convidar algum outro
membro do time (da funcionalidade ou do projeto) para avaliar o que foi feito em sua
classe durante este processo.
Teste unitrio: cada desenvolvedor responsvel por executar os
testes de unidade nos mtodos de suas classes para garantir o alcance das
necessidades do negcio.
Promover a build: estando a classe inspecionada e testada, ela
ento pode ser promovida a build.

5.1.5 Lean Development
O Lean Development (LD) um mtodo baseado na viso da
produo Lean, da rea de manufatura e processos. Essa forma de produo
seria o estgio seguinte produo em massa, pregando a customizao em
massa, com a ambio de diminuir consideravelmente os gastos: metade do esforo,

29
o espao, do investimento em ferramentas, etc. No mbito do desenvolvimento de
software essas propostas seguem a mesma linha, filosofia e ambio.
Dessa forma, o LD no se preocupa em pregar prticas de
desenvolvimento ao contrrio do XP , j que seu foco no ponto de vista
estratgico, direcionado primordialmente ao nvel gerencial da organizao e no ao
nvel de instrumentao, no caso, os desenvolvedores.
A ideia geral dessa forma da produo Lean a observao dos
problemas da mudana de requisitos sob uma nova perspectiva: as decises
do cliente devem ser adiadas ao mximo, deixando para que elas sejam feitas
quando houver um maior conhecimento do assunto. E quando as decises forem
feitas, a implementao deve ser rpida, evitando que as condies externas afetem
uma funcionalidade antes de ela ser entregue.
Por ser uma forma de produo passada para a rea de Engenharia
de Software, necessrio que ocorra uma adaptao adequada de seus princpios
com a preocupao de manter a filosofia para esse outro ambiente de produo.
Dessa forma, a seguir so apresentados esses princpios, derivados para a viso do
software segundo Poppendieck:
Eliminar o desperdcio: ao observar o processo produtivo por
inteiro.
Amplificar o aprendizado: aumentando a retroalimentao,
atravs de ciclos rpidos e iterativos.
Atrasar o compromisso: deixar suas opes disponveis pelo
maior tempo possvel, para que as decises sejam feitas com o
mximo de conhecimento sobre o assunto.
Entregar rapidamente: as entregas devem estar alinhadas com
os anseios do cliente em um determinado momento de tempo. A
demora em entregar pode fazer com que o resultado no seja
mais o que o cliente precise ou deseje.
D poder ao time: a equipe de desenvolvimento deve ter o poder
de decidir, algo necessrio devido rapidez da implementao.
Construa com integridade: o software deve satisfazer ao cliente
realizando o que ele deseja (integridade percebida), ter um
ncleo coeso (integridade conceitual) e manter-se til com o
tempo.

30
Veja o todo: a viso dos implementadores deve ser do produto
como um todo e no apenas de uma parte ou subsistema.
Uma adaptao mais prtica e voltada para implementao desses
princpios para a Engenharia de software feita por Charette apud Highsmith. Dessa
forma, foi interpretada a produo Lean para criar o mtodo de desenvolvimento
de software conhecido por LD. A seguir, colocado o conjunto de princpios que
regem esse mtodo:
1. A satisfao do cliente a maior prioridade.
2. Sempre provenha o melhor valor para o dinheiro.
3. Sucesso depende na participao ativa do cliente.
4. Todo projeto LD um esforo do time.
5. Tudo pode ser mudado.
6. As solues devem ser de domnio e no pontuais.
7. Complete, no construa.
8. 80% da soluo hoje melhor do que 100% da soluo amanh.
9. Minimalismo essencial.
10. As necessidades determinam a tecnologia.
11. O crescimento do produto o crescimento de caractersticas, e
no de tamanho.
12. Nunca force o LD para fora de seus limites.
Em relao ao processo de desenvolvimento, so definidas trs
etapas principais: incio, o estado de crescimento regular (steady-state), e transio
e renovao. No incio o foco anlise de valor ao cliente, o estudo do negcio e
projeto de viabilidade, com isso feita uma anlise de riscos e outras etapas de
escopo gerencial.
Na etapa de estado de crescimento regular o objetivo realizar o
desenvolvimento de forma iterativa e incremental em perodos fechados (time-boxes)
de 90 dias no mximo. Cada iterao realiza um pouco das fases tradicionais de
desenvolvimento (anlise, projeto, implementao e testes), integrando
continuamente o software. A grande diferena em relao aos outros mtodos a
utilizao em larga escala de templates (solues de domnio) para aumentar a
velocidade de produo e sua reutilizao (condizente com o princpio 7).
Na etapa de transio feita a entrega, focando na documentao
e treinamento, pensando ainda na evoluo do sistema.

31
5.2 MODELOS EVOLUCIONRIOS
5.2.1 Modelo de Montagem de Componentes
Desenvolvimento baseado em componentes ou component-based
development (CBD) tambm conhecido como component-based software
engineering (CBSE) ou simplesmente componente de software, no define o que
um componente e restringe-se a dizer que o modelo de desenvolvimento baseado
em componentes utiliza paradigma de orientao a objetos baseando-se em uma
classe como cdigo reutilizvel, ou seja, o componente. Em orientao a objetos
uma classe encapsula dados e algoritmos e este ltimo tambm pode ser usado
para manipular os dados.
Caracteriza-se esse modelo como incorporador do modelo espiral
com uma abordagem iterativa para a criao de software. Atravs desta abordagem
uma biblioteca de classes construda com as classes identificadas no
desenvolvimento do software e a partir de ento toda iterao da espiral dever
verificar o contedo da biblioteca que pode ser reutilizado ou identificar se novas
classes devem ser inseridas na biblioteca para posterior reuso.
Segue os seguintes passos implantados com uma abordagem evolucionria:
1. Pesquisa e avaliao de componentes disponveis para o
domnio em questo.
2. Consideraes sobre a integrao de componentes.
3. Projeto de arquitetura de software.
4. Integrao dos componentes arquitetura.
5. Testes para garantir a funcionalidade adequada.

5.2.2 Espiral
Neste modelo o projeto atacado como uma srie de pequenos
ciclos, cada um finalizando uma verso de um software executvel.
O modelo em espiral foi proposto por Boehm em 1988 como forma
de integrar os diversos modelos existentes poca, eliminando suas dificuldades e
explorando seus pontos fortes. Este modelo foi desenvolvido para abranger as

32
melhores caractersticas tanto do ciclo de vida clssico como da prototipao,
acrescentando, ao mesmo tempo, um novo elemento - a anlise de riscos - que falta
a esses paradigmas.
Entretanto a integrao no se d atravs da simples incorporao
de caractersticas dos modelos anteriores. O modelo em espiral assume que o
processo de desenvolvimento ocorre em ciclos, cada um contendo fases de
avaliao e planejamento, onde a opo de abordagem para a prxima fase (ou
ciclo) determinada. Estas opes podem acomodar caractersticas de outros
modelos.

O modelo original em espiral organiza o desenvolvimento como um
processo iterativo em que vrios conjuntos de quatro fases se sucedem at se obter
o sistema final. Um ciclo se inicia com a determinao de
Objetivos, alternativas e restries (primeira tarefa) onde ocorre o
comprometimento dos envolvidos e o estabelecimento de uma estratgia para
alcanar os objetivos. Na segunda tarefa, anlise e avaliao de alternativas,
identificao e soluo de riscos, executa-se uma anlise de risco. Prototipao
uma boa ferramenta para tratar riscos. Se o risco for considerado inaceitvel, pode
parar o projeto. Na terceira tarefa ocorre o desenvolvimento do produto. Neste
quadrante pode-se considerar o modelo cascata. Na quarta tarefa o produto
avaliado e se prepara para iniciar um novo ciclo.
Variaes do modelo espiral consideram entre trs e seis tarefas ou
setores da espiral, que podem ser:

33
Comunicao com o cliente;
Planejamento;
Anlise de risco;
Engenharia;
Construo e liberao;
Avaliao do cliente.
O modelo espiral atualmente a abordagem mais realstica para
desenvolvimento de software em grande escala, e usa uma abordagem que capacita
a empresa que presta o servio, e o cliente a entender e reagir aos riscos em cada
etapa evolutiva. Este tipo de modelo exige considervel experincia na
determinao de riscos e depende dessa experincia para ter sucesso, pode ser
difcil convencer os clientes que uma abordagem evolutiva controlvel.
Vantagens deste modelo:
O modelo em espiral permite que ao longo de cada iterao
se obtenham verses do sistema cada vez mais completas,
recorrendo prototipagem para reduzir os riscos.
Este tipo de modelo permite a abordagem do refinamento
seguido pelo modelo em cascata, mas que incorpora um
enquadramento iterativo que reflete, de uma forma bastante
realstica, o processo de desenvolvimento.
Desvantagens:
Pode ser difcil convencer grandes clientes (particularmente
em situaes de contrato) de que a abordagem evolutiva
controlvel.
A abordagem deste tipo de modelo exige considervel
experincia na avaliao dos riscos e baseia-se nessa
experincia para o sucesso. Se um grande risco no for
descoberto, podero ocorrer problemas.
Este tipo de modelo relativamente novo e no tem sido
amplamente usado.
importante ter em conta que podem existir diferenas entre
o prottipo e o sistema final. O prottipo pode no cumprir os
requisitos de desempenho, pode ser incompleto, e pode

34
refletir somente alguns aspectos do sistema a ser
desenvolvido.
O modelo em espiral pode levar ao desenvolvimento em
paralelo de mltiplas partes do projeto, cada uma sendo
abordada de modo diferenciado, por isso necessrio o uso
de tcnicas especficas para estimar e sincronizar
cronogramas, bem como para determinar os indicadores de
custo e progresso mais adequados.

5.2.3 Modelo de Desenvolvimento Concorrente
representado como uma srie de grandes atividades tcnicas,
tarefas e seus estados associados.
Define uma srie de eventos que podem disparar transies de um estado para
outro, para cada uma das atividades de ES.
utilizado para o desenvolvimento de aplicaes Cliente/Servidor.
Pode ser aplicado a qualquer tipo de desenvolvimento de software e
fornece uma viso exata de como est o estado do projeto.

5.2.4 Modelo de Prototipagem
O modelo de desenvolvimento baseado na prototipao procura
suprir duas grandes limitaes do modelo cascata. De acordo com Jalote a idia
bsica deste modelo que ao invs de manter inalterados os requisitos durante o
projeto e codificao, um prottipo desenvolvido para ajudar no entendimento dos
requisitos. Este desenvolvimento passa por um projeto, codificao e teste, sendo
que cada uma destas fases no executada formalmente. Usando assim os
prottipos o cliente pode entender melhor os requisitos do sistema.



35
A sequncia de eventos deste modelo esta exibido na figura abaixo:



O prottipo desenvolvido com uma verso inicial do documento de
especificao dos requisitos. Depois do prottipo estar pronto o cliente o utiliza e
baseado na sua avaliao do cliente fornecido ao as impresses do que precisa
ser alterado, o que esta faltando e o que no preciso. O prottipo ento
modificado incorporando as sugestes de mudana e o cliente usa o prottipo
novamente repetindo o processo at que o mesmo seja vlido em termos de custo e
tempo. No final os requisitos iniciais so alterados para produzir a especificao final
dos requisitos.
Segundo Pressman e Jalote este modelo pode trazer os
seguintes benefcios:
O modelo interessante para alguns sistemas de grande
porte nos quais representem certo grau de dificuldade para
exprimir rigorosamente os requisitos
possvel obter uma verso do que ser o sistema com um
pequeno investimento inicial
A experincia de produzir o prottipo pode reduzir o custo das
fases posteriores
A construo do prottipo pode demonstrar a viabilidade do
sistema.
Questes a serem consideradas quanto utilizao do modelo:
A Prototipao deve ser utilizada apenas quando os usurios

36
podem participar ativamente no projeto
No descuidar de uma boa anlise que deve ser conduzida
durante todo o processo de prototipao
Esclarecer aos usurios que o desempenho apresentado pelo
prottipo no necessariamente ser o mesmo do sistema final
Evitar que o sistema final seja um prottipo em que foram
implementados todos os requisitos especificados, pois se
corre o risco de ter-se um sistema mal implementado, uma
vez que as tcnicas utilizadas para desenvolver um prottipo
so diferentes daquelas utilizadas na implementao de um
sistema (relaxamento de regras de negcio, manipulao de
excees etc.)
Durante a etapa de prototipao, documentar todos os pontos
levantados e implementados no prottipo, que no constavam
dos requisitos iniciais, para inclu-los na documentao final.

5.2.5 Modelo Incremental
Combina elementos do modelo cascata sendo aplicado de maneira
interativa. O modelo de processo incremental interativo igual prototipagem, mais
diferente a prototipagem o incremental tem como objetivo apresentar um produto
operacional a cada incremento realizado. Esse modelo muito til quando a
empresa no possui mo de obra disponvel no momento para uma implementao
completa, dentro do prazo estipulado.


37
6 CONCLUSO
Atravs do estudo de um Caso de Uso, temos a oportunidade de
visualizar graficamente elementos do mundo real, observando a documentao
necessria para compreenso do trabalho a ser realizado.
A utilizao do modelo Entidade Relacionamento de suma
importncia para representao grfica daquilo que queremos representar facilitando
a compreenso daqueles envolvidos na construo do projeto.
No existe um processo correto ou incorreto, como no existe um
modelo de desenvolvimento que seja a panaceia universal para o problema do
desenvolvimento de software. Dependendo de sua aplicao, ambiente e objetivo, a
utilizao de um processo ou modelo especfico pode ser vantajoso ou no. Cabe a
cada organizao avaliar o seu problema com cuidado e usar os modelos
apresentados como um guia para o desenvolvimento do seu prprio processo de
desenvolvimento, onde o objetivo principal um resultado que demonstre qualidade,
tanto no andamento, quanto e principalmente no seu resultado final.















38
REFERNCIAS
PERINI, Luis Cludio. Engenharia de software. So Paulo. Editora Pearson, 2009.
TANAKA, Simone Sawasaki. Anlise de Sistemas I. So Paulo. Editora Pearson,
2009.
http://www.slideshare.net/ricardofrdrc/trgettrust-metodologias-geis-modelos-geis-
para-anlise-de-requisitos-de-software

http://pt.wikipedia.org/wiki/Desenvolvimento_gil_de_software#M.C3.A9todos_.C3.A
1geis_e_o_gerenciamento_de_projeto

http://improveit.com.br/xp

http://qualiblog.wordpress.com/2009/10/08/uma-introducao-ao-scrum/

http://www.macoratti.net/proc_sw1.htm

http://blog.hallanmedeiros.com/2010/03/29/documentacao-de-casos-de-uso/