Conceitos básicos de análise de sistema

1. Desafio

Determinada Incorporadora comercializa terrenos em certa cidade, sua força de venda esta concentrada em corretores cadastrados a Imobiliárias credenciadas diretamente a Incorporadora. Ultimamente com a demanda de compra de terrenos aumentando, houve um investimento para ofertar novas unidades. Com o aumento das vendas surgiu a necessidade de obter um sistema que controle o estoque para que determinado terreno não seja vendido para mais de um comprador. Pense que todo dia a Incorporadora envia uma lista atualizada com os terrenos disponíveis para as imobiliárias que reciprocamente repassa a seus corretores, no decorrer do dia esta listagem não foi atualizada. O que ocorre é que em certos casos os corretores estão vendendo um mesmo terreno para compradores diferentes gerando grande descontentamento aos clientes. Para resolver este problema existe a possibilidade de ser criado um sistema via web com sua infraestrutura instalada na Incorporadora para que os corretores tenham acesso em tempo real ao sistema de vendas para checar se o terreno esta disponível ou não. Estando disponível ele poderá registrar que esta unidade esta reservada e aguardando a finalização da compra. Para isto, o corretor deverá realizar o preenchimento do cadastro do comprador. É importante criar algumas regras com campos obrigatórios para este cadastro. Deverá ser criada uma forma de envio por e-mail ou impressão de uma notificação que este terreno esta em processo de compra para o cliente. Outra regra é que não havendo a finalização da compra em sete dias o terreno automaticamente ficará com o status disponível no sistema e poderá ser novamente reservado. As conexões para acesso ao sistema web deverão ser de inteira responsabilidade das imobiliárias, podendo ser através de modem 3g ou outra tecnologia que julgar melhor.

2. Etapa 01

Aula-tema: Conceitos Básicos sobre Análise de Sistemas: A Importância da

Informação. Conceitos Básicos sobre Análise de Sistemas: Análise Estruturada de

Sistemas

2.1 Passo 01

Fazer a leitura do capítulo do livro texto da disciplina ou dos livros da bibliografia complementar que traz informações sobre introdução a Análise Estruturada de Sistemas e sobre Documento de Especificação para Análise Estruturada de Sistemas.

1. Produzir e entregar para o Professor um resumo sobre a importância do documento de especificação para a Análise Estruturada. O resumo deverá conter entre 200 e 250 palavras.

Resumo: Importância do Documento de Especificação

Aluno: Maycon Wilson da Silva

RA: 8062783862

O Documento de Especificação é o resultado final da análise dos requisitos e das outras atividades da fase de definição de um sistema; antes de falar da importância deste documento, vamos entender melhor a respeito de requisitos e especificação.

O requisito de um sistema é uma condição identificada com o cliente que necessita resolver um problema ou alcançar um objetivo.

A especificação de um sistema é a descrição sistemática do que ele deve executar. A especificação é utilizada para comunicação entre analistas e projetistas do sistema.

Tendo conhecimento dos itens necessários para criação do Documento de Especificação, fica fácil compreender sua suma importância, pois sem ele não seria possível desenvolver um sistema. O documento, uma vez pronto tem que ser entregue ao cliente para validação, gerando consentimento entre clientes, analistas e desenvolvedores; detalhadamente, o documento de especificação contém os requisitos funcionais e de qualidade do sistema, inclui as capacidades, os recursos, os benefícios e os critérios de aceitação. Ele é utilizado dentro do processo de desenvolvimento do software, sendo fundamentalmente organizado.

Definindo, toda a analise estruturada de um sistema e a identificação de todos os requisitos para o desenvolvimento são descritos através de linguagem natural, seguidos por padrões determinados no documento de especificação.

Resumo: Importância do Documento de Especificação

Aluno: Alex Vaz Pedroso

RA: 8873426653

Ter a importância da especificação é reunir dentro de um grupo as técnicas e ferramentas sendo que o foco é a definição do sistema e o seu auxilio. Assim sendo, dentro de cada conceito reunir a metodologia que envolve o desenvolvimento de um sistema utilizando técnicas gráficas. Aplicar durante o processo as ferramentas de análise que são os modelos para a estrutura a ser desenvolvida, como: diagramas, textos, mapas, fluxogramas.

Desenvolver desta maneira é fundamental, pois, terá, por partes, cada uma de suas funcionalidades e a divisão de dados a ser aplicada, ou seja, os seus registros e os procedimentos e funções.

Um dos modelos representados nesta especificação é o Modelo Comportamental que se refere ao comportamento do sistema, ou seja, como ele reage internamente ao processo do seu exterior. Ele possui a sua relação com o Diagrama de Fluxo de Dados, Mini Especificação, Diagrama de Transição de Estado e o Diagrama de Entidade e Relacionamento. Tudo isso indica a junção do contexto em função de cada evento realizado na construção do seu modelo.

Ao realizar uma DFD o seu objetivo é a clareza do seu relatório, economia de representação, o entendimento dos utilizadores e sua comunicação unindo estes fatores principalmente com a equipe de desenvolvimento, e analisar a documentação do projeto desenvolvido.

Em uma Mini Especificação é válido afirmar que ela é representada como o último nível do DFD. Possui conceitos como regras de negócio sobre o seu funcionamento; Regras de Derivação que é a definição de valores (fórmula), ou seja, calculo da receita, quantidade vendida; Regras de integridade, como: não poder excluir um pedido solicitado; Regras de Processo se refere á pedido sem produto em estoque, pedido pendente;

O DTE é representado como uma transformação do sistema através do controle de tempo. A sua tese é caracterizada por obter um Estado onde encontramos o seu comportamento no sistema; Possui sua Transição representada pela passagem do sistema de um estado para outro; e também sua Ação que atua como a atividade do sistema; finalizamos com sua Condição, que é a causa necessária em um decorrer de um evento, reagindo desta forma uma transição de estado.

Entendo que toda análise estruturada e sua especificação é começar diretamente pelo modelo lógico proposto e abordar duas apresentações do sistema que é: função e dados.

Possuir uma facilidade de alteração na hora da sua manutenção. Ter eficiência no tempo de resposta e seus recursos utilizáveis e necessários. Obter segurança e controle quando diz respeito a acesso indevido aos dados e contra destruição da perca de informações. Garantir responsabilidade de correção e entendimento sobre os dados executados, e o registro das mudanças efetuadas (auditoria). Reutilizar componentes no desenvolvimento do sistema e a sua portabilidade, ou seja, ser executável em diversas plataformas. Obter uma visão completa do modelo há ser desenvolvido, iniciando assim o processo de separação das condições do ambiente e sua organização conforme o seu agrupamento.

Resumo: Importância do Documento de Especificação

Aluno: Leandro Souza Santana

RA: 9895555712

De acordo com o que li sobre o Assunto, acredito que o Documento de Especificação tenha extrema importância no processo de elaboração/criação de um software, pois o "Diagrama de Fluxo de Dados” declara a existência dos procedimentos e das interfaces entre eles, mas e o seu conteúdo? Dai entra o Documento de Especificação, ou Especificação de Processos, que podem ser descritos dos seguintes modos: Texto Narrativo, Português Estruturado, Tabelas de Decisão, Árvores de Decisão, Fórmulas Matemáticas e Algumas Combinações das Acima Descritas. A especificação de um processo começa pela sua nomeação, porém é na descrição do processo que o analista deve atentar para atingir o objetivo de fazer uma especificação de processo completa, não ambígua e não redundante.

O documento de Especificação de um software contém todos os requisitos funcionais e de qualidade do software, incluindo as capacidades do produto, os recursos disponíveis, os benefícios e os critérios de aceitação. Este documento serve como um meio de comunicação entre o projetista do software e o usuário, a fim de estabelecer um “acordo” acerca do software pretendido. Deve-se evitar que durante o desenvolvimento do documento de requisitos decisões de projeto sejam tomadas. Assim, devido à importância do documento de requisitos dentro do processo de desenvolvimento do software, é fundamental que este documento seja organizado de forma a melhorar a compreensão e a legibilidade dos requisitos, evitando que problemas e erros surjam na fase de implementação do Software.

Resumo: Importância do Documento de Especificação

Aluno: Roberto de Oliveira

RA: 8219934952

O documento de especificação serve como uma forma de comunicação entre o desenvolvedor do software e o cliente, pois, nesse documento contém todas as informações referente as funcionalidades e características do software de uma forma mais clara e objetiva para ajudar na compreensão do cliente.

Uma das alternativas usada para produzir esse documento de uma forma que seja mais adequada ao entendimento do cliente, seria com imagens gráficas destacando os principais componentes do software sem informações desnecessárias e com auxílio de textos para ajudar a compreender o documento de uma maneira mais clara. Porém, não é tão simples como parece, não tem como o desenvolvedor do sistema saber realmente se o cliente ira entender tudo que foi documentado com o objetivo de facilitar a comunicação entre usuário e projetista ou desenvolvedor, mesmo tentando reduzir as especificações muito técnicas para poder transmitir o que é importante aos olhos do usuário.

Um fato importante referente as especificações que iram conter no documento, é que o desenvolvedor literalmente deve inserir todas as funcionalidades do sistema com extremo detalhe, mas não pode inserir especificações técnicas que não estão aos olhos do cliente, pois, pode acabar tornando mais confuso ao invés de ajudar e facilitar a comunicação com o cliente.

Resumo: Importância do Documento de Especificação

Aluno: Gustavo Henrique da Silva

RA: 8219913874

Um documento de especificação, utilizando o modelo narrativo, gera na maior parte dos casos um documento com muitas palavras, redundante, com difícil leitura e escrita, vários sentidos e interpretações.

Devem cumprir alguns critérios, entre eles estão:

• Ser passível de fraccionamento: Ou seja, devem ser capazes de transmitir muita informação.

• Redução de complexidade: Grande parte dos sistemas modelar são complexos, por isso se reduz em partes simples.

• Focalização em perspectivas especifica: é necessário que haja mais que uma perspectiva.

• Gráficos: apresentam a informação de forma mais rápida, com menos interpretações.

• Moderação na informação: pois cada porção deve apresentar uma quantidade moderada de informação.

• Mais baratos do que algo real: a construção de modelo se torna uma economia de tempo e dinheiro.

Lógicos e não físicos: ignorar aspectos que são dependentes de aspectos físicos diminui a complexidade e garantir que não se tomam decisões de implementação não exatas.

Repetição mínima: quanto menor, mais não se vê a falta de algo e é mais fácil a manutenção do modelo.

Com suporte de detalhe textual: deve-se ter quantidade de texto suficiente para que tudo fique claro.

Existem três tipos de modelos: modelo essencial, ambiental, comportamental e de implementação do utilizador.

Não é sempre que é necessário utilizar várias ferramentas de modelação, quando são usadas suportam umas a outras.

Resumo: Importância do Documento de Especificação

Aluno: Erik Fagundes de Arruda Lobo

RA: 8223949818

O DOCUMENTO DE ESPECIFICAÇÃO DE UM SISTEMA DEVE RECORRER DE MODELOS QUE PREENCHAM AS NESSECIDADES DE UMA EMPRESA.

AS NESSECIDADES DEVE SER LEVANTADAS PELO ANALISTA DE FORMA PRECISA E COM O MAIOR NUMERO DE DETALHES POSSÍVEIS.

A ANALISE ESTRUTURADA É UM MÉTODO DE REQUISITOS DO SOFTWERE, É UMA ATIVIDADE DE CONSTRUÇÃO DE MODELOS.

O SISTEMA É DIVIDIDO EM PARTES FUNCIONAIS E COMPORTAMENTAIS E ASSIM DESCREVE-SE O PROJETO QUE SERÁ CONSTRUIDO.

NA ENGENHARIA DE SOFTWERE É O METODO QUE SE DESTACA-SE ENTRE OS PROFISSIONAIS EM T.I. É REPRESENTADA POR SIMBOLOS QUE PERMITEM CRIAR MODELOS DE FLUXO DE INFORMAÇÃO O BASICO DESSE CICLO DE ANALISE

(CONSEPÇÃO DE SOFTWERE) CRIAR SOLUÇÕES – O QUE A DE ERRADO MELHORIAS A SER REALIZADAS QUAIS SÃO AS PARTES AFETADAS – ESTRATEGIAS PARA MELHORIA NÓS PROCESSOS A FIM DE GANHOS LUCROS ELVADOS COM DESENVOLVIMENTOS.

(ESTUDO DE VIABILIDADE) LEVANTAMENTO DE REQUISITOS UM ESTUDO DE COMPARAÇÃO ESCOLHA DE SOLUÇÕES – TECNICA FERRAMENTAS A DISPOSIÇÃO OS RECURSOS DISPONIVEIS PROPRIOS OU NÃO QUE AJUDAM EM SOLUÇÕES – ECOMOMIA FAZER UM MONTANTE FINANCEIRO A SER IMPREGADO – OPERACIONAL MUDANÇAS NAS ROTINAS EXISTENTES OU A SEREM CRIADAS

(PROJETO LÓGICO) USANDO DIAGRAMA DE FLUXO DE DADOS REDEFINIR E CONFIRMAR AS ETAPAS DOS PROJETOS EXISTENTES ONDE CONTATO ANALISTA X USUARIO SEJA FREQUENTE PARA MELHOR DESENVOLVER O PROJETO E MELHORAR ARGANIZAÇÃO DE CADA ETAPA A SER SEGUIDA.

(PROJETO FISICO) ANALISTA SE PREOCUPA COM O DESEVOLVIMENTO DO PROJETO LÓGICO HARDIWERE E SOFTWERE QUE SERÃO USADOS NO PROJETO

(IMPLANTAÇÃO) UMA DAS FASES MAIS COMPLEXAS ALÉM DA PROGRAMAÇÃO, POIS É NESSE MOMENTO A TECNOLOGIA DEVE SER IMPLANTADA NO AMBIENTE DA EMPRESA. NESTA HORA MUITAS COISAS PODEM ALTERAR O PROJETO INICIAL E PRECISAM SER TRATADAS COM INTELIGENCIA E ALTERNATIVAS PARA NÃO ESTRAGAR RELAÇÃO ALANISTA X CLIENTE.

(MANUTENÇÃO) ONDE AJUSTES ACONTECEM ENCREMENTOS E CORREÇÕES DO PROJETO O ALALISTA NÃO DEVE TER MEDO DESTE MOMENTOÉ NECESSARIO A FIM DE MELHORAR E APRIMORAR A TECNOLOGIA QUE DEVE SER GERENCIADA.

A COMUNICAÇÃO SER O AGENTE PRINCIPAL PARA O SUSSESSO DE UM PROJETO ONDE O ANALISTA E CLIENTE PRECISAM ANDAR INTERAGINDO E SOLUCIOANNDO POSSIVEIS PROBLEMAS O PROCESSO DA COMUNICAÇÃO SÃO ALVOS QUE PRECISAM SER BEM DEFINIDOS PARA QUE NÃO SE PERCA TEMPO CUSTO DINHEIRO E ESCOPO DO PROJETO.

2.2 Passo 02

1. Identificar por meio de leitura e pesquisas na internet as principais ferramentas que apoiam os profissionais de Análise e Especificação de Sistemas na organização dos requisitos iniciais do problema. Produzir e entregar para o professor um resumo sobre este assunto.

Realizar a leitura de arquivo: Introdução à Engenharia de Requisitos. Disponível em: <https://docs.google.com/file/d/0B7u8Pce2Xh_8TWttN1BWOGJ4WUU/edit?us

p =sharing>. Acesso em: 13 abr. 2013.

Resumo: Técnicas para analise de requisitos. “Vantagens e Desvantagens”.

A forma mais fácil de definir os requisitos iniciais para resolver um problema criando um software que atenda às necessidades do cliente, seria através de entrevistas e questionários com o próprio cliente ou usuário, podendo assim ter uma base para definir os requisitos iniciais do projeto. Porém podemos encontrar dificuldades nessa fase, pois, nem sempre o cliente sabe o que quer realmente ou não consegue expressar de forma clara o que deseja podendo levar a outras interpretações chegando a causar conflito de informações para as partes interessadas.

Deve ser feito um estudo para verificar a viabilidade do software, se o domínio que o cliente tem irá suportar a execução do sistema e não ter problemas posteriores e até maiores gastos para reparar o erro de planejamento, e ao invés de conseguir algo que para ajudar a solucionar o problema da empresa ter um software inativo causando mais transtornos para organização. É importante verificar se o sistema deverá interagir com outros sistemas já existentes na empresa, se a execução do software irá suportar esse tipo de funcionalidade ou será utilizada de forma individual sem a necessidade de ajustes referente a interações com outros sistemas. Para obter um bom resultado referente a essas questões, nada melhor que entrevistar os usuários do sistema atual que está ativo e os usuários do sistema que será implementado, técnicos que estejam familiarizados com as tecnologias envolvidas, responsáveis pelo setor e manutenção do software.

Mediante ao exposto acima podemos dizer que os requisitos iniciais de um software são:

• Requisitos Funcionais – Para verificar se as funcionalidades do software irá atender a necessidade de automatização do cliente

• Requisitos Operacionais – Para verificar as especificações de características referente ao processamento do software como: frequência, estabilidade, desempenho, entre outras.

• Requisitos de Contingência – Para verificar outras formas de funcionamento caso ocorra alguma falha ou inoperância esporádica na execução do software.

• Requisitos Técnicos – Restrições quanto a arquitetura tecnológica, portas de comunicações, domínios, linguagens, entre outras.

Com essas informações fica mais fácil trabalhar com o cliente e desenvolver o sistema de uma forma que atenda todas as suas necessidades evitando que ocorra muitas falhas ou transtornos posteriores.

2.3 Passo 03

Identificar por meio de pesquisas na internet os principais métodos de comunicação usados pelos analistas para obtenção das informações sobre o projeto. Realizar leitura do seguinte artigo: Definição de requisitos de software baseada numa arquitetura de modelagem de negócios. Disponível em:

<https://docs.google.com/a/aedu.com/file/d/0B7u8Pce2Xh_8VGh0U0RSVEVIVk0/edit?usp=sharing>. Acesso em: 13 abr. 2013.

1. Produzir e apresentar para o professor em forma de Relatório 1 - Análise Inicial, contendo as seguintes informações:

2.1 Descrever quais são as necessidades do negócio.

2.2 Elaborar um questionário com as necessidades internas e externas para entrevistas com os envolvidos no processo.

2.3 Descrever os requisitos necessários para atender e atingir a metas da solução.

Relatório 1 – Análise Inicial

Necessidades do negócio.

Desenvolver, identificar, modelar e alinhar, com organização, de acordo com os sistemas de informação, o levantamento de requisitos, com os objetivos reais deste negócio. Analisar os requisitos com orientação e objeto, através de uma modelagem UML (Unified Modeling Language) chamado Caso de Uso, isso integra a representação de dois domínios, negócio e software. Válido observar que, a forma de representação não é um ponto comum nas propostas de negócio com a UML. Ela possui duas linhas distintas: a que defende a representação e definição de requisitos através de caso de uso e a que discorda de tal representação, propondo que se faça primeiramente a modelagem dos processos e só depois definam os requisitos de sistema de informação através de casos de uso.

Com o uso da UML, usaremos a linguagem produzida para o seu desenvolvimento, que é a ampliação de maneira controlada, isto é,através do seu mecanismo de extensão capaz de expressar todos os modelos possíveis em qualquer domínio de análise.

As atividades para o processo do negócio terá sua definição para resolução tanto de entrada como de saída, ou seja, teoricamente, adicionar um valor e criar um resultado que seja mais útil e eficiente ao cliente que recebe o serviço ou produto. Fazer uma análise para a empresa em termos de negócio, sem se preocupar com uma visão organizacional, pois, isso facilita a definição do contexto onde o sistema de informação irá atuar. Para a empresa ser adaptável a esta mudança é necessário que tenha um relatório simples e unificado.

Usar a UML como arquitetura de modelagem terá sua atenção em vários aspectos significativos, como: visão de negócio, processo, estrutura e comportamento, ou seja, teremos o Diagrama de Processos de Negócio e o Diagrama de Linha de Montagem, sendo assim, um papel importante na ligação entre requisitos de negócios e casos de uso. O primeiro é descrito os processos de forma principal a respeito dos objetos, que é: objetivos, entradas, saídas, fornecedores e controles. Já o outro diagrama mostra um número de pacotes horizontais chamados de linha de montagem, que pode ser uma classe específica ou diferente.

Um pacote de linha de montagem é estereotipado através da UML desenhado como um longo retângulo horizontal. Já o diagrama é usado como técnica de levantamento de casos de uso do sistema ou de sistemas que darão suporte aos processos de negócio.

A negociação em termos de uso corresponde a processos de negocio e clientes, pois, são bem representados pelos casos de uso para representar um domínio fechado, ou seja, determinar requisitos de usuários e não podem ser vistos como requisitos de clientes.

Sobre a UP (Processo Unificado) que é outra modelagem de arquitetura, com a aplicação técnica de Eriksson e Penker (2000) é correto afirmar que o bom desenvolvimento do software é à base da definição de várias metodologias encontradas no mercado, pois, ela determina um conjunto de atividades necessárias para transformar requisitos em sistemas de software. Neste caso, através desta união com a UML, ela utiliza a linguagem de modelagem para o desenvolvimento do software. São exibidos conceitos sistemáticos quando se diz respeito a questões relacionadas com a identificação de casos de uso de negócio. Entretanto, a UP é fundamental em três excelentes práticas: centrado em arquitetura, iterativo e incremental.

Encontramos na UP a sua divisão com quatro fases sequenciais: Concepção, Elaboração, Construção e Transição, e, cada fase é uma determinada meta a ser atingida em se tratando de desenvolvimento. No caso da concepção, há o destaque quando se refere à identificação dos requisitos, mas não para a especificação detalhada. Já a elaboração requer grande concentração e esforço, pois, exige detalhes sobre a especificação de requisitos na atividade.

Vamos integrar nos workflow as definições estabelecidas pela UP a respeito de suas modelagens: Objetivos do negócio – identificar os principais objetivos em uma estrutura hierárquica para sua visualização, com base nas entrevistas realizadas com os conhecedores do negócio. Isso resulta em um Diagrama de Objetivos. Processos de negócio – defini a realização dos objetivos com ênfase no auxilio dos objetivos de negócio, mas não são relacionados necessariamente; as entrevistas com os envolvidos também deve ser realizada. Isso resulta em um Diagrama de Processos de Negócio. Recursos Envolvidos – ter uma estrutura de informações de como modelar separadamente as atividades sobre a modelagem do processo de negócio, sendo assim, entender cada termo relacionado. Isso resulta em um Diagrama de Modelos de Recursos, Informações e de Organização. Comportamento dos Recursos – facilitar o processo de vendas quando o pedido destacado for alterado, aberto e confirmado ao cliente.

Entende-se que será tal objeto como: pedido solicitado, verificação em estoque, produção, expedição e entrega. Sempre cumprindo as mudanças para facilitar a identificação no processo. Isso resulta em um Diagrama de Recursos e Diagramas de Interação de Recursos e de Estados. Definir Papéis e Responsabilidades - em cada etapa tem que ter um responsável, mas geralmente, não ficará apenas em uma organização, mas passará por mais de uma delas. Pois, dependendo do processo pode envolver um ou mais atores, mas é certo definir quem vai agir em cada uma das atividades. Isso resulta em Tabela de Papéis e Responsabilidades.

Na concepção dos Objetivos de Negócios é abordar todos os objetivos, e sua elaboração é atualizar possíveis esclarecimentos.

Os Processos de Negócio, quanto a sua concepção é identificar os principais recursos, como: entrada, saída, fornecedores. Já na elaboração é detalhar o que será abordado em relação ao fluxo atual.

Sobre os Recursos Envolvidos, referente à sua concepção, é identificar através do Processo de negócio, tais recursos e suas propriedades. Quanto à elaboração, é identificar detalhadamente cada processo do negócio.

No Comportamento dos Recursos, a concepção exerce sua função referente a alterações que pode haver durante o processo. Já na elaboração, é apenas detalhar na fase de concepção o movimento a respeito dos processos.

O Definir Papéis e Responsabilidades têm a sua concepção justamente sobre definir tarefas durante o processo do negócio, sejam eles nas suas funções e organizações.

Lembrando que no Workflow vamos identificar as Necessidades de Informatização, pois, ele dará todo o suporte, caso, identifique a possível necessidade de novos sistemas. Na concepção é utilizado o Diagrama de Linha de Montagem para dar apoio ao desenvolvimento da atividade. O seu início é representado com as informações e referencias já existentes para identificar operações que não estão sendo mantidas pelo sistema de software disponível. No entanto, sua fase de Elaboração, atualiza e vem aprofundar cada vez mais as descrições dos processos, principalmente aos sistemas realizados, sempre obtendo um escopo para um sistema identificado. Cada atividade realizada deve ser informatizada e sempre respeitando o conceito que será realizado através da linha de montagem.

Inicia-se então a Descrição do Fluxograma da Fase Concepção. Entrevistar o cliente para a modelagem do negócio, obtendo informações retiradas num registro de reunião, contendo o esboço do diagrama;

Analisar o negócio e fazer uma documentação das informações obtidas na reunião; modelar todos os recursos envolvidos e definir papéis e responsabilidades; registrar e documentar termos no glossário pra expressar os conceitos no negócio; registrar especificações de alguns requisitos não funcionais, quando se refere a segurança e performance.

Validar Ánalise com o Cliente nas reuniões para apresentar a ánalise do negócio, tudo isso quando se refere a levantar e especificar requisitos.

Definir a arquitetura de software, como modelo de pacotes, modelo de classes, componentes, implantação, incrementar glossário, especificação suplementar e modelos de Casos de uso;

Validar arquitetura geral do sistema com o cliente; elaborar um cronograma; elaborar orçamento e formalizar a prestação de serviço, isto é, a assinatura de um contrato junto com o cliente.

Inicia-se então a Descrição do Fluxograma da Fase de Elaboração. Definir subdomínios na arquitetura de software; levantar requisitos quando for entrevistar o cliente sobre Casos de uso já existentes; analisar cada modelo e elaborar as atividades propostas; especificar requisitos quanto a sua colaboração das atividades; desenvolver mapa de navegação (interface), dentre essas quais serão as páginas da web; desenvolver modelos de estados aplicando apenas quando houver mudança ao longo da execução do processo; ajustar modelo de classes para desenvolver modelo de dados para corresponder ao modelo relacional;

gerar um registro de reunião para validar os modelos de análise; atualizar arquitetura do negócio com novas informações.

Inicia-se então a Descrição do Fluxograma da Fase de Construção. Definir o planejamento respeitando o prazo estabelecido no Cronograma Geral; descrever os testes que serão feitos na realização do projeto; Implementar atividades tanto de Componentes como Banco de Dados; fazer os testes dos componentes com base no Plano de testes; atualizar especificações suplementares, glossário, Casos de Uso, Modelo de Classes, Mapa de Navegação, Modelo de Estados e Modelo de Dados; integrar componentes e realizar testes sempre verificando a participação entre eles; desenvolver manual do sistema para os usuários com suas funcionalidades e explicações para a realizações operacionais.

Inicia-se então a Descrição do Fluxograma da Fase de Transição. Documentar de acordo com a plataforma testada suas limitações e soluções encontrada nos testes; desenvolver um planejamento para a implantação do sistema construído; implantar e instalar Hardware e Software de acordo com a infra-estrutura do cliente; treinar usuários para o acesso ao novo sistema; preparar o ambiente organizacional para ser implementado o sistema; conforme o Plano de Testes, realizar os testes no ambiente de produção; planejar a manutenção e sempre que necessário voltar a uma das quatro fases do desenvolvimento, que é: Concepção, Elaboração, Construção ou Transição.

Questionários

Questionário para Incorporadora

1. Qual a importância da realização de cadastro do sistema?

a) Muito Importante

b) Importante

c) Pouco Importante

2. Qual a importância da frequência de atualização do estoque?

a) Muito Importante

b) Importante

c) Pouco Importante

3. Qual a importância do acesso rápido e fácil ao sistema?

a) Muito Importante

b) Importante

c) Pouco Importante

4. Qual a importância de alerta gerados pelo sistema, no processo de venda?

a) Muito Importante

b) Importante

c) Pouco Importante

5. Qual a importância da estabilidade do sistema?

a) Muito Importante

b) Importante

c) Pouco Importante

Questionário para as imobiliárias

1. Qual a importância de comunicação em tempo real com a Incorporadora?

a) Muito Importante

b) Importante

c) Pouco Importante

2. Qual a importância de controlar todas as vendas de terrenos em tempo real?

a) Muito Importante

b) Importante

c) Pouco Importante

Questionário para os vendedores

1. Qual a importância de obter dados de estoque sempre atualizados?

a) Muito importante

b) Importante

c) Pouco Importante

2. Qual a importância de registrar notificações e receber alertar sobre os processos de vendas dos terrenos?

a) Muito Importante

b) Importante

c) Pouco Importante

Questionário para os clientes

• Qual a importância de comprar um terreno de forma rápida?

a) Muito importante

b) Importante

c) Pouco Importante

Requisitos funcionais, não funcionais e de domínio

• Requisitos Funcionais

o Cadastro de terrenos

o Cadastro de Imobiliárias

o Cadastro de Vendedores

o Controle de Vendas

• Requisitos Não Funcionais

o Notificações por e-mail

• Requisitos de Domínio

o Servidor de aplicação Web

o Alta velocidade de conexão com a internet

2.4 Passo 04

1. Realizar o estudo de viabilidade operacional levando em consideração as funcionalidades que o sistema deverá cumprir dentro do processo apresentado pelo desafio. Relatório 2 - Estudo de viabilidade Sistema de Vendas. O relatório deverá ser entregue ao Professor usando a forma de tabela.

Relatório 2 – Estudo de Viabilidade de Vendas

Tabela1 – Viabilidade Técnica

Requisitos Funcionais Usuario Admin Tecnologia Usada Vantagens Desvantagens Conclusão

1 Gestão de Vendas Sim(imolibiliario) sim(incorporadora) web (html\css\javascript) - ASP, PHP. Maior suporte, atualização instantanea, usual Falta de segurança, instabilidade Venda em tempo real, controle abrangente

1.1 Definição Banco de Dados Não Sim Mysql Open Source Nivel Biaxo de Segurança Mysql, open souce e capacitação de integração

Oracle Segurança Mão de Obra escassa

SlqServer Suporte Não Portavél

3. Etapa 02

Aula-tema: Metodologia para Coleta de Dados e Informações: O Levantamento de

Dados e de Fatos, Seminários, Questionários e Observação Pessoal. Metodologia

para Coleta de Dados e Informações.

3.1 Passo 01

Fazer a leitura do capítulo do livro texto da disciplina ou dos livros da bibliografia complementar que traz informações sobre Análise de Requisitos.

Ler artigo: Técnicas para levantamento de Requisitos. 2012. Disponível em:

<https://docs.google.com/a/aedu.com/file/d/0B7u8Pce2Xh_8MXZiTjFsdWRpUVE/edit?usp=sharing>. Acesso em: 14 abr. 2013.

1. Produzir e entregar para o professor um resumo sobre a importância da análise de requisitos.

Importância da Analise de Requisitos

Entender a analise de requisitos é saber a condição ou capacidade que o software deverá atender. No desenvolvimento de um software é importante entender as necessidades dos clientes, respondendo as seguintes perguntas: O que deverá ser feito pelo sistema? Como? O obtido? Isso atende a necessidade?

No inicio, em um desenvolvimento de um software, contém as seguintes atividades: compreensão do domínio, coleta de requisitos, classificação, resolução de conflitos, definição das prioridades e verificação de requisitos.

Um requisito não é suficiente para o desenvolvimento de um sistema, mas serve para se ter o entendimento das reais necessidades do cliente.

Provavelmente o programador não saberá produzir de forma completa o software esperado, faz-se necessário a especialização. Para que se tenha necessidades e características que sejam projetadas, implementadas e testadas. Aqui é encontrada umas das dificuldades encontradas no levantamento de requisitos, que é: quando o usuário não sabe o que quer ou sabe e não consegue transmitir para o analista. Identifica-se um levantamento adequado, aquele que tem uma definição do projeto, de informações necessárias, para que se de um retorno e soluções inteligentes.

Quando se tem um levantamento inadequado se tem um retorno pobre com conclusões comprometidas, custos elevados, prazos vencidos, entre outros. Os requisitos podem ser divididos em funcionais e não funcionais

Os funcionais mostram o comportamento do sistema, detalhando os resultados de entrada e saída. Descreve o que o produto deve ter para satisfazer uma necessidade. Sendo que se devem ter detalhes suficientes para que se construa um produto correto, com o mínimo necessário de explicações do analista. Os requisitos funcionais se dividem em:

• Usabilidade: atende a fatores humanos, como estética, fácil aprendizado, entre outros.

• Confiabilidade: relacionado a frequência e severidade de uma falha, recuperação e precisão.

• Performance: são condições impostas a determinados requisitos funcionais.

• Suportabilidade: relacionada a testabilidade, facilidade de manutenção e execução em diferentes plataformas operacionais.

Sempre é importante conversar com os envolvidos, que tenham algum interesse no projeto. No inicio do projeto, é necessário que se escolha a técnica para o requisito. O desenvolvimento se baseará na técnica escolhida, será feito solicitações de melhorias e relatos de defeitos.

Para um sistema simples, existem muitos pontos de vista diferentes que devem ser considerados. Os diferentes pontos de vista a respeito de um problema ‘veem’ o problema de modos diferentes. Entretanto, suas perspectivas não são independentes, mas em geral apresentam algo em comum, de modo que apresentam requisitos comuns. Utilizam para estruturar e organizar o processo de levantamento e os próprios requisitos.

A engenharia de requisitos é utilizada para estruturar e organizar o processo de levantamento e os próprios requisitos. Abaixo estão algumas técnicas:

• Etnografia - A etnografia é uma técnica de observação que pode ser utilizada para compreender os requisitos sociais e organizacionais.

• Workshop - É uma técnica de obtenção de dados em grupo usada em uma reunião estruturada.

• Prototipagem - Técnica que usa protótipos consegue explorar detalhes de um produto, podendo ser mostrado um subconjunto de funcionalidades do produto.

• Entrevistas - Através de uma entrevista, técnica mais simples, mas que produz resultados. O entrevistador da espaço para o entrevistado, tendo que ser cumprido o plano de entrevista.

• Questionário - Os questionários são interessantes e podem fornecer um feedback rápido, pois possuem o formato "pergunta - reposta", entretanto, deve ser usado como uma forma de complementar, afim de quantificar o que foi levantado em entrevistas, mostrar que opiniões são difundidas ou limitadas.

• JAD - É uma técnica onde gera a união, pois promove a cooperação, entendimento e trabalho em grupo entre usuários desenvolvedores.

Normalmente as solicitações aparecerão de forma classificada como desnecessárias, mas teve ser analisada de forma criteriosa.

3.2 Passo 02

Identificar por meio da leitura do Passo 1 Tópico 2 a Técnica mais adequada para elaborar uma analise de requisitos. Elaborar um resumo que descreva um comparativo com as vantagens e desvantagens de cada uma das técnicas que o texto apresenta.

3.3 Passo 03

Realizar a leitura do Capítulo 4 do arquivo: A Engenharia de Requisitos Orientada a Aspectos. Disponível em:

<https://docs.google.com/file/d/0B7u8Pce2Xh_8OFVVUGNrUUllSU0/edit?usp=sharing>. Acesso em: 13 abr. 2013.

Identificar por meio da leitura do Tópico 1 os requisitos funcionais e não funcionais do sistema.

1. Construir resumo e representá-lo por meio de uma Tabela contendo a apresentação em forma de Tabela dos Requisitos. Segue exemplo Tabela.

3.4 Passo 04

1. Construir e apresentar para o professor o Relatório 3 - Análise de Requisitos, contemplando os Passos 2 e 3.

Relatório 3 – Analise de Requisitos

Resumo: Técnicas para Levantamento de Requisitos (Comparativo com Vantagens e Desvantagens)

Aluno: Gustavo Henrique da Silva

RA: 8219913874

As técnicas mais utilizadas na analise de requisitos são:

• Entrevista - A técnica Entrevista visa obter a opinião dos entrevistados, o que ajuda na descoberta dos problemas-chave a serem tratados, conhecer os sentimentos sobre o estado atual do sistema e levantar procedimentos informais.

o Vantagens - Incluir perguntas ao decorrer da entrevista, eliminar perguntas, mudar a ordem das perguntas, o poder de motivar o entrevistado, mudar a ordem da entrevista para aspectos mais importantes e o programador descobrirá o que é mais importante.

o Desvantagens - O entrevistado perde a atenção em entrevistas longas, é obrigatório um plano de entrevista, tratamento diferenciado para cada entrevistado, ocorre o risco de que o analista não consiga entender o cliente e é necessário mais tempo e recurso para a realização.

• Questionário - Os questionários são interessantes e podem fornecer um feedback rápido, pois possuem o formato "pergunta - reposta", entretanto, deve ser usado como uma forma de complementar, afim de quantificar o que foi levantado em entrevistas, mostrar que opiniões são difundidas ou limitadas.

o Vantagens - Permite que os participantes respondam no momento em que acharem conveniente, questões padronizadas garante uniformidade, atinge um grande números de pessoas e possui menor custo.

o Desvantagens - Não há garantia que todos respondam e pode-se se haver pontos de vista diferentes para cada entrevistado.

• Observação - Nela pode-se capturar informações relevantes para o desenvolvimento do projeto, pois coloca o programador dentro do campo de atuação dos usuários do sistema, observando como as coisas são feitas e quais as soluções para os problemas.

o Vantagens - Alia-se com o mercado, permite abordagem total e consegue-se observar o ambiente.

o Desvantagens - Necessidade de treinamento, o ponto de vista não pode ser bom, tem-se uma amostra menor e dificulta a analise e a interpretação das situações.

• Prototipação - Instrumento utilizado com cautela para recolher requisitos, onde são usados protótipos. Quando o cliente não sabe expressar seus requisitos de forma satisfatória.

o Vantagens - Redução de tempo e do custo de desenvolvimento pela antecipação de erros, satisfação de segurança por ver o protótipo e um retorno antecipado.

o Desvantagens - Tempo maior para realização e tem alto custo de investimento.

• Analítico - Analise e documentação e conhecimento existentes com o intuito de adquirir requisitos através do levantamento de informação do sistema, como por exemplo: informações financeiras, características do produto, histórico da organização, entre outros.

o Vantagens - Reutilização de informação e evolução do projeto.

o Desvantagens - É necessário opinião de especialistas, lida com informação antiga e dificultado a idealização do produto final.

Resumo: Técnicas para Levantamento de Requisitos (Comparativo com Vantagens e Desvantagens)

Aluno: Leandro Souza Santana

RA: 9895555712

• Brainstorming - Significa tempestade cerebral ou tempestade de ideias. O brainstorming é uma dinâmica de grupo que é usada em várias empresas como uma técnica para resolver problemas específicos, para desenvolver novas ideias ou projetos, para juntar informação e para estimular o pensamento criativo.

o Vantagens - O relacionamento entre líder e equipe é fortalecido;

o A comunicação entre as pessoas evolui;

o Diversas cabeças pensam melhor do que uma.

o Desvantagens - Muita conversação e pouca ação;

o Quantidade grande de sugestões de pouca qualidade;

o Pode ser aplicada em excesso;

o Há risco de dominação/monopolização pelos participantes mais extrovertidos;

o Pode gerar certa pressão sobre as pessoas mais tímidas.

• Questionários e Pesquisas - Podendo ser os questionários com perguntas fechadas no qual caiba apenas as respostas sim ou não, ou perguntas abertas, na qual possibilita a descrição segundo o usuário de suas atividades e possíveis problemas, levando em consideração as opiniões expressas do cliente.

o Vantagens - Preparar antecipadamente com questões objetivas;

o Identificar quem responderá: nome, função e localização;

o Distribuir com instruções detalhadas de como preencher e o prazo de devolução.

o Desvantagens - Comunicação restrita com o usuário e não há troca de informação.

• Etnografia - Um tipo de técnica de observação, onde o analista entra no campo de trabalho da empresa, observando a cultura de trabalho e história. Fazendo anotações das tarefas executadas pelos departamentos.

o Vantagem - Devido ao tempo de observação acaba adquirindo um conhecimento profundo e real do ambiente.

o Desvantagem: A forma como é interpretado cada situação, requer investimento em treinamento especializado.

• WorkShop - Uma técnica feita através de uma reunião bem estruturada, com componentes que tem um investimento, um interesse pela empresa. Tendo assim um conjunto de requisitos bem definidos.

o Vantagem - Adquire requisitos bem definidos, maiores opiniões formando assim algo mais eficaz, tempo reduzido para coletar as informações

o Desvantagens - Não abre ideias externas além da equipe encontrada no local e como necessita de hora e dia marcados pode ocasionar em ausências.

• Prototipação - É utilizado no estágio inicial do projeto. Ajuda aos stakeholders a desenvolver uma forte noção sobre a aplicação a qual ainda não foi implementada através da visualização da mesma eles podem identificar os reais requisitos e fluxos de trabalho do sistema. É muito utilizado quando os stakeholders são incapazes de expressar os seus requisitos ou se os mesmos não têm nenhuma experiência com o sistema.

o Vantagens - Redução de tempo e custo de desenvolvimento devido à detecção dos erros em uma fase inicial do projeto.

o Desvantagens - Demanda um tempo maior para sua realização devido à

complexidade do sistema e a limitações técnicas.

• Entrevista - A entrevista é uma técnica simples, que gera bons resultados na fase inicial de obtenção de dados. Essa é a hora que o cliente fala sobre todas as suas necessidades.

o Vantagens - Com um plano geral bem elaborado, o analista terá facilidade em descobrir que informação o usuário está mais interessado e usar um estilo adequado ao entrevistar.

o Desvantagens: Podem ocorrer vários desvios de curso na entrevista, como consumir mais tempo e recursos com sua realização, usuário tem dificuldade de concentração em reuniões muito longas, e também o entrevistado pode não saber expressar corretamente suas necessidades ao analista.

• JAD: (Joint Application design) - O processo JAD consiste em principais causas: customização, sessões e agrupamento. Na customização, o analista prepara as tarefas como organizar os times, prepara o material etc.na faze de sessões, o analista marca reuniões com os stakeholders. Na fase de grupamento todos os requisitos levantados nas fases anteriores são convertidos em documentos de especificação de requisitos.

o Vantagem - O que ocorre na fase de sessões é altamente produtivas porque resolvem dificuldades do desenvolvimento do sistema para a empresa.

o Desvantagem - Requer mais recursos se comparado à métodos tradicionais.

Resumo: Técnicas para Levantamento de Requisitos (Comparativo com Vantagens e Desvantagens)

Aluno: Roberto De Oliveira

RA: 8219934952

Irei descrever abaixo, algumas técnicas mais adequadas para análise de requisitos.

1. Entrevistas

Esse tipo de método é um dos mais usuais, pois permite que o desenvolvedor e o cliente tenham um diálogo, podendo deixar de uma forma mais clara o que o cliente deseja auxiliar, esclarecer suas dúvidas e real necessidade.

VANTAGENS DESVANTAGENS

1-Fica mais fácil para o analista compreender o que o cliente deseja. 1-Existe o risco de ocorrer algum desvio durante a entrevista.

2-É possível alterar a sequência das perguntas. 2-Um entrevistado pode assimilar as informações melhor que o outro.

3-Deixar o entrevistado mais a vontade em relação a implantação no novo software. 3-O entrevistado pode não conseguir passar de uma forma clara o que realmente deseja.

4-Tem a possibilidade de incluir perguntas que não estavam no questionário. 4-Se a entrevista for muito longa, o entrevistado pode perder o foco.

2. Analíticos

O método analítico abrange o lado mais técnico do software, informações como, fluxo de trabalho, interação com outros sistemas, características do programa, entre outras.

VANTAGENS DESVANTAGENS

1- O conhecimento abrangente dos especialistas faz com que o processo evolutivo aumente a qualidade e maturidade do software. 1-Sem a documentação e opinião dos especialistas é impossível identificar os requisitos.

2-O reuso de dados já existentes economiza tempo e dinheiro 2-Existe a possibilidade de levar restrição visionária da conclusão do software.

3. Prototipação

A prototipação ajuda aos clientes terem uma nação mais claro sobre as funcionalidades e requisitos do software. É uma técnica utilizada quando o cliente não tem conhecimento referente ao software a ser implantado.

VANTAGENS DESVANTAGENS

1-Facilidade em receber o feedback do cliente. 1-Comparado com os outros métodos, tem um custo maior de desenvolvimento.

2-Desenvolvimento do software mais rápido,

com redução de tempo e erros.

4. Observação

Com essa técnica os desenvolvedores devem visitar o local para acompanhar e observar o dia a dia das operações e processos realizados para poder desenvolver um software que atenda às necessidades do cliente com uma visão real do negócio.

VANTAGENS DESVANTAGENS

1-Não existe muitas interrupções durante a análise. 1-Necessita de um treinamento específico.

2-Confiável para uma observação com baixo nível de inferência. 2-As pessoas podem não gostar de serem observadas.

3-Verificar o comportamento das pessoas na utilização do software atual. 3-Não deixa claro para o observado a forma de análise.

Mediante ao cenário exposto acima, podemos dizer que todas as formas têm suas vantagens e desvantagens, cabe aos desenvolvedores do projeto e clientes, discutirem a melhor forma para poder desenvolver o sistema com mais praticidade, eficiência e custo benefício para ambas as partes.

Tabela de Requisitos

Requisitos Funcionais Requisistos Não Funcionais

Requisitos Descrição Prioridade Requisitos Descrição Prioridade

RF01 Cadastros das imobiliarias, terrenos e vendedores Alta RNS01 Segurança Essencial

RF02 Controle de estoque dos terrenos Alta RNS02 Desempenho Essencial

RF03 Envio de notificações Alta RNS03 Usuabilidade Essencial

RF04 Atualização em tepo real Alta RNS04 Confiabilidade Essencial