Made available in DSpace on 2014-06-12T15:57:50Z (GMT). No. of bitstreams: 2 arquivo3233_1.pdf: 1717748 bytes, checksum: fc31dd5d633c8fe2f7bf27b2e26c7705 (MD5) license.txt: 1748 bytes, checksum: 8a4605be74aa9ea9d79846c1fba20a33 (MD5) Previous issue date: 2009 / A aquisição de serviços de Tecnologia da Informação (TI) pela Administração Pública (AP) se faz necessária para a melhoria do atendimento à sociedade e ao cidadão. Nos serviços de desenvolvimento de software são necessários métodos de gerenciamento de seus processos. Para o setor público também se faz necessário o atendimento a requisitos legais do processo licitatório. Ao mesmo tempo em que a Administração Pública busca soluções de TI, a sua implementação nem sempre é bem sucedida, por planejamento insuficiente, por contestações na publicação do edital de licitação pública ou por problemas no gerenciamento de seus contratos. Na revisão realizada na literatura, ficou evidenciado que um dos problemas da aquisição pública está em sua gestão. A gestão de contratos de serviços exige cuidados especiais e novas competências do pessoal de TI, especialmente em relação à legislação vigente. Assim surge uma indagação: existe um modelo de processo de engenharia que possa orientar o gestor público na aquisição de serviços de desenvolvimento de software que seja aderente ao marco legal? O objetivo deste trabalho é propor um processo de aquisição de serviços de TI na AP adequado às diretrizes dadas pela Instrução Normativa MPOG nº 4/2008. O foco escolhido foi a fase de gerenciamento do contrato de aquisição de serviços de TI. Neste trabalho, o serviço de TI a ser adquirido está restrito ao desenvolvimento completo de software. A metodologia adotada dividiu o trabalho em cinco fases. Inicialmente buscou-se uma revisão teórica de modelos e padrões de aquisição, bem como uma revisão do marco legal. A segunda fase foi realizada com entrevistas a gestores de TI de órgãos de esferas e poderes diversos da AP. A terceira fase foi dedicada ao desenvolvimento da primeira versão da proposta de modelo de processo. Aqui foi feita a publicação da proposta na web e desenvolvido um questionário para a fase seguinte. Na quarta fase houve uma pré-avaliação do modelo com gestores públicos experientes em serviços de TI. Foram realizadas entrevistas apresentando o modelo na web e foi solicitado o retorno de contribuições técnicas pelo questionário desenvolvido também disponível na web. A última fase foi uma validação final através de questionários via web com uma solicitação dirigida aos especialistas por e-mail. O processo de gerenciamento da execução do contrato de aquisição proposto segue as diretrizes dadas pela Instrução Normativa nº 4/2008, é referenciado pelas melhores práticas e modelos da literatura técnica e acadêmica, por trabalhos relacionados, bem como pelo referencial legal consultado. É dirigido para uso na Administração Pública e para aqueles que adquirem segundo a Lei nº 8.666/1993. A solução contempla fluxos de atividades, descrição de tarefas com instruções, artefatos, responsáveis, templates e referências. Parte deste modelo de processo é um guia para uso pelo gestor do contrato, acessível na web com navegação por hipertextos. Este processo foi submetido a gestores de aquisição de serviços de TI na AP, em um processo de validação, que consideraram a solução como adequada e que pode ser uma referência na gestão da fase do gerenciamento do contrato

[pt] Leis e regulamentos afetam o desenvolvimento de software, já que freqüentemente exigem mudanças nos requisitos de software para proteger indivíduos e empresas em relação à segurança, privacidade, governança, sustentabilidade e muito mais. Requisitos legais podem ditar novos requisitos ou restringir os existentes. O problema da conformidade de software é como garantir que o software esteja em conformidade com as normas impostas pela legislação. O problema é particularmente desafiador porque combina etapas difíceis: 1) analisar documentos legais, 2) extrair requisitos desses documentos, 3) identificar requisitos conflitantes com aqueles já implementados em software e 4) garantir que o software permaneça compatível mesmo com as alterações. A conformidade é um processo contínuo: as leis, o software e o contexto no qual o sistema de software opera mudam continuamente. Os trabalhos que lidam com o problema de conformidade concentram-se apenas em um ou dois assuntos: analisar documentos legais ou extrair requisitos ou identificar conflitos ou mudanças. Esta tese trata de todos os problemas ao mesmo tempo; a ideia é extrair requisitos do texto legal, compará-los com o requisito de software, resolver os possíveis conflitos que possam surgir, lidando continuamente as mudanças no ambiente, leis e requisitos. Para tanto, este trabalho propõe um framework que é composto por um processo de compliance e monitoramento contínuo das mudanças ambientais. O processo de conformidade suporta a identificação, extração, comparação e resolução de conflitos para ajudar na conformidade do software, produzindo um conjunto conforme de requisitos. O processo de conformidade é baseado na anotação semântica e no modelo de meta. A anotação semântica ajuda a extrair requisitos do arquivo, usando padrões. O modelo de meta é usado para ajudar na comparação entre requisitos e representar requisitos em uma especificação de requisitos formal e consistente. O processo é suportado por ferramentas; sendo algumas reutilizadas (Desiree e NomosT) para avançar cada etapa. Foi necessário adaptar as ferramentas para o contexto do processo de conformidade, criando diretrizes, padrões e heurísticas. O monitoramento contínuo está preocupado com as mudanças que afetam a conformidade do software e tem o mecanismo para garantir que, mesmo com essas mudanças, o software recupere a conformidade. O monitoramento da conformidade é baseado em agentes e requisitos não funcionais. Os agentes são representados usando em i, a idéia é mostrar a colaboração entre os agentes para garantir a conformidade contínua. A especificação de requisitos de como cada agente deve se comportar também foi gerada usando a linguagem Desiree e BPMN. O catálogo de Requisitos Não Funcionais é usado para ajudar a definir as operações para o reconhecimento de software. A validação do framework foi feita em duas partes: primeiro, o processo de compliance e após todo o framework proposto. Para o processo de conformidade, o esforço e a exatidão foram medidos comparando o uso do processo proposto e um método ad-hoc. Para todo o framework, foi usado o exemplo de monitoramento das mudanças no ambiente quando um carro automatizado cruza a fronteira entre Washington e o Canadá. A contribuição deste trabalho é a estrutura da Eunomia, que tem uma perspectiva de processo e modelo de metas, com ênfase no monitoramento que ajuda a lidar com o desafio da conformidade. O framework equipa a equipe de engenharia de requisitos com um método sistemático e suportado por ferramentas que pode ser reutilizado para reduzir o esforço de tempo e melhorar a qualidade da especificação de requisitos. / [en] Laws and regulation affect software development, as they frequently demand changes in software requirements to protect individuals and businesses regarding security, privacy, governance, sustainability and more. Legal requirements can dictate new requirements or constrain existing ones. The problem of software compliance is how to ensure that the software complies with the norms that the legislation imposes. The problem is particularly challenging because it combines difficultsteps: 1)analyze legal documents, 2) extract requirements from those documents, 3) identify conflictingrequirements with those already implemented in software and 4) ensure that software remains compliant even with the changes. Compliance is a continuous process: laws, software and the context within which software system operates changes continuously. The works dealing with the compliance problem focus only on one or two subjects: analyze legal documents or extract requirements or identify conflicts or changes. This thesis deals with all the problems at the same time; the idea is to extract requirements from legal text, compare them with the software requirement, resolve the possible conflicts that may arise, continuously leading with the changes on environment, laws and requirements. For this, this work proposes a framework that is composed of a compliance process and continuous monitoring of environmental changes. The framework deals with different types of laws (security, privacy, transparency, health care) that are represented in explicit norms. The compliance process supports the identification, extraction, comparison and conflict resolution to help software compliance, by producing a compliant set of requirements. The compliance process is based on the semantic annotation and goal model. The semantic annotation helps to extract requirements from thelaw, using patterns. The goal model is used to help the comparison between requirement and to represent requirements in a formal and consistent requirement specification. The process is tool supported; some tools were reused (Desiree and NomosT) to further each step. It was necessary to adapt the tools for the context of the compliance process, creating a guideline, patterns, and heuristics. The continuous monitoring is concerned about the changes that affect the software compliance and has presented using in i, the idea is to showthe collaboration between the agents to ensure the continuous compliance. The requirement specification of how each agent should behave was also generated using Business Process Modeling Notation and Desiree language. The Non Functional Requirements catalogue is used to help to define operalizations for the software awareness. The framework validation was made in two parts: first, the compliance process and after all the framework proposed. For the compliance process, the effort and correctness were measured comparing the use of the proposed process andan ad-hoc method. For the entire framework, the example of monitoring the changes in the environment when an automated car is crossing the border between Washington and Canada was used. The study shows that context has a strong influence on the software requirements, and nonconformity problems may incur penalties. The contribution of this work is the Eunomia framework that has a process and goal model perspective with emphasis on monitoring that helps to deal with the compliance challenge. The framework equips the requirements engineering team with a systematic method. Eunomia framework is a tool-supported and systematic process which can be reused to reduce the time effort and to improve the quality of the requirement specification that helps to create a compliant software requirement specification that is compliant over the time.

Submitted by Clebson Anjos (clebson.leandro54@gmail.com) on 2016-02-11T19:32:02Z No. of bitstreams: 1 arquivototal.pdf: 4976069 bytes, checksum: f6823a093e9be9d6a14113d2ff7e56f3 (MD5) / Made available in DSpace on 2016-02-11T19:32:02Z (GMT). No. of bitstreams: 1 arquivototal.pdf: 4976069 bytes, checksum: f6823a093e9be9d6a14113d2ff7e56f3 (MD5) Previous issue date: 2014-07-24 / Coordenação de Aperfeiçoamento de Pessoal de Nível Superior - CAPES / In software development process, Requirements Engineering is responsible for identifying what are the objectives of the desired product, its features, activities and constraints, based on the understanding of the scenario where this product is used and/or expected behaviors by users. To interact directly or indirectly with the people, the products and the processes impacted by them, are required to comply with the legal regulations related and found in the legal rules or laws. At the organizational level, these regulations determine how business practices should be, which will be reproduced for their products/processes. The Legal Compliance is a requirement imposed on organizations by government departments and their non-compliance may result in legal and financial problems for these organizations. It is the role of Requirements Engineering dealing with legal compliance in these scenarios. In this context, the Nòmos framework extends the i* framework to achieve legal compliance requirements of information systems and business processes. Nòmos proposes a systematic and cohesive method to achieve this goal, from the execution of activities of elicitation, modeling and negotiation of requirements and laws. However, Nòmos was designed to be used in requirements models represented in i*. Since i* is not widely used in industry, dependence on i* can hurt the adoption of Nòmos as a process to achieve legal compliance in Requirements Engineering. In this sense, this work proposes to adapt the process of Nòmos, making it less dependent on i* and more flexible to be used with other modeling languages requirements. So, was created the GenNormas, in order to guide the acquisition of legal compliance of software requirements or business processes specified in other modeling languages, in addition to i *. Finally, to illustrate the use of our approach, it has been applied in the specification of a hypothetical system, connected to the e-commerce domain, applying GenNormas in requirements specification models, such as the Business Process Modeling Notation (BPMN), in Use Case Diagram and the User Stories. / No processo de desenvolvimento de software, a Engenharia de Requisitos é responsável por identificar quais são os objetivos do produto pretendido, suas funcionalidades, atividades e restrições, a partir do entendimento do cenário onde este produto será utilizado e/ou dos comportamentos esperados por seus usuários. Por interagirem direta ou indiretamente com as pessoas, estes produtos, e os processos impactados por eles, estão obrigados a cumprirem com as regulamentações jurídicas relacionadas e encontradas nas normas jurídicas ou leis. No âmbito organizacional, estas regulamentações determinam como devem ser as práticas de negócio, que serão reproduzidas por seus produtos/processos. A conformidade legal é uma exigência imposta às organizações pelos departamentos governamentais e o seu não-cumprimento pode acarretar transtornos judiciais e financeiros às organizações. É papel da Engenharia de Requisitos lidar com a conformidade legal nestes cenários. Nesse contexto, o Framework Nòmos estende o Framework i* para alcançar a conformidade legal dos requisitos de sistemas de informação e de processos de negócio. Nòmos propõe um método sistemático e coeso para atingir este objetivo, a partir da execução de atividades de elicitação, modelagem e negociação de requisitos e leis. Porém, Nòmos foi concebido para ser usado em modelos de requisitos representados em i*. Visto que o i* não é usada amplamente na indústria, a dependência do i* pode prejudicar a adoção do Nòmos como processo para alcançar a conformidade legal na engenharia de requisitos. Neste sentido, esta dissertação propõe adaptar o processo do Nòmos, tornando-o menos dependente do i* e mais flexível para ser utilizado com outras linguagens de modelagem de requisitos. Assim, foi criado o GenNormas no intuito de guiar a obtenção da conformidade legal de requisitos de software ou de processos de negócio especificados em outras linguagens de modelagem, além do i*. Finalmente, para exemplificar a utilização da nossa abordagem, ela foi aplicada na especificação de um sistema hipotético, ligado ao domínio do comércio eletrônico, aplicando o GenNormas em modelos de especificação de requisitos, como a Notação de Modelagem para Processos de Negócio (BPMN), no Diagrama de Caso de Uso e nas Estórias de Usuário.