Você está na página 1de 38

SISTEMA DE ENSINO PRESENCIAL CONECTADO ANLISE DE DESENVOLVIMENTO DE SISTEMAS ADSO N JOS HONORI DE MELO Utilizando Casos de Uso, entendendo

o Modelo EntidadeRelacionamento e aprofundan do nos conceitos de Mtodos geis e Evolucionrios de desenvolvimento de software. Palmas 2011

ADSON JOS HONORI DE MELO Utilizando Casos de Uso, entendendo o Modelo EntidadeRelacionamento e aprofundan do nos conceitos de Mtodos geis e Evolucionrios de desenvolvimento de software. Trabalho apresentado as disciplinas de Anlise de Sistemas I, Engenharia de Softwa re, Banco de Dados I, Linguagem e Tec. de Programao II e Seminrios II da Universida de Norte do Paran - UNOPAR Prof(s). : Polyanna Gomes Roberto Y. Nishimura Lus Clau dio Perini Anderson Gonalves Palmas 2011

SUMRIO 1 2 2.1 2.2 2.2.1 2.2.2 2.2.3 2.2.3.1 2.2.3.2 2.2.3.3 2.2.3.4 2.2.3.5 2.2.4 2.2. 4.1 2.2.4.2 2.2.4.3 2.2.4.3.1 2.2.4.3.2 2.2.5 2.3 2.3.1 2.3.2 2.3.3 2.3.4 2.3.5 2.4 2.4.1 2.4.2 2.4.3 2.4.4 2.4.5 2.5 2.5.1 2.5.2 2.5.3 2.5.3.1 3 INTRODUO ....... ................................................................................ .............................3 DESENVOLVIMENTO ................................. .......................................................................4 CASO DE USO CONTROLAR USURIO ........................................................... ...........4 TCNICA DE MODELAGEM ENTIDADE E RELACIONAMENTO (MER) ................ ........7 CONCEITOS BSICOS DE MODELAGEM DE DADOS ................................ ...................7 ENTIDADES ................................................. ......................................................................9 ATRIBUTO S .............................................................................. .........................................9 COMPOSTOS E SIMPLES (ATMICOS)......... .............................................................. 10 MONOVALORADOS E MULTIVALORADOS ............................................................... .. 10 ARMAZENADOS E DERIVADOS .................................................. ................................. 10 VALORES NULLS (NULOS) ..................... ...................................................................... 10 COMPLE XOS ............................................................................ ...................................... 11 RELACIONAMENTOS E CARDINALIDADE ...... ............................................................. 11 GRAU DE RELACIO NAMENTO ........................................................................ ............. 11 NOMES DE PAPIS E RELACIONAMENTO RECURSIVO....................... .................... 12 CARDINALIDADE........................................... ................................................................. 13 RAZES DE CAR DINALIDADE PARA RELACIONAMENTOS BINRIOS ................... 13 RESTRIES DE PARTICIP AO E DEPENDNCIAS DE EXISTNCIA .................. 14 ADMINISTRADOR DE DADOS ......... .............................................................................. 1 4 MTODOS GEIS DE DESENVOLVIMENTO DE SOFTWARE .................................... 15 EXTREME PROGRAMMING OU XP ................................................... ........................... 15 SCRUM ........................................... ................................................................................ . 18 FEATURE DRIVEN DEVELOPMENT FDD............................................. ..................... 20 RATIONAL UNIFIED PROCESS RUP .......................... ............................................... 21 METODOLOGIA DE DESENVOLVIMENT O DE SISTEMAS DINMICOS DSDM ...... 23 MODELO EVOLUCIONRIO PARA DESENVOLVIMENTO DE S OFTWARE .............. 25 MODELO DE PROTOTIPAGEM ............................... ...................................................... 25 MODELO ESPIRAL ....... ................................................................................ .................. 26 MODELO INCREMENTAL E ITERATIVO ........................... ............................................ 28 DESENVOLVIMENTO BASEADO EM COMPO NENTES CBD ................................... 29 MODELO CONCORRENTE ........... ................................................................................ . 30 DESENVOLVENDO EM .NET E C#................................................. ............................... 31 CONCEITOS ................................... ................................................................................ 31 PRINCIPAIS BENEFCIOS E CARACTERSTICAS ........................................ ............... 31 CENRIO DE ESTUDO CONTROLAR DVD ............................... ................................ 32 COMPONENTES UTILIZADOS ..................... ................................................................. 33 CONCLUSO ... ................................................................................ ............................... 35 REFERNCIAS ...................................................................... ............................................................... 36

1 INTRODUO A tarefa de programar legal e empolgante, mas desenvolver um software d e qualidade um desafio complexo e difcil. Entre a paixo pela programao, requisitos, boas idias e um software de excelncia, existem muito mais do que apenas cdigos e si ntaxes. Analisar e projetar, solucionar os problemas, dar caractersticas de fcil c omunicao, reviso, implementao e evoluo aos projetos de software que realmente faz do alista de Sistemas, figura mpar no meio da tecnologia da informao. Segundo Larman ( 2007, p. 29), A anlise enfatiza uma investigao do problema e dos requisitos, em vez de uma soluo. Por exemplo, se desejamos um novo sistema online de comercializao, com o ele ser usado? Quais as suas funes? Nesse sentido, a engenharia de software cuida da engenharia relacionada com todo s os aspectos da criao de solues de software computacional, desde o levantamento de requisitos at a manuteno do mesmo. Ela no aborda apenas questes tcnicas, e sim, aspect os relacionados com gerncia, teorias e mtodos que venham a apoiar sua produo. Os bancos de dados to essenciais no cotidiano da sociedade moderna, representam a spectos do mundo real. So constitudos por uma coleo lgica e coerente de dados com alg um significado inerente. parte importante das grandes solues de software em geral. Portanto, neste trabalho, abordaremos a resoluo de problemas especficos, sempre nos pautando e orientando pelos conceitos e tcnicas expostos acima.

4 2 DESENVOLVIMENTO 2.1 CASO DE USO CONTROLAR USURIO Casos de Uso, so narrativas em texto, amplamente utilizadas para levantar os requisitos de determinada soluo de software. Descreve a funcionalidade especfica que um sistema, supostamente, deve desempenhar ou exibir , por meio da modelagem do dilogo que um usurio, um sistema externo ou outra entid ade ter com o sistema desenvolvido. Pode tambm ser representado por um diagrama qu e utilize os conceitos da UML. Cenrio (Controlar usurio): O Aluno chega biblioteca e solicita o cadastramento. O bibliotecrio solicita a documentao para cadastro e comea a alimentar o sistema com o s dados obrigatrios. O sistema checa pendncias anteriores. Sistema efetua o cadast ro. Bibliotecrio solicita impresso em duas vias. O aluno assina uma via e o biblio tecrio deve digitalizar e arquivar no sistema. O sistema deve oferecer as funcion alidades de consulta, edio, bloqueio e excluso de dados cadastrais. Nome do Caso de Uso Atores envolvidos Interessados e interesses Pr-condio Ps-condio Controlar Usurio 1 Bibliotecrio 1 Aluno: deseja cadastrar-se de forma rpida e efici ente; 2 Bibliotecrio: deseja ter controle total sobre o processo de cadastramento e gerenciamento de cadastrados. Bibliotecrio autenticado no sistema. Aluno cadas trado com todos os dados obrigatrios, biblioteca com controle total da situao cadas tral. A) Fluxo de sucesso principal CADASTRAR: 1 o bibliotecrio pede novo cadastro, aps checar documentos obrigatrios; 2 o sistema solicita entrada de dados (CPF); 3 [EV ] o sistema checa, atravs do CPF, base de dados interna de outro programa procura de pendncias; 4 o sistema solicita entrada de mais dados (nome, endereo, RG, n de matrcula, curso, email); 5 o sistema valida e confirma o cadastramento;

5 6 o bibliotecrio gera e imprimi, em duas vias, o protocolo da operao; 7 o aluno ass ina e entrega uma via ao bibliotecrio; 8 - o bibliotecrio digitaliza e arquiva est a via como imagem no sistema. Fluxo de excees CADASTRAR: 3a aluno com pendncias na biblioteca: 3a.1 sistema avisa que existem pendncias na biblioteca; 3a.2 bibliotecrio solicita impresso das pendnc ias; 3a.3 sistema gera relatrio e imprimi. 3a.4 sistema salva estado do cadastro at que pendncia seja resolvida. B) Fluxo de sucesso principal CONSULTAR/EDITAR: 1 o bibliotecrio inicia a consult a; 2 o bibliotecrio entra com NOME ou CPF; 3 [EV] o sistema procura o registro; 4 o bibliotecrio seleciona o registro; 5 o sistema carrega na tela os dados; 6 o b ibliotecrio edita as informaes; 7 o sistema grava.

Fluxo de excees CONSULTAR/EDITAR: 3a no cadastrado: 3a.1 sistema avisa que no h regi tro de cadastro; 3a.2 sistema pergunta se deseja cadastrar; 3a.3 sistema chama md ulo de cadastro; C) Fluxo de sucesso principal CONSULTAR/EXCLUIR: 1 o bibliotecrio inicia a consul ta; 2 o bibliotecrio entra com NOME ou CPF; 3 [EV] o sistema procura o registro; 4 o bibliotecrio seleciona o registro; 5 o sistema carrega na tela os dados; 6 o bibliotecrio solicita excluso; 7 o sistema pede confirmao para excluso;

6 7 o bibliotecrio confirma; 8 o sistema realiza a excluso.

Fluxo de excees CONSULTAR/EXCLUIR: 3a no cadastrado: 3a.1 sistema avisa que no h reg stro de cadastro; 3a.2 sistema pergunta se deseja cadastrar; 3a.3 sistema chama mdulo de cadastro; D) Fluxo de sucesso principal CONSULTAR/BLOQUEAR: 1 o bibliotecrio inicia a consu lta; 2 o bibliotecrio entra com NOME ou CPF; 3 [EV] o sistema procura o registro; 4 o bibliotecrio seleciona o registro; 5 o sistema carrega na tela os dados; 6 o bibliotecrio solicita bloqueio; 7 o sistema solicita o motivo; 7 o bibliotecrio i nforma e confirma bloqueio; 8 o sistema realiza o bloqueio. Fluxo de excees CONSULTAR/ BLOQUEAR: 3a registro no encontrado: 3a.1 sistema avisa que no h registro de cadastro; 3a.2 sistema pergunta se deseja cadastrar; 3a.3 sis tema chama mdulo de cadastro;

7 Diagrama UML do Caso de Uso: Figura 1 Diagrama caso de uso - UML Ferramenta Astah (antigo JUDE) 2.2 TCNICA DE MODELAGEM ENTIDADE E RELACIONAMENTO (MER) sem dvida alguma, a tcnica de modelagem mais difundida. Ela permite fazer um modelo conceitual dos dados do mundo real que estamos analisando. Seu criador, Peter Chen, elaborou a tcnica no ano de 1976, que foi adaptada positivamente ao passar dos anos. O MER (Modelo E ntidadeRelacionamento), baseia-se na idia de que o mundo real consiste de entidad es e de relacionamentos entre essas entidades. 2.2.1 CONCEITOS BSICOS DE MODELAGE M DE DADOS Quando pretendemos desenvolver aplicaes que usam banco de dados relacio nais devemos possuir os conceitos bsicos sobre modelagem de dados. No importa se a aplicao muito simples; a correta modelagem dos seus

8 dados ir com certeza tornar sua aplicao mais robusta e mais fcil de manter. Os objet ivos principais da modelagem de dados so: a) Representar o ambiente observado; b) Documentar e normalizar; c) Fornecer processos de validao; d) Observar processos de relacionamentos entre objetos. Modelar implica em construir. Podemos definir as etapas envolvidas na construo de modelos em :

1 - Modelo conceitual - Representa as regras de negcio sem limitaes tecnolgicas ou d e implementao, por isto a etapa mais adequada para o envolvimento do usurio que no p recisa ter conhecimentos tcnicos. Neste modelo temos : a) Viso Geral do negcio; b) Facilitao do entendimento entre usurios e desenvolvedores; c) Possui somente as ent idades e atributos principais; d) Pode conter relacionamentos n para m. 2 - Mode lo Lgico Abordam limites impostos por algum tipo de tecnologia de banco de dados (banco de dados hierrquico, banco de dados relacional ,etc.). Suas caractersticas so : a) Deriva do modelo conceitual e via a representao do negcio; b) Possui entidad es associativas em lugar de relacionamentos n:m; c) Define as chaves primrias das entidades; d) Normalizao at a 3 forma normal; e) Adequao ao padro de nomenclatura; f) Entidades e atributos documentados. 3 - Modelo Fsico - Leva em considerao limites impostos pelo SGBD (Sistema Gerenciad or de Banco de dados) e pelos requisitos no funcionais dos programas que acessam os dados. Caractersticas: a) Elaborado a partir do modelo lgico;

9 b) Pode variar segundo o SGBD; c) Pode ter tabelas fsicas (log , lider , etc.); d ) Pode ter colunas fsicas (replicao). 2.2.2 ENTIDADES So representaes abstratas de alg uma coisa do mundo real. Por exemplo: a placa de um carro, o nmero de um pedido n um restaurante, o Jos Ribamar funcionrio da empresa, a disciplina de Cincias de uma escola, todos so entidades, que podem ser concretas, conceituais, fatos e etc. Ao agrupamento de entidades afins, damos o nome de Conjunto de Entidades. Por ex emplo: todos os veculos ou todos os funcionrios da empresa. muito importante saber que no MER, s se representam os Conjuntos de Entidades e nunca entidades individ uais. Ainda, s merecem representao os conjuntos de entidades do mundo real que cont enham dados de interessa da organizao. Durante o processo de modelagem costuma-se conceituar cada conjunto de entidades de modo a definir claramente todas as entidades que possam pertencer quele conju nto. Exemplo: Veculo: conjunto que engloba todos os meios de transporte de propri edade da empresa. 2.2.3 ATRIBUTOS Para cada conjunto de entidades do modelo, gua rdam-se algumas informaes pertinentes relacionadas aos seus elementos. Isto feito atravs dos atributos. Exemplo: Veculo = (Placa + Marca + Cor + Data-aquisio + Quilom etragem) ou Aluno = (Matrcula + Nome do Aluno + Data da Matrcula). Nomes de atributos so diferentes de valores de atributos, por exemplo, Marca, o n ome, enquanto Ford, GM ou Fiat, so os valores do atributo. Um atributo s pode aparecer numa nica entidade do modelo. Todavia, nada impede que atributos de entidades diferentes tenham mesmo nome,

10 embora representando informaes diferentes. Por exemplo, o atributo Nome pode apare cer na entidade Cliente onde ele indica nome do cliente, e pode tambm estar na en tidade Funcionrio, onde ele significa nome do funcionrio. 2.2.3.1 COMPOSTOS E SIMP LES (ATMICOS) Atributos compostos podem ser divididos em subpartes menores, que r epresentam a maioria de atributos bsicos com significados diferentes. Por exemplo , em uma entidade empregado, temos um atributo endereo que pode ser subdividido e m EnderecoRua, Cidade, Estado, CEP. Os atributos que no permitem subdivises so conh ecidos como atributos Simples ou Atmicos. Os atributos compostos podem formar uma hierarquia, exemplo: EnderecoRua, pode ser subdividido em trs atributos simples (Rua, Nmero e Apartamento). 2.2.3.2 MONOVALORADOS E MULTIVALORADOS A maioria dos atributos tem um valor nico para uma determinada entidade, so denominados monovalo rados. Exemplo: Idade um atributo monovalorado de uma pessoa. Atributos multival orados so aqueles que tm mais de um valor. Exemplo: Titulao, pois uma pessoa pode se r graduada em dois ou mais cursos. Atributos multivalorados devem ter limite inf erior e superior para restringir o nmero de valores permitidos a cada entidade in dividual. 2.2.3.3 ARMAZENADOS E DERIVADOS a relao entre dois ou mais atributos. Ex emplo: os atributos Idade e DataNascimento de uma pessoa. Para uma entidade pess oa em particular, o valor de idade pode ser determinado pela data corrente (hoje ) e o valor de DataNascimento da pessoa. Assim, o atributo Idade considerado der ivado do atributo DataNascimento, que, por sua vez, chamado de atributo armazena do. 2.2.3.4 VALORES NULLS (NULOS) Algumas situaes apresentam entidades em que no se pode aplicar valores a um determinado atributo. Exemplo: Apartamento um atribut o que

11

s ter um valor se o endereo for de um edifcio. Ou ainda, o atributo Titulao s aceitar lores de pessoas que possuam graduao acadmica. 2.2.3.5 COMPLEXOS Atributos composto s e multivalorados poder ser aninhados de uma forma arbitrria. Representa-se essa organizao arbitrria agrupando-se os componentes de um atributo composto entre parnt eses (), separando-se os componentes por meio de vrgulas e mostrando os atributos multivalorados entre chaves {}. Esse escopo define os atributos complexos. Por exemplo, se uma pessoa pode ter mais de uma residncia e cada uma delas vrios telef ones, um atributo EnderecoFone teria a estrutura a seguir: {EnderecoFone({Fone(CodigodeArea,NumeroFone)}, Endereco(EnderecoRua(Numero, Rua, Apartamento), Cidade, Estado, CEP))} 2.2.4 RELACIONAMENTOS E CARDINALIDADE Assi m como as entidades, os relacionamentos desempenham papel importante no MER. Ele s acontecem quando um atributo de determinada tabela se relaciona com outra enti dade. Por exemplo, o atributo Gerente, de Departamento, corresponde ao funcionrio que gerencia o departamento; o atributo DepartamentoControle, de Projeto, diz respeito ao departamento que controla o pr ojeto; o atributo Supervisor, de Empregado, refere-se a outro empregado (aquele que supervisiona esse empregado); o atributo Departamento, de Empregado, corresp onde ao departamento no qual o empregado trabalha, e assim sucessivamente. 2.2.4.1 GRAU DE RELACIONAMENTO O grau de um tipo de relacionamen to o nmero de entidades que participam desse relacionamento. Temos o grau binrio ( 2 relacionamentos) e ternrio (3). Podemos encontrar relacionamentos de mais graus , mas os mais comuns so os binrios. Um exemplo de relacionamento de grau ternrio:

12 Figura 2 Relacionamento de grau ternrio Fonte: Nishimura (2009, p. 57) Em Fornece, observem que em cada instncia de relacionamento ri associa-se a trs en tidades um fornecedor s, uma pea p e um projeto j. 2.2.4.2 NOMES DE PAPIS E RELACI ONAMENTO RECURSIVO Cada tipo de entidade que participa de um relacionamento exec uta um papel particular no mesmo. O nome de papel significa o papel que uma enti dade executa em cada instncia de relacionamento, e ajuda a explicar o significado do relacionamento. Quando determinada entidade participa mais de uma vez em um tipo de relacionamento em papis diferentes, temos o relacionamento recursivo. Exe mplo de relacionamento recursivo:

13 Figura 3 Relacionamento recursivo Fonte: Nishimura (2009, p. 60) O tipo relacionamento Superviso relaciona um empregado a um supervisor, no qual a mbas as entidades, empregado e supervisor, so membros do mesmo tipo entidade Empr egado. Assim, o tipo entidade Empregado participa duas vezes em Superviso: uma no papel de supervisor (ou chefe), e outro, no papel de supervisionado. 2.2.4.3 CA RDINALIDADE So restries impostas para limitar as possibilidades de combinaes de entidades que podem participar do conjunto de relacionamentos corresp ondente. Se por exemplo, numa empresa, existe uma regra onde diz que cada empreg ado tem de trabalhar exatamente para um departamento, teramos portanto, de descre ver essa restrio no esquema. Temos dois tipos principais de restries. 2.2.4.3.1 RAZES DE CARDINALIDADE PARA RELACIONAMENTOS BINRIOS Especifica o nmero mximo de instncias de relacionamento em que uma entidade pode participar. As razes possveis para ess e tipo de

14 cardinalidade so: 1:1 1:N N:1 M:N. Onde N representa qualquer nmero de entidades r elacionadas (zero ou mais). 2.2.4.3.2 RESTRIES DE PARTICIPAO E DEPENDNCIAS DE EXISTNCI A Determina se a existncia de uma entidade depende de sua existncia relacionada ou tra entidade, pelo tipo relacionamento. Essa restrio determina o nmero mnimo de instn cias de relacionamento em que cada entidade pode participar. H dois tipos de rest ries de participao: total e parcial. 2.2.5 ADMINISTRADOR DE DADOS O administrador de bancos de dados (DBA) executa uma funo estratgica na empresa, considerando que o m aior bem de uma organizao hoje so os dados, que esto sobre sua gerncia. Para se enten der o tamanho da responsabilidade do DBA com os dados da organizao, perdas ocasion ais de dados, dependendo de seu volume e importncia, podem causar srios prejuzos em presa e inclusive lev-la falncia. Podemos resumir sua atuao em 3 grandes grupos e br eves descries (as atribuies dentro desses escopos devem variar de organizao para organ izao), a saber: a) Criao/Manuteno de estruturas de bancos de dados: Segue metodologias de desenvolvi mento pr-estabelecidas,

interagindo com modeladores de sistema/dados, analistas de sistemas. b) Monitorao e otimizao de performance: Inclui a otimizao tanto lgica (implementao de novos process s de software, mtodos de acesso a dados, entre outros) como a fsica (dimensionamen to de hardware (servidores e interfaces de redes) c) Criao/Manuteno de polticas de se gurana de acesso: Abrange a poltica de segurana da corporao, que deve ser solicitada ao administrador de segurana.

15 2.3 MTODOS GEIS DE DESENVOLVIMENTO DE SOFTWARE As definies modernas de desenvolvimen to de software gil, evoluram a partir da metade de 1990 como parte de uma reao contr a mtodos "pesados", caracterizados por uma pesada regulamentao, regimentao e micro ge renciamento, que inviabilizavam o desenvolvimento de solues de pequeno e mdio porte sem caractersticas de softwares para ambientes crticos. Velocidade e dinamismo, so dois pontos importantes da tcnica, onde graas aos mtodos g eis, o cliente inteiramente o piloto do seu projeto e obtm muito rapidamente uma primeira produo do seu software. Em 2001, membros proeminentes da comunidade se reuniram em Snowbird e adotaram o nome mtodos geis, tendo publicado o Manifesto gil, documento que rene os princpios e prticas desta metodologia de desenvolvimento. A essncia do manifesto diz que: a) Indivduos e interaes, mais do qu e processos e instrumentos; b) Desenvolvimento de software em vez de documentao ex austiva; c) Colaborao com o cliente em vez de negociao contratual; d) Abertura mudana em vez de seguir um plano rgido. Todos os mtodos tm limites e uma aplicabilidade especfica. Mtodos geis, so muito bons para softwares menores e menos complexos, mas no so adequados quando tratamos de a plicaes crticas de grande escala, com equipe de desenvolvimento descentralizada em lugares diferentes ou que ainda tenham importantes interaes com outros sistemas a nvel de hardware ou software. 2.3.1 EXTREME PROGRAMMING OU XP A XP foi desenvolvi da por Kent Beck, dono e presidente da First Class Software Inc, onde seus dois maiores interesses e objetivos so padres e programao extrema. A XP foi concebida a p artir da ideia que desenvolver software

16 difcil, e desenvolver software de qualidade no prazo combinado ainda mais complex o. A XP uma maneira leve, eficiente, de baixo risco, flexvel, previsvel, cientfica e di vertida de desenvolver software Kent Caractersticas marcantes: a) As equipes de desenvolvimento trabalham diretamente com o cliente em ciclos muito curtos de uma a duas semanas, no mximo; b) As entre gas de verses do software acontecem muito cedo e a uma freqncia elevada para maximi zar o impacto das reaes dos utilizadores; c) A equipe de desenvolvimento trabalha em colaborao total com base programao aos pares; d) O cdigo testado e limpo ao longo de todo o processo de desenvolvimento; e) Indicadores permitem medir o adiantame nto do projeto para permitir a atualizao do plano de desenvolvimento.

Ciclo de vida de um projeto XP: Um projeto XP atravessa algumas fases durante o seu ciclo de vida, que so: explorao, planejamento inicial, iteraes do release, produo, manuteno e morte. a) A fase de explorao anterior construo do sistema. Nela, investigaes de possveis so feitas e verifica-se a viabilidade de tais solues. Os programadores elaboram pos sveis arquiteturas e tentam visualizar como o sistema funcionar considerando o amb iente tecnolgico (hardware, rede, software, performance, trfego onde o sistema ir r odar). Com isso, os programadores e os clientes vo ganhando confiana, e quando ele s possurem estrias suficientes, j poder comear a construir o primeiro release do sist ema.

17 b) A fase de planejamento inicial deve ser usada para que os clientes concordem em uma data para lanamento do primeiro release. O planejamento funciona da seguin te forma: Os programadores, juntamente com o cliente, definem as estrias (use cas e simplificados) a serem implementadas e as descrevem em cartes. Os programadores assinalam certa dificuldade para cada estria e, baseados na sua velocidade de implementao, dizem quantas estrias podem implemen tar em uma iterao. Depois, os clientes escolhem as estrias de maior valor para ser implementada na iterao isso chamado planejamento de iterao. O processo ento se repete at terminar as iteraes do release.

c) Na fase das iteraes do release so escritos os casos de teste funcionais e de uni dade. Os programadores vo seguindo mais ou menos o seguinte fluxo de atividades n a seguinte ordem (Em cada iterao): escrita dos casos de testes; projeto e refatora mento; codificao; realizao dos testes; e integrao. medida que esse fluxo vai sendo se uido, o sistema vai sendo construdo segundo os princpios, valores e prticas apresentados nas sees anteriores. Depois de terminado o primeiro release, j se ter u ma idia melhor das tecnologias e do domnio do problema de modo que as iteraes podero ser mais curtas nos releases subseqentes e j se podem fazer estimativas mais confiv eis com o que se aprendeu das iteraes passadas. Depois do final do primeiro releas e, considera-se o incio da fase de produo onde cada release subseqente do sistema, d epois de construdo, colocado para rodar em um ambiente que simula o ambiente de p roduo para ver seu comportamento em termos de performance. Pode-se fazer testes de aceitao adicionais para simular o funcionamento real do sistema no ambiente alvo.

18 d) A fase de manuteno pode ser considerada como uma caracterstica inerente a um pro jeto XP. Em XP voc est simultaneamente produzindo novas 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 idias de arquitetur a 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 e rrada pode paralisar o funcionamento do sistema resultando em prejuzos para o cliente. e) A fase de mort e corresponde ao trmino de um projeto XP. Existem duas razes para se chegar ao fin al de um projeto, uma boa e a outra ruim. A boa razo quando o cliente j est satisfe ito com o sistema existente e no enxerga nenhuma funcionalidade que possa vir a s er implementada no futuro. A m razo para a morte em XP seria o projeto ter se torn ado economicamente invivel, devido a dificuldades de adicionar funcionalidades a um custo baixo e devido a uma alta taxa de erros. 2.3.2 SCRUM Criado por Jeff Su therland e Ken Shawaber na dcada de 90, a tcnica faz parte do modelo de desenvolvi mento gil de software que fornece mtodos para se definir o planejamento, os princi pais papis de pessoas e a forma de trabalho do time. A idia do SCRUM justamente de finir papis bem especficos para as pessoas envolvidas no projeto e como cada pesso a vai agir, ou seja, o que cada uma vai ter que fazer para o projeto seguir em f rente com sucesso. Os principais papis so: a) o ScrumMaster, que mantm os processos (normalmente no

19 lugar de um gerente de projeto) b) o Proprietrio do Produto, ou Product Owner, qu e representa os stakeholders e o negcio c) a Equipe, ou Team, um grupo multifunci onal com cerca de 7 pessoas e que fazem a anlise, projeto, implementao, teste etc. Caractersticas marcantes: a) Processo gil para gerenciar e controlar o desenvolvim ento de projetos; b) Roupagem para outras prticas de engenharia de software. Como XP ou FDD; c) Processo que controla o caos resultante de necessidades e interes ses conflitantes; d) Aumenta a comunicao e maximiza a cooperao; e) Detecta e remove qualquer impedimento que atrapalhe o desenvolvimento de um produto; f) Escalabil idade desde projetos pequenos ater grande projetos nas organizaes. Ciclo de vida de um projeto SCRUM: O ciclo de vida do Scrum tem o seu ciclo comp osto por uma srie de iteraes bem definidas, cada uma com durao de duas a quatro seman as, chamada Sprints. Antes de cada Sprint, realiza-se uma reunio de planejamento (Sprint Planning Meeting) em que os membros do time tm contato com o Product Owne r (pessoa que define os itens que compem o Product Backlog) para selecionar e est imar os itens do Product Backlog ((lista das funcionalidades priorizadas do prod uto) que acreditam conseguir entregar ao final da Sprint. A prxima fase a execuo da Sprint. Durante a execuo o time controla o andamento do des envolvimento realizando Reunies Dirias (Daily Meeting) de no mais que 15 minutos de durao, e observando o seu progresso usando um grfico chamado Sprint Burndown.

20 Ao final de cada Sprint, deve-se realizar uma Reunio de Reviso (Sprint Review), em que o time demonstra o produto gerado na Sprint e valida se o objetivo foi atin gido. Logo em seguida, realiza-se a Reunio de Retrospectiva (Sprint Retrospective ), uma reunio de lies aprendidas, com o objetivo de melhorar o processo para a prxim a reunio. 2.3.3 FEATURE DRIVEN DEVELOPMENT FDD A FDD nasceu num projeto em Cingap ura, entre 1997 e 1999, a partir do Mtodo Coad (uma metodologia completa para Anli se, Desenho e Programao Orientados por Objetos, desenvolvida por Peter Coad nas dca das de 1980 e 1990) e das tcnicas de gerenciamento iterativo, incremental e enxut o de projetos, utilizadas por Jeff De Luca, um gerente de projetos australiano. Seu lema "Resultados freqentes, tangveis e funcionais". Caractersticas marcantes: a) Fornece a estrutura suficiente para equipes maiores; b) Enfatiza a produo de software de qualidade; c) Entrega resultados freqentes, ta ngveis e funcionais; d) Realiza trabalho significativo desde o incio, antes de tor nar-se altamente iterativa; e) Fornece informao de estado e progresso de forma sim ples e compreensvel; f) Fcil aceitao de clientes, gerentes e desenvolvedores. Ciclo de vida da FDD: a) Desenvolver um Modelo Abrangente: pode envolver desenvolvimento de requisitos, anlise orientada por objetos, modelagem lgica de da dos e outras tcnicas para entendimento do domnio de negcio em questo. O resultado um modelo de objetos (e/ou de dados) de alto nvel, que guiar a equipe durante os ciclos de construo. b) Constru ir uma Lista de Funcionalidades: decomposio funcional do modelo do domnio, em trs ca madas tpicas: reas de

21 negcio, atividades de negcio e passos automatizados da atividade (funcionalidades) . O resultado uma hierarquia de funcionalidades que representa o produto a ser c onstrudo (tambm chamado de product backlog, ou lista de espera do produto). c) Pla nejar por Funcionalidade: abrange a estimativa de complexidade e dependncia das funcionalidades, tambm levando em considerao a priorid ade e valor para o negcio/cliente. O resultado um plano de desenvolvimento, com o s pacotes de trabalho na seqncia apropriada para a construo. d) Detalhar por Funcion alidade: j dentro de uma iterao de construo, a equipe detalha os requisitos e outros artefatos para a codificao de cada funcionalidade, incluindo os testes. O projeto para as funcionalidades inspecionado. O resultado o modelo de domnio mais detalha do e os esqueletos de cdigo prontos para serem preenchidos. e) Construir por Func ionalidade: cada esqueleto de cdigo preenchido, testado e inspecionado. O resulta do um incremento do produto integrado ao repositrio principal de cdigo, com qualid ade e potencial para ser usado pelo cliente/usurio. 2.3.4 RATIONAL UNIFIED PROCES S RUP O Processo Unificado um processo de engenharia de software desenvolvido po r trs dos principais gurus da indstria de software: Ivar Jacobson, James Rumbaugh e Grady Booch, sendo o resultado de mais de 30 anos de experincia acumulada. o pr imeiro processo de desenvolvimento a explorar integralmente as capacidades do pa dro UML e baseia-se nas prticas comuns aos projetos de software com mais alto ROI (retorno do investimento) do mercado. Processo de Software Unificado (Rational U nified Process) = Processo + Mtodos + Linguagem (UML).

22 Caractersticas marcantes: a) Dirigido por casos de uso (use cases); b) Centrado n a arquitetura; c) Iterativo e incremental; Ciclo de vida do RUP: O ciclo de vida adotado no RUP tipicamente evolutivo. Cont udo, uma forma de organizao em fases adotada para comportar os ciclos de desenvolv imento, permitindo uma gerncia mais efetiva de projetos complexos. a) Concepo: nest a fase, estabelecido o escopo do projeto e suas fronteiras, determinando os prin cipais casos de uso do sistema. Esses casos de uso devem ser elaborados com a pr eciso necessria para se proceder estimativas de prazos e custos. As estimativas de vem ser globais para o projeto como um todo e detalhadas para a fase seguinte. A ssim, a nfase nesta etapa recai sobre o planejamento e, por conseguinte, necessrio levantar requisitos do sistema e preliminarmente analis-los. Ao trmino dessa fase , so examinados os objetivos do projeto para se decidir sobre a continuidade do desenvolvimento; b) Elaborao: o propsito desta fase analisar mais refinadamente o domnio do problema, estabelecer uma arquitetura de fundao slida, des envolver um plano de projeto para o sistema a ser construdo e eliminar os element os de projeto que oferecem maior risco. Embora o processo deva sempre acomodar a lteraes, as atividades da fase de elaborao asseguram que os requisitos, a arquitetur a e os planos esto suficientemente estveis e que os riscos esto suficientemente mit igados, de modo a se poder prever com preciso os custos e prazos para a concluso d o desenvolvimento. c) Construo: durante esta fase, um produto completo desenvolvido de maneira iterativa e incremental, para que esteja pronto para a transio comunida de usuria.

23 d) Transio: nesta fase, o software disponibilizado comunidade usuria. Aps o produto ter sido colocado em uso, naturalmente surgem nov as consideraes que vo demandar a construo de novas verses para permitir ajustes do sis tema, corrigir problemas ou concluir algumas caractersticas que foram postergadas . importante realar que dentro de cada fase, um conjunto de iteraes, envolvendo pla nejamento, levantamento de requisitos, anlise, projeto e implementao e testes, real izado. Contudo, de uma iterao para outra e de uma fase para a prxima, a nfase sobre as vrias atividades muda, como mostra a figura 1, em que a cor preta indica grand e nfase, enquanto a cor branca indica muito pouca nfase. Na fase de concepo, o foco principal recai sobre o entendimento dos requisitos e a determinao do escopo do pr ojeto (planejamento e levantamento de requisitos). Na fase de elaborao, o enfoque est na captura e modelagem dos requisitos (levantamento de requisitos e anlise), a inda que algum trabalho de projeto e implementao seja realizado para prototipar a arquitetura, evitando certos riscos tcnicos. Na fase de construo, o enfoque concent ra-se no projeto e na implementao, visando evoluir e rechear o prottipo inicial, at obter o primeiro produto operacional. Finalmente, a fase de transio concentra-se n os testes, visando garantir que o sistema possui o nvel adequado de qualidade. Alm disso, usurios devem ser treinados, caractersticas ajustadas e elementos esquecid os adicionados. 2.3.5 METODOLOGIA DE DESENVOLVIMENTO DE SISTEMAS DINMICOS DSDM DSDM uma metodologia de desenvolvimento de software originalmente baseada em "De senvolvimento Rpido de Aplicao" (RAD). Emprega uma metodologia de desenvolvimento i terativo e incremental que enfatiza o envolvimento constante do usurio e tem foco na entrega de softwares dentro do prazo e com custo estimados atravs do controle e ajuste de requisitos ao longo do desenvolvimento.

24

Caractersticas marcantes: a) Envolvimento ativo do usurio; b) Poder de deciso da eq uipe DSDM; c) Entrega freqente; d) O critrio mais importante para aceitao adequao t fa requisitada; e) Teste integrado ao ciclo de vida. Ciclo de vida da DSDM: a) Anlise de Viabilidade: durante este estgio do projeto, a viabilidade de uso do DSDM examinada. Os artefatos para este estgio so Relatrio de Viabilidade e Prottipo da Viabilidade. So estendidos at o Planejamento de Definies G erais at o resto do projeto, e alm deste um controle de Risco identifica os riscos mais impactantes do projeto. b) Estudo de Negcio: levantamento dos requisitos pr imrios. Examina-se a influncia dos processos do negcio, usurios envolvidos e seus re spectivos desejos e necessidades. c) Iterao do Modelo Funcional: os requisitos ide ntificados nos estgios anteriores sero convertidos em modelos funcionais. Este mod elo consiste tanto do funcionamento do prottipo quanto do modelo. Prototipar uma sada para tcnicas de projeto em que neste estgio auxilia num verdadeiro

envolvimento do usurio no projeto. O prottipo desenvolvido revisado por diferentes grupos. De forma a garantir qualidade, os testes so efetuados ao longo de cada i terao. d) Iterao de desenho e construo: O maior intuito desta Iterao do DSDM integr componentes funcionais de fases anteriores em um sistema que satisfaa as necessi dades do usurio. Ele tambm controla os requisitos no funcionais que foram definidos para o Sistema. Novamente Testes vem a ser uma atividade fundamental no andamen to deste estgio. e) Implantao: na fase de Implantao, o sistema testado e mais a

25

documentao de usurio entregue aos usurios e treinos a estes futuros usurios so aplica os. O sistema para ser entregue deve ter seus requisitos revisados de acordo com o que foi definido nas etapas iniciais do projeto. 2.4 MODELO EVOLUCIONRIO PARA DESENVOLVIMENTO DE SOFTWARE Este modelo busca o desenvolvimento de software evol uindo a partir de prottipo inicial. Todos os conceitos e ideias vo sendo materiali zado em requisitos medida que o prottipo evolui, at atingir o produto idealizado. O objetivo trabalhar com o Cliente em toda a fase do desenvolvimento, a partir d as especificaes iniciais. Entretanto os requisitos devem ser bem compreendidos. O modelo evolucionrio pode trazer diversas vantagens, tais como antecipar o produ to final para avaliao do Cliente, manter uma comunicao entre os desenvolvedores e us urios para solucionar problemas tcnicos e antecipar o treinamento dos usurios. 2.4. 1 MODELO DE PROTOTIPAGEM A prototipagem um modelo de processo que possibilita ao desenvolvedor criar um modelo do software que deve ser construdo. Assim, uma prvi a avaliao tanto do cliente, quanto do desenvolvedor pode ser feita. Este modelo po de ser usado como um modelo de processo independente, ou como uma tcnica, que pod e ser implantada no contexto de qualquer um dos modelos de processo existentes. A vantagem da prototipagem auxiliar o engenheiro de software e o cliente, a ente nderem melhor o que deve ser construdo, quando os requisitos esto confusos. Caract ersticas marcantes: a) Utilizado quando o cliente no definiu detalhadamente os req uisitos de entrada, processamento e sada; b) Possibilita ao desenvolvedor criar u ma verso do software com

26 um pequeno investimento inicial; c) Prvia avaliao tanto do cliente, quanto do desen volvedor; d) A construo do prottipo demonstra a viabilidade do sistema. e) Reduo dos riscos e das incertezas do desenvolvimento; Ciclo de vida: Figura 4 Ciclo de vida Prototipao Fonte: Pfleeger Engenharia de Software (2004, p. 43) O desenvolvimento comea com um conjunto simples de requisitos fornecidos pelos cl ientes e usurios. As alternativas so exploradas. Examinam-se as telas, tabelas, re latrios e outras sadas do sistema, diretamente utilizadas pelos clientes e usurios. Feita a deciso do que os clientes e usurios realmente querem, os requisitos so rev isados. Havendo consenso de como deveriam ser os requisitos, o desenvolvedor se volta para as atividades de requisitos, afim de reconsiderar e alterar a especif icao. Ento, o sistema codificado, e as alternativas, discutidas, de novo com uma po ssvel iterao entre requisitos e projeto. 2.4.2 MODELO ESPIRAL O modelo em espiral foi proposto por Boehm em 1988, como fo rma de integrar os diversos modelos existentes poca, eliminando suas dificuldades e explorando seus pontos fortes. Este modelo foi desenvolvido para abranger as

27 melhores caractersticas tanto do ciclo de vida clssico como da prototipao, acrescent ando, ao mesmo tempo, um novo elemento - a anlise de riscos - que falta a esses m odelos. Caractersticas marcantes: a) Modelo iterativo e sistemtico; b) Verses utilizveis ao final de cada iterao; c) Acompanhamento de toda vida do software, mesmo depois de entregue; d) Anlise de riscos. Ciclo de vida: Figura 5 Ciclo de vida Espiral Fonte: Pressman 2006 O ciclo se subdivide em regies que abrigam conjuntos de tarefas que crescem propo rcionalmente ao risco e ao tamanho do projeto. Iniciado o processo, ele passa po r todas as regies e depois volta primeira, executando novamente as regies seguindo uma espiral at que se tenha o produto desejado. a) Comunicao com o Cliente: mantm contato direto afim de levantar informaes teis ao si stema; b) Planejamento: define custo e tempo de desenvolvimento, alm

28 de realizar uma anlise de risco, onde estes so avaliados para que o desenvolviment o no se torne invivel na prxima etapa do modelo; c) Modelagem: responsvel pela criao d a representao

conceitual da aplicao; d) Construo: cuida da implementao e testes; e) Implantao: resp el pela instalao, suporte e feedback do incremento desenvolvido. 2.4.3 MODELO INCR EMENTAL E ITERATIVO Este modelo uma extenso do modelo espiral sendo porm mais form al e rigoroso. Dividi-se o trabalho em partes menores ou iteraes. Cada iterao result ar num incremento. Iteraes so passos em fluxo de trabalho e incrementos so cresciment os do produto. O princpio subjacente ao processo incremental e iterativo que a equipe envolvida possa refinar e alargar paulatinamente a qualidade, detalhe e mbito do sistema en volvido. Caractersticas marcantes: a) Anlise e medies como guia do processo de aprimoramento; b) Desenvolvimento incremental e iterativo; c) Refinamento e qualidade paulatin amente no decorrer do projeto. Ciclo de vida: a) Inicializao: cria uma verso base do sistema. O objetivo desta imp lementao inicial criar um produto para que o usurio possa avaliar. Ele deve oferece r um exemplo dos aspectos chave do problema e prover uma soluo que seja simples o bastante para que possa ser compreendida e implementada facilmente. b) Iterativa : envolve o re-projeto e implementao das tarefas da lista de controle do projeto e a anlise da verso corrente do

29 sistema. O objetivo para o projeto de implementao de qualquer iterao ser simples, di reto e modular, preparado para suportar re-projeto neste estgio ou como uma taref a a ser adicionada na lista de controle do projeto. c) Lista de controle do proj eto: a lista de controle do projeto modificada luz dos resultados da anlise que e nglobam as prticas de modularidade, usabilidade, reusabilidade, eficincia e obteno d os objetivos. 2.4.4 DESENVOLVIMENTO BASEADO EM COMPONENTES CBD O modelo CBD prope -se a ser uma maneira prtica e radicalmente diferente de construir aplicaes oferece ndo tcnicas imensamente melhores de desenvolv-las, mais baratas, rpidas e que se ad aptaria naturalmente com a emergente tecnologia de objetos distribudos.

Caractersticas marcantes: a) Separao clara entre especificao e implementao; b) Reusabi idade de componentes; c) Encapsulamento de dados e processos; d) Independncia da tecnologia de componentes; e) Incorpora caractersticas de tecnologias Orientadas a Objetos no Modelo Espiral; Ciclo de vida: a) Nvel de domnio do problema: foco no entendimento do problema, En volve o desenvolvimento de mind-maps (representao estruturada de termos relacionados), diagrama de contexto e cenrios. b ) Nvel de especificao do componente: descreve o comportamento do sistema, visvel externamente, de forma no ambgua. Inicialmente, es pecificamos de forma informal as entradas, as mudanas no objeto e as sadas retorna das.Depois necessria a especificao formal das operaes.

30 c) Nvel de projeto do componente: a nfase nesse estgio definir uma estrutura intern a que satisfao os requisitos comportamentais, tecnolgicos e de engenharia de software. 2.4.5 MODELO CONCORRENT E As fases de um processo de desenvolvimento no ocorrem seqencialmente, e sim, con correntemente. O mecanismo pelo qual o processo ocorre baseado em eventos que si nalizam alteraes de estado dentro de cada fase. O modelo representa atividades sim ultneas de todos os membros da equipe de desenvolvimento, e os eventos que altera m o estado so gerados por necessidades do usurio, decises da gerncia, e resultados d e revises tcnicas. Por exemplo, a fase de Especificao pode estar em um dentre diversos estados: em de senvolvimento, completo, revisado, e controlado no repositrio. A criao, e toda revi so especificao original, ativa a fase de Desenvolvimento, de forma que h um ciclo co nstante entre os estados. Embora o modelo apresente complexidade elevada, bem adaptado a situaes reais de de senvolvimento, onde realmente existe uma diviso temporal menos discreta entre as fases em execuo. Caractersticas marcantes: a) Fases do projeto ocorrem concorrentemente; b) Adapta do a situaes reais sem definio temporal exata entre as fases de desenvolvimento; c) Muito utilizado para aplicaes Cliente/Servidor; d) Simultaneidade.

31 2.5 DESENVOLVENDO EM .NET E C# 2.5.1 CONCEITOS O Visual Studio o IDE (Ambiente de Desenvolvimento Integrado) no qual os desenvolvedores trabalham para criar programas em uma dentre vrias lingu agens, incluindo Visual C#, para o .NET Framework. Utilizaremos as verses do Visu al Studio 2010 Express e o .NET Framework 4.0 neste trabalho. O .NET Framework um ambiente para desenvolvimento e execuo que permite o funcionam ento conjunto e perfeito de linguagens de programao e bibliotecas diferentes, tend o em vista a criao de aplicativos para Windows, Web, dispositivos mveis e Office. C # uma destas linguagens, orientada a objeto, de tipo seguro, simples, mas podero sa, que permite aos programadores criar uma variedade de aplicativos. 2.5.2 PRIN CIPAIS BENEFCIOS E CARACTERSTICAS a) Para Desenvolvedores: Construir customizaes par a SharePoint; Desenvolver aplicaes para Windows 7, utilizando seus recursos (Multi touch, Pin Bar, etc.); Compreender de forma mais simples cdigos e arquitetura j ex istentes; Identificar por testes, os impactos de alteraes no cdigo; Customizar o Visual Studio para atender s suas necessidades. b) Para Testers: Aproveitar uma colaborao profunda com o time de desenvolvimento; Avanar (Fast Forward) por testes manuais; Reproduzir bugs em um ambiente virtuali zado; Automaticamente, incluir contexto aos bugs; Total visibilidade do progress o do teste.

32

c) Para Gerentes de projeto: Novo dashboard mantm o time em sincronia; geis templa tes ajudam no processo de estimativa; Rastreabilidade de requisitos mantm as part es interessadas informadas; Visual Studio Team Web Access auxilia na emisso de re latrios; Novos relatrios ajudam a permitir gerenciamento proativo de projeto. 2.5. 3 CENRIO DE ESTUDO CONTROLAR DVD Dentro de uma aplicao de vdeo locadoras, encontramo s vrias aes praticadas por possveis atores (atendente, gerente e cliente), lembrando sempre que, para ser um ator, necessrio que haja interao com o sistema. As aes so: l cao, reserva, pagamentos, controle de fornecedores, controle de clientes e, contro le de DVD, este ltimo, foco deste cenrio de estudo. Figura 6 Diagrama UML

33 2.5.3.1 COMPONENTES UTILIZADOS Os componentes e controles so base do desenvolvime nto rpido de aplicativos. So objetos reutilizveis que expe um ou mais interfaces par a clientes de uma maneira padronizada. Nomear os componentes corretamente e de forma intuitiva a maneira mais inteligen te e fcil para evitar transtornos em futuras manutenes do software. Exemplo: txbGen ero.Text = ao (observem que neste caso estamos usando a propriedade Text. Para dar o nome, podemos usar a abreviao txb de textBox, que referencia o tipo de componente mais o nome da finalidade dele, Gnero do filme) Tela Principal do Sistema: a) Me nu Strip: destinado a criao de menus, com ele criamos nossa barra de menus princip al do sistema (Cadastrar, Cadastrar/Alterar, Financeiro, Reservas e Locaes); b) St atusStrip: barra de status inferior, por meio da qual passamos valiosas informaes ao usurio do sistema; Figura 7 Tela "Principal do Sistema"

34 Formulrio de Cadastro do DVD: a) Label: propriedade mais usada Text, onde colocam os o nome que aparecer na tela de nosso formulrio, identificando os contedos que de vero ser inseridos nos TextBox; b) TextBox: armazena texto dos mais variados tipo s; c) RichTextBox: indicado para texto maiores, podemos alterar o tipo, estilo d e letra; d) RadioButton: utilizado para selecionar um item entre vrios, em nosso formulrio, decidiremos se o DVD duplo ou no; e) ComboBox: lista de opes possveis para selecionar, usaremos para informar a quantidade de DVD's para cada ttulo cadastrado, seleo de f ornecedores e o gnero do filme; f) Button: componente visual com finalidade de ex ecutar alguma tarefa, em nosso programa, pode executar a insero de uma imagem de c apa, acionar o leitor de cdigo de barras ou aes bsicas de sistemas (gravar, editar, cancelar); g) PictureBox: exibio de imagens, mostrar a imagem de capa selecionada p elo atendente; Telas resultantes do Cadastro de DVD: Figura 8 Tela "Cadastro de DVD"

35 3 CONCLUSO Definitivamente, para nos tornarmos bons analistas de sistemas, demand a-se muito estudo e exige-se um grau elevado de conhecimento em diversas frentes da tecnologia e das relaes humanas. Neste contexto, vimos quo so importantes os conceitos e tcnicas abordados neste doc umento: Casos de Uso, Engenharia de Software, Banco de Dados e Programao Orientada a Objetos, so contedos obrigatrios no saber destes profissionais de informtica, que nortearo suas carreiras e daro os subsdios necessrios para o sucesso de suas emprei tadas. E finalmente, desenvolvimentos de softwares so uma arte! Produzilos com tica, rapi dez, eficincia, inteligncia, economia, robustez e, principalmente, qualidade, o qu e se espera dos profissionais que dominam e praticam todos os conceitos abordado s neste trabalho.

36 REFERNCIAS TANAKA, Simone Sawasaki. Anlise de sistemas I: curso superior de tecnol ogia em anlise e desenvolvimento de sistemas 2. So Paulo: Pearson Education do Bra sil, 2009. 182 p. LARMAN, Craig. Utilizando UML e padres: uma introduo anlise e ao p rojeto orientados a objetos e ao desenvolvimento iterativo. 3. ed. Porto Alegre: Bookman, 2008. PFLEEGER, Shari Lawrence. Engenharia de software: teoria e prtica . 2. ed. So Paulo: Pearson, 2003. NISHIMURA, Roberto Yukio. Banco de Dados I: sis temas II. So Paulo: Pearson Prentice Hall, 2009. FLORES, Emerson Ricardo. Linguag ens e Tcnicas de Programao II - Anlise e Desenvolvimento de Sistemas 2. So Paulo: Pea rson Prentice Hall, 2009. UML and C++ - A Practical Guide to Object-Oriented Dev elopment, So Paulo, MAKRON Books, 2001. WIKPDIA http://pt.wikipedia.org CISNEIROS, Hugo. Modelo de Desenvolvimento http://www.devin.com.br/modelo-scrum/, 2009. MS DN, http://msdn.microsoft.com gil SCRUM.