Fortaleza, Sexta-feira, 29 Março 2024

Tecnologia da Informação

Mostrando itens por tag: RUP

Quinta, 01 Dezembro 2016 10:18

A Análise Essencial de Sistemas

 ANÁLISE ESSENCIAL

 

A Análise Essencial de Sistemas relaciona-se com eventos que interagem diretamente com o sistema. O sistema, por sua vez, possui um conjunto de reações que responderão aos eventos.

O modelo essencial é composto por Diagrama de Contexto, Lista de Eventos, Diagrama de Fluxo de Dados (DFD), Modelo Entidade-Relacionamento (MER) e Dicionário de Dados. Os componentes da Análise Essencial são descritos a seguir:

a) diagrama de contexto, que tem a finalidade de situar o sistema dentro do negócio da empresa, aonde é demonstrada a finalidade principal do sistema, e as entidades que interagem com o sistema;

 Analise Essencial de Sistemas

 b) lista de eventos, que é uma lista textual dos estímulos no ambiente externo aos quais o sistema deve responder;

 c) diagrama de fluxo de dados (DFD), que apresenta os processos e o fluxo de dados entre eles. Os dados fluem de um nódulo de processamento para outro, onde se modificam.

 Analise Essencial de Sistemas

 d) modelo entidade-relacionamento, que fornece uma visão simples e gráfica do sistema para os usuários que não necessitam saber dos detalhes funcionais do sistema;

 e) dicionário de dados, que é um repositório de informações sobre os componentes dos sistemas. Os dicionários de dados fornecem a informação em forma de texto a fim de auxiliar a informação gráfica mostrada no DFD.

 

FIGURA 1 - Exemplo de Diagrama de Contexto

 Analise Essencial de Sistemas

 Analise Essencial de Sistemas
 Analise Essencial de Sistemas

 Conceito

 A Análise Essencial é a técnica que orienta a análise de sistemas para a essência do negócio ao qual se destina independente das soluções de informática que serão utilizadas em sua construção, partindo do princípio de que os sistemas existem independentemente dos computadores, e são feitos visando uma oportunidade de negócio.

 Na Análise Essencial existem dois modelos, denominados de Modelo Essencial e Modelo de Implementação.

 Analise Essencial de Sistemas

 Modelo Essencial

Apresenta o sistema em um nível de abstração completamente independente de restrições tecnológicas. Antes que um sistema seja implementado, é necessário conhecer-se a sua verdadeira essência, não importando saber se sua implementação vai ser manual ou automatizada, e nem mesmo que tipo de hardware ou software vai ser usado. O Modelo Essencial é formado por:

Modelo Ambiental: Define a fronteira entre o sistema e o resto do mundo

Modelo Comportamental: Define o comportamento das partes internas do sistema necessário para interagir com o ambiente;

Métodos Envolvidos: Modelagem de Dados e Modelagem Funcional.

 Modelo Ambiental

O Modelo Ambiental é o modelo que define:

A fronteira do sistema com o ambiente onde ele se situa, determinando o que é interno e o que é externo a ele.

As interfaces entre o sistema e o ambiente externo, determinando que informações chegam ao sistema vindas do mundo exterior e vice-versa.

Os eventos do ambiente externo ao sistema aos quais este deve responder.

Ferramentas para definição do ambiente.

O Modelo Ambiental consiste de quatro componentes:

1.Declaração de Objetivos

2.Diagrama de Contexto

3.Lista de Eventos

4.Dicionário de Dados Preliminar (opcional)

 Declaração dos Objetivos

Consiste de uma breve e concisa declaração dos objetivos do sistema.

É dirigida para a alta gerência, gerência usuária ou outras pessoas não diretamente envolvidas no desenvolvimento do sistema.

Pode ter uma, duas ou várias sentenças, mas não deve ultrapassar um parágrafo.

Não deve pretender dar uma descrição detalhada do sistema.

 Diagrama de Contexto

Apresenta uma visão geral das características importantes do sistema, as pessoas, organizações ou sistemas com os quais o sistema se comunica (Entidades Externas), os dados que o sistema recebe do mundo exterior e que de alguma forma devem ser processados, os dados produzidos pelo sistema e enviados ao mundo exterior e a fronteira entre o sistema e o resto do mundo.

Analise Essencial de Sistemas

Lista de eventos

É uma relação de estímulos que ocorrendo no mundo exterior implicam que o sistema de algum tipo de resposta.

Também pode ser definido informalmente como um acontecimento do mundo exterior que requer do sistema alguma resposta. É um ativador de uma função. É a forma como o evento age sobre o sistema. É a consequência do fato de ter ocorrido um evento externo. É a chegada de um estímulo que indica que o evento ocorreu e isto faz com que o sistema então ative uma função pré-determinada para produzir a resposta esperada.

UM ESTÍMULO: É um ativador de uma função. É a forma como o evento age sobre o sistema. É a consequência do fato de ter ocorrido um evento externo. É a chegada de um estímulo que indica que o evento ocorreu e isto faz com que o sistema então ative uma função pré-determinada para produzir a resposta esperada.

UMA RESPOSTA: É o resultado gerado pelo sistema devido à ocorrência de um evento. Uma resposta é sempre o resultado da execução de alguma função interna no sistema como consequência do reconhecimento pelo sistema de que um evento ocorreu.

Modelo Comportamental

Define o comportamento interno que o sistema deve ter para se relacionar adequadamente com o ambiente.Ou, o Modelo Comportamental é definido do ponto de vista interno, é o modelo interior do sistema. Descreve de que maneira o sistema, enquanto um conjunto de elementos inter-relacionados, reage, internamente, como um todo organizado, aos estímulos do exterior.

Consiste de quatro componentes:

         - DFD Particionado

         - Diagrama ER (DER)

         - Diagrama de Transição de Estado (DTE)

         - Dicionário de Dados Preliminar (opcional)

         - Especificações de processos

Modelo de Implementação

Tem como objetivo definir a forma de implementação do sistema em um ambiente técnico específico. Apresenta o sistema num nível de abstração completamente dependente de restrições tecnológicas.

Simbologia

 Analise Essencial de Sistemas

Conjunto de artefatos gráficos que permitem a montagem de diagramas na análise essencial.

Processo: Conjunto de atividade que produzem, modificam ou atribuem qualidade às informações.
Depósito de Dados: Conjunto de informações armazenadas pelo processo para serem utilizadas por algum processo, a qualquer momento.
Entidade Externa: É algo situado fora do escopo do sistema, que é fonte ou destino das suas informações.
Fluxo de Dados: O nome deve expressar o significado do conjunto de informações que está fluindo.

Vantagens da Análise Essencial sobre a Estruturada

Análise Essencial começa pelo modelo essencial, o que equivale, na Análise Estruturada, começar diretamente pelo modelo lógico proposto.

  • A Análise Estruturada aborda duas perspectivas do sistema - função e dados -, ao passo que a Análise Essencial aborda três perspectivas - função, dados e controle.
  • Na Análise Estruturada o particionamento é feito através da abordagem top-down, enquanto na Análise Essencial, o particionamento é por eventos.

 Fonte: Wikipedia

 DOWNLOAD MODELOS

 

 

Leia Mais... Modelo Versão 1.0 - SGPS Documento de Visão

 

 

Leia Mais... Modelo Versão.1.0 - SGPS Especificacao de CasoUso

 

Publicado em Sistemas
Quinta, 15 Setembro 2016 18:15

RUP - Rational Unified Process

RUP - Rational Unified Process

1 -  INTRODUÇÃO:

Uma metodologia para desenvolvimento de sistemas especifica a sequência de passos a serem seguidos durante o desenvolvimento de um sistema de informação. A cada um destes passos, associa-se um conjunto de atividades, seus produtos e as regras de verificação que garantem a passagem para a próxima fase [Pressman, 2001].

2 - O QUE É RUP (RATIONAL UNIFIED PROCESS)

O RUP - Rational Unified Process (Processo Unificado Rational ), é uma metodologia (ou processo) iterativa, onde cada iteração representa um ciclo completo de desenvolvimento, desde a captação de requisitos na análise até a implementação e a realização de testes, resultando numa versão executável do sistema. Por sua vez, as iterações são agrupadas em fases. Uma fase é o período de tempo entre dois marcos de progresso, onde objetivos são alcançados, artefatos são concluídos e decisões são tomadas em relação à passagem para a fase seguinte.
Criado pela Rational Software Corporation, fornece-nos técnicas a serem seguidas pelos membros da equipe de desenvolvimento de software com o objetivo de aumentar a sua produtividade.
O RUP usa a abordagem da orientação a objetos em sua concepção e é projetado e documentado utilizando a notação UML (Unified Modeling Language) para ilustrar os processos em ação.
É preferencialmente aplicável a grandes equipes de desenvolvimento e a grandes projetos, porém o fato de ser totalmente customizável torna possível que seja adaptado para projetos de qualquer tamanho.
O RUP é na verdade um produto composto de material de referência na forma de páginas HTML, descrevendo toda uma metodologia.

3 - PRINCÍPIOS BÁSICOS DO RUP

O RUP está fundamentado em três princípios básicos: orientação a casos de uso, arquitetura e iteração. Ele é dito dirigido a casos de uso, pois são os casos de uso que orientam todo o processo de desenvolvimento. Com base no modelo de casos de uso, são criados uma série de modelos de análise, projeto e implementação, que realizam estes casos de uso. É centrado em arquitetura, pois defende a definição de um esqueleto para a aplicação (a arquitetura), a ganhar corpo gradualmente ao longo do desenvolvimento. Finalmente, o RUP é iterativo e incremental, oferecendo uma abordagem para particionar o trabalho em porções menores ou mini-projetos. Esses três conceitos são igualmente importantes. A arquitetura provê a estrutura para guiar o desenvolvimento do sistema em iterações, enquanto os casos de uso definem as metas e conduzem o trabalho de cada iteração.

3.1 - Outros Princípios:

  • Atacar os riscos cedo e continuamente;
  • Certificar-se de entregar algo de valor ao cliente;
  • Focar no software executável;
  • Acomodar mudanças cedo;
  • Liberar um executável da arquitetura cedo;
  • Construir o sistema com componentes;
  • Trabalhar junto como um time;
  • Fazer da qualidade um estilo de vida, não algo para depois.


A figura 01 mostra a arquitetura do RUP, que tem duas estruturas (ou dimensões): o eixo horizontal representa o tempo e mostra aspectos do ciclo de vida do processo na medida em que ele se desenvolve. O eixo vertical representa o núcleo das disciplinas do processo, que agrupa as atividades de acordo com a natureza de cada uma. Cada disciplina possui um fluxo de trabalho específico.

4 - A ESTRUTURA DINÁMICA DO RUP

Apesar de parecer um modelo em cascata, na verdade cada fase é composta de uma ou mais iterações, o que se assemelha a um modelo em espiral. Estas iterações são em geral curtas (1-2 semanas) e abordam algumas poucas funções do sistema. Isto reduz o impacto de mudanças, pois quanto menor o tempo, menor a probabilidade de haver uma mudança neste período para as funções em questão.

 

Fases do RUP
figura 01 – Estrutura do RUP

5 - FASES DE DESENVOLVIMENTO O processo de desenvolvimento é dividido em ciclos, sendo que o ciclo de desenvolvimento é subdividido em 4 fases consecutivas. Estas fases são concluídas tão logo uma milestone é alcançada. Uma milestone define uma etapa, na fase, na qual decisões críticas são feitas ou objetivos são alcançados.

            5.1 - Concepção: nesta fase, é estabelecido o escopo do projeto e suas fronteiras, determinando os principais casos de uso do sistema. Esses casos de uso devem ser elaborados com a precisão necessária para se proceder estimativas de prazos e custos. As estimativas devem ser globais para o projeto como um todo e detalhadas para a fase seguinte. Assim, a ênfase nesta etapa recai sobre o planejamento e, por conseguinte, é necessário levantar requisitos do sistema e preliminarmente analisá-los. Ao término dessa fase, são examinados os objetivos do projeto para se decidir sobre a continuidade do desenvolvimento, é nesta fase que é apresentada o plano de projeto, caso de uso inicial e o glossário do projeto, entre outros. ;

            5.2 - Elaboração: o propósito desta fase é analisar mais refinadamente o domínio do problema, estabelecer uma arquitetura de fundação sólida, desenvolver um plano de projeto para o sistema a ser construído e eliminar os elementos de projeto que oferecem maior risco. Esta é a fase mais crítica de todas, pois ao final desta fase a engenharia é considerada completa e os custos para modificação do sistema aumentam a medida que o projeto avança. Do ponto de vista administrativo, é ao final desta fase que um projeto deixa de ser uma operação de baixo risco e baixo custo para se tornar uma operação de alto risco e alto custo.Embora o processo deva sempre acomodar alterações, as atividades da fase de elaboração asseguram que os requisitos, a arquitetura e os planos estão suficientemente estáveis e que os riscos estão suficientemente mitigados, de modo a se poder prever com precisão os custos e prazos para a conclusão do desenvolvimento.

            5.3 - Construção: durante esta fase, um produto completo é desenvolvido de maneira iterativa e incremental, para que esteja pronto para a transição à comunidade usuária.

            5.4 - Transição: nesta fase, o software é disponibilizado à comunidade usuária. Após o produto ter sido colocado em uso, naturalmente surgem novas considerações que vão demandar a construção de novas versões para permitir ajustes do sistema, corrigir problemas ou concluir algumas características que foram postergadas. É importante realçar que dentro de cada fase, um conjunto de iterações, envolvendo planejamento, levantamento de requisitos, análise, projeto e implementação e testes, é realizado. Contudo, de uma iteração para outra e de uma fase para a próxima, a ênfase sobre as várias atividades muda, como mostra a figura 01, em que a cor preta indica grande ênfase, enquanto a cor branca indica muito pouca ênfase. Na fase de concepção, o foco principal recai sobre o entendimento dos requisitos e a determinação do escopo do projeto (planejamento e levantamento de requisitos). Na fase de elaboração, o enfoque está na captura e modelagem dos requisitos (levantamento de requisitos e análise), ainda que algum trabalho de projeto e implementação seja realizado para prototipar a arquitetura, evitando certos riscos técnicos. Na fase de construção, o enfoque concentra-se no projeto e na implementação, visando evoluir e rechear o protótipo inicial, até obter o primeiro produto operacional. Finalmente, a fase de transição concentra-se nos testes, visando garantir que o sistema possui o nível adequado de qualidade. Além disso, usuários devem ser treinados, características ajustadas e elementos esquecidos adicionados.

 6 – A ESTRUTURA ESTÁTICA DO RUP

Além das fases dinâmicas do RUP, existem outros quatro conceitos básicos:

trabalhadores (workers), atividades (activities), artefatos (artifacts) e fluxos de trabalho

(workflows). Eles são agrupados pelas disciplinas relacionadas no eixo vertical da figura 01.

Segundo Kroll e Kruchten (2003), uma disciplina é uma coleção de atividades relacionadas que estão ligadas a uma área de interesse dentro do processo. As disciplinas do RUP são descritas por meio de fluxos de trabalho que mostram uma seqüência significativa de grupos de atividades que produz um determinado resultado. Cada grupo de atividades é descrito por um diagrama de detalhamento de fluxo de trabalho, já que cada fluxo de trabalho envolve uma grande dimensão. Esses diagramas mostram todas as atividades do grupo, os papéis envolvidos e os artefatos de entrada e saída. Um artefato é um produto de trabalho do processo, ou seja, o que é produzido no processo de desenvolvimento e/ ou utilizado por ele (um modelo ou uma classe, por exemplo). Os papéis usam os artefatos na execução das atividades.

Existem nove (9) fluxos de trabalho no RUP, referentes às disciplinas nele definidas, que representam uma partição de todos os trabalhadores e atividades dentro de um agrupamento lógico. São divididos em 6 (seis) fluxos de trabalho de engenharia e 3 (três) de suporte.

Os fluxos de trabalho de engenharia são:

  • Modelagem de Negócio;
  • Requisitos;
  • Análise e Projeto;
  • Implementação;
  • Teste;
  • Implantação.

Os fluxos de trabalho de suporte são:

  • Gerenciamento de Projeto;
  • Gerenciamento de Configuração e Mudança;
  • Ambiente.

7 – TAREFAS:

Cada tarefa é descrita em detalhe, incluindo que papel é responsável por ela, a qual workflow ela pertence e quais são os subprodutos de entrada e saída.

7.1 - Modelo de equipe: Os diversos papéis necessários no projeto são descritos em detalhe. Assim como no MSF, cada papel pode ser representado por mais de uma pessoa, ou uma pessoa pode ter mais de um papel, dependendo da carga de trabalho necessário. Porém o RUP aborda os papéis em um maior nível de detalhe. Ao todo são mais de 30. Exemplos de papéis são: analista de sistemas, analista de negócio, etc.

7.2 - Modelos de documentos: O RUP apresenta modelos e exemplos para os diversos documentos (artefatos) gerados ao longo do projeto. Estes documentos são descritos em detalhe, assim como as tarefas que os geram e as que os utilizam. Para os usuários das ferramentas Rational, existe um recurso adicional e-coach, que orienta o usuário a usar ferramentas como o Requisite Pro passo a passo. Os documentos são totalmente compatíveis com a UML, o que reforça a questão de padronização.

8 – CASOS DE USO

Um caso de uso é uma descrição de como um ator ou vários atores usam um sistema para alcançar um objetivo, incluindo o que o sistema faz para que este intento seja alcançado (BITTNER, 2003).

Phillips e Kemp (2002) afirmam que os casos são primordiais ao RUP porque estabelecem a base para o desenvolvimento, uma vez que provêem a visão funcional (tarefa), modelando o caminho pelo qual um ator interage com o sistema. Essa visão funcional é obtida pela descrição dos requisitos funcionais do sistema a ser construído.

Assim, cada caso de uso deve descrever um uso do sistema e envolve as seqüências de interações, bem como a manipulação de objetos. São representados na UML pelo diagrama de casos de uso, que é detalhado por meio dos fluxos de eventos, na especificação dos casos de uso.

Os casos de uso executam um papel bem mais amplo no RUP, fora do espaço de requisitos, em direção à análise, projeto, implementação e testes de um sistema de software, sendo o RUP, por isso, um processo que tem uma abordagem guiada por casos de uso. Isso significa que os casos de uso definidos para um sistema são a base para todo o processo de desenvolvimento.

Bittner e Spence (2002) definiram um ciclo de vida dos casos de uso, em que estes iniciam com desenhos que os mostram juntamente com seus atores, interagindo com o sistema, durante esses casos de uso. Logo depois, entretanto, eles evoluem, sendo inseridas breves descrições (parágrafos curtos) que resumem o que acontece com cada um deles (chamadas fluxos de eventos). Apesar de essas descrições serem suficientes para esclarecer, são necessárias mais informações. Por isso, através delas são gerados esboços de fluxos de eventos, que irão dar uma indicação do tamanho e complexidade dos casos de uso.

9 – REQUISITOS DO SISTEMA

Como o RUP é guiado por casos de uso e estes especificam grande parte dos requisitos de um sistema de software, além de promover outras atividades do processo unificado, será descrito a seguir o que vem a ser um requisito de sistema, bem como sua importância.

Um requisito de um sistema de software é definido por Dorfmann et al (1990) como uma capacidade do software necessária para o usuário resolver um problema e alcançar seu objetivo, ou, dito de outra maneira, é uma capacidade do software que deve ser encontrada ou possuída por um sistema ou componente para satisfazer um contrato, padrão, especificação ou outro formalismo.

Os requisitos de um sistema de computação são resumidos por Blashek (2002) como aqueles que constituem uma especificação das características e propriedades do sistema ou uma descrição do que o sistema deve fazer, de como ele deve se comportar, bem como das suas restrições de operação.

Enfim, um requisito é tudo o que pode ser descrito como um serviço ou restrição de um sistema, que é derivado de uma ou mais características do sistema a ser construído, as quais devem atender às necessidades de um ou mais usuários.

Existem dois tipos de requisitos: os que são específicos do usuário e os pertinentes a sistema. Os primeiros consistem num informativo (em linguagem natural) do que o sistema deve ter, assim como de suas restrições, enquanto os pertinentes ao sistema determinam o que foi descrito nos primeiros, porém de forma detalhada (como um contrato). Os dois se distinguem somente no nível de detalhes.

Com relação aos requisitos de sistema, que serão, em sua maioria, modelados em diagramas de casos de uso, são divididos em três (3):

9.1 - Requisitos funcionais: aqueles que podem ser formalizados por meio de um modelo de casos de uso e seus fluxos (como visto anteriormente), especificando o comportamento de entrada e saída de um sistema e o que deve ser feito (as funcionalidades) em um sistema;

9.2 - Requisitos não funcionais: descrevem os atributos do sistema ou do ambiente do sistema, especificando ‘como’ deve ser feito. Geralmente, são restrições das funcionalidades oferecidas pelo sistema, como requisitos legais (regulamentos), padrões aplicáveis, atributos de qualidade do sistema, que incluem requisitos de usabilidade, confiabilidade, desempenho e portabilidade, além de outros, como sistemas operacionais e ambientes, requisitos de compatibilidade e restrições de projeto;

9.3 -  requisitos de domínio: são derivados do domínio da aplicação, refletindo características deste domínio.

10 - OS ARTEFATOS:

Numa pesquisa realizada por Souza et al (2004), na busca de identificar os artefatos de maior importância para a manutenção de um software, foram consultados sessenta e sete (67) profissionais com experiência prática em manutenção de software. Nessa pesquisa, os artefatos foram divididos por abordagem, ou seja, em abordagem estruturada e orientada a objetos. Esses requisitos, quer tenham sido listados (na abordagem estruturada), ou formalizados em modelos de casos de uso de suas especificações (na abordagem orientada a objetos), juntamente com o código fonte e os modelos de dados (MER), foram considerados os artefatos mais importantes a serem considerados em uma manutenção de software.

Esse resultado, ainda em Souza et al (2004), comprovou a preocupação dos profissionais da área de manutenção com a identificação de uma maior semântica que os modelos pudessem expressar independente da forma como foram implementados.

Portanto, as documentações dos requisitos de um software, bem como seu gerenciamento podem levar a um processo de manutenção menos desgastante, mais preciso.

Publicado em Sistemas


Insira aqui o seu Nome e E-Mail para receber gratuitamente as atualizações do Blog do Anísio Alcântara

Nós também detestamos SPAM. Prometemos nunca enviar nenhum E-Mail indesejado para sua caixa postal.





| Principal | Contato | Webmail | Notícias | Android App | NASA Ao Vivo | Águias Ao Vivo | Radio FM | TV Assembléia | Livros Grátis |


Copyright © 2012 Anísio Silva de Alcântara. All Rights Reserved.


O Blog do Anísio Alcântara foi publicado no dia 25 de Março de 2012