Blog

Módulo de Cadastro de Relações — Patologia versus Fármaco Histórico de Revisões Data Versão Descrição Autores 09/03/20121. 0 Criação do Documento Inicial de Especificação dos Requisitos, Protótipo Módulo de Cadastro de Relações – Patologia versus Fármaco Os analistas: Leandro, Marcos, Marcelo e Obede org to view nut*ge índice 1 – Introdução 3 1 . 1 – Definições, Acrônimos e Abreviações 3 1. 2 – Referências3 1. 3 – Identificação e Localização deste Documento 3 2- Visão Geral do Sistema 3 2. 1 – Características dos Usuários 3 2. – Premissas3 2. 3 – Restrições de Cronograma 4 Requisitos Funcionais 4 Requisitos Não-Funcionais 4 – Usabilldade4 4. 1 4. 2 – Confiabilidade4 4. 3 – Desempenho 4 4. 4 – Reusabilidade7 documento é o levantamento de requisitos que propõe detalhar o módulo em uma visão panorâmica, ou seja, pretende explicar como c subsistema integrará aos demais módulos do Departamento de Gestão Laboratorial – DCL. Nessa iteração procuramos focar mais sobre as informações necessárias sobre as doenças e seus medicamentos porque acreditamos ser à base do subsistema. 1. – Referências Patologias e Fármacos, Material dispon[vel em , link Patologias e Fármacos, material disponível em , http://portaI. anvisa. gov. br/wps/content/Anvisa+Portal/Anvisa ‘Inicio/Medicamentos Denise Gastaldo, processo de Engenharia de Requisitos Aplicado a Requisitos Não-Funcionais de Desempenho – Um Estudo de Caso, Material disponível em http://wer. inf. puc-rio. bMwer03/artigos/denise_gastaldo. pdf Goodrich, Michel – Estrutura de Dados e Algoritmos em Java, Trad. Bernardo Copstein, Leandro Bento Pompermeier. – 4. ed. – Porto Alegre: gookman, 2007. 3 – Identificação e Localização deste Documento Coordenação do Curso de Sistemas de Informação – Faculdade Estácio Atual 2 Visão Geral do Sistema 2. 1 – Características dos Usuários A Ferramenta Módulo de Cadastro de Relações – Patologia versus Fármaco será utilizada por um perfil de usuário, tido como usuario balconista que terá permissão apenas de visualizar as informações sobre os medicamentos referentes às doenças e seus dados estatísticos. Um segundo perfil de usuário, tido como administrador poderá realizar as atualizações, alterações e manutenções de cadastros do módulo. . 2 – Premissas Problemas relacionados com vírus, falhas de hardware, quedas de nergia são fatores que podem afetar o funcion com vírus, falhas de hardware, quedas de energia são fatores que podem afetar o funcionamento do módulo, porém pode- se estabelecer uma manutenção preditiva para o hardware, uso de nobreaks para eliminar possíveis danos por queda de energia e uso de um bom anti-vírus, bem como, Tutorial de orientação para usuários sobre como evitar a contaminação por vírus, considerando a utilização de sistemas operacionais Windows. . 3 – Restrições de Cronograma Data da entrega da Etapa – 09. 03. 2012 Data da entrega da 2a Etapa – 02. 05. 2012 3- Requisitos Funcionais RI] Identificar os usuários: Os usuários deverão estar “logados” no sistema antes de acessarem os recursos do Módulo de Cadastro de Relações – Patologia versus Fármaco, de modo que o sistema possa controlar as permissões dos usuários de acordo com o perfil de cada um. R2] O subsistema deverá permitir a visualização completa sobre as doenças pesquisadas, dando como resultado da busca suas formas de tratamento, bem como, os medicamentos receitáveis a cada caso. [R3] O subsistema deve permitir que usuários autorizados sejam capazes de atualizar e alterar as informações. Neste caso, uma escrição do por quê a alteração está sendo feita e deve ser inserida. 4- Requisitos Nao-Funcionais 4. 1 – Usabilidade [R4] A ferramenta deve seguir as recomendações de usabilidade, definidas pelos Analistas do Projeto Módulo de Cadastro de Relações – Patologia versus Fármaco. R5] Será disponibilizado Tutorial que reduzirá consideravelmente o tempo de aprendizagem para que usuános normais tenham bom rendimento no uso da ferramenta. 4. 2 – Confiabilidade [6] O Subsistema Projeto Módulo de Cadast PAGF3rl(Fq rendimento no uso da ferramenta. [6] O Subsistema Projeto Módulo de Cadastro de Relações – atologia versus Fármaco deverá informar ao usuário quando ele tentar fazer uma operação ilegal ou quando ele estiver prestes a realizar uma operação que pode ser “perigosa”. 7] O Subsistema Projeto Módulo de Cadastro de Relações – Patologia versus Fármaco deve possuir mecanismos que garantam que o usuário não perca informações. O subsistema precisa oferecer recursos que possibilitem que o usuario recupere o conteúdo da ferramenta caso ocorra, como, por exemplo, erro de execução do aplicativo, queda de energia, etc. 4. 3 – Desempenho Um requisito de desempenho impõe condições aos requisitos uncionais. or exemplo, para uma determinada ação, ele pode especificar parâmetros de desempenho para: • velocidade • eficiência • disponibilidade • exatidão • taxa de transferência • tempo de resposta • tempo de recuperação • uso de recurso Figura 1 – Processo de engenharia de requisitos aplicado a requisitos não -funcionais de desempenho No processo acima, o ciclo para ambas as visões, não-funcional e funcional, inicia-se com o entendimento do domínio da aplicação, fase que caracteriza o processo de elicitaç¿o de requisitos da engenharia de requisitos.

A interface entre o mundo real e a máquina é formada pelos requisitos que os sistemas devem atender; por sua vez, as especificações de requisitos são as descrições desta interface. Assim, o domínio da aplicação é a propriedade al que conhecemos e que verdadeiras, e os requisitos de um sistema são as propriedades do mundo que se deseja atingir através de um sistema computacional. O domínio da aplicação é a conexão entre o que a máqulna deve fazer e os requisitos da aplicação.

Somente com o entendimento do domínio da aplicação será possível definir os requisitos de um sistema. Muitos erros encontrados nos requisitos são provenientes da falta de entendimento do domínio da aplicação. O passo seguinte do ciclo é a definição dos requisitos do cliente que retratam o entendimento do domínio da aplicação aplicado à visão sistêmica. Este passo também é comum para as visões funcional e não-funcional e também está caracterizado dentro da fase de elicitação de requisitos do processo de engenharia de requisitos.

Com o entendimento do domínio da aplicação e a definição dos requisitos do cliente é possível fazer a identificação dos requisitos ão-funcionais de desempenho, que consiste na identificação de características de desempenho dentro do conjunto de requisitos definidos. Após a identificação dos requisitos não-funcionais de desempenho ocorre a definição dos casos de uso, iniciando a fase de análise do processo de engenharia de requisitos. Os casos de uso capturam as funcionalidades básicas do sistema de uma maneira facilmente entendlda pelos usuários não técnicos.

Pode ser utilizado para representar todo o sistema elou partes do sistema. Os casos de uso são representados por atores, que nteragem com o sistema e por funcionalidades realizadas pelos atores e podem ser aplicados nas fases de análise, projeto, implementação e testes. Desta forma, é possível caracterizar uma das atividades da implementação e testes. Desta forma, é possível caracterizar uma das atividades da fase de análise do processo de engenharia de requisitos, pois com a utilização dos casos de uso é possível identificar além das funcionalidades do sistema os pontos de negociação e novos cenários a visão funcional.

A fase de análise se estende nas atividades de utilização da linguagem de specificação PLanguage e utilização dos grafos de requisitos nao- funcionais. A utilização destes métodos auxilia o entendimento mais aprofundado do sistema permitindo a definição da solução computacional nos projetos. A utilização da PLanguage e dos grafos de requisitos não-funcionais pertence à fases de análise e serão descritas nas seções seguintes.

A documentação, próxima fase do processo de engenharia de requisitos, será composta pela saída da fase de análise que irá gerar diagramas de caso de uso, descrição dos casos de uso, descrição dos requisitos em PLanguage e representação dos requisitos nao-funcionais através dos grafos. A fase de validação será composta pela aceitação do documento gerado na fase de documentação pelo cliente interno e externo, liberando as especificações dos requisitos não- funcionais de desempenho para a fase de projeto detalhado.

Características 1. Comparações no pior caso: 2n log2n + O(n) é o mesmo que 2n Ign + ocn) 2. Trocas no pior caso: n log2n + O(n) é o mesmo que n Ign + O(n) 3. Melhor e pior caso: O(n log2n) é o mesmo que O(n Ign) Código em C++ template void heap_sort( std::vector ) nt tam = static_cast( lista. size() ), i; for( i = tamn -1; 0; – PAGFsrl(Fq for( i = tam/2 – 1; 0; –i ) maxHeapify(lista, i , tam ); iterator elem; for( elem lista. rbegin(); elem lista. rend(); elem++ ) std::iter_swap( elem, lista. egin() ); maxHeapifiy( lista, O, –tam void maxHeapify( std::vector &lista, const int pos, const int n ) int max=2 * pos + 1; max < n) (max 1) < n lista. at(max) < lista. at(max+l) ) if( lista. at(max) > lista. at(pos) ) lista[max], lista[pos] ); lista, max, n 4. 4 — Reusabilidade Bass et Al (2003, p. 31) afir PAGFarlfq do custo de um t[pico requisitos, análise e desenho”. Segundo ele “a partir daí, ganhos significativos só são conseguidos por meio de reutilização” Prof. Dr.

Jorge Henrique Cabral Fernandes DIMAP-UFRN Janeiro de 2004 – define Reuso e Reusabilidade como um processo de se utilizar múltiplas cópias de um componente de software preexistente em vários sistemas e configurações novas. O reuso das funções providas pelo componente deve ser feito utilizando- se apenas da interface deste. Em outras palavras, não deve haver modificações no código deste componente. 4. 5 – Requisitos de Ambiente de Desenvolvimento Armazenamento de Dados: Arquivos Binários e Arquivos TXT

Linguagem de Programação: C++ IDE: Qt 4 SDK Gerador de Relatório: Nenhum (Saída em TXT) 6 – Requisitos de Ambiente do Cliente Estes são os requisitos básicos necessários para utilizar o Subsistema Módulo de Cadastro de Relações – Patologia versus Fármaco Versão 1 Componentes de Hardware Configuração mínima exigida Configuração Recomendável Processador Intel Pentium 4 1. 7 Intel dual core 1. 7 MHZ ou Equivalente RAM 1 GBI GB Espaço disponível em disco (HD)320 GB 500 GB Resoluçao de tela 800×600 1024×728 Impressora Jato de tinta ou a laser – Componentes de Software Configuração minima exiglda

Sistema operacional Windows 2000/XPNista/7 x86Windows XP/ Vista/Seven Adobe Acrobat Reader Versão 7. 0 -NET Framework n 2. 0 C] PAGF8rl(Fq Processador Intel Pentium IV 1. 3 GHZ AMD sempron 2. 200+ GHZ RAM 1 GB Espaço disponível em disco (HD)N/A. Resolução de tela 800×600 Componentes de Software Configuração mínima exigida Sistema operacional Windows 2000/XPNista/seven x86/64 bits Navegadores Cl Microsoft Internet Explorer 6. x ou superior (Windows 2000/XP/Vista) C] Mozilla Firefox 2. x ou superior (Windows 2000/XPNista) 7- Requisitos de Interface 7. 1 – Interfaces com o Usuário Figura 1 Tela Inicial do Módulo

Descrição para o usuário acessar a tela inicial deverá ter inicializado o computador, acessado o Sistema Departamento de Gestão Laboratorial – DGC e só então acessar o Módulo de Cadastro de Relações – Patologias versus Fármaco digitando seu login e senha. Figura 2 – Tela Módulo de Pesquisa de Patologias e Fármacos O usuário depois de digitado login e senha e na tela do módulo pesquisa aparecerá um campo onde pede para Informar a Patologia, após o usuário digitar Inflamação de Garganta, por exemplo, deverá aparecer as informa ões sobre o princípio ativo – diclofenaco de Sódi o Medicamento