Software Development vs. Software Maintenance

2,698 views

Published on

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,698
On SlideShare
0
From Embeds
0
Number of Embeds
10
Actions
Shares
0
Downloads
55
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Software Development vs. Software Maintenance

  1. 1. Software Development vs. Software Maintenance Rahul Agarwal Virginia Tech rahulaga@vt.edu Abstract While Software Development and Software Maintenance are two distinct and widely separated activities they are actually part of the same life cycle Software design and development has come a long and the same importance needs to be assigned to both way since the early ad hoc ways to development for overall success and good Project Management. frameworks of today. We will try to understand what However in the real world only about 2% of the Software Project Management is and how it plays a research in past 10 years in computer science has been critical role in the success of any software product. We devoted to maintenance [Kemerer CF], so while I try will also analyze how Project Management applies to to treat equally and objectively the subject of and differs for Software Development and Software development and maintenance there is an awkward Maintenance. While the success rate of software imbalance in the available literature and empirical projects has been notoriously low, the exponential studies. increase in the absolute number of projects since 1970s and given the ubiquitous use of software we can As pointed out in [CS5984] for the year 1999 of safely assume that improvement in software project the total IT spending 30% was for maintenance, 25% management is underway and we will have improved for new development and the rest on infrastructure and development and maintenance of software in the other expenses (Figure-2). Therefore even though future. maintenance has the largest share of the budget it is ironic that there is not much focus on this area. Let us now look at Software Development and Software 1. Introduction Maintenance briefly. Software Engineering practices from the typical Software Development in our discussion ‘Waterfall Model’ view consists of: encompasses broadly the Rational Unified Process (RUP) [RUP, Royce 1998] and its four phases: (i) Requirements and Requirement Specifications (ii) Design and Architecture (i) Inception: It involves establishing the project (iii) Programming and scope and concept, demonstrating at least one Integration (iv) Testing and Software Delivery Development Requirements (v) Maintenance For the purpose of our Design/Architecture discussion we would like to group the first four Programming/Integration elements as ‘Development’ and the study Maintenance Testing/Delivery separately and this is shown in Figure 1. Maintenance Figure 1: Software Development and Software Maintenance
  2. 2. possible architecture, estimating cost and schedule and estimating New Other Development potential risks. 13% (ii) Elaboration: It involves baselining 25% the architecture and a completing the plan for the construction phase. (iii) Construction: It involves developing quality software as Infrastructure rapidly as possible to optimize 32% resource use and achieve (alpha, Maintainence beta) releases. 30% (iv) Transition: It involves testing and deploying the new system and Figure 2: IT Spending (1999) [CS5984] assessing user response and training end users and maintainers. (i) Poor quality of existing software Each phase has iterative steps and starting from (ii) System architecture and design done requirements gathering it culminates with product without maintenance in mind and deployment and training. For our discussion we (iii) Inexperienced personnel assume that the software development ends once the product is deployed and handed over to the users. In my opinion the most important factor is the failure to attract top talent and personnel in this critical Software Maintenance involves making changes to field since maintenance is generally not as exciting as the software after delivery in order to correct faults and creating something new. deficiencies found during usage, or to improve performance or any other attribute as well as to adapt This article will rigorously try to examine the role the product to a new environment. These are generally of Software Project Management in development and classified as [Favre]: maintenance. In trying to compare and contrast Software Development and Maintenance with regards (i) Corrective – due to error detections to Project Management we need to first examine the (ii) Adaptive – due to change in environment role of Project Management and its critical aspects and (iii) Perfective – for improving quality (e.g. then apply these objectively to both (Section 2). We performance) can then compare the results (Section 3) and conclude (iv) Evolutive – due to changing user with their differences and analyze how to bring requirements balance into these processes (Section 4). (v) Preventive – due to forseeable errors but with no immediate benefit (e.g. Y2K problem) 2. Software Project Management for Development and Maintenance Software maintenance is not given the priority it deserves and as such it is often neglected by the A successful project will meet customer management [Charette 1997]. There are many risk expectations, cost, schedule, quality, features, and factors in maintenance as the maintainers have to work make a profit for the developer [Royce 1998]. While with an existing system, have little or no these seem daunting, a good software project documentation, have many layers of patches and fixes management approach can balance the trade-offs and on top the original design, and little flexibility in make them a reality. Software Engineering is different changing the overall structure of the product. They from conventional Manufacturing Engineering also have to deal more with customer relations as processes and has the properties of complexity, customers expect the system to be running smoothly conformity, changeability and invisibility [SE]. and are not as forgiving as in the development stage. Managing software on economies of scale is also not possible. The marginal cost [Gwartney] associated There are a number of reasons suggested by with every additional function point or line of code is [Kemerer CF] for poor maintenance and ironically lack not negligible as suggested by classical economic of budget/resources is not an issue. The main problems theories for other engineering disciplines. Managing are: software is thus inherently different from conventional
  3. 3. products; therefore we need to study Requirements Management with respect to software Engineering, as a special topic. 7% “Project Management is a system Design, 6% of management procedures, practices, technologies, skill, and experience that Programming, are necessary to successfully manage 12% an engineering project.” [Thayer]. With regards to software it becomes Integration, 8% known as Software Engineering Maintenance, Project Management and involves 67% dealing with five major aspects Figure 3: Relative Costs of Phases of a Life-cycle [Schach 1999] common to any management activity [CS5984, Thayer]. These are: earlier. Efficient communication among all personnel at all levels of the management and • Planning: This involves pre-determining the conflict resolution are essential. complete course of action to meet project and organizational objectives by specifying goals • Controlling: This involves measuring and and objectives and developing strategies, evaluating performance and progress of the policies, plans and procedures for achieving organization and project towards meeting the them. This broadly includes risk assessment goals. Projects metrics to promote visibility, and mitigation, determining future course of monitoring and reporting systems are used action and preparing budgets and plans. and standards applied to assess the quality of the products. • Organizing: This involves developing an efficient project and organizational structure These encompass all the desired functions for “to allocate artifacts and responsibilities” managing a project however to do so successfully we [Royce 1998] in a pre-defined manner across need to take care of a number of aspects that are now teams. Organizations are generally organized discussed with respect to, and later applied to with an Organization Manager together with development and maintenance. four management authorities overseeing the Process, Environment, Quality and Personnel Life-Cycle and a number of individual Project Managers. A project is organized with a software Choosing the correct life-cycle is important and it management team overseeing the system determines how maintainable the software product will engineering, administration, architecture, be [Zagal 2002]. The important life-cycle models are development and assessment teams. Each Water Fall model, Spiral model, Exploratory model, team is relatively autonomous and responsible Incremental model and Reuse-based model; each with of the set of tasks assigned. its pros and cons. While each has the typical five stages described in the introduction there are variations • Staffing: This involves selecting and training how they are achieved. The stages maybe undertaken the vital human resources of the organization. exclusively and the next step undertaken only upon It broadly includes recruiting qualified completion of the current one or with repeated personnel, mentoring them into the development of software artifacts with improvements organizational culture, providing necessary in a number of ways including, rapid prototyping, training and conducting periodic employee customer involvement, and creating more risk driven assessment and feedback. approaches. Further details about Software Development stages can be found in [SE, RUP, Royce • Directing: This involves providing leadership, 1998] and are not discussed here. motivation, guidance and creating an atmosphere conducive for achieving According to [Schach 1999] the maintenance part organizational and project goals set out of the life-cycle accounts for 67% of the project cost
  4. 4. (Figure 3). Therefore in choosing the life-cycle [Zagal them more useful. There are two perspectives, top- 2002] suggests a shift from the traditional approach by down and bottom-up and they detail the plan from incorporating the maintenance into the very core of the macro-level to the micro-view and vice versa using the development life-cycle in a “Maintenance-Oriented” WBS partitions [Royce 1998]. The plan is essential for model. Thus to build software with maintenance in both development and maintenance however it would mind a number of changes shall be required at every have to be determined separately to meet the different stage of development. This may however not always objectives. be possible given various constraints, for example performance requirements might conflict with Software costs are determined by [Royce 1998]: modularity requirements. Trade-offs will therefore have to be made and generally since maintenance is (i) Its size (function points, lines of code) not accorded a high priority it is often neglected. (ii) Processes used (iii) Personnel (experience, training) For Software Maintenance [DOE 2002] proposes (iv) Environment (tools, techniques) a basic maintenance model using seven stages based (v) Quality “on the same software engineering principles and practices that lower risk and improve quality during With a quantum improvement in technology we the planning and development stages of the life-cycle.” can now use higher order languages (Java, C++), employ the Object Oriented paradigm, and use These seven stages are derived by grouping iterative development based on pre-defined “logically related” segments of work. frameworks like J2EE and Microsoft .NET. These together with Visual development and integration tools (i) Problem/Modification Identification Stage and faster and significantly cheaper hardware can (ii) Analysis Stage improve software economics dramatically. (iii) Design Stage (iv) Construction Stage The environment for software development and (v) System Test Stage maintenance must be suitably automated and these (vi) Acceptance Stage needs depend on the scale of the project. It is essential (vii) Delivery Stage to setup the infrastructure to meet the requirements for successful iterative development of any software As we can see these stages are very similar to the project. Automation is needed at all process levels and development process and similar management is part of a good project plan. The different automation strategies can be applied. needs depend on the workflows of the project and these are [Royce 1998]: Project planning and Cost Estimation (i) Management using metrics and cost A software project plan is as intangible as the estimation software itself and iterative processes are required to (ii) Environment using change management and formulate a good plan [Royce 1998]. There are a version control number of planning strategies and a good plan is (iii) Requirements using vision statements, use essential for estimating time, effort, resources and cost cases and iterative models required to build a software product. (iv) Design using visual modeling (v) Implementation using editors, compilers, We can decompose our plan into smaller more linkers and debuggers manageable task sets using Work Breakdown (vi) Assessment and Deployment using test Structures (WBS). WBS decomposes the project into automation and defect tracking discrete work tasks, assigns responsibilities and sets framework for scheduling and budgeting. Artifacts and Milestones Conventionally these WBS were too structured around the product design, had too little or too much detail These are strongly related to our next point of and could not be compared with others. discussion (Metrics) and are the critical tangible (printed manuals) and intangible (software code) In the Evolutionary approach ‘levels’ are defined process products that need to be examined at every for different workflows and phases and this makes phase. [Royce 1998] classifies artifacts created in each
  5. 5. of the stages into (i) Management and (ii) Engineering Most LCA components are derived from LCO Sets. Generally all the artifacts are composed of text, and after an iterative process leads to the final system graphics, UML, or other ad hoc notations and formats. and software architecture. Both emphasize on system feasibility study. IOC includes software development, The Management artifacts comprise documentation, licensing, deployment and training. (i) Planning Artifacts - work breakdown While most of these milestones apply specifically structure, business case, release to software development we must also identify specifications, software development plan milestones for maintenance. In my opinion these are (ii) Operational Artifacts - release description, similar to the ones discussed above. status assessments, software change order database, deployment documents and Project Metrics environment Software project metrics are an important part of The Engineering artifacts comprise any software development and they make progress and quality tangible and provide a basis for estimating cost (i) Requirements Set - vision documents and and schedule for project completion. Metrics can be requirements models summarized into the following categories: (ii) Design Set - design models, test models and software architecture description (i) Cost: Measuring actual vs. budgeted labor, (iii) Implementation Set - source code baseline hardware, software, office and other costs and associated files, and component (ii) Schedule: Measuring actual vs. planned executables deliverables completed, deliverables not (iv) Deployment Set - integrated executable completed, milestones met and milestones not product, associated files and user manual met (iii) Risk: Measuring anticipated vs. actual events These artifacts are used in determining progress and impact and according to Boehm [Boehm 1996] there are three (iv) Quality: Measuring actual vs. planned milestones to achieve: reviews, defects in code/documentation, major/minor defects and the origin of defect. (i) Life-cycle objectives (LCO) (ii) Life-cycle architecture (LCA) There are seven core metrics defined in [Royce (iii) Initial operational capability (IOC) 1998] for Software Development and classified under two heads: Each of these milestones can be applied to any suitable development process like waterfall or spiral. Management The most important goal of LCO is to determine the feasibility of the project. LCO thus tries to determine (i) Work and Progress: It comprises defining the objective and scope of the project, determine estimates and tracking progress and can be normal and abnormal scenarios of the proposed system assessed by completion of use-cases, counting usage, determine the stakeholders that include users, lines of code, evaluating test cases, and customers, developers, maintainers, the inter-operator checking against milestones. organizations if the system is linked to external (ii) Budgeted Costs and Expenditures: Comparing systems, and also a public representative if it involves costs and expenditures and this can be their safety, privacy or other issues. completed very objectively and these can also be compared to estimated cost and projections LCO also includes gathering system can be made. requirements and sufficient information to identify (iii) Staffing and team dynamics: Starting from a system architectures. It recommends using the small team growth progresses as risks are WWWWWHH principle of assessing Objectives better understood. Employee turnover shows (Why), Milestones and Schedules (What, When), poorly on the project and is an important Responsibilities (Who, Where), Approach (How), and measurement. Resources (How much).
  6. 6. Table 1: Metrics for Software Maintenance [DOE 2002] Problem Analysis Stage Design Stage Programming System Test Stage Acceptance Stage Delivery Stage Identification, Stage Modification Stage Factors Correctness Flexibility Flexibility Flexibility Flexibility Flexibility Completeness Maintainability Traceability Traceability Traceability Traceability Traceability Reliability Usability Reusability Maintainability Verifiability Interoperability Reusability Testability Comprehensibility Testability Testability Maintainability Maintainability Reliability Interoperability Comprehensibility Comprehensibility Comprehensibility Comprehensibility Reliability Reliability Reliability Metrics No. of Requirement S/W complexity Volume/ Error rates, by Error rates, by Documentatio omissions on changes Design changes functionality priority and type priority and type n changes (i.e. Modification (function points or version Request (MR) Documentation Effort per function lines of code) Generated Generated description error rates area documents, No. of MR Error rates, by Corrected Corrected training submittals Effort per function Elapsed time priority and type manuals, area (e.g., SQA) operation No. of duplicate Test plans and guidelines) MRs Elapsed time procedure changes Time expended (schedule) for problem Error rates, by validation Error rates, by priority and type priority and type Number of lines of code, added, deleted, modified, tested Quality in greater risk and even failure. The basic [SEI] paradigm is to: (iv) Change traffic and stability: These qualities are inter-related and with decrease in change (i) Identify (locate risks before they become requests the software converges towards problems) stability and predictability (ii) Analyze (evaluate impact and (v) Breakage and Modularity: Modularity is probability) average breakage (extent of change) and over (iii) Plan (mitigate risk by present and future time these should decrease for greater stability action) (vi) Rework and Adaptability: This aspect (iv) Track (monitor) and measures the time required for cost of change (v) Control (correct deviations) the risk (vii) Mean time between failures (MTBF) and maturity: Maturity is gained as the MTBF decreases over time and these are important quality characteristics Software Maintenance metrics according to [DOE 2002] are defined across each of its stage and summarized in Table 1. Risk Management Risk is defined as “a potential problem; a problem is a risk whose likelihood has reached 100%” [Charette 1997] or “Risk is the possibility of suffering loss” [SEI]. Risk is essentially lack of information, time or control [CS5984] and failure to take action can result Figure 4: Risk Management Paradigm [SEI]
  7. 7. Shared • Product vision based on This is undertaken using efficient communication. product vision common purpose, shared Following this paradigm Risk Management is the ownership, and collective process of assessing risk, taking steps to reduce it to an communication acceptable level and maintaining that level of risk. • Working cooperatively to Teamwork achieve common goal Two types of risk management have been suggested in • Pooling talents, skills, and [CS5984]: knowledge (i) Reactive Risk Management: As the name Human Resource Management (HRM) suggests its reacting to problems as they occur and there is no future planning to prevent Human Resources are the most important asset of failures any organization and HRM tasks include [Thayer]: (ii) Proactive Risk Management: This involves formal risk analysis and mitigation plans to (i) Recruiting: filling organizational positions by ensure that projects are not disrupted. hiring new personnel or promoting qualified people Effective Risk Management can be done using the (ii) Assimilating: Orientate and familiarize new framework of the 7 principles. people with the organization culture and practices Table 2: Risk Management Principles [SEI] (iii) Training: Provide help to improve knowledge, Global • Viewing software attitude and skills of the people perspective development within the (iv) Appraising: Evaluate personnel and set context of the larger performance goals systems-level view (v) Compensating: Provide wages, bonuses, • Recognizing the benefits, and other remuneration opportunity in risk (vi) Terminating: Remove people if necessary Forward- • Thinking for the future looking view • Managing resources while The quality and motivation of personnel is very anticipating uncertainties important and can determine project success or failure. • Encouraging free-flowing However it is imperative to recognize that [Bryan] Open information at and “Not all programmers are created equal.” This needs to communication between all project levels kept in mind when allocating different tasks of • Enabling all kinds of development and maintenance in a team. communication • Using processes that value 3. Comparison of Development and the individual voice Maintenance (bringing unique knowledge and insight to The importance and high cost of maintenance has identifying and managing been emphasized throughout this discussion. However risk) on most commercial projects the development and Integrated • Making risk management maintenance contracts are awarded to separate management an integral and vital part of contractors. This adds to the maintenance woes since project management no matter how well documented there is no way to • Adapting risk management express the developers mind on paper. Also the lack of methods and tools to a qualified personnel and relegation of maintenance project's infrastructure and creates a disparity between development and culture maintenance. Continuous • Constant vigilance • Identifying and managing Setting it apart from development, in addition to the process risks routinely through all direct costs mentioned so far maintenance also incurs phases of the project's life- indirect costs in the form of deterioration of software cycle and customer displeasure. The latter can be serious for
  8. 8. Table 3: Summary comparison of Software Development and Software Maintenance Software Development Software Maintenance Remark Life-Cycle • Multiple • Essentially based • Quick approaches – on customer solutions are linear, iterative, feedback and preferred incremental, “build-and-fix” [Favre] evolutionary approach therefore • Adaptive elaborate • Preventive life-cycles • Corrective not available • Perfective for • Evolutive maintenance Planning and Cost • WBS • Automation • NIL Estimation • Automation • Ad hoc cost • Cost estimation estimation models Artifacts and • Management • NIL • NIL Milestones and Engineering artifacts • LCO, LCA, IOC milestones Project Metrics • Cost • Correctness • Maintenance • Schedule • Maintainability metrics • Risk • Traceability listed • Quality • Reusability include • Reliability development • Flexibility metrics as • Testability well • Usability • Comprehensibility • Completeness Risk Management • Risk • Incorporating Risk • NIL Management Management into Paradigm [SEI] the organization [Charette 1997] Human Resource • Well trained • NIL • Poor Management personnel training and • All Universities resource offer availability courses/degrees • Certifications (e.g. Microsoft (MCSA, MCSD), Sun Certifications etc) continued for business survival. Of the desired management functions [CS5984, Thayer] while all are Development processes need to be modified to applied to development to a large extent, they are build software modules with high cohesion and low hardly applied to maintenance and seriously lack in coupling, thus enabling easier maintenance. With staffing and direction. emergence of commercial off the shelf software
  9. 9. (COTS) modularity among software is increasing. This [Bryan] Bryan, GE, Not all Programmers are created Equal, is a welcome change though we need to be wary of the University of California, Irvine reliability of component vendors. [Charette 1997] Charette, R. et al, Managing Risk in Software Maintenance, IEEE Software, Many/June 1997 [CS5984] Bohner, S., CS5984 Lecture Notes, Virginia Tech, Based on the Software Management aspects studied Fall 2004 in Section 2, Table 3 summarizes the differences [DOE 2002] System Engineering Methodology Version 3, between Development and Maintenance with regard to US Department of Energy, Directive number DOE 200.1-1A, Project Management. September 2002, Chapter 10 [Favre] Software Maintenance http://www- 4. Conclusion adele.imag.fr/~jmfavre/ENSEIGNEMENT/TRANSPARENT S/SoftwareMaintenance/7/SoftwareMaintenance-7.pdf [Gwartney] Gwartney et al, Economics: Private and Public Software Project Management has become more Choice, Thomson South-Western, Tenth Edition, Chapter 1. complex with the evolution of technology and as we [Kemerer CF] Kemerer, C. F., Software Maintenance, move ahead with more complex and service oriented University of Pittsburg, Chapter 11 software products new paradigms will emerge. Both [Royce 1998] Royce W, Software Project Management A Development and Maintenance play equally important Unified Framework, Addison Wesley 1998 roles in the success of a project and both get will [RUP] Kroll, Per, The Spirit of RUP, Rational Software 2001 become more complex and harder to manage. [Schach 1999] Schach, R., Software Engineering, Fourth Edition, McGraw-Hill, Boston, MA 1999, pp. 11 To get better return on investment on our [SE] Software Engineering http://manta.cs.vt.edu/cs5704/SEmodule/SE/Lessons/index.ht maintenance dollars we need to build software with ml maintenance in mind. While this shall be an ongoing [SEI] process the importance of project management cannot http://www.sei.cmu.edu/programs/sepm/risk/risk.mgmt.overv be undermined and it will continue to determine iew.html project success or failure. [Thayer] Thayer, R. H., Software Engineering Project Management, IEEE Computer Society, Second Edition, 5. References Chapter 3, 7 [Zagal 2002] Zagal, JP, Ahues, RS, Voehl, MN, Maintenance-Oriented Design and Development: A Case [Boehm 1996] Boehm, B., Anchoring the Software Process, Study, IEEE Software July/August 2002 IEEE Software, July 1996

×