SystemDesign Methodologies

CM 3380-3

Maintenance is not part of the design process

by Claudia Buder, bq923372 Anne Holzapfel, hq923380

Abstract
In context of the level three module of System design Methodology a report about a given subject has been created. The following report describes shortly the underlying theory of the subject Maintenance is not part of the design process. Furthermore four case studies dealing with this topic are described. Some facts about the case studies are given. Finally a conclusion has been formed to verify or disprove this thesis on the basis of the described case studies and the theory.

Content
Abstract.......................................................................................................................................2 Content........................................................................................................................................3 List of Figures.............................................................................................................................4 Introduction.................................................................................................................................5 Allegation....................................................................................................................................5 Software Development/ Engineering..........................................................................................5 Software Development Methodology.....................................................................................7 Design Process........................................................................................................................7 Maintenance Process...............................................................................................................7 Summary.................................................................................................................................8 Case Studies................................................................................................................................8 A future for Professional Communicators in Software Engineering......................................8 General Information............................................................................................................8 The Authors.........................................................................................................................8 Content................................................................................................................................9 NASAs TReK Project: A Case Study in Using the Spiral Model of Software Development .................................................................................................................................................9 General Information............................................................................................................9 The Authors.........................................................................................................................9 Content................................................................................................................................9 Maintenance-Oriented Design and Development: A Case Study.........................................10 General information..........................................................................................................10 The authors........................................................................................................................10 Content..............................................................................................................................10 A Case Study: Demands on Component-based Development..............................................11 General information..........................................................................................................11 The authors........................................................................................................................11 Content..............................................................................................................................12 Conclusion................................................................................................................................12

List of Figures
Picture 1: Waterfall model..........................................................................................................6 Picture 2: Spiral model................................................................................................................6 Picture 3: The (a) traditional approach to software development and (b) a shift in that perspective.................................................................................................................................11

Introduction
In context of the SDM Module two assignments should be worked out. For the first one, described in the following, there was the possibility to choose one topic out of ten. It was decided to elaborate Maintenance is not part of the design process. Within the considerations software engineering is the basis for this assignment. Maintenance and design will be regarded as subprocesses of the software development process. In fact there are special definitions for the maintenance and the design that should provide the concepts for the work. Further meanings of maintenance and design are not taken into account as subject of the report.

Allegation
Both the design and the maintenance process describe the changing and modelling of a system or software. While the design process takes part during the development of the product, the maintenance only recently occurs after the system development and its delivery. Therefore, design and maintenance are different processes within software development but they influence each other.

Software Development/ Engineering

When developing an application special procedures take place. The way of going about the creation and upkeep of a new software product or system is called software process or software engineering. Within the development there are several activities that belong to it: specification of software development of software validation of software evolution of software Commonly specified models of the software process are used for making it more transparent. One of them is the Waterfall model that describes the different stages of the development in sequence with some overlap (see picture 1). The different phases are: specify requirements create design write code test maintain.

Picture 1: Waterfall model

The pure waterfall model process is usually not practical enough. Therefore there is another often used model, the Spiral model (see picture 2). There the Waterfall model is traversed several times and each pass through the Waterfall produces a new specified product that is more suitable than the previous one until the final product is ready for delivery. Maintenance is included in the section service at the end of the spiral.

Picture 2: Spiral model

Both models and the definition of the software development process show that the design process is independent from the maintenance process. But the design of the software is very

important for the quantity and quality of the later maintenance. The after-development maintenance can be very expensive when the requirement analysis and the design are not performed properly, e.g. no up-to-date requirements document, inflexible design.

Software Development Methodology

Software development methodology is based on a life-cycle model of system development and has a number of development phases with a set of steps and rules for each phase. Whereas a life cycle coarsely partitions the development of a system into stages, a methodology takes a life cycle and further divides each of the stages into a number of steps. A methodology will prescribe in great detail what tasks need to be done, what documents are produced at each stage and what documents are required as input to each stage. In fact, it provides a detailed plan for producing a system. (Britton and Doake, 19- 20) The use of a methodology eases the management of a project because of defining the input and output of every single process of a project. Thus a methodology should be adapted to the project and not be considered as perfect. Methodologies change over time equal to projects and topics.

Design Process
The design process that bases on the specified requirements deals with how the application is to be constructed, how the parts are involved and how they are to be assembled. There are three stages within the design process: study and understand the problem, identification of features of at least one possible solution and description of each abstraction used within the solution. Different levels of abstraction develop several models because of error and omission detection. During the process more and more details are added that create precise specifications of algorithms and data structures that has to be implemented further on. All of these activities are evaluated parallel and include the following steps: architectural design abstract specification interface design component design data structure design algorithm design.

Maintenance Process
The maintenance process describes the work performed on an application that happens after it has been delivered and includes some system changes to maintain its ability to survive (evolution). Maintenance can cover everything from fixing minor coding mistakes to major misunderstandings of user requirements. It deals with the modification and the extension of a developed system.

On the one hand there can be a defect removal that cares about finding and fixing all inconsistencies with the requirements document. On the other hand by introducing and satisfying new requirements there can be an enhancement of the software. There are three types of maintenance corrective maintenance (fixing reported errors in the software) adaptive maintenance (changing the software to some new environment) perfective maintenance (implementing new functional or non functional system requirements). Different types of errors also need different types to care about them. Coding errors, design errors, specification errors need different levels of maintenance complexity. All changes made during the maintenance process are validated and finally a new version of the system/ software is released.

Summary
Regarding the software development process (see different models) the design and maintenance process are independent parts. The definitions and objectives of both processes state that design is important before implementing the software. It handles the specified requirements and creates a useful basis for the coding. In contrast the maintenance of a system refers to a finished system and releases as result new versions of it. However, the design process should work in consideration of the later system maintenance in relation to reusability, portability and flexibility. A cost reduction may be a consequence of a well performed design phase. Finally, the thesis that maintenance is not part of the design process is provided by theory.

Case Studies
A future for Professional Communicators in Software Engineering
General Information
A future for Professional Communicators in Software Engineering was published by ACM (Association of Computing Machinery) Press in New York 1994. The case studys aim is that Communicators learn more about software engineering by describing in detail the phases of software development so that they are able to improve software products. The purpose of this paper is to specify areas in which technical communicators should become more competent and in which software engineering managers should consider involving communicators (Horberg 1994, 1). The author tries to answer the question why it is so difficult to develop good software. He wants to give a reference that software would be better when involving Communicators in more of the software development phases.

The Authors
John K. Horberg was a PhD student at Rensselaer Polytechnic Institute's Department of Language, Literature, and Communication at the time the article was published.

Content
The case study deals with an analysis of the software development phases including the maintenance and design process to show where professional communicators can be involved to increase the quality of communication between the developer of the software and the customers. The article is divided into three sections named Difficulties of Software Engineering, Survey of Software Engineers and Customers and Task for professional Communicators. The first section reflects the problem of communication between customers and engineers. The engineer tries to create an error free program but the customer doesnt really get what he wants. Here is where Horberg comes to the conclusion that a design process should be more flexible because user requirements change over time. To react flexible to those changing requirements the professional communicators are needed because software engineers are better at engineering software then they are at communicating with customers (Horberg 1994, 4). The second section explains a study on satisfaction and dissatisfaction of customers and engineers about software projects and its belonging communication, evaluated by the author in 1993. It results in the opinion that better communication between user and developer will end in a better software product. In the third section the software engineering process is explained in detail to show where communicators can take part. John K. Horbergs definition of a software engineering process is based on the Waterfall model (see above). The design process is described as a phase of showing the customer the development of the software design in single steps using for example storyboarding. Maintenance is not named as part of it but as an independent phase. The author has the opinion that involving communicators in the design process will reduce maintenance costs and result in higher quality of software.

NASAs TReK Project: A Case Study in Using the Spiral Model of Software Development
General Information
NASAs TReK Project: A Case Study in Using the Spiral Model of Software Development was published by ACM in Communications of the ACM (Volume 45 Issue 4) in April 2002. The Case Study deals with the use of the spiral model during the development of a PC based ground control system. It should help other project teams to choose the right process model to consistently produce high quality software on time, within budget, and under highly volatile real-world constraints (Hendrix and Schneider 2002, 1). The effort of the project team is reflected and estimated.

The Authors
T. Dean Hendrix is an assistant professor of computer science and engineering at Auburn University. Dr. Hendrix's research deals with issues in software engineering and associated automated environments. His current focus is on software visualization systems to support the human comprehension of software [www.eng.auburn.edu]. Michelle P Schneider is employed at NASAs Marshall Space Flight Centre and is the Telescience Resource Kit (TReK) project leader.

Content
The Telescience Resource Kit (TReK) is a project from the NASA (National Aeronautics and Space Administration). The developed software is used to monitor and control processes at the ISS (International Space Station). A life cycle has been worked out based on the Spiral

Model because they need an incremental approach more than a document driven approach like the Waterfall model. The developed lifecycle model for the TReK project has three phases, requirement analysis, the spiral and release. The spiral contains four regions which fulfils all the necessary software development activities including analysis, design, coding, testing and maintenance. It also includes project activities such as planning, scheduling, system management, configuration management, and quality assurance(Hendrix and Schneider 2002, 4). The four defined regions within the spiral were: planning/ risk assessment studies and engineering demonstration evaluation The number of increments was not fixed at the beginning of the project. It should be possible to react flexible to changing user requirements. The maintenance process was seen as an integral part of the lifecycle and handled within the spiral. Maintenance in their opinion began directly in a software project and isnt a separate, isolated activity to be addressed in the future(Hendrix and Schneider 2002, 5). If changes are needed during the development process they are performed whenever essential. The authors do not explicitly assign the maintenance to a process, neither to the design process nor as a special process itself.

Maintenance-Oriented Design and Development: A Case Study

General information
The case study is a report published in the IEEE journal IEEE SOFTWARE July/August 2002 as part of the category focus out of the box. The report represents a case study where traditional and maintenance-oriented processes are compared. The importance of maintenance and the focus on the development process toward it are shown, so that the software projects ends in success, on time and on budget.

The authors
As the director of online community development at Virtualia S.A. Jos Pablo Zagal makes researches in humancomputer interactions, computer game design and development, computer-assisted education, and online communities (BS in engineering and MSc in computer science). Ral Santelices Ahus, Blue Planet Software Ral Santelices Ahus is a software engineer at Blue Planet Software interested in virtual reality, computer game development, and real-time artificial intelligence (BS in engineering and MSc in computer science). Miguel Nussbaum Voehl: The full professor of computer science in the School of Engineering at the Catholic University of Chile has research interests including knowledge engineering, artificial intelligence in human sciences, and technology applications in education (EE from the Catholic University of Chile, MSc in computer science and PhD in informatics).

Content
For demonstrating the statement that maintenance efforts are very time and resourceconsuming as a part of the software development process and for making the importance and complexity of it visible, that case study cares about the development of handheld video games. The creation of Selva, a video game with educational content, was the task within a

project of a multidisciplinary team of the Schools of Engineering and Psychology at the Pontificia Universidad Catlica de Chile between 1996 and 1999. The project followed the traditional approach of software development. The main concern was the maintenance orientation within design and implementation. The later maintenance would be: modifications to the game levels and in each games dynamics interface changes changes to the educational schema Within the report some design instabilities are described that could be led to a maintenance cost increase. But the tasks of the used maintenance-oriented process plan show that the several design parts altogether worked with regard on the later maintenance and that it became a function of the design process. Nevertheless, the maintenance process was also an independent standalone process of the software development. Software development becomes an initial base design followed by maintenance as the next step. The base design specifies the design schemes and how they will handle quality assurance and requirement changes.( Zagal, Ahus and Voehl 2002, 100)

Picture 3: The (a) traditional approach to software development and (b) a shift in that perspective

A Case Study: Demands on Component-based Development

General information
The case study was published by ICSE in 2000 in Limerick, Ireland as a research and development report concerning the software development process within ABB Advant industrial process control system. In general the importance of producing flexible and compatible software with regard to designing, developing and maintaining components for reuse is described. As example, the design of the Advant system of ABB is used and the development and maintenance aspects of a component based system are used.

The authors
Ivica Crnkovic is professor on software engineering and chair of software engineering lab at the Mlardalen University (Vsters, Sweden), Department of Computer Engineering. Furthermore, he is involved in the Mlardalen Real-time Research Center MRTC.

Magnus Larsson also works for the Department of Computer Engineering at the Mlardalen University (Vsters, Sweden). 1993 Bachelor in Computer Engeneerin at Mrlardalen University 1995 Master in Computer Science at Uppsala University 2000 Licentiate degree in Computer Science at Mlardalen University In 1999 he started a Ph.D. program at Mrlardalen University and since 1993 Larrson designs and implements the infrastructure in ABBs automation platform. He cares about the ABB Automation products, research and development.

Content
First, the paper gives an overview of the situation of ABB as a global electrical engineering and technology company. It describes the Advant system, its architecture and components more in detail and underlines the special design of it for reuse. The main concern of the project is the design in view of scalability, openness and cost-efficiency, also in relation to the flexibility, robustness, stability and compatibility (migration between different platforms) of the system components and the necessary maintenance of the system. All requirements are described in detail and its advantages are highlighted. Later on, there is a description of the maintenance process that was handled on different levels: the system level (customers report their problems) the standard product level (errors detected in a specific product version are reported) the component level (e.g. a failure occurs at the product level, while the root cause lies in a component) These levels and the maintenance volume where planned and handled in the planning, design and development process of the project, to ensure reusability of the system with low costs. The conclusion of the case study is positive and mentions once more the independency of the maintenance and design process: Success in development, maintenance and continued improvement of the systems has been achieved by a careful architecture design, where the main principle is the reuse of components. The reuse orientation provides many advantages, but it also requires systematic approach in design planning, extensive development, support of a more complex maintenance process, and in general more consideration being given to components. (Crnkovic and Larsson 2000, 29-30)

Conclusion
In fact, by recognizing that maintenance is not a part of the software development process which is often topic of a case study, it was very difficult to find case studies that match the need of this report. Because of seeing maintenance as dependent to the software development process we attempted to find case studies concerning that subject, which include a definition of maintenance in the described project. However, these case studies included not more than one short sentence about maintenance within the described project. These difficulties may be led back to the problem that maintenance is not taken into account enough during the development of the software. Although it is a special independent process as the two case studies A future for Professional Communicators in Software Engineering and Maintenance-Oriented Design and Development: A Case Study expose, it should be more often regarded as important point during design decisions as mentioned in A Case Study: Demands on Component-based Development. The earlier maintenance is taken into account the less costs have to be spend on it. If you design your software considering reusability, scalability and flexibility it will affect the maintenance effort after the delivery of the project.

By defining the word maintenance it is important to be very precise. Sometimes maintenance is seen as every change made in the application during the whole lifecycle. Thus NASAs TReK Project: A Case Study in Using the Spiral Model of Software Development treat maintenance as being present and performed during the whole incremental process of software development. That is what we call testing and troubleshooting. But if maintenance is defined as that part of the development where modifying and improving of the still delivered software takes place, the other three case studies will fit in this definition. As mentioned before maintenance is according to our definition not part of the design process but to enhance the quality of the software and to reduce maintenance effort it should be considered as a serious decision criteria when designing and implementing the software.

Word count: 3110

References
Books Sommerville, Ian (1996) Software Engineering. Fifth Edition. Addison-Wesley Publishing Company Pressman, Roger S.( 2001) Software Engineering. A practical Approach. Fifth Edition. McGraw-Hill Book Co Britton, Carol and Doake, Jill (1993) Software System Development. A gentle introduction. McGraw-Hill Book Company Europe Braude, Eric. Sotware Design (2003) From Programming to Architecture. Wiley International Edition. John Wiley & Sons, Inc.

Articles Crnkovic, Ivica and Larsson, Magnus (2000) A Case Study: Demands on Component-based Development. ICSE, 22-30 Zagal, Jos Pablo, Ahus, Ral Santelices and Nussbaum Voehl, Miguel (2002) MaintenanceOriented Design and Development: A Case Study. IEEE Software July/ August 2002, p.100106 Hendrix, T. Dean and Schneider, Michelle P (April 2002) NASAs TReK Project: A Case Study in Using the Spiral Model of Software Development. Communications of the ACM Volume 45 Issue 4 Horberg, John K. (1994) A future for Professional Communicators in Software Engineering. ACM (Association of Computing Machinery) Press