Software Analysts Research Articles

QUARE: towards a question-answering model for requirements elicitation

Requirements elicitation is a stakeholder-centered approach; therefore, natural language remains an effective way of documenting and validating requirements. As the scope of the software domain grows, software analysts process a higher number of requirements documents, generating delays and errors while characterizing the software domain. Natural language processing is key in such a process, allowing software analysts for speeding up the requirements elicitation process and mitigating the impact of the ambiguity and misinterpretations coming from natural-language-based requirements documents. However, natural-language-processing-based proposals for requirements elicitation are mainly focused on specific domains and still fail for understanding several requirements writing styles. In this paper, we present QUARE, a question-answering model for requirements elicitation. The QUARE model comprises a meta-ontology for requirements elicitation, easing the generation of requirements-elicitation-related questions and the initial structuration of any software domain. In addition, the QUARE model includes a named entity recognition and relation extraction system focused on requirements elicitation, allowing software analysts for processing several requirements writing styles. Although software analysts address a software domain at a time, they use the same kind of questions for identifying and characterizing requirements abstractions such as actors, concepts, and actions from a software domain. Such a process may be framed into the QUARE model workflow. We validate our proposal by using an experimental process including real-world requirements documents coming from several software domains and requirements writing styles. The QUARE model is a novel proposal aimed at supporting software analysts in the requirements elicitation process.

Locating and categorizing inefficient communication patterns in HPC systems using inter-process communication traces

High Performance Computing (HPC) systems are used in a variety of industrial and research sectors to solve complex problems that require powerful computing platforms. For these systems to remain reliable, we should be able to debug and analyze their behavior in order to detect root causes of potential poor performance. Execution traces hold important information regarding the events and interactions among communicating processes, which are essential for the debugging of inter-process communication. Traces, however, tend to be considerably large, hindering their applicability. In previous work, we presented an approach for automatically detecting communication patterns and segmenting large HPC traces into execution phases. The goal is to reduce the effort of analyzing traces by allowing software analysts to focus on smaller parts of interest. In this paper, we propose an approach for detecting and localizing inefficient communication patterns using statistical and trace segmentation methods. In addition, we use the Analytic Hierarchy Process to categorize slow communication patterns based on their severity and complexity levels. Using our approach, an analyst can quickly locate slow communication patterns that may be the cause of important performance problems. We show the effectiveness of our approach by applying it to large traces from three HPC systems.

A Lightweight BPMN Extension for Business Process-Oriented Requirements Engineering

Process-oriented requirements engineering approaches are often required to deal with the effective adaptation of existing processes in order to easily introduce new or updated requirements. Such approaches are based on the adoption of widely used notations, such as the one introduced by the Business Process Model and Notation (BPMN) standard. However, BPMN models do not convey enough information on the involved entities and how they interact with process activities, thus leading to ambiguities, as well as to incomplete and inconsistent requirements definitions. This paper proposes an approach that allows stakeholders and software analysts to easily merge and integrate behavioral and data properties in a BPMN model, so as to fully exploit the potential of BPMN without incurring into the aforementioned limitation. The proposed approach introduces a lightweight BPMN extension that specifically addresses the annotation of data properties in terms of constraints, i.e., pre- and post-conditions that the different process activities must satisfy. The visual representation of the annotated model conveys all the information required both by stakeholders, to understand and validate requirements, and by software analysts and developers, to easily map these updates to the corresponding software implementation. The presented approach is illustrated by use of two running examples, which have also been used to carry out a preliminary validation activity.

Integrating Option Grid Patient Decision Aids in the Epic Electronic Health Record: Case Study at 5 Health Systems.

BackgroundSome researchers argue that the successful implementation of patient decision aids (PDAs) into clinical workflows depends on their integration into electronic health records (EHRs). Anecdotally, we know that EHR integration is a complex and time-consuming task; yet, the process has not been examined in detail. As part of an implementation project, we examined the work involved in integrating an encounter PDA for symptomatic uterine fibroids into Epic EHR systems.ObjectiveThis study aims to identify the steps and time required to integrate a PDA into the Epic EHR system and examine facilitators and barriers to the integration effort. MethodsWe conducted a case study at 5 academic medical centers in the United States. A clinical champion at each institution liaised with their Epic EHR team to initiate the integration of the uterine fibroid Option Grid PDAs into clinician-facing menus. We scheduled regular meetings with the Epic software analysts and an expert Epic technologist to discuss how best to integrate the tools into Epic for use by clinicians with patients. The meetings were then recorded and transcribed. Two researchers independently coded the transcripts and field notes before categorizing the codes and conducting a thematic analysis to identify the facilitators and barriers to EHR integration. The steps were reviewed and edited by an Epic technologist to ensure their accuracy. ResultsIntegrating the uterine fibroid Option Grid PDA into clinician-facing menus required an 18-month timeline and a 6-step process, as follows: task priority negotiation with Epic software teams, security risk assessment, technical review, Epic configuration; troubleshooting, and launch. The key facilitators of the process were the clinical champions who advocated for integration at the institutional level and the presence of an experienced technologist who guided Epic software analysts during the build. Another facilitator was the use of an emerging industry standard app platform (Health Level 7 Substitutable Medical Applications and Reusable Technologies on Fast Healthcare Interoperability Resources) as a means of integrating the Option Grid into existing systems. This standard platform enabled clinicians to access the tools by using single sign-on credentials and prevented protected health information from leaving the EHR. Key barriers were the lack of control over the Option Grid product developed by EBSCO (Elton B Stephens Company) Health; the periodic Epic upgrades that can result in a pause on new software configurations; and the unforeseen software problems with Option Grid (ie, inability to print the PDA), which delayed the launch of the PDA. ConclusionsThe integration of PDAs into the Epic EHR system requires a 6-step process and an 18-month timeline. The process required support and prioritization from a clinical champion, guidance from an experienced technologist, and a willing EHR software developer team.

Empirical analysis of CASE tool impact on the development process in North Macedonian IT companies

Service architects and developers are interested to create software tools/applications that would help software analysts in the process of software requirements elicitation and specification, which then will improve the productivity and quality of th

A domain-specific language for verifying software requirement constraints

• Detection of requirement inconsistencies comes with a significant cost. • We propose a DSL based on Set Theory (GIRL) for structural invariants. • GIRL invariants can be evaluated using Alloy, the target language for a translation semantics. • With a prototypical IDE as an Eclipse plugin, requirement analysts evaluated usability and effectiveness. • Participants effectively used the analysis, complex logical constructs. Software requirement analysis can undoubtedly benefit from prevention and early detection of failures, in particular by some kind of automatic analysis. Formal methods offer means to represent and analyze requirements with rigorous tools, avoiding ambiguities, and allowing automatic verification of requirement consistency. However, formalisms often clash in the culture or lack of software analysts' skills, making them challenging to apply. In this article, we propose a Domain-Specific Language (DSL) based on Set Theory for requirement analysts. The Graphical InvaRiant Language (GIRL) can be used to specify software requirement structural invariants, with entities and their relationships. Those invariants can then have their consistency evaluated by the Alloy Analyzer, based on a translational semantics we provide for transforming GIRL models into Alloy specifications with no user intervention. With a prototypical language editor and transformations implemented into an Eclipse plugin, we carried out a qualitative study, with requirement analysts working for a government software company in Brazil, to evaluate usability and effectiveness of the GIRL-based analysis of real software requirements. The participants were able to effectively use the underlying formal analysis since 79 out of 80 assigned invariants were correctly modeled. While participants perceived as low the complexity of learning and using GIRL's simplest, set-based structures and relationships, the most complex logical structures, such as quantification and implication, were challenging. Furthermore, almost all post-study evaluations from the participants were positive, especially as a tool for discovering requirement inconsistencies.

O perfil do egresso de Análise e Desenvolvimento de Sistemas do IFPB – Campus Monteiro

The growing demand for Information Technology (IT) experts requires the training of highly qualified professionals. Thus, the present study aimed to trace the professional and socioeconomic profiles of the alumni of the Analysis and Systems Development course, of Federal Institute of Paraíba (IFPB)- Monteiro, in order to verify the actual situation after they have graduated. It also aims to check whether their profile matches the predetermined description established in the Pedagogical Project of the Course (PPC) and the National Catalog for Technological Higher Education Courses. Based on the results obtained through a survey analysis, we highlight the following findings: the family income of the graduate has increased after the conclusion of the course; the majority of graduates chose to work instead of (only) studying; the graduates are working as software analysts, developers or engineers; despite of the fact that some students were not working in IT, most of them remain in the area; the average of alumni monthly incomes is approximately R$ 2,862.00; and no graduate is unemployed

PY-RATE ADVENTURES: A 2D Platform Serious Game for Learning the Basic Concepts of Programming With Python

Background. Learning programming is a cognitively demanding field of study accompanied with various difficulties. Although there is a high demand in the market for programmers, software analysts and engineers, a high dropout rate is recorded in relevant fields of study. Serious games are a promising means of engaging students in learning programming by giving them more incentives and making the process of learning programming concepts and languages more entertaining. Aim. This article introduces a new serious game called PY-RATE ADVENTURES, which aims to assist young students in their introduction to the basic programming concepts using Python. The game does not have any prerequisites and is suitable for players with no previous knowledge of programming. This article aims to present important information regarding the analysis, design and pilot evaluation of PY-RATE ADVENTURES. Method. The game was evaluated by 31 people that had recently graduated or were students of an Interdepartmental Programme of Postgraduate Studies in Information Systems. The participants voluntarily played the game and answered a questionnaire based on the MEEGA+ model, after their hands on experience with the game. This questionnaire’s purpose was to evaluate PY-RATE ADVENTURES in terms of perceived player experience and short-term learning. Results. The participants positively evaluated the game almost in all the elements of player experience. Furthermore, the majority of the users consider that the game helped them to learn basic programming concepts in Python and stated that they would prefer to learn programming with this game rather than other teaching methods. Conclusion. The positive results of the pilot evaluation give us the motivation to proceed and evaluate the game with students in secondary education, in order to extract stronger and generalisable conclusions regarding the impact of the game as an educational tool for learning programming concepts.

Data management in clinical research: Synthesizing stakeholder perspectives

ObjectiveThis study assesses data management needs in clinical research from the perspectives of researchers, software analysts and developers. Materials and methodsThis is a mixed-methods study that employs sublanguage analysis in an innovative manner to link the assessments. We performed content analysis using sublanguage theory on transcribed interviews conducted with researchers at four universities. A business analyst independently extracted potential software features from the transcriptions, which were translated into the sublanguage. This common sublanguage was then used to create survey questions for researchers, analysts and developers about the desirability and difficulty of features. Results were synthesized using the common sublanguage to compare stakeholder perceptions with the original content analysis. ResultsIndividual researchers exhibited significant diversity of perspectives that did not correlate by role or site. Researchers had mixed feelings about their technologies, and sought improvements in integration, interoperability and interaction as well as engaging with study participants. Researchers and analysts agreed that data integration has higher desirability and mobile technology has lower desirability but disagreed on the desirability of data validation rules. Developers agreed that data integration and validation are the most difficult to implement. DiscussionResearchers perceive tasks related to study execution, analysis and quality control as highly strategic, in contrast with tactical tasks related to data manipulation. Researchers have only partial technologic support for analysis and quality control, and poor support for study execution. ConclusionSoftware for data integration and validation appears critical to support clinical research, but may be expensive to implement. Features to support study workflow, collaboration and engagement have been underappreciated, but may prove to be easy successes. Software developers should consider the strategic goals of researchers with regard to the overall coordination of research projects and teams, workflow connecting data collection with analysis and processes for improving data quality.

Software change decision support: a proposed framework and case study

Software change is a common and continuous process. It must be controlled in a rigorous way to avoid software quality degradation. Despite the existence of a number of research studies on software change control, software professionals often rely on their experience and intuition to decide whether to accept or reject software change requests. The research reported on here suggests a framework for software change decision support. The first part of the framework is a conceptual model which contains a comprehensive list of software attributes that a software change might affect. The literature has been surveyed in order to construct this conceptual model. The second part of the framework provides a formulation of the software change decision as a fuzzy multiple attribute group decision problem. Software analysts are required to linguistically assess the impact of every change implementation solution on every attribute. Then, the provided solution algorithm for the fuzzy multiple attribute decision problem has to be executed in order to come out with a ranking of the different implementation solutions. An implementation of the framework has been validated through a limited industrial application. This experiment proved that the proposed solution has an interesting potential.

Computer Software-Related Litigation: Discovery and the Overly-Protective Order

Litigation involving allegations of intellectual property infringement concerning computer software is some of the most complex, time consuming, and expensive litigation in which private parties engage. Certain practices in discovery, including, most significantly, the use of poorly drafted discovery agreements that also include “overly protective” orders, increase that expense dramatically. Regardless of whether the allegation is patent infringement, copyright infringement, or trade secret misappropriation, prosecuting and defending the assertions in the case requires a probing analysis of the computer source code. In these types of cases, both parties will engage forensic software analysts to assist the lawyers in preparation for trial and to provide expert witness testimony for the court. The forensic software analysts will dissect the computer source code, often examining the source code of both parties, looking for signs of infringement or misappropriation as well as for technical explanations for similarities in the way the code is written or structured. But first, the computer source code must be disclosed to the opposing party. Such disclosure is almost always done pursuant to a protective order, typically stipulated to by the attorneys. Lawyers often agree to protective orders that significantly and unnecessarily increase the costs of discovery. Attorneys should pay careful attention to the provisions addressing the requirements of production and analysis. Additionally, attorneys must understand the consequences of the clauses contained in protective orders in these types of litigation. As described in this article, it is possible to provide robust protection for disclosed source code while at the same time not unnecessarily and dramatically increasing the cost of discovery by weaponizing the protective order. The goals of this article are three-fold. First, we seek to help lawyers understand the process of forensic software analysis. Second, we provide a set of model clauses aimed at avoiding pitfalls in the design of the discovery process, including model clauses for a protective order of appropriate scope and with appropriate protections from further disclosure of the source code that is produced. Third, for judges who are asked to intervene in discovery battles, including fights over the proper scope of a protective order, this article is meant to assist in evaluating the parties’ arguments.

Enterprise Resource Planning And Its Future Relationship To Decision Support System

<p class="ForMoreInfoHeader" style="text-align: justify; margin: 0in 34.2pt 0pt 0.5in;"><span style="font-style: normal; font-size: 10pt;" lang="EN-GB"><span style="font-family: Times New Roman;">This paper looks at the development of ERP and DSS, with a focus on the differences between the two systems in terms of their evolution and applications and the potential for convergence in the future. For the most part, ERP and DSS have evolved in parallel, and as a result those organizations, which have already implemented ERP, are now having problems integrating DSS and data warehousing into their system. ERP vendors hold the opinion that it is comparatively simple to add on DDS applications, but this tends to be contradicted by the fact that most ERP specialists are not experienced in DSS or in data warehousing. Software analysts from both sides of the industry agree that convergence is inevitable, but differ in their views as to how this should be achieved. It would seem that a greater degree of collaboration, and the transfer of skills between the two sides, is the most practical option, coupled with a case-by-case approach to the requirements of individual customers rather than trying to find blanket solutions. </span></span></p>

Modeling the standard compliant software processes in the university environment

PurposeOne way to improve the quality of business and software processes is to make them compliant with standard. This paper seeks to explore the suitability of the BPMN and the teaching method for process modeling, which uses SEI CMMI‐SW standard as input and produces software process models as output.Design/methodology/approachThe research approach consists of two parts. First, the students' responses during practical lectures of process modeling were gathered and studied. Then, the teaching process was modified and students' responses were studied again. The second part involves the survey about students' attitude towards BPMN usability and ease of use.FindingsThere are two key findings of the study. First, using the SEI CMMI‐SW standard in early phases of software process modeling is not very effective, because it overloads the students with abstract requirements, which are included in the standard. The more effective way is to use the standard in later phases of process modeling, in the phase of assessment and improvement of the process model. The second key finding is that there is a positive attitude among students towards BPMN usage for process modeling.Research limitations/implicationsThere is no evidence that this teaching approach can be generalized beyond the population of information science students and academic environment.Practical implicationsThe improved teaching method for business and software process modeling can be used in similar environments (practical lectures of process modeling). Although there is no evidence, quality managers from organizations can also benefit from the lesson learned and avoid a less suitable process‐modeling approach.Originality/valueThe paper is useful to all roles in education and businesses, who deal with process models and standards (teachers, business and software analysts, quality managers, process designers).

UML Fever: Diagnosis and Recovery

The Institute of Infectious Diseases has recently published research confirming that the many and varied strains of UML Fever1 continue to spread worldwide, indiscriminately infecting software analysts, engineers, and managers alike. One of the fever’s most serious side effects has been observed to be a significant increase in both the cost and duration of developing software products. This increase is largely attributable to a decrease in productivity resulting from fever-stricken individuals investing time and effort in activities that are of little or no value to producing deliverable products. For example, afflictees of Open Loop Fever continue to create UML (Unified Modeling Language) diagrams for unknown stakeholders. Victims of Comfort Zone Fever remain glued in the modeling space, postponing the development of software. And those suffering from Gnat’s Eyebrow Fever continue creating models that glorify each and every Boolean value of prospective software implementations.

21 CFR Part 11: How Does it Affect Laboratory Automation Software Developers?

Just what is “21 CFR Part 11”? Do I need to consider it when designing lab automation software? Sure, I store data electronically, but my “official” copy is a signed hardcopy stored in my documentation control system, so Part 11 doesn't apply to me, right? These and similar questions are being asked with increasing frequency during the development process for both off-the-shelf and custom lab automation software. This article presents a brief overview of the FDA regulation concerning the use of electronic records and electronic signatures and a guide for software analysts and developers.

21 CFR Part 11: How Does it Affect Laboratory Automation Software Developers?

Just what is “21 CFR Part 11”?Do I need to consider it when designing lab automation software? Sure, I store data electronically, but my “official” copy is a signed hardcopy stored in my documentation control system, so Part 11 doesn't apply to me, right?These and similar questions are being asked with increasing frequency during the development process for both off-the-shelf and custom lab automation software. This article presents a brief overview of the FDA regulation concerning the use of electronic records and electronic signatures and a guide for software analysts and developers.

Cultural Context and its Impact on Requirements Elicitation in Thailand

AbstractThis paper reports one part of an ethnographic study of how software analysts in Thai software houses undertake the requirements engineering process. In this paper the impact of Thai culture on the elicitation of requirements in information systems developed will be reported. The important role of requirements for software and systems development can be traced to the early study of software engineering. Software developers realised that errors during the requirements phase caused high cost in fixing systems and often led to rejection of systems (Laudon and Laudon 1995). This paper compares the nature of elicitation of requirements by systems analysts in Thailand with standard descriptions of elicitation in requirements engineering research. Detailed descriptions of elicitation processes and an evaluation of text are used to suggest that elicitation in Thailand is affected by different use of analytical and elicitation tools, different adaptation of those tools to the elicitation process, an inability to gain full access to all users where requirements can be identified, increased time needed to uncover requirements and an inability to develop requirements specification. This has important implications for Software Houses using western consultants or organisations employing consultants not familiar with Thai Culture. Understanding the nature of the impact of Thai culture on Requirements engineering processes should ensure that project failure due to poor understanding of requirements for systems would be lessened.

Distributed computing environments: Effects on software maintenance difficulty

The computing world is undergoing a significant transformation from centralized computer architectures to non-centralized or distributed computer architectures. Historically, the largest single life cycle computer system cost has been for maintaining information system software. This paper examines a new area of research in software maintenance (and development in general), focusing on the issue of whether and to what extent distributed computer operating environments directly affect software maintenance. The issue depends on two diametrics of information system architectures: component simplicity and system complexity. The smaller (but more numerous) the system components, the easier they are to deal with individually (i.e., lower software maintenance costs) but the more difficult it is to deal with the overall system (i.e., higher software maintenance costs). This paper proposes a new conceptual model for information systems complexity based on component number and variety, interaction number and variety, and the overall rate of change. By applying this complexity model to distributed computing environments, this research sought empirical quantitative and qualitative data from IS system and application software analysts, designers, programmers, testers, and customer service representatives to determine whether the complexity of a distributed computer system has a greater effect on software maintenance than component simplicity and what the related explanatory factors are. Results indicate that the overall complexity of the studied distributed systems overwhelmed the ease-of-use and simplicity of their components — thus increasing the overall difficulty of software maintenance. Some distributed computing factors had a much greater effect than others. Finally, this paper offers some management guidance on lowering the cost of distributed computing environment software maintenance costs by adjusting the level of system distribution and by minimizing component and system difficulties.

SYSTEMS ENGINEERING METHODS COMPARED

AbstractConsiderable confusion exists concerning the various methods used in the Function‐Requirement‐Architecture‐Test (F‐R‐A‐T) activities of systems engineering. Functional Flow Block Diagrams, Requirements Allocation Sheets, State Diagrams, N2 Charts, Schematic Block Diagrams, Behavior Diagrams, and others are common. IDEF adds Data Flow Diagrams, Context Diagrams, and Relationship Diagrams. Software analysts have recently created Object Oriented Analysis. From Japan, we get Quality Functional Deployment.These various methods can be compared and contrasted by first using systems engineering to functionally analyze engineering, then looking at the function each method performs. The methods can then be compared and analyzed for the strengths, weaknesses, and application of each.An important conclusion is that the new approaches focus on significantly small subsets of the overall systems engineering analysis tasks. Consequently, serious shortfalls in overall understanding of the system may result if they are the only form of analysis used.

Teaching oral communication in computer science

Software analysts currently spend a large portion of their time communicating with others. Effective communication skills is of extreme importance if one wishes to be an efficient and productive software analyst. This article describes some of the exercises related to oral communications that are imposed on our students. Advantages and difficulties are discussed.