SUMRIO

1INTRODUO............................................................................................................3
2Atividade PROSTA......................................................................................................4
3CONCLUSO............................................................................................................23
4REFERNCIA...........................................................................................................24

1 INTRODUO

Neste trabalho vamos explorar um caso de uso de controle de

matricula, tambm as tcnicas de modelagem Entidade Relacionamento, explicando
sobre

entidades,

relacionamentos,

atributos

cardinalidade,

tambm

administrador de banco de dados, modelos conceitual de dados, modelo lgico de

dados e o modelo fsico de dados.
Elaborar um projeto que pode usar e seus componentes principais
neste caso de uso, sobre os modelos geis e evolucionrios, alguns como:
Extremem Programming (XP), Scrum, Dynamic Systems Development Method e
Feature Driven Development alem de outros.
Poderemos assim aprender um pouco mais sobre todos os assuntos
aqui mencionados, ganhando assim conhecimento e capacitao para prosseguir
em nosso curso de Analise e Desenvolvimento de Sistemas. Teremos oportunidade
de conhecer mais profundamente como funciona tudo passo, ser um grande
aprendizado para todos ns.

2 ATIVIDADE PROSTA
1 - Considere

um

Caso

de

Uso

Controlar

Usurio,

cujo

objetivo cadastrar o usurio da biblioteca. Partindo desse cenrio, elabore a

documentao do Caso de Uso.
Caso de uso: Controlar Cadastro do Aluno
Descrio:

Registrar Aluno no sistema

Ator: Secretaria e Aluno

Cenrio principal
1 passo - Secretaria solicita cadastro de controle de matricula
2 passo - Sistema exibe pagina do controle de matricula
3 passo - Secretaria seleciona e escolhe a opo de incluso
4 passo - Sistema apresenta cdigo de matrcula
5 passo - Aluno informa seu CPF
6 passo - Sistema valida CPF digitado
7 passo - Aluno fornece seus demais dados
8 passo - Sistema solicita Escola do Aluno
9 passo - Sistema verifica se atributos foram digitados
10 passo - Sistema atribui uma data do cadastro do Aluno
11 passo - Secretaria confirma cadastro
12 passo - Sistema cria uma instancia da matricula
13 passo - Sistema manda uma mensagem confirmando o cadastro
14 passo - Sistema encerra o caso de uso
Cenrio Alternativo
1 passo - Sistema permite alterar
2 passo - Secretaria escolhe opo de altera
3 passo - Aluno informa os dados que devem ser alterados
4 passo Secretaria confirma alterao
5 passo - Sistema atualizao dos dados
6 passo - Sistema informa com uma mensagem a confirmao da alterao
7 passo - Sistema Finaliza uso case (sistema volta ao passo 14)

2
Relacionamento,

Considerando

explique

com

tcnica

suas

palavras

de
o

Modelagem
que

so

Entidade
Entidades,

Relacionamentos, Atributos, Cardinalidade, Administrador de banco de dados,

modelo conceitual de dados, modelo lgico de dados e modelo fsico de dados.
Entidades: So conjuntos de informaes importantes para quem
quer representar ou armazenar de maneira concreta ou abstrata. Na geralmente so
encontradas em uma descrio textual na lngua portuguesa como substantivos.
Para cada elemento do conjunto dado nome de instncia ou ocorrncia.
Relacionamento: uma associao entre os elementos que tm
uma importncia quando associados entre si, e podem ser encontrada em uma
descrio textual na lngua portuguesa como verbos. Assim o Relacionamento um
acontecimento que liga duas coisas ou objetos existentes no mundo real. A cada
dado nome de ocorrncia ou relacionamento.
Atributo: a caracterstica, propriedade ou prprio dado de uma
entidade ou at de um relacionamento. Toda entidade possui propriedades ou
qualidades que so descritas por atributos e valores, podendo ser associadas a
cada ocorrncia de uma entidade ou relacionamento.
Cardinalidade:

um

conceito

importante

para

definir

relacionamento, ela define o nmero de ocorrncias em um relacionamento. Para

determinar a cardinalidade, deve fazer algumas perguntas direcionada ao
relacionamento em ambas as direes.
Administrador de Banco de Dados: o profissional responsvel
pela manuteno e gerenciamento de um banco de dados. Tambm responsvel
pela criao de backups, serve para recuperar dados caso ocorram problemas ou
erros no hardware. Alm de guardar os arquivos, preserva em boas condies dos
mesmos, pela segurana dos dados, acessibilidade, desempenho das mquinas,
processos e no desenvolvimento de testes de todo o planejamento de banco de
dados. Ou seja, busca a melhor maneira de organizar, selecionar e armazenar todos
os dados, avaliando todas as partes tcnicas e pessoais que iro ser utiliz-los.

responsvel em altera e testa todos os procedimentos, antes de abrir acesso dos

dados aos seus usurios, bem como gerenciar o direito de acesso de cada setor e
pessoa.
Modelo Conceitual de Dados: Concentra-se no mais alto nvel de
abstrao e no leva em conta o banco de dados em si, mas a forma como as
estruturas sero criadas para armazenar os dados. a forma mais natural dos fatos
que esto mais prximas da realidade do ambiente do cliente. O Cliente deve
fornecer todos os dados que dar suporte construo de todo o modelo.
Modelagem de dados uma tcnica usada para a especificao das regras de
negcios e as estruturas de dados de um banco de dados, ela faz parte do ciclo de
desenvolvimento de um sistema de informao de importncia para o bom resultado
do projeto. Modelar dados consiste em desenhar o sistema de informaes com
aplicaes tericas e prticas, visando construir um modelo de dados consistente
aplicvel em qualquer SGBD moderno.
Modelo Conceitual de Dados: Deve ser usada para envolver o
cliente.

O diagrama de dados deve ser construdo com base no diagrama de

Entidade e Relacionamento, onde devem ser identificados todas as entidades e os

relacionamentos existentes. Este diagrama a chave para a compreenso do
modelo.
Modelo lgico de Dados: Este tem algumas limitaes e
implementa recursos como adequao de padro e nomenclatura. Define as chaves
primrias e estrangeiras e deve ser criado levando em conta os exemplos de
modelagem de dados criados no modelo conceitual.
Modelo fsico de Dados: No modelo fsico feita a modelagem
fsica do modelo de banco de dados. Leva-se em conta as limitaes impostas pelo
SGBD escolhido e deve ser criado sempre com base nos exemplos de modelagem
de dados produzidos no modelo lgico.
3 Tendo se feita opo para desenvolvimento na linguagem C#,
faa a escolha de que tipo de projeto (cenrio) ser criado e em que verso da .Net

Framework e do Visual Studio sero realizadas as implementaes, bem como

fundamentar sua escolha tambm devem ser relacionados quais os principais
componentes que sero, bem como descrever sua funcionalidade e explicar em que
em que situao ser explicado.
Vamos usar o projeto Windows Forms que uma parte importante
do Visual Basic a capacidade de criar aplicativos Windows Forms executados nos
computadores dos usurios. No Windows Forms, um formulrio uma superfcie
visual na qual so exibidas informaes para o usurio normalmente os aplicativos
so criados pela insero de controles em formulrios e pelo desenvolvimento de
respostas a aes do usurio, como cliques do mouse ou pressionamentos de
teclas.
Um controle um elemento discreto de interface do usurio que
exibe dados ou aceita a entrada de dados. O Windows Forms contm uma
variedade de controles que podem ser colocados em formulrios: controles que
exibem caixas de texto, botes, caixas suspensas, botes de rdio e at mesmo
pginas da Web. Est escolha a mais propicio para que o uso em um computador
do tipo desktop, aonde a secretaria, possa fazer o uso do formulrio na matricula do
aluno. Como somente a secretaria teria acesso a este formulrio poderia ser algo
mais simples, usual e rpido. Usaremos os seguintes componentes:
Boton: Um boto que tem a finalidade de executar tarefas por meio
de um clique. - Usado no final do formulrio para poder confirmar os dados do
cadastro e tambm a finalizao da matricula.
CheckListBox: Componente usado para fazermos seleo entre um
grupo de itens. Usado para selecionar alguns dados dos alunos ex: faixa de salrio,
perodo das aulas, estado e etc.
CheckBox:

Componente

usado

para

fazermos

seleo

de

verdadeiro e falso. - Usaremos para selecionar o sexo do aluno. (masculino ou

feminino)
ComboBox:

Componente usado para fazermos seleo de uma

lista de itens, aonde somente um pode ser selecionado. - Usaremos para colocar a
lista de cursos disponveis para matricula.
DateTimePicker: Mostra um calendrio. - Usado para selecionar a
data de nascimento do aluno.

Label: A propriedade mais usada o Text. - Usado aonde

colocaremos os nomes que aparecer na tela do formulrio.
Tendo sido feita a opo para desenvolvimento na linguagem
C#, escolha do tipo de usado na seleo do curso ou dos perodos so:
Radiobutton: Utilizado para selecionar apenas um item no grupo.
TabControl: Utilizado quando temos muitas informaes para
colocar no formulrio. Usado para organizar dos dados que vai ser pedidos no
formulrio.
GroupBox: Utilizado para formar um grupo e organizar informaes.
- Usado para poder colocar radiobutton, labels e etc. para manter separados alguns
itens.
Length: Comando usado para contar caracteres tem em uma string.
- Usado na validade do CPF do aluno. Podem ser usados vrios outro, mas estes
so os principais.
4 Faa uma pesquisa bibliogrfica onde voc devera levantar
informaes sobre Modelos geis e Modelos Evolucionrios, onde devera identificar
pelo menos 5 (cinco) modelos de cada tipo. Aps identificar os modelos voc dever
colocar as caractersticas marcantes de cada modelo, citar e explicar o seu ciclo de
vida, comentando as atividades de cada fase do ciclo. Para auxiliar em seu trabalho
indico que pesquise os livros indicados na bibliografia bsica da disciplina de
Engenharia de software. Obs: os livros esto tanto no meio digital como na biblioteca
fsica de sua unidade.
MODELOS GEIS
Extreme Programming
O

sucesso

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.
Essas fases so compostas de vrias tarefas que so executadas. 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.
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 a serem implementadas e as descrevem em cartes. Os programadores
assinalam as dificuldade para cada estria e, baseados na sua velocidade de
implementao, dizem quantas estrias podem implementar em uma iterao. Os
clientes escolhem as estrias de maior valor para serem implementadas na iterao
isso chamado planejamento iterao. O processo 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 escrita dos casos de testes; projeto e
refatoramento; codificao; realizao dos testes; e integrao. medida que esse
fluxo vai sendo seguido, o sistema vai sendo construdo, depois de terminado o
primeiro release, j se ter uma idia melhor das tecnologias e do domnio do
problema de modo que as iteraes podero ser mais curtas nos releases
subseqentes.
A fase

de

manuteno

pode

ser

considerada

como

uma

caracterstica inerente a um projeto XP. Em XP voc est simultaneamente

produzindo-nos

funcionalidades,

mantendo

sistema

existente

rodando,

incorporando novas pessoas na equipe e melhorando o cdigo. Mecanismos como:

10

refatoramento, introduo de novas tecnologias, e introduo de novas idias 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 do projeto ter se tornado economicamente invivel,
devido a dificuldades de adicionar funcionalidades a um custo baixo e devido a uma
alta taxa de erros.
Scrum
O Scrum, usa um conjunto de padres de processo de software,
que so adequados para projetos com prazos apertados e requisitos que mudam
freqentemente. Cada padro de processo define um conjunto de atividades.
O ciclo de vida do Scrum baseado em trs fases principais:
Pr-planejamento os requisitos so descritos e priorizados no
Product Backlog. O planejamento inclui tambm a estimativa de esforo para cada
requisito, definio da equipe de desenvolvimento, as ferramentas a serem usadas,
os possveis riscos do projeto, as necessidades de treinamento e uma proposta de
arquitetura de desenvolvimento baseada na lista de tarefas.
Software desenvolvido sprints, que duram de acordo com o TIMEBOX, e na qual cada equipe recebe uma parte do backlog para desenvolvimento.
Sempre apresenta um produto executvel ao final.
Ps-planejamento iniciada quando todos os tpicos so satisfatrio
tempo,

competitividade,

requisitos,

qualidade,

custo. Atividades:

testes

de

integrao, testes de sistema, documentao do usurio, preparao de material de

treinamento, preparao de material de marketing.
O ciclo de vida do Scrum tem o seu ciclo composto por uma srie de
iteraes bem definidas, cada uma com durao de duas a quatro semanas,
chamadas Sprints. Antes de cada Sprint, realiza-se uma reunio de planejamento

11

em que os membros do time tem contato com o Product Owner para selecionar e
estimar os itens do Product Backlog que acreditam conseguir entregar ao final da
Sprint. A prxima fase a execuo da Sprint durante a execuo da Sprint, o time
controla o andamento do desenvolvimento realizando Reunies Dirias de no mais
que 15 minutos de durao, e observando o seu progresso usando um grfico
chamado Sprint Burndown.
Ao final de cada Sprint, deve-se realizar uma Reunio de Reviso
em que o time demonstra o produto gerado na Sprint e valida se o objetivo foi
atingido. Logo em seguida, realiza-se a Reunio de Retrospectiva uma reunio de
lies aprendidas, com o objetivo de melhorar o processo, time e/ou produto para a
prxima Sprint.
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.
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.
O ciclo de vida da FDD composto de 05 prticas para cada . 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

12

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 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.
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
foram identificadas e modeladas no processo anterior, so aqui identificadas como
reas de negcio. Dentro de cada rea o time deve conseguir identificar as
atividades de negcio daquela rea especfica, 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 programadoreschefes.
Determinar a sequncia do desenvolvimento: o time determina a
sequncia do desenvolvimento baseando-se nas dependncias entre elas, a equipe

13

de desenvolvimento 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 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 equipe de funcionalidades: sabendo quais as classes que
sero

envolvidas

no

desenvolvimento

de

determinada

funcionalidade,

programador-chefe convoca os desenvolvedores responsveis por cada classe

envolvida para fazer parte da 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.
Desenvolver diagrama de sequncia: o time desenvolve o
diagrama de sequncia relacionado aquela 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 diagrama 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.

14

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.
Dynamic Systems Development Method
O frameword DSDM consiste de 3 fases seqenciais, nomeadas de
pr-projeto, ciclo de vida e ps-projeto. O ciclo de vida a fase mais elaborada das
3. Consiste em 5 estgios que formam o passo-a-passo das iteraes aplicadas ao
desenvolvimento do sistema.
1 Fase
O Pr-Projeto: so identificados os projetos candidatos, so
definidos oramento e assinatura do contrato. Controlando estes critrios
antecipadamente pode-se evitar problemas futuros e em estgios mais crticos.
2 Fase
O Ciclo de Vida
Ciclo de vida do DSDM de 5 estgios que um projeto possui para o
desenvolvimento de um sistema. Os dois primeiros estgios, Anlise de viabilidade e
negcios so fases sequenciais que se completam entre si. Aps a concluso destas
fases, o sistema desenvolvido iterativamente e incrementalmente segundo as
iteraes do Modelo Funcional, desenho e construo, at implementao.
1 - O Estudo de Viabilidade: durante este nvel do projeto, a
viabilidade de utilizao da DSDM para este projeto examinada. Os pr-requisitos
para o uso da DSDM so encontrados respondendo a questes como: Pode este
projeto ir de encontro s necessidades de negcio apontadas?, , este projeto,
adequado ao uso da DSDM? e Quais so os riscos mais importantes envolvidos?.
As tcnicas mais importantes utilizadas nesta fase so os workshops.
Para entrega ao cliente, so preparados neste nvel o Relatrio e o

15

Prottipo de Viabilidade que dizem respeito viabilidade do projeto em mos. A

estes, adicionam-se um esboo global do plano para o resto do projeto e um
Registro de Risco que identifica os riscos mais importantes no projeto.
2 - O Estudo do Negcio: engloba todo o trabalho realizado no
Estudo de Viabilidade. Depois do projeto ser declarado fivel para o uso da DSDM,
este nvel examina o processo de financiamento, os utilizadores envolvidos e as
suas necessidades e desejos respectivos. Uma vez mais, os workshops so uma
das mais valiosas tcnicas. Workshops nos quais os diferentes stakeholders se
renam e discutam o sistema proposto. A informao retirada destas sesses
combinada numa lista de requisitos. Uma importante propriedade desta lista de
requisitos a possibilidade de se definir prioridades. Estas prioridades so definidas
utilizando uma perspectiva MoSCoW. Baseado neste escalonamento, um plano de
desenvolvimento construdo como uma linha mestra para o resto do projeto. Uma
importante tcnica utilizada no desenvolvimento do plano a tcnica de
Timeboxing2. Esta tcnica essencial para serem atingidos os objetivos da DSDM,
nomeadamente a imposio de tempo e oramento fixos, garantindo no entanto a
qualidade desejada. Uma arquitetura de sistema outro meio para guiar o
desenvolvimento do Sistema de Informao.
No final deste nvel, devero estar prontos para entrega ao cliente
uma definio de rea de negcio que descreve o contexto do projeto dentro da
companhia, a definio da arquitetura do sistema que fornece uma arquitetura global
inicial do SI em desenvolvimento juntamente com o plano de desenvolvimento que
reala os passos mais importantes no processo de desenvolvimento. Na base
destes dois ltimos documentos est a lista de prioridades dos requisitos. A lista
define todos os requisitos do sistema, organizados de acordo com o princpio do
MoSCoW. Por fim, o Registro de Risco atualizado com os fatos que foram
identificados durante esta fase da DSDM.
3 - Anlise Funcional: os requisitos que foram identificados nos
nveis anteriores so convertidos para um Modelo Funcional. A Prototipagem uma
das tcnicas chave dentro deste nvel, que ajuda no bom envolvimento do utilizador
final com o projeto. O prottipo desenvolvido revisto pelos diferentes grupos de
utilizadores. Para assegurar a qualidade do projeto, os testes so implementados
em cada iterao da DSDM. Uma importante parte dos testes so realizados na
Anlise Funcional. O Modelo Funcional pode ser subdividido em quatro sub nveis:

16

Identificar Prottipo Funcional: determinar as funcionalidades a

serem implementadas no prottipo que resulta desta iterao.
Acordar Calendrio de Tarefas: definir como e quando desenvolver
estas funcionalidades.
Criar Prottipo Funcional: desenvolver o prottipo.
Rever o Prottipo: procurar correes possveis no prottipo
desenvolvido. Isto pode ser feito atravs de testes com utilizadores finais e revendo
a documentao.
Neste nvel, necessrio entregar ao cliente o Modelo Funcional e o
Prottipo Funcional que, juntos, representam as funcionalidades que podem ser
realizadas nesta iterao, prontas para serem testadas pelos utilizadores. Alm
destes dois documentos, a Lista de Requisies atualizada, sendo apagados os
itens que foram implementados e repensando as prioridades dos requisitos
restantes.
4 - Desenho: o ponto central desta iterao da DSDM a
integrao das componentes funcionais do nvel anterior num sistema que satisfaa
as necessidades do utilizador. Mais uma vez, os testes so uma das atividades mais
importantes. O Desenho pode ser dividido em quatro sub nveis:
Identificar Prottipo de Desenho: identificar requisies funcionais
e no-funcionais que so necessrios no sistema testado.
Acordar Calendrio de Tarefas: definir como e quando desenvolver
estes requisitos.
Criar Prottipo de Desenho: criar um sistema que possa, com
segurana, ser fornecido aos utilizadores finais para um uso dirio.
Rever Prottipo de Desenho: verificar a exatido do sistema
desenhado. Mais uma vez, os testes e revises so peas fundamentais.
Ao utilizador, sero entregues o Prottipo de Desenho para que
estes efetuem testes ao produto-prottipo.
5 - Implementao: o sistema testado e a sua documentao so
entregues aos utilizadores finais que devero comear a ser treinados para a futura
utilizao do novo SI. O sistema a ser entregue foi revisto para incluir todos os
requisitos que foram definidos nos primeiros nveis do projeto. O nvel de
implementao pode ser dividido em quatro sub nveis:

17

Aprovao do utilizador: os utilizadores finais aprovam o sistema

testado para implementao e as linhas mestras para a implementao e uso do
sistema so criadas.
Treinar os utilizadores: treinar os futuros utilizadores no uso do
sistema.
Implementao: o sistema testado no local de trabalho dos
utilizadores finais.
Rever Negcio: rever o impacto do sistema implementado no
negcio, um problema central ser tentar compreender se o sistema vai de encontro
aos objetivos definidos no incio do projeto. Dependendo disto, o projeto passar
para a fase seguinte, o Ps-Projeto ou voltar a uma das fases anteriores para
desenvolvimento posterior.
No final deste nvel, o sistema dever ser entregue e instalado,
pronto para o uso de todos os utilizadores finais e a Documentao de Utilizao do
Sistema dever ser detalhada.
3 Fase
Ps-projeto
Esta fase garante a eficincia e eficcia do projeto. Atravs de
manutenes, melhorias e ajustes de acordo com os princpios do DSDM. A
manuteno pode ser vista como um contnuo desenvolvimento. Invs de finalizar o
ciclo de vida de apenas 1 vez, normalmente o projeto pode retomar fases/etapas
anteriores a fim de refinar ainda mais o passo concludo.
Crystal
A famlia Crystal inclui grande nmero de diferentes mtodos que
so selecionados de acordo com as caractersticas do projeto a ser desenvolvido.
Atualmente, tm-se quatro mtodos, e apenas dois dos mtodos mantm o
desenvolvimento de novas prticas para cobrir diferentes tipos de projetos.
Famlia Crystal so identificados por cores, quanto mais escura for a
cor do mtodo, maior a complexidade do projeto. Existem algumas caractersticas
comuns famlia Crystal, como o desenvolvimento incremental com ciclos de no
mximo quatro meses, grande nfase na comunicao e cooperao das pessoas,

18

no limitao de quaisquer prticas de desenvolvimento, ferramentas ou produtos de

trabalho e incorporao de objetivos para reduzir produtos de trabalho intermedirios
e desenvolv-los como projetos evoludos.
O ciclo de vida desta famlia baseado nas seguintes prticas:
Staging: Planejamento do prximo incremento do sistema. A equipe
seleciona os requisitos que sero implementados na iterao e o prazo para sua
entrega;
Edio e reviso: construo, demonstrao e reviso dos
objetivos do incremento;
Monitoramento: o processo monitorado com relao ao progresso
e estabilidade da equipe. medido em marcos e em estgios de estabilidade;
Paralelismo: em Crystal Orange as diferentes equipes podem
operar com o mximo paralelismo. Isto permitido atravs do monitoramento da
estabilidade e da sincronizao entre as equipes.
Inspees de usurios: so sugeridas duas a trs inspees feitas
por usurios a cada incremento;
Workshops refletivos: so reunies que ocorrem antes e depois de
cada iterao com objetivo de analisar o progresso do projeto.
Local matters: so os procedimentos a serem aplicados, que
variam de acordo com o tipo de projeto.
Work Products: sequncia de lanamento, modelos de objetos
comuns, manual do usurio, casos de teste e migrao de cdigo. Especificamente
para o Clear, casos de uso e descrio de funcionalidade; Especificamente para o
Orange: documento de requisitos.
Standards:

padres

de

notao,

convenes

de

produto,

formatao e qualidade usadas no projeto.

Tools: ferramentas mnimas utilizadas.
Crystal

Clear:

compiladores,

gerenciadores

de

verso

configurao. Para Crystal Orange: ferramentas de verso, programao, teste,

comunicao, monitoramento de projeto, desenho e medio de performance.

19

MODELOS EVOLUCIONRIOS
Modelo Espiral
Este

modelo

foi

desenvolvido

para

abranger

as

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. O modelo define quatro importantes atividades representadas por
quatro quadrantes:
1. Planejamento: determinao dos objetivos, alternativas e
restries.
2. Anlise de riscos: anlise de alternativas e identificao/resoluo
de riscos.
3. Engenharia: desenvolvimento do produto no nvel seguinte .
4. Atualizao feita pelo cliente: avaliao dos resultados da
engenharia.
Ele usa uma abordagem evolucionria engenharia de software,
capacitando o desenvolvedor e o cliente a entender e reagir aos riscos em cada fase
evolutiva. O modelo espiral usa a prototipao como um mecanismo de reduo de
riscos, mas, o que mais importante, possibilita que o desenvolvedor aplique a
abordagem de prototipao em qualquer etapa da evoluo do produto. Ele mantm
a abordagem de passos sistemticos sugerida pelo ciclo de vida clssico, mas
incorpora-a numa estrutura iterativa que reflete mais realisticamente o mundo real. O
modelo espiral exige uma considerao direta dos riscos tcnicos em todas as
etapas do projeto e, se adequadamente aplicado, deve reduzir os riscos antes que
eles se tornem problemticos.
O modelo de ciclo de vida espiral apresentado por Boehm em 1988
combina as caractersticas positivas da gerncia (documento associado s fases do
ciclo) do modelo de cascata com as fases sobrepostas encontradas no modelo
incremental e, tambm,com as verses anteriores de um sistema do modelo de
prototipao. O modelo em espiral parte do princpio de que a forma do
desenvolvimento de software no pode ser completamente determinada de
antemo.
A prototipao vista como um meio de reduo de riscos, a permitir

20

que se descubram os problemas potenciais antes de se comprometer com um

sistema completo. O modelo caracteriza-se como um gerador de modelo de
processo. Cada ciclo do modelo em espiral possui quatro atividades principais:
Elaborar objetivos, restries e alternativas para entidades de
software. Avaliar alternativas com relao aos objetivos e restries, e identificar as
principais fontes de riscos. Elaborar a definio das entidades de software em um
projeto.
Planejar o prximo ciclo. Abortar um projeto se ele apresentar um
alto fator de risco.
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.
Modelo de Montagem de Componentes
Desenvolvimento baseado em componentes (CBD), 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 passos implantados com uma abordagem evolucionria:

21

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.
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, 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.
Modelo Prototipagem
Auxilia o engenheiro de software e o cliente a entenderem melhor o
que deve ser construdo quando os requisitos esto confusos. Usado como uma
tcnica que pode ser implementada dentro de qualquer modelo.
- Prottipo verso preliminar do software. Pode ser um programa ou
no papel.
- Concentra-se na representao dos aspectos do software que so
visveis para o cliente.
- Lay-out da interface
- Entradas e sadas
- O cliente tem que concordar que o prottipo ser usado apenas
para levantar requisitos.
- O software real ser desenvolvido com olho na qualidade.
- Clico de vida do modelo Prototipagem:
- Obteno dos Requisitos: desenvolvedor e cliente definem os
objetivos gerais do software, identificam quais requisitos so conhecidos e as reas
que necessitam de definies adicionais.
- Projeto Rpido: representao dos aspectos do software que so
visveis ao usurio (abordagens de entrada e formatos de sada).

22

- Construo Prottipo: Implementao rpida do projeto

- Avaliao do Prottipo: Cliente e desenvolvedor avaliam o prottipo
- Refinamento dos Requisitos: cliente e desenvolvedor refinam os
requisitos do software a ser desenvolvido. Ocorre neste ponto um processo de
iterao que conduzir primeira atividade at que as necessidades do cliente sejam
realizadas e o desenvolvedor entenda o que precisa ser feito.
- Construo Produto: Identificados os requisitos, o prottipo deve
ser descartado e a verso de produo deve ser construda considerando os
critrios de qualidade.

23

3 CONCLUSO
A criao de um software importante, podemos trocar idias com
os funcionrios, com os clientes da empresa, para poder obter mais informaes.
Alm de fazer reunies com clientes e funcionrios para um conhecimento melhor e
poder desenvolver um software mais confivel e com menos erros.
Podemos conhecer um pouco das tcnicas usada para se
desenvolver um bom software, para que o cliente no venha ter problema futuros
com a perda de informaes, que o mais importante nas empresas. Aprendendo
assim a desenvolver um software usando ou um modelo gil ou evolucionrio, assim
o desenvolvimento com certeza ser bem sucedido e deixar o cliente satisfeito.
Sendo assim o profissional da rea tem que ser responsvel e seguir
os passos o que determinado na construo de um trabalho, executando com
perfeio e procurando o mximo de informaes possveis.
Agradeo a oportunidade que este trabalho proporcionou para saber
sobre

desenvolvimento

de

software.

Acrescentara

muito

conhecimento

aprendizado na minha vida profissional, mostrou que a tecnologia tornou-se uma

ferramenta vital para empresas e clientes no mundo de hoje.
Desde j agradeo e espero ter correspondido com este trabalho
trazendo informaes e um pouco de conhecimento.

24

4 REFERNCIA
FLORES,

Emerson

Ricardo;

TANAKA,

Simone

Sawasaki;

Linguagens e Tcnicas de Programao. So Paulo: Pearson Prentice Hall, 2009.

PERINI, Luis Cludio; HISATOMI, Marco Ikuro; BERTO; Wagner
Luiz. Engenharia de Software: So Paulo: Pearson Prentice Hall, 2009.
NISHIMURA, Roberto Yukio; Banco de Dados. So Paulo: Pearson
Prentice Hall, 2009.
TANAKA, Simone Sawasaki; Anlise de Sistemas. So Paulo:
Pearson Prentice Hall, 2009.
ASSOCIAO BRASILEIRA DE NORMAS TCNICAS. Informao
e documentao referncias elaborao: NBR 6023. Rio de Janeiro, 2002a.
______. Informao e documentao numerao progressiva
das sees de um documento apresentao: NBR 6024. Rio de Janeiro, 2003a.
______. Informao e documentao sumrio apresentao:
NBR 6027. Rio de Janeiro, 2003b.
______. Informao e documentao citaes em documentos
apresentao: NBR 10520. Rio de Janeiro, 2002b.