Análise e Projeto de Sistema: Estudo de Caso da Intranet

Curitiba 2016 Análise e Projetos de Sistemas Práticas Carla Daiane Zatti 9 Estudo de caso Um estudo de caso é entre outros conceitos um processo específico para o estudo ou o desenvolvimento do objeto de estudo que pode ser um caso individual ou não O objetivo do presente capítulo é focar a apresentação de um estudo de caso cujo objeto é o resultado referente às fases de análise e de projeto do desenvolvimento de um sistema de informação fictício ela borado como exemplo do que foi apresentado nos capítulos anteriores O estudo de caso escolhido para exemplificar o que foi estudado até aqui é o desenvolvimento de intranet para uma empresa fictícia Análise e Projetos de Sistemas 154 91 Visão geral e escopo Uma equipe de desenvolvimento de sistemas é contratada para implan tar a intranet de determinada empresa É proposto o desenvolvimento dessa ferramenta que deve possibilitar a informatização das funções de comunica ção e integração com outros sistemas da empresa Deve também ser capaz de operar em vários navegadores de internet bem como conter diversas funções como publicação de notícias agenda eletrônica armazenamento de informa ções dos colaboradores entre outros 92 Especificação de requisitos Nesta seção são especificados os supostos requisitos funcionais e não funcionais para o desenvolvimento da intranet 921 Requisitos funcionais Foram identificados alguns requisitos funcionais representados no qua dro 91 Quadro 91 Requisitos funcionais Código Nome Descrição Não funcionais RF01 Manter acessos Esta funcionalidade deve permitir ao usuário funcio nário acessar o sistema A ação que deve estar dispo nível é registrar log de aces sos Cada acesso deve ter um usu ário e respectivos data e horá rio de login e de logout Compatibilidade Desempenho Disponibilidade Manutenção Portabilidade Segurança Usabilidade 155 Estudo de caso Código Nome Descrição Não funcionais RF02 Manter cartão ponto Esta funcionalidade deve permitir ao usuário fun cionário registrar o cartão ponto As ações que devem estar dis poníveis são cadastrar e con sultar registro de cartãoponto e visualizar pendências Cada registro deve ter um usuário e respectivos data e horários Compatibilidade Confiabilidade Desempenho Disponibilidade Interoperabilidade Manutenção Portabilidade Segurança Usabilidade RF03 Manter usu ários Esta funcionalidade deve permitir ao usuário admi nistrador gerenciar os usuá rios do sistema As ações que devem estar disponíveis são consultar e editar usuários Cada usuário deve ter acessos Compatibilidade Interoperabilidade Manutenção Portabilidade Segurança Usabilidade RF04 Manter notifi cações Esta funcionalidade deve permitir ao usuário funcio nário receber notificações do sistema As ações que devem estar disponíveis são consultar e excluir notificações Cada notificação deve ter uma origem e um destino e também respectivos data e horário Compatibilidade Confiabilidade Interoperabilidade Portabilidade Segurança Usabilidade Análise e Projetos de Sistemas 156 Código Nome Descrição Não funcionais RF05 Manter mensa gens Esta funcionalidade deve permitir ao usuário funcio nário enviar e receber men sagens de outros usuários As ações que devem estar dis poníveis são cadastrar con sultar e excluir mensagens Cada mensagem deve ter um remetente e um destina tário e também respectivos data e horário Desempenho Portabilidade Segurança Usabilidade RF06 Manter notí cias Esta funcionalidade deve permitir ao usuário adminis trador publicar e ao usuário funcionário ler notícias As ações que devem estar dis poníveis são cadastrar con sultar e editar notícias Cada notícia deve ter um escritor e sua respectiva data e horário Compatibilidade Portabilidade Usabilidade RF07 Manter com promissos Esta funcionalidade deve permitir ao usuário funcio nário visualizar sua agenda As ações que devem estar dis poníveis são cadastrar con sultar editar e excluir com promissos Cada compromisso deve ter participantes e local e tam bém sua respectiva data horário e duração Compatibilidade Confiabilidade Disponibilidade Interoperabilidade Portabilidade Segurança Usabilidade Fonte Elaborado pela autora 2016 157 Estudo de caso 922 Requisitos não funcionais Foram identificados os seguintes requisitos não funcionais a compatibilidade I O sistema deve oferecer compatibilidade e suporte às versões atuais dos navegadores Internet Explorer Google Chrome e Mozilla Firefox b confiabilidade I Não mais que um registro de cartãoponto a cada 1 milhão pode ser perdido devido a falhas no sistema II Não mais que dez notificações a cada 100 mil podem ser per didas devido a falhas no sistema III Não mais que dez mensagens a cada 100 mil podem ser perdi das devido a falhas no sistema IV Não mais que dez compromissos a cada 100 mil podem ser perdidos devido a falhas no sistema c desempenho I Ao submeter a solicitação de acesso ao sistema a tela inicial deve aparecer em no máximo dez segundos II Ao enviar uma mensagem a um usuário do sistema ela deve aparecer para ele em no máximo cinco minutos d disponibilidade I O sistema deve estar disponível pelo menos 999 do tempo em dias úteis no horário comercial e interoperabilidade I O sistema deve ser capaz de enviar e receber informações do sistema de controle de cartãoponto e do sistema do departa mento de Recursos Humanos Análise e Projetos de Sistemas 158 f manutenção I As correções de eventuais defeitos no sistema devem ser cor rigidas e disponibilizadas em até uma hora após o primeiro registro formal ou informal de reclamação de usuários g portabilidade I O sistema deve ser desenvolvido de forma a possibilitar sua operação na versão mais recente dos navegadores compatíveis a ser atualizada h segurança I Todos os usuários devem possuir senha para acessar o sistema II Apenas os usuários administradores devem ter acesso ao cadas tro de notícias i usabilidade I Um novo usuário deve ser capaz de operar corretamente o sistema após não mais que quatro horas de orientação 93 Análise do sistema Nesta seção são apresentados os diagramas de contexto de fluxo de dados e de entidade e relacionamento e o dicionário de dados do projeto 931 Diagrama de contexto Para o diagrama de contexto DC foram identificados os seguintes ele mentos a sistema intranet b atores usuário comum Usuário administrador Sistema cartão ponto Sistema RH 159 Estudo de caso Figura 91 Diagrama de contexto do sistema Fonte Elaborado pela autora 2016 932 Diagrama de fluxo de dados Para o diagrama de flux de dados DFD foram identificados os seguin tes elementos a entidades externas usuário comum Usuário administrador Sis tema cartãoponto Sistema RH b processos registrar cartãoponto consultar cartãoponto publi car notícia ler notícia visualizar agenda cadastrar compromisso receber notificação receber mensagem enviar mensagem cadas trar usuário editar usuário c arquivosDepósitos de dados usuários acessos notícias compro missos notificações mensagens Análise e Projetos de Sistemas 160 Figura 92 Diagrama de fluxo de dados do sistema Fonte Elaborado pela autora 2016 161 Estudo de caso 933 Diagrama de entidade e relacionamento Para o diagrama de entidade e relacionamento DER foram identifica dos os seguintes elementos a entidades usuário Administrador Funcionário CartãoPonto Notícia Compromisso Notificação Mensagem Figura 93 Diagrama de entidade e relacionamento do sistema Fonte Elaborado pela autora 2016 Análise e Projetos de Sistemas 162 934 Dicionário de dados Para o dicionário de dados DD foram identificados os seguintes quadros Quadro 92 Dicionário de dados Tabela Usuário Tabela USUÁRIO Nome Descrição Tipo Tamanho PK login Nome de usuário Char 50 senha Senha Char 15 perfil Permissão de acesso a funcionalidades Char 15 Fonte Elaborado pela autora 2016 Quadro 93 Dicionário de dados Tabela Funcionário Tabela FUNCIONÁRIO Nome Descrição Tipo Tamanho PK matricula Matrícula Int Nome Nome Char 100 Cargo Cargo Char 50 Fonte Elaborado pela autora 2016 Quadro 94 Dicionário de dados Tabela Administrador Tabela ADMINISTRADOR Nome Descrição Tipo Tamanho PK matricula Matrícula Int nome Nome Char 100 cargo Cargo Char 50 Fonte Elaborado pela autora 2016 163 Estudo de caso Quadro 95 Dicionário de dados Tabela CartãoPonto Tabela CARTÃOPONTO Nome Descrição Tipo Tamanho PK registro Código identificador Int data Data registrada Date horario Horário registrado Time FK funcionario Matrícula do funcio nário Int Fonte Elaborado pela autora 2016 Quadro 96 Dicionário de dados Tabela Notícia Tabela NOTÍCIA Nome Descrição Tipo Tamanho PK codigo Código identificador Int Titulo Título Char 100 Texto Texto Char 1000000 Data Data de publicação Date horario Horário de publi cação Time Fonte Elaborado pela autora 2016 Quadro 97 Dicionário de dados Tabela Compromisso Tabela COMPROMISSO Nome Descrição Tipo Tamanho PK Id Código identificador Int Tipo Tipo Char 15 assunto Assunto Char 100 data Data de realização Date horario Horário de realização Time Análise e Projetos de Sistemas 164 Tabela COMPROMISSO Nome Descrição Tipo Tamanho duracao Duração em minutos Float local Local de realização Char 100 Fonte Elabora pela autora 2016 Quadro 98 Dicionário de dados Tabela Notificação Tabela NOTIFICAÇÃO Nome Descrição Tipo Tamanho PK id Código identificador Int FK destinatario Código do usuário destinatário Int texto Texto Char 100 data Data de recebimento Date horario Horário de recebimento Time Fonte Elaborado pela autora 2016 Quadro 99 Dicionário de dados tabela Mensagem Tabela MENSAGEM Nome Descrição Tipo Tamanho PK id Código identificador Int FK remetente Código do usuário remetente Int FK destinatario Código do usuário destinatário Int texto Texto Char 1000 data Data de envio Date horario Horário de envio Time Fonte Elaborado pela autora 2016 165 Estudo de caso 94 Linguagem de Modelagem Unificada Nesta seção são apresentados os diagramas da Linguagem de Modela gem Unificada UML o diagrama de classes o diagrama de caso de uso e os diagramas de sequência 941 Diagrama de classe O diagrama de classes proposto é identificado na figura 94 Figura 94 Diagrama de classes do sistema Fonte Elaborado pela autora 2016 Análise e Projetos de Sistemas 166 942 Diagrama de caso de uso O diagrama de caso de uso UC proposto é identificado na figura 95 Figura 95 Diagrama de caso de uso do sistema Fonte Elaborado pela autora 2016 943 Diagramas de sequência Os diagramas de sequência estão divididos por funcionalidade O exemplo mostrado na figura 96 é o das funcionalidades de acesso ao sistema e registro de cartãoponto 167 Estudo de caso Figura 96 Diagramas de sequência das funcionalidades de acesso ao sistema e registro de cartãoponto Fonte Elaborado pela autora 2016 O segundo exemplo é da funcionalidade de gerenciamento de usuários exposto na figura 97 Figura 97 Diagramas de sequência da funcionalidade de gerenciamento de usuários Fonte Elaborado pela autora 2016 Análise e Projetos de Sistemas 168 Já o terceiro exemplo na figura 98 referese à funcionalidade de envio e recebimento de mensagens e notificações Figura 98 Diagramas de sequência da funcionalidade de envio e recebimento de mensagens e notificações Fonte Elaborado pela autora 2016 O quarto exemplo é o da funcionalidade de manter notícias Figura 99 Diagramas de sequência da funcionalidade de manter notícias Fonte Elaborado pela autora 2016 E o quinto e último exemplo é da funcionalidade de manter compro missos e notificações 169 Estudo de caso Figura 910 Diagramas de sequência da funcionalidade de manter compromissos e notificações Fonte Elaborado pela autora 2016 95 Projeto do banco de dados Nesta seção são apresentados os projetos de banco de dados o projeto lógico e o projeto físico 951 Projeto lógico Para o projeto de banco de dados BD foram identificadas as tabelas Usuário login senha perfil Chave primária login Consulta dos dados por login ou perfil Análise e Projetos de Sistemas 170 Funcionário matrícula nome cargo Chave primária matrícula Consulta dos dados por matrícula nome ou cargo Administrador matrícula nome cargo Chave primária matrícula Consulta dos dados por matrícula nome ou cargo Cartãoponto registro data hora rio funcionario Chave primária matrícula Chave estrangeira funcionario refe rência à tabela Funcionário Consulta dos dados por data e horário Notícia codigo titulo texto data horario Chave primária codigo Consulta dos dados por data Compromisso id tipo assunto data horario duração local Chave primária id Consulta dos dados por assunto ou data e horário Notificação id texto data hora rio destinatario Chave primária id Chave estrangeira destinatario refe rência à tabela Usuário Consulta dos dados por data e horário Mensagem id texto data hora rio remetente destinatario Chave primária id Chaves estrangeiras remetente e destina tario referências à tabela Usuário Consulta dos dados por data e horário 171 Estudo de caso 952 Projeto físico O projeto físico proposto é CREATE TABLE Usuario login char50 senha char15 perfil char15 primary keylogin CREATE TABLE Funcionario matricula int nome char100 cargo char50 primary keymatricula CREATE TABLE Administrador matricula int nome char100 cargo char50 primary keymatricula CREATE TABLE Cartaoponto registro int data date horário time funcionário int NOT NULL primary keyregistro foreign key funcionario references Funcionario CREATE TABLE Noticia codigo int titulo char100 texto char1000000 data date horario time pri mary keycodigo CREATE TABLE Compromisso id int tipo char15 assunto100 data date horario time duracao float local char100 primary keyid CREATE TABLE Notificacao id int texto char100 data date horario time destinatario int NOT NULL primary keyid foreign key destinatario references Usuario CREATE TABLE Mensagem id int texto char100 data date horario time remetente int NOT NULL destinatario int NOT NULL primary keyid foreign key remetente references Usuario foreign key destinatario references Usuario Síntese O estudo de caso deste capítulo apresentou uma simulação do desenvol vimento do projeto de um sistema Intranet Foram apresentados os requisi tos funcionais e não funcionais e os diagramas de contexto de fluxo de dados de entidade e relacionamento de classes de caso de uso e de sequência bem Análise e Projetos de Sistemas 172 como o dicionário de dados Foi também simulado o projeto do banco de dados incluindo os projetos lógico e físico Atividades 1 De acordo com o requisito não funcional de compatibilidade a intranet deve funcionar nos navegadores Internet Explorer Google Chrome e Mozilla Firefox O fato de ela funcionar também no Safari ou no Opera impacta no escopo do projeto a Sim pois todos os navegadores que suportam a intranet devem estar contemplados no escopo do projeto portanto os dois navega dores não especificados devem ser adicionados ao escopo b Sim pois ela deve funcionar apenas nos navegadores especificados portanto o código deve ser corrigido para que ela funcione apenas nos três navegadores citados c Não pois o fato de ela funcionar em outros navegadores que não os especificados não interfere no escopo do projeto portanto nenhuma alteração é necessária 2 No DER o que significa a relação entre Administrador Usuário e Funcionário representada na imagem a seguir a Administradores e funcionários são usuários b Usuários possuem administradores e funcionários c Todo administrador é um usuário mas nem todo funcionário é um usuário 3 Se o cliente pedisse um novo requisito como a possibilidade de inclusão de comentários para as notícias quais seriam as melhores 173 Estudo de caso opções de atributos dessa nova classe Comentário a ser criada no diagrama de classes a Id texto data e horário b Id texto data horário e usuário c Id texto data horário usuário e notícia 4 E quais seriam as chaves estrangeiras dessa nova entidade Comen tário a ser criada no DER a Id e texto b Data e horário c Usuário e notícia 10 Mais um Estudo de Caso O objetivo do presente capítulo é elaborar mais um exemplo para frisar o entendimento do conteúdo deste livro Dessa vez o estudo de caso fictício se trata de um aplicativo para celular Análise e Projetos de Sistemas 176 101 Visão geral e escopo Uma empresa qualquer fabrica dispositivos eletrônicos com GPS Glo bal Positioning System ou Sistema de Posicionamento Global que são acopla dos a coleiras para rastreamento de animais Ela então decide contratar um desenvolvedor de aplicativos para dispositivos móveis para implementar e dis ponibilizar um aplicativo que permita a visualização da localização do animal É proposto o desenvolvimento de um aplicativo para dispositivos móveis que deve possibilitar rastrear e visualizar a localização exata de animais bem como ler o QR Code Quick Response Code ou Código de Resposta Rápida do dispositivo eletrônico para a identificação do animal Deve também ser capaz de operar em vários sistemas operacionais móveis bem como conter diversas funções como cadastramento dos dados dos animais entre outros 102 Especificação de requisitos Nessa seção são especificados os supostos requisitos funcionais e não funcionais para o desenvolvimento do aplicativo 1021 Requisitos funcionais Foram identificados os seguintes requisitos funcionais RF001 Cadastro de usuário O sistema deve permitir o cadastro do usuário na base de dados do sistema Dados de usuário Login Nome de usuário Campo alfanumérico editável apenas no primeiro acesso Senha Senha para acessar o aplicativo Campo alfanumérico editável Nome Nome completo Campo alfabético editável Endereço Endereço da residência do animal e seu dono Caixa com vários campos editáveis 177 Mais um Estudo de Caso RF001 Cadastro de usuário O sistema deve permitir o cadastro do usuário na base de dados do sistema Telefones Telefone para contato Caixa com vários campos editáveis Email Email para contato Campo alfanumérico editável Dependências NA Prioridade alta RF002 Acesso ao sistema O sistema deve permitir o acesso ao aplicativo Dados de Login Login Nome de usuário cadastrado na base de dados Campo alfanumérico editável Senha Senha de acesso ao aplicativo Campo alfanumérico editável Dependências Cadastro de usuário Prioridade alta RF003 Alteração de senha O sistema deve permitir a alteração da senha cadastrada na base de dados do sistema Dados de usuário Login Nome de usuário cadastrado na base de dados Campo alfanumérico editável Senha Senha de acesso ao aplicativo Campo alfanumérico editável Dependências Cadastro de usuário Login Prioridade normal Análise e Projetos de Sistemas 178 RF004 Cadastro de animal O sistema deve permitir o cadastro de animais na base de dados do sistema Dados de animal Tipo Espécie do animal Botão de opção Nome Nome do animal Campo editável Sexo Gênero do animal Botão de opção Raça Raça do animal Combobox Idade Idade do animal Combobox Cor Cores do animal Campo alfabético editável Outras características Outras informações relevantes sobre o animal Campo alfanumérico editável Dependências Cadastro de usuário Login Prioridade alta RF005 Edição de animal O sistema deve permitir a edição de animais na base de dados do sistema Dados de animal Código Código identificador do registro do animal Campo numérico não editável gerado automaticamente pelo sistema Tipo Espécie do animal Botão de opção Nome Nome do animal Campo editável Sexo Gênero do animal Botão de opção Raça Raça do animal Combobox Idade Idade do animal Combobox Cor Cores do animal Campo alfabético editável Outras características Outras informações relevantes sobre o animal Campo alfanumérico editável Desaparecido Animal desaparecido Caixa de seleção 179 Mais um Estudo de Caso RF005 Edição de animal O sistema deve permitir a edição de animais na base de dados do sistema Encontrado Animal encontrado Caixa de seleção Dependências Cadastro de usuário Login Cadastro de animal Prioridade alta RF006 Criação de Avatar O sistema deve permitir a criação de avatares para os animais cadastrados na base de dados do sistema Dependências Cadastro de usuário Login Cadastro de animal Prioridade baixa RF007 Registro de coordenadas O sistema deve permitir o registro de coordenadas recebidas pelo GPS do dispositivo eletrônico na base de dados do sistema Dados de coordenada Coordenada X Coordenada Y Data e hora Data e horário do recebimento das coordenadas Dependências Cadastro de usuário Login Cadastro de animal Prioridade alta Análise e Projetos de Sistemas 180 RF008 Visualização de mapa O sistema deve permitir a visualização do mapa com a localização do ani mal a partir das coordenadas recebidas pelo GPS do dispositivo eletrônico e cadastradas na base de dados do sistema Dependências Cadastro de usuário Login Cadastro de animal Registro de coordenadas Prioridade alta RF009 Leitura de QR Code O sistema deve permitir a leitura do QR Code exibido pelo dispositivo ele trônico Dependências Cadastro de usuário Login Cadastro de animal Prioridade alta RF009 Identificação de animal O sistema deve receber dados do animal e seu dono via leitura do QR Code do dispositivo eletrônico Dados do animal Tipo Espécie do animal Campo não editável Nome Nome do animal Campo não editável Sexo Gênero do animal Campo não editável Raça Raça do animal Campo não editável Idade Idade do animal Campo não editável Cor Cores do animal Campo não editável 181 Mais um Estudo de Caso RF009 Identificação de animal O sistema deve receber dados do animal e seu dono via leitura do QR Code do dispositivo eletrônico Outras características Outras informações relevantes sobre o animal Campo não editável Desaparecido Animal desaparecido Caixa de seleção Encontrado Animal encontrado Caixa de seleção Dados do dono do animal Nome Nome completo Campo não editável Endereço Endereço da residência do animal e seu dono Caixa com vários campos não editáveis Telefones Telefone para contato Caixa com vários campos não editáveis Email Email para contato Campo não editável Dependências Cadastro de usuário Login Cadastro de animal Leitura de QR Code Prioridade alta 1022 Requisitos não funcionais Foram identificados os seguintes requisitos não funcionais Quadro 101 Requisitos não funcionais Componente Requisito mínimo Sistema operacional SO iOS 8 Android 50 Windows Phone 81 Processador 2 GHz Análise e Projetos de Sistemas 182 Componente Requisito mínimo Memória RAM 1 GB Tela 1080 x 1920 Câmera 13 MP com autofoco Rede Conectividade com a internet Segurança Banco de dados protegido para acesso apenas de usuários cadas trados Facilidade de uso Modo inicial primeiro uso Fonte Elaborado pela autora 2016 103 Análise do sistema Nessa seção são apresentados os diagramas de contexto fluxo de dados e de entidade e relacionamento e o dicionário de dados do projeto 1031 Diagrama de contexto DC Para o DC foram identificados os elementos a seguir a Sistema App Atores usuário dono do animal dispositivo eletrônico usuário comum Figura 101 Diagrama de contexto Fonte Elaborado pela autora 2016 183 Mais um Estudo de Caso 1032 Diagrama de fluxo de dados DFD Para o DFD foram identificados os elementos a seguir a Entidades externas usuário dono do animal dispositivo eletrônico usuário comum b Processos cadastrar usuário cadastrar animal visualizar mapa registrar localização ler QR Code c ArquivosDepósitos de dados usuário animal localização Figura 102 Diagrama de fluxo de dados Fonte Elaborado pela autora 2016 Análise e Projetos de Sistemas 184 1033 Diagrama de entidade e relacionamento DER Para o DER foram identificados os elementos a seguir a Entidades usuário cidade animal raça localização Figura 103 Diagrama de entidade e relacionamento Fonte Elaborado pela autora 2016 185 Mais um Estudo de Caso 1034 Dicionário de dados DD Para o DD foram identificadas as tabelas seguintes Tabela 101 Usuário Nome Descrição Tipo Tamanho PK login Nome de usuário Char 50 senha Senha Char 15 nome Nome completo Char 100 endrua Nome da rua Char 50 endnum Número da casa Int endcomp Complemento Char 15 FK endcid Cidade Int fonecel Telefone celular Char 10 foneres Telefone residencial Char 10 fonecom Telefone comercial Char 10 email Endereço de email Char 50 Fonte Elaborado pela autora 2016 Tabela 102 Cidade Nome Descrição Tipo Tamanho PK id Código Int nome Nome Char 25 Fonte Elaborado pela autora 2016 Tabela 3 Animal Nome Descrição Tipo Tamanho PK cod Código Int tipo Espécie Bool nome Nome Char 25 sexo Gênero Bool Análise e Projetos de Sistemas 186 Nome Descrição Tipo Tamanho FK raca Raça Int idade Idade Float cor Cor Char 50 outro Outras características Char 150 des Animal desaparecido Bool enc Animal encontrado Bool Fonte Elaborado pela autora 2016 Tabela 4 Raça Nome Descrição Tipo Tamanho PK id Código Int raca Raça Char 100 esp Espécie Bool Fonte Elaborado pela autora 2016 Tabela 5 Localização Nome Descrição Tipo Tamanho PK Pos Código Int X Coordenada X Float Y Coordenada Y Float Quando Data e horário Datetime Fonte Elaborado pela autora 2016 104 UML Nessa seção são apresentados os diagramas da UML diagrama de clas ses diagrama de caso de uso e diagramas de sequência 187 Mais um Estudo de Caso 1041 Diagrama de classe O diagrama de classes proposto é o seguinte Figura 104 Diagrama de classe Fonte Elaborado pela autora 2016 1042 Diagrama de caso de uso O diagrama de UC proposto é o seguinte Análise e Projetos de Sistemas 188 Figura 105 Diagrama de caso de uso Fonte Elaborado pela autora 2016 1043 Diagramas de sequência Os diagramas de sequência estão divididos por funcionalidade O pri meiro diagrama é o da funcionalidade de acesso ao sistema Figura 106 Diagrama de sequência acesso ao sistema Fonte Elaborado pela autora 2016 189 Mais um Estudo de Caso O segundo diagrama é da funcionalidade de cadastro de usuário Figura 107 Diagrama de sequência cadastro de usuário Fonte Elaborado pela autora 2016 Já o terceiro diagrama se refere à funcionalidade de cadastro de animal Figura 108 Diagrama de sequência cadastro de animal Fonte Elaborado pela autora 2016 Análise e Projetos de Sistemas 190 O quarto diagrama é o das funcionalidades de receber coordenadas e visualizar mapa Figura 109 Diagrama de sequência receber coordenadas e visualizar mapas Fonte Elaborado pela autora 2016 O quinto e último diagrama é da funcionalidade de ler QR Code Figura 1010 Diagrama de sequência ler QR Code Fonte Elaborado pela autora 2016 191 Mais um Estudo de Caso Síntese O estudo de caso deste capítulo apresentou uma simulação do desenvol vimento do projeto de um aplicativo para smartphones Foram apresentados os requisitos funcionais e não funcionais e os diagramas de contexto de fluxo de dados de entidade e relacionamento de classes de caso de uso e de sequ ência bem como o dicionário de dados Atividades 1 De acordo com os requisitos não funcionais o aplicativo deve funcio nar nos sistemas operacionais Android iOS e Windows O fato de ele funcionar também em outro SO impacta no escopo do projeto a Sim pois todos os sistemas operacionais que suportam o aplicativo devem estar contemplados no escopo do projeto portanto qual quer outro SO não especificado deve ser adicionado ao escopo b Sim pois ele deve funcionar apenas nos sistemas operacionais espe cificados portanto o código deve ser corrigido para que ele fun cione apenas nos três SOs especificados c Não pois o fato de ele funcionar em outro sistema operacional que não o especificado não interfere no escopo do projeto portanto nenhuma alteração é necessária 2 Se o cliente pedisse um novo requisito possibilidade de inclusão da sua casa no mapa qual seria o atributo essencial dessa nova classe Casa a ser criada no diagrama de classes a Coordenadas b Endereço c Número 3 E qual não poderia ser a chave primária dessa nova entidade Casa a ser criada no DER a Id Análise e Projetos de Sistemas 192 b Nome c Endereço 4 Esboce o diagrama de sequência da funcionalidade de registro de casa no mapa Conclusão Análise e Projetos de Sistemas 194 A análise e o projeto de sistemas são duas etapas importantes e neces sárias para o desenvolvimento de softwares com qualidade A análise modela o problema e consiste das atividades necessárias para entender o domínio do problema isto é o que deve ser feito sendo basicamente uma atividade de investigação Já o projeto modela a solução e consiste das atividades de cria ção do como pode ser feito Podemos considerar também que a análise consiste de todas as atividades feitas com conhecimento e anuência do cliente pois a informação produzida durante a análise é aquela que o cliente deve conhecer e aprovar Já o projeto inclui as atividades que resultam em informação que interessa apenas ao ana lista de sistemas e ao programador Atualmente é comum o cliente ultrapassar a análise e adentrar a discussão da solução do problema principalmente no que tange às interações que ocorrem na interface do usuário E essa situação é salutar para que o software seja desenvolvido com qualidade e de acordo com as necessidades dos clientesusuários aqui considerados stakeholders Independentemente da proposta utilizada o projeto de sistema deve ser mapeado utilizando uma metodologia que deve ser escolhida e decidida com cautela pois dela dependerá todo o contexto do projeto e a implementação do software O projeto de sistema também segue uma sequência de etapas que deve ser seguida para se atingir o objetivo É importante citar que um projeto é um documento vivo por isso pode e deve ser atualizado sempre que houver necessidade pois um de seus objetivos é atender às necessidades dos clientesusuários com qualidade Os estudos de caso apresentados neste material refletem a contextuali zação das etapas de análise e de projeto de sistemas de informação e podem ser tomados como base para uma sequência de etapas segura na realização dessa atividade importantíssima para o profissional da área de Tecnologia da Informação Gabarito Análise e Projetos de Sistemas 196 1 Introdução à Análise e Projeto de Sistemas 1 Sobre a teoria geral dos sistemas marque a alternativa falsa a A TGS teve grande aceitação por todos desde o seu surgimento A TGS não teve grande aceitação por todos desde o seu surgimento Ela surgiu dos trabalhos de Ludwig von Bertalanffy quando se per cebeu a inviabilidade de tratar as ciências por partes isoladas e tem como objetivo estudar a natureza dos sistemas e a relação entre suas partes em diferentes espaços 2 Sobre o pensamento sistêmico marque a alternativa falsa c É contra a racionalidade científica pois acredita que ela não oferece parâmetros suficientes para o desenvolvimento humano e para a descrição do universo material Não nega a racionalidade científica mas acredita que ela não oferece parâmetros suficientes para o desenvolvimento humano e para a des crição do universo material O pensamento sistêmico é uma forma de abordagem da análise de conflitos e da criação de soluções que pode auxiliar na mudança dos sistemas de acordo com os processos do ambiente E é a capacidade de avaliar os acontecimentos ao redor e suas possíveis implicações a fim de criar uma solução única que possa contemplar as expectativas de todas as partes envolvidas 3 Sobre a visão sistêmica marque a alternativa falsa c Está baseada no conceito de que o todo resultante da junção das partes é equivalente à soma destas Está baseada no conceito de que o todo resultante da junção das partes é muito maior do que a soma destas Consiste na capacidade de compreensão dos sistemas de acordo com a abordagem da teoria geral dos sistemas Seu objetivo é entender a influência das partes entre si e buscar excelência naquilo que diz respeito ao sistema 4 O que são stakeholders a São as partes interessadas em um sistema ou seja as pessoas que podem ser afetadas ou possuem participação em um deter minado sistema 197 Gabarito Não são as pessoas e grupos mais importantes de um planejamento estratégico ou plano de negócios nem as pessoas responsáveis por um planejamento estratégico ou plano de negócios 2 Sistemas de Informação 1 Quando surgiram os computadores c Na década de 1940 durante a Segunda Guerra Mundial 2 Qual é a diferença entre SI de um grupo e SI corporativo b Os SIs de grupo auxiliam as atividades de um departamento de uma empresa enquanto os SIs corporativos auxiliam as ativida des de grande parte de uma empresa Os SIs de um grupo auxiliam as atividades de um grupo de indivíduos de um departamento de uma empresa e os SIs interorganizacionais auxiliam as atividades dos indivíduos de empresas diferentes 3 Qual das alternativas abaixo lista exemplos de recursos humanos de hardware software dados e rede respectivamente c Usuário CPU ferramenta de edição de texto BD SQL Internet Banco de dados internet sistema operacional gerente de projetos e computador são exemplos de recursos de dados rede software humanos e hardware respectivamente HD operador de sistema planilha eletrônica BD Oracle e World Wide Web são recursos de hardware humanos software dados e rede respectivamente 4 Qual processo de desenvolvimento de software é caracterizado por suas etapas serem executadas apenas uma vez sendo que cada etapa nunca é iniciada antes do término da etapa anterior a Cascata Tanto na prototipação quanto no evolucionário as etapas são exe cutadas mais de uma vez Análise e Projetos de Sistemas 198 3 Levantamento de requisitos 1 É um requisito evidente b efetuar login O telefone móvel deve utilizar a plataforma iOS requisito não funcional criptografar senha requisito oculto ou escondido 2 Verificar acesso é um requisito de c segurança 3 A técnica de elicitação de requisitos na qual o analista visita o local em foco com a finalidade de observar os usuários em seu ambiente de trabalho enquanto eles executam suas atividades é chamada de a análise de observação Estudo etnográfico é uma técnica de observação e análise de componente social das tarefas desempenhadas em dada organi zação Sessão JAD é baseada em sessões de dinâmica de grupo e workshops nos quais stakeholders e analistas de requisitos se reúnem para debater as funcionalidades desejadas do produto de software 4 A técnica de entrevista com stakeholder consiste em a uma reunião do projeto requerido em que se sugere entrevistar apenas uma pessoa por vez Um grupo de discussão informal de tamanho reduzido com o obje tivo de coletar informações qualitativas é uma técnica chamada de grupo focal Sessões de dinâmica de grupo e workshops nos quais stakeholders e analistas de requisitos se reúnem para debater as funcionalidades desejadas do produto de software é uma técnica chamada de sessão JADRAD 4 Análise de Sistemas 1 Quais os métodos de análise mais utilizados hoje b Análise estruturada análise essencial e análise orientada a objetos 199 Gabarito A análise tradicional não é mais utilizada 2 Qual o principal elemento da análise essencial b O conjunto de requisitos verdadeiros A abordagem baseada em processos e dados é o principal elemento da análise estruturada a abstração de conceitos utilizados no mundo real é o principal elemento da análise orientada a objetos 3 Marque I para identidade A para atributo e M para método I Pessoa I Funcionário A Saldo A Cor A Nome M Trabalhar I Carro M Excluir A CPF I Cachorro M Comer I Cliente 4 Pastor alemão pequinês e buldogue são cães é um exemplo de b herança Instanciação é a definição de objetos abaixo de uma classe e as raças caninas acima são classes especializadas mas não objetos a visibilidade está relacionada aos atributos 5 Ferramentas de Apoio à Análise de Sistemas 1 Quais são os principais diagramas da análise de sistemas a DC DFD e DER O DD não é um diagrama 2 O que é um diagrama de fluxo de dados b É um diagrama dos processos do sistema e dos dados que ligam esses processos descrevendo o fluxo de informação e a estrutura do sistema a ser desenvolvido O DC é um diagrama de alto nível que representa todo o sistema como um único processo E o DER é um diagrama que representa o modelo de dados de um sistema para facilitar ao projetista do banco de dados a construção do modelo de dados Análise e Projetos de Sistemas 200 3 Quais são os elementos componentes do DFD b Processos entidades externas fluxo de dados e depósitos de dados Sistema entidades e dados são elementos componentes do DC e entidades e relacionamentos são elementos componentes do DER 4 O que é um diagrama de entidade e relacionamento c É um diagrama que representa o modelo de dados de um sis tema para facilitar ao projetista do banco de dados a construção do modelo de dados O DC é um diagrama de alto nível que representa todo o sistema como um único processo E o DFD é um diagrama dos processos do sistema e dos dados que ligam esses processos descrevendo o fluxo de informação e a estrutura do sistema a ser desenvolvido 6 Linguagem de Modelagem Unificada 1 Quais são os diagramas estruturais a Diagrama de classe de objeto de componente de estrutura de pacote e de implantação Diagrama de caso de uso de atividade de máquina de estados e de interação são diagramas comportamentais E diagrama de sequên cia de comunicação de tempo e geral de interação são diagramas comportamentais de interação 2 Quais são os elementos do diagrama de classe a Classes e relacionamentos Atores casos de uso relacionamentos e cenário são elementos do diagrama de caso de uso Atores objetos mensagens linhas de vida são elementos do diagrama de sequência 3 O que é um diagrama de caso de uso b É um diagrama da UML cuja finalidade é representar um requi sito do sistema a ser informatizado e ajudar na comunicação entre os analistas e o cliente 201 Gabarito Diagrama de classe é uma representação com o objetivo de definir e descrever as informações da estrutura usada pelo aplicativo E diagrama de sequência é um diagrama que representa uma sequ ência de processos operações ou métodos no decorrer do tempo 4 O que é um diagrama de sequência c É um diagrama que representa uma sequência de processos operações ou métodos no decorrer do tempo Diagrama de classe é uma representação com o objetivo de definir e descrever as informações da estrutura usada pelo aplicativo E diagrama de caso de uso é um diagrama da UML cuja finalidade é representar um requisito do sistema a ser informatizado e ajudar na comunicação entre os analistas e o cliente 7 Projeto de Sistemas 1 O que é modularidade b É uma estratégia baseada na construção de produtos comple xos a partir da divisão e da estruturação do sistema ou do sof tware em partes distintas chamadas de subsistemas módulos ou componentes Abstração é um conjunto selecionado de conceitos e regras de forma a focar aspectos específicos de interesse em um sistema Refinamento é um processo de elaboração no qual um pro grama é desenvolvido pelo refinamento sucessivo de níveis de detalhes procedimentais 2 O que é usabilidade b É a implementação de recursos e de um atributo de qualidade dos produtos focando o usuário final Confiabilidade é uma medida da capacidade de probabilidade ou de garantia de um sistema um item uma instalação um equipamento um dispositivo um produto ou um serviço para desempenhar uma função Manutenibilidade é uma caracterís Análise e Projetos de Sistemas 202 tica um aspecto ou um atributo da qualidade de software ou de hardware que caracteriza um projeto de sistema produto de software ou componente 3 O que é projeto de dados a É o projeto da estrutura dos dados necessários para implemen tar o software através da transformação das informações obti das durante a fase de análise Projeto de interfaces é o projeto que descreve como o software deve se comunicar interna e externamente como outros sistemas e com seus usuários Projeto procedimental é o projeto que refina e transforma os componentes estruturais em uma descrição procedi mental detalhada da arquitetura do software 4 O que é projeto procedimental c É o projeto que refina e transforma os componentes estrutu rais em uma descrição procedimental detalhada da arquite tura do software Projeto de dados é o projeto da estrutura dos dados necessários para implementar o software através da transformação das infor mações obtidas durante a fase de análise Projeto de interfaces é o projeto que descreve como o software deve se comunicar interna e externamente com outros sistemas e com seus usuários 8 Projeto Lógico e Físico 1 O modelo lógico consiste em a descrever um modelo criado a partir do modelo conceitual para o sistema Projeto lógico consistem em descrever como as informações são organizadas internamente e a estrutura que pode ser processada pelo sistema sem detalhar a estrutura de armazenamento físico e descrever um projeto que poderia ser implementado em diferentes plataformas como hardware linguagem de programação e SGBD 203 Gabarito 2 A primeira e a última atividade do projeto lógico são respectivamente c modelagem de dados e aprovação do projeto lógico Modelagem de processos é a segunda atividade 3 O que é modelo físico c É a organização física das estruturas de armazenamento de dados e dos índices de acesso Modelo lógico é a descrição de um modelo criado a partir do modelo conceitual para o sistema 4 Qual o artefato da etapa do projeto lógico b Documento do projeto físico 9 Estudo de caso 1 De acordo com o requisito não funcional de compatibilidade a intranet deve funcionar nos navegadores Internet Explorer Google Chrome e Mozilla Firefox O fato de ela funcionar também no Safari ou no Opera impacta no escopo do projeto c Não pois fato de ela funcionar em outros navegadores que não os especificados não interfere no escopo do projeto portanto nenhuma alteração é necessária Nem todos os navegadores que suportam a intranet devem estar contemplados no escopo do projeto mas nada impede que ela fun cione apenas nos três navegadores especificados 2 No DER o que significa a relação entre Administrador Usuário e Funcionário representada na imagem a seguir a Administradores e funcionários são usuários Análise e Projetos de Sistemas 204 Usuários não possuem administradores nem funcionários Todo administrador é um usuário assim como todo funcionário tam bém é um usuário 3 Se o cliente pedisse um novo requisito como a possibilidade de inclusão de comentários para as notícias quais seriam as melhores opções de atributos dessa nova classe Comentário a ser criada no diagrama de classes c Id texto data horário usuário e notícia Cada comentário deve estar associado ao usuário que o fez bem como à notícia que o recebeu 4 E quais seriam as chaves estrangeiras dessa nova entidade Comen tário a ser criada no DER c Usuário e notícia O id seria a chave primária e o texto a data e o horário seriam atributos comuns 9 Mais um Estudo de Caso 1 De acordo com os requisitos não funcionais o aplicativo deve funcio nar nos sistemas operacionais Android iOS e Windows O fato de ele funcionar também em outro SO impacta no escopo do projeto c Não pois fato de ele funcionar em outro sistema operacional que não os especificados não interfere no escopo do projeto portanto nenhuma alteração é necessária Nem todos os sistemas operacionais que suportam o aplicativo devem estar contemplados no escopo do projeto mas nada impede que ele funcione apenas nos três SOs especificados 2 Se o cliente pedisse um novo requisito possibilidade de inclusão da sua casa no mapa qual seria o atributo essencial dessa nova classe Casa a ser criada no diagrama de classes a Coordenadas 205 Gabarito Endereço e número não são essenciais para o registro 3 E qual não poderia ser a chave primária dessa nova entidade Casa a ser criada no DER c Endereço Endereços não costumam ser usados como chave primária 4 Esboce o diagrama de sequência da funcionalidade de registro de casa no mapa Não há resposta totalmente correta Referências Análise e Projetos de Sistemas 208 ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS ABNT NBR ISOIEC 25010 Engenharia de software e sistemas Rio de Janeiro 2011 BOOCH G RUMBAUGH J JACOBSON I The unified modeling language user guide Redwood city Addison Wesley Longman 1999 BOOCH G RUMBAUGH J JACOBSON I UML guia do usuário Campus 2005 DAVIDSON M Uncommon sense the life and thought of Ludwig von Bertalanffy 19011972 father of general systems theory California Tar cher 1983 DEMARCO T Análise estruturada e especificação de sistema Rio de Janeiro Campus 1989 ELMASRI R NAVATHE S B Fundamentals of database systems Pear son 2010 GEHRINGER M LONDON J Odisséia Digital São Paulo Abril 2001 GLINZ M Glossário de terminologia engenharia de requisitos 2011 Disponível em httpibqtscombruploadsconteudo5303IREB CPREFLGlossario20Rev20TM2030102013pdf Acesso em 3 jun 2016 IBM IBM rational unified process Disponível em ftppublicdhe ibmcomsoftwarepdfbrRUPDSpdf Acesso em 2 jun 2016 INTERNATIONAL REQUIREMENTS ENGINEERING BOARD Pro fissional para engenharia de requisitos certificado pelo IREB Nível Fundamental Syllabus 2012 Disponível em httpwwwabramtiorg brsitesdefaultfilesarquivossyllabuscprefl21pdf Acesso em 3 jun 2016 MCMENAMIM S M PALMER J F Análise essencial de sistemas São Paulo Makron McgrawHill 1991 MICROSOFT Ajuda do Visio Disponível em httpssupport officecomptbrarticleAjudadoVisiod511cc4408a94157bc38 8738ce586823uiptBRrsptBRadBR Acesso em 7 jun 2016 209 Referências NIELSEN J 10 usability heuristics for user interface design Nielsen Nor man Group 1995 Disponível em httpswwwnngroupcomarticlesten usabilityheuristics Acesso em 12 jul 2016 POHL K RUPP C Fundamentos da engenharia de requisitos Rocky noock 2012 PRESSMAN R S Software engineering a practioners approach New York McGrawHill 2005 THE PROJECT CARTOONCOM BETA Disponível em httpwww projectcartooncom Acesso em 3 jun 2016 UNIFIED MODELING LANGUAGE Disponível em httpwwwuml org Acesso em 10 jun 2016 VON BERTALANFFY L Teoria geral dos sistemas Petrópolis Vozes 2008