Você está na página 1de 37

SISTEMA DE ENSINO PRESENCIAL CONECTADO ANLISE DE DESENVOLVIMENTO DE SISTEMAS ADSON JOS HONORI DE MELO

Utilizando Casos de Uso, entendendo o Modelo EntidadeRelacionamento e aprofundando 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 aprofundando nos conceitos de Mtodos geis e Evolucionrios de desenvolvimento de software.

Trabalho apresentado as disciplinas de Anlise de Sistemas I, Engenharia de Software, Banco de Dados I, Linguagem e Tec. de Programao II e Seminrios II da Universidade Norte do Paran - UNOPAR Prof(s). : Polyanna Gomes Roberto Y. Nishimura Lus Claudio 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 ATRIBUTOS .......................................................................................................................9 COMPOSTOS E SIMPLES (ATMICOS)....................................................................... 10 MONOVALORADOS E MULTIVALORADOS ................................................................. 10 ARMAZENADOS E DERIVADOS ................................................................................... 10 VALORES NULLS (NULOS) ........................................................................................... 10 COMPLEXOS .................................................................................................................. 11 RELACIONAMENTOS E CARDINALIDADE ................................................................... 11 GRAU DE RELACIONAMENTO ..................................................................................... 11 NOMES DE PAPIS E RELACIONAMENTO RECURSIVO........................................... 12 CARDINALIDADE............................................................................................................ 13 RAZES DE CARDINALIDADE PARA RELACIONAMENTOS BINRIOS ................... 13 RESTRIES DE PARTICIPAO E DEPENDNCIAS DE EXISTNCIA .................. 14 ADMINISTRADOR DE DADOS ....................................................................................... 14 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 DESENVOLVIMENTO DE SISTEMAS DINMICOS DSDM ...... 23 MODELO EVOLUCIONRIO PARA DESENVOLVIMENTO DE SOFTWARE .............. 25 MODELO DE PROTOTIPAGEM ..................................................................................... 25 MODELO ESPIRAL ......................................................................................................... 26 MODELO INCREMENTAL E ITERATIVO ....................................................................... 28 DESENVOLVIMENTO BASEADO EM COMPONENTES 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 de 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 sintaxes. Analisar e projetar, solucionar os problemas, dar caractersticas de fcil comunicao, reviso, implementao e evoluo aos projetos de software que realmente faz do Analista 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, como ele ser usado? Quais as suas funes?

Nesse sentido, a engenharia de software cuida da engenharia relacionada com todos 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, aspectos relacionados com gerncia, teorias e mtodos que venham a apoiar sua produo.

Os bancos de dados to essenciais no cotidiano da sociedade moderna, representam aspectos do mundo real. So constitudos por uma coleo lgica e coerente de dados com algum 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.

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 entidade ter com o sistema desenvolvido. Pode tambm ser representado por um diagrama que 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 os dados obrigatrios. O sistema checa pendncias anteriores. Sistema efetua o cadastro. Bibliotecrio solicita impresso em duas vias. O aluno assina uma via e o bibliotecrio deve digitalizar e arquivar no sistema. O sistema deve oferecer as funcionalidades 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 eficiente; 2 Bibliotecrio: deseja ter controle total sobre o processo de cadastramento e gerenciamento de cadastrados. Bibliotecrio autenticado no sistema. Aluno cadastrado com todos os dados obrigatrios, biblioteca com controle total da situao cadastral.

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;

6 o bibliotecrio gera e imprimi, em duas vias, o protocolo da operao; 7 o aluno assina e entrega uma via ao bibliotecrio; 8 - o bibliotecrio digitaliza e arquiva esta 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 pendncias; 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 consulta; 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 edita as informaes; 7 o sistema grava.

Fluxo de excees CONSULTAR/EDITAR: 3a no cadastrado: 3a.1 sistema avisa que no h registro de cadastro; 3a.2 sistema pergunta se deseja cadastrar; 3a.3 sistema chama mdulo de cadastro;

C) Fluxo de sucesso principal CONSULTAR/EXCLUIR: 1 o bibliotecrio inicia a consulta; 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;

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 registro 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 consulta; 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 informa 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 sistema chama mdulo de cadastro;

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 EntidadeRelacionamento), baseia-se na idia de que o mundo real consiste de entidades e de relacionamentos entre essas entidades. 2.2.1 CONCEITOS BSICOS DE MODELAGEM DE DADOS Quando pretendemos desenvolver aplicaes que usam banco de dados relacionais devemos possuir os conceitos bsicos sobre modelagem de dados. No importa se a aplicao muito simples; a correta modelagem dos seus

dados ir com certeza tornar sua aplicao mais robusta e mais fcil de manter. Os objetivos 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 de implementao, por isto a etapa mais adequada para o envolvimento do usurio que no precisa ter conhecimentos tcnicos. Neste modelo temos : a) Viso Geral do negcio; b) Facilitao do entendimento entre usurios e desenvolvedores; c) Possui somente as entidades e atributos principais; d) Pode conter relacionamentos n para m. 2 - Modelo 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 entidades 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 Gerenciador de Banco de dados) e pelos requisitos no funcionais dos programas que acessam os dados. Caractersticas: a) Elaborado a partir do modelo lgico;

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 alguma coisa do mundo real. Por exemplo: a placa de um carro, o nmero de um pedido num 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 exemplo: 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 individuais. Ainda, s merecem representao os conjuntos de entidades do mundo real que contenham 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 conjunto. Exemplo: Veculo: conjunto que engloba todos os meios de transporte de propriedade da empresa. 2.2.3 ATRIBUTOS Para cada conjunto de entidades do modelo, guardam-se algumas informaes pertinentes relacionadas aos seus elementos. Isto feito atravs dos atributos. Exemplo: Veculo = (Placa + Marca + Cor + Data-aquisio + Quilometragem) ou Aluno = (Matrcula + Nome do Aluno + Data da Matrcula).

Nomes de atributos so diferentes de valores de atributos, por exemplo, Marca, o nome, 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 aparecer na entidade Cliente onde ele indica nome do cliente, e pode tambm estar na entidade Funcionrio, onde ele significa nome do funcionrio. 2.2.3.1 COMPOSTOS E SIMPLES (ATMICOS) Atributos compostos podem ser divididos em subpartes menores, que representam a maioria de atributos bsicos com significados diferentes. Por exemplo, em uma entidade empregado, temos um atributo endereo que pode ser subdividido em EnderecoRua, Cidade, Estado, CEP. Os atributos que no permitem subdivises so conhecidos 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 monovalorados. Exemplo: Idade um atributo monovalorado de uma pessoa. Atributos multivalorados so aqueles que tm mais de um valor. Exemplo: Titulao, pois uma pessoa pode ser graduada em dois ou mais cursos. Atributos multivalorados devem ter limite inferior e superior para restringir o nmero de valores permitidos a cada entidade individual. 2.2.3.3 ARMAZENADOS E DERIVADOS a relao entre dois ou mais atributos. Exemplo: os atributos Idade e DataNascimento de uma pessoa. Para uma entidade pessoa 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 derivado do atributo DataNascimento, que, por sua vez, chamado de atributo armazenado. 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 atributo que

11

s ter um valor se o endereo for de um edifcio. Ou ainda, o atributo Titulao s aceitar valores de pessoas que possuam graduao acadmica. 2.2.3.5 COMPLEXOS Atributos compostos e multivalorados poder ser aninhados de uma forma arbitrria. Representa-se essa organizao arbitrria agrupando-se os componentes de um atributo composto entre parnteses (), 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 telefones, 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 Assim como as entidades, os relacionamentos desempenham papel importante no MER. Eles acontecem quando um atributo de determinada tabela se relaciona com outra entidade. 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 projeto; o atributo Supervisor, de Empregado, refere-se a outro empregado (aquele que supervisiona esse empregado); o atributo Departamento, de Empregado, corresponde ao departamento no qual o empregado trabalha, e assim

sucessivamente. 2.2.4.1 GRAU DE RELACIONAMENTO O grau de um tipo de relacionamento 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 entidades um fornecedor s, uma pea p e um projeto j. 2.2.4.2 NOMES DE PAPIS E RELACIONAMENTO RECURSIVO Cada tipo de entidade que participa de um relacionamento executa um papel particular no mesmo. O nome de papel significa o papel que uma entidade 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. Exemplo 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 ambas as entidades, empregado e supervisor, so membros do mesmo tipo entidade Empregado. 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 CARDINALIDADE So restries impostas para limitar as possibilidades de

combinaes de entidades que podem participar do conjunto de relacionamentos correspondente. Se por exemplo, numa empresa, existe uma regra onde diz que cada empregado tem de trabalhar exatamente para um departamento, teramos portanto, de descrever 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 esse tipo de

14

cardinalidade so: 1:1 1:N N:1 M:N. Onde N representa qualquer nmero de entidades relacionadas (zero ou mais). 2.2.4.3.2 RESTRIES DE PARTICIPAO E DEPENDNCIAS DE EXISTNCIA Determina se a existncia de uma entidade depende de sua existncia relacionada outra entidade, pelo tipo relacionamento. Essa restrio determina o nmero mnimo de instncias de relacionamento em que cada entidade pode participar. H dois tipos de restries 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 maior bem de uma organizao hoje so os dados, que esto sobre sua gerncia. Para se entender o tamanho da responsabilidade do DBA com os dados da organizao, perdas ocasionais de dados, dependendo de seu volume e importncia, podem causar srios prejuzos empresa e inclusive lev-la falncia. Podemos resumir sua atuao em 3 grandes grupos e breves descries (as atribuies dentro desses escopos devem variar de organizao para organizao), a saber:

a) Criao/Manuteno de estruturas de bancos de dados: Segue metodologias de desenvolvimento 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 processos de software, mtodos de acesso a dados, entre outros) como a fsica (dimensionamento de hardware (servidores e interfaces de redes) c) Criao/Manuteno de polticas de segurana 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 desenvolvimento de software gil, evoluram a partir da metade de 1990 como parte de uma reao contra mtodos "pesados", caracterizados por uma pesada regulamentao, regimentao e micro gerenciamento, 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 geis, 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 que processos e instrumentos; b) Desenvolvimento de software em vez de documentao exaustiva; 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 aplicaes 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 desenvolvida 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 partir da ideia que desenvolver software

16

difcil, e desenvolver software de qualidade no prazo combinado ainda mais complexo.


A XP uma maneira leve, eficiente, de baixo risco, flexvel, previsvel, cientfica e divertida 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 entregas de verses do software acontecem muito cedo e a uma freqncia elevada para maximizar 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 adiantamento 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 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 poder comear a construir o primeiro release do sistema.

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 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 certa 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 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 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. medida que esse fluxo vai sendo seguido, o sistema vai sendo construdo segundo os princpios, valores e prticas

apresentados nas sees anteriores. 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 e j se podem fazer estimativas mais confiveis com o que se aprendeu das iteraes passadas. Depois do final do primeiro release, considera-se o incio da fase de produo onde cada release subseqente do sistema, depois de construdo, colocado para rodar em um ambiente que simula o ambiente de produo 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 projeto 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 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. e) A fase de morte corresponde ao trmino de um projeto XP. Existem duas razes para se chegar ao final de um projeto, uma boa e a 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 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. 2.3.2 SCRUM Criado por Jeff Sutherland e Ken Shawaber na dcada de 90, a tcnica faz parte do modelo de desenvolvimento gil de software que fornece mtodos para se definir o planejamento, os principais papis de pessoas e a forma de trabalho do time. A idia do SCRUM justamente definir papis bem especficos para as pessoas envolvidas no projeto e como cada pessoa vai agir, ou seja, o que cada uma vai ter que fazer para o projeto seguir em frente 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, que representa os stakeholders e o negcio c) a Equipe, ou Team, um grupo multifuncional com cerca de 7 pessoas e que fazem a anlise, projeto, implementao, teste etc.

Caractersticas marcantes: a) Processo gil para gerenciar e controlar o desenvolvimento 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 interesses conflitantes; d) Aumenta a comunicao e maximiza a cooperao; e) Detecta e remove qualquer impedimento que atrapalhe o desenvolvimento de um produto; f) Escalabilidade 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 composto por uma srie de iteraes bem definidas, cada uma com durao de duas a quatro semanas, 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 Owner (pessoa que define os itens que compem o Product Backlog) para selecionar e estimar os itens do Product Backlog ((lista das funcionalidades priorizadas do produto) que acreditam conseguir entregar ao final da Sprint.

A prxima fase a execuo da Sprint. Durante a execuo o time controla o andamento do desenvolvimento 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 atingido. 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 prxima reunio. 2.3.3 FEATURE DRIVEN DEVELOPMENT FDD A FDD nasceu num projeto em Cingapura, entre 1997 e 1999, a partir do Mtodo Coad (uma metodologia completa para Anlise, Desenho e Programao Orientados por Objetos, desenvolvida por Peter Coad nas dcadas de 1980 e 1990) e das tcnicas de gerenciamento iterativo, incremental e enxuto 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, tangveis e funcionais; d) Realiza trabalho significativo desde o incio, antes de tornar-se altamente iterativa; e) Fornece informao de estado e progresso de forma simples 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 dados 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) Construir uma Lista de Funcionalidades: decomposio funcional do modelo do domnio, em trs camadas 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 construdo (tambm chamado de product backlog, ou lista de espera do produto). c) Planejar por Funcionalidade: abrange a estimativa de

complexidade e dependncia das funcionalidades, tambm levando em considerao a prioridade e valor para o negcio/cliente. O resultado um plano de desenvolvimento, com os pacotes de trabalho na seqncia apropriada para a construo. d) Detalhar por Funcionalidade: 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 detalhado e os esqueletos de cdigo prontos para serem preenchidos. e) Construir por Funcionalidade: cada esqueleto de cdigo preenchido, testado e inspecionado. O resultado um incremento do produto integrado ao repositrio principal de cdigo, com qualidade e potencial para ser usado pelo cliente/usurio. 2.3.4 RATIONAL UNIFIED PROCESS RUP O Processo Unificado um processo de engenharia de software desenvolvido por 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 primeiro processo de desenvolvimento a explorar integralmente as capacidades do padro 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 Unified Process) = Processo + Mtodos + Linguagem (UML).

22

Caractersticas marcantes: a) Dirigido por casos de uso (use cases); b) Centrado na arquitetura; c) Iterativo e incremental;

Ciclo de vida do RUP: O ciclo de vida adotado no RUP tipicamente evolutivo. Contudo, uma forma de organizao em fases adotada para comportar os ciclos de desenvolvimento, permitindo uma gerncia mais efetiva de projetos complexos. a) Concepo: nesta fase, estabelecido o escopo do projeto e suas fronteiras, determinando os principais casos de uso do sistema. Esses casos de uso devem ser elaborados com a preciso necessria para se proceder estimativas de prazos e custos. As estimativas devem ser globais para o projeto como um todo e detalhadas para a fase seguinte. Assim, 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, desenvolver um plano de projeto para o sistema a ser construdo e eliminar os elementos de projeto que oferecem maior risco. Embora o processo deva sempre acomodar alteraes, as atividades da fase de elaborao asseguram que os requisitos, a arquitetura e os planos esto suficientemente estveis e que os riscos esto suficientemente mitigados, de modo a se poder prever com preciso os custos e prazos para a concluso do

desenvolvimento. c) Construo: durante esta fase, um produto completo desenvolvido de maneira iterativa e incremental, para que esteja pronto para a transio comunidade usuria.

23

d) Transio:

nesta

fase,

software

disponibilizado

comunidade usuria. Aps o produto ter sido colocado em uso, naturalmente surgem novas consideraes que vo demandar a construo de novas verses para permitir ajustes do sistema, corrigir problemas ou concluir algumas caractersticas que foram postergadas. importante realar que dentro de cada fase, um conjunto de iteraes, envolvendo planejamento, levantamento de requisitos, anlise, projeto e implementao e testes, realizado. 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 grande 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 projeto (planejamento e levantamento de requisitos). Na fase de elaborao, o enfoque est na captura e modelagem dos requisitos (levantamento de requisitos e anlise), ainda que algum trabalho de projeto e implementao seja realizado para prototipar a arquitetura, evitando certos riscos tcnicos. Na fase de construo, o enfoque concentra-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 nos testes, visando garantir que o sistema possui o nvel adequado de qualidade. Alm disso, usurios devem ser treinados, caractersticas ajustadas e elementos esquecidos adicionados.
2.3.5 METODOLOGIA DE DESENVOLVIMENTO DE SISTEMAS DINMICOS DSDM

DSDM uma metodologia de desenvolvimento de software originalmente baseada em "Desenvolvimento Rpido de Aplicao" (RAD). Emprega uma metodologia de desenvolvimento iterativo 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 equipe DSDM; c) Entrega freqente; d) O critrio mais importante para aceitao adequao tarefa 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 Gerais 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 primrios. Examina-se a influncia dos processos do negcio, usurios envolvidos e seus respectivos desejos e necessidades. c) Iterao do Modelo Funcional: os requisitos identificados nos estgios anteriores sero convertidos em modelos funcionais. Este modelo 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 iterao. d) Iterao de desenho e construo: O maior intuito desta Iterao do DSDM integrar os componentes funcionais de fases anteriores em um sistema que satisfaa as necessidades do usurio. Ele tambm controla os requisitos no funcionais que foram definidos para o Sistema. Novamente Testes vem a ser uma atividade fundamental no andamento 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 aplicados. 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 evoluindo a partir de prottipo inicial. Todos os conceitos e ideias vo sendo materializado 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 das especificaes iniciais. Entretanto os requisitos devem ser bem compreendidos.

O modelo evolucionrio pode trazer diversas vantagens, tais como antecipar o produto final para avaliao do Cliente, manter uma comunicao entre os desenvolvedores e usurios 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 prvia avaliao tanto do cliente, quanto do desenvolvedor pode ser feita. Este modelo pode ser usado como um modelo de processo independente, ou como uma tcnica, que pode 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 entenderem melhor o que deve ser construdo, quando os requisitos esto confusos. Caractersticas marcantes: a) Utilizado quando o cliente no definiu detalhadamente os requisitos de entrada, processamento e sada; b) Possibilita ao desenvolvedor criar uma verso do software com

26

um pequeno investimento inicial; c) Prvia avaliao tanto do cliente, quanto do desenvolvedor; 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 clientes e usurios. As alternativas so exploradas. Examinam-se as telas, tabelas, relatrios 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 revisados. Havendo consenso de como deveriam ser os requisitos, o desenvolvedor se volta para as atividades de requisitos, afim de reconsiderar e alterar a especificao. Ento, o sistema codificado, e as alternativas, discutidas, de novo com uma possvel iterao entre requisitos e projeto.

2.4.2 MODELO ESPIRAL 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

27

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 modelos.

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 proporcionalmente ao risco e ao tamanho do projeto. Iniciado o processo, ele passa por 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 sistema; b) Planejamento: define custo e tempo de desenvolvimento, alm

28

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

conceitual da aplicao; d) Construo: cuida da implementao e testes; e) Implantao: responsvel pela instalao, suporte e feedback do incremento desenvolvido. 2.4.3 MODELO INCREMENTAL E ITERATIVO Este modelo uma extenso do modelo espiral sendo porm mais formal e rigoroso. Dividi-se o trabalho em partes menores ou iteraes. Cada iterao resultar num incremento. Iteraes so passos em fluxo de trabalho e incrementos so crescimentos 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 envolvido.

Caractersticas marcantes: a) Anlise e medies como guia do processo de aprimoramento; b) Desenvolvimento incremental e iterativo; c) Refinamento e qualidade paulatinamente no decorrer do projeto.

Ciclo de vida: a) Inicializao: cria uma verso base do sistema. O objetivo desta implementao inicial criar um produto para que o usurio possa avaliar. Ele deve oferecer 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, direto e modular, preparado para suportar re-projeto neste estgio ou como uma tarefa a ser adicionada na lista de controle do projeto. c) Lista de controle do projeto: a lista de controle do projeto modificada luz dos resultados da anlise que englobam as prticas de modularidade, usabilidade, reusabilidade, eficincia e obteno dos 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 oferecendo tcnicas imensamente melhores de desenvolv-las, mais baratas, rpidas e que se adaptaria naturalmente com a emergente tecnologia de objetos distribudos.

Caractersticas marcantes: a) Separao clara entre especificao e implementao; b) Reusabilidade 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, Envolve 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, especificamos de forma informal as entradas, as mudanas no objeto e as sadas retornadas.Depois necessria a especificao formal das operaes.

30

c) Nvel de projeto do componente: a nfase nesse estgio definir uma estrutura interna que satisfao os requisitos

comportamentais, tecnolgicos e de engenharia de software. 2.4.5 MODELO CONCORRENTE As fases de um processo de desenvolvimento no ocorrem seqencialmente, e sim, concorrentemente. O mecanismo pelo qual o processo ocorre baseado em eventos que sinalizam alteraes de estado dentro de cada fase. O modelo representa atividades simultneas de todos os membros da equipe de desenvolvimento, e os eventos que alteram o estado so gerados por necessidades do usurio, decises da gerncia, e resultados de revises tcnicas.

Por exemplo, a fase de Especificao pode estar em um dentre diversos estados: em desenvolvimento, completo, revisado, e controlado no repositrio. A criao, e toda reviso especificao original, ativa a fase de Desenvolvimento, de forma que h um ciclo constante entre os estados.

Embora o modelo apresente complexidade elevada, bem adaptado a situaes reais de desenvolvimento, onde realmente existe uma diviso temporal menos discreta entre as fases em execuo.

Caractersticas marcantes: a) Fases do projeto ocorrem concorrentemente; b) Adaptado 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 linguagens, incluindo Visual C#, para o .NET Framework. Utilizaremos as verses do Visual Studio 2010 Express e o .NET Framework 4.0 neste trabalho.

O .NET Framework um ambiente para desenvolvimento e execuo que permite o funcionamento conjunto e perfeito de linguagens de programao e bibliotecas diferentes, tendo 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 poderosa, que permite aos programadores criar uma variedade de aplicativos. 2.5.2 PRINCIPAIS BENEFCIOS E CARACTERSTICAS a) Para Desenvolvedores: Construir customizaes para SharePoint; Desenvolver aplicaes para Windows 7, utilizando seus recursos (Multitouch, Pin Bar, etc.); Compreender de forma mais simples cdigos e arquitetura j existentes; -

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 virtualizado; Automaticamente, incluir contexto aos bugs; Total visibilidade do progresso do teste.

32

c) Para Gerentes de projeto: Novo dashboard mantm o time em sincronia; geis templates ajudam no processo de estimativa; Rastreabilidade de requisitos mantm as partes interessadas informadas; Visual Studio Team Web Access auxilia na emisso de relatrios; Novos relatrios ajudam a permitir gerenciamento proativo de projeto. 2.5.3 CENRIO DE ESTUDO CONTROLAR DVD Dentro de uma aplicao de vdeo locadoras, encontramos 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: locao, reserva, pagamentos, controle de fornecedores, controle de clientes e, controle 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 desenvolvimento rpido de aplicativos. So objetos reutilizveis que expe um ou mais interfaces para clientes de uma maneira padronizada.

Nomear os componentes corretamente e de forma intuitiva a maneira mais inteligente e fcil para evitar transtornos em futuras manutenes do software. Exemplo: txbGenero.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) Menu Strip: destinado a criao de menus, com ele criamos nossa barra de menus principal do sistema (Cadastrar, Cadastrar/Alterar, Financeiro, Reservas e Locaes); b) StatusStrip: 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 colocamos o nome que aparecer na tela de nosso formulrio, identificando os contedos que devero ser inseridos nos TextBox; b) TextBox: armazena texto dos mais variados tipos; c) RichTextBox: indicado para texto maiores, podemos alterar o tipo, estilo de 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 fornecedores e o gnero do filme; f) Button: componente visual com finalidade de executar alguma tarefa, em nosso programa, pode executar a insero de uma imagem de capa, 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 pelo atendente; Telas resultantes do Cadastro de DVD:

Figura 8 Tela "Cadastro de DVD"

35

3 CONCLUSO Definitivamente, para nos tornarmos bons analistas de sistemas, demanda-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 documento: 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 empreitadas.

E finalmente, desenvolvimentos de softwares so uma arte! Produzilos com tica, rapidez, eficincia, inteligncia, economia, robustez e, principalmente, qualidade, o que se espera dos profissionais que dominam e praticam todos os conceitos abordados neste trabalho.

36

REFERNCIAS TANAKA, Simone Sawasaki. Anlise de sistemas I: curso superior de tecnologia em anlise e desenvolvimento de sistemas 2. So Paulo: Pearson Education do Brasil, 2009. 182 p. LARMAN, Craig. Utilizando UML e padres: uma introduo anlise e ao projeto 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: sistemas II. So Paulo: Pearson Prentice Hall, 2009. FLORES, Emerson Ricardo. Linguagens e Tcnicas de Programao II - Anlise e Desenvolvimento de Sistemas 2. So Paulo: Pearson Prentice Hall, 2009. UML and C++ - A Practical Guide to Object-Oriented Development, So Paulo, MAKRON Books, 2001. WIKPDIA http://pt.wikipedia.org CISNEIROS, Hugo. Modelo de Desenvolvimento http://www.devin.com.br/modelo-scrum/, 2009. MSDN, http://msdn.microsoft.com gil SCRUM.