Você está na página 1de 41

SISTEMA DE ENSINO PRESENCIAL CONECTADO TECNOLOGIA EM ANLISE E DESENVOLVIMENTO DE SISTEMAS XXXXXXXXXXXXX XXXXXX XXXXXXX XXXXXXXXX

ATIVIDADE INTERDISCIPLINAR - INDIVIDUAL

Palmas - TO 2011

XXXXXXXXXXXXX XXXXXX XXXXXXX XXXXXXXXX

ATIVIDADE INTERDISCIPLINAR - INDIVIDUAL

Trabalho apresentado ao Curso de Tecnologia em Anlise e Desenvolvimento de Sistemas da Universidade Norte do Paran UNOPAR Professores: Polyanna Pacheco Gomes Luis Claudio Perini Roberto Y. Nishimura Anderson E. N. Gonalves

Palmas - TO 2011

SUMRIO 1 2 INTRODUO ..................................................................................................... 3 DOCUMENTAO DE CASO DE USO CONTROLAR USURIO ...................... 4

2.1 ATORES .............................................................................................................. 4 2.2 DIAGRAMA DE CASO DE USO CONTROLAR USURIO.................................. 4 2.3 PR-CONDIO ................................................................................................. 4 2.4 PS-CONDIO ................................................................................................. 4 2.5 FLUXO DE EVENTOS PRINCIPAL ..................................................................... 4 2.6 FLUXO SECUNDRIO ........................................................................................ 5 3 TCNICA DE MODELAGEM ENTIDADE E RELACIONAMENTO ...................... 6

3.1 ENTIDADE ........................................................................................................... 6 3.2 RELACIONAMENTOS ......................................................................................... 6 3.3 ATRIBUTOS......................................................................................................... 7 3.3.1 Classificao dos Atributos ........................................................................... 7

3.3.1.1 Atributo Simples ............................................................................................ 7 3.3.1.2 Atributo Composto ........................................................................................ 7 3.3.1.3 Atributo Multivalorado ................................................................................... 7 3.3.1.4 Atributo Determinante ................................................................................... 7 3.4 RELACIONAMENTO ENTRE ENTIDADES E CARDINALIDADE ........................ 8 3.4.1 Tipos de Relacionamento ............................................................................. 8

3.4.1.1 Relacionamento um-para-um ........................................................................ 8 3.4.1.2 Relacionamento um-para-muitos .................................................................. 9 3.4.1.3 Relacionamento muitos-para-muitos............................................................. 9 3.4.2 Cardinalidade ................................................................................................ 9

3.5 ADMINISTRADOR DE BANCO DE DADOS ...................................................... 10 3.6 MODELO CONCEITUAL DE DADOS ................................................................ 10 3.7 MODELO LGICO DE DADOS ......................................................................... 10 3.8 MODELO FSICO DE DADOS ........................................................................... 10 4 DESENVOLVIMENTO DE PROJETO EM VISUAL STUDIO ............................. 11

4.1 VISUAL STUDIO 2008 EXPRESS EDITION...................................................... 11 4.2 MICROSOFT .NET FRAMEWORK 3.5 .............................................................. 11 4.3 CASO DE USO .................................................................................................. 12 4.4 TELAS NO VISUAL STUDIO ............................................................................. 13

4.4.1 4.4.2 5

Tela Principal do Programa Para Controle de Locadora ............................. 13 Tela da Funo Cadastrar DVD .................................................................. 14

MODELOS DE PROCESSOS DE SOFTWARE ................................................ 17

5.1 MODELOS GEIS ............................................................................................. 17 5.1.1 5.1.2 Extreme Programming ................................................................................ 17 SCRUM ....................................................................................................... 19

5.1.2.1 Papis e Responsabilidades no SCRUM .................................................... 20 5.1.2.2 O Fluxo do SCRUM .................................................................................... 20 5.1.2.3 Vantagens do SCRUM ................................................................................ 22 5.1.3 Dynamic Systems Development Method (DSDM) ...................................... 22

5.1.3.1 Princpios, Tcnicas e Fases do DSDM ...................................................... 23 5.1.4 5.1.5 Feature-Driven Development ...................................................................... 25 Lean Development ...................................................................................... 28

5.2 MODELOS EVOLUCIONRIOS ........................................................................ 31 5.2.1 5.2.2 5.2.3 5.2.4 5.2.5 6 Modelo de Montagem de Componentes ..................................................... 31 Espiral ......................................................................................................... 31 Modelo de Desenvolvimento Concorrente .................................................. 34 Modelo de Prototipagem ............................................................................. 34 Modelo Incremental..................................................................................... 36

CONCLUSO .................................................................................................... 37

REFERNCIAS ......................................................................................................... 38

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

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

2.1 ATORES Bibliotecrio.

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

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

2.4 PS-CONDIO O cadastro do usurio ser realizado.

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

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

[Fluxo Secundrio] Botes: Voltar Salvar

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

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

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

DEPARTAMENTO

LOTAO

PESSOA

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

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

PERTENCE

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

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

Gerente

Chefia

Seo

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

Seo

Trabalha

Funcionrio

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

Fornecedor

Fornece

Produto

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

10

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

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

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

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

11

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

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

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

12

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

4.3 CASO DE USO

13

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

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

14

4.4.2 Tela da Funo Cadastrar DVD

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

15

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

16

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

17

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

5.1.1 Extreme Programming Extreme Programming (XP) uma metodologia de desenvolvimento de software, nascida nos Estados Unidos ao final da dcada de 90. Vem fazendo sucesso em diversos pases, por ajudar a criar sistemas de melhor qualidade, que so produzidos em menos tempo e de forma mais econmica que o habitual. Tais objetivos so alcanados atravs de um pequeno conjunto de valores, princpios e prticas, que diferem substancialmente da forma tradicional de se desenvolver software. O sucesso e popularidade adquiridos por XP se devem

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

18

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

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

19

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

5.1.2 SCRUM SCRUM um processo interativo e incremental para o

desenvolvimento de projetos e utilizado desde 1990. O seu objetivo entregar o mximo de valor de negcio no menor tempo.

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

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

20

5.1.2.1 Papis e Responsabilidades no SCRUM No SCRUM, os papis dos participantes em projetos so muito bem definidos. Existem basicamente trs papis no SCRUM: PO (Product Owner), SCRUM Master e o prprio time. A seguir sero detalhadas as caractersticas de cada participante: Product Owner: Criar e compartilhar uma viso projeto Tomar decises sobre os itens do product backlog Indicar e priorizar itens de backlog Validar a entrega no final do Sprint

Time: Estimar os itens do backlog Desenvolver Auto-organizados para entregar o que o Product Owner quer

SCRUM Master: Contato direto com o Product Owner Cuidar do time Disseminar o SCRUM Garantir comunicao Evitar impedimentos

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

21

Sprint Planning 1 Estimativas da prxima entrega O PO participa

Sprint Planning 2 Planejamento dentro da equipe O PO no precisa participar

Daily SCRUM Reunio diria, que engloba: O que fiz desde a ltima daily SCRUM? O que espero fazer at a prxima daily SCRUM? O que est impedindo o progresso?

Sprint Review Entrega dos artefatos planejados para este sprint. Importante: Presume-se que antes foi definido que este sprint teria algo pronto a ser apresentado Sprint Retrospective Aprendizado, lies aprendidas, discutir sucessos e erros do sprint TIMEBOX: Conceito do SCRUM que obriga que eventos sejam realizados periodicamente

22

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

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

23

5.1.3.1 Princpios, Tcnicas e Fases do DSDM As ideias principais do DSDM podem ser observadas no conjunto de princpios que foram definidos para nortear o mtodo: O envolvimento ativo do usurio imperativo. O time deve ter o poder para tomar decises. O foco na entrega frequente de produtos. O encaixe ao propsito do negcio o critrio essencial para a aceitao das entregas. O desenvolvimento iterativo e incremental necessrio para convergir com preciso s solues do negcio. Todas as mudanas durante o desenvolvimento so

reversveis. Requisitos so alinhados em um alto nvel. O teste integrado por todo o ciclo de vida. Uma abordagem colaborativa e cooperativa entre as partes envolvidas essencial. possvel notar com esses princpios que o cliente e o negcio so os pontos essenciais do mtodo, enquanto que os aspectos tcnicos, como a programao, so pouco abordados, o que fica ainda mais evidente na descrio do processo. Esse enfoque e o fato do DSDM ser visto como um arcabouo faz com que existam solues para mescl-lo a outros mtodos, sendo possvel a utilizao em conjunto, por exemplo, com o XP ou o RUP, mas ainda mantendo os princpios definidos no DSDM. Alm desses princpios, existem algumas tcnicas principais que so usadas durante a execuo de um projeto usando DSDM: Time-boxes: definio de um perodo fixo para a execuo do projeto, colocando at datas de entrega. Com isso, caso haja alguma funcionalidade que no possa ser implementada durante o perodo estipulado, ela deve ser feita aps o desenvolvimento em si (antes da fase de ps-projeto). MoSCoW: regra bsica para a priorizao de requisitos durante o perodo de desenvolvimento. A ideia fundamental

24

priorizar e implementar

os

requisitos

que sejam

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

Pr-Projeto

Estudo de Viabilidade

Ps-Projeto

Estudo do Negcio

Modelo Funcional

Implementao

Projeto e Construo

25

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

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

desenvolvimento de software iterativo e incremental. Diferentemente de outras metodologias, a FDD no extremamente focada na programao ou no modelo, mas sim utiliza o bom senso para abstrair o melhor dos dois mundos.

26

O ciclo de vida da FDD composto de 05 (cinco) prticas. So elas: Desenvolver um modelo abrangente: este processo abrange todo o projeto, o que significa que ele ser executado uma nica vez no projeto. Formar o time de modelagem: este time normalmente composto por especialistas de negcio e programadores, sendo facilitados por um arquiteto com experincia em modelagem. Conduzir o Domain Walkthrough (Estudo dirigido sobre o domnio): os especialistas de negcio apresentaro ao restante da equipe uma viso do produto. Aps isso, realizaro apresentaes focadas em pequenas partes do negcio. Estudar documentao: Dependendo da complexidade da rea de negcio apresentada, a equipe pode solicitar um intervalo para estudar a documentao fornecida pelo especialista de negcio. Desenvolver modelos de pequenos grupos: aps cada

apresentao (ou estudo), a equipe dividida em pequenos grupos, que elaboraro uma proposta de modelo (sem detalhamento) para aquela parte especfica do negcio que foi apresentada. Desenvolver o modelo da equipe: as propostas so apresentadas e uma delas, ou uma combinao delas, escolhida por consenso para ser o modelo para aquela parte do negcio apresentada. Refinar o modelo abrangente: o modelo escolhido incluso no modelo abrangente do produto. Este modelo abrangente o resultado da juno de todos os modelos escolhidos para cada parte do negcio apresentada. Escrever notas: notas e observaes so includas no modelo abrangente. As atividades vo se repetindo at que tenhamos um modelo abrangente que cubra todas as partes de negcio previstas para o produto(ou release). Construir a lista de funcionalidades: este processo abrange todo o projeto, o que significa que ele ser executado uma nica vez no projeto. Formar o time da lista de funcionalidades: normalmente, este time composto unicamente pelos programadores chefes que participaram do processo anterior. Construir a lista de funcionalidades: as partes do produto, que

27

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

28

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

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

29

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

30

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

continuamente o software. A grande diferena em relao aos outros mtodos a utilizao em larga escala de templates (solues de domnio) para aumentar a velocidade de produo e sua reutilizao (condizente com o princpio 7). Na etapa de transio feita a entrega, focando na documentao e treinamento, pensando ainda na evoluo do sistema.

31

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

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

32

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

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

33

Comunicao com o cliente; Planejamento; Anlise de risco; Engenharia; Construo e liberao; Avaliao do cliente.

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

34

refletir

somente

alguns

aspectos

do

sistema

ser

desenvolvido. O modelo em espiral pode levar ao desenvolvimento em paralelo de mltiplas partes do projeto, cada uma sendo abordada de modo diferenciado, por isso necessrio o uso de tcnicas especficas para estimar e sincronizar

cronogramas, bem como para determinar os indicadores de custo e progresso mais adequados.

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

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

35

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

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

36

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

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

37

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

38

REFERNCIAS PERINI, Luis Cludio. Engenharia de software. So Paulo. Editora Pearson, 2009. TANAKA, Simone Sawasaki. Anlise de Sistemas I. So Paulo. Editora Pearson, 2009. http://www.slideshare.net/ricardofrdrc/trgettrust-metodologias-geis-modelos-geispara-anlise-de-requisitos-de-software http://pt.wikipedia.org/wiki/Desenvolvimento_gil_de_software#M.C3.A9todos_.C3.A 1geis_e_o_gerenciamento_de_projeto http://improveit.com.br/xp http://qualiblog.wordpress.com/2009/10/08/uma-introducao-ao-scrum/ http://www.macoratti.net/proc_sw1.htm http://blog.hallanmedeiros.com/2010/03/29/documentacao-de-casos-de-uso/

Você também pode gostar