Anda di halaman 1dari 6

(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
Computer department Science and Research Branch, Islamic Azad University Tehran, Iran

Nasser Modiri
Computer department Islamic Azad University Zanjan, Iran

Mirmohsen Pedram
Computer Engineering department Tarbiat Mollem University Karaj/Tehran, Iran

Abstract Several researches have shown software complexity has affected different features of software. The most important ones are productivity, quality and maintenance of software. Thus, measuring and controlling of complexity will have an important influence to improve these features. So far, most of the proposed approaches to control and measure complexity are in code and design phase and mainly have based on code and cognitive methods; But measuring and control the complexity in these phases (design and code) is too late. In this paper, with emphasis on requirement engineering process, we analyze the factors affecting complexity in the early stages of software life cycle and present a model. This model enables software engineering to identify the complexity reasons that are the origin of many costs in later phases (especially in maintenance phase) and prevent error publishing. We also specify the relationship between software complexity and important features of software, namely quality, productivity and maintainability and present a model too. Keywords- Requirement Engineering, Software Complexity, Software Quality

Recent surveys suggest that 44% to 80% of all defects are inserted in the requirements phase [2]. Thus, if errors are not identified in the requirements phase, it is leading to make mistakes, wrong development product and loss valuable resource. However, it will not be possible to develop better quality requirements without a well-defined Requirement Engineering (RE) process. Since RE is the starting point of software engineering and later stages of software development rely heavily on the quality of requirements, there is a good reason to pay close attention to it. According to CHAOS report that published by the Standish Group [3], good RE practices contribute more than 42% towards the overall success of a project, much more than other factors (see Table 1).
TABLE I. PROJECT SUCCESS FACTOR % of Respon ses 15.9% 13.9% 13.0% 9.6% 8.2% 7.7% 7.2% 5.3% 2.9% 2.4% 13.9% Factors Strongly Related to RE

Project Success Factors


User involvement Executive Management Support Clear Statement of Requirement Proper Planning Realistic Expectation Smaller Project Milestones Competent Staff Ownership Clear Vision and Objectives Hard-working, focused Staff Other

In decades, software complexity has created a new era in computer science. Software complexity could be defined as the main driver of cost, reliability and performance of software systems. Nonetheless, there is no common agreement on software complexity definition, but most of them is based on Zuse's view of software complexity [1]," software complexity is the degree of difficulty in analyzing, maintaining, testing, designing and modifying software". In other words, software complexity is an issue that is in the entire software development process and every stage of product life cycle. In the development phases of software, complexity strongly influences the required effort to analyze and describe requirements, design, code, test and debugging the system. In maintenance phases, complexity specifies the difficulty in error correction and the required effort to change different software module. Requirements form the foundation of the software development process. Loose foundation brings down the whole structure and weak requirements documentation (the result of Requirement Engineering process) result in project failure.

In following chapters of this article, both complexity and Requirement Engineering field will introduce and provide our proposed model to control the complexity by identifying

88 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 cycle. II. REQUIREMENT ENGINEERING

Many researchers believe that software complexity is made up of the following complexity [8]: Problem complexity, which measures the complexity of the underlying problem. This type of complexity can be traced back to the requirement phase, when the problem is defined. Algorithmic complexity, which reflects the complexity of the algorithm implemented to solve the problem. Structural complexity reflects the complexity of the algorithm implemented to solve the problem. Cognitive complexity measures the effort required to understand the software.

Before discussing RE activities, it is worth having a definition of Requirement Engineering. Zave [4] provides one of the clearest definitions: "Requirement engineering is the branch of software engineering concerned with the real world goals for, functions of, and constraints on software systems. It is also concerned with the relationship of these factors to precise specifications of software behavior, and to their evolution overtime and across software families." Brooks F.P [5] said that, "The hardest single part of building a software system is deciding what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other software systems". The Requirement Engineering consists of five sub process: Requirement Elicitation, Requirement Analysis, Requirement Specifications, Requirement Validation, and Requirement Management. Capturing of user requirements and analyzing them forms the first two phases of the Requirement Engineering process. After elicitation, these requirements are categorized and prioritized in the requirements analysis phase. Grouping requirements into logical entities help in planning, reporting, and tracking them. Prioritization specifies the relative importance and risk of each requirement that help in managing the project effectively. At the requirements specification stage, the collected information during requirements elicitation is structured into a set of functional and non-functional requirements for the system and SRS is provided as the output of the Requirement Engineering process. Note that a good SRS must have special circumstances that are expressed in the standard IEEE [6], for example, no ambiguity, complete, verifiable, adaptation, variability Traceability, etc. However, the customers cannot always specify accurate and complete requirements at the start of the process. Removing obsolete requirements, adding new ones, and changing them are part of a never ending process during the software development life cycle. Traceability aids in assessing the impact of changes and is fundamental action for Requirements Management process. On the other hand, Requirements Management ensures that changes are maintained throughout the software development life cycle (SDLC). III. CURRENT WORK IN THE SOFTWARE COMPLEXITY AREA

Since most of the activities have been in identifying and measuring the algorithmic, structural and cognitive complexity. Algorithmic complexity measured implemented algorithm to solve the problem and is based on mathematical methods. This complexity is measurable as soon as an algorithm of a solution is created, usually during the design phase. Structural complexity is composed of data flow, control flow and data structure. Some metrics are proposed to measure this type of complexity, for example McCabe cyclomatic complexity[9] (that directly measures the number of linear independent paths within a module and considered as a correct and reliable metric), Henry and Kafura metric[10] (measures the information flow to/from the module are measured, high value of information flow represent the lack of cohesion in the design that will cause higher complexity) and Halstead metric[11] (which is based on the principle of count of operators and operand and their respective occurrences in the code among the primary metrics, and is the strongest indicator in determining the code complexity). There are some metrics based on cognitive methods such as KLCID [12] complexity metric (It defines identifiers as the programmer defined variables and based on identifier density. To calculate it, the number of unique program lines is considered). Identifying and controlling complexity in code or design stages of development is too late and leads error publishing in the whole system. So to prevent wasting valuable resources and complexity, it is better to focus on early stages of the software life cycle. Therefore, the result of identifying complexity factors is low costs and high quality in software development and especially in maintenance stages of software. By knowing these factors, project team try to prevent occurring them or establish suitable strategies in design and implementation phase. IV. MODEL OF SOFTWARE COMPLEXITY FACTORS

Software complexity is a broad topic in software engineering and has attracted many researchers since 1976 [7]. Complexity control and management have important roles in risk management, cost control, reliability prediction, and quality improvement. The complexity can be classified in two parts: problem complexity (or inherent complexity) and solution complexity (also referred to as added complexity). Solution complexity is added during the development stages following the requirements phase, mostly during the designing and coding phase.

In the proposed model, we have provided software complexity factors according to their importance in the first phase of SDLC (see Figure 1). Based on this model, there are two main complexity factors in requirements phase: Human resource and requirements document (the output of Requirement Engineering process).

89 ISSN 1947-5500

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

Figure 1. The Model of Software Complexity Factors

Human resource is considered in stakeholders and project team levels. Stakeholders are the most important complexity factors, because the requirements extraction process results and their requested and desirable items form the system base. Stakeholders are people with different backgrounds, organizational and personal goals and social situations, and each of them has its own method for understanding and expressing the knowledge and communicates in various ways with other people. So complexity is widely depending on the stakeholders, and placed in the first level of the model. The Input data to perform the next phases of the software life cycle are documents, which are derived of the requirements analysis phase. All items and stated requirements, causes the complexity and so documents have considered as the second level of the model. It is necessary to say that this level of the complexity results in inherent complexity of the system. Finally, project team (as a subset of human resources) is considered as another complexity factor, because of differences in cognitive, experimental, subjective skills, and placed in the third level of model. In the following, the model discussed more in details. A. Inherent Complexity Factors The output of the Requirement Engineering process is Software Requirement Specification (SRS). SRS is included the principles of software acceptance, and monitors software product, not the product development process. SRS composed of several items, such as functional requirements, nonfunctional requirements, design constraints, interfaces, users, inputs and outputs, etc. All these items are the basis for the complexity identification.

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 software design will also be partitioned that way. More number of sub functions in a functional requirement means the high rate of complexity in that requirement. Non-Functional Requirement: It refers to the system qualitative requirements and not fulfilling those leads to customer's dissatisfaction. More number of non-functional requirements and more force to do them lead to more complexity in the product. A way to rank requirements is to distinguish classes of requirements as essential, desirable, and optional. Design constraints: This should specify design constraints that can be imposed by other standards, hardware limitations, etc. Some constraints are, Implementation language, database integrity policies, operating environment, size of required resources; all of these limit the developers and add complexity in the system. System Interfaces: There are hardware interfaces, software interface, user interface, communication interface, etc. These specify the logical characteristics between the software product and hardware components, other software products, users and different communication protocol. The more numbers of the interfaces represent more complexity in the system. Input, Output, Files: Functional requirements process the inputs and process and generating the outputs, also files are stored data in the system. So the number of files, input and output parameters and the relationship between them is very important. Many numbers of these parameters represent high transactions and so complexity in the system. Users: These requirements are the number of supported terminals and the number of concurrent users. High

90 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 complexity of the system. B. Added Complexity Factors Added complexity is added during different phases of the software life cycle because of various factors such as inappropriate use of standards, methodologies, methods and tools, lack of coordination of the project team, lack of enough skills and experience, etc. Human resource is a part of the project resources and lack of it is one the complexity causes. Human resource is investigated in stakeholders and project team levels. Stakeholder level: Stakeholders are individuals or organizations that were affected by the project and directly or indirectly affect system requirements. Requirement extraction is the process of identifying stakeholder needs, and the most common challenges during requirements elicitation process are to ensure effective communication between various stakeholders and elicit implicit knowledge. So effective 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 extraction from numerous stakeholders leads to waste much of resources (time and cost); further integrating the extracted requirement is timeconsuming and so hard. o Stakeholder's skills: System users are a group of major stakeholders. Individually, they can enhance sustainability at the company they work for by bringing their personal skills and experiences to aid change and innovation. Against, an inexperienced user by providing irrelevant, contradictory and confused requirements and frequent changes in requirements may cause the complexity and thus imposes heavy costs on the software.

Project team level: Skill and experience of the project members has also been identified as a possible factor affecting the complexity of user requirements. The skill of members could be measured in a number of very complex ways, But for experience of the project members, one factor has been highlighted as being important: has the project member worked on a similar project before, if so how many similar projects has he/she been part of and has project member had experience in the same team before? Also sub-contract may be considered as complexity factors. If the Requirement Engineering team is not present in the next phases of software development, new team is not familiar with initial SRS. Hence changing or improving the software may ignore some aspect and may lead to errors and complexity. V. MODEL OF SOFTWARE COMPLEXITY RESULTS

In this section, we are going to provide a model of software complexity results and check its impact on the main features of the system namely quality and the productivity.

Figure 2. The Model of Software Complexity Results

Cost, quality and maintenance issues can be seen in the most related topics to software development process. Complexity is determining factors that may affect them (see Figure 2). Complexity has affected on two important aspects of the software: error proneness and maintenance. The main idea behind the relationship between complexity and errorproneness is that when comparing two different solutions the more complex solution is also generating the more number of errors. This relationship is one of the most analyzed by software metrics researchers and previous studies and experiments have found this relationship to be statistically significant [14].

91 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 difficult to understand, and it increases the probability of hiding Since a great deal of software development costs are directed to the software integration testing, it is crucial for the project performance to possess the instruments for predicting and identifying the type of errors that may occur in a specific module. Error-proneness can influence quality. This impact is traceable through "usability" and "reliability" of the software. The concept of usability is connected to what the customer expects from the product. If the customer feels that he can use it in a way that he intend to, he will more likely be satisfied and regard it as a product with high quality. Thus, a large number of errors in software are presumably something that would lower the usability of the program. The reliability of a system is often measured by trying to determine the mean time elapsed between occurrences of faults (the result of the software errors) in a system. More reliable product is more stable and has fewer unexpected interruptions than a less reliable product. A defective product has a large amount of errors and it should be undergone of frequent changes to fix them. Frequent changes are not desirable to users and have negative effect on product quality. On the other hand, such product needs more resources to fix errors and thus have indirectly impact on the productivity. The relationship between complexity and maintainability is clear. According to Corbi's viewpoint [15], more maintenance costs are spent for understanding the system rather than to modify and improve it. Therefore, higher levels of system complexity make it difficult to understand, so maintenance would be time-consuming and costly. On the other hand, as shown in Figure 3, the cost required to fix an error later in the life cycle increases exponentially: it costs 5-10 times more to repair errors during coding phase and

errors. These errors show cost of current disturbances and cost of future activities to fix them. repeated testing waste resources and loss make low productivity. Therefore, less product complexity has been high maintainability. According to many quality models, maintainability is determining factor of the system. Finally, we should consider that the quality and productivity have a close relationship with each other. If we focus too hard on productivity, we may improve our efficiency and lower our project costs, but this gain is worthless if we are not building quality systems that meet the demands from our customers. Similarly, if we are aiming to create the perfect system, we may lose control of the costs. Moreover, the time it takes to improve and correct the system may cause a late delivery of the product. VI. CONCLUSION AND FUTURE WORK

Software quality and productivity depend on several factors such as on time delivery, within budget and fulfilling user's needs. Software complexity is one of the most important indicators that affect the software quality and productivity. To achieve higher quality and better productivity, software complexity should be controlled from the initial phases of the SDLC. In this article, with emphasis on Requirements Engineering process, we have analyzed the influential factors in software complexity, particularly in the first phase of software development, and provide a model. We also propose a model of complexity result. These models could be use as a roadmap to assist the manager in identifying complexity factors and avoiding them. In addition, it would be appropriate to know the impact of complexity on important characteristics of the system. 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. REFERENCES
[1] [2] Zuse, H., "software Complexity-measures and methods. Berlin: Walter de Gruyter", Berlin: Walter de Gruyter & Co, 1991 Eberlein A., Requirements Acquisition and Specification for Telecommunication Services, PhD Thesis, University of Wales, Swansea, UK, 1997 The Chaos Report the Standish Group Internatio al,, 1995 Zave P. and Jackson M. Four Dark Corners of Requirements Engineering, ACM Transactions on Software Engineering and Methodology, pp. 1-30, 1997 Brooks, F.P. , Essence and Accidents of Software Engineering, IEEE Computer, Vol. , pp. 10-19, April 1987 IEEE Std. 830-1984, IEEE Guide to Requirements Specification, 1984 W. P. Stevens, G. J. Myers, and L. L. Constantine, "Structural Design", IBM Systems Journal, vol. 13, no. 2, Jun. 1976, pp. 113-129

between 100-200 times more during maintenance phase than during the requirements phase [16].
Figure 3. Relative Cost of Fixing Errors in Project Lifecycle

The idea behind the relation between error-proneness and maintenance is that, maintainer spends a lot of financial and human resources to identify and correct errors and this means lower productivity. Mainly, complex system has frequent maintenance. Software maintenance challenges are system understanding, considering the side effects of changes and testing the performed changes. Frequent changes may make less interest in testing and surly loss product quality. On the other hand,

[3] [4]

[5] [6] [7]

92 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 Approach, London: International Thomson Computer Press, 1996 [9] Thomas J.McCabe, "A Complexity Measure", IEEE Transactions On Software Engineering, pp: 308-320, 1976

[10] Henry, S., Kafura, K.: Software structure metrics based on information flow. IEEE, Transactions on Software Engineering, pp: 510518, 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 ISSN 1947-5500