(IJCSIS) International Journal of Computer Science and Information Security,Vol. 10, No. 3, March 2012
quality of the software. XP builds on a very strict iterativeapproach limiting the time needed to encounter errors andforces developers to fix the problem as soon as possible.
Quality as a Primary Objective:
XP software development process defines quality as amajor objective to improve the overall quality of thesoftware. Quality targets have to be defined by involvingproject team members and customer (On-Site Customer).Thus the quality goals become achievable and measurable.
Continuous Verification of Quality:
This includes extensive testing. Besides internal unittesting, external acceptance tests with the customer areneeded too, in order to verify that the product fulfills theneeds and requirements of the customer (Test-DrivenDevelopment).
The requirements of the customer who normally doesnot have a deep technical knowledge have to be considered,so that developers are able to build an application based onthat information. Thus it is necessary that the project teamunderstands the customer and his business. Otherwise it isnot possible to implement the customer needs accurately.XP teams focuses on the customer needs and requirementsthroughout the entire project by means of communicationand by framing user stories.
Architecture of a system has a major impact on theoverall quality of the product. Using a simple well-designedarchitecture allows easy integration and reuse (SimpleDesign and Continuous Integration).
Focus on Teams:
Focusing on team work also effects the motivation of project members. Seeing everyone as an equally importantpart of the project leads to a high identification of the teammembers with the product. Hence the project code is notowned by any single programmer but owned by the teamcollectively (Collective Code Ownership).
Better solutions are more likely with Pair Programmingsince two persons most likely have different perspectives of the same problem and therefore they complement each otherin solving it. This approach saves time and minimizes thenumber of errors. This is an explicit practice of XP.
Tailoring with Restrictions:
Software development process should rely on coreelements. Building on these core elements the processshould adapt practices (tailoring) according to the projecttype and project size (eg. RDP)
Risk management enables early risk mitigation and thepossibility to act instead of to react to problems and risks. Awell-defined risk awareness and mitigation managementform together an effective risk management and is a keyfactor in achieving high product quality.V.
EXISTING SYSTEMIn the existing system, a large number of codes aredivided into only two modules. So in the existing system,performance analysis takes more time and is also notaccurate.As per Mancoridis et al., the earliest of software metricsdeal with the measurement of code complexity and itsmaintainability. He measured the Modularization Quality(MQ) which is the combination of coupling and cohesion.Cohesion is measured as the ratio of the number of internalfunction-call dependencies that actually exist, to themaximum possible internal dependencies. Coupling ismeasured as the ratio of the number of actual externalfunction-call dependencies between the two subsystems, tothe maximum possible number of such externaldependencies. The system level MQ is calculated as thedifference between the average cohesion and the averagecoupling.VI.
PROCESS OF PROPOSED SYSTEM:In the proposed system, we haveconsidered the leaf nodes of the directory hierarchy of theoriginal source code to be the most fine-grained functionalmodules. All the files (and functions within) inside a leaf level directory are considered to belong to a single module,with the module corresponding to the directory itself. In thismanner, all leaf level directories form the module set for thesoftware.
A lot of work has been done in the past onautomatic approaches for code reorganization. There arecertain principles, which are most applicable to codereorganization. Our current ongoing effort is targeted on thereorganization of legacy software, containing millions of lines of non-object oriented code. This code was nevermodularized, or the modularization was very poor. Theproblem could be attributed as reorganization of millions of lines of code into modules. This code could reside inthousands of files, in hundreds of directories. Here, eachmodule is formed by grouping a set of entities like files,functions, data structures and variables into a logicallyinterconnected unit.
Modularization is based on certain designprinciples:
Principle1: Principles Related to Similarity of Purpose
A module is a cluster of a set of data structures andfunctions that together offer a distinct purpose. To rephrase,the structures used for representing knowledge and anyassociated functions in the same module should fit togetheron the basis of similarity-of-service as opposed to, forinstance, on the basis of function call dependencies. Clearly,