Definição de requisitos de software baseada numa arquitetura de modelagem de negócios

Não é uma tarefa fácil definir requisitos para os sistemas de software que darão suporte a um negócio, dada a dinâmica de mudanças nos processos. O levantamento de requisitos tem sido feito de forma empírica, sem o apoio de métodos sistematizados que garantam o desenvolvimento baseado nos reais objetivos do negócio. A engenharia de software carece de métodos que tornem mais ordenadas e metódicas as etapas de modelagem de negócios e de levantamento de requisitos de um sistema. Neste artigo é apresentada uma metodologia de desenvolvimento de software resultante da incorporação de atividades propostas para modelagem de negócios e levantamento de requisitos, baseadas em uma arquitetura de modelagem de negócios. Essas atividades tornam o desenvolvimento de software mais sistemático e alinhado aos objetivos da organização, e podem ser incorporadas em qualquer metodologia de desenvolvimento baseada no UP (Unified Process - Processo Unificado).

Apoio à gerência de requisitos de software utilizando Design Rationale

Coordenação de Aperfeiçoamento de Pessoal de Nível Superior (CAPES)

Gerência de mudanças de requisitos: uma proposta de aplicação a um estudo de caso

As organizações desenvolvedoras de software, na sua maioria, têm grande dificuldade de identificar e adotar um processo adequado de gestão de mudanças de requisitos. Durante todo o ciclo de vida de desenvolvimento de um software existem inúmeras solicitações de mudanças de escopo e de requisitos (técnicos ou não). Isso provoca muitos transtornos aos projetos e aos envolvidos. Por isso, há uma necessidade determinante de que essas organizações utilizem um processo adequado de acompanhamento e de controle de requisitos. Com base nisso, este trabalho procura apresentar uma metodologia de gerenciamento de mudanças dos requisitos, desde a base conceitual, que envolve os requisitos ( tipos, problemas, técnicas de elicitação e visão geral sobre modelo de gerência de requisitos), até a aplicação da metodologia proposta em um estudo de caso. O desenvolvimento deste trabalho teve como objetivo principal desenvolver a estrutura de uma metodologia que fosse de fácil aplicação nas organizações, dando uma noção de como devem ser gerenciadas as mudanças de requisitos, sua documentação, os modelos de documentos a serem utilizados e um exemplo prático de aplicação da metodologia.

FRIDA: um método para elicitação e modelagem de RNFs

Os requisitos direcionam o desenvolvimento de software porque são cruciais para a sua qualidade. Como conseqüência tanto requisitos funcionais quanto não funcionais devem ser identificados o mais cedo possível e sua elicitação deve ser precisa e completa. Os requisitos funcionais exercem um papel importante uma vez que expressam os serviços esperados pela aplicação. Por outro lado, os requisitos não funcionais estão relacionados com as restrições e propriedades aplicadas ao software. Este trabalho descreve como identificar requisitos não funcionais e seu mapeamento para aspectos. O desenvolvimento de software orientado a aspectos é apontado como a solução para os problemas envolvidos na elicitação e modelagem dos requisitos não funcionais. No modelo orientado a aspectos, o aspecto é considerado o elemento de primeira ordem, onde o software pode ser modelado com classes e aspectos. As classes são comumente usadas para modelar e implementar os requisitos funcionais, já os aspectos são adotados para a modelagem e implementação dos requisitos não funcionais. Desse modo, é proposta a modelagem dos requisitos não funcionais através das fases do ciclo de vida do software, desde as primeiras etapas do processo de desenvolvimento. Este trabalho apresenta o método chamado FRIDA – From RequIrements to Design using Aspects, cujo objetivo é determinar uma forma sistemática para elicitar e modelar tanto os requisitos funcionais quanto os não funcionais, desde as fases iniciais do ciclo de desenvolvimento. Em FRIDA, a elicitação dos requisitos não funcionais é realizada usando-se checklists e léxicos, os quais auxiliam o desenvolvedor a descobrir os aspectos globais – utilizados por toda a aplicação – bem como, os aspectos parciais que podem ser empregados somente a algumas partes da aplicação. O próximo passo consiste na identificação dos possíveis conflitos gerados entre aspectos e como resolvê-los. No método FRIDA, a identificação e resolução de conflitos é tão importante quanto a elicitação de requisitos não funcionais, nas primeiras fases do ciclo de vida do software. Além disso, é descrito como usar a matriz de conflitos para automatizar esse processo sempre que possível. A extração dos aspectos e sua modelagem visual são características muito importantes, suportadas pelo método, porque elas possibilitam a criação de modelos que podem ser reutilizados no futuro. Em FRIDA, é demonstrado como transformar os requisitos em elementos da fase de projeto (classes e aspectos) e como traduzir esses elementos em código. Outra característica do método FRIDA é que a conexão entre diagramas, que pertencem a diferentes fases do processo de desenvolvimento do software, permite um alto nível de rastreabilidade. Em resumo, FRIDA requer que o desenvolvedor migre de uma visão puramente funcional para outra que contemple também os requisitos não funcionais.

Interfaz web para BaDELE3000

El objetivo del presente Trabajo de Fin de Carrera es el estudio, diseño e implementación de una aplicación web que sirva de interfaz para una base de datos relacional llamada BaDELE3000 que trabaja actualmente con unos 3000 lexemas y sigue en fase de desarrollo. BaDELE modela conceptos y principios lingüísticos más o menos complejos, dentro del marco de la Teoría Sentido-Texto. El desarrollo de esta interfaz, permitirá a personas autorizadas, seguir nutriendo la base de datos. La memoria está formada por cinco capítulos, una bibliografía y un apéndice. Cada capítulo se divide en secciones. La sección, «Estado de la cuestión», introduce las bases linguísticas en las que se basa el modelo desarrollado, y su situación actual. En la tercera sección, «Especificación de Requisitos Software», se recogen todos los requisitos que el cliente ha transmitido al desarrollador. La siguiente sección de la memoria, «Desarrollo de la aplicación», es la más extensa. Empieza de manera teórica, describiendo los ciclos de vida en cascada y en espiral. En los siguientes apartados de la sección se explican las diferentes fases del ciclo de vida: fase de análisis, fase de diseño, centrándose en la elaboración del modelo de datos y relacional, fase de implementación, explicando las decisiones importantes en el desarrollo de la aplicación y la estructura modular de la aplicación, y por último, se trata la fase de pruebas, describiendo los tipos de pruebas ejecutados sobre el sistema y cómo se realizaron. En la quinta sección, se añaden las conclusiones obtenidas como fruto del trabajo realizado y se tratan posibles aspectos de mejora en la aplicación. En última sección, se incluye toda la bibliografía consultada y el manual de instalación y usuario de la aplicación

Dos requisitos à arquitetura em linhas de produtos de software: uma estratégia de transformações entre modelos

The tracking between models of the requirements and architecture activities is a strategy that aims to prevent loss of information, reducing the gap between these two initial activities of the software life cycle. In the context of Software Product Lines (SPL), it is important to have this support, which allows the correspondence between this two activities, with management of variability. In order to address this issue, this paper presents a process of bidirectional mapping, defining transformation rules between elements of a goaloriented requirements model (described in PL-AOVgraph) and elements of an architectural description (defined in PL-AspectualACME). These mapping rules are evaluated using a case study: the GingaForAll LPS. To automate this transformation, we developed the MaRiPLA tool (Mapping Requirements to Product Line Architecture), through MDD techniques (Modeldriven Development), including Atlas Transformation Language (ATL) with specification of Ecore metamodels jointly with Xtext , a DSL definition framework, and Acceleo, a code generation tool, in Eclipse environment. Finally, the generated models are evaluated based on quality attributes such as variability, derivability, reusability, correctness, traceability, completeness, evolvability and maintainability, extracted from the CAFÉ Quality Model

Reqsys-MDD: uma ferramenta para mapeamento entre modelos de features e requisitos em linhas de produto de software

The approach Software Product Line (SPL) has become very promising these days, since it allows the production of customized systems on large scale through product families. For the modeling of these families the Features Model is being widely used, however, it is a model that has low level of detail and not may be sufficient to guide the development team of LPS. Thus, it is recommended add the Features Model to other models representing the system from other perspectives. The goals model PL-AOVgraph can assume this role complementary to the Features Model, since it has a to context oriented language of LPS's, which allows the requirements modeling in detail and identification of crosscutting concerns that may arise as result of variability. In order to insert PL-AOVgraph in development of LPS's, this paper proposes a bi-directional mapping between PL-AOVgraph and Features Model, which will be automated by tool ReqSys-MDD. This tool uses the approach of Model-Driven Development (MDD), which allows the construction of systems from high level models through successive transformations. This enables the integration of ReqSys-MDD with other tools MDD that use their output models as input to other transformations. So it is possible keep consistency among the models involved, avoiding loss of informations on transitions between stages of development

ONTOLOGIAS DE DOMÍNIO PARA CONVERSÃO DE CONHECIMENTO TÁCITO EM EXPLÍCITO NA MODELAGEM DE REQUISITOS DE SOFTWARE: APLICAÇÃO EM UM PROJETO DE DATA WAREHOUSE PARA A INDÚSTRIA MÉDICA FARMACÊUTICA

A pesquisa tem o objetivo de contribuir para os estudos relacionados ao desenvolvimento de software, mais especificamente à fase de levantamento de requisitos da Engenharia de Software, ao esclarecer como um método não muito popular, a construção de Ontologias de Domínio, pode ajudar na definição de requisitos de qualidade, que consequentemente contribuem para o sucesso de projetos de implementação de sistemas de informação.

Metaheurísticas como soporte a la selección de requisitos del software

Las técnicas de optimización y metaheurísticas han sido aplicadas ampliamente en numerosas áreas, entre ellas la Ingeniería del Software. En este trabajo mostramos la incorporacíon de estas técnicas como soporte a las tareas de selección de un grupo de requisitos de entre aquellos que han sido propuestos por los clientes, validando experimentalmente sus resultados. Los algoritmos metaheurísticos son ejecutados desde una herramienta web que permite la definicíon colaborativa de los requisitos de un proyecto software y ayudan a los desarrolladores durante la ejecución del mismo.

Problem-Based SRS: método para especificação de requisitos de software baseado em problemas

Requirements specification has long been recognized as critical activity in software development processes because of its impact on project risks when poorly performed. A large amount of studies addresses theoretical aspects, propositions of techniques, and recommended practices for Requirements Engineering (RE). To be successful, RE have to ensure that the specified requirements are complete and correct what means that all intents of the stakeholders in a given business context are covered by the requirements and that no unnecessary requirement was introduced. However, the accurate capture the business intents of the stakeholders remains a challenge and it is a major factor of software project failures. This master’s dissertation presents a novel method referred to as “Problem-Based SRS” aiming at improving the quality of the Software Requirements Specification (SRS) in the sense that the stated requirements provide suitable answers to real customer ́s businesses issues. In this approach, the knowledge about the software requirements is constructed from the knowledge about the customer ́s problems. Problem-Based SRS consists in an organization of activities and outcome objects through a process that contains five main steps. It aims at supporting the software requirements engineering team to systematically analyze the business context and specify the software requirements, taking also into account a first glance and vision of the software. The quality aspects of the specifications are evaluated using traceability techniques and axiomatic design principles. The cases studies conducted and presented in this document point out that the proposed method can contribute significantly to improve the software requirements specification.

BPM e gestão de requisitos : uma proposta de alinhamento para a Câmara dos Deputados

Estuda a relação existente entre a ferramenta de gestão de processos de negócio Business Process Management (BPM) e o Processo CENIN de Desenvolvimento (PROCEDE) para propor as mudanças necessárias para que o Centro de Informática possa dar tratamento adequado à nova forma de demanda de soluções de software pelos órgãos da Câmara dos Deputados.

Sistema software para el control de producción de la unidad de rodajes

El presente proyecto consiste en el análisis y búsqueda de soluciones para el control de producción de la unidad de rodajes de la compañía CAF S.A. Para ello, se ha tenido que analizar procesos de producción, capturar requerimientos, desarrollar unas herramientas de control de producción temporales y elaborar una especificación de requisitos. Sin olvidar la gestión e interlocución con proveedores. Estas líneas de trabajo se encuentran descritas en esta memoria, junto con análisis de resultados, conclusiones y unas líneas futuras donde se seguirá trabajando.

O ZEP Framework: um framework para a criação de métodos para envolvimento de stakeholders no desenvolvimento de soluções de software.

A especificação dos requisitos de software pressupõe que se conheçam os requisitos do sistema do que será parte. Os requisitos do sistema, por sua vez, pressupõem o conhecimento do negócio (business) onde o sistema será utilizado. Para que estes conhecimentos sejam obtidos é importante o envolvimento dos stakeholders tanto no nível de sistema quanto no nível de negócio. As literaturas sobre Engenharia de Requisitos, Engenharia de Software e Engenharia de Sistemas concordam que o envolvimento dos stakeholders é fundamental. O tratamento dispensado ao assunto, no entanto, é pequeno, dada a importância do tema. Esta dissertação, utilizando conceitos da Engenharia de Métodos Situacionais e de Design Science, apresenta o ZEP Framework, um artefato, produzido com o software EPF Composer, que permite a criação de métodos para envolver o stakeholder. Estes métodos, para serem criados, devem levar em consideração as peculiaridades da organização, dos recursos disponíveis e do projeto em si. São apresentados, ainda, alguns cenários, na área de Turismo, como exemplos da utilização do framework.