A Model for the Controlled Development of Software Complexity Impacts

Shared by: ijcsiseditor

Stats

views:: 84
posted:: 7/5/2011
language:: English
pages:: 6

Public Domain

Document Sample

(IJCSIS) International Journal of Computer Science and Information Security,
Vol. 9, No. 6, 2011

A Model for the Controlled Development of
Software Complexity Impacts
Ghazal Keshavarz Nasser Modiri Mirmohsen Pedram
Computer department Computer department Computer Engineering department
Science and Research Branch, Islamic Azad University Tarbiat Mollem University
Islamic Azad University Zanjan, Iran Karaj/Tehran, Iran
Tehran, Iran nassermodiri@yahoo.com pedram@tmu.ac.ir
ghazalkeshavarz@gmail.com

Abstract— Several researches have shown software complexity Recent surveys suggest that 44% to 80% of all defects are
has affected different features of software. The most important inserted in the requirements phase [2]. Thus, if errors are not
ones are productivity, quality and maintenance of software. Thus, identified in the requirements phase, it is leading to make
measuring and controlling of complexity will have an important mistakes, wrong development product and loss valuable
influence to improve these features. So far, most of the proposed resource.
approaches to control and measure complexity are in code and
design phase and mainly have based on code and cognitive However, it will not be possible to develop better quality
methods; But measuring and control the complexity in these requirements without a well-defined Requirement Engineering
phases (design and code) is too late. In this paper, with emphasis (RE) process. Since RE is the starting point of software
on requirement engineering process, we analyze the factors engineering and later stages of software development rely
affecting complexity in the early stages of software life cycle and heavily on the quality of requirements, there is a good reason to
present a model. This model enables software engineering to pay close attention to it.
identify the complexity reasons that are the origin of many costs
in later phases (especially in maintenance phase) and prevent According to CHAOS report that published by the Standish
error publishing. We also specify the relationship between Group [3], good RE practices contribute more than 42%
software complexity and important features of software, namely towards the overall success of a project, much more than other
quality, productivity and maintainability and present a model factors (see Table 1).
too.
TABLE I. PROJECT SUCCESS FACTOR
Keywords- Requirement Engineering, Software Complexity,
Software Quality Factors
% of
Strongly
Project Success Factors Respon
Related to
I. INTRODUCTION ses
RE
In decades, software complexity has created a new era in User involvement 15.9% 
computer science. Executive Management
13.9% 
Support
Software complexity could be defined as the main driver of
Clear Statement of
cost, reliability and performance of software systems. 13.0% 
Requirement
Nonetheless, there is no common agreement on software
Proper Planning 9.6%
complexity definition, but most of them is based on Zuse's
view of software complexity [1]," software complexity is the Realistic Expectation 8.2%
degree of difficulty in analyzing, maintaining, testing,
Smaller Project Milestones 7.7%
designing and modifying software". In other words, software
complexity is an issue that is in the entire software Competent Staff 7.2%
development process and every stage of product life cycle.
Ownership 5.3%
In the development phases of software, complexity strongly Clear Vision and
influences the required effort to analyze and describe 2.9%
Objectives
requirements, design, code, test and debugging the system. In Hard-working, focused
2.4%
maintenance phases, complexity specifies the difficulty in error Staff
correction and the required effort to change different software Other 13.9%
module.
Requirements form the foundation of the software In following chapters of this article, both complexity and
development process. Loose foundation brings down the whole Requirement Engineering field will introduce and provide our
structure and weak requirements documentation (the result of proposed model to control the complexity by identifying
Requirement Engineering process) result in project failure.

88 http://sites.google.com/site/ijcsis/
ISSN 1947-5500
(IJCSIS) International Journal of Computer Science and Information Security,
Vol. 9, No. 6, 2011
influential factors on complexity in early stages of the life Many researchers believe that software complexity is made
cycle. up of the following complexity [8]:
 Problem complexity, which measures the complexity
II. REQUIREMENT ENGINEERING of the underlying problem. This type of complexity can
Before discussing RE activities, it is worth having a be traced back to the requirement phase, when the
definition of Requirement Engineering. Zave [4] provides one problem is defined.
of the clearest definitions: "Requirement engineering is the
 Algorithmic complexity, which reflects the complexity
branch of software engineering concerned with the real world
of the algorithm implemented to solve the problem.
goals for, functions of, and constraints on software systems. It
is also concerned with the relationship of these factors to  Structural complexity reflects the complexity of the
precise specifications of software behavior, and to their algorithm implemented to solve the problem.
evolution overtime and across software families."
 Cognitive complexity measures the effort required to
Brooks F.P [5] said that, "The hardest single part of understand the software.
building a software system is deciding what to build. No other
part of the conceptual work is as difficult as establishing the Since most of the activities have been in identifying and
detailed technical requirements, including all the interfaces to measuring the algorithmic, structural and cognitive complexity.
people, to machines, and to other software systems". Algorithmic complexity measured implemented algorithm to
solve the problem and is based on mathematical methods. This
The Requirement Engineering consists of five sub process: complexity is measurable as soon as an algorithm of a solution
Requirement Elicitation, Requirement Analysis, Requirement is created, usually during the design phase.
Specifications, Requirement Validation, and Requirement
Management. Structural complexity is composed of data flow, control
flow and data structure. Some metrics are proposed to measure
Capturing of user requirements and analyzing them forms this type of complexity, for example McCabe cyclomatic
the first two phases of the Requirement Engineering process. complexity[9] (that directly measures the number of linear
After elicitation, these requirements are categorized and independent paths within a module and considered as a correct
prioritized in the requirements analysis phase. Grouping and reliable metric), Henry and Kafura metric[10] (measures
requirements into logical entities help in planning, reporting, the information flow to/from the module are measured, high
and tracking them. Prioritization specifies the relative value of information flow represent the lack of cohesion in the
importance and risk of each requirement that help in managing design that will cause higher complexity) and Halstead
the project effectively. At the requirements specification stage, metric[11] (which is based on the principle of count of
the collected information during requirements elicitation is operators and operand and their respective occurrences in the
structured into a set of functional and non-functional code among the primary metrics, and is the strongest indicator
requirements for the system and SRS is provided as the output in determining the code complexity).
of the Requirement Engineering process. Note that a good SRS
must have special circumstances that are expressed in the There are some metrics based on cognitive methods such as
standard IEEE [6], for example, no ambiguity, complete, KLCID [12] complexity metric (It defines identifiers as the
verifiable, adaptation, variability Traceability, etc. However, programmer defined variables and based on identifier density.
the customers cannot always specify accurate and complete To calculate it, the number of unique program lines is
requirements at the start of the process. Removing obsolete considered).
requirements, adding new ones, and changing them are part of Identifying and controlling complexity in code or design
a never ending process during the software development life stages of development is too late and leads error publishing in
cycle. Traceability aids in assessing the impact of changes and the whole system.
is fundamental action for Requirements Management process.
On the other hand, Requirements Management ensures that So to prevent wasting valuable resources and complexity, it
changes are maintained throughout the software development is better to focus on early stages of the software life cycle.
life cycle (SDLC). Therefore, the result of identifying complexity factors is low
costs and high quality in software development and especially
III. CURRENT WORK IN THE SOFTWARE COMPLEXITY AREA in maintenance stages of software. By knowing these factors,
project team try to prevent occurring them or establish suitable
Software complexity is a broad topic in software strategies in design and implementation phase.
engineering and has attracted many researchers since 1976 [7].
Complexity control and management have important roles in
IV. MODEL OF SOFTWARE COMPLEXITY FACTORS
risk management, cost control, reliability prediction, and
quality improvement. The complexity can be classified in two In the proposed model, we have provided software
parts: problem complexity (or inherent complexity) and complexity factors according to their importance in the first
solution complexity (also referred to as added complexity). phase of SDLC (see Figure 1).
Solution complexity is added during the development stages Based on this model, there are two main complexity factors
following the requirements phase, mostly during the designing in requirements phase: Human resource and requirements
and coding phase. document (the output of Requirement Engineering process).

89 http://sites.google.com/site/ijcsis/
ISSN 1947-5500
(IJCSIS) International Journal of Computer Science and Information Security,
Vol. 9, No. 6, 2011
 Functional Requirements: Functional requirements should
define the fundamental actions that must take place in the
software. Most researchers claim the size of the product is
one of the main factors in determining its complexity. In
the other words, the more functional requirements result
in a larger and more complex system and would require
more effort and resources to solve it (especially in
maintenance phase ).
o Stability Degree: Some of the systems located in
the dynamic and competitive environment or
interact with evolving systems. The functional
requirements of these systems expose in frequent
changes. Systems which undergo frequent
modification have higher error rates, because
each modification represents an opportunity for
new errors to be generated. It may also be the
case that when systems are undergoing frequent
changes, there is less opportunity and less
interest in testing those changes thoroughly. All
of these lead to the complexity.
o Sub function: It may be appropriate to partition
the functional requirements into sub functions or
sub processes. This does not imply that the
Figure 1. The Model of Software Complexity Factors software design will also be partitioned that way.
More number of sub functions in a functional
Human resource is considered in stakeholders and project requirement means the high rate of complexity in
team levels. Stakeholders are the most important complexity that requirement.
factors, because the requirements extraction process results and  Non-Functional Requirement: It refers to the system
their requested and desirable items form the system base. qualitative requirements and not fulfilling those leads to
Stakeholders are people with different backgrounds, customer's dissatisfaction. More number of non-functional
organizational and personal goals and social situations, and requirements and more force to do them lead to more
each of them has its own method for understanding and complexity in the product. A way to rank requirements is
expressing the knowledge and communicates in various ways to distinguish classes of requirements as essential,
with other people. So complexity is widely depending on the desirable, and optional.
stakeholders, and placed in the first level of the model.  Design constraints: This should specify design constraints
The Input data to perform the next phases of the software that can be imposed by other standards, hardware
life cycle are documents, which are derived of the requirements limitations, etc. Some constraints are, Implementation
analysis phase. All items and stated requirements, causes the language, database integrity policies, operating
complexity and so documents have considered as the second environment, size of required resources; all of these limit
level of the model. It is necessary to say that this level of the the developers and add complexity in the system.
complexity results in inherent complexity of the system.  System Interfaces: There are hardware interfaces,
Finally, project team (as a subset of human resources) is software interface, user interface, communication
considered as another complexity factor, because of differences interface, etc. These specify the logical characteristics
in cognitive, experimental, subjective skills, and placed in the between the software product and hardware components,
third level of model. In the following, the model discussed other software products, users and different
more in details. communication protocol. The more numbers of the
interfaces represent more complexity in the system.
A. Inherent Complexity Factors  Input, Output, Files: Functional requirements process the
The output of the Requirement Engineering process is inputs and process and generating the outputs, also files
Software Requirement Specification (SRS). SRS is included are stored data in the system. So the number of files, input
the principles of software acceptance, and monitors software and output parameters and the relationship between them
product, not the product development process. SRS composed is very important. Many numbers of these parameters
of several items, such as functional requirements, non- represent high transactions and so complexity in the
functional requirements, design constraints, interfaces, users, system.
inputs and outputs, etc. All these items are the basis for the  Users: These requirements are the number of supported
complexity identification. terminals and the number of concurrent users. High

90 http://sites.google.com/site/ijcsis/
ISSN 1947-5500
(IJCSIS) International Journal of Computer Science and Information Security,
Vol. 9, No. 6, 2011
number of any of these items represents the high  Project team level: Skill and experience of the project
complexity of the system. members has also been identified as a possible factor
affecting the complexity of user requirements. The skill of
B. Added Complexity Factors
members could be measured in a number of very complex
Added complexity is added during different phases of the ways, But for experience of the project members, one
software life cycle because of various factors such as factor has been highlighted as being important: has the
inappropriate use of standards, methodologies, methods and project member worked on a similar project before, if so
tools, lack of coordination of the project team, lack of enough how many similar projects has he/she been part of and has
skills and experience, etc. Human resource is a part of the project member had experience in the same team before?
project resources and lack of it is one the complexity causes. Also sub-contract may be considered as complexity
Human resource is investigated in stakeholders and project factors. If the Requirement Engineering team is not
team levels. present in the next phases of software development, new
 Stakeholder level: Stakeholders are individuals or team is not familiar with initial SRS. Hence changing or
organizations that were affected by the project and improving the software may ignore some aspect and may
directly or indirectly affect system requirements. lead to errors and complexity.
Requirement extraction is the process of identifying
stakeholder needs, and the most common challenges V. MODEL OF SOFTWARE COMPLEXITY RESULTS
during requirements elicitation process are to ensure In this section, we are going to provide a model of software
effective communication between various stakeholders complexity results and check its impact on the main features of
and elicit implicit knowledge. So effective the system namely quality and the productivity.
communication is an important factor in project success
and developing a good SRS. In the following, we are
going to describe the associated challenges with
stakeholders.
o Heterogeneity of the Organization: When doing a
project for an organization, there is strong
possibility that all stakeholders are not in a
geographical location. This means that
requirements extraction is done from various
stakeholders and in many different places. This
problem is occurred due to the heterogeneity of
the organization.
Research has been done into a number of
‘capability barriers’ which prevent effective
communication in geographically dispersed
groups [13]. The three identified problems
included not sharing a common first language,
being separated by sixteen time zones and the
difference in typing ability when communicating
via a messaging program.
o Number of stakeholders: When conducting a
project for a Virtual Organization, requirements Figure 2. The Model of Software Complexity Results
extraction from numerous stakeholders leads to
waste much of resources (time and cost); further Cost, quality and maintenance issues can be seen in the
integrating the extracted requirement is time- most related topics to software development process.
consuming and so hard. Complexity is determining factors that may affect them (see
o Stakeholder's skills: System users are a group of Figure 2).
major stakeholders. Individually, they can Complexity has affected on two important aspects of the
enhance sustainability at the company they work software: error proneness and maintenance. The main idea
for by bringing their personal skills and behind the relationship between complexity and error-
experiences to aid change and innovation. proneness is that when comparing two different solutions the
Against, an inexperienced user by providing more complex solution is also generating the more number of
irrelevant, contradictory and confused errors. This relationship is one of the most analyzed by
requirements and frequent changes in software metrics’ researchers and previous studies and
requirements may cause the complexity and thus experiments have found this relationship to be statistically
imposes heavy costs on the software. significant [14].

91 http://sites.google.com/site/ijcsis/
ISSN 1947-5500
(IJCSIS) International Journal of Computer Science and Information Security,
Vol. 9, No. 6, 2011
High levels of software complexity make software more errors. These errors show cost of current disturbances and cost
difficult to understand, and it increases the probability of hiding of future activities to fix them.
Since a great deal of software development costs are repeated testing waste resources and loss make low
directed to the software integration testing, it is crucial for the productivity.
project performance to possess the instruments for predicting
and identifying the type of errors that may occur in a specific Therefore, less product complexity has been high
module. maintainability. According to many quality models,
maintainability is determining factor of the system.
Error-proneness can influence quality. This impact is
traceable through "usability" and "reliability" of the software. Finally, we should consider that the quality and
The concept of usability is connected to what the customer productivity have a close relationship with each other. If we
expects from the product. If the customer feels that he can use focus too hard on productivity, we may improve our efficiency
it in a way that he intend to, he will more likely be satisfied and and lower our project costs, but this gain is worthless if we are
regard it as a product with high quality. Thus, a large number not building quality systems that meet the demands from our
of errors in software are presumably something that would customers. Similarly, if we are aiming to create the perfect
lower the usability of the program. system, we may lose control of the costs. Moreover, the time it
takes to improve and correct the system may cause a late
The reliability of a system is often measured by trying to delivery of the product.
determine the mean time elapsed between occurrences of faults
(the result of the software errors) in a system. More reliable VI. CONCLUSION AND FUTURE WORK
product is more stable and has fewer unexpected interruptions
than a less reliable product. Software quality and productivity depend on several factors
such as on time delivery, within budget and fulfilling user's
A defective product has a large amount of errors and it needs. Software complexity is one of the most important
should be undergone of frequent changes to fix them. Frequent indicators that affect the software quality and productivity. To
changes are not desirable to users and have negative effect on achieve higher quality and better productivity, software
product quality. On the other hand, such product needs more complexity should be controlled from the initial phases of the
resources to fix errors and thus have indirectly impact on the SDLC.
productivity.
In this article, with emphasis on Requirements Engineering
The relationship between complexity and maintainability is process, we have analyzed the influential factors in software
clear. According to Corbi's viewpoint [15], more maintenance complexity, particularly in the first phase of software
costs are spent for understanding the system rather than to development, and provide a model. We also propose a model
modify and improve it. Therefore, higher levels of system of complexity result. These models could be use as a roadmap
complexity make it difficult to understand, so maintenance to assist the manager in identifying complexity factors and
would be time-consuming and costly. avoiding them. In addition, it would be appropriate to know the
On the other hand, as shown in Figure 3, the cost required impact of complexity on important characteristics of the
to fix an error later in the life cycle increases exponentially: it system.
costs 5-10 times more to repair errors during coding phase and In future work, we are going to complete the model of
complexity factors and provide a requirement based metric.
This metric is extracted from all the factors that mentioned in
this article. By using both, we can measure and control the
software complexity much before the actual implementation
and design thus saving on cost and time especially in
maintenance phase.

between 100-200 times more during maintenance phase than REFERENCES
during the requirements phase [16].
[1] Zuse, H., "software Complexity-measures and methods. Berlin: Walter
de Gruyter", Berlin: Walter de Gruyter & Co, 1991
Figure 3. Relative Cost of Fixing Errors in Project Lifecycle
[2] Eberlein A., Requirements Acquisition and Specification for
Telecommunication Services, PhD Thesis, University of Wales,
The idea behind the relation between error-proneness and Swansea, UK, 1997
maintenance is that, maintainer spends a lot of financial and
[3] The Chaos Report the Standish Group Internatio
human resources to identify and correct errors and this means al,http://www.standishgroup.com/sample_research/index.php, 1995
lower productivity. [4] Zave P. and Jackson M. Four Dark Corners of Requirements
Mainly, complex system has frequent maintenance. Engineering, ACM Transactions on Software Engineering and
Methodology, pp. 1-30, 1997
Software maintenance challenges are system understanding,
[5] Brooks, F.P. , Essence and Accidents of Software Engineering, IEEE
considering the side effects of changes and testing the Computer, Vol. , pp. 10-19, April 1987
performed changes. Frequent changes may make less interest in [6] IEEE Std. 830-1984, IEEE Guide to Requirements Specification, 1984
testing and surly loss product quality. On the other hand,
[7] W. P. Stevens, G. J. Myers, and L. L. Constantine, "Structural Design",
IBM Systems Journal, vol. 13, no. 2, Jun. 1976, pp. 113-129

92 http://sites.google.com/site/ijcsis/
ISSN 1947-5500
(IJCSIS) International Journal of Computer Science and Information Security,
Vol. 9, No. 6, 2011
[8] Fenton N., Pfleeger S, Software Metrics- A Rigorous and Practical [9] Thomas J.McCabe, "A Complexity Measure", IEEE Transactions On
Approach, London: International Thomson Computer Press, 1996 Software Engineering, pp: 308-320, 1976

[10] Henry, S., Kafura, K.: Software structure metrics based on
information flow. IEEE, Transactions on Software Engineering, pp:
510–518, 1982
[11] Halstead M., "Element of Software Science", Amsterdam: Elsevier,
1977
[12] Kushwaha, D.S. and Misra, A.K., Improved Cognitive Information
Complexity Measure: A metric that establishes program
comprehension effort, ACM SIGSOFT Software Engineering,
Volume 31 Number 5, September 2006
[13] Toomey, L., Smoliar, S., Adams, L. Trans-Pacific Meetings in a
Virtual Space, FX Palo Alto Labs Technical Reports, 1998
[14] Curtis, B., Sheppard, B. Milliman,P. Third time charm: stronger
pediction of programmer peformnace by software complexity metric.
In proceeding of the 4th International Conference on Software
Engineering, pp: 356-360, 1979
[15] Corbi, T. A., “Program Understanding: Challenge for the 1990s”,
IBM System Journal, pp: 294-306, 1989
[16] Wieringa R.J., Requirements Engineering - Frameworks for
Understanding, John Wiley and Sons,1995

AUTHORS PROFILE
Ghazal Keshavarz received her BA. Degree in Comp. Sc. & Engg from
Shiraz Technical University, Shiraz, Iran in the year 2006. Currently she is
pursuing M.Sc. in Comp. Sc. & Engg from Islamic Azad University
(Science and Research branch), Tehran, Iran under the guidance of Dr
Modiri. She is presently working on Requirement Based Complexity metric
and Software Quality and Complexity Model.

Dr. Nasser Modiri received his M.Sc and PhD in Electronics engineering
from the University of Southampton (UK) and the University of Sussex
(UK). Assistant Professor of Department of Computer Engineering in
Islamic Azad University (Zanjan/Iran).

Dr. Mirmohsen Pedram Assistant Professor of Department of Computer
Engineering in Tarbiat Moallem University (Karaj/Iran).

93 http://sites.google.com/site/ijcsis/
ISSN 1947-5500