3-degree freedom network model to support release

International Journal of Electrical Electronics & Computer Science Engineering

Volume 4, Issue 5 (October, 2017) | E-ISSN : 2348-2273 | P-ISSN : 2454-1222

Available Online at www.ijeecse.com

27

3-Degree Freedom Network Model to Support Release Management Using

Efficient Requirements Engineering

Indranil Nath Chartered Fellow, BCS, The Chartered Institute for IT, London, United Kingdom

[email protected]

Abstract: This paper will discuss the multi degree-of-freedom

Software Engineering model, underlying formalisms of

software life - cycle and software metrics that will form the

basis of the Software Re-Engineering approach, underlying

formalisms of Release Management using efficient

Requirement Engineering, tying it all together, An

application of software re-engineering approach, research

results, followed by conclusions.

Keywords: Release Planning, Software Economics, Software

Requirements Management, Software Engineering, Software

Development Process, Requirements Specification Lifecycle

Model.

I. INTRODUCTION

Developing software product line [1] face complex

challenges when determining requirements for

upcoming releases. Often the wish list of requirements

extends the capacity of available resources,

requirements may not be unambiguous, they may be

difficult to prioritize, etc. As a matter of fact, many

aspects influence the definition of an optimal set of

requirements for a next release. Several scholars have

presented lists of such aspects including: importance or

business value, personal preference of certain customers

and other stakeholders, penalty if not developed, cost of

development in man days, development lead-time,

requirement volatility, requirement dependencies,

ability to reuse, and requirements quality.

II. RELEASE RE ENGINEERING USING

REQUIRMENTS ANALYSIS

For software vendors, the process to determine the

requirements for the next release of a software product

is often difficult. In this paper the mathematical

formalization of release composition with a

corresponding optimization tool that aims to support

product managers and development project managers

during release planning is discussed. The tool is based

on integer linear programming and assumes that an

optimal set of requirements is the set with maximum

projected revenue against available resources in a given

time period. The input for the optimization is twofold.

Input data like the list of candidate requirements,

estimated revenue and required team resources per

requirement, whether or not a requirement is mandatory,

comprise the first type of input. Secondly, several

managerial steering mechanisms provide flexibility in

the optimization environment: SE-CUBE (SE3) View of

Requirements, team composition, permitting of team

transfers, extension of deadlines, and hiring external

resources. Through experiments based on real-life data

make a sound case for the applicability of this

methodology.

III. THE SE-CUBE MODEL FOR SOFTWARE

ENGINEERING (SE3)

The development of commercial software is managed

by splitting it up into suitable logical units in order to

divide the various development tasks into logical units

of manageable size, example, the Software Process

[2][3]; The System’s logical views and The Software

Architecture [4]. The importance of all three of these

domains of concern is reflected by the numerous

approaches, models, and specification techniques

currently being available and worked on by research

groups, and by the increasing number of specific tools

offering support to commercial software developers.

Present Software Engineering literature addresses only a

“partial” or one-dimensional model that organizes real

life software development only in a limited way,

because constraints and parameters relating different

domains of concern (dimensions in this case) are not

modelled universally, and hence, can’t be easily

enforced. Examples of such constraints, crossing

domains of concern are, “Which views are necessary to

be specified for a certain component, and which are

not? ” or “When (in which phase) has a certain

component to be specified/introduced (i.e., from scratch,

or later)?” To cope with these requirements in a

universal software engineering models, this paper

concentrates on the integration of the different domains

of concern into one comprehensive, multi-degrees-of-

freedom model. The three domains of concern

introduced in the introduction are considered as

especially important for system development, and used

representatively as fundamental structuring mechanism

for the construction of the multidimensional model.

Consequently, modelling the isolated areas of concern

will not be a purpose of its own anymore, but will

become modelling the dimensions of the multi-degrees-

of-freedom model [5]. As it presently limit to three

“degrees-of-freedom”, the resulting model will be called

SE-CUBE Model of Software Engineering (SE3) in the

rest of the paper. The phases of the process, the

components of the architecture, and the perspectives of

the view dimension are the constituents of the three

degrees-of-freedom, i.e., they are the “building blocks”

for the partial models that capture the three domains of

concern involved. Of course, software engineering

comprises many more domains of concern, but main

mailto:[email protected]




28

purpose of SE-CUBE is to investigate integration issues

of domains of concern in general, and on a formal basis.

Other domains of concern can be important or even

crucial for certain systems and in certain situations, too

(e.g., resource management, configuration management),

but they do not contribute in SE-CUBE to the course of

a project in a structuring way. Where important

information concerning other “degrees-of-freedom” of

software development, such as, commitment of people

to tasks, access rights to documents, and other project

related information will also be included in the SE-

CUBE, in a subordinate level, and will not contribute to

the structure of SE-CUBE models.

Fig. 1. 3-Degree of Freedom Show Software

Engineering Components SE-CUBE

A three-degree-of-freedom network is used to support

SE3. Each node of the network represents a logical

component to be called software engineering component,

which contains information about a (small) portion of

the actual software development. Each software

engineering component is identified by a unique

combination of constituents of each of the dimensions

of the SE3. The combinations of constituents determine,

coordinate of the exact position of the component within

the context of the software development project. Edges,

connecting the nodes of the network, model

relationships and constraints between the components.

Figure 1 illustrates the analogy of the three-degree-of-

freedom network containing related components. The

constituents of the degrees-of-freedom are simplified for

the purpose of clarity. Node X represents the

behavioural view of the interface component in the

analysis phase, while Node Y represents the static

structure of the control component during design.

Between the two nodes, a specific relationship exits,

that models the fact that (the specification of) node X

serves as information source when working on (the

specification of) node Y.

The relationships between the nodes of the network

constrain how (in which order, and under which

circumstances) members of a software development

team can access the software engineering components to

perform the tasks to which they have been committed.

This means that prescribing, identifying, and following

paths through the SE3 network can model the work of

the project team members.

IV. DISCUSSION

A qualitative method was used to conduct a survey

using the two sets of questionnaires - Inspection

Checklist for Software Requirements Specification and

Impact Analysis Checklist for Requirements Changes,

to clearly understand the organizational completeness,

correctness, quality attributes, and traceability of

requirements. The survey also helped pin point the

implication of changes in requirements changes, the

system elements that affected by the proposed changes

and effort estimation for the requirement changes. The

root cause of incidents or defects over the software

lifecycle phase was understood and documented.

Defect/Incident Root Cause Code Listing provided the

details of the root cause of the incident. The phase

where the root causes was found and who the owners

were in the lifecycle were carefully studied and

documented. Few of the major root causes that was

identified are as follows

1. Presented Requirements was incorrect, submitted

subject/items to input/output was incorrect

2. Inaccurate impact analysis

3. Inaccurate define design

4. Inappropriate DB, File, Screen, Components

5. Incorrect Coding

6. Lack of verification

7. Lack of test cases of system interface test

8. Lack of migration test cases

9. Incorrect recovery operations

10. Incorrect release activities

Table I. Defects Due to Requirements Management

Miss in a Year

The complete list of Defect Rate by incident - Root

Cause, Effort, Turn-Around Time and Cost, this data

was collected over a period of 9 months. The raw data




29

collected here is the basis for all analysis and

extrapolation done during the research for this paper.

Table II. Defects Due to Design Specification Miss in a

Year

Similarly defects due to Design Specification miss were

137 for which more that 379 hours were spent (Refer

Table II), defect due to coding & development miss

were 67 with more that 276 person hours spent (Refer

Table III), defect due to testing miss were 38 with 76.8

person hours spent (Refer Table IV), while due

production miss were 111 for which 165.5 person hours

were spent.

Table III. Defects Due to Coding & Development Miss

in a Year

Information like Incident Defect Number, the name of

the incident or defect, dates when the incidents or

defects occurred, the name of the sub-system where it

occurred, the job number, time to processes this incident,

hours take to fix the defects and Cost of fix the defects

is recorded. The root causes were mapped in this data

list to clearly understand the causes of the defects.

Using the data defects due to misses in every phase of

the software development lifecycle was extrapolated. A

total of 102 defects (Refer Table I) were found due to

requirements management miss that consumed 250

hours of defect correct effort (Refer Table I).

Table IV. Defects Due to Testing Miss in a Year

Table V. Defects Identified During Production in a Year

The data defining the defect type and extrapolate the

defect types versus the defect inject phase of each cause

of incidents occurred during the software development

lifecycle were analyzed (Refer Table VI).

It was observed that for the Software Development

Lifecycle Development phases being Requirements,

Design, Coding, Test and Production, the defect types

were restricted to Business Requirements, Change

Management, Design Documentation, Estimation,

Production Failures, Impact Analysis Incorrect Code,

Integration Test Cases, System Interface, JCL,

Operations, Production Data, Release Management,

Systems Test cases, Unit Test Case, Use cases and

Verification/Validation.

A total of 455 defects (Refer Table VII) were found

over the period December 2002 until September 2003

for which 1149.1 hours of effort (Refer Table VII) were

spent in correcting the defect. To summarize, 22.4% of

defect at requirement phase resulted into 21.8% of effort

spent (Refer Table VII), 30.1% of defect during Design

phase resulted into 33.1% of effort (Refer Table VII),

14% of coding defect that consumed 67% of total effort

(Refer Table VII), while 8.4% of defect at test phase

contributed to 8.4% of Effort (Refer Table VII)




30

consumption and not the least 24.4% of defects at

Production phase resulted into 14.4% of effort spent

(Refer Table VII).

Table VI. Defects Identified During Production in a

Year

One can clearly summarize the relationships between

phases and the effort correlation. With 22.4%of defect

being in requirements, it is clear that design defects

would be high (30.1%), which leads into wrong coding

resulting into 14.7% of coding defects.

Table VII. Defects Identified During Production in a

Year

Further making is even worse that little time being spent

on testing, the deliverables were taken into production

phase where 24.4% of the defects were found (Refer

Table VII).

Table VIII. Defects Identified During Production in a

Year

The defect removal efforts & costs by types of defects

were also measured. During the 9 months period the

information technology delivery resources spent, more

than 261 person hours in removing Business

Requirements defects (Refer Table VIII), about 65

person hours for defect due poor Change Management

(Refer Table VIII), more than 1916 person hours of

effort in removing defect caused by poor Design (Refer

Table VIII), about 97 person hours due poor

Documentation that let to defects (Refer Table VIII),

more than 276 person hours spent due poor Estimation

(Refer Table VIII), about 259 person hours due

Production failures, more than 1046 person hours for




31

defects removal due poor impact analysis during the

requirement phase (Refer Table VIII).

All these resulted into poor design which resulted into

spending more than 658 person hours to remove defects

caused due Incorrect Code. More than 372 person hours

were spent to remove defects caused by poor Integration

Test, while more than 279 hours spent due poor design

of system interfaces (Refer Table VIII). It was also

understood that more than 1302 hours were spent

correcting defects caused by lack of good Unit Test

Cases (Refer Table VIII). The company spent roughly

$500,000 (United States Dollars) to fix a total of 455

defects, that worth 7648.6 man-hours (Refer Table VIII).

The Level 3 Capability Maturity define that 20% of the

defect should be detected as one crosses the coding

stage, while 80% of the defects should be detected until

the System Test Phase to achieve a Process Change

Base of Level 3. Where as for Level 5 (highest level of

the CMMI) defines that 85% of the defects should be

detected until the Functional Test Phase (Unit Test

Phase).

A 3-degree-of-freedom network that is introduced

earlier is a model to support requirements management

within the software process along with a mathematical

model of release management, which incorporates

progressive software release with requirements being

added or changed were mapped for the sake of analysis

in this section.

Each node of the 3-D network represented the logical

component, which contains information about a (small)

portion of the actual software development along with

the requirements for the work-products within that

portion are mapped. Each component is identified by a

unique combination of constituents of each of the

dimensions of the 3D model.

To plot the 3D model using the collected data, the

number of defects caused during each of the Software

Development Life Cycle phases (Requirements

Definition, Design, Coding, Test and Production) was

tabled. This was tabled below the Development Process

Column, which is one of the axes to the 3-degree-

freedom network (Refer Table IX). Defect/Incident

Root Cause Code List helped extrapolate the defects

types by Systems components (Repository, Process,

Control, Interface) and the Systems Views

(Functionality, Behaviour and Functionality). Number

of Defect due each of the axes were extrapolated and

tabled (Refer Table IX).

Table IX. 3-Degree of Freedom Network (SE-CUBE)

Table X. Requirements Management Cost (#s: 74

Stakeholders were Interviewed to Extrapolate

Stakeholder Priority)




32

Table XI. Defect/Incident Root Cause Code Listing

A three-dimensional graph representing the Software

Engineering three-degree-of free Network was plotted

for the three axes (Refer Fig 2) to help learn the

software release management strategy using SE-CUBE.

The CD numbers A11, A13, U21, etc. was to reflect the

type of defect that occurred during the phases. Careful

study of the mapping could help optimize the release

management efforts model to support requirement

management which can be integrated with a release-

planning approach to achieve innovative way to capture,

control, and evolve the user requirements or releases in

an evolutionary life-cycle process.

Requirements management considered in this way could

be unique to each organization and could be considered

as a corporate asset. Hence a study on the 3-Degree-of-

Freedom network to understand on what constraints the

developer in the company assessed the software

engineering components to perform the tasks to which

they had committed and show how requirement

development and management could be integrated with

a release-planning approach which could be an

innovative way to capture, control and evolve the user

requirements. This was the underlying formalism of

Release Management concept.

Further, the Requirements Management Cost due each

types of defects were calculated by determining the

Weight of the Requirements Management or

Requirements Dependencies (D) against each type of

defects occurred in the software development lifecycle.

Also the Stakeholder priority (S) was determined by

interviewing 74 stakeholders from different parts of the

company’s’ businesses. The Defect Removal Efficiency

was also calculated. All were tabulated in Table X.

Fig. 2. 3-Degree of Freedom Network (SE-CUBE)

A Pearson Correlation test was done to determine if

there was any kind of relationship between the Effort

Constraints incurred during the software development

cycle and the cost of Requirements Management. The

test proved (refer Fig 3) the two variables Effort

Constraints and Requirements Management Cost during

the software development lifecycle had some degree of

positive correlation as we notice the cluster in Figure 3.

In this case the sample correlation coefficient of 0.98

implies a relatively strong positive relationship between

RMC and Effort Constraints.




33

Finally a test to understand the sensitivity of

Requirements over the Requirements Management Cost

was studied. To do this the Solver option in EXCEL

was used to solve linear and nonlinear optimization

problems with certain constraints placed on the decision

variables. Up to 17 decision variables, 6 explicit

constraints in terms of Stakeholder priority (where 74

stakeholders were interviewed to extrapolate

stakeholder priority) were used to solve the problem

with an objective to maximize the Defect Removal

Efficiency (DRE) while minimizing the Requirements

Management Cost (RMC) and minimizing the number

of defects (n). Refer to Table X and Table XI for three

Linear Models.

Fig. 3. Pearson Correlation: Effort Constraints vs. RM

Cost

The LPP performed as a part of this paper provided a

more convincing argument to support this paper. The

LPP formulated under the following objective functions

and constraint conditions:

Maximizing Defect Removal Efficiency

Minimizing Requirement Management Cost

Minimize Defects

The Objective functions were designed to support the

Release Management, a derived metrics as a

measurement to support efficient requirements analysis

and release management [6], for efficient requirement

analysis as described. For a software release, the

stakeholder prioritization S is formulated as:

Set of stakeholder: 𝑆 = {𝑠1 , 𝑠2 , …… , 𝑠𝑚 }

Weight of each stakeholder 𝑠𝑘 ∈ 𝑆: 𝑤(𝑠𝑘)

Each stakeholder S assigns a priority to the situation that

ri is assigned to the option 𝑘 ∶ 𝑃(𝑠, 𝑟 𝑖 , 𝑘)

Thus, in the evolutionary life cycle, a software release is

defined as:

Release ℛ = 𝑓(ℛ, 𝐶, 𝐷, Ω, 𝑆)

Where

ℛ = Set of requirements

C = Assigned ℛ into an evolutionary life cycle release

categories

D = Requirement Dependencies and requirement

precedence within the domain ℛ

Ω = Effort constraints, and

S = Stakeholders Prioritization

Which is considered as a weightage that is given by the

stakeholder on the requirements to be dealt with, at the

time of progressive software releases.

The total numbers of stakeholders were 74 and the

number of stakeholder that voted for certain

Requirements in a certain Release was considered as

constraints, and answer report, sensitivity report and

limit report were generated.

Table XIII. Linear Models for Maximizing DRE,

Minimizing RMC and Minimizing Defect

The interpretation of the data and the interpretation of

the findings are described in Section V.




34

V. SIGNIFICANT FINDINGS

This research has focused on investing how modelling

areas of concern of software engineering, from the point

of Requirement Analysis, from a conceptual approach

that could enhance software development and assist in

re-engineering them into a comprehensive software

engineering framework which can be adapted and used

for wide range of software development projects.

The research studied the representation; capture learning,

re-use and re-engineering of domain specific software

design and requirements analysis knowledge including

the task environment in form of Requirements, Schedule,

Resources, Skills, Technology and finally Release Plans

that of a given software engineering problem in order to

help engineers and developers to formulate the goals

and constraints. The research has exhibited the multi-

degree-freedom Software Engineering Model (Software

Engineering CUBE), underlying formalisms of software

life cycle and software metric as a derived metric to

allow efficient Requirements Analysis and bi-

directional requirements traceability for Release Re-

engineering.

On careful examination it can understand the results of

the LPP solver and interpret these results to show how it

confirms to this projected research output. As stated

earlier the objective here was always to maximize the

Defect Removal Efficiency (DRE) while minimizing the

Requirements Management Cost (RMC) and

minimizing the number of defects (n). Referring to

Table XII (DRE formulation) where an equal weight is

distributed to each stakeholder (that is all linear

constraint coefficients defined as 1) it can interpret the

results in as “Change Management’ having the most

significant effect is Defect Removal Efficiency.

This simply means that when normalizing the effect of

all other factors, that is normalizing the value of all

other Decision Variables and the data presented, one

can safely say that there is a direct and significant

correlation in Change Management to Defect

proliferation in each Software Release, which leads to

believe that Requirement Management can be

significantly improved if matured Change Management

procedures are strictly followed while Release

Management continues to have exactly same

Stakeholder priorities. As are minimizing the Defects,

while Minimizing the Requirement Management Costs,

showed the final values of these as 0.

It also showed the sensitivity and other criteria for the

LPP solver results and from these we can safely

interpret Change Management is the most significant

process area while implementing efficient Requirement

Analysis. The data presented is of a software

development instant for a large financial protection

company but that it is representative enough to model

real life Requirement Analysis and make generalized

interpretations. Also “Weight on RM (D)” is a

generalized weight-age. This could change on different

software project types and software project domains. An

interesting line of further investigation would be to

change these RM significance weights (D) and re-run

the solver.

Also it would be interesting to change the weight on

each stakeholder priority adding another dimension to

the problemwhere executive decision-making power of

each stakeholder could be also reflected within the

problem formulation.

VI. CONCLUSIONS

This research introduced the 3-Degree-Freedom

network model to support Requirements Management

with in the software process and the mathematical

model of Release Management. Although each node of

the Three-Degree network as logical components as

work-products were mapped there is a room for further

research and analysis of static and dynamic structure of

the Software Engineering 3-Degree-Of-Freedom and

study the pattern evolution out of it.

As mentioned further study of Requirements

Management significance while change the Weight on

Requirements Management by each stakeholder priority

could be another area of further research and pattern

investigation. This could also include further study of

coefficient relation to defects

VII. REFERENCES

[1] Klaus Pohl, “Requirements Engineering-

Fundamental, Priciples, Techniques”, Part VIII-37

Reuirements Engineering for Software Product Line.

[2] Roger S. Pressman, “Software Enginnering-A

Practioner’s Approach”, Software Enginnering

Series, Chapter 2, The Process.

[3] Pankaj Jalote, “CMM in Practice – Processes for

Executing Softwre Projects at Infosys”, chapter 5-

Process Database and Process Capability Baseline.

[4] Mark Richards, “Software Architecture Patterns-

Understanding Common Architecture Patterns and

When to Use them”. O’Reilly Books.

[5] I. Nath, S Kundu, “Is Software Requirements a

Corporate Asset?” Fig.2. Degrees of Freedom in the

Software Engineering Components of SE-CUBE,

IEEE International Engineering Maangement

Conference Proceedigs, Innovation and

Entrepreneurship for Sustainable Development,

Volune 1, 2004.

[6] I. Nath, “A Derived Metrics as a Measurement to

Support Efficient Requirements Analysis and

Release Management”, Advances in Science,

Technology and Engineering Systems Journal Vol 2.

No. 3, 36-40 (2017), ASTESJ ISSN:2415-669.

3-degree freedom network model to support release

Documents