An Exhaustive Requirement Analysis Approach to Estimate Risk Using Requirement Defect and Execution Flow Dependency for Software Development

2018 ◽  
Vol 11 (2) ◽  
pp. 68-87 ◽  
Author(s):  
Priyanka Chandani ◽  
Chetna Gupta
Keyword(s):  
Software Development ◽  
Development Process ◽  
Requirement Analysis ◽  
Software Development Process ◽  
Whole Process ◽  
Clear Vision ◽  
Flow Dependency ◽  
Software Engineers ◽  
Business Requirements

Requirement defects are one of the major sources of failure in any software development process as they prevent smooth operation and is taxing both in terms of tracking and validation. The objective of this article is to make requirement analysis phase exhaustive by estimating risk at requirement level using requirement defect information and execution flow dependency as early as possible to inhibit them from being incorporated in design and implementation. The proposed approach works as a two-fold process which computes risk involved with each requirement twice. The whole process is divided into a three-layered framework to finalize requirements with clear vision and scope of a project. The entire process has been supported by a software case study. The results of the proposed work are promising and will help software engineers in ensuring that all business requirements are captured correctly with clear vision and scope. It will also help in decreasing the chances of failure, risk, and conflicts between stakeholder and developer and other challenges involved to develop the project.

An Exhaustive Requirement Analysis Approach to Estimate Risk Using Requirement Defect and Execution Flow Dependency for Software Development

2021 ◽  
pp. 1405-1425
Author(s):  
Priyanka Chandani ◽  
Chetna Gupta
Keyword(s):  
Software Development ◽  
Requirement Analysis ◽  
Design And Implementation ◽  
Whole Process ◽  
Failure Risk ◽  
Clear Vision ◽  
Flow Dependency ◽  
Software Engineers ◽  
Business Requirements

Requirement defects are one of the major sources of failure in any software development process as they prevent smooth operation and is taxing both in terms of tracking and validation. The objective of this article is to make requirement analysis phase exhaustive by estimating risk at requirement level using requirement defect information and execution flow dependency as early as possible to inhibit them from being incorporated in design and implementation. The proposed approach works as a two-fold process which computes risk involved with each requirement twice. The whole process is divided into a three-layered framework to finalize requirements with clear vision and scope of a project. The entire process has been supported by a software case study. The results of the proposed work are promising and will help software engineers in ensuring that all business requirements are captured correctly with clear vision and scope. It will also help in decreasing the chances of failure, risk, and conflicts between stakeholder and developer and other challenges involved to develop the project.

SERIES

2022 ◽  
pp. 1139-1153
Author(s):  
Chetna Gupta ◽  
Priyanka Chandani
Keyword(s):  
Early Identification ◽  
Requirement Analysis ◽  
Domain Modeling ◽  
Design And Implementation ◽  
Preventive Actions ◽  
Clear Vision ◽  
Software Engineers ◽  
Risk Estimator ◽  
Business Requirements

Requirement defects are one of the major sources of failure in any software development process, and the main objective of this chapter is to make requirement analysis phase exhaustive by estimating risk at requirement level by analyzing requirement defect and requirement inter-relationships as early as possible to using domain modeling to inhibit them from being incorporated in design and implementation. To achieve this objective, this chapter proposes a tool to assist software developers in assessing risk at requirement level. The proposed tool, software risk estimator, SERIES in short, helps in early identification of potential risk where preventive actions can be undertaken to mitigate risk and corrective actions to avoid project failure in collaborative manner. The entire process has been supported by a software case study. The results of the proposed work are promising and will help software engineers in ensuring that all business requirements are captured correctly with clear vision and scope.

SERIES

2021 ◽  
pp. 238-252
Author(s):  
Chetna Gupta ◽  
Priyanka Chandani
Keyword(s):  
Early Identification ◽  
Requirement Analysis ◽  
Domain Modeling ◽  
Design And Implementation ◽  
Preventive Actions ◽  
Clear Vision ◽  
Software Engineers ◽  
Risk Estimator ◽  
Business Requirements

Requirement defects are one of the major sources of failure in any software development process, and the main objective of this chapter is to make requirement analysis phase exhaustive by estimating risk at requirement level by analyzing requirement defect and requirement inter-relationships as early as possible to using domain modeling to inhibit them from being incorporated in design and implementation. To achieve this objective, this chapter proposes a tool to assist software developers in assessing risk at requirement level. The proposed tool, software risk estimator, SERIES in short, helps in early identification of potential risk where preventive actions can be undertaken to mitigate risk and corrective actions to avoid project failure in collaborative manner. The entire process has been supported by a software case study. The results of the proposed work are promising and will help software engineers in ensuring that all business requirements are captured correctly with clear vision and scope.

Formal Specifications of Software Model Evolution Using Contracts

2011 ◽  
pp. 184-208
Author(s):  
Claudia Pons ◽  
Gabriel Baum
Keyword(s):  
Software Development ◽  
Development Process ◽  
Formal Specifications ◽  
Software Development Process ◽  
Software Life Cycle ◽  
Software Artifacts ◽  
Software Model ◽  
Intelligent Analysis ◽  
Software Engineers

During the object-oriented software development process, a variety of models of the system is built. All these models are semantically overlapping and together represent the system as a whole. In this chapter, we present a classification of relationships between models along three different dimensions, proposing a formal description of them in terms of mathematical contracts, where the software development process is seen as involving a number of agents (the development team and the software artifacts) carrying out actions with the goal of building a software system that meets the user requirements. In this way, contracts can be used to reason about correctness of the development process, and to compare the capabilities of various groupings of agents in order to accomplish a particular contract. The goal of the proposed formalization is to provide formal foundations for tools that perform intelligent analysis on models assisting software engineers through the software life cycle.

Towards Measuring the Change Impact in ATL Model Transformations

2016 ◽  
Vol 26 (02) ◽  
pp. 153-181 ◽  
Author(s):  
Andreza Vieira ◽  
Franklin Ramalho
Keyword(s):  
Software Development ◽  
Static Analysis ◽  
Development Time ◽  
Development Process ◽  
Model Transformations ◽  
Software Development Process ◽  
Model Driven ◽  
Change Impact ◽  
The Impact

The Model-Driven Development (MDD) approach shifts the focus on code to models in the software development process. In MDD, model transformations are elements that play an important role. MDD-based projects evolve along their lifecycle in a way that changes in their transformations are frequent. Before applying changes it is important to measure their impacts within the transformation. However, currently no technique helps practitioners in this direction. We propose an approach to measure the change impact in ATL model transformations. Based on static analysis, it detects the elements impacted by a change and calculates the change impact value through three metrics we defined. By using our approach, practitioners can (i) save effort and development time since the elements impacted with the change are automatically detected and (ii) better schedule and prioritize changes according to the impact value. To empirically evaluate our approach we conducted a case study.

scholarly journals Building a web-based app for persons with physical disabilities: A collaboration between game developers and rehabilitation researchers (Preprint)

2019 ◽  
Author(s):  
Alexandra Terrill ◽  
Justin J. MacKenzie ◽  
Maija Reblin ◽  
Jackie Tyne Einers ◽  
Jesse Ferraro ◽  
...  
Keyword(s):  
Mental Health ◽  
Software Development ◽  
Development Process ◽  
Physical Disabilities ◽  
End Users ◽  
Lessons Learned ◽  
Software Development Process ◽  
Web Based ◽  
Cord Injury

BACKGROUND Individuals with disability and their partners, who often provide care, are both at risk for depression and lower quality of life. Mobile health (mHealth) interventions are promising to address barriers for mental health care. Rehabilitation researchers and software development researchers must collaborate effectively with each other, and with clinical and patient stakeholders to ensure successful mHealth development. OBJECTIVE To aid researchers interested in mHealth software development by describing the collaborative process between a team of rehabilitation researchers, software development researchers, and stakeholders. Thus, we provide a framework (conceptual model) for other teams to replicate in order to build a web-based mHealth app for individuals with physical disability. METHODS Rehabilitation researchers, software development researchers, and stakeholders (people with physical disabilities and clinicians) are involved in an iterative software development process. The overall process to develop an mHealth intervention includes initial development meetings and a co-design method called “designbox”, in which the needs and key elements of the app are discussed. Based on the objectives outlined, a prototype is developed and goes through scoping iterations with feedback from stakeholders and end-users. The prototype is then tested by users to identify technical errors and gather feedback on usability and accessibility. RESULTS Illustrating the overall development process, we present a case study based on our experience developing an app (SupportGroove) for couples coping with spinal cord injury. Examples of how we addressed specific challenges are also included. For example, feedback from stakeholders resulted in development of app features for individuals with limited functional ability. Initial designs lacked accessibility design principles made visible by end-users. Solutions included large text, single-click, and minimal scrolling to facilitate menu navigation for individuals using eye-gaze technology. Prototype testing allowed further refinement and demonstrated high usability and engagement with activities in the app. Qualitative feedback indicated high levels of satisfaction, accessibility, and confidence in potential utility. We also present key lessons learned about working in a collaborative interdisciplinary team. CONCLUSIONS mHealth promises to help overcome barriers to mental health intervention access. However, the development of these interventions can be challenging because of the disparate and often siloed expertise required. By describing the mHealth software development process and illustrating it with a successful case study of rehabilitation researchers, software development researchers, and stakeholders collaborating effectively, our goal is to help other teams avoid challenges we faced and benefit from our lessons learned. Ultimately, good interdisciplinary collaboration will benefit individuals with disabilities and their families. CLINICALTRIAL n/a

Ethics in Software Engineering

2011 ◽  
pp. 266-272 ◽  
Author(s):  
Pankaj Kamthan
Keyword(s):  
Software Engineering ◽  
Software Development ◽  
Public Interest ◽  
Unethical Behavior ◽  
Development Process ◽  
Software Industry ◽  
Software Development Process ◽  
Bottom Line ◽  
Legal Implications ◽  
Software Engineers

There are various reasons for discussing the issue of ethics within a software engineering context. By participating in a software development process, software engineers can influence the final product, namely the software itself, in different ways including those that may be contrary to public interest. In other words, they could engage in an unethical behavior, inadvertently or deliberately. This could lead to personal harm, and potentially result in loss of confidence in software and loss of trust in organizations that own them. This can adversely affect the acceptance of software as a useful product, question the credibility of software engineering as a profession, lead to legal implications, and impact the bottom line of the software industry at-large.

A CRITICAL ANALYSIS AND COMPARISON OF AGILE WITH TRADITIONAL SOFTWARE DEVELOPMENT PROCESS

2017 ◽  
Vol 5 (4) ◽  
pp. 88-93
Author(s):  
Priyanka Kataria ◽  
Shweta Shrivas ◽  
Ishita Shukla ◽  
A. Hemlata
Keyword(s):  
Software Development ◽  
Creative Thinking ◽  
Development Process ◽  
Software Development Process ◽  
Agile Methodology ◽  
Short Period ◽  
Marginal Prices ◽  
Agile Software ◽  
New Software Development

During the past years, new software development approaches were introduced to suit within the new trend of the software development corporations. Most Software Corporation’s today aim to provide valuable software in short period of time with marginal prices and among unstable, ever-changing environments. Agile methodology focuses on the challenges of unpredictability of the real world by relying on individuals and their creative thinking instead of method. In this paper we tend to explore about the current agile methods, strengths and weaknesses of agile strategies and numerous problems with their relevancy. We have conjointly enclosed comparison between traditional software development process and agile software development process. This paper also includes brief discussion about the benefits and problems associated with these methodologies by performing case study of two corporations.

Sign in / Sign up

Export Citation Format

Share Document