SISTEMA DE ENSINO PRESENCIAL CONECTADO TECNOLOGIA EM ANÁLISE 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 Análise e Desenvolvimento de Sistemas da Universidade Norte do Paraná – UNOPAR Professores: Polyanna Pacheco Gomes Luis Claudio Perini Roberto Y. Nishimura Anderson E. N. Gonçalves

Palmas - TO 2011

SUMÁRIO 1 2 INTRODUÇÃO ..................................................................................................... 3 DOCUMENTAÇÃO DE CASO DE USO CONTROLAR USUÁRIO ...................... 4

2.1 ATORES .............................................................................................................. 4 2.2 DIAGRAMA DE CASO DE USO CONTROLAR USUÁRIO.................................. 4 2.3 PRÉ-CONDIÇÃO ................................................................................................. 4 2.4 PÓS-CONDIÇÃO ................................................................................................. 4 2.5 FLUXO DE EVENTOS PRINCIPAL ..................................................................... 4 2.6 FLUXO SECUNDÁRIO ........................................................................................ 5 3 TÉCNICA DE MODELAGEM ENTIDADE E RELACIONAMENTO ...................... 6

3.1 ENTIDADE ........................................................................................................... 6 3.2 RELACIONAMENTOS ......................................................................................... 6 3.3 ATRIBUTOS......................................................................................................... 7 3.3.1 Classificação 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 LÓGICO DE DADOS ......................................................................... 10 3.8 MODELO FÍSICO 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 Função 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 Papéis 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 Princípios, Técnicas e Fases do DSDM ...................................................... 23 5.1.4 5.1.5 Feature-Driven Development ...................................................................... 25 Lean Development ...................................................................................... 28

5.2 MODELOS EVOLUCIONÁRIOS ........................................................................ 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

CONCLUSÃO .................................................................................................... 37

REFERÊNCIAS ......................................................................................................... 38

3

1 INTRODUÇÃO Neste trabalho estarei abordando as documentações do Caso de Uso Controlar Usuário; as técnicas de modelagem e relacionamento, atributos e suas classificações e a cardinalidade, bem como os conceitos de modelos de processos de software, dando ênfase aos modelos ágeis e revolucionários.

4

2 DOCUMENTAÇÃO DE CASO DE USO CONTROLAR USUÁRIO Documentação relativa ao Caso de Uso Controlar Usuário, partindo do cenário hipotético de cadastrar usuários de uma biblioteca.

2.1 ATORES Bibliotecário.

2.2 DIAGRAMA DE CASO DE USO CONTROLAR USUÁRIO O Caso de Uso Controlar Usuário é iniciado pelo bibliotecário e tem como objetivo cadastrar o usuário através dos campos e serem preenchidos.

2.3 PRÉ-CONDIÇÃO O bibliotecário deve estar cadastrado no sistema; O bibliotecário deve estar logado no sistema; Para que o cadastro do usuário seja efetuado no sistema é necessário que os fluxos principais sejam preenchidos corretamente.

2.4 PÓS-CONDIÇÃO O cadastro do usuário será realizado.

2.5 FLUXO DE EVENTOS PRINCIPAL 1. Depois de o bibliotecário efetuar logon, será exibida uma tela principal, contendo opções administrativas; 2. Ao escolher a opção administrativa “Cadastrar Usuário” será exibido o ambiente com as seguintes características:

5

Cadastro de Usuário:              Nome Completo* Data de Nascimento* Sexo (M, F)* C.P.F.* R.G. Órgão Expedidor* Estado* Cidade* CEP* Bairro* Logradouro (Rua, Quadra, Conjunto, etc...)* Número* Telefone

[Fluxo Secundário] Botões:   Voltar Salvar

2.6 FLUXO SECUNDÁRIO Caso não seja preenchido algum campo obrigatório, será visualizado um alerta, com os devidos campos a serem preenchidos.

6

3 TÉCNICA DE MODELAGEM ENTIDADE E RELACIONAMENTO 3.1 ENTIDADE Entidade é aquele objeto existente no mundo real, com uma identificação distinta e significado próprio. São as coisas que existem no negócio, ou ainda, que descrevem o negócio em si. Se algo existe e proporciona algum interesse em manter dados sobre ele, isto caracteriza como uma Entidade do negócio. 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 serão 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, são entidades: Cliente, Funcionário, Departamento, fornecedor, etc. Cada entidade representa objetos com as mesmas características. Um banco de dados, portanto, compreende uma coleção de conjuntos de entidades do mesmo tipo.

3.2 RELACIONAMENTOS Geralmente são os verbos, é um conjunto de associações entre as entidades, acontecimento que liga duas entidades existentes no mundo real. O relacionamento pode ser binário ou ternário e é representado através de um losango internamente nomeado e ligado a entidades através de linhas, conforme abaixo:

DEPARTAMENTO

LOTAÇÃO

PESSOA

7

3.3 ATRIBUTOS São propriedades (características) que identificam as entidades. Uma entidade é representada por um conjunto de atributos. Nome, endereço, telefone e cidade, por exemplo, são atributos da entidade Clientes. Enquanto que salário, cargo e departamento são atributos da entidade funcionários. 3.3.1 Classificação dos Atributos Os atributos podem ser simples, composto, multivalorado ou determinante. 3.3.1.1 Atributo Simples Não possui qualquer característica especial: A maioria dos atributos será simples. Quando um atributo não é composto, recebe um valor único como nome, por exemplo, e não é um atributo chave, então ele será atributo simples. 3.3.1.2 Atributo Composto O seu conteúdo é formado por vários itens menores. Ex.: Endereço. Seu conteúdo poderá ser dividido em vários outros atributos, como: Rua, Número, Complemento, Bairro, Cep e Cidade. 3.3.1.3 Atributo Multivalorado O seu conteúdo é formado por mais de um valor. Ex.: Telefone. Uma pessoa poderá ter mais de um número 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, não pode haver dados repetidos. É indicado sublinhando-se o nome do atributo. Exemplo: CNPJ, CPF, Código do fornecedor, Número da matrícula, etc. Os atributos determinantes serão as chaves primárias no banco de dados e seu uso tem implicações na normalização de dados.

8

3.4 RELACIONAMENTO ENTRE ENTIDADES E CARDINALIDADE Relacionamento entre entidades é o tipo de ocorrência existente entre entidades. O símbolo 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 serão relacionadas, há casos em que não há relacionamento entre entidades, nestes casos consideramos como entidades isoladas.

3.4.1 Tipos de Relacionamento Existem três 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

1

1

Chefia

Seção

9

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

Seção

Trabalha

Funcionário

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

Fornecedor

N

N

Fornece

Produto

3.4.2 Cardinalidade A cardinalidade é um conceito importante para ajudar a definir o relacionamento, ela define o número de ocorrências em um relacionamento. Para determinar a cardinalidade, deve-se fazer a pergunta relativa ao relacionamento em ambas as direções. Um departamento possui quantos empregados? - no mínimo 1 e no máximo N. Um empregado está alocado em quantos departamentos? - no mínimo em 1 e no máximo 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 irão acessar o banco de dados e é responsável pelos projetos lógicos e físicos, bem como pela modelagem de dados.

3.6 MODELO CONCEITUAL DE DADOS A modelagem conceitual baseia-se no mais alto nível e deve ser usada para envolver o cliente. Os exemplos de modelagem de dados vistos pelo modelo conceitual são mais fáceis de compreender, já que não há limitações ou aplicação de tecnologia específica. O diagrama de dados que deve ser construído aqui se chama Diagrama de Entidade e Relacionamento, onde deverão ser identificados todas as entidades e os relacionamentos entre elas. Este diagrama é a chave para a compreensão do modelo conceitual de dados.

3.7 MODELO LÓGICO DE DADOS Descreve as estruturas que estarão contidas no banco de dados (as entidades), de acordo com as possibilidades permitidas pela abordagem, mas sem considerar nenhuma característica de um SGBD ou atributo. Neste modelo é onde começamos a organizar melhor os dados que serão armazenados, identificamos os tipos dos atributos e algumas regras básicas que podem ser implementadas dentro do próprio banco de dados. Nesta fase é recomendado que sejam aplicadas as formas normais através do Modelo Relacional Normalizado evitando maiores problemas na fase do modelo físico.

3.8 MODELO FÍSICO DE DADOS No modelo físico fazemos a modelagem física do modelo de banco de dados. Levam-se em conta as limitações impostas pelo SGBD escolhido e deve ser criado sempre com base nos exemplos de modelagem de dados produzidos no item anterior, modelo lógico.

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 criação de aplicativos utilizando o .NET Framework 3.5. o programa faz a verificação, destaque e autocorreção de sintaxe, sugerindo e aplicando retificações em mais de 200 erros comuns de programação. 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 aplicações para a internet. A arquitetura das informações do software foi elaborada para tornar a tarefa de programação mais ágil. As ferramentas são dispostas por ícones ou sub menus, garantindo um número menor de cliques para a localização de uma opção, reduzindo o tempo e tornando o processo de desenvolvimento mais dinâmico. Todos os projetos ficam disponíveis em abas, tornando o desenvolvimento das aplicações mais ágil. O menu direito de cada opção apresenta as propriedades das funções de maneira completa, sendo possível editar e configurar estas opções. A nova função “Split” permite que os desenvolvedores visualizem as funções “Design” e “Source” paralelamente, tornando a manutenção da página 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 programação para Windows. Ele combina o poder do .NET

12

Framework 2.0 com novas tecnologias para construção de aplicativos, possibilitando novas experiências, comunicação integrada e sem fronteiras, além de habilidades para vários 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 seleção de template, clica em Windows Form para a criação 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 necessários.  Clica-se em cima do menu para adicionar opções internas dele, digitando o nome na caixa Type Here.

14

4.4.2 Tela da Função Cadastrar DVD

É através da tela Properties Window que podemos definir as propriedades dos controles que estão na nossa aplicação em tempo de desenvolvimento. As propriedades definem as características do controle, e variam de controle para controle. Vamos ver o exemplo da Label. Clique sobre o Label1 que foi inserido no formulário e dê uma olhada na Properties Window:  Name – define o nome do controle. Através do nome, podemos fazer referência a esse controle por meio do código. É sempre bom colocarmos três caracteres inicias ao nome para que possamos lembrar no código que tipo de controle ele é. Exemplo: lblMensagem .  BorderStyle – define a borda que o controle terá. Por padrão, ele não 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á visível no formulário (True) ou invisível (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 botões, pois quando estão nesse estado não recebem cliques. Existem também os eventos, que são ações às quais os controles respondem em tempo de execução. Os controles podem responder a eventos como clique de botão, passagem do ponteiro sobre o controle, e muitos outros. Existem eventos que são específicos para alguns controles. Podem-se conferir os eventos disponíveis de um controle clicando sobre o mesmo, indo até a Properties Window e clicando no botão “Events“, que possui a figura de um raio. A finalidade dos eventos pode ser deduzida pelo nome, em alguns casos, e sempre há uma descrição do evento selecionado abaixo da lista. ComboBox, selecionando este controle vemos que a janela de propriedades se re-configura e podemos mudar suas configurações:  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 serão usados para a sugestão de auto preenchimento.  BackColor – é a cor de fundo do formulário, 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 várias colunas na tabela, então definimos qual das colunas será a informação que o usuário irá enxergar.  ValueMember – como a DisplayMember define qual informação o usuário ve, aqui definimos qual informação é útil ao sistema, por exemplo o IdUsuario. Ou seja, o valor que aquela informação 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 não, ou seja, se o usuário pode usá-lo ou não.  Location – define a posição Top (distância do controle em relação a margen superior do formulário) e a posição Left (distância do controle em relação a margen esquerda do formulário)  Text – é a informação selecionada. Também 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 usuário para seleção.  Size – define a largura e a altura do controle.

17

5 MODELOS DE PROCESSOS DE SOFTWARE 5.1 MODELOS ÁGEIS Os métodos ágeis diferem largamente no que diz respeito à forma de serem gerenciados. Alguns métodos são suplementados com guias para direcionar o gerenciamento do projeto, mas nem todos são aplicáveis. Uma característica comum dos processos ágeis é a capacidade de funcionar em ambientes muito exigentes que tem um grande número de incertezas e flutuações (mudanças) que podem vir de várias fontes como: equipe em processo de formação que ainda não trabalhou junto em outros projetos, requisitos voláteis, baixo conhecimento do domínio de negócio pela equipe, adoção de novas tecnologias, novas ferramentas, mudanças muito bruscas e rápidas no ambiente de negócios das empresas: novos concorrentes, novos produtos, novos modelos de negócio.

5.1.1 Extreme Programming Extreme Programming (XP) é uma metodologia de desenvolvimento de software, nascida nos Estados Unidos ao final da década de 90. Vem fazendo sucesso em diversos países, por ajudar a criar sistemas de melhor qualidade, que são produzidos em menos tempo e de forma mais econômica que o habitual. Tais objetivos são alcançados através de um pequeno conjunto de valores, princípios e práticas, 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 motivação dos profissionais envolvidos com XP e também devido a sua natureza simples e objetiva por se basear em práticas que já provaram sua eficiência no cenário do desenvolvimento de software. Essas práticas têm como objetivo entregar funcionalidades de forma rápida e eficiente ao cliente. Além disso, XP foi criado considerando que mudanças são inevitáveis e que devem ser incorporadas constantemente. Um projeto XP atravessa algumas fases durante o seu ciclo de vida.

18

Essas fases são compostas de várias tarefas que são executadas. Abaixo será dada uma explicação 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: exploração, planejamento inicial, iterações do release, produção, manutenção e morte. A fase de exploração é anterior à construção do sistema. Nela, investigações de possíveis soluções são feitas e verifica-se a viabilidade de tais soluções. Os programadores elaboram possíveis arquiteturas e tentam visualizar como o sistema funcionará considerando o ambiente tecnológico (hardware, rede, software, performance, tráfego) onde o sistema irá rodar. Com isso, os programadores e os clientes vão ganhando confiança, e quando eles possuírem estórias suficientes, já poderão começar 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 lançamento do primeiro release. O planejamento funciona da seguinte forma: os programadores, juntamente com o cliente, definem as estórias (use case simplificados) a serem implementadas e as descrevem em cartões. Os programadores assinalam uma certe dificuldade para cada estória e, baseados na sua velocidade de implementação, dizem quantas estórias podem implementar em uma iteração. Depois, os clientes escolhem as estórias de maior valor para serem implementadas na iteração – isso é chamado planejamento iteração. O processo então se repete até terminar as iterações do release. O tempo para cada iteração deve ser de uma a três semanas e para cada release de dois a quatro meses. Na fase das iterações do release são escritos os casos de teste funcionais e de unidade. Os programadores vão seguindo mais ou menos o seguinte fluxo de atividades na seguinte ordem (em cada iteração): escrita dos casos de testes; projeto e refatoramento; codificação; realização dos testes; e integração. A medida que esse fluxo vai sendo seguido, o sistema vai sendo construído segundo os princípios, valores e práticas. Depois de terminado o primeiro release, já se terá uma ideia melhor das tecnologias e do domínio do problema de modo que as iterações poderão ser mais curtas nos releases subsequentes e já se podem fazer estimativas mais confiáveis com o que se aprendeu das iterações passadas. A fase de manutenção pode ser considerada como uma

característica 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 código. Mecanismos como: refatoramento, introdução de novas tecnologias, e introdução de novas ideias de arquitetura podem ser utilizados em um projeto XP. É importante ressaltar que a manutenção dada em um sistema que já está em produção deve ser feita com muita cautela, pois uma alteração errada pode paralisar o funcionamento do sistema resultando em prejuízos para o cliente. A fase morte corresponde ao término de um projeto XP. Existem duas razões para se chegar ao final de um projeto, uma boa e outra ruim. A boa razão é quando o cliente já está satisfeito com o sistema existente e não enxerga nenhuma funcionalidade que possa vir a ser implementada no futuro. A má razão para a morte em XP seria a de o projeto ter se tornado economicamente inviável, 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 máximo de valor de negócio no menor tempo.

O SCRUM tem como foco o PDCA (Plan, Do, Check, Act), resultando na melhoria contínua. Inicialmente, ele foi concebido para utilização em projetos de software, que possuem algumas características, tais como:    São empíricos: complexos, caóticos, com detalhes pouco conhecidos. Difícil estimativa de tempo de duração 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 (definição mais adiante) e reflete os trabalhos pendentes do time.

20

5.1.2.1 Papéis e Responsabilidades no SCRUM No SCRUM, os papéis dos participantes em projetos são muito bem definidos. Existem basicamente três papéis no SCRUM: PO (Product Owner), SCRUM Master e o próprio time. A seguir serão detalhadas as características de cada participante:  Product Owner:             Criar e compartilhar uma visão projeto Tomar decisões 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 comunicação 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 essência desse framework e deve ser seguido o mais próximo possível da sua realidade.

21

 Sprint Planning 1          Estimativas da próxima entrega O PO participa

 Sprint Planning 2 Planejamento dentro da equipe O PO não precisa participar

 Daily SCRUM Reunião diária, que engloba: O que fiz desde a última daily SCRUM? O que espero fazer até a próxima 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, lições 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  Formação de profissionais auto gerenciáveis  Maior envolvimento do cliente  Entregas frequentes  Desenvolvimento da equipe (liderança e auto-organização)  Pessoas responsáveis pelos seus atos: na Daily SCRUM o time indica como está; seus impedimentos e, com o suporte do SCRUM Master, torna-se responsável pela sua entrega acordada.  Disseminação da prática de retrospectivas ou lições aprendidas: o que erramos no último sprint e o que podemos melhorar nos próximos sprints?  Foco no cliente: O time entende que sua tarefa é uma parte em um Sprint e veem valor agregado no que estão fazendo  O cliente também se torna responsável nas alterações 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 Informação (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ª versão. Esta metodologia foi desenvolvida por um consórcio de vendedores e peritos no campo dos Sistemas de Informação, no qual partilharam e combinaram as suas melhores técnicas. Assim, a DSDM surge como uma extensão do RAD (Rapid Application Development), focada em projetos de Sistemas de Informação caracterizados por prazos e orçamentos apertados. A DSDM aborda os problemas que frequentemente ocorrem no desenvolvimento de informação que se prendem essencialmente com a falta de tempo, com orçamentos mais apertados ou com outro tipo de razões para que o projeto falhe, tal como a falta de envolvimento dos encarregados do projeto ou dos utilizadores finais.

23

5.1.3.1 Princípios, Técnicas e Fases do DSDM As ideias principais do DSDM podem ser observadas no conjunto de princípios que foram definidos para nortear o método:          O envolvimento ativo do usuário é imperativo. O time deve ter o poder para tomar decisões. O foco é na entrega frequente de produtos. O encaixe ao propósito do negócio é o critério essencial para a aceitação das entregas. O desenvolvimento iterativo e incremental é necessário para convergir com precisão às soluções do negócio. Todas as mudanças durante o desenvolvimento são

reversíveis. Requisitos são alinhados em um alto nível. O teste é integrado por todo o ciclo de vida. Uma abordagem colaborativa e cooperativa entre as partes envolvidas é essencial. É possível notar com esses princípios que o cliente e o negócio são os pontos essenciais do método, enquanto que os aspectos técnicos, como a programação, são pouco abordados, o que fica ainda mais evidente na descrição do processo. Esse enfoque e o fato do DSDM ser visto como um arcabouço faz com que existam soluções para mesclá-lo a outros métodos, sendo possível a utilização em conjunto, por exemplo, com o XP ou o RUP, mas ainda mantendo os princípios definidos no DSDM. Além desses princípios, existem algumas técnicas principais que são usadas durante a execução de um projeto usando DSDM:  Time-boxes: definição de um período fixo para a execução do projeto, colocando até datas de entrega. Com isso, caso haja alguma funcionalidade que não possa ser implementada durante o período estipulado, ela deve ser feita após o desenvolvimento em si (antes da fase de pós-projeto).  MoSCoW: regra básica para a priorização de requisitos durante o período de desenvolvimento. A ideia fundamental

24

é priorizar e implementar

os

requisitos

que sejam

considerados principais, deixando os menos importantes para depois.  Modelagem: não deve ser uma atividade burocrática, sendo usada para prover um melhor entendimento do problema e da solução.  Prototipação: forma de verificar a adequação dos requisitos e facilitar as discussões com o cliente. O protótipo criado deve evoluir juntamente com o projeto.   Teste: essa atividade deve ser executada sistematicamente e de forma contínua durante o projeto. Gerência de configuração: essencial, visto que os produtos são entregues com uma grande frequência. Em relação ao processo do DSDM, existem 5 fases básicas (como mostra a figura abaixo), antecedidas por uma fase de pré-projeto e precedidas pelo pós-projeto. No pré-projeto, tem-se como objetivo definir se o projeto deve ou não ser implementado, observando aspectos gerenciais básicos, como questões monetárias 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 solução mais adequada, além das atividades tradicionais em um estudo desse tipo. Na etapa seguinte, de estudo do negócio, são observados “os processos que serão afetados e as suas necessidades de informação”, definindo o escopo do projeto.

Pré-Projeto

Estudo de Viabilidade

Pós-Projeto

Estudo do Negócio

Modelo Funcional

Implementação

Projeto e Construção

25

Posteriormente é iniciado o desenvolvimento em si, que é executado de forma interativa em cada uma das três fases seguintes: modelagem funcional, projeto e construção e implementação. Como a transição entre essas fases é algo bastante complicado, a decisão de quando e como isso deve acontecer acaba sendo feita de projeto a projeto, podendo haver sobreposição e mescla entre elas. Além disso, a qualquer momento pode haver um refinamento do projeto, fazendo com que se volte a fases anteriores para corrigir problemas, solucionar dúvidas, etc. Na primeira fase de desenvolvimento, que cuida do modelo funcional, os requisitos (funcionais e não funcionais) são obtidos, montando uma lista de prioridades e colocando-os no protótipo, documentando a maioria dessa forma ao invés da textual. No entanto, o foco é apenas a visão básica dos requisitos, uma vez que os detalhes deles serão desenvolvidos na fase de projeto e construção, em que o objetivo é obter o sistema testado. Na fase de feita a transição do sistema do ambiente de desenvolvimento para o operacional, cuidando do treinamento e outras tarefas que sejam necessárias. Ao finalizar as etapas de desenvolvimento com um resultado satisfatório na realização dos requisitos, chega-se a fase de pós-projeto. Nela é feita a manutenção do sistema, realizando as tarefas de alteração 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 utilização de boas práticas durante o ciclo de seu desenvolvimento. Uma característica 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 não é extremamente focada na programação 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) práticas. São 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 negócio e programadores, sendo facilitados por um arquiteto com experiência em modelagem. Conduzir o Domain Walkthrough (Estudo dirigido sobre o domínio): os especialistas de negócio apresentarão ao restante da equipe uma visão do produto. Após isso, realizarão apresentações focadas em pequenas partes do negócio. Estudar documentação: Dependendo da complexidade da área de negócio apresentada, a equipe pode solicitar um intervalo para estudar a documentação fornecida pelo especialista de negócio. Desenvolver modelos de pequenos grupos: após cada

apresentação (ou estudo), a equipe é dividida em pequenos grupos, que elaborarão uma proposta de modelo (sem detalhamento) para aquela parte específica do negócio que foi apresentada. Desenvolver o modelo da equipe: as propostas são apresentadas e uma delas, ou uma combinação delas, é escolhida por consenso para ser o modelo para aquela parte do negócio apresentada. Refinar o modelo abrangente: o modelo escolhido é incluso no modelo abrangente do produto. Este modelo abrangente é o resultado da junção de todos os modelos escolhidos para cada parte do negócio apresentada. Escrever notas: notas e observações são incluídas no modelo abrangente. As atividades vão se repetindo até que tenhamos um modelo abrangente que cubra todas as partes de negócio 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, são aqui identificadas como áreas de negócio. Dentro de cada área de negócio, o time deve conseguir identificar as atividades de negócio daquela área específica e, dentro destas atividades, as funcionalidades que a compõem. 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 sequência do desenvolvimento: o time determina a sequência do desenvolvimento baseando-se nas dependências entre elas, na carga de trabalho da equipe de desenvolvimento e também na complexidade das funcionalidades a serem implementadas. Atribuir atividades de negócio aos programadores-chefes: cada programador-chefe fica responsável por um conjunto de atividades de negócio. Ele será o programador-chefe de todas as funcionalidades que compõem suas atividades. Atribuir classes aos desenvolvedores: cada classe passará a ter um “dono”. Este “dono”, que é um programador, será o responsável por qualquer manutenção necessária naquela classe. As classes são distribuídas pelo time levando em consideração a experiência, carga e sequência 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 serão envolvidas no desenvolvimento de determinada funcionalidade, o programador-chefe convoca os desenvolvedores responsáveis por cada classe envolvida para fazer parte da equipe. Conduzir Domain Walkthrough (Estudo dirigido sobre o domínio): dependendo do nível de complexidade da funcionalidade e de quão clara ela está para a equipe, o programador-chefe pode convocar um especialista de negócio para promover uma apresentação detalhada daquela funcionalidade para a equipe. Estudar documentação relacionada: ainda dependendo do nível de entendimento do time, pode ser reservado um período para ser estudada documentação de negócio e anotações relacionadas àquela funcionalidade.

28

Desenvolver diagrama(s) de sequência: o time desenvolve o(s) diagrama(s) de sequência relacionado(s) àquela funcionalidade. Refinar o modelo abrangente: já com um maior entendimento do negócio, o time se sente seguro em refinar o modelo abrangente, incluindo métodos e atributos nas classes envolvidas no desenvolvimento da funcionalidade. Escrever prólogo de métodos e classes: Com as informações geradas pelo(s) diagrama(s) de sequência, cada programador é responsável por criar os prólogos de suas classes. Isto inclui cabeçalhos de métodos com tipagem de parâmetros, atributos e outros. Vale lembrar que apenas os prólogos são criados aqui, nada de implementação deve ser realizado. Inspeção 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 métodos: cada desenvolvedor implementa suas classes e métodos de acordo com a visão abrangente e detalhamento realizado nos processos anteriores. Inspecionar código: 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 unitário: cada desenvolvedor é responsável por executar os testes de unidade nos métodos de suas classes para garantir o alcance das necessidades do negócio. Promover a build: estando a classe inspecionada e testada, ela então pode ser promovida a build.

5.1.5 Lean Development O Lean Development (LD) é um método baseado na visão da produção Lean, da área de manufatura e processos. Essa forma de produção seria o estágio seguinte à produção em massa, pregando a customização em massa, com a ambição de diminuir consideravelmente os gastos: metade do esforço,

29

o espaço, do investimento em ferramentas, etc. No âmbito do desenvolvimento de software essas propostas seguem a mesma linha, filosofia e ambição. Dessa forma, o LD não se preocupa em pregar práticas de desenvolvimento – ao contrário do XP –, já que seu foco é no ponto de vista estratégico, direcionado primordialmente ao nível gerencial da organização e não ao nível de instrumentação, no caso, os desenvolvedores. A ideia geral dessa forma da produção Lean é a observação dos problemas da mudança de requisitos sob uma nova perspectiva: as decisões do cliente devem ser adiadas ao máximo, deixando para que elas sejam feitas quando houver um maior conhecimento do assunto. E quando as decisões forem feitas, a implementação deve ser rápida, evitando que as condições externas afetem uma funcionalidade antes de ela ser entregue. Por ser uma forma de produção passada para a área de Engenharia de Software, é necessário que ocorra uma adaptação adequada de seus princípios com a preocupação de manter a filosofia para esse outro ambiente de produção. Dessa forma, a seguir são apresentados esses princípios, derivados para a visão do software segundo Poppendieck:  Eliminar o desperdício: ao observar o processo produtivo por inteiro.  Amplificar o aprendizado: aumentando a retroalimentação, através de ciclos rápidos e iterativos.  Atrasar o compromisso: deixar suas opções disponíveis pelo maior tempo possível, para que as decisões sejam feitas com o máximo 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 não seja mais o que o cliente precise ou deseje.  Dê poder ao time: a equipe de desenvolvimento deve ter o poder de decidir, algo necessário devido à rapidez da implementação.  Construa com integridade: o software deve satisfazer ao cliente – realizando o que ele deseja – (integridade percebida), ter um núcleo coeso (integridade conceitual) e manter-se útil com o tempo.

30

 Veja o todo: a visão dos implementadores deve ser do produto como um todo e não apenas de uma parte ou subsistema. Uma adaptação mais prática e voltada para implementação desses princípios para a Engenharia de software é feita por Charette apud Highsmith. Dessa forma, foi interpretada a produção Lean para criar o método de desenvolvimento de software conhecido por LD. A seguir, é colocado o conjunto de princípios que regem esse método: 1. A satisfação do cliente é a maior prioridade. 2. Sempre provenha o melhor valor para o dinheiro. 3. Sucesso depende na participação ativa do cliente. 4. Todo projeto LD é um esforço do time. 5. Tudo pode ser mudado. 6. As soluções devem ser de domínio e não pontuais. 7. Complete, não construa. 8. 80% da solução hoje é melhor do que 100% da solução amanhã. 9. Minimalismo é essencial. 10. As necessidades determinam a tecnologia. 11. O crescimento do produto é o crescimento de características, e não de tamanho. 12. Nunca force o LD para fora de seus limites. Em relação ao processo de desenvolvimento, são definidas três etapas principais: início, o estado de crescimento regular (steady-state), e transição e renovação. No início o foco é “análise de valor ao cliente, o estudo do negócio e projeto de viabilidade”, com isso é feita uma análise 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 períodos fechados (time-boxes) de 90 dias no máximo. Cada iteração realiza um pouco das fases tradicionais de desenvolvimento (análise, projeto, implementação e testes), integrando

continuamente o software. A grande diferença em relação aos outros métodos é a utilização em larga escala de templates (soluções de domínio) para aumentar a velocidade de produção e sua reutilização (condizente com o princípio 7). Na etapa de transição é feita a entrega, focando na documentação e treinamento, pensando ainda na evolução do sistema.

31

5.2 MODELOS EVOLUCIONÁRIOS 5.2.1 Modelo de Montagem de Componentes Desenvolvimento baseado em componentes ou component-based development (CBD) também é conhecido como component-based software engineering (CBSE) ou simplesmente componente de software, não define o que é um componente e restringe-se a dizer que o modelo de desenvolvimento baseado em componentes utiliza paradigma de orientação a objetos baseando-se em uma classe como código reutilizável, ou seja, o componente. Em orientação a objetos uma classe encapsula dados e algoritmos e este último também pode ser usado para manipular os dados. Caracteriza-se esse modelo como incorporador do modelo espiral com uma abordagem iterativa para a criação de software. Através desta abordagem uma biblioteca de classes é construída com as classes identificadas no desenvolvimento do software e a partir de então toda iteração da espiral deverá verificar o conteúdo 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 evolucionária: 1. Pesquisa e avaliação de componentes disponíveis para o domínio em questão. 2. Considerações sobre a integração de componentes. 3. Projeto de arquitetura de software. 4. Integração dos componentes à arquitetura. 5. Testes para garantir a funcionalidade adequada.

5.2.2 Espiral Neste modelo o projeto é atacado como uma série de pequenos ciclos, cada um finalizando uma versão de um software executável. 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 características tanto do ciclo de vida clássico como da prototipação, acrescentando, ao mesmo tempo, um novo elemento - a análise de riscos - que falta a esses paradigmas. Entretanto a integração não se dá através da simples incorporação de características dos modelos anteriores. O modelo em espiral assume que o processo de desenvolvimento ocorre em ciclos, cada um contendo fases de avaliação e planejamento, onde a opção de abordagem para a próxima fase (ou ciclo) é determinada. Estas opções podem acomodar características de outros modelos.

O modelo original em espiral organiza o desenvolvimento como um processo iterativo em que vários conjuntos de quatro fases se sucedem até se obter o sistema final. Um ciclo se inicia com a determinação de Objetivos, alternativas e restrições (primeira tarefa) onde ocorre o comprometimento dos envolvidos e o estabelecimento de uma estratégia para alcançar os objetivos. Na segunda tarefa, análise e avaliação de alternativas, identificação e solução de riscos, executa-se uma análise de risco. Prototipação é uma boa ferramenta para tratar riscos. Se o risco for considerado inaceitável, 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. Variações do modelo espiral consideram entre três e seis tarefas ou setores da espiral, que podem ser:

33

     

Comunicação com o cliente; Planejamento; Análise de risco; Engenharia; Construção e liberação; Avaliação do cliente.

O modelo espiral é atualmente a abordagem mais realística para desenvolvimento de software em grande escala, e usa uma abordagem que capacita a empresa que presta o serviço, e o cliente a entender e reagir aos riscos em cada etapa evolutiva. Este tipo de modelo exige considerável experiência na determinação de riscos e depende dessa experiência para ter sucesso, pode ser difícil convencer os clientes que uma abordagem evolutiva é controlável.  Vantagens deste modelo:  O modelo em espiral permite que ao longo de cada iteração se obtenham versões 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 realística, o processo de desenvolvimento.  Desvantagens:  Pode ser difícil convencer grandes clientes (particularmente em situações de contrato) de que a abordagem evolutiva é controlável.  A abordagem deste tipo de modelo exige considerável experiência na avaliação dos riscos e baseia-se nessa experiência para o sucesso. Se um grande risco não for descoberto, poderão ocorrer problemas.   Este tipo de modelo é relativamente novo e não tem sido amplamente usado. É importante ter em conta que podem existir diferenças entre o protótipo e o sistema final. O protótipo pode não cumprir os requisitos de desempenho, pode ser incompleto, e pode

34

refletir 

somente

alguns

aspectos

do

sistema

a

ser

desenvolvido. O modelo em espiral pode levar ao desenvolvimento em paralelo de múltiplas partes do projeto, cada uma sendo abordada de modo diferenciado, por isso é necessário o uso de técnicas específicas 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 série de grandes atividades técnicas, tarefas e seus estados associados. Define uma série de eventos que podem disparar transições de um estado para outro, para cada uma das atividades de ES. É utilizado para o desenvolvimento de aplicações Cliente/Servidor. Pode ser aplicado a qualquer tipo de desenvolvimento de software e fornece uma visão exata de como está o estado do projeto.

5.2.4 Modelo de Prototipagem O modelo de desenvolvimento baseado na prototipação procura suprir duas grandes limitações do modelo cascata. De acordo com Jalote a idéia básica deste modelo é que ao invés de manter inalterados os requisitos durante o projeto e codificação, um protótipo é desenvolvido para ajudar no entendimento dos requisitos. Este desenvolvimento passa por um projeto, codificação e teste, sendo que cada uma destas fases não é executada formalmente. Usando assim os protótipos o cliente pode entender melhor os requisitos do sistema.

35

A sequência de eventos deste modelo esta exibido na figura abaixo:

O protótipo é desenvolvido com uma versão inicial do documento de especificação dos requisitos. Depois do protótipo estar pronto o cliente o utiliza e baseado na sua avaliação do cliente é fornecido ao as impressões do que precisa ser alterado, o que esta faltando e o que não é preciso. O protótipo é então modificado incorporando as sugestões de mudança e o cliente usa o protótipo novamente repetindo o processo até que o mesmo seja válido em termos de custo e tempo. No final os requisitos iniciais são alterados para produzir a especificação final dos requisitos.  Segundo Pressman e Jalote este modelo pode trazer os seguintes benefícios:  O modelo é interessante para alguns sistemas de grande porte nos quais representem certo grau de dificuldade para exprimir rigorosamente os requisitos    É possível obter uma versão do que será o sistema com um pequeno investimento inicial A experiência de produzir o protótipo pode reduzir o custo das fases posteriores A construção do protótipo pode demonstrar a viabilidade do sistema.  Questões a serem consideradas quanto à utilização do modelo:  A Prototipação deve ser utilizada apenas quando os usuários

36

podem participar ativamente no projeto    Não descuidar de uma boa análise que deve ser conduzida durante todo o processo de prototipação Esclarecer aos usuários que o desempenho apresentado pelo protótipo não necessariamente será o mesmo do sistema final Evitar que o sistema final seja um protótipo em que foram implementados todos os requisitos especificados, pois se corre o risco de ter-se um sistema mal implementado, uma vez que as técnicas utilizadas para desenvolver um protótipo são diferentes daquelas utilizadas na implementação de um sistema (relaxamento de regras de negócio, manipulação de exceções etc.)  Durante a etapa de prototipação, documentar todos os pontos levantados e implementados no protótipo, que não constavam dos requisitos iniciais, para incluí-los na documentação 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 não possui mão de obra disponível no momento para uma implementação completa, dentro do prazo estipulado.

37

6 CONCLUSÃO Através do estudo de um Caso de Uso, temos a oportunidade de visualizar graficamente elementos do mundo real, observando a documentação necessária para compreensão do trabalho a ser realizado. A utilização do modelo Entidade Relacionamento é de suma importância para representação gráfica daquilo que queremos representar facilitando a compreensão daqueles envolvidos na construção do projeto. Não existe um processo correto ou incorreto, como não existe um modelo de desenvolvimento que seja a panaceia universal para o problema do desenvolvimento de software. Dependendo de sua aplicação, ambiente e objetivo, a utilização de um processo ou modelo específico pode ser vantajoso ou não. Cabe a cada organização avaliar o seu problema com cuidado e usar os modelos apresentados como um guia para o desenvolvimento do seu próprio processo de desenvolvimento, onde o objetivo principal é um resultado que demonstre qualidade, tanto no andamento, quanto e principalmente no seu resultado final.

38

REFERÊNCIAS PERINI, Luis Cláudio. Engenharia de software. São Paulo. Editora Pearson, 2009. TANAKA, Simone Sawasaki. Análise de Sistemas I. São 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/

Sign up to vote on this title
UsefulNot useful