portifolio 2º semestre - 1

Upload: kevinsousa

Post on 08-Jan-2016

231 views

Category:

Documents


0 download

DESCRIPTION

Trabalho curso de Analise de Sistemas

TRANSCRIPT

ABNT - UNOPAR - Resumido

PAGE

SUMRIO

31INTRODUO

2Atividade PROSTA43CONCLUSO234REFERNCIA24

1 INTRODUO

Neste trabalho vamos explorar um caso de uso de controle de matricula, tambm as tcnicas de modelagem Entidade Relacionamento, explicando sobre entidades, relacionamentos, atributos e cardinalidade, tambm o administrador de banco de dados, modelos conceitual de dados, modelo lgico de dados e o modelo fsico de dados.

Elaborar um projeto que pode usar e seus componentes principais neste caso de uso, sobre os modelos geis e evolucionrios, alguns como: Extremem Programming (XP), Scrum, Dynamic Systems Development Method e Feature Driven Development alem de outros.

Poderemos assim aprender um pouco mais sobre todos os assuntos aqui mencionados, ganhando assim conhecimento e capacitao para prosseguir em nosso curso de Analise e Desenvolvimento de Sistemas. Teremos oportunidade de conhecer mais profundamente como funciona tudo passo, ser um grande aprendizado para todos ns.2 Atividade PROSTA1 - Considere um Caso de Uso Controlar Usurio, cujo objetivo cadastrar o usurioda biblioteca. Partindodessecenrio, elabore a documentao do Caso de Uso.Caso de uso:Controlar Cadastro do Aluno

Descrio:Registrar Aluno no sistema

Ator:Secretaria e Aluno

Cenrio principal1 passo - Secretaria solicita cadastro de controle de matricula

2 passo - Sistema exibe pagina do controle de matricula

3 passo - Secretaria seleciona e escolhe a opo de incluso

4 passo - Sistema apresenta cdigo de matrcula

5 passo - Aluno informa seu CPF

6 passo - Sistema valida CPF digitado

7 passo - Aluno fornece seus demais dados

8 passo - Sistema solicita Escola do Aluno

9 passo - Sistema verifica se atributos foram digitados

10 passo - Sistema atribui uma data do cadastro do Aluno

11 passo - Secretaria confirma cadastro

12 passo - Sistema cria uma instancia da matricula

13 passo - Sistema manda uma mensagem confirmando o cadastro

14 passo - Sistema encerra o caso de uso

Cenrio Alternativo

1 passo - Sistema permite alterar

2 passo - Secretaria escolhe opo de altera

3 passo - Aluno informa os dados que devem ser alterados

4 passo Secretaria confirma alterao

5 passo - Sistema atualizao dos dados

6 passo - Sistema informa com uma mensagem a confirmao da alterao

7 passo - Sistema Finaliza uso case (sistema volta ao passo 14)

2 - Considerando a tcnica de Modelagem Entidade Relacionamento, explique com suas palavras o que so Entidades, Relacionamentos, Atributos, Cardinalidade, Administrador de banco de dados, modelo conceitual de dados, modelo lgico de dados e modelo fsico de dados.

Entidades: So conjuntos de informaes importantes para quem quer representar ou armazenar de maneira concreta ou abstrata. Na geralmente so encontradas em uma descrio textual na lngua portuguesa como substantivos. Para cada elemento do conjunto dado nome de instncia ou ocorrncia.

Relacionamento: uma associao entre os elementos que tm uma importncia quando associados entre si, e podem ser encontrada em uma descrio textual na lngua portuguesa como verbos. Assim o Relacionamento um acontecimento que liga duas coisas ou objetos existentes no mundo real. A cada dado nome de ocorrncia ou relacionamento.

Atributo: a caracterstica, propriedade ou prprio dado de uma entidade ou at de um relacionamento. Toda entidade possui propriedades ou qualidades que so descritas por atributos e valores, podendo ser associadas a cada ocorrncia de uma entidade ou relacionamento.

Cardinalidade: um conceito importante para definir o relacionamento, ela define o nmero de ocorrncias em um relacionamento. Para determinar a cardinalidade, deve fazer algumas perguntas direcionada ao relacionamento em ambas as direes.

Administrador de Banco de Dados: o profissional responsvel pela manuteno e gerenciamento de um banco de dados. Tambm responsvel pela criao de backups, serve para recuperar dados caso ocorram problemas ou erros no hardware. Alm de guardar os arquivos, preserva em boas condies dos mesmos, pela segurana dos dados, acessibilidade, desempenho das mquinas, processos e no desenvolvimento de testes de todo o planejamento de banco de dados. Ou seja, busca a melhor maneira de organizar, selecionar e armazenar todos os dados, avaliando todas as partes tcnicas e pessoais que iro ser utiliz-los. responsvel em altera e testa todos os procedimentos, antes de abrir acesso dos dados aos seus usurios, bem como gerenciar o direito de acesso de cada setor e pessoa.

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

Modelo Conceitual de Dados: Deve ser usada para envolver o cliente. O diagrama de dados deve ser construdo com base no diagrama de Entidade e Relacionamento, onde devem ser identificados todas as entidades e os relacionamentos existentes. Este diagrama a chave para a compreenso do modelo.

Modelo lgico de Dados: Este tem algumas limitaes e implementa recursos como adequao de padro e nomenclatura. Define as chaves primrias e estrangeiras e deve ser criado levando em conta os exemplos de modelagem de dados criados no modelo conceitual.

Modelo fsico de Dados: No modelo fsico feita a modelagem fsica do modelo de banco de dados. Leva-se em conta as limitaes impostas pelo SGBD escolhido e deve ser criado sempre com base nos exemplos de modelagem de dados produzidos no modelo lgico.

3 Tendo se feita opo para desenvolvimento na linguagem C#, faa a escolha de que tipo de projeto (cenrio) ser criado e em que verso da .Net Framework e do Visual Studio sero realizadas as implementaes, bem como fundamentar sua escolha tambm devem ser relacionados quaisosprincipais componentes que sero, bem como descrever sua funcionalidade e explicar em que em que situao ser explicado.

Vamos usar o projeto Windows Forms que uma parte importante do Visual Basic a capacidade de criar aplicativos Windows Forms executados nos computadores dos usurios. No Windows Forms, um formulrio uma superfcie visual na qual so exibidas informaes para o usurio normalmente os aplicativos so criados pela insero de controles em formulrios e pelo desenvolvimento de respostas a aes do usurio, como cliques do mouse ou pressionamentos de teclas. Um controle um elemento discreto de interface do usurio que exibe dados ou aceita a entrada de dados. O Windows Forms contm uma variedade de controles que podem ser colocados em formulrios: controles que exibem caixas de texto, botes, caixas suspensas, botes de rdio e at mesmo pginas da Web. Est escolha a mais propicio para que o uso em um computador do tipo desktop, aonde a secretaria, possa fazer o uso do formulrio na matricula do aluno. Como somente a secretaria teria acesso a este formulrio poderia ser algo mais simples, usual e rpido. Usaremos os seguintes componentes:Boton: Um boto que tem a finalidade de executar tarefas por meio de um clique. - Usado no final do formulrio para poder confirmar os dados do cadastro e tambm a finalizao da matricula.

CheckListBox: Componente usado para fazermos seleo entre um grupo de itens. Usado para selecionar alguns dados dos alunos ex: faixa de salrio, perodo das aulas, estado e etc.

CheckBox: Componente usado para fazermos seleo de verdadeiro e falso. - Usaremos para selecionar o sexo do aluno. (masculino ou feminino)

ComboBox: Componente usado para fazermos seleo de uma lista de itens, aonde somente um pode ser selecionado. - Usaremos para colocar a lista de cursos disponveis para matricula.

DateTimePicker: Mostra um calendrio. - Usado para selecionar a data de nascimento do aluno.

Label: A propriedade mais usada o Text. - Usado aonde colocaremos os nomes que aparecer na tela do formulrio.

Tendo sido feita a opo para desenvolvimento na linguagem C#,escolha do tipo de usado na seleo do curso ou dos perodos so:

Radiobutton: Utilizado para selecionar apenas um item no grupo.

TabControl: Utilizado quando temos muitas informaes para colocar no formulrio. Usado para organizar dos dados que vai ser pedidos no formulrio.

GroupBox: Utilizado para formar um grupo e organizar informaes. - Usado para poder colocar radiobutton, labels e etc. para manter separados alguns itens.Length: Comando usado para contar caracteres tem em uma string. - Usado na validade do CPF do aluno. Podem ser usados vrios outro, mas estes so os principais.

4 Faa uma pesquisa bibliogrfica onde voc devera levantar informaes sobre Modelos geis e Modelos Evolucionrios, onde devera identificar pelo menos 5 (cinco) modelos de cada tipo. Aps identificar os modelos voc dever colocar as caractersticas marcantes de cada modelo, citar e explicar o seu ciclo de vida, comentando as atividades de cada fase do ciclo. Para auxiliar em seu trabalho indico que pesquise os livros indicados na bibliografia bsica da disciplina de Engenharia de software. Obs: os livros esto tanto no meio digital como na biblioteca fsica de sua unidade.

MODELOS GEIS

Extreme Programming

O sucesso e popularidade adquiridos por XP se devem principalmente aos relatos de bons resultados obtidos em projetos, a motivao dos profissionais envolvidos com XP e tambm devido a sua natureza simples e objetiva por se basear em prticas que j provaram sua eficincia no cenrio do desenvolvimento de software. Essas prticas tm como objetivo entregar funcionalidades de forma rpida e eficiente ao cliente. Alm disso, XP foi criado considerando que mudanas so inevitveis e que devem ser incorporadas constantemente.

Um projeto XP atravessa algumas fases durante o seu ciclo de vida. Essas fases so compostas de vrias tarefas que so executadas. Um projeto XP passa pelas seguintes fases: explorao, planejamento inicial, iteraes do release, produo, manuteno e morte.

A fase de explorao anterior construo do sistema. Nela, investigaes de possveis solues so feitas e verifica-se a viabilidade de tais solues. Os programadores elaboram possveis arquiteturas e tentam visualizar como o sistema funcionar considerando o ambiente tecnolgico (hardware, rede, software, performance, trfego) onde o sistema ir rodar.

A fase de planejamento inicial deve ser usada para que os clientes concordem em uma data para o lanamento do primeiro release. O planejamento funciona da seguinte forma: os programadores, juntamente com o cliente, definem as estrias a serem implementadas e as descrevem em cartes. Os programadores assinalam as dificuldade para cada estria e, baseados na sua velocidade de implementao, dizem quantas estrias podem implementar em uma iterao. Os clientes escolhem as estrias de maior valor para serem implementadas na iterao isso chamado planejamento iterao. O processo se repete at terminar as iteraes do release. O tempo para cada iterao deve ser de uma a trs semanas e para cada release de dois a quatro meses.

Na fase das iteraes do release so escritos os casos de teste funcionais e de unidade. Os programadores vo seguindo mais ou menos o seguinte fluxo de atividades na seguinte ordem escrita dos casos de testes; projeto e refatoramento; codificao; realizao dos testes; e integrao. medida que esse fluxo vai sendo seguido, o sistema vai sendo construdo, depois de terminado o primeiro release, j se ter uma idia melhor das tecnologias e do domnio do problema de modo que as iteraes podero ser mais curtas nos releases subseqentes.

A fase de manuteno pode ser considerada como uma caracterstica inerente a um projeto XP. Em XP voc est simultaneamente produzindo-nos funcionalidades, mantendo 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.

A fase morte corresponde ao trmino de um projeto XP. Existem duas razes para se chegar ao final de um projeto, uma boa e outra ruim. A boa razo quando o cliente j est satisfeito com o sistema existente e no enxerga nenhuma funcionalidade que possa vir a ser implementada no futuro. A m razo para a morte em XP seria a do projeto ter se tornado economicamente invivel, devido a dificuldades de adicionar funcionalidades a um custo baixo e devido a uma alta taxa de erros.

Scrum

O Scrum, usa um conjunto de padres de processo de software, que so adequados para projetos com prazos apertados e requisitos que mudam freqentemente. Cada padro de processo define um conjunto de atividades.

O ciclo de vida do Scrum baseado em trs fases principais:

Pr-planejamento os requisitos so descritos e priorizados no Product Backlog. O planejamento inclui tambm a estimativa de esforo para cada requisito, definio da equipe de desenvolvimento, as ferramentas a serem usadas, os possveis riscos do projeto, as necessidades de treinamento e uma proposta de arquitetura de desenvolvimento baseada na lista de tarefas.

Software desenvolvido sprints, que duram de acordo com o TIME-BOX, e na qual cada equipe recebe uma parte do backlog para desenvolvimento. Sempre apresenta um produto executvel ao final.

Ps-planejamento iniciada quando todos os tpicos so satisfatrio tempo, competitividade, requisitos, qualidade, custo. Atividades: testes de integrao, testes de sistema, documentao do usurio, preparao de material de treinamento, preparao de material de marketing.

O ciclo de vida do Scrum tem o seu ciclo composto por uma srie de iteraes bem definidas, cada uma com durao de duas a quatro semanas, chamadas Sprints. Antes de cada Sprint, realiza-se uma reunio de planejamento em que os membros do time tem contato com o Product Owner para selecionar e estimar os itens do Product Backlog que acreditam conseguir entregar ao final da Sprint. A prxima fase a execuo da Sprint durante a execuo da Sprint, o time controla o andamento do desenvolvimento realizando Reunies Dirias de no mais que 15 minutos de durao, e observando o seu progresso usando um grfico chamado Sprint Burndown.

Ao final de cada Sprint, deve-se realizar uma Reunio de Reviso em que o time demonstra o produto gerado na Sprint e valida se o objetivo foi atingido. Logo em seguida, realiza-se a Reunio de Retrospectiva uma reunio de lies aprendidas, com o objetivo de melhorar o processo, time e/ou produto para a prxima Sprint.

Feature Driven Development

Feature-Driven Development (FDD) uma metodologia gil para o processo de engenharia de software, que foi elaborada com foco na entrega frequente de software funcionando para os clientes e na utilizao de boas prticas durante o ciclo de seu desenvolvimento. Uma caracterstica marcante da FDD o fato dela favorecer fortemente o envolvimento de clientes (interno ou externo) ao processo de planejamento e desenvolvimento do software.

um processo de desenvolvimento de software iterativo e incremental. Diferentemente de outras metodologias, a FDD no extremamente focada na programao ou no modelo, mas sim utiliza o bom senso para abstrair o melhor dos dois mundos.O ciclo de vida da FDD composto de 05 prticas para cada . So elas:

Desenvolver um modelo abrangente: este processo abrange todo o projeto, o que significa que ele ser executado uma nica vez no projeto.

Formar o time de modelagem: este time normalmente composto por especialistas de negcio e programadores, sendo facilitados por um arquiteto com experincia em modelagem.

Conduzir o Domain Walkthrough (Estudo dirigido sobre o domnio): os especialistas de negcio apresentaro ao restante da equipe uma viso do produto. Aps isso, realizaro apresentaes focadas em pequenas partes do negcio.

Estudar documentao: Dependendo da complexidade da rea de negcio apresentada, a equipe pode solicitar um intervalo para estudar a documentao fornecida pelo especialista de negcio.

Desenvolver modelos de pequenos grupos: aps cada apresentao ou estudo, a equipe dividida em pequenos grupos, que elaboraro uma proposta de modelo para aquela parte especfica do negcio que foi apresentada.

Desenvolver o modelo da equipe: as propostas so apresentadas e uma delas, ou uma combinao delas, escolhida por consenso para ser o modelo para aquela parte do negcio apresentada.

Refinar o modelo abrangente: o modelo escolhido incluso no modelo abrangente do produto. Este modelo abrangente o resultado da juno de todos os modelos escolhidos para cada parte do negcio apresentada.

Escrever notas: notas e observaes so includas no modelo abrangente. As atividades vo se repetindo at que tenhamos um modelo abrangente que cubra todas as partes de negcio previstas para o produto.

Construir a lista de funcionalidades: este processo abrange todo o projeto, o que significa que ele ser executado uma nica vez no projeto.

Formar o time da lista de funcionalidades: normalmente, este time composto unicamente pelos programadores chefes que participaram do processo anterior.

Construir a lista de funcionalidades: as partes do produto, que foram identificadas e modeladas no processo anterior, so aqui identificadas como reas de negcio. Dentro de cada rea o time deve conseguir identificar as atividades de negcio daquela rea especfica, dentro destas atividades as funcionalidades que a compem.

Planejar por funcionalidades: este processo abrange todo o projeto, o que significa que ele ser executado uma nica vez no projeto.

Formar o time de planejamento: normalmente este time composto pelo gerente de projeto, gerente de desenvolvimento e programadores-chefes.

Determinar a sequncia do desenvolvimento: o time determina a sequncia do desenvolvimento baseando-se nas dependncias entre elas, a equipe de desenvolvimento tambm na complexidade das funcionalidades a serem implementadas.

Atribuir atividades de negcio aos programadores-chefes: cada programador-chefe fica responsvel por um conjunto de atividades de negcio. Ele ser o programador-chefe de todas as funcionalidades que compem suas atividades.

Atribuir classes aos desenvolvedores: cada classe passar a ter um dono que um programador, ser o responsvel por qualquer manuteno necessria naquela classe. As classes so distribudas pelo time levando em considerao a experincia, carga e sequncia de trabalho de cada desenvolvedor.

Detalhar por funcionalidade: este processo ser executado uma vez para cada funcionalidade.

Formar equipe de funcionalidades: sabendo quais as classes que sero envolvidas no desenvolvimento de determinada funcionalidade, o programador-chefe convoca os desenvolvedores responsveis por cada classe envolvida para fazer parte da equipe.

Estudar documentao relacionada: ainda dependendo do nvel de entendimento do time, pode ser reservado um perodo para ser estudada documentao de negcio e anotaes relacionadas quela funcionalidade.

Desenvolver diagrama de sequncia: o time desenvolve o diagrama de sequncia relacionado aquela funcionalidade.

Refinar o modelo abrangente: j com um maior entendimento do negcio, o time se sente seguro em refinar o modelo abrangente, incluindo mtodos e atributos nas classes envolvidas no desenvolvimento da funcionalidade.

Escrever prlogo de mtodos e classes: Com as informaes geradas pelo diagrama de sequncia, cada programador responsvel por criar os prlogos de suas classes. Isto inclui cabealhos de mtodos com tipagem de parmetros, atributos e outros. Vale lembrar que apenas os prlogos so criados aqui, nada de implementao deve ser realizado.

Inspeo de design: o programador-chefe da funcionalidade deve convidar algum outro membro do time do projeto para avaliar o que foi feito em sua classe durante este processo.

Desenvolver por funcionalidade: este processo ser executado uma vez para cada funcionalidade.

Implementar classes e mtodos: cada desenvolvedor implementa suas classes e mtodos de acordo com a viso abrangente e detalhamento realizado nos processos anteriores.

Inspecionar cdigo: cada desenvolvedor deve convidar algum outro membro do time da funcionalidade ou do projeto para avaliar o que foi feito em sua classe durante este processo.

Teste unitrio: cada desenvolvedor responsvel por executar os testes de unidade nos mtodos de suas classes para garantir o alcance das necessidades do negcio.

Dynamic Systems Development Method

O frameword DSDM consiste de 3 fases seqenciais, nomeadas de pr-projeto, ciclo de vida e ps-projeto. O ciclo de vida a fase mais elaborada das 3. Consiste em 5 estgios que formam o passo-a-passo das iteraes aplicadas ao desenvolvimento do sistema.

1 FaseO Pr-Projeto: so identificados os projetos candidatos, so definidos oramento e assinatura do contrato. Controlando estes critrios antecipadamente pode-se evitar problemas futuros e em estgios mais crticos.

2 Fase

O Ciclo de Vida

Ciclo de vida do DSDM de 5 estgios que um projeto possui para o desenvolvimento de um sistema. Os dois primeiros estgios, Anlise de viabilidade e negcios so fases sequenciais que se completam entre si. Aps a concluso destas fases, o sistema desenvolvido iterativamente e incrementalmente segundo as iteraes do Modelo Funcional, desenho e construo, at implementao.

1 - O Estudo de Viabilidade: durante este nvel do projeto, a viabilidade de utilizao da DSDM para este projeto examinada. Os pr-requisitos para o uso da DSDM so encontrados respondendo a questes como: Pode este projeto ir de encontro s necessidades de negcio apontadas?, , este projeto, adequado ao uso da DSDM? e Quais so os riscos mais importantes envolvidos?. As tcnicas mais importantes utilizadas nesta fase so os workshops.

Para entrega ao cliente, so preparados neste nvel o Relatrio e o Prottipo de Viabilidade que dizem respeito viabilidade do projeto em mos. A estes, adicionam-se um esboo global do plano para o resto do projeto e um Registro de Risco que identifica os riscos mais importantes no projeto.

2 - O Estudo do Negcio: engloba todo o trabalho realizado no Estudo de Viabilidade. Depois do projeto ser declarado fivel para o uso da DSDM, este nvel examina o processo de financiamento, os utilizadores envolvidos e as suas necessidades e desejos respectivos. Uma vez mais, os workshops so uma das mais valiosas tcnicas. Workshops nos quais os diferentes stakeholders se renam e discutam o sistema proposto. A informao retirada destas sesses combinada numa lista de requisitos. Uma importante propriedade desta lista de requisitos a possibilidade de se definir prioridades. Estas prioridades so definidas utilizando uma perspectiva MoSCoW. Baseado neste escalonamento, um plano de desenvolvimento construdo como uma linha mestra para o resto do projeto. Uma importante tcnica utilizada no desenvolvimento do plano a tcnica de Timeboxing2. Esta tcnica essencial para serem atingidos os objetivos da DSDM, nomeadamente a imposio de tempo e oramento fixos, garantindo no entanto a qualidade desejada. Uma arquitetura de sistema outro meio para guiar o desenvolvimento do Sistema de Informao.

No final deste nvel, devero estar prontos para entrega ao cliente uma definio de rea de negcio que descreve o contexto do projeto dentro da companhia, a definio da arquitetura do sistema que fornece uma arquitetura global inicial do SI em desenvolvimento juntamente com o plano de desenvolvimento que reala os passos mais importantes no processo de desenvolvimento. Na base destes dois ltimos documentos est a lista de prioridades dos requisitos. A lista define todos os requisitos do sistema, organizados de acordo com o princpio do MoSCoW. Por fim, o Registro de Risco atualizado com os fatos que foram identificados durante esta fase da DSDM.

3 - Anlise Funcional: os requisitos que foram identificados nos nveis anteriores so convertidos para um Modelo Funcional. A Prototipagem uma das tcnicas chave dentro deste nvel, que ajuda no bom envolvimento do utilizador final com o projeto. O prottipo desenvolvido revisto pelos diferentes grupos de utilizadores. Para assegurar a qualidade do projeto, os testes so implementados em cada iterao da DSDM. Uma importante parte dos testes so realizados na Anlise Funcional. O Modelo Funcional pode ser subdividido em quatro sub nveis:

Identificar Prottipo Funcional: determinar as funcionalidades a serem implementadas no prottipo que resulta desta iterao.

Acordar Calendrio de Tarefas: definir como e quando desenvolver estas funcionalidades.

Criar Prottipo Funcional: desenvolver o prottipo.

Rever o Prottipo: procurar correes possveis no prottipo desenvolvido. Isto pode ser feito atravs de testes com utilizadores finais e revendo a documentao.

Neste nvel, necessrio entregar ao cliente o Modelo Funcional e o Prottipo Funcional que, juntos, representam as funcionalidades que podem ser realizadas nesta iterao, prontas para serem testadas pelos utilizadores. Alm destes dois documentos, a Lista de Requisies atualizada, sendo apagados os itens que foram implementados e repensando as prioridades dos requisitos restantes.

4 - Desenho: o ponto central desta iterao da DSDM a integrao das componentes funcionais do nvel anterior num sistema que satisfaa as necessidades do utilizador. Mais uma vez, os testes so uma das atividades mais importantes. O Desenho pode ser dividido em quatro sub nveis:

Identificar Prottipo de Desenho: identificar requisies funcionais e no-funcionais que so necessrios no sistema testado.

Acordar Calendrio de Tarefas: definir como e quando desenvolver estes requisitos.

Criar Prottipo de Desenho: criar um sistema que possa, com segurana, ser fornecido aos utilizadores finais para um uso dirio.

Rever Prottipo de Desenho: verificar a exatido do sistema desenhado. Mais uma vez, os testes e revises so peas fundamentais.

Ao utilizador, sero entregues o Prottipo de Desenho para que estes efetuem testes ao produto-prottipo.

5 - Implementao: o sistema testado e a sua documentao so entregues aos utilizadores finais que devero comear a ser treinados para a futura utilizao do novo SI. O sistema a ser entregue foi revisto para incluir todos os requisitos que foram definidos nos primeiros nveis do projeto. O nvel de implementao pode ser dividido em quatro sub nveis:

Aprovao do utilizador: os utilizadores finais aprovam o sistema testado para implementao e as linhas mestras para a implementao e uso do sistema so criadas.

Treinar os utilizadores: treinar os futuros utilizadores no uso do sistema.

Implementao: o sistema testado no local de trabalho dos utilizadores finais.

Rever Negcio: rever o impacto do sistema implementado no negcio, um problema central ser tentar compreender se o sistema vai de encontro aos objetivos definidos no incio do projeto. Dependendo disto, o projeto passar para a fase seguinte, o Ps-Projeto ou voltar a uma das fases anteriores para desenvolvimento posterior.

No final deste nvel, o sistema dever ser entregue e instalado, pronto para o uso de todos os utilizadores finais e a Documentao de Utilizao do Sistema dever ser detalhada.

3 Fase

Ps-projeto

Esta fase garante a eficincia e eficcia do projeto. Atravs de manutenes, melhorias e ajustes de acordo com os princpios do DSDM. A manuteno pode ser vista como um contnuo desenvolvimento. Invs de finalizar o ciclo de vida de apenas 1 vez, normalmente o projeto pode retomar fases/etapas anteriores a fim de refinar ainda mais o passo concludo.

Crystal

A famlia Crystal inclui grande nmero de diferentes mtodos que so selecionados de acordo com as caractersticas do projeto a ser desenvolvido. Atualmente, tm-se quatro mtodos, e apenas dois dos mtodos mantm o desenvolvimento de novas prticas para cobrir diferentes tipos de projetos.

Famlia Crystal so identificados por cores, quanto mais escura for a cor do mtodo, maior a complexidade do projeto. Existem algumas caractersticas comuns famlia Crystal, como o desenvolvimento incremental com ciclos de no mximo quatro meses, grande nfase na comunicao e cooperao das pessoas, no limitao de quaisquer prticas de desenvolvimento, ferramentas ou produtos de trabalho e incorporao de objetivos para reduzir produtos de trabalho intermedirios e desenvolv-los como projetos evoludos.

O ciclo de vida desta famlia baseado nas seguintes prticas:

Staging: Planejamento do prximo incremento do sistema. A equipe seleciona os requisitos que sero implementados na iterao e o prazo para sua entrega;

Edio e reviso: construo, demonstrao e reviso dos objetivos do incremento;

Monitoramento: o processo monitorado com relao ao progresso e estabilidade da equipe. medido em marcos e em estgios de estabilidade;

Paralelismo: em Crystal Orange as diferentes equipes podem operar com o mximo paralelismo. Isto permitido atravs do monitoramento da estabilidade e da sincronizao entre as equipes.

Inspees de usurios: so sugeridas duas a trs inspees feitas por usurios a cada incremento;

Workshops refletivos: so reunies que ocorrem antes e depois de cada iterao com objetivo de analisar o progresso do projeto.

Local matters: so os procedimentos a serem aplicados, que variam de acordo com o tipo de projeto.

Work Products: sequncia de lanamento, modelos de objetos comuns, manual do usurio, casos de teste e migrao de cdigo. Especificamente para o Clear, casos de uso e descrio de funcionalidade; Especificamente para o Orange: documento de requisitos.

Standards: padres de notao, convenes de produto, formatao e qualidade usadas no projeto.

Tools: ferramentas mnimas utilizadas.

Crystal Clear: compiladores, gerenciadores de verso e configurao. Para Crystal Orange: ferramentas de verso, programao, teste, comunicao, monitoramento de projeto, desenho e medio de performance.

MODELOS EVOLUCIONRIOS

Modelo Espiral

Este modelo foi desenvolvido para abranger as melhores caractersticas tanto do ciclo de vida clssico como da prototipao, acrescentando, ao mesmo tempo, um novo elemento, a anlise de riscos que falta a esses paradigmas. O modelo define quatro importantes atividades representadas por quatro quadrantes:

1. Planejamento: determinao dos objetivos, alternativas e restries.

2. Anlise de riscos: anlise de alternativas e identificao/resoluo de riscos.

3. Engenharia: desenvolvimento do produto no nvel seguinte .

4. Atualizao feita pelo cliente: avaliao dos resultados da engenharia.

Ele usa uma abordagem evolucionria engenharia de software, capacitando o desenvolvedor e o cliente a entender e reagir aos riscos em cada fase evolutiva. O modelo espiral usa a prototipao como um mecanismo de reduo de riscos, mas, o que mais importante, possibilita que o desenvolvedor aplique a abordagem de prototipao em qualquer etapa da evoluo do produto. Ele mantm a abordagem de passos sistemticos sugerida pelo ciclo de vida clssico, mas incorpora-a numa estrutura iterativa que reflete mais realisticamente o mundo real. O modelo espiral exige uma considerao direta dos riscos tcnicos em todas as etapas do projeto e, se adequadamente aplicado, deve reduzir os riscos antes que eles se tornem problemticos.

O modelo de ciclo de vida espiral apresentado por Boehm em 1988 combina as caractersticas positivas da gerncia (documento associado s fases do ciclo) do modelo de cascata com as fases sobrepostas encontradas no modelo incremental e, tambm,com as verses anteriores de um sistema do modelo de prototipao. O modelo em espiral parte do princpio de que a forma do desenvolvimento de software no pode ser completamente determinada de antemo.

A prototipao vista como um meio de reduo de riscos, a permitir que se descubram os problemas potenciais antes de se comprometer com um sistema completo. O modelo caracteriza-se como um gerador de modelo de processo. Cada ciclo do modelo em espiral possui quatro atividades principais:

Elaborar objetivos, restries e alternativas para entidades de software. Avaliar alternativas com relao aos objetivos e restries, e identificar as principais fontes de riscos. Elaborar a definio das entidades de software em um projeto.

Planejar o prximo ciclo. Abortar um projeto se ele apresentar um alto fator de risco.

Modelo Incremental

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

Modelo de Montagem de Componentes

Desenvolvimento baseado em componentes (CBD), no define o que um componente e restringe-se a dizer que o modelo de desenvolvimento baseado em componentes utiliza paradigma de orientao a objetos baseando-se em uma classe como cdigo reutilizvel, ou seja, o componente. Em orientao a objetos uma classe encapsula dados e algoritmos e este ltimo tambm pode ser usado para manipular os dados.

Caracteriza-se esse modelo como incorporador do modelo espiral com uma abordagem iterativa para a criao de software. Atravs desta abordagem uma biblioteca de classes construda com as classes identificadas no desenvolvimento do software e a partir de ento toda iterao da espiral dever verificar o contedo da biblioteca que pode ser reutilizado ou identificar se novas classes devem ser inseridas na biblioteca para posterior reuso.

Segue passos implantados com uma abordagem evolucionria:

1. Pesquisa e avaliao de componentes disponveis para o domnio em questo.

2. Consideraes sobre a integrao de componentes.

3. Projeto de arquitetura de software.

4. Integrao dos componentes arquitetura.

5. Testes para garantir a funcionalidade adequada.

Modelo de Desenvolvimento Concorrente

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

Modelo Prototipagem

Auxilia o engenheiro de software e o cliente a entenderem melhor o que deve ser construdo quando os requisitos esto confusos. Usado como uma tcnica que pode ser implementada dentro de qualquer modelo.

- Prottipo verso preliminar do software. Pode ser um programa ou no papel.

- Concentra-se na representao dos aspectos do software que so visveis para o cliente.

- Lay-out da interface

- Entradas e sadas

- O cliente tem que concordar que o prottipo ser usado apenas para levantar requisitos.

- O software real ser desenvolvido com olho na qualidade.

- Clico de vida do modelo Prototipagem:

- Obteno dos Requisitos: desenvolvedor e cliente definem os objetivos gerais do software, identificam quais requisitos so conhecidos e as reas que necessitam de definies adicionais.

- Projeto Rpido: representao dos aspectos do software que so visveis ao usurio (abordagens de entrada e formatos de sada).

- Construo Prottipo: Implementao rpida do projeto

- Avaliao do Prottipo: Cliente e desenvolvedor avaliam o prottipo

- Refinamento dos Requisitos: cliente e desenvolvedor refinam os requisitos do software a ser desenvolvido. Ocorre neste ponto um processo de iterao que conduzir primeira atividade at que as necessidades do cliente sejam realizadas e o desenvolvedor entenda o que precisa ser feito.

- Construo Produto: Identificados os requisitos, o prottipo deve ser descartado e a verso de produo deve ser construda considerando os critrios de qualidade.

3 CONCLUSOA criao de um software importante, podemos trocar idias com os funcionrios, com os clientes da empresa, para poder obter mais informaes. Alm de fazer reunies com clientes e funcionrios para um conhecimento melhor e poder desenvolver um software mais confivel e com menos erros.

Podemos conhecer um pouco das tcnicas usada para se desenvolver um bom software, para que o cliente no venha ter problema futuros com a perda de informaes, que o mais importante nas empresas. Aprendendo assim a desenvolver um software usando ou um modelo gil ou evolucionrio, assim o desenvolvimento com certeza ser bem sucedido e deixar o cliente satisfeito.Sendo assim o profissional da rea tem que ser responsvel e seguir os passos o que determinado na construo de um trabalho, executando com perfeio e procurando o mximo de informaes possveis.Agradeo a oportunidade que este trabalho proporcionou para saber sobre desenvolvimento de software. Acrescentara muito conhecimento e aprendizado na minha vida profissional, mostrou que a tecnologia tornou-se uma ferramenta vital para empresas e clientes no mundo de hoje.Desde j agradeo e espero ter correspondido com este trabalho trazendo informaes e um pouco de conhecimento.4 REFERNCIA

FLORES, Emerson Ricardo; TANAKA, Simone Sawasaki; Linguagens e Tcnicas de Programao. So Paulo: Pearson Prentice Hall, 2009.PERINI, Luis Cludio; HISATOMI, Marco Ikuro; BERTO; Wagner Luiz. Engenharia de Software: So Paulo: Pearson Prentice Hall, 2009.

NISHIMURA, Roberto Yukio; Banco de Dados. So Paulo: Pearson Prentice Hall, 2009.TANAKA, Simone Sawasaki; Anlise de Sistemas. So Paulo: Pearson Prentice Hall, 2009.ASSOCIAO BRASILEIRA DE NORMAS TCNICAS.Informao e documentao referncias elaborao: NBR 6023. Rio de Janeiro, 2002a.

______.Informao e documentao numerao progressiva das sees de um documento apresentao: NBR 6024. Rio de Janeiro, 2003a.

______.Informao e documentao sumrio apresentao: NBR 6027. Rio de Janeiro, 2003b.

______.Informao e documentao citaes em documentos apresentao: NBR 10520. Rio de Janeiro, 2002b.

Sistema de Ensino Presencial Conectado

Analise e Desenvolvimento de Sistemas

marcelo pereira de lima

DESENVOLVIMENTO DE

SOFTWARE

Itapuranga

2011

Marcelo Pereira de Lima

DESENVOLVIMENTO DE

SOTWARE

Trabalho apresentado ao Curso Analise e Desenvolvimento de Sistema da Universidade Norte do Paran UNOPAR para disciplina Analise e Desenvolvimento. Aos Professores:

Prof Emerson Ricardo Flores

Prof Luiz Cludio Perini

Prof Simone Sawasaki Tanaka

Prof Roberto Yukio Nishimura

Itapuranga

2011