Recommended Configuration Management Practices for Freelance Software Developers Chaudry Bilal Ahmad Khan
Dr. Ali Ahsan
Department of Electrical Engineering Institute of Space Technology Islamabad, Pakistan
[email protected]
Department of Engineering Management Center of Advanced Studies in Engineering Islamabad, Pakistan
[email protected]
Abstract - Configuration Management (CM) is an important activity throughout the software development life cycle (SDLC). CM becomes essential if any of the artifacts is to be changed during the life cycle. There are many practices which can be adopted in configuration management to stream line the work and bring the quality to the software development process. For this reason most of the software development companies also adopt configuration management practices with larger teams to implement these practices. The problem appears with the freelance software developers, where the numbers of people working in teams are a few. This is an investigative study which is carried out to find if the freelance software developers adopt the configuration management practices. Moreover, the purpose of this study is to find out the configuration management practices freelance software developers suggest are important and should be done by the freelance software developers. The study was done by distributing an open ended questionnaire to the freelance software developers working in a team of 5-30. The results show that although the freelance software developers do not implement all the configuration management practices, but they do suggest a few practices which they feel are important for them to carry out their work efficiently. Keywords—Software Configuration Management; Software Quality Management; Change Management, Freelance Software Development
I.
INTRODUCTION
This paper presents the recommendations of CM practices for freelance software developers. CM can be thought as the combination of hardware and software to provide better traceability and control over the processes involved in the SDLC. Adoption of the CM practices has not only helped in developing and streamlining the processes during SDLC but also helped the software developers increase their return on their investment (ROI) in their businesses [1]. Successful
implementation of CM brings the quality to the software and work by cutting down the wastage of time in SDLC [2]. II.
Literature review
CM involves different steps for developing the baselines and versions of all the Configuration Items (CI). These basic steps of CM are applied to entire SDLC starting from getting the requirements of the software to software testing, verification and validation. Software Engineering Institute has also developed Capability Maturity Model Integration (CMMI) version 1.3 for the improvement of the processes for developing better software products and their services [3]. CMMI 1.3 gives a detailed description of all the process improvement methods including CM. Previously, studies have been done on the implementation, benefits and recommendations of CM practices in the organizations developing software [4-8]. The studies clearly show that it is recommended to adopt the CM practices to make the processes more reliable and robust resulting into a better and efficient end product. According to [9-10] CM is an integration of four basic requirements which can be done on different tools, the description of which are listed below: A. Identification of CIs First, it is important to identify the CIs. There are different types of artifacts which can be identified as CIs and non configurable items (NCI). The artifacts which can be identified as CIs can undergo change during SDLC. It is important to keep track of and control all kinds of changes during SDLC. The software requirement specification documents, software designs and test cases are the typical examples of the CIs. Another type of artifacts which usually are not identified as CIs are the NCIs. These artifacts need not be changed and controlled during the SDLC. Matrices results and software test results are the example of the NCIs. It is therefore important to identify all the CIs and add them in the repository.
B. Control of CIs Once the CIs are identified and are included in the repository, it is necessary to keep track of the changes of each CI throughout SDLC. The change requests from the customers may change the requirement specification document which may change subsequent steps in SDLC. In order to maintain proper change propagation through each step of the SDLC, it is important to have a control over each CI. Control not only helps in the change propagation but also in the bug tracking. It becomes important to keep track of the bugs generated each time the code is written and tested or every time the code is changed due to the change in the design or change in the requirement specifications. C. Accounting of CIs The controlled CIs produce statistics and status reports every time the change occurs in the artifact. These statistics provide an overview of how many times and why the artifact was changed including who worked on the artifacts. The status reports provide the current status of the artifact along with the baselines and versioning if applicable. D. Auditing the CIs All the changes made to the artifact is stored as a log. This log provides the details of all the changes made as a history along with the timestamps. This improves the traceability of all the artifacts selected as CIs. E. Tools for CM There are several software tools available for CM. Some of these software tools are open source like CFEngine and SmartFrog and some can be purchased like Microsoft’s Sharepoint. III. PROBLEM STATEMENT CM practices are largely being implemented in the organizations where the software are developed. Different software development organizations use different software for the management and control of their configurable artifacts or CIs. In larger organizations it becomes easier to implement all the CM practices as there are larger number of employees and properly established teams. However it becomes necessary for the software development organization to hire a configuration manager who can take care of CM processes. As CM plays an important role in SDLC by providing the traceability of the artifacts, it is important for any software developer to maintain the record of the changes made to the artifacts. Maintaining the traceability of the CIs in a large scale project requires a bigger team but for the smaller projects CM does not require a bigger team because handling the CIs is relatively easy and changes are easier to track. This brings in the freelance software developers into focus. The freelance software developers usually work in the smaller projects compared to the software development
organizations therefore requiring lesser effort to adopt the CM practices. Due to lack of human resource, it might become a problem to implement the CM practices. These reasons formulate the following research questions: Do the freelance software developers adopt CM practices? Which CM practices are recommended by the freelance software developers? Is it feasible for the freelance software developers to adopt the CM practices? IV. RESEARCH DESIGN In case of any change in the CI, it becomes necessary to keep track of the changes in it. For instance, in an ongoing software development project the customer may request a change in the requirements of the software. This may lead to a chain reaction changing different processes of software lifecycle. Irrespective of the size of the project, it becomes difficult important for the teams to keep track of the changes. In case of the freelance software developers, it is not necessary that all the CM practices should be followed. However there might be some of the CM practices which freelance software developers may think as important. It is therefore important to consult the freelance software developers if they adopt any of the CM practices. It is necessary to understand that a freelance software developer has relatively smaller teams as compared to software organizations. Therefore freelance developer’s focus on the CM practices may vary from that of the software organizations. A. METHODOLOGY This was a qualitative study. The questionnaires in this study contained total of forty eight CM practices. The questionnaire was an open ended questionnaire with an option of „Yes‟ and „No‟ to measure the percentage of software developers who were adopting different CM practices. The open ended questions consisted of two different categories. One of the open ended option for the respondents was “Should the respective CM practice be done by the freelance software developer?” and the second open ended option was “Why do you think the respective CM practice should be done?” The unit of analysis in this research was the freelance software developers. The questionnaires were distributed amongst the freelance software developers using the emails and Skype and the response was the received the same way. While distributing the questionnaires it was kept in mind that the freelance software development teams should consist of members of 5-30 freelance software developers. IV. DATA ANALYSIS AND DISCUSSION After receiving the data from the respondents, percentage of CM practices was measured.
A. Adoption of CM Practicesnby Freelancers
The results show the percentage of freelancers recommending each practice. It can be seen that more than 85% of the users recommended the practices “Monitoring and control mechanism of the process is in place”, “The status of request is being tracked till its closure” and “Changes have been clearly identified made in next build”, where 75% of the users recommend “Disaster recovery is being properly done”, “Archived versions of configuration items are being stored and recovered” and “Reasonable time has been taken for request processing?”.
Fig-1: Percentage of CM Usage by Freelance Software Developers The results in Fig-1 show that 57% of the respondents responded that they use CM practices, however 43% of the freelance software developers said that they do not use CM practices. This means that more than half of the responded are using CM practices. The results given in Fig-2 shows that there are some practices none of the freelancers are doing. The practice like “Documents being uploaded on any CM tool without any delay?” was not done by any of the freelancer. However the practices like “Monitoring and control mechanism of the process is in place.”, “The status of request are tracked till its closure” and “Changes have been clearly identified in next build” are done by more than 80% of the freelancers.
Fig-3: Recommended Practices Similarly third largely recommended practices with 62% of recommendations are “Unique identifiers have been assigned to all configuration items”, “The owner responsible for each configuration item has been identified”, “Changes to configuration items are being controlled throughout the life of the product”, “Authorization is being obtained before changed configuration items are entered into the Configuration management system”, “The history of change has been maintained” and “The upgraded versions of the changed work products have been correctly identified”. The reasons why the freelancers should adopt the specific practice mentioned by the freelancers were also investigated and the common reasons were filtered from all of the said reasons. These common reasons were calculated and the percentages of these are given in the graph in Fig-4.
Fig-2: Adoption Response of Freelancers for Each Practice B. Recommended by Freelancers: Once the results regarding the adoption of CM practices by freelance software developers are obtained, percentage of recommended practices by each freelancer was measured and can be seen in Fig-3.
Fig-4 shows that approximately 62% of the freelancers agreed that disaster recovery should be properly done. However each of the practices like “Monitoring and control mechanism of the process is in place”, “There is coherence between various directory structures of project using any tool”, “Redundant configuration items are deleted”, “The documents are being uploaded on any CM tool without any delay”, “Unique identifiers have been assigned to all configuration items”, “The integrity of the baselines has been assessed” and “The history of change has been
maintained” was recommended by 38% of the freelancers each.
should be done and percentage of respondents who have not adopted CM practices. The results in Fig-6 give a very interesting insight of how much percent of the freelancers are not doing the practices and how many are recommending these practices along with the common reasons. The results of this plot can be seen in Fig-6.
Fig-4: Reason for Adotping CM Practices C. Recommended CM Practices and Common Reasons for Adopting Practices: The result obtained from the recommendations becomes more meaningful if compared with the results of common reasons for adoption mentioned by the freelancers. This is the reason why practices recommended
by each freelancer were compared with their common reasons. The result is shown in Fig-5 below: Fig-5: Recommended CM Practices and Common Reasons for Adopting Practices The comparison in Fig-5 shows a good view of respondents recommending and giving the common reasons for why practice is recommended. This gives a good picture about how many freelancers are facing the same issue. Like 75% of the freelancers are not doing anything for disaster recovery but there are 62% freelancers who are giving the same reason for having the disaster recovery plan. D. Comparison of Recommended Practices and Common Reasons by Non-Adopters: Another comparison analyzed the recommended practices, common reason of why a specific practice
Fig-6: Comparison of Recommended Practices and Common Reasons by Non-Adopters The results show that the practices like “Planning of Audits”, “Conducting of Audits”, “Coherence Between Different Directory Structures”, “Usage of CM tools”, “Dedicated CM Manager”, “Deletion of Redundant CM Items”, “Disaster Recovery”, “Uploading of document in CM tool”, “Unique Identifier Assignment”, “Identification of Owner Responsible for Each Configuration Item”, “Storage and Recovery of Configuration Item”, “Maintaining Backup”, “Maintenance of Baselines”, “Change Requests Initiated and Recorded”, “Reason for Changes Recorded”, “Proper maintenance of Configuration Management Item so that Older Item can be Recovered”, “Integrity of Base Line”, “Proper Time Taken for Request Processing”, “Maintenance of History of Change”, “Dependent work Product are Correctly Identified”, “Baseline Done After Implementation” and “Changes Been Identified Clearly in the Next Build” were recommended but were not adopted by freelancers and the recommendations were also common for each practice. E. Reasons for not Adopting CM Practices: The reasons taken from the most of the freelancers why they do not adopt CM practices are listed as under: Do not have the time to implement these practices High Cost is required to support these practices The project life cycle is too small to do these practices
V.
CONCLUSION
The freelance software developers do not recommend all the 48 practices due to different reasons already discussed above. The practices which were not done by the freelancers but were recommended by more than 50% of the freelancers and also had the common reasons were chosen as the proposed practices to be done by the freelancers. The recommended practices for the freelancers are given as under:
Establishing Monitoring and Control mechanism of the process Planning of audits Usage of CM tool Coherence between Various directory structures of project using any tool Deletion of recommended configuration items Establishing disaster recovery mechanism Unique identification to the Configuration item Identification of the person who will do the Configuration management Maintaining backups History of Change to be Maintained Properly Identification of Versions of Changed Work Product Baselining done after the change implementation Clear identification of changes in the next build
References [1] [2]
[3] [4]
[5]
[6]
Marent, "The Benefits of Software Configuration Management," Marent White Paper, 2001. A. G. Do, "The Impact of Configuration Management During the Sofwtare Product's Lifecycle," in IEEE, 1999. S. E. Institute, "CMMI for Development, Version 1.3," Carnegie Mellon, 2010. A. Sarma and D. R. a. A. v. d. Hoek, "Empirical Evidence of the Benefits of Workspace Awareness in Software Configuration Management," in SIGSOFT, 2008. S. S. M. Fauzi, N. Ramli, and M. H. N. M. Nasir, "Software Configuration Management – A Result from the Assessment and Its Recommendation," in International Conference on Information Management and Engineering, 2009. R. Foulkes and M. P. Mills, "Software Configuration Management and Its Contribution to Reliability Program Management," IEEE Transaction on Reliability, vol. R-32, no. 3, pp. 289-292, Aug. 1983.
[7]
[8]
[9]
[10]
S. Pei and D. Chen, "The Implementing of Software Configuration Management Based on CMM," in IEEE, 2009. T. N. Nguyen, E. V. Munson, and C. Thao, "Object-oriented Configuration Management Technology can Improve Software Architectural Traceability," in Third ACIS International Conference on Software Engineering Research, Management and Applications, 2005. D. o. D. Systems Management College, Systems Engineering Fundamentals. Belvoir, Virginia, USA: DEFENSE SYSTEMS MANAGEMENT COLLEGE PRESS, 1999. B. Bruegge and A. H. Dutoit, Object Oriented Software Engineering Using UML, Patterns, and Java. Pearson, 2010.
