PROGRAM UNDERSTANDING TASK IN THE CONTEXT OF PSP

PROGRAM UNDERSTANDING TASK IN THE CONTEXT OF PSP Vladan Jovanovic, Georgia Southern University, vladan@georgiasouthern.edu Richard Chambers, Georgia Southern University, rchamber@georgiasouthern.edu Steavn Mrdalj, Eastern Michigan University, stevan.mrdalj@emu.edu ABSTRACT Our experiences with professional programming and software process improvement as well as our recent experience adapting the Personal Software Process (PSP) for a university undergraduate course lead us to formulate a PSP level 2.1 process script for a new task, Program Understanding. We recognize this task to be crucial in the software maintenance process in which an existing system must be understood before change can be planned and implemented. Personal Software Maintenance Process is our derivative of the PSP (4) with the program understanding task being its main addition. The paper presents this step following the standard PSP format. Keywords: Personal Software Process, PSP, Program Understanding, Programming Process, Software Maintenance INTRODUCTION With efforts to improve onshore productivity to offset the lower labor costs of offshore suppliers, the software maintenance process is becoming increasingly important as existing systems are recycled and improved rather than re-invented. The use of existing software components in the building of new functionality, especially the use of Commercial Off The Shelf (COTS) components and frameworks, is becoming more necessary to provide consistent quality of software products and to improve software developer productivity. Yet academe frequently neglects the tasks of software maintenance and the use of COTS emphasizing the tasks of new development. Even Humphrey s (6, 7, 8) Personal Software Process (PSP), after more then 10 years of field exposure, does not offer specific guidance for maintenance programmers. The goal of the Personal Software Process (PSP) is to help individual programmers improve their own, individual software development process by using a disciplined and measurable programming skills improvement process. The PSP meta-process steps the student through a series of small projects during which the student collects measurements on defect rates, defect types, and other indicators of programmer productivity and programmer effectiveness in order to better understand and appreciate their strengths and weaknesses as a programmer. Recognizing that a programming process addressing maintenance has more tasks requiring some additional skills compared to new design, we decided to describe a simple but comprehensive process in a manner similar to a PSP script. We summarize the steps appropriate to maintenance programming using a generalized, language neutral approach. Volume V, No 2, 2004 551 Issues in Information Systems

In this paper we report initial results of our attempt to extend scope of applicability of PSP ideas to large systems with a prolonged life cycle. We specifically focus on the maintenance phase of the System Development Life Cycle (SDLC) in the case of post deployment enhancements. We treat enhancements and fixes as maintenance interventions driven by formal change requests. We do not discuss another, equally important class of intervention, the discovered defect (hitherto undocumented defect found while making changes to the source code), but see no reason why this proposed change to the PSP would not cover that eventuality as well. We assume change requests are either combined into a single intervention or treated as separate interventions. We assume change requests are mapped to interventions depending on uniqueness of the envisioned change and common features/functionality of the change requests the analysis of which include mapping maintenance task to common practices and resource expertise. As initiators of changes as well as the process of change request resolution varies independently of the personal software maintenance process we are excluding this aspect from our discussion. The work is an extension of, and a major update of an unpublished research (2) originally supervised in 1996 by one of the authors aimed to address opportunities and technologies recently adopted in mainstream IT. In this paper we are presenting essential elements of a PSP based Personal Software Maintenance Process (PSMP). PERSONAL SOFTWARE MAINTENANCE PROCESS (PSMP) The original PSP assumes the PSP methodology will be applied to individual work habits of programmers working in small teams. From the standpoint of our work and this paper, practices not included in PSP but in common use by individual programmers during the well organized maintenance of large systems are: - Change Request Analysis (including Risk Analysis and Scope Analysis) - Code and component reusability practices and processes - Refactoring (3) of source code as a part of implementing a change in functionality - Evaluation of proposed solutions Before justifying our selection of PSP level used as our baseline, we should clarify terms we are using. New design is an expression used for situations where new solutions are to be developed without previously available models or similar solutions. Such an approach is justified for the rare system deploying previously unknown capability or functionality implementing new basic requirements (as opposed to additional requirements congruent with existing functionality) or for very small (toy) problems typically used as illustrations in schools. By large system we mean software systems composed of approximately one million lines of code or more. Typical software development work comprises extending, enhancing or evolving an existing system or generating a new system using part or all of an existing system as a base for the new system. This implies that most programmers are practically always in a maintenance 'iteration' of an existing system with the benefit of a large body of work done previously. Consequently programmers are making small changes - interventions of a few hundred to a few thousand lines of code affecting much less then 1% of the code base. Larger change sets representing different product generations (releases) delivering jumps in application capability generally involve Volume V, No 2, 2004 552 Issues in Information Systems

portions of related work. This related work is partitioned or chunked based on related functionality, related data sources/sinks, functional layers, or other measures of commonality and is implemented with several, incremental iterations of the evolving application. Our focus was on the software maintenance process only. Starting from the well defined processes of the PSP family we selected PSP level 2.1 as a baseline given that: a) iterative development (PSP level 3) clearly represents a better fit in new design situations, and b) maintenance interventions can be treated as independent iterations and we wanted to focus on maintenance specific activities in a single intervention of a maintenance iteration. We consolidated our personal software maintenance process PSMP level 2.1 definition as an analog to the PSP 2.1 process. In the PSMP we added explicit checklists for quality criteria and key programming and design principles to be used in both the assessment of and planning for maintenance changes. Our live laboratory included not only repositories of personal experiences of the authors but a live software application of approximately one million lines of source code which is currently under maintenance in the Georgia Southern University NCR Project Laboratory. The software is a point of sale terminal application donated by the NCR Corporation to Georgia Southern University in 2002. A project team composed of two full time staff members and a number of CS, IS, and IT students (typically five to nine) are working on the application which has been licensed back to NCR and is sold as an NCR commercial software product. The project team has informally achieved a partial CMM level 2 organizational capability with verification test plans, source code and document repository, a service report database for tracking defects, ad hoc code reviews, and a standard build process. The project team maturity is somewhat impacted by the use of students with an initial skill level lower than the average professional programmer, a lack of real world experience in a commercial environment, and a profound belief that their academic preparation has been sufficient for a commercial environment. We have offset these issues through the use of hiring interviews to select good candidates, providing large amounts of guidance from the full time staff members, allowing students to make mistakes followed by a review of the mistake and their behavior leading to the mistake, and using a Co-Op process (full time work week) rather than a Student Intern process (part time while attending classes). We have also been blessed by being able to retain a core of students who have been with the project since its inception which has provided us the opportunity to create and maintain a CMM level 2 aware culture in the project team. A number of professional programming artifacts and ideas presented as part of the PSP model inspired some experimentation with the maintenance process. Results of the experiments indicated changes to PSP 2.1 to improve and update the PSP by creating a Personal Software Maintenance Process version (PSMP) of PSP thereby better supporting the software maintenance process used by individual programmers. We have modified several PSP guidelines and scripts to include important quality criteria for assessing goodness such as: sufficiency, necessity, consistency, cohesion, coupling, and a number of O-O design principles discussed for example in (5 and 9). The definition of the process also references a list of visualization tools (diagrams) and standards (defect classification, coding style etc.). We are currently experimenting with Orthogonal Defect Classification (ODC) process (1) profiling (process signature pattern recognition in order to assess readiness for test, and for release, the effectiveness of inspections, testing and review processes used etc.) and expect to replace PSP recommended defect Volume V, No 2, 2004 553 Issues in Information Systems

classification guidelines (7) with more comprehensive ODC based guidelines. A formal PSP like script for the PSPM Program Understanding Process (task) is presented in the Table 1. PSMP Program Understanding Process Script. This is essentially a checklist showing new tasks in the key maintenance process of Program Understanding. Also included in our PSMP 2.1 forms kit is the PSMP Project Plan Summary Script presented in the Appendix. There with bold letters we have highlighted the differences (added tasks) on top of a standard PSP 2.1 Project Plan Summary. The scope of experimental work on PSMP improvement goes beyond these scripts to cover the entire software process and its organizational support but they represent essential elements of a PSMP we are presenting in this paper. CONCLUSION Our PSP enhancements and specialization for the Software Maintenance Process are in the experimental phase and as such there is no definitive conclusion yet on its potential. Further work is necessary before an industrial strength process can be offered, but some future directions for exploration can already be identified. The PSMP model as tried implies that programmers are educated and experienced in using patterns, for example adapter and façade, in order to modernize legacy systems. As more and more programming work involves the use of Commercial Off The Shelf (COTS) components and generated code (using designers and wizards), the activities involved in understanding existing code and standards before making maintenance/enhancement changes is becoming more slanted towards those activities involved in understanding the problem domain. Evaluation of design alternatives and approaches especially regarding understanding the interfaces between pre-existing components is becoming (in our experience at least) a more pronounced activity. Observations and experimentations are in progress and we expect to enhance PSMP in the near future in the context of component based design with more architecture and evaluation bound tasks. REFERENCES 1. Chillarege, R., Bhandari, I., Chaar, J., Halliday, M., Moebus, D., Ray, B., Wong, M. (1992). Orthogonal Defect Classification - A Concept for In-Process Measurements, IEEE Transactions on Software Engineering, Vol. 18, No. 11, Nov 1992. 2. Fader, H. (1996). A Personal Software Maintenance Process, April 10, 1996, internal CIS research report, University of Detroit Mercy. 3. Fowler, M. (1999). Refactoring- Improving the Design of Existing Code: Addison Wesley 4. Higgins, D. (1986). Data Structured Software Maintenance- The Warnier/Orr Approach, Dorset House. 5. Horstmann, J. (2004). Object Oriented Design & Patterns: John Wiley. 6. Humphrey, W. (1995). A Discipline for Software Engineering: Addison Wesley. 7. Humphrey, W. (1997). Introduction to Personal Software Process: Addison Wesley. 8. Humphrey, W. (2000). Introduction to Team Software Process: Addison Wesley. 9. Martin, R. (2002). Agile Software Development: Principles, Patterns, and Practices: Prentice Hall. 10. Spinellis, D. (2003). Code Reading: Addison Wesley. Volume V, No 2, 2004 554 Issues in Information Systems

Table 1: PSMP Program Understanding Process Script Phase Purpose To guide you in performing the Program Understanding tasks for the PSMP Entry Criteria Source code Inputs Required Approved Change Request with background documentation Access to subject matter experts (when possible) Problem description PSMP Project Plan Summary form Size estimating template and historical estimated and actual size and time for the Program Understanding phase Time and Defect Recording Logs Defect Type standard 1 Program Understanding Planning Evaluation Criteria Script Produce or obtain a requirements statement. Measure the code size of the existing program. Estimate the time required for Design Recovery and Modification Design based upon historical productivity for Program Understanding. Enter the plan data in the PSMP Project Plan Summary. Complete the Time Recording Log. 2 Design Recovery Study existing Design Documentation to grasp probably affected portions of the system. Use Program Reading Skills (10), Structure Charts, UML Class Diagrams, Function Abstraction, Warnier s Diagrams (4), Sequence Diagrams, standardized design patterns and actual patterns from the application system code under maintenance (or from the experience base in the organization- this is less formal and independent of reusable model and implementation libraries) where appropriate to document the highlevel design of the program. Generate a question and answers journal documenting the design recovery activities, discovered issues, rationale for and the actual decisions for the proposed changes Generate problem domain use cases documenting how the current functionality is used and mapping problem domain actions into solution domain functionality and capability Use Program Reading skills, Structure Charts, UML Class Diagrams, Function Abstraction, Warnier Diagrams, Sequence Diagram and design patterns where appropriate to document the detailed design of parts of the program that require documentation in order to implement the required changes. Complete the Time Recording Log. 3 Modification Design Use program slicing, standard re-factorings and unit tests or informal methods to identify lines of code to add, delete, and modify. Use standardized method to develop a conceptual design. Define new test cases Review design, evaluate alternatives and provide rationale Complete the Time Recording Log. Exit Criteria A high level design of the existing software. Detailed design of parts of the software impacted by modifications. Questions and answers journal detailing discovered design, discovered defects, discovered issues, and modification plans PSMP Planning Form with plan and actual Program Understanding time, and planned program size figures. Volume V, No 2, 2004 555 Issues in Information Systems

Appendix PSMP Project Plan Summary (page 1/2) Programmer- Student Date Program Program # Instructor Language Summary Plan Actual To Date LOC/Hour Planned Time Actual Time CPI (Cost-Performance Index) (Planned/Actual) % Reused % New Reused Test Defects/KLOC Total Defects/KLOC Yield % % Appraisal COQ % Failure COQ COQ A/F Ratio Program Size (LOC): Plan Actual To Date Base(B) (Measured) (Measured) Deleted (D) (Counted) Modified (M) (Counted) Added (A) (N-M) (T-B+D-R) Reused (R) (Counted) Total New & Changed (N) (A+M) Total LOC (T) (N+B-M-D+R) (Measured) Total New Reused Upper Prediction Interval (70%) Lower Prediction Interval (70%) Time in Phase (min.) Plan Actual To Date To Date % Program Understanding Planning Design Recovery Modification Design Planning Design Design View Code Code Review Compile Test Volume V, No 2, 2004 556 Issues in Information Systems

PSMP Project Plan Summary (page 2/2) Programmer-Student Date Program Program # Instructor Language Postmortem Total Total Time UPI (70%) Total Time LPI (70%) Defects Injected Plan Actual To Date Program Understanding Planning Design Recovery Modification Design Planning Design Design View Code Code Review Compile Test Total Development Defects Removed Plan Actual To Date Program Understanding Planning Design Recovery Modification Design Planning Design Design View Code Code Review Compile Test Total Development After Development Defect Removal Efficiency Plan Actual To Date Defects/Hour Design Review Defects/Hour Code Review Defects/Hour Compile Defects/Hour - Test DRL(DLDR/UT) DRL(Code Review/UT) DRL(Compile/UT) Volume V, No 2, 2004 557 Issues in Information Systems