Software Reengineering Process Research Articles

Compilador e intérprete en línea de diagramas de flujo con fines didácticos

This work deals with the development, fine-tuning and testing of an online flowchart compiler and interpreter. The development methodology takes as a frame of reference the software reengineering process model, in conjunction with the Object-Oriented Hypermedia Design Method (OOHDM). The software product obtained is a web application for educational purposes that differs from other tools mainly in three aspects: supporting the Polya problem-solving heuristics, create flowcharts following the recommendations for graphic symbology of the American National Standards Institute (ANSI), and be freely available on the internet. The online compiler and interpreter fine-tuning ran on two web browsers that support modal dialog boxes, one for personal computers and one for mobile devices. In addition, compliance tests with the W3C standards, loading speed tests, and a user experience perception test were applied to 22 students of a preparatory course on algorithms. The results obtained in all the tests carried out are considered satisfactory and in accordance with the current context of the students.

Scrumbanfall: An Agile Integration of Scrum and Kanban with Waterfall in Software Engineering

Software industries have been growing with the rise of automation technologies and looking for change in their software development practices to gain the benefits of automation technologies for achieving their business goals. Agile Business Process Reengineering (ABPR) is trending approach for Software Engineering Management (SEM) in software industries, which helps software development organization in transformation of software development practices. Scrum and Kanban are fascinating Agile methodologies adopted by Software Engineering Management practitioners. Scrumban, a mixture of both Scrum and Kanban, has derived strengths of both frameworks, in formation of a robust framework against challenges of Agile Software Engineering (ASE) methodologies like work flow control, lead time management, product delivery that could not be solved by Scrum or Kanban as a standalone framework. But still some of challenges, which are out of scope of Scrumban like project requirement documentation, planning, scheduling, estimation and clear product vision at initial stage of the project. Such issues have raised a request of research for Software Process Reengineering (SPR) in Scrumban by customizing its structure for to form the next level of hybrid framework. The Traditional SDLC methodology ‘Waterfall’ has answers for such issues. An empirical analysis, for resolution of such issues, with the help of ‘Waterfall’ model and its life cycle protocols is the main goal this research study by integrating Scrum and Kanban with Waterfall to form a hybrid framework ‘Scrumbanfall’ aligning Kanban in center of integration under the boundary of Scrum rules. This research also highlights limitations of Scrumbanfall like team members and their roles and capabilities for the large scaled project having team members in distributed environment, which open the door for next level of research to overcome such challenges using further hybridization of Scrumbanfall.

Machine Learning: A Software Process Reengineering in Software Development Organization

BPR (Business Process Re-engineering) is an organizational mechanism that improves the organizational ability in responding to the challenges of qualitative result by change management and improvement in software engineering processes, productivity, product quality and competitive advantage. BPR inherits, explores and implements the building of process change, to incorporate enhancements to the essential considerations and protocols of (SEM) Software Engineering Management. Machine Learning (ML) can be the key aspect for BPR in software development organization. The goal of this research study is raising the conceptual vision about integration of automation technology like ML and its life cycle development within Software Development Life Cycle (SDLC) of the software product and highlights benefits and drawbacks ML techniques in SPM (Software Project Management), and how to implement ML in standard SEM practices. We have attempted the introduction of machine learning in SEM to determine specific performance and tasks reuse using empirical analysis and discussion on implementation of ML algorithms. The empirical study of software technologies includes control structure of an autonomous software application. In current era, ML imparts consistently promising accuracy in some SEM fields. The goal of this paper is an empirical and analytical study and literature review to propose desired level of quality software, through the comparative evaluation of existing processes and their respective support for Software Quality Engineering (SQE).

Reengineering framework for open source software using decision tree approach

A Software engineering is an approach to software development. Once software gets developed and delivered, it needs maintenance. Changes in software incur due to new requirements of the end-user, identification of bug in software or failure to achieve system objective. It has been observed that successive maintenance in the developed software reduces software quality and degrades the performance of software system. Reengineering is an approach of retaining the software quality and improving maintainability of the software system. But the question arises “when to reengineer the software”. The paper proposed a framework for software reengineering process using decision tree approach which helps decision makers to decide whether to maintain or reengineer the software systems.

An empirical approach for software reengineering process with relation to quality assurance mechanism

Software development advances focus on productivity of existing software systems and quality is the basic demand of every engineering product. In this paper, we will discuss the complete re-engineering process with aspects of forwarding, reverse and quality assurance mechanism. As we know the software development lifecycle (SDLC) follows a complete mechanism of the engineering process. In forward engineering, we tried to follow selective main phases of software engineering(data,requirements, design, development, implementation).In reverse engineering, we move backward from the last phase of developing the product as it gathers requirements from the implemented product(implementation, coding, design, requirements, data). During reengineering, we add up more quality features on customer demands, but the actual demand is to fulfill quality needs that can be assured by external as well as internal quality attributes such as reliability, efficiency, flexibility, reusability, and robustness in any software system. We discussed a methodological approach to move from re-engineering to the journey of quality assurance. More than 50 studies come into discussion and throughput results proposed by graph and tabular form. We can say if the re-engineering process produces quality attributes, then it can be said by old software system refactoring as code refactoring, data refactoring and architectural refactoring we obtained a quality product at a lower cost instead of new software system development, which causes a decrease in quality attributes as cost, time etc. In future work, testing methodology can be proposed for quality assurance.

On the application of model-driven engineering in data reengineering

Model-Driven Engineering (MDE) emphasizes the systematic use of models to improve software productivity and some aspects of the software quality such as maintainability or interoperability. Model-driven techniques have proven useful not only as regards developing new software applications but also the reengineering of legacy systems. Models and metamodels provide a high-level formalism with which to represent artefacts commonly manipulated in the different stages of a software evolution process (e.g., a software migration) while model transformation allows the automation of the evolution tasks to be performed. Some approaches and experiences of model-driven software reengineering have recently been presented but they have been focused on the code while data reengineering aspects have been overlooked. The objective of this work is to assess to what extent data reengineering processes could also take advantage of MDE techniques.The article starts by characterising data-reengineering in terms of the tasks involved. It then goes on to state that MDE is particularly amenable as regards addressing the tasks previously identified. We present an MDE-based approach for the reengineering of data whose purpose is to improve the quality of the logical schema in a relational data migration scenario. As a proof of concept, the approach is illustrated for two common problems in data re-engineering: undeclared foreign keys and disabled constraints. This approach is organised following the three stages of a software reengineering process: reverse engineering, restructuring and forward engineering. We show how each stage is implemented by means of model transformation chains. A running example is used to illustrate each stage of the process throughout the article. The approach is validated with a real widely-used database. An assessment of the application of MDE in each stage is then presented, and we conclude by identifying the main benefits and drawbacks of using MDE in data reengineering.

Ruling out key enablers for software process reengineering in Indian small and medium enterprises

It has been of utmost significance for the software industry to find a way for the successful implementation of software process improvement (SPI). It assumes greater importance when we talk about small and medium enterprises (SMEs). Majority of the researchers have explored limited resources in terms of cost, time and expertise for the low adoption rate of software process reengineering (SPR) in Indian SMEs. Last decade evidenced evolvement of software SMEs; and the rate of adoption of SPI initiatives realised some appreciation. In order to explore the reasons attributing towards the success or failure of SPI, researchers need to focus on the underlying multi-dimensional issues. Sufficient literature is available regarding SPI initiatives of triumphant organisations, but not much has been said about Indian SMEs. This paper aims to point out the facilitating factors in SPI that can really boost the quality of software processes to provide a competitive edge to the Indian SMEs.

Proposed Software Re-engineering Process That Combine Traditinal Software Reengineering Process With Spiral Model

Software re-engineering, a recent research area includes reverse engineering, forward engineering and reengineering tools while re-engineering modification to get new enhanced until now does not discussed in a serious manner, so in this paper the traditional software reengineering is discussed and the software reengineering process is suggested. The proposed incorporates both the reverse engineering and forward engineering integrated with spiral model where reverse engineering applies to existing system code to extract design & requirements, although this is often used as means to mitigate risks & reduced costs of operation and maintaining the software system. This paper briefly describes traditional re-engineering then discusses the emerging of proposed-reengineering which is often used as means to simplify the complex tasks. The paper represents how quality is going to be effect with the help of given software reengineering process. An analysis of various possible risks, their impact and mapping with various attributes is correspondingly presented. This paper is also presenting the way to reduce the impact of most of these risks by using proposed re-engineering through get all the useful features of spiral model. Keywords: Software Engineering, Software Re-engineering Process, Proposed Re-engineering Process, Reverses Engineering; Forward Engineering, Risk Assessment, Software Metrics.

Techrisk - A Decisional Framework to Measure Technical Dimensions of Legacy Application for Rejuvenation Through Reengineering

Competitive business environment wants to modernize existing legacy system in to self-adaptive ones. A variety of options are available to renovate legacy system in to more contemporary system. Recently the phenomenon of “software reengineering “, a methodology to allow old ways of thinking to be replaced with new, fresh approaches to increase productivity and quality of system, has been reported. However evolving legacy system through reengineering is a risky and error –prone task due to extensive changes it requires in the majority of cases. Therefore cost effective reengineering requires identifying and measuring impact of system, managerial and technical risk. We present a technical domain framework TechRisk to identify and measure quality and functional dimensions of legacy system. The objective is to identify those risk factors of technical domain which are critical to the success of reengineering. Proposed decision driven framework TechRisk provide support to identify and eliminate the highest impact risks in the software reengineering process and help to create a successful reengineering solution.

Essence of Software Process Reengineering in SME's: Towards Process Customization and Automation

Software Process Reengineering is the core kernel of software process improvement (SPI). Today, the very promising small scale software enterprises (SME's) are striving for standardization of their software development processes. They are carrying out improvement processes but not a proper set of processes. Lack of experienced process engineers and activities which lead them to have a good CMM level is a big issue to be resolved. There are no underlying problems for large scale software industries due to enough resources like available budget, trained as well as experienced and dedicated software professional's team for software process improvement programs, required set of efficient tools and technology for actual implementation. And top of the all required infrastructure, proper understanding and mindset for applying software reengineering initiative. Unfortunately, there is limited adoption, absorption, adaptation and assimilation of software process improvement models in SME's due to lack of know-how and available resources in terms of money, time, perceived benefits, quality focus. Unavailability of required automated tool sets, in-house software process assessment. In nutshell, there is limited adoption, absorption, adaptation and assimilation of software process improvement models in SME's due to lack of know-how and available resources in terms of money, time and perceived benefits. This paper explores as SPI has evolving nature, there is a need of Cost-effective framework which provide customization of tools and techniques w.r.t prevalent technologies encompassing agility, object orientation, component based modeling and reuse, architecture centric approaches, configuration and risk management, heterogeneous project types and sizes.

Software process re‐engineering: a model and its application to an industrial case study

AbstractMany software organizations engage in software process improvement (SPI), but process descriptions may soon become outdated especially if the organization, for a while, has given low priority to SPI. As a result, software organizations may need to re‐engineer process descriptions that are inconsistent with desired process practices. While the literature addresses how organizations can re‐engineer business processes and legacy systems, no guidance exists on re‐engineering legacy process descriptions. Software process re‐engineering (SPR) is a transitional activity that helps organizations effectively re‐engage in SPI by assessing legacy process descriptions; selecting process descriptions that need to be removed, innovated, or implemented; and defining a plan to align process descriptions with desired process practices. SPR results in a repository of managed process descriptions and a plan for disciplined software process management. In this article, we derive principles for SPR, use these principles to propose a model for re‐engineering legacy process descriptions, and present an industrial case study to demonstrate the effectiveness of the model. In the presented case, SPR had several benefits: it leveraged earlier investments in SPI; it engaged key stakeholders in revitalizing improvement efforts; it created a shared understanding of the organization's desired process practices; and, it established a solid platform for continued SPI. Copyright © 2008 John Wiley & Sons, Ltd.

레거시 시스템 진화를 위한 효율적 재공학 프로세스

1980년대 이후, 소프트웨어 위기에 대응하기 위한 다양한 소프트웨어 공학적 기법들이 출현하기 시작 하였고, 현재 소프트웨어의 질적 항상 및 생산성 향상을 꾀하기 위한 개발 지침으로 소프트웨어 개발 프로세스를 적용하는데 관심이 집중되어지고 있다. 그러나 대부분의 방법론들이 앞으로 구축한 새로운 시스템의 재사용성 확보에 치중할 뿐, 기존의 레거시 시스템 자원을 재사용하여 새로운 시스템을 구축하는 재공학 방법은 지원하지 못하고 있는 실정이다. 본 논문에서는 레거시 시스템의 효율적 진화를 위한 재공학 프로세스(Reengineering Process)로 RUP를 확장, 커스터마이징하여 구성한 RUP+re을 제시한다. RUP+re는 Small-h 모델을 바탕으로 크게 역공학 워크플로우(Reverse Engineering Workflow), 변환 워크플로우(Transformation Workflow), 진화 워크플로우(Evolution Workflow)로 구성되어진다. RUP+re의 각 워크플로우와 세부스텝을 제공하고 재공학 사례 연구론 통하여 실질적으로 프로세스를 검증함으로서 레거시 시스템 자원의 진화론 위한 소프트웨어 재공학 프로세스 구축에 효율적인 지침을 제공한다. The various software engineering techniques have been come out in order to cope with the software crisis since 1980's. These days the software Engineering has focused on the process of software development which is the guide for a qualify and productive improvement of software. But, most of the methodologies assume that a new system will be constructed and reused in the future. these do not support how we reuse legacy system's resources and construct a new system efficiently. In this paper, we present an efficient Reengineering Process for legacy system evolutions, RUP+re, which extends and customizes RUP. RUP+re consists of Reverse Engineering Workflow, Transformation Workflow and Evolution Workflow based on Small-h model. We describe RUP+re's workflows with their own detail steps and verify the process through the case study practivally. So, we provide efficient guidelines to the software Reengineering process construction which evolutes the resources of a legacy system.

Cognitive processes in program comprehension: An empirical analysis in the Context of software reengineering

Changes in an organization's internal and external environment impose numerous demands on management information systems (MIS). Since few MIS can be designed to fully anticipate all change, system portfolios frequently tend to become heavily weighted with older systems needing maintenance and revision. To maintain cost effectiveness, encourage system reuse, and ensure that the new system's behavior will differ from that of the old one only as intended, the former's functional design must be recovered (preferably from the old program code itself) when undertaking such maintenance and revision. We studied of how experts perform this design recovery activity by analyzing the cognitive processes of six experienced system developers engaged in the program comprehension phase of software reengineering. Results of protocol analysis indicate that subjects distributed their cognitive processes in a systematic and generally comparable fashion. Over the sample, similar transitions between two activities and patterns of three activities were observed to occur with high frequency. The most frequently occurring program comprehension transitions and patterns generally occurred within, rather than across, two activity groups: recognition and design documentation. We conclude with suggestions for further research on program comprehension and the design of computerized tools to support the software reengineering process.

Software process reengineering: Toward a new generation of CASE technology

Business process reengineering is generating considerable interest in the business community because of its demonstrated capacity to reduce costs and increase an organization's responsiveness to competitive challenges and opportunities. The software crisis, as evidence by escalating costs and sluggish responsiveness to changing requirements, is similar to the business problems now being addressed through the application of business process reengineering principles. This article applies three of these same principles to the software crisis: (1) the surfacing of tacit assumptions and an examination of them for error, obsolescence, or irrelevance; (2) a radical redefinition of processes; and (3) the use of technology as a process enabler. After applying these principles to the problems of software development, maintenance, and reengineering, we derived a radical redefinition of the software process. The capabilities of three integrated multitool CASE environments are proposed as an enabling technological infrastructure for the reengineered software process. These are the software specification, software engineering, and software reengineering environments. The reengineered software process and integrated environments are shown to leverage human resources from three sources: legacy software, domain architectures, and reuse libraries.

REVERSE ENGINEERING, REENGINEERING, AND CONCURRENT ENGINEERING OF SOFTWARE

This survey reviews four classes of reengineering of software systems: code restructuring and translation of code into a new language, design recovery for corrective maintenance, design recovery for software enhancement, and software reengineering as part of radical business process reengineering. Special attention is given to the reengineering of data bases and user interfaces. We also consider concurrent software engineering, its place in the software reengineering process, and groupware in support of this process.

Notes on concurrent engineering

A basic set of principles from concurrent engineering is synthesized. These principles, when coupled with COSMOS, a management model, can be a very powerful tool in helping to reengineer the software development process. The combined model is applied to the system requirement phase, and a framework for software process reengineering is suggested.< <ETX xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">&gt;</ETX>