A Model for the Controlled Development of Software Complexity Impacts by ijcsiseditor


									                                                               (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

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).
                                                                                            TABLE I.        PROJECT SUCCESS FACTOR
    Keywords- Requirement Engineering, Software Complexity,
Software Quality                                                                                                               Factors
                                                                                                                   % of
                                                                                     Project Success Factors      Respon
                                                                                                                              Related to
                       I.    INTRODUCTION                                                                           ses
   In decades, software complexity has created a new era in                         User involvement               15.9%          
computer science.                                                                   Executive Management
                                                                                                                   13.9%          
   Software complexity could be defined as the main driver of
                                                                                    Clear Statement of
cost, reliability and performance of software systems.                                                             13.0%          
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%
requirements, design, code, test and debugging the system. In                       Hard-working, focused
maintenance phases, complexity specifies the difficulty in error                    Staff
correction and the required effort to change different software                     Other                          13.9%
    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
          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.
                                                                                    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,
[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

To top