(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 departmentScience and Research Branch,Islamic Azad University
Nasser Modiri
Computer departmentIslamic Azad UniversityZanjan, Iran
Mirmohsen Pedram
Computer Engineering departmentTarbiat Mollem UniversityKaraj/Tehran, IranTehran, Iranghazalkeshavarz@gmail.comnassermodiri@yahoo.compedram@tmu.ac.ir
Abstract
—Several researches have shown software complexityhas affected different features of software. The most importantones are productivity, quality and maintenance of software. Thus,measuring and controlling of complexity will have an importantinfluence to improve these features. So far, most of the proposedapproaches to control and measure complexity are in code anddesign phase and mainly have based on code and cognitivemethods;But measuring and control the complexity in thesephases (design and code) is too late. In this paper, with emphasison requirement engineering process, we analyze thefactorsaffecting complexity in the early stages of software life cycle andpresent a model. This model enables software engineering toidentify the complexity reasons that are the origin of many costsin later phases (especially in maintenance phase) andpreventerror publishing. We also specify the relationship betweensoftware complexity and important features of software, namelyquality, productivity and maintainability and present a modeltoo.
Keywords-Requirement Engineering, Software Complexity,Software Quality
I.I
NTRODUCTION
In decades, software complexity has created a new era incomputer 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 softwarecomplexity definition, but most of them is based on Zuse'sview of software complexity [1]," software complexity is thedegree of difficulty in analyzing, maintaining, testing,designing and modifying software". In other words, softwarecomplexity is an issue that is in the entire softwaredevelopment process and every stage of product life cycle.In the development phases of software, complexity stronglyinfluences the required effort to analyze and describerequirements, design, code, test and debugging the system. Inmaintenance phases, complexity specifies the difficulty in errorcorrection and the required effort to change different softwaremodule.Requirements form the foundation of the softwaredevelopment process. Loose foundation brings down the wholestructure and weak requirements documentation (the result of Requirement Engineering process) result in project failure.Recent surveys suggest that 44% to 80% of all defects areinserted in the requirements phase [2]. Thus, if errorsare notidentified in the requirements phase, it is leading to makemistakes, wrong development product and loss valuableresource.However, it will not be possible to develop better qualityrequirements without a well-defined Requirement Engineering(RE)process. Since RE is the starting point of softwareengineering and later stages of software development relyheavily on the quality of requirements, there is agood reason topay close attention to it.According to CHAOS report that published by the StandishGroup [3], good RE practices contribute more than 42%towards the overall success of a project, much more than otherfactors (see Table 1).
TABLE I. P
ROJECT
S
UCCESS
F
ACTOR
Project Success Factors% of ResponsesFactorsStronglyRelated toRE
User involvement15.9%
Executive ManagementSupport13.9%
Clear Statement of Requirement13.0%
Proper Planning9.6%Realistic Expectation8.2%Smaller Project Milestones7.7%Competent Staff7.2%Ownership5.3%Clear Vision andObjectives2.9%Hard-working, focusedStaff 2.4%Other13.9%
In following chapters of thisarticle, both complexity andRequirement Engineering field will introduce and provide ourproposed model to control the complexity by identifying
88http://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 lifecycle.II.R
EQUIREMENT
E
NGINEERING
Before discussing RE activities, it is worth having adefinition of Requirement Engineering. Zave [4] provides oneof the clearest definitions: "Requirement engineering is thebranch of software engineering concerned with the real worldgoals for, functions of, and constraints on software systems. Itis also concerned with the relationship of these factors toprecise specifications of software behavior, and to theirevolution 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 otherpart of the conceptual work is as difficult as establishing thedetailed technical requirements, including all the interfacestopeople, to machines, and to other software systems".The Requirement Engineering consists of five sub process:Requirement Elicitation, Requirement Analysis, RequirementSpecifications, Requirement Validation, and RequirementManagement.Capturing of user requirements and analyzing them formsthe first two phases of the Requirement Engineering process.After elicitation, these requirements are categorized andprioritized in the requirements analysis phase. Groupingrequirements into logical entities help in planning, reporting,and tracking them. Prioritization specifies the relativeimportance and risk of each requirement that help in managingthe project effectively. At the requirements specification stage,the collected information during requirementselicitation isstructured into a set of functional and non-functionalrequirements for the system and SRS is provided as the outputof the Requirement Engineering process. Note that a good SRSmust have special circumstances that are expressed in thestandard IEEE [6], for example, no ambiguity, complete,verifiable, adaptation, variability Traceability, etc. However,the customers cannot always specify accurate and completerequirements at the start of the process. Removing obsoleterequirements, adding new ones, and changing them are part of a never ending process during the software development lifecycle. Traceability aids in assessing the impact of changes andis fundamental action for Requirements Management process.On the other hand, Requirements Management ensures thatchanges are maintained throughout the software developmentlife cycle (SDLC).III.C
URRENT
W
ORK
I
N
T
HE
S
OFTWARE
C
OMPLEXITY
A
REA
Software complexity is a broad topic in softwareengineering and has attracted many researchers since 1976 [7].Complexity control and management have important roles inrisk management, cost control, reliability prediction, andquality improvement. The complexity can be classified in twoparts: problem complexity (or inherent complexity) andsolution complexity (also referred to as added complexity).Solution complexity is added during the development stagesfollowing the requirements phase, mostly during the designingand coding phase.Many researchers believe that software complexity is madeup of the following complexity [8]:
Problem complexity, which measures the complexityof the underlying problem. This type of complexity canbe traced back to the requirement phase, when theproblem is defined.
Algorithmic complexity, which reflects the complexityof the algorithm implemented to solve the problem.
Structural complexity reflects the complexity of thealgorithm implemented to solve the problem.
Cognitive complexity measures the effort required tounderstand the software.Since most of the activities have been in identifying andmeasuring the algorithmic, structural and cognitive complexity.Algorithmic complexity measured implemented algorithm tosolve the problem and is based on mathematical methods. Thiscomplexity is measurable as soon as an algorithm of a solutionis created, usually during the design phase.Structural complexity is composed of data flow, controlflow and data structure. Some metrics are proposed to measurethis type of complexity, for example McCabe cyclomaticcomplexity[9] (that directly measures the number of linearindependent paths within a module and considered as a correctand reliable metric), Henry and Kafura metric[10] (measuresthe information flow to/from the module are measured, highvalue of information flow represent the lack of cohesion in thedesign that will cause higher complexity) and Halsteadmetric[11] (which is based on the principle of count of operators and operand and their respective occurrences in thecode among the primary metrics, and is the strongest indicatorin determining the code complexity).There are some metrics based on cognitive methods such asKLCID [12] complexity metric (It defines identifiers as theprogrammer defined variables and based on identifier density.To calculate it, the number of unique program lines isconsidered).Identifying and controlling complexity in code or designstages of development is too late and leads error publishing inthe whole system.So to prevent wasting valuable resources and complexity, itis better to focus on early stages of the software life cycle.Therefore, the result of identifying complexity factors is lowcosts and high quality in software development and especiallyin maintenance stages of software. By knowing these factors,project team try to prevent occurring them or establish suitablestrategies in design and implementation phase.IV.M
ODEL
O
F
S
OFTWARE
C
OMPLEXITY
F
ACTORS
In the proposed model, we have provided softwarecomplexity factors according to their importance in the firstphase of SDLC (see Figure1).Based on this model, there are two main complexity factorsin requirements phase: Human resource and requirementsdocument (the output of RequirementEngineering process).
89http://sites.google.com/site/ijcsis/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 projectteam levels. Stakeholders are the most important complexityfactors, because the requirements extraction process results andtheir requested and desirable items form the system base.Stakeholders are people with different backgrounds,organizational and personal goals and social situations, andeach of them has its own method for understanding andexpressing the knowledge and communicates in various wayswith other people. So complexity is widely depending on thestakeholders, and placed in the first level of the model.The Input data to perform the next phases of the softwarelife cycle are documents, which are derived of the requirementsanalysis phase. All items and stated requirements, causes thecomplexity and so documents have considered as the secondlevel of the model. It is necessary to say that this level of thecomplexity results in inherent complexity of the system.Finally, project team (as a subset of human resources) isconsidered as another complexity factor, because of differencesin cognitive, experimental, subjective skills, and placed in thethird level of model. In the following, the model discussedmore in details.
A.Inherent Complexity Factors
The output of the Requirement Engineering process isSoftware Requirement Specification (SRS). SRS is includedthe principles of software acceptance, and monitors softwareproduct, not the product development process. SRS composedof several items, such as functional requirements, non-functional requirements, design constraints, interfaces, users,inputs and outputs, etc. All these items are the basis for thecomplexity identification.
Functional Requirements: Functionalrequirements shoulddefine the fundamental actions that must take place in thesoftware. Mostresearchersclaim thesizeofthe product isoneof themain factorsin determiningits complexity.Inthe other words, the more functional requirements resultin alarger and more complex system and would requiremoreeffort andresourcestosolve it(especially inmaintenance phase ).
o
Stability Degree: Some of the systems located inthe dynamic and competitive environment orinteract with evolving systems. The functionalrequirements of these systems expose in frequentchanges. Systems which undergo frequentmodification have higher error rates, becauseeach modification represents an opportunity fornew errors to be generated. It may also be thecase that when systems are undergoing frequentchanges, there is less opportunity and lessinterest in testing those changes thoroughly. Allof these lead to the complexity.
o
Sub function: It may be appropriate to partitionthefunctional requirements into sub functions orsub processes. This does not imply that thesoftware design will also be partitioned that way.More number of sub functions in a functionalrequirement means the high rate of complexity inthat requirement.
Non-Functional Requirement
:
It refers to the systemqualitative requirements and not fulfilling those leads tocustomer's dissatisfaction. More number of non-functionalrequirements and more forceto do them leadto morecomplexity in the product. A way to rank requirements isto distinguish classes of requirements as essential,desirable, and optional.
Design constraints:This should specify design constraintsthat can be imposed by other standards, hardwarelimitations, etc. Some constraints are, Implementationlanguage, database integrity policies, operatingenvironment, size of required resources; all of these limitthe developers and add complexity in the system.
System Interfaces: There arehardware interfaces,software interface, user interface, communicationinterface, etc. These specifythelogicalcharacteristicsbetweenthe softwareproductandhardwarecomponents,othersoftware products, usersanddifferentcommunicationprotocol. The more numbers oftheinterfaces representmore complexity in the system.
Input, Output, Files: Functional requirements process theinputs and process and generating the outputs, also filesare stored data in the system. So the number offiles, inputand output parametersand the relationship betweenthemis very important. Many numbers of these parametersrepresent hightransactionsandso complexity inthesystem.
Users: These requirementsare the number of supportedterminals and the number of concurrent users. High
90http://sites.google.com/site/ijcsis/ISSN 1947-5500
Search History:
Result 00 of 00
00 results for result for
p.
A Model for the Controlled Development of Software Complexity Impacts
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…
(More)
293
Reads
0
Readcasts
0
Embed Views
More From This User
Notes
Load more
