Software Engineering

Subject Code: MI 0033 BKID – B1965 Revised Edition II: Spring 2010

Sikkim Manipal University Directorate of Distance Education

Department of Management Studies

Board of Studies Chairman Mr. Pankaj Khanna HOD Management Studies Director SMU DDE HR, Fidelity Mutual Fund Additional Registrar Mr. Shankar Jagannathan SMU DDE Former Group Treasurer Wipro Technologies Limited Dean Mr. Abraham Mathew SMU DDE Chief Financial Officer Infosys BPO Dr. T. V. Narasimha Rao Ms. Sadhna Dash Adjunct Faculty and Advisor Senior HR Consultant SMU DDE Bangalore Prof. K. V. Varambally Director Manipal Institute of Management, Manipal

Revised Edition II: Spring 2010 Printed: September 2014 This book is a distance education module comprising a collection of learning materials for our students. All rights reserved. No part of this work may be reproduced in any form by any means without permission in writing from Sikkim Manipal University, Gangtok, Sikkim. Printed and Published on behalf of Sikkim Manipal University, Gangtok, Sikkim by Manipal Global Education Services Manipal – 576 104. Printed at Manipal Technologies Limited, Manipal.

Author’s Profile: Dr Jai Raj Nair holds a Bachelor's degree in Architecture from Bengal Engineering College (University of Calcutta), PGDBM from IIM, Calcutta and Ph.D from Symbiosis International University, Pune. He worked for 9 years in the business domain of Engineering and Software Consultancy in reputed organizations like Development Consultants Ltd. (Delhi and Calcutta), and Kirloskar Computer Services Ltd. (Bengaluru) prior to joining the academic world. At reputed B-Schools, he has taught IT-related subjects, pertinent for management, for over 12 years. Dr Nair is a voracious reader and an avid writer. He has presented papers at several national, regional and international conferences. Some of his papers were selected for international conferences conducted in Thailand, Italy, Greece and India. He has also published research papers and articles in management journals of repute. His research interests include e-retailing, supply chain management and retro-logistics, business process reengineering, technology-enabled retailing, to name a few.

Reviewer’s Profile Ramya S Gowda holds MS in Computer Science and Engineering and is pursuing her post-graduation in management. She was working as Scientist C in Master Control Facility, Department of Space Communication, ISRO, Hassan. She has been associated with academics from 2006. She is presently working as a faculty member in Sikkim Manipal University. She has published papers in various fields like Pattern Recognition, E-Learning and Distance Education, Data mining, Business intelligence, ecommerce, enterprise resource planning in national and international Journals and conference such as International Conference on Digital Factory (ICDF), National Conference on IT Enabled Practices and Emerging management paradigms, International Conference on Computer Technology and Development (ICCTD), emerging trends in computer science and information technology (ETCSIT), international journal on computer science and information technology (IJCSIT), International Journal Of Computational Engineering Research (ijceronline.com), and Journal of Information Technology and Engineering.

In House Content Review Team Dr. Sudhakar G. P. Ms. Ramya S Gowda. HOD Assistant Professor Dept. of Management Studies Dept. of Management Studies SMU DDE SMU DDE

Contents

Unit 1 Software as a Product and Software Engineering 1

Unit 2 Software as a Process and Traditional Process Models 21

Unit 3 Agile Development Methodology 44

Unit 4 Software Requirements Analysis and the SRS 56

Unit 5 Software Project Management: Part 1 (Project Planning and Project Estimation) 73

Unit 6 Software Project Management: Part 2 (Project Scheduling, Tracking and Risk Management) 94

Unit 7 Software Reliability 118

Unit 8 System Engineering 143

Unit 9 Analysis Concepts and Principles 165

Unit 10 Software Design Concepts and Principles 189

Unit 11 Software Testing Techniques and Technical Metrics 214 Unit 12 Software Testing Strategies 236 Unit 13 Software Verification 261 Unit 14 Capability Maturity Model for Software 279 Unit 15 CMM-Based Process Improvement 300 Unit 16 Software Quality Assurance 319

MI 0033 Software Engineering Course Description “Software Engineering” refers to a set of theories, techniques and methods, and tools which makes humans able to design, create and control large software products in a reliable and cost effective manner. The term software engineering was coined at NATO sponsored conferences held in Europe in the 1960s to discuss the growing engineer crisis and the need to focus on software development. Today, every sector of the economy depends on computers to a great extent as any sector uses computer-based information system. Business have realised the importance of software in improving performance and to gain competitive advantage. Like any other economic endeavour, development of software requires a systematic approach that includes comprehensive methods, better tools for efficient execution of these methods and procedures for quality assurance, coordination and control. It also involves people and their management. All the requirement aspects relating to any development have combined together to evolve as a discipline called software engineering. It is concerned with building quality eng-ware within time and resource constraints. The Self learning material (SLM) covers the process and product of software engineering, including the process framework, different process patterns, and different process models. Different project estimation techniques and models, different phases of software risk management are also discussed in this course. The concept of software reliability, system engineering, various design concepts and principles, software testing strategies are also covered in this course. The SLM throws light on software verification, CMM and its improvement and software quality assurance.

Course Objectives Software engineering is a discipline that connects the information system and organisation together. With help of this discipline we can create and manage various software in an industry. Since the aim of this SLM is to introduce students to various concepts of software and its process, each

unit of this SLM will help the students to be equipped with required knowledge. After studying this course, the student should be able to:  explain the dual nature of software – as a product and as a process  analyse why software researchers and practitioners are constantly endeavoring to improve software process on a continuous basis  elucidate some of the important models of “agile development”  elaborate how requirements are elicited from customers and importance of SRS  elucidate software project planning and scheduling  explain project tracking, control and risk management.  explain software reliability and software reliability metrics  describe the system architecture and its specifications  demonstrate software prototyping and software specification during software analysis  illustrate architectural design and procedural design  list out the automated testing tools  elaborate the art of testing and debugging  describe about symbolic execution  elucidate the five maturity levels of Capability Maturity Model (CMM) for software.  discuss the CMM based process improvement.  describe briefly about software quality assurance This courseware comprises 16 units. A brief description of the units is given below: Unit 1: Software as a Product and Software Engineering This unit provides you with an overview of software and software engineering. This unit also covers the process and product of software engineering, including the process framework, different process patterns, and different process models. Unit 2: Software as a Process and Traditional Process Models This unit discusses software as a process and explains some of the important software process models. This unit also analyses why software researchers and practitioners are constantly endeavouring to improve software process on a continuous basis.

Unit 3: Agile Development Methodology This unit explains “agility” as the latest methodology for software development. This unit also differentiates traditional software process models and agile models. It explains why the software fraternity adopted the “agility” philosophy. Some of the important models of “agile development” is also covered in this unit. Unit 4: Software Requirements Analysis and the SRS This unit covers the importance of requirements engineering in the software development process and tips to collect requirement of the customers. This unit explains the importance of SRS and use case methodology as the latest technique for specifying functionalities. Unit 5: Software Project Management: Part 1 (Project Planning and Project Estimation) This unit discusses different project management processes, describes about software project planning and explains project estimation techniques and models. Unit 6: Software Project Management: Part 2 (Project Scheduling, Tracking and Risk Management) This unit covers different project metrics such as size-oriented and function- oriented metrics, explains about software project planning, project estimation techniques and models, project scheduling, tracking and control and risk management. Unit 7: Software Reliability This unit explain various software reliability metrics, programming for reliability with respect to fault avoidance and fault tolerance. This unit also describes software quality metrics and software reuse. Unit 8: System Engineering This unit discusses on computer systems engineering and its types, system analysis and architecture. This unit also explains system specification review.

Unit 9: Analysis Concepts and Principles This unit discusses on requirement analysis and tasks, describes the scope of communication, explains the analysis principles, software prototyping and software specification. Unit 10: Software Design Concepts and Principles This unit discusses the concept of software design, design process and its fundamentals. This unit also explains the modular design and data design and illustrates architectural design and procedural design. This unit brief design documentation. Unit 11: Software Testing Techniques and Technical Metrics This unit describes software testing fundamentals, white box testing, black box testing and discuss about the control structure testing. This unit describes the testing of real-time system. The various automated testing tools are listed in this unit. Unit 12: Software Testing Strategies This unit defines strategic approach to software design and describes strategic issues. This unit also explains unit testing, integration testing, validation testing and system testing. It covers the art of debugging. Unit 13: Software Verification This unit describes code reading, static analysis, symbolic execution, proving correctness and code inspection. Unit 14: Capability Maturity Model for Software This unit discusses the levels of CMM for software, enlist the key process areas of CMM and briefly describes common features of CMM. Unit 15: CMM-Based Process Improvement This unit describes management sponsorship, concepts of commitments and management by fact, CMM-based process training and useful processes and point out the customer–supplier relationship in CMM-based processes. Unit 16: Software Quality Assurance This unit explains quality concepts and quality movement. This unit also describes software reviews and formal technical reviews and covers SQA activities. It also explain SQA plan.

Software Engineering Unit 1

Unit 1 Software as a Product and Software Engineering

Structure: 1.1 Introduction Objectives 1.2 The Rationale for a Software Engineering Discipline 1.3 Software 1.4 Software Engineering Characteristics of software engineering Objectives of software engineering 1.5 The Dual Role of Software 1.6 Industry Perspective 1.7 Software: The Product Software programs versus software products Evaluation of software product-ISO/IEC9126 1.8 Product Line Engineering 1.9 Summary 1.10 Glossary 1.11 Terminal Questions 1.12 Answers 1.13 Case Study

1.1 Introduction If one were to pose a simple question to a layman on the street – “what is software?” – chances are that a majority of the people would say “software is nothing but a collection of codes written in a programming language.” This typical response is a classic example of a “half-truth.” The “full-truth” is that software is the resultant output that software professionals create and then maintain till the end of the software lifespan. It encompasses not only the programs per se but also content that is presented and generated as the program executes. The documentation of the program in either physical form or digital form is also considered as an integral part of the software. It is a widely accepted notion that survival and prosperity of software professionals, now and in the future, will depend on how well they can deliver quality software at predicted cost and within committed time. Possession of programming skills maybe only one of the conditions to attain

Sikkim Manipal University B1965 Page No. 1 Software Engineering Unit 1 that goal, but more importantly, the software development has to be carried out in a highly disciplined manner. Software Engineering is that scientific discipline that enables systematic development of software and management of the developmental activities. Over the past few decades, researchers and practitioners of this discipline have developed frameworks, development strategies and methodologies for achieving the above goal, about which you will learn in this course. Objectives: After studying this unit, you should be able to:  appreciate software holistically  describe the evolution of software engineering in to an important discipline  differentiate between managing software projects and managing any other kinds of projects and the reason behind it  explain the dual nature of software – as a product and as a process  differentiate between software programs and software products  list the six quality characteristics of software as defined by ISO/IEC 9126 Model  describe the concept of product line engineering

1.2 The Rationale for a Software Engineering Discipline Software is now an essential ingredient in many businesses, but all too often the work is late, over budget, or of poor quality that fails to meet requirements of the clients in its entirety. Current marketplace dynamics requires that software be created by engineers who consistently use effective methodologies. These learning have to take place right at the academic level, so that the students like you can have an opportunity to practice and perfect them during your period of formal education. Typically, a student gets initiated into the software world by mastering a programming language. They experiment on academic projects (that are also called as dummy projects) and hone their technological skills and techniques to handle issues at this dummy problem level. As they mature, they learn to improvise on these methods and consequently, gain confidence in their ability to develop large software programs in a short span

Sikkim Manipal University B1965 Page No. 2 Software Engineering Unit 1 of time. However, such learning is often insufficient as they do not impart a sufficient foundation for handling the problems of real-world, large-scale projects that require coordination of several professionals who maybe geographically dispersed. This is where a formal grinding in software engineering comes to the rescue. We begin our journey by first defining software and software engineering.

Self-Assessment Questions 1. ______is nothing but a collection of codes written in a programming language. 2. ______is that scientific discipline that enables systematic development of software and management of the developmental activities. 3. What are academic projects called as?

1.3 Software Software is an umbrella term that refers to the different types of programs that execute on computers and related devices such as cell phones, washing machines, car engines, etc. At a very broad level, software is classified into two types – application software (e.g. Microsoft Office) and system software (e.g. Windows Operating System). Middleware is an expression that refers to software that acts as a “go-between” between two dissimilar kinds of application software (e.g. making request from an application in a Windows-based computer to a Linux-based computer, where the operating systems are dissimilar). We can purchase software or also obtain software in different formats such as shareware, liteware, freeware and open source. Shareware software is usually full-fledged software with all the features made available during a free trial period. After this period gets over, the user has to purchase the licence for continued use of the software. Liteware software is a category of shareware where the concept is the same but all the features are not made available during the trial period. Freeware software is always free, but may have restrictions on the copyright. In open source software, the developer furnishes the source code as well and the users who enhance the code have to agree to continue sharing the enhanced code as well. Open source

Sikkim Manipal University B1965 Page No. 3 Software Engineering Unit 1 software has become a rage now and probably, Android is the most popular open source software that is currently in vogue. Traditionally, software used to be packaged on floppy disks, CD-ROMs and DVDs. Today, most of the vendors prefer allowing the customer to download the purchased software from their servers, in an attempt to minimise piracy risks. Hence, in today’s context, much of the purchased software, shareware and freeware are downloaded over the Internet. We present below a few general kinds of application software:  Personal productivity software (e.g. Microsoft Excel)  Presentation software (e.g. Corel Draw)  Graphics software (e.g. MS Office Picture Manager)  CAD/CAM software (e.g. AutoCAD)  Specialised scientific applications (e.g. SPSS)  Software for specific industries or verticals (pharmaceutical industry, education industry), BFSI vertical (Banking, Financial Services, Insurance) Another method of classifying software would be as follows:  System software (e.g. UNIX, Windows)  Real-time software (e.g. Satellite Imaging Application)  Business software (e.g. Siebel CRM)  Engineering/scientific software (e.g. CAD/CAM)  Embedded software (e.g. Cell phones)  Personal Computer software (e.g. Word processors, DBMS, multimedia)  Artificial Intelligence software (e.g. software based on Data Mining, Neural Networks)  Web applications (e.g. Python, Ajax) Despite the multiple ways in which software can be classified, we need to realise that these classifications are not watertight and there can be overlaps (e.g. Microsoft Access, as a database, can be considered as “business software” as well as a personal computer software).

Sikkim Manipal University B1965 Page No. 4 Software Engineering Unit 1

Self-Assessment Questions 4. Software that has a free trial period but with limited features is called as ______software. 5. UNIX is an example for ______. 6. Give an example for web applications.

1.4 Software Engineering The term “software engineering” was coined way back in 1968 during the proceedings of the “North Atlantic Treaty Organization (NATO) Software Engineering Conference” held at Garmisch, Germany, and was intended to trigger discussions regarding the perceived “software crisis” at that point in time. The so-called crisis evolved around certain complexities in the software developmental process like projects running late, projects running beyond estimated cost, dubious quality of the software being created, mismatch between customer requirements and the functionalities delivered by the software and most importantly the fact that software projects had become unmanageable and code was difficult to modify and upgrade! Here are some real-life examples where major software projects floundered, either in terms of time or cost overrun. 1. In 1983, the State of Oklahoma, USA, awarded the contract to a leading accounting firm to develop a software system to handle the compensation claims of its workers. The initial budget was half million dollars. After 2 years, the software was still dysfunctional and it was estimated that more than $2 million had been spent in those 2 years. The software was finally delivered in 1987 after spending eight times the estimated budget! 2. Bank of America (BoA) embarked on a new computerised financial accounting software system. The budget was $23 million and the estimated time for delivery was 5 years. The existing system was abandoned and BoA spent $60 million more to make the new software functional. Finally, the whole project was terminated and never saw the light of the day. 3. In 1982, Allstate Insurance began developing an $8 million computer to automate its business processes. The estimated 5-year period got stretched to 11 years and the cost was in the region of $100 million!

Sikkim Manipal University B1965 Page No. 5 Software Engineering Unit 1

4. US Department of Defence installed the Airborne Self-Protection Jammer (ASJP), an electronic air-defence system, in more than 2,000 navy fighters and attack planes finally after a cost overrun of $1 billion and time overrun of 4 years! 5. The Federal Bureau of Investigators (FBI, USA) gave up midway the development of an ambitious fingerprint-on-demand software system and an information database on crime after spending over $500 million! (Source: Neumann, P. G. (1993, October). System development woes. Communications of the ACM, Vol. 36(10), pp. 146.) Most of the above failures happened because of the lack of engineering approach to software development. Thus, we see from the above examples that several companies have lost massive amounts of money because the software engineering approach was not followed! Such failures set the tone for later generation software practitioners to adopt the software engineering paradigm. The Institute of Electrical and Electronics Engineers (IEEE), regarded as the world’s largest professional association dedicated to advancing technological innovation and excellence, has provided a formal definition for software engineering: “Software engineering (SE) is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, and the study of these approaches; that is, the application of engineering to software.” In other words, software engineering is the application of engineering principles to software development because it integrates certain engineering practices into the methodology, for example, standard practices, standard formats for documentations, standard quality checkpoints, etc. This explains why software development is not considered as a “craft” but an “engineering process.” Simply put, software engineering can be looked at as a process, a set of methods, and an array of tools that are used for developing computer software

Self-Assessment Questions 7. When and where was the term “software engineering” coined?

Sikkim Manipal University B1965 Page No. 6 Software Engineering Unit 1

8. The Institute of Electrical and Electronics Engineers (IEEE), regarded as the world’s largest professional association dedicated to advancing technological innovation and excellence, has provided a formal definition for software engineering. (True/ False)

Activity 1: Assume that you are a software project consultant working in a software company. You have been assigned the task of inculcating discipline into the software approach in your company. How would you start your work? (Hint: Think of yourself as an evangelist, a “change-champion”!. Refer section 1.2)

1.4.1 Characteristics of software engineering Software Engineering promotes the idea that software should be developed by adopting a systematic, standardized engineering approach. Software and hardware are the two parts of a computer. However, there are major differences when one compares the manner in which a software project is to be conducted vis-à-vis a hardware project. Some of the important differences are as follows:  Hardware is “manufactured” whereas software is “engineered.”  Hardware performance reduces over time due to the snowballing effects of temperature extremes, humidity, dust, maltreatment and other environmental ills whereas software performance deteriorates over time due to the effect of introducing changes into the software code.  Hardware production is based on “assembly-line” production whereas software is predominantly custom-built.  Hardware translates into a physical object whereas software is virtual.  Unlike hardware, “spare parts” are not available for software.  A typical hardware component is discarded in an environment-friendly manner after its life-term gets over whereas in case of software, the tendency has been to reuse the components so that re-coding can be minimised. In fact, this philosophy of “software reuse” forms the backbone for the “object-oriented paradigm,” explained in Appendix I.

Sikkim Manipal University B1965 Page No. 7 Software Engineering Unit 1

Example 1: In today’s software, the Graphical User Interface (GUI) is built using the reusable components such as message windows, pull down menus and many more such components. The latest trend is to use in-built components in the software. This practice of using in-built components is popularly known as component engineering. The software requirements specifications must be clear, unambiguous, correct and consistent. The software requirements should not mention about the design and verification details of software, unless specified by the stakeholders.  The description of performance, design, functionality and interfaces must be clearly mentioned. There should not be any ambiguity or conflicts between the requirements. To ensure unambiguity in the requirements, a formal requirement specification language must be used.  The response of the software system to different situations must be noted.  The conformance about the software standard followed must be mentioned clearly along with the details about the inappropriate sections.  Labelling of details related to tables, figures, terms definitions, references and the units of measure used must be mentioned.  The requirements must be traceable, so that one can trace the references back to the requirements to know whether all the specified requirements are met as per customer needs.  The requirements must be verifiable against the specifications. 1.4.2 Objectives of software engineering As we are discussing about software and software engineering and have already discussed about the features of software, let us have a look at the objectives of software engineering.  Satisfy user requirement – Understanding the needs and requirements of the customer and developing the product according to the needs and requirements is extremely important, as a product that does not cater to the intended use will prove to be a failure.  High reliability – A software product delivered to the customer must be bug free and highly reliable.

Sikkim Manipal University B1965 Page No. 8 Software Engineering Unit 1

 Low maintenance – Maintenance of a software product is done when fully developed software is delivered to the customer. A small change in the structure of the software product should never end in restructuring the entire software product, as it would cost money to the company.  Delivery on time – A systematic approach needs to be adopted to deliver the software products as per the contract agreement.  Low production costs – The software product must be affordable/cost effective.  High performance – The developed software product must have an optimum performance level.  Ease of reuse – The software product must be user-friendly.

Self-Assessment Questions 9. What are the two parts of a computer? 10. Hardware is manufactured whereas software is ______. 11. The software product must be of high production cost in order to have an optimum performance level. (True/ false)

1.5 The Dual Role of Software Let us now discuss about the dual role of software. At one level, we can consider software as a product (e.g. Microsoft PowerPoint) and at another level we can consider software as a podium for delivering another product (e.g. Microsoft Windows as an operating system). We can also view software from a product perspective as well as from a process perspective. In other words, software is both a product and a process. Software as a product – The role of software as a product is basically providing computing capabilities as well as accessibility to local hardware through network computers. As a product, it produces, manages and modifies the source of information. Software as a process – Software, as a process, is a framework for the tasks that are required for building high-quality software. It is the process perspective that makes software engineering such a challenging discipline. Software as a process is covered in greater detail in Unit 2, where you will be exposed to traditional process models such as “Waterfall Model,” “Spiral

Sikkim Manipal University B1965 Page No. 9 Software Engineering Unit 1

Model,” etc. In Unit 3, we will discuss about the latest developmental approach in software engineering namely, the “Agile Method.” Nowadays, we find a significant improvement in the role of software when compared to the earlier decades. The following are some of the factors that affect the role of software:  Changes in the field of computer architecture (Right from Pentium-I to Supercomputers).  Improvement in hardware performance.  Massive improvement in computer processing capabilities at the same or lower cost.  Wide variety of inputs and outputs (changing from simple text to multimedia videos).  The increasing trend towards Natural User Interface (NUI) thereby making computers even more user-friendly, as compared to GUI-based computers. We have seen the different roles of software over the past few decades. These changes are due to the continuous development and improvement in hardware performance as well as significant changes in computing architecture. The software development process can be divided into four eras: Early era (1950–1960) This era witnessed designing of custom-made software for each application with limited distribution. Since it was batch oriented, the software developed was used by the person who developed it. Second era (1960–1972) This era brought in new concepts in computer systems. It enabled human– machine interaction by developing new applications and new levels of software and hardware. Real-time and multi-user software that could adapt any kind of changes and could be operated by many users at the same time was developed. Third era (1973–1985) This era saw the development of consumer-designed software. The cost of the hardware became low and hence distribution of developed software became economical.

Sikkim Manipal University B1965 Page No. 10 Software Engineering Unit 1

Fourth era (1985–Till date) This period has been very important for the growth of computer and software technology. We have been seeing a humongous and sustained growth, which has resulted in the development of powerful desktop systems, computer networking, parallel computing, artificial intelligence and object- oriented technology.

Self-Assessment Questions 12. Software, as a ______, is a framework for the tasks that are required for building high-quality software. 13. Expand the acronym ______NUI. 14. Which “era” has witnessed massive growth in “artificial intelligence”?

1.6 Industry Perspective By now you must be familiar with the evolving role of software. Let us try to understand the industry perspective of software engineering. During the early years of computing, it was found that the computer-based systems were developed by using the hardware. Since the cost of the hardware was high, technical standards and formal controls in the development of hardware were put in place. Each time a product was built, a thorough analysis of all the aspects involved in the design and development of the product was made mandatory. Processes were measured and analysed and suggestions for improvement were given. Thus, this was the early phase of hardware engineering. The software programming, on the other hand, was viewed as an “art form.” In the field of software, there were very few systematic methods and experienced people. The process of learning was based on trial and error method rather than a defined method, as there were no formal set of guidelines to be followed. However, in today’s world, the cost for the development of computer-based system has drastically changed. Hardware which was once considered as costly has become more cost effective and software has become costly. The following are some of the reasons for the software to become costly:  Long-time taken to finish the program.  Unable to fix all the bugs in a software product.

Sikkim Manipal University B1965 Page No. 11 Software Engineering Unit 1

 Unable to measure the progress of software development. With the aforementioned reasons, developers felt that there has to be a study that can help them to overcome the cost of software. This study is known as “software engineering.”

Self-Assessment Questions 15. In the early days of computing, it was found that the computer-based systems were developed by using the ______. 16. In the early days of software programming, the learning was based on the ______method.

Activity 2: Trace the growth of “software development” across various eras. Try to find out the latest trends in software development. (Hint: Refer Section 1.6.)

1.7 Software: The Product In this section, we will discuss about software as a product and the methods of evaluating it. Apart from this, we will also differentiate between a software program and a software product. When the requirements are provided, a clear set of objectives are set and the managers must decide the best model to be followed keeping in mind the deadlines, budget, availability of people and the technicalities required for the project. Without a defined requirement, it is impossible to estimate the cost and time required for the completion of a project. We now briefly describe how different types of software are used in different products. System software System software is written to serve other programs. It refers to the collection of files and programs that constitute a computer’s operating system. Examples for files are the drivers for printers, library functions, system services and configuration files. System software is installed while installing the operating system. It can be updated by executing “Windows update” for windows and cannot be run by the end user like an application program.

Sikkim Manipal University B1965 Page No. 12 Software Engineering Unit 1

Some of the examples for system software programs are assemblers, debuggers and compilers. Since it runs at a very basic level of computer, it is called as the “Low-Level” software and it acts as a user interface to enable the interaction between the operating system and the hardware. The system software always runs in the background. Artificial intelligence software, a system software, designs are knowledge-based expert systems that perform human-like operations. Robotics, artificial neural networks and medical diagnostic equipments are some of the applications where artificial intelligence software is used.

Application software Application program is not involved in performing the task directly; instead, it uses the capabilities of the computer in performing a single or multiple tasks. Some of the examples of application software are the word processors, spreadsheets, graphic software, accounting software and media players. It is a subclass of computer software developed for a business need and is supported by a database. It is a set of multiple applications bundled together to perform a task. Embedded software is an example of application software, that is, a program that is embedded/resides within a system or product and is designed to perform a particular task that requires very powerful set of processors.

1.7.1 Software programs versus software products In the previous section, we have seen how different kinds of software are used in different products. Let us now differentiate between a software program and software product, as given in Table 1.1.

Table 1.1: Software Program and Software Product

Software program Software product A software program is developed by A software product is developed by a software engineer and has limited many software developers and has functionality. much functionality. A user interface is not very important In a software product, the user for a software program, as it is often interface is very important, as the end used only by the developer. users of the product are not software developers instead, the customer.

Sikkim Manipal University B1965 Page No. 13 Software Engineering Unit 1

A software program usually has very A software product has usually has little documentation. extensive documentation, as it contains the details of all the processes involved in the manufacturing of the software product. A software program is developed on A software product is developed on the basis of a developer’s the basis of software engineering requirement. principles. A software program is for a single A software product is for multiple user. users.

1.7.2 Evaluation of software product-ISO/IEC9126 The previous section gave us an idea about the differences between a software program and a software product. In this section, we will learn how a manufactured software product is evaluated by a particular standard. The purpose of software engineering is to develop a good quality software product, which is affordable by the common man. Therefore, it is necessary to have high-quality products and ensure safety for human life. Note that there are two different types of approaches followed to ensure software quality.  Direct specification and evaluation of the quality of software.  Assuring high quality of the process by which the product is developed. In today’s corporate world, we see that multinational software companies are following appropriate standards to produce quality software products for different customers. The quality of a software product is defined by ISO/IEC 9126. This is an international standard for evaluating the quality of a software product. The International standard of ISO/IEC 9126 model consists of six quality characteristics, which are discussed here.  Functionality – Functionality is the ability of a software product to meet the expected needs of the end-user. It has been observed that although software is developed almost close to the requirements of the customer needs, it may not function properly. In that case, the software product is of no use.

Sikkim Manipal University B1965 Page No. 14 Software Engineering Unit 1

 Efficiency – Efficiency is the ability of a software product to perform accurate operations as defined. It is to ensure that the software product used in the system performs its best. The response time of the product has to be as expected.  Usability – A software product must be utilised to its maximum level, for the purpose, for which it is chosen. You also need to check whether the software developed is serving the purpose and has tolerance to errors. Thus, documentation must be provided about the product with a better understanding of the user interface.  Reliability – Reliability of a software product is the performance level of software under specified usage conditions.  Maintainability – A software product is analysed on usage, changed and tested for correctness, for maintainability. Maintainability is to make sure that the corrected product does not affect the performance of the other modules.  Portability – It is the ease with which a software product can be moved from one computing platform to another platform. Portability of software can be found in high-performance computing platforms. The standard ensures that the aforementioned six characteristics adhere to the software quality of a product.

Self-Assessment Questions 17. The quality of a software product is defined by ______. 18. Making provision for allowing changes to the software reflects the ______quality feature. 19. “Write once, run anywhere” was the claim with which the programming language “Java” was released in the late 1990s. Which of the software quality features does this reflect?

Activity 3: As a student of software engineering, try to think about the different software products that a developer can design for a sophisticated health care unit. (Hint: Refer to Section 1.7, especially the quality characteristics.)

Sikkim Manipal University B1965 Page No. 15 Software Engineering Unit 1

1.8 Product Line Engineering By now you must be familiar with the software development process, the software product and the way to evaluate them. Now let us educate ourselves about product line engineering. Product line engineering is also known as “product family engineering.” It is the synonym of domain engineering. We can define the product line engineering as the process of studying the product family. Product family refers to the architecture of the product platform of an organisation. This study provides the necessary information about the common and varying components of the product family. The study of product family is considered as a latest approach for creating new products. Its emphasis is more on the way to reuse the product in order to reduce cost and time. Therefore, product line engineering is a concept of reusing components and structures, thus saving cost and time. It is not a technology; but rather it is the way of doing business. Organisations that have tried to implement product line engineering have benefited. Software product family is a way of satisfying the specific needs of the customer by developing a product from a common set of assets in a specified way. They are always viewed as business drivers as it is considered as a low-risk and high-profit practice. So, companies today plan to merge both the business and the technical approaches for their success. Some of the benefits of product line engineering are listed below:  Higher productivity  Higher quality  Faster time-to-market  Lower labour needs  A new application of a proven concept  An innovative, growing concept in software engineering

Benefits In today’s corporate houses, attrition (constant reduction in the personnel) is very high, so product line engineering helps to overcome problems related to resource shortage. Organisations have started to implement product line

Sikkim Manipal University B1965 Page No. 16 Software Engineering Unit 1 engineering to realise its fruits. It was observed that, by using product line engineering, organisations have benefited and some of these benefits are listed below:  Improved productivity by as much as ten times.  Increased quality by as much as ten times.  Decreased cost by as much as 60%.  Decreased labour needs by as much as 87%.  Decreased time to market (to field, to launch) by as much as 98%.  Ability to move into new markets in months, not years.1

Self-Assessment Questions 20. Product line engineering is also known as ______. 21. Product line engineering focuses on ______of software. 22. List down any one benefit of product line engineering.

1.9 Summary Let us recapitulate the important concepts discussed in this unit:  Application of software engineering is required for development of software as past experiences have proved that a sloppy approach to software development can lead to time/cost overrun and under- performance issues. This provides the justification for treating software engineering as a stand-alone discipline.  Software and hardware, though complementary, require different approaches altogether. Hardware follows the “assembly-line production” philosophy whereas software is mostly custom-built.  Software exhibits dual nature – as a product and as a process.  There are six quality attributes for software as advocated by ISO/IEC 9126, namely, functionality, efficiency, usability, reliability, maintainability and portability.  Product line engineering, as a concept, is extremely important in today’s world.

1 http://www.sei.cmu.edu/productlines/ Sikkim Manipal University B1965 Page No. 17 Software Engineering Unit 1

1.10 Glossary Assembly-line production: An assembly line is a manufacturing process in which parts are added to a product in a sequential manner using optimally planned logistics to create a finished product much faster than with handcrafting-type methods. Natural User Interface (NUI): A Natural User Interface (NUI) is a system for human–computer interaction that the user operates through intuitive actions related to natural, everyday human behaviour. Programming language: An artificial language used to write instructions that can be translated into machine language and then executed by a computer. Software crisis: Software crisis was a term used in the early days of computing science to describe the impact of rapid increases in computer power and the complexity of the problems that could be tackled. In essence, it refers to the difficulty of writing correct, understandable and verifiable computer programs. Software piracy: Software piracy refers to the un-authorised duplication and the use of computer software.

1.11 Terminal Questions 1. Define software engineering and briefly discuss about its evolution. 2. Differentiate between “software” and “hardware.” 3. Briefly explain the characteristics used for evaluating the software quality. 4. Explain the objectives of software engineering. 5. Describe product line engineering, in brief. 6. Justify the need to have a separate discipline called as “Software Engineering.”

1.12 Answers Self-Assessment Questions 1. Software 2. Software Engineering

Sikkim Manipal University B1965 Page No. 18 Software Engineering Unit 1

3. Dummy Projects 4. Liteware 5. System 6. Phython 7. In 1968 during the proceedings of the “North Atlantic Treaty Organization (NATO) Software Engineering Conference” held at Garmisch, Germany 8. True 9. Hardware and Software 10. Engineered 11. False 12. Process 13. Natural user interface 14. Fourth Era (1985–Till Date) 15. Hardware 16. Trial and error 17. ISO/IEC 9126 18. Maintainability 19. Portability 20. Product family engineering 21. Reusability 22. Higher quality

Terminal Questions 1. (Refer to Section 1.4 for further information.) 2. (Refer to Section 1.4.1 for further information.) 3. (Refer to Section 1.7.2 for further information.) 4. (Refer to Section 1.4.2 for further information.) 5. (Refer to Section 1.8 for further information.) 6. (Refer to Section 1.2 for further information.)

Sikkim Manipal University B1965 Page No. 19 Software Engineering Unit 1

1.13 Case Study From Hardware Business to a Software Business: The Challenges Mr. Sub Jaanta is a successful entrepreneur who had set up a factory for manufacturing computer hardware in 1990 at Basirhat in West Bengal. Two decades later, his manufacturing unit was regarded as the best in Eastern India and has won several awards for its exemplary manufacturing processes. Being an entrepreneur, Mr. Sub Jaanta wants to explore newer avenues to carry his business forward. An obvious choice for him would be to consider a software development company that would be the perfect complement to his successful hardware business. He has a choice – either to acquire an existing software company or to start a new company from scratch. The global recession clouds lifted in 2010, and ever since, Mr. Sub Jaanta has been contemplating on setting up a software company as he believes that with his superb experience in the hardware manufacturing industry, he can easily pull off a software super-success story. Discussion Questions: 1. Is it a better idea to acquire an existing software company or to start a new software company? Justify your answer. 2. The fundamental belief for Mr. Sub Jaanta is that he can repeat the success story as hardware and software are both complementary to each other. Do you believe in his optimism? Justify your answer. 3. If you were appointed as an adviser to Mr. Sub Jaanta, how would you advise him to take his new software venture ahead? Explain the possible “pitfalls” and methods to bypass them.

References:  Aggarwal, K. K (2007), Software Engineering. New age International publishers,  Pankaj Jalote. (2010). Software Engineering – A Precise Approach. Daryaganj, New Delhi : Wiley-India  Roger S Pressman. (2010). Software Engineering – A Practitioner Approach. McGraw-Hill Higher Education.  A. A. Puntambekar. (2007). Software Engineering. Pune: Technical Publications

Sikkim Manipal University B1965 Page No. 20 Software Engineering Unit 2

Unit 2 Software as a Process and Traditional Process Models Structure: 2.1 Introduction Objectives 2.2 Software Project Life Cycles Process framework Process patterns 2.3 Process Models Linear sequential/waterfall model V-shaped model Prototype model Spiral model Incremental delivery model Rational unified process (RUP) Summary of the major process models 2.4 Using Process Models in Software Projects 2.5 Summary 2.6 Glossary 2.7 Terminal Questions 2.8 Answers 2.9 Case Study

2.1 Introduction We discussed software as a product in Unit 1. In this unit, we will describe software as a process and also explain some of the important software development life cycle models that have been in existence over the last few decades. These models have been collectively referred to as “Traditional Software Process Models.” A process can be defined as a set of “things” to be done when some work product (called software artefacts) is to be produced. We can define a software process as the manner in which software is developed. It is a step- by-step procedure of developing a complete software product. Each organisation follows its own set of processes to develop software development process, which are usually based on one or more of the aforementioned “traditional software process models.” The process of

Sikkim Manipal University B1965 Page No. 21 Software Engineering Unit 2 software development, which involves highly sophisticated software development tools and processes, is quite complex. The use of software development processes ensures that developers follow a systematic approach in developing the software and also incorporate the company guidelines to complete their project schedules. In today’s world, software companies are looking for better processes to enhance their quality and predictability of software development along with maintenance of costs. It is important to note that in the framework of software engineering, a process is not a rigid directive for developing computer software. On the contrary, it is a flexible methodology that allows the software practitioners doing the work to select the relevant set of work activities and tasks. The goal is always to deliver software on-time, on-cost and with the full set of requirements as desired by the customer. Objectives: After studying this unit, you should be able to:  describe software as a process  explain some of the important software process models  analyse why software researchers and practitioners are constantly endeavouring to improve software process on a continuous basis

2.2 Softrware Project Life Cycles We can classify software development projects into various types based on their business functional domain. In case a software company is interested in specialising in only one product or service, it will need to understand that particular function or domain thoroughly. Mere technical knowledge in how to develop the software by writing lines of codes may not be sufficient. For example, Kolkata-based “UshaComm” that has gained expertise in telecommunications-billing solutions that are used all across the world. For such companies, it is a prudent approach when they consider breaking down the project into a broad series of phases that would enable them to manage the project efficiently. The phases could be requirements in engineering, analysis, design, coding, testing, implementation and maintenance.

Sikkim Manipal University B1965 Page No. 22 Software Engineering Unit 2

As mentioned earlier, a software process can be defined as the step-by-step manner in which software is developed. Each organisation tailors this into its own set of processes to develop software development process. The use of software development processes within the project life cycles ensures that developers follow a systematic approach in developing the software and also incorporate the company guidelines to complete their project schedules. In today’s world, software companies are looking for better processes to enhance their quality and predictability of software development along with maintenance of costs.

Self-Assessment Questions 1. The use of software development processes within the project life cycles ensures that developers follow a unstructured approach in developing the software. True/false? 2. A software process can be defined as the ______manner in which software is developed. 3. UshaComm has gained expertise in which product worldwide?

Activity 1: Can you identify other software companies like UshaComm that have acquired the skill sets required for being “single-product” companies? How are these companies different from the software giant, Infosys Technologies Ltd.? (Hint: Refer to Section 2.2. Try to find out about the kind of projects that Infosys takes up.)

2.2.1 Process framework After introducing you to the concept of software process, we will now discuss about the process framework. The Capability Maturity Model (CMM) is a standard process framework based on people and product and their role in making a project successful. The CMM was propounded by “Software-Engineering Institute – Carnegie Mellon University, USA.” We will discuss more about the CMM and its levels in Unit 12. The teams in an organisation adopt their respective frameworks pertaining to the tasks assigned.

Sikkim Manipal University B1965 Page No. 23 Software Engineering Unit 2

We will now briefly discuss about some process framework activities shown in Figure 2.1.

Fig. 2.1: Process Framework Activities We can bridge the gap between the customer and the company through better communication, because the company interacts with the customer for gathering the project requirements. After obtaining the customer requirements, the project is planned. Then, the requirements are analysed and the software is designed in the process of modelling. Afterwards, the development of code and testing takes place in “construction.” Then, the developed software is delivered to the customer and a feedback is obtained for the product. The “umbrella activities” shown in Figure 2.1 take place across the entire software development work right from the requirements stage to the final implementation at the customer’s premises. We can define umbrella activities as the activities that focus on tracking and controlling the project, and are undertaken through the entire process of software development. In the process of software development, risks may take place. Such risks and their impact on the quality are analysed, and corrective action is taken, in the process of risk management. And, the process of ensuring that a software system and its relevant documentation are wholly of sufficient quality, for their purpose, is named as “Software Quality Assurance” (SQA). We can define “software configuration management” as the process of

Sikkim Manipal University B1965 Page No. 24 Software Engineering Unit 2 managing the configuration involved in a project when there is a change in the software. And, the activity of reusability management involves providing information pertaining to the reuse of software product. Finally, measurement takes place, to measure both the product and the process, to ensure that the projects undertaken by the company are delivered per the schedule.

2.2.2 Process patterns We know that a process is a systematic activity in any project, where a defined set of inputs are given to generate the required outputs. Now, we will discuss process patterns that are involved in a software development project. The term “pattern” relates to the process of solving a problem using a template. It helps an individual to know what to do, but not how to do. It is a way of reaching a solution for a common problem. We can conclude that the process pattern is a set of tasks and techniques used to develop object- oriented software. Process patterns help in the construction of software processes in an organisation. Let us briefly describe the three types of process patterns.  Task process pattern – Task process pattern provides a step-by-step procedure to do a specific task. For example, technical review, reuse of first process patterns.  Stage process pattern – It involves steps that are performed very often/iteratively for a single project stage. We can consider the stage process pattern as a high-level process pattern, which is included in many task process patterns. This kind of process pattern finds its presence in every stage of a software process like the object-oriented software process in the program stage  Phase process pattern – A phase process pattern gives us the details pertaining to the interactions that occur between the stage process patterns for a single project phase. For example, the initiate phase and the delivery phase. The construct pattern is a combination /collection of two or more stage process patterns. Most of the project phases are done in a serial manner and are similar to the structure development and object development, for example, the spiral model. In today’s world,

Sikkim Manipal University B1965 Page No. 25 Software Engineering Unit 2

an object-oriented program is considered as iterative only in small pilot projects whereas in the large projects, it is considered as a serial process. Generally, a process pattern describes the following: o Complete process. o Important framework activity. o Task within the framework activity. Let us have a look at the template of a process pattern given in Table 2.1.

Table 2.1: Process Pattern Template Pattern name Intent Type Initial context Problem Solution Resulting context Known uses Table 2.1 gives us a brief idea about a process pattern template that defines the following parts: Pattern name Nomenclature/naming must be done in a meaningful way and should be simple so that an individual can guess its functionality from its name. Intent The intention/purpose/need of the pattern must be described. Type It specifies the type of pattern. Initial context For a process pattern to begin, it must have true initial conditions. You must describe the following issues before the commencement of any process pattern:  The set of organisational or team-related activities that have already occurred.

Sikkim Manipal University B1965 Page No. 26 Software Engineering Unit 2

 The list of entry state processed.  Already existing software engineering or project-related information. Problem After mentioning a problem, we need to describe the pattern to solve the problem. Solution A problem, for which a pattern has been described, is always accompanied by a solution. For example, when there is insufficient information about the customer requirements, we need to get back to the customer for the relevant missing information and also must ensure that reviews are conducted, every time there is a change in requirements. This helps the development team to plan their activities before the actual start of development. Resulting context It gives detailed information about the results of a successful process pattern. You must ensure that the following information is checked when a process pattern ends.  The team-related or organisational activities that must have occurred.  Exit state for the process.  The software engineering information or project information that has been developed.

Self-Assessment Questions 4. CMM stands for ______. 5. The gap between the customer and the software company can be bridged through better ______. 6. Development of software code and testing takes place in a phase called as ______. 7. Reusability management involves providing information pertaining to the ______of the software product. 8. The term “pattern” relates to the process of solving a problem using a ______.

Sikkim Manipal University B1965 Page No. 27 Software Engineering Unit 2

2.3 Process Models We will now study the different software process models. We can define a process model as a step-by-step, systematic approach for software development. You must note that a distinct set of tasks are performed at each step to provide a high-quality software product. They are known by different names such as the generic software process model, the prescriptive process model, and so on. The process models discussed in this unit are listed below:  Linear sequential/waterfall model.  Prototype model.  V-shaped model.  Spiral model.  Iterative model.  Incremental delivery approach.  Rational unified process (RUP).

 2.3.1 Linear sequential/waterfall model This is perhaps the oldest model of the traditional process models. The basic assumption is that the development of software progresses in a sequential form, analogous to the manner in which water flows down a waterfall. One can move to the next step only when the current step is completely over. It is not possible to backtrack to the previous step. As an example from the diagram below (Figure 2.2), we cannot move backwards from the implementation to the design phase after the design phase is over. Such a model is of little practical use in today’s software environment as the requirements are no longer simple and very often the client is unable to articulate his/her full set of requirements at the very beginning of the project. However, this model still has its utility in projects that are small and the requirements are well understood in advance. An example would be developing accounting software packages, where the requirements are in general fixed over a long period of time.

Sikkim Manipal University B1965 Page No. 28 Software Engineering Unit 2

The Waterfall Model is depicted in Figure 2.2.

Fig. 2.2: Waterfall Model We will now briefly describe these steps of the waterfall model. 1. Requirements phase – In this phase, the requirements of the customer like the functionalities and the constraints are collected accurately. These requirements are analysed and checked if they can be implemented. A document known as the requirement specification document is prepared and this is used as the input to the next phase of design. 2. Design/system design – In this phase, the architectural design of the product to be developed is defined. The user interfaces and the components involved are also defined. The entire process is documented and is known as the system architecture document, which is the input to the next phase. Based on the system architecture document, the software blocks are decided. Important system states like start-up and shutdowns are considered and their behaviour is observed. The details are gathered and documented and are called the software design document. The output of this phase is a Software Design Document, which is the basis for the implementation phase. 3. Implementation-coding – On the basis of the software design document, modules are developed using codes. To start with, a small unit is developed and slowly they are integrated to form a complete module. 4. Testing – Software integration and verification: In this phase, the units that have been developed are tested for their functionality. The modules

Sikkim Manipal University B1965 Page No. 29 Software Engineering Unit 2

are checked to verify that they meet the requirement specifications. Tests are performed at the module interfaces and the internal code of the software is also tested. Finally, all the units are integrated and tested to check the performance of the entire system. Once all the units are integrated, the system is tested against the requirements given by the customer. 5. Deployment and maintenance – Operation and Maintenance: In this phase, the newly developed software is delivered to the customer and the customer would be using the software product for the first time. Therefore, the customer checks whether all the stated requirements are implemented and also validates them. When changes are observed in the system, developers fix the problem for the customer. For software projects that are large and embrace newer technologies, it is practically impossible to understand all the requirements upfront and then proceed to the other phases. In such cases, the waterfall model is woefully inadequate.

2.3.2 V-shaped model After studying the “waterfall model,” we see that the major drawback of the model is the inability to change the design whenever there is a change in the requirements, which is inevitable. So, to overcome this drawback, the V- model was developed. The steps of the V-model are similar to the waterfall model, but with a difference in the way in which the approach is made. In a waterfall model, it is a cascading/linear approach, where each activity level comes down, step by step. Whereas in the V-model, the figure looks like a “V” and the coding phase is the vertex of the figure. The biggest advantage of this model is the simultaneous development and testing methodology. Hence, it is used in most of the software companies. There is no wastage of time, as the activities of development and testing are done at the same time. The tests are derived from the design and requirements phase. Since traceability is easier, the requirements can always be traced back to the design phase to verify that the task is done correctly and meets the requirements. The operation and maintenance phase found in the waterfall model is replaced by the validation of requirements phase. Whenever there is a change in the requirements, changes could be made immediately and validated as well.

Sikkim Manipal University B1965 Page No. 30 Software Engineering Unit 2

The different phases of the V model are illustrated in the Figure 2.3.

Fig. 2.3: V-Shaped Model

2.3.3 Prototype model A software prototype is a working model/simulation of the final software product to be delivered to the customer. It works very well when the customer can explain his/her further requirements only after trying out a simplified version of the product. In this model, the customer gives a very sketchy image of his/her requirements. The developer creates a prototype on this basis. The customer then “test-drives” the prototype and gives the feedback, based on which the developer refines the prototype and adds further enhancements. This process repeats iteratively till the final product is delivered to the customer. The advantages of prototype approach are as follows:  It enables all the stakeholders (including the customer and developer) to envisage how the software would appear in terms of its interface with the end-user. The customer can check the usability and functionality and provide feedback for further development.  A prototype enables meaningful communication between the customer and the developer – the prototype helps the customer to envisage and understand his requirements better in an iterative manner.

Sikkim Manipal University B1965 Page No. 31 Software Engineering Unit 2

 Prototyping reduces software risks especially when the project is a complex one. You will learn about software risks in Unit 9. A variation to the above discussion is what is called as Quick & Dirty Protocol (QDP). In QDP, the developed prototype acts only as a guideline and cannot be iteratively evolved into the final product. It has to be discarded in the end. The final product has to be engineered from the beginning which could add to the cost of the project. 2.3.4 Spiral model The spiral model was proposed by Barry Boehm, who is widely regarded as the guru of software engineering for his pioneering efforts at trying to seek order within a chaotic software industry. This model is very simplistic and yet combines the iterative nature of the prototyping method and the sequential nature of the waterfall method. In effect, this model is a series of waterfall models following an iterative approach. The spiral model is illustrated in Figure 2.4.

Fig. 2.4: Spiral Model In this model, the software to be delivered is envisaged in the first prototype. A waterfall model is applied here and the developers go through the entire Sikkim Manipal University B1965 Page No. 32 Software Engineering Unit 2 life cycle, including analysis and design phases. At the end of the first iteration, the first version of the software is delivered and then the process repeats all over again till the second version is delivered. The new version can have added functionalities or enhancements over the earlier versions. This process can be repeated infinitely and hence, the term “spiral model” is apt for it as a spiral can also be continued infinite times. Remember that it starts at the centre and traverses in a clockwise direction. Each traversal denotes a deliverable. The iterations/repetitive traversals denote the tasks accomplished. For example, the first traversal may result in identifying the objectives and constraints and the second stage may result in identifying and resolving the risks, and so on. Finally, the last iteration will lead to the end product. As you can notice in Figure 2.4, there are four task regions in the spiral model: 1. Determine objectives. 2. Identify and resolve risks. 3. Develop and test. 4. Plan the next iteration. We can differentiate the spiral model from the other software models on the basis of its risk evaluation task. The spiral model does not have fixed phase for requirements, design and testing that are normally found in the other software models (such as V-Shaped Model). It follows a step-by-step approach, so the developers and customers interact after every step and thus risks are detected very early in this life cycle and helps in accomplishing the tasks. This model is very handy where the stakeholders are unsure about the final software solution to be developed. Both the customer and the developer can take a relook at the functionality of the software developed till date in each consecutive spiral loop. 2.3.5 Incremental delivery model In this approach, the software developer develops the required software not in a single burst but rather in a series of small increments. This methodology has certain distinct advantages, namely:

Sikkim Manipal University B1965 Page No. 33 Software Engineering Unit 2

The customer and the developer can jointly decide on which features and functionalities need to be given more priority so that the customer’s business is least affected. This would lead to creation of a sequential preference table based on which the features and functionalities would be delivered in successive increments. It enables the customer and the developer to reduce the scope to a smaller and more manageable increment which is easier to comprehend. It enables the developer to manage with lesser resources (like manpower and monetary resources) as compared to the other approaches. You may have realised by now that the incremental delivery approach to software development is all about chopping up the overall software delivery into a number of small units, which are to be delivered on a priority basis in each increment. The fundamental difference between the iterative and incremental approaches is that incremental assumes the addition of newer modules over time whereas the iterative approach successively enhances existing functionality.

2.3.6 Rational Unified Process (RUP) Rational Inc. was an object orientation company promoted by the “three Amigos of Object-Orientation” – Grady Booch, James Rumbaugh and Ivar Jacobson. This company propounded the Rational Unified Process (RUP) along with a set of tools such as Rational Rose to assist the software development life cycle (SDLC). RUP breaks down a software project into four phases – Inception, Elaboration, Construction and Transition Phase. Each of these phases is elaborated below. 6. Inception phase This phase corresponds to the planning phase in the SDLC, which constitutes around 10% of the total effort (usually stated in man-months). This phase aims at laying down the broad scope of the product being developed, develop a vision for the product, estimate the effort, estimate the resources and assess the risks. This phase comes to an end once the planning of work for the elaboration phase finishes.

Sikkim Manipal University B1965 Page No. 34 Software Engineering Unit 2

7. Elaboration phase This phase mainly elaborates the use cases. A use case is defined as a sequence of actions that an end-user and the computer must perform to fulfil a specified business task. This forms the basis for creating the Software Requirement Specifications (SRS). You will learn more about use cases and SRS in Unit 4: Software Requirements Analysis and the SRS. The software architecture is finalised in this phase which is based on the developer’s understanding of the customer requirements. This phase also includes carrying out detailed estimates and risk analysis for the project. All the tasks in this second phase constitute about 20% of the total effort of the project. 8. Construction phase The actual construction of the software occurs in this third phase. Coding and testing are the two most important activities in this phase that could take up about 60% of the total effort. The system development is by and large incremental and iterative in nature. 9. Transition phase This is the phase where the software is implemented at the customer’s premises. This phase constitutes about 10% of the total effort and includes tasks like completing the entire software, completing all the testing including the user acceptance test, completing and handing over all documentation for the user (either in hard copy or soft copy format) and making preparations for training of the end-users. The major advantages of the RUP are as follows:  RUP acknowledges the reality of changing requirements  RUP advocates splitting the project into smaller components. Hence, the developers can focus early on the high-risk components, which lead to early solution to problems whenever a risk becomes a reality.  RUP permits the developers to build up the software gradually in an incremental fashion by allowing them to do planning, designing and coding in small bursts.

Sikkim Manipal University B1965 Page No. 35 Software Engineering Unit 2

 RUP promotes team integration by allowing all stakeholders to get involved in the project in the initial stages itself.  RUP enables the software to progress over time, as opposed to the “big bang approach” where the risk of total system failure is high. 2.3.7 Summary of the major process models A brief summary of the strengths and weaknesses of important process models discussed above is depicted in Table 2.2.

Table 2.2: Strengths and Weaknesses of Important Process Models Applicable types of Model Strengths Weaknesses projects Waterfall  Simple  All or nothing—  Well-understood model  Easy to execute too risky problems,  Intuitive and logical  Requirements  Short duration frozen early projects,  Easy contractually  May choose  Automation of

outdated existing manual hardware/tech systems  Disallows changes  No feedback from users  Encourages requirements bloating Prototyping  Helps requirements  Possibly higher  Systems with novice model elicitation cost and users; or areas with  Reduces risk schedule requirements uncertainty.  Better and more  Encourages stable final system requirements  Heavy reporting bloating based systems can  Disallows later benefit from User- change Interface prototyping Spiral model  Regular deliveries,  Overhead of  For businesses leading to business planning each where time is benefit iteration important; risk of  Can accommodate  Total cost may long projects cannot changes naturally increase be taken;  Allows user  System  Requirements not feedback architecture and known and evolve design may with time  Avoids requirements suffer Sikkim Manipal University B1965 Page No. 36 Software Engineering Unit 2

bloating  Rework may  Naturally prioritises increase requirements  Allows reasonable exit points  Reduces risks Rational  All benefits of  For each project,  Can be applied to a unified iterative one has to wide range of process design the projects as it allows (RUP)  Provides a flexible framework for a process flexibility range of projects

Self-Assessment Questions 9. The four phases of the RUP are inception, elaboration, communication, and ______. 10. For a “library management software,” where the requirements are well understood and are unlikely to change, the ______model is well applicable 11. The “V-Shaped Model” is a rectification of flaws in the “Spiral Model.” (True or False) 12. The founders of Rational Inc., the founders of the RUP, were collectively referred to as “the three ______.”

Activity 2: Compare and contrast the “waterfall model” and the “spiral model.” Can you find any similarity between the two models? Can you say that the introduction of “Windows Operating System” at different points in time (like Windows 95, Windows 98, Windows XP, Windows Vista and Windows 7) is an example of the spiral model? Justify your answer. (Hint: Refer to Section 2.3.)

2.4 Using Process Models in Software Projects Till now we have studied several development process models. An important question that arises is that why do we need to have different models like these? Remember, while developing software, the goal is not only to develop software that fulfils the customer requirements but also to

Sikkim Manipal University B1965 Page No. 37 Software Engineering Unit 2 perform the development within estimated budget and committed time. Additionally, there could be other restraints in a project that we may need to address. In a scenario like this, it is important to choose a development model that would enable us to deliver high-quality software. Let us consider a couple of examples to illustrate this point.

Example 1: Assume that a software company has been awarded the contract for developing a web portal for a confectionery shop. The personnel at the confectionery shop have agreed to spend a great deal of time at the beginning of the project during the phase of requirements gathering and analysis but they are clear that later on their availability for discussions will be highly restricted and not guaranteed. The total time allotted for the project is 6 months with no chance of negotiation for deadline extension. It may be noted that some features of the web portal are absolutely necessary, whereas there are some features that are desirable but not essential to run the portal. Probably these could be accommodated in later iterations/increments. Keeping the above constraints in mind, we can easily rule out the waterfall model as the “all-or-nothing” risk that it brings along is not acceptable due to the non-extensible deadline. The iterative model is not applicable here as the customer will not be available later on for discussions and finalisation of requirements that will be filled in later. Incremental model is apt here where the requirements can be frozen early on and the features and functionalities can be prioritised in each incremental development. The RUP model that allows phase-wise iterations can also be considered for this project.

Example 2: Assume that a 40-year-old grocery store in your neighbourhood wishes to get custom-built accounting software developed. In such a project, the waterfall model would be ideal as the requirements are well understood due to the experience in years of having handled the same accounting function in a paper-and-pencil mode. Besides, the basic accounting principles do not change and hence, there is no risk of major requirement changes during the tenure of the project, which suits the waterfall model well.

Sikkim Manipal University B1965 Page No. 38 Software Engineering Unit 2

Self-Assessment Questions 13. An accounting software package, where the requirements are well understood and are unlikely to change can be developed using the ______model. 14. It is important to choose a development model that that would enable us to deliver ______software. 15. The RUP Model allows ______iterations.

Activity 3: Assume that you are working for a software company. Your company has been assigned the task of carrying out THREE software projects, namely: 1) A “Library Automation Software” for Sikkim Manipal University where the requirements have to be jointly finalised by your company and the University. 2) A “Management Information System Software” for a medical store, where the requirements are frozen in advance and there won’t be any more additional requirements 3) An “Inventory Management Software” for a retail chain where the customer would like to be closely involved with the development process as he is not very clear about his requirements. For each of the above three projects you have to decide on the software process model to be applied. Which model will you apply in each case? Justify your answers. (Hint: Refer to Section 2.3.)

2.5 Summary Let us recapitulate the important concepts discussed in this unit:  Software as a process is extremely important. Various process models, called as “traditional process models,” have been adopted over the last few decades in order to bring standardisation and order into the software process, which would otherwise have become quite chaotic. These include waterfall model, V-shaped model, spiral model, RUP, etc. A newer developmental paradigm called “Agile Methodology” is now becoming popular in the software world.

Sikkim Manipal University B1965 Page No. 39 Software Engineering Unit 2

 A process is the collection of tasks that are done in some pre-defined order so that we can achieve the desired outcomes. A development process model is a general process specification that best fits the situation under consideration.  The waterfall model is the oldest and the simplest of all the process models where all the steps are performed in sequence. It is suitable only for those kinds of problems where the requirements are very well understood right at the beginning of the project. The V-shaped model was added later to correct certain shortcomings in the waterfall model.  In the prototyping approach, a simple working model of the final software, called prototype is created that precedes the actual software. This is used to develop the requirements on a clearer understanding of the project by the customer. Such an approach suits those kinds of projects where all the requirements cannot be specified by the customer upfront.  The spiral model is actually a series of “waterfalls” in an incremental delivery mode.  One of the newer paradigms is the Rational Unified Process (RUP) where there are four phases – inception, elaboration, communication and transition.

2.6 Glossary Artefact: An object processed by a computer and is owned by the software system. Examples of artefacts are documents (e.g. training manuals), lines of code in the program, etc. CMM (Capability maturity model): The Capability Maturity Model (CMM) is a methodology used to develop and refine an organisation's software development process. SDLC (Software development life cycle): A framework that for the activities performed at each phase of a software development project.

2.7 Terminal Questions 1. Explain why the “waterfall model” has very less utility in the modern world.

Sikkim Manipal University B1965 Page No. 40 Software Engineering Unit 2

2. Provide three examples of projects that can be developed on the “prototyping model approach.” 3. Explain the concept of “software project life cycle” with a suitable example. 4. Explain how the “V-shaped model” is an enhancement of the waterfall model. 5. Explain the four phases of the RUP.

2.8 Answers Self-Assessment Questions 1. False 2. Step-by-step 3. Telecom billing solutions 4. Capability Maturity Model 5. Communication 6. Construction 7. Reuse 8. Template 9. Transition 10. Waterfall 11. False 12. Amigos 13. Waterfall 14. High-quality 15. Phase-wise

Terminal Questions 1. (Refer to Section 2.3.1 for further information.) 2. (Refer to Section 2.3.3 for further information.) 3. (Refer to Section 2.2 for further information.) 4. (Refer to Section 2.3.2 for further information.) 5. (Refer to Section 2.3.7 for further information.)

Sikkim Manipal University B1965 Page No. 41 Software Engineering Unit 2

2.9 Case Study Client Background Arun Kumar founded the Signals and Systems in the year 2007. Signals and Systems is a subsidiary of Cable and Network Signals. The Cable and Networks Signals is owned by Yash Singhania. It is one of the leading companies in Telecommunication equipments, embedded software systems, medical equipments and computer networks holding operations in many other countries. Business Need Signals and Systems was planning to adopt the software engineering practices to ensure continuous improvement and wanted to get a Capability Maturity Model Integration (CMMI) certification for its company, since obtaining a CMMI certification is considered as a benchmark standard. To achieve this, a lot of documentation and knowledge of tools were required. Therefore, the company required a mentor who was specialised and had the potential to train. Also software engineering practices were to be implemented. Cable and Networks Signals Solution Implementation A formal training was given to the employees in the company with regard to software testing concepts and techniques, object-oriented analysis and design and configuration management along with the usage of several tools related to software testing. Process models were introduced to have a systematic approach. Benefits CMMI level 3 was achieved, which included the following:  A well-defined and documented standard process was established.  Improvements were observed over a period of time.  Consistent process performance was established in the organisation.  The employees in the organisation became confident and well-versed in using the tools and also solved problems using the correct process model.

Sikkim Manipal University B1965 Page No. 42 Software Engineering Unit 2

Discussion Question: 1. Discuss how the company followed a systematic approach in attaining CMMI Level 3.

References/E-References:

References:  Aggarwal, K. K (2007), Software Engineering. New age International publishers,  Pankaj Jalote. (2010). Software Engineering – A Precise Approach. Daryaganj, New Delhi : Wiley-India  Roger S Pressman. (2010). Software Engineering – A Practitioner Approach. McGraw-Hill Higher Education.  A. A. Puntambekar. (2007). Software Engineering. Pune: Technical Publications

E-References:  www.ibm.com/software/awdtools/rup/. (Retrieved on 8th May 2012.)

Sikkim Manipal University B1965 Page No. 43 Software Engineering Unit 3

Unit 3 Agile Development Methodology Structure: 3.1 Introduction to the Agility Concept Objectives 3.2 Agile Development: The Manifesto The agile process Cost of change vis-à-vis traditional models Extreme programming (XP) and agile processes XP: In Summary 3.3 Other Agile Processes 3.4 Summary 3.5 Glossary 3.6 Terminal Questions 3.7 Answers 3.8 Case Study

3.1 Introduction to the Agility Concept By now, we are familiar with several process models that have been in use since the last few decades. However, the traditional models have not proved to be entirely foolproof! They have been often described as “highly bureaucratic” that has led to slowdown of several projects. This in turn has led to time and cost overrun of several projects. Since the 1990s, software researchers and practitioners have been working on an entirely different paradigm called as “agility.” Ivar Jacobson, one of the “three amigos” of object-orientation philosophy, has explained agility in his own words as follows: “Agility has become today’s buzzword when describing a modern software process. Everyone is agile. An agile team is a nimble team able to appropriately respond to changes. Changes are what software development is very much about. Changes in the software being built, changes to team members, changes because of new technology, changes of all kinds that may have an impact on the product they build or the project that creates the product. Support for changes should be built-in everything we do in software, something we embrace because it is the heart and soul of software. An agile team recognizes that software is developed by individuals working in teams and that the skills of these people, their ability to collaborate is at the core for the success of the project.”

Sikkim Manipal University B1965 Page No. 44 Software Engineering Unit 3

We can subject any software process to the philosophy of “agility.” The only precondition for achieving is that we need to plan the process in such a manner that would facilitate the software development team to alter the work flow and keep them simple and lean enough, adopt a planning paradigm that encourages the flexible nature of an agile development approach and adopt a strategy of delivering software to the customer in an incremental fashion, wherein each delivery will have new enhancements/ functionalities or modifications to the previous delivery. This way we can ensure that the software gets “live” at the customer end more quickly than what would have been possible in the traditional process methodologies. Objectives: After studying this unit, you should be able to:  Explain “agility” as the latest methodology for software development  differentiate between traditional software process models and agile models  explain why the software fraternity adopted the “agility” philosophy  elucidate some of the important models of “agile development”

3.2 Agile Development: The Manifesto Let us start this unit with a brief historical background that will set the tone for the next set of discussions. In 2001, Kent Beck and 16 other noted software developers, writers and consultants (referred to as the “Agile Alliance”) signed the “Manifesto for Agile Software Development.” It stated: “We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:  Individuals and interactions over processes and tools  Working software over comprehensive documentation  Customer collaboration over contract negotiation  Responding to change over following a plan  That is, while there is value in the items on the right, we value the items on the left more.” 3.2.1 The agile process Let us now study a bit more about the salient features of the agile process.

Sikkim Manipal University B1965 Page No. 45 Software Engineering Unit 3

An agile process is guided by scenarios (customer portrayal of the requirements in story-board format), acknowledges that plans are not frozen permanently and can be changed as and when required, builds software on an iteration-basis and delivers the final software over several “software incremental deliveries,” and adjusts to the changes that is bound to happen during the entire duration of the project. As mentioned earlier, agile approaches developed in the 1990s as a reaction to document-driven approaches that were sometimes highly bureaucratic. Most agile approaches have some common principles.  Working software is used as yardstick for measuring the progress of software development.  The final software need to be delivered in multiple increments, with each increment quite small.  The planning should be so adaptive that even changes desired during the late stage of the project should also be accommodated.  Prefer face-to-face communications as opposed to relying mostly on documentation.  Continuous response and continuous customer commitment and enthusiasm are essential for an agile project’s success.  Prefer simple design that evolves over time.  The software development team is authorised to determine the software delivery dates. This is contrary to traditional methods, where typically a top-management person may decide on the delivery dates and the software development team have to then abide.  Thus, we can generalise and say that it is practically impossible to predict in advance from a planning viewpoint all the aspects of analysis, design, construction and testing.  You may have realised by now that we are talking of a process that can manage unpredictability! We can achieve this only by being adaptable, and that too incrementally, rather than being firm. Customer feedback is essential in the agile process as also using an operational prototype that will be iteratively developed. 3.2.2 Cost of change vis-à-vis traditional models In traditional software developmental models, it has been observed that the cost of change does not increase in a straight line pattern but rather in a

Sikkim Manipal University B1965 Page No. 46 Software Engineering Unit 3 non-linear fashion. The cost of change is minimal at the requirements gathering stage and it is comparatively easier to accommodate a change here as it is in the early stage of the project. However, as we move towards the latter phases of the project we observe that the cost of change becomes very high. Proponents of the agile method have established that a well-designed agile process can reduce the overall cost of change even in the later phases of the project without significantly impacting cost and time. 3.2.3 Extreme programming (XP) and agile processes Several agile methodologies have been introduced, some of which have become very popular. Out of all these methodologies, Extreme Programming (XP) is regarded as the most prevalent. Similar to other agile approaches, it accepts the fact that changes will happen in the requirements. Consequently, XP advocates that instead of belittling changes as unwanted elements, the development ideology should be evolved around the fact that changes are inevitable. Thus, the development methodology needs to be flexible with the ability to respond quickly to changes. Therefore, this method is based on development of software iteratively, and sidesteps the problem of having to rely on comprehensive and numerous documentation that are sometimes difficult to sustain and maintain. This method encourages people-to-people communication to make sure that the required changes are incorporated into the programs. We will now briefly discuss the development process of XP which is by and large a very good representation of a typical agile process. The following points discuss the XP Planning in a nutshell:  Commences with the business analyst constructing “user stories” in consultation with the customer.  The agile team members analyse each user story and estimate a cost to it.  Next, the user stories are clustered together for the first and subsequent incremental deliveries.  The agile team estimates the effort and sets the deadline for the “incremental delivery.”

Sikkim Manipal University B1965 Page No. 47 Software Engineering Unit 3

 Post-delivery of the first increment, estimates are worked out and accordingly for other incremental deliveries, the delivery dates are committed.  An XP project commences with “user stories” that are brief explanations of the “scenarios,” which the customers and end-users want the software to take care. This form is quite unlike the conventional requirement specifications (explained later) mainly in explanation of the details – the user stories exclude thorough elaboration of the requirements. Such detailing happens only at the time of construction, thereby granting more time to the users for eliciting their requirements.  The authorised development team then makes an approximate calculation of the time required to develop the user story into a software increment. The estimates are expressed in weeks and are often approximate figures that are imprecise. Once these estimates are ready along with the user stories, the next step is to conduct release planning, a step that finalises which of the user stories are to be incorporated in which incremental delivery, and also delivery dates for each of these deliveries. A series of frequent, small deliveries are preferred. The user stories are also used to create the acceptance tests. Each incremental delivery has to pass the acceptance test before final delivery to the customer. The overall process is shown in Figure 3.1.

Fig. 3.1: The Overall Agile Process

Development takes place in a series of iterations where each iteration lasts for about a few weeks. The first step in “iteration” is what is called as “iteration planning” where we select the user stories to be incorporated in that particular iteration. You should remember that those user stories that are considered by the customer as having high-value and therefore, high- risk are given more importance and incorporated during the initial iterations. There is always a possibility that in previous iterations there could have been failed acceptance tests. Such failures are appropriately handled in

Sikkim Manipal University B1965 Page No. 48 Software Engineering Unit 3 subsequent iterations. The nitty-gritty details of the user stories are collected and analysed during the iteration for developing the incremental delivery of the software. The developmental method adopted in the iterations follows certain distinctive methods. First, development is taken up by pairs of programmers (i.e. two programmers would be jointly developing code), instead of individual programmers which is a very unique way of handling the software project. Second, it encourages a “reverse methodology” wherein automated unit tests are designed first even before writing the actual code. The actual program that is written later should clear the first-written unit tests. This methodology is called as “test-driven development.” As more and more functionality gets added to the unit, the unit tests are also scaled up to accommodate the new functionalities. After this step, the code is modified so as to be able to clear the newly created unit tests. Third, because of the inevitable changes, it is probable that the design developed earlier may become inappropriate for further stages in the development. XP takes care of this problem by encouraging a step called as “refactoring.” Refactoring is employed to modify the design, after which the refactored program is considered for the next level of development. While refactoring, only the existing functionalities are considered and no new functionality is added. The reason for this is that the design of the program under refactoring will be greatly enhanced. The discussion so far has provided us with a bird’s eye view of extreme programming. Other rules for XP have also been framed that consider matters like software developers and customer’s rights during the execution of the project, interpersonal interactions among members of the team, protocols for conducting meetings, etc. The agile methods, including extreme programming, are appropriate only for projects where the probability of frequent requirements change is very high, leading to substantial requirements risks. Since such methods rely heavily on continuous interactions among the team members, it is useful when teams are preferably collocated and has relatively lesser number of developers. Another point to be considered is that as agile methods encourage continuous participation of the customer in the project for deciding on important milestones, it is imperative that the customer should

Sikkim Manipal University B1965 Page No. 49 Software Engineering Unit 3 be made aware of the fact he must be willing to work as a pseudo-team member and get involved at all stages of the project. Only then will the agile methods be successful. 3.2.4 XP: In Summary

Strength Weakness Types of projects

 Agile and  Can tend to become  Where responsive ad hoc requirements  Short delivery  Lack of documentation are changing cycles can be an issue a lot, customer  Continuous  Continuous code is deeply feedback can change is risky engaged in lead to better development, acceptance and where the size of the project is not too large

Self-Assessment Questions 1. In the spiral model, as we move from one phase to the other the cost of change increases in a non-linear fashion. (True/False) 2. Agile process helps to manage certainty in a software project. (True/False) 3. Which of the following models allow changes in later stages of the software project - spiral, incremental, waterfall, agile? 4. XP commences with creation of ______stories. 5. Which of the following process models would be most appropriate in a situation where there the “requirements risk” is low – spiral model/XP? 6. Agile methodology tends to give little or no importance to project documentation. (True/ False) 7. The practice of using two programmers for jointly developing the code is called as ______. 8. During “refactoring” new functionalities are added. (True/False)

Sikkim Manipal University B1965 Page No. 50 Software Engineering Unit 3

Activity 1: Imagine yourself as a project manager in a software company. Describe how you would explain the concept of “agile development” to your team. You will also need to explain to them how and why such an approach is different from the other traditional approaches. (Hint: Try to explain the differences by taking up a real-life situation.)

3.3 Other Agile Processes We will now discuss very briefly about some of the other important agile processes that are in existence. The processes that will be touched upon in this section are the following:  Adaptive Software Development (ASD)  Dynamic Systems Development Method (DSDM)  Scrum  Crystal  Feature-Driven Development Adaptive Software Development (ASD) This method was originally proposed by Jim Highsmith. Some of the distinctive features of the ASD are its mission-driven planning aspect, component-based focus that helps in reusability and profuse use of time- boxing (a time management technique common in software planning where the complete schedule is broken up into individual units referred to as “time- boxes” where each time-box has its own set of outputs, milestones and budget). The other distinguishing features of the ASD include comprehensive risk consideration and stresses on collaboration for understanding requirements better. It also advocates that “continuous learning” must happen throughout the project that can be used in future projects to minimise risks. Dynamic Systems Development Method (DSDM) The DSDM methodology was promoted by the DSDM Consortium, created in 1994 by a group of software engineering practitioners and software vendors. The most important distinctive feature of DSDM is that it has nine guiding principles, namely:  Active user involvement is imperative.  DSDM teams must be empowered to make decisions. Sikkim Manipal University B1965 Page No. 51 Software Engineering Unit 3

 The focus is on frequent delivery of products.  Fitness for business purpose is the essential criterion for acceptance of deliverables.  Iterative and incremental development is necessary to converge on an accurate business solution.  All changes during development are reversible.  Requirements are baselined at a high level.  Testing is integrated throughout the life cycle.  Communication and cooperation among all project stakeholders is required to be efficient and effective. Scrum This is another popular agile methodology followed in the industry, originally proposed by Schwaber and Beedle. The name “scrum” has been borrowed from an activity in the game of rugby. Some of the distinctive features of the scrum method are as follows: The entire work is compartmentalised into “packets.” Testing and documentation are simultaneous activities during the entire phase of software development. The development is taken up in “sprints” and the work to be done is extracted from an accumulation of requirements to be fulfilled. Very short duration meetings are conducted and sometimes in standing position without the use of even chairs and tables. Using the allotted time-box, “simulations” of the software are released to the customer. Crystal This methodology was originally propounded by Cockburn and Highsmith. Two of the distinctive features of this methodology are that there is a provision of “manoeuvrability” based on problem characteristics and that it emphasizes face-to-face communication. Feature-Driven Development (FDD) The FDD methodology was originally propounded by Peter Coad and others. Two of the distinctive features of FDD are that the stress is on defining “features” (a function that is valued by a customer and can be

Sikkim Manipal University B1965 Page No. 52 Software Engineering Unit 3 delivered in maximum 2 weeks) and that the design and construction phases merge in FDD unlike other methodologies. Self-Assessment Questions 9. Which agile method gets its name from an act in the game of rugby? 10. DSDM stand for ______11. Which of the following agile method suggests profuse use of the concept of “time-boxing” a. dynamic systems development method b. adaptive software development method c. scrum method d. Feature driven development method

3.4 Summary Let us recapitulate the important concepts discussed in this unit:  This unit introduced us to the latest methodology of software development called “agile methods.” We understood why it became necessary for software developers to adopt such an approach which apparently goes against the philosophy of the traditional models that stressed on documentations and other activities which often became bureaucratic and slowed down the work. Agile methods tend to simplify the process and also improve communication between the software developers and the customers, deliver quick outputs and improve the overall effectiveness of the development methodology.  While studying this unit, we also learnt about the important agile methods such as XP, Scrum, DSDM, ASD, FDD and Crystal.

3.5 Glossary Pair programming: Pair programming is a concept in extreme programming where two software developers work together at a single workstation. The developer who writes the code is called as the “driver” whereas the other developer is called as the “navigator.” The “navigator” checks each line of code as it is created by the “driver.” The two developers swap their roles quite frequently.

Sikkim Manipal University B1965 Page No. 53 Software Engineering Unit 3

User stories: User stories, an integral part of “extreme programming” are used to envisage the functionalities that a business system must provide, and to help in understanding customer requirements better.

3.6 Terminal Questions 1. Explain how the philosophy of the “agile software development method” is different from that of the “traditional software development methods.” 2. There is a belief that – “Since ‘agile methods’ attach little importance to documentation there is always a risk that the process followed for software development will be of low quality.” Do you agree with this statement? Justify your answer. 3. Explain three distinctive features of the agile process, as compared to traditional methods. 4. Write short notes on the “Scrum” and “DSDM” approaches to “Agile Development.”

3.7 Answers Self-Assessment Questions 1. True 2. False 3. Agile 4. User 5. Spiral Model 6. True 7. Pair Programming 8. False 9. Scrum 10. Dynamic Systems Development Method 11. b. Adaptive Software Development Terminal Questions 1. (Refer to Section 3.1 for further information.) 2. (Refer to Section 3.2 for further information.) 3. (Refer to Section 3.2 for further information.) 4. (Refer to Section 3.3 for further information.)

Sikkim Manipal University B1965 Page No. 54 Software Engineering Unit 3

3.8 Case Study A Dilemma – Which Process Model to Use? (Part 2) Let us once again consider the case study given in Unit 2. Assume that you are working for a software company. Your company has been assigned the task of carrying out THREE software projects, namely: 1. A “Library Automation Software” for Sikkim Manipal University where the requirements have to be jointly finalised by your company and the University. 2. A “Management Information System Software” for a medical store, where the requirements are frozen in advance and there won’t be any more additional requirements 3. An “Inventory Management Software” for a retail chain where the customer would like to be closely involved with the development process as he is not very clear about his requirements. Discussion Question: 1. Assume that in Unit 2, for each of the above three projects you had decided on the software process model to be applied. Your project manager analyses the projects and concludes that the “Extreme Programming” approach would be suitable for all the above three projects. Do you agree with his conclusion? Justify your answers.

References/E-References: References:  Jalote, P, Software Engineering – A Precise Approach, Wiley India Pvt Ltd, 2010  Pressman, Roger S. Software Engineering: A Practitioner’s Approach. McGraw-hill Higher Education, 2010

E-References:  www.agilemanifesto.org (Retrieved on 30th April 2012)  www.agilemethodology.org (Retrieved on 30th April 2012)

Sikkim Manipal University B1965 Page No. 55 Software Engineering Unit 4

Unit 4 Software Requirements Analysis and the SRS Structure: 4.1 Introduction Objectives 4.2 Requirements Engineering 4.3 Software Requirements Specification (SRS) Need and importance of the SRS Roadmap to developing an SRS Required characteristics of a good SRS General layout and structure of a standard SRS 4.4 Use Case-Based Software Requirements Fundamental concepts in use case methodology An example of a detailed use case Developing use cases 4.5 Summary 4.6 Glossary 4.7 Terminal Questions 4.8 Answers 4.9 Case Study

4.1 Introduction A lot has been written about creating correct software systems that work exactly as per the customer requirements. However, this is possible only if the developer knows exactly what the customer needs and what the software must do. Hence, a very important first step in building correct software is to clearly define what the software must do. Identifying correct and detailed user requirements is becoming even more important as the world is moving towards more complex software systems with each passing day. In the software engineering context, requirements are used to create the specification (in software parlance this is called as a “software requirements specification (SRS)” that serves as the basis of contract between the developer and the customer). Obviously, only when these requirements are clearly specified in advance can we validate the developed software against these requirements. In other words, keeping the SRS as a guidebook, it becomes possible for every stakeholder to satisfy themselves whether or Sikkim Manipal University B1965 Page No. 56 Software Engineering Unit 4 not the delivered software has satisfied all the requirements. The goal, which is still proving to be extremely difficult to satisfy in totality, is to develop such precise specifications for software requirements so that the customer can precisely state what he requires and then validate the delivered software. Objectives: After studying this unit, you should be able to:  describe the importance of requirements engineering in the software development process  elaborate how requirements are elicited from customers  explain the importance of the SRS  elucidate “use case methodology” as the latest technique for specifying functionalities

4.2 Requirements Engineering Let us start our discussion by introducing you to the concept of “requirements engineering.” We will first try to understand the exact meaning of “requirement” as defined by IEEE. It is defined as (a) a condition of capability needed by a user to solve a problem or achieve an objective; (b) a condition or a capability that must be met or possessed by a system – to satisfy a contract, standard, specification or other formally imposed document. Remember that in requirements management we are aiming to detail out the requirements and/or capabilities that a proposed software system has to deliver. We discussed about several traditional process models and the agile model in Units 2 and 3, respectively. All these models have this commonality that the requirements have to be specified upfront. The only difference here is that in case of agile models, detailed requirements are not required in the beginning to start the project. As the project progresses, the requirements are elicited by continuous interaction with the customer. Most of the traditional approaches advocate the need for specifying requirements precisely before the actual development work starts. After understanding the concept of “requirement,” let us now try to understand the concept of “requirements engineering.” Requirements engineering can be defined as the act of understanding, structuring and

Sikkim Manipal University B1965 Page No. 57 Software Engineering Unit 4 accurately depicting the user’s requirements so that it can be correctly built into the software systems that meet those requirements. Requirements engineering is a very important element of the software engineering process. Broadly, the entire activity of requirements engineering can be split into six distinct steps, namely: 1. Plan the requirements engineering activities 2. Freeze the scope of the requirements 3. Extract requirements from the users 4. Analyse the requirements in terms of feasibility, and so on 5. Document the requirements 6. Verify requirements and seek user approval and obligation to the documented requirements, as this forms the basis of contract For the sake of brevity, we can consider the requirements engineering process as consisting of three generic tasks – requirements analysis, requirements specification and requirements validation. Requirements analysis – Usually starts with a high-level “problem statement,” that is, an expression of what the client is looking for as a software-based solution to his problem. Remember that in this context, “problem” need not be a problem at all; we can also consider requirements for business enhancements, better output, and so on as a part of the problem description. During the analysis phase, the problem domain and the environment are simulated in order to understand the system behaviour, constraints on the system, its inputs and outputs, and so on. The fundamental purpose of this activity is to obtain a thorough understanding of what the software needs to provide. Frequently, during analysis, the analyst will have a series of meetings and interactions with the clients and stakeholders. Through these interactions and scrutiny of documents pertaining to the existing system, the analyst starts creating a picture of the required system. The analyst’s understanding at each step is cross-verified with the client and the end-users to reduce “impedance mismatch” so that the analyst can be reasonably sure that he has understood the requirement explained by the end-user clearly. The process of requirements analysis ends when the analyst believes that all the requirements have been understood by him.

Sikkim Manipal University B1965 Page No. 58 Software Engineering Unit 4

Requirements specification – The next logical step in requirements engineering, is formulated on the basis of the understanding obtained in the previous phase of requirements analysis. Here the main focus is on specifying the requirements in unambiguous terms. Another important focus of this phase is to extract only those nuggets of useful information that need to be addressed in the project. Usually the previous step leads to a lot of “information overload” and filtering out the redundant information becomes very important. Requirements validation – This process ensures that all the agreed-upon client requirements have been included in the SRS. It also ensures that the SRS is of high quality and conforms to the standard format. The requirements engineering phase ends with the creation of a document called software requirements specification (SRS). SRS illustrates only what the proposed software should do. The implementation details of how it will be done are not included in the SRS. The SRS can be considered as a document that bridges the business analysis team with the technical team that has to finally develop the software. Methods for eliciting and gathering requirements Remember that defining user requirements involves understanding how an existing system works and the problems that come associated with it. In this section, we will examine some methods for collecting information in order to develop such an understanding. There are several important issues to consider in getting a holistic and clear picture of a system. One is to look at the existing business processes in the system and uncover the tasks in those processes. One can also start by probing specific system functions and their tasks, which can then be examined in detail. Such examination can reveal the users, who carry out the tasks, the interactions between the users, the tools they use and the artefacts on which they operate. Thus, an analyst must always take into account the users and their roles. How do the users apply the artefacts? With whom do they interact? Where do they find information? This has a significant influence on the way the system works. Remember also that there is no such thing as a standard system as every organisation is different and the manner in which work is done will vary from one organisation to another. It is advisable, therefore, not to have

Sikkim Manipal University B1965 Page No. 59 Software Engineering Unit 4 preconceived ideas about a system and analysts must approach any study with an open mind. There are four main ways of doing this, namely:  By asking questions – By interviewing people in the system, through surveys and questionnaires or by electronic means using e-mail or a discussion board;  By observational studies – By participating within the user environment and ensuring that the analyst is also part of the typical work life till the requirements engineering phase is over;  By prototyping – In this case, we can prototype either the requirements or the user interface; and  By formal sessions – This includes structured workshops, group discussions and facilitated teams. Self Assessment Questions 1. Which of the following process models does not require detailed requirements to be specified at the beginning of the project – waterfall model or agile model? 2. Requirements engineering consists of three generic tasks – requirements analysis, requirements ______and requirements validation. 3. The requirements engineering phase ends with the creation of a document called SRS. What does SRS stand for? 4. SRS bridges the ______team with the technical team.

4.3 Software Requirements Specification (SRS) As explained earlier, a software requirements specification (SRS) is a comprehensive description of the intended purpose and environment for software under development. We shall study SRS in more detail in this section. We begin by discussing the need and importance of the SRS. 4.3.1 Need and importance of the SRS Typically, there are three sets of stakeholders in any software project: the client (usually considered as the top management), the end-users (employees of the client who will work hands-on on the software) and the software developers. The needs are specified by the client, the software is developed by the developers and the system is directly used by the end-

Sikkim Manipal University B1965 Page No. 60 Software Engineering Unit 4 user. Thus, we see that there is a clear disconnect between who requires what and who develops it for them. This happens mainly because of a major communication error – usually the client does not understand software and the software developers do not understand the business domain! The fundamental need for the SRS is to bridge the communication gap so that the client and the developer together have a joint and a shared vision of the software proposed to be built. The importance of the SRS can be gauged from the points given below (extracted from IEEE 830 Standard):  SRS establishes the basis of agreement between the user and the software developer. o User needs have to be satisfied, but most probably the user may not understand software. o Developers will develop the system, but most probably may not be an expert on the problem domain. o Thus, SRS becomes the medium to bridge the communication gap and specify user needs in a way in which both parties can understand.  SRS provides clarity to the user regarding his own requirements. o Typically, users do not always know their requirements. o The requirements engineering process helps clarify needs.  SRS provides a reference for validation of the final product after it is delivered. o SRS provides an unambiguous understanding about what to expect from the delivered software. o SRS also helps in validating the delivered software by checking whether the software satisfies the SRS.  High-quality SRS is essential for high-quality software. o Requirement errors become apparent in the delivered software. o A high-quality SRS will ensure that requirement errors are weeded out before the development work starts. This will automatically lead to a high-quality software.

Sikkim Manipal University B1965 Page No. 61 Software Engineering Unit 4

 High-quality SRS reduces the development time and cost by guarding against unnecessary rework that may have to be done at a later stage in the project. 4.3.2 Roadmap to developing an SRS Figure 4.1 shows the general process that is followed for developing a typical SRS.

End-user Business Requirements Domain

Requirements

Vision Document

Non-functional Functional Requirements Requirements

SRS

Fig. 4.1: General Process Followed for Developing SRS In a nutshell, the general process is as follows: The understanding of the business domain requirements coupled with the user requirements leads the business analyst (who is an integral part of the software development team) to create a vision document. A vision document is a summary document created by a team in the early days of a project to build the case for doing the project; agree upon the general scope and requirements at a general from a customer’s viewpoint and obtain team alliance and seek their agreement on the project definition. It serves as a base document for further work on the project. This vision document sets the tone for defining the functional and non-functional requirements that the software has to deliver. An example of a functional requirement would be “creating the balance sheet” and an example of a non-functional requirement would be “voice- based interactivity” in the software.

Sikkim Manipal University B1965 Page No. 62 Software Engineering Unit 4

These functional and non-functional requirements are what constitute a major portion of the SRS. It has become a common practice in the recent past to use “use case–based specifications” in the SRS, about which we will study in Section 4.4. 4.3.3 Required characteristics of a good SRS The IEEE standard specifies that the desirable characteristics of a good SRS are as follows: a) Correctness b) Unambiguous c) Completeness d) Consistency e) Ranked for importance and/or stability f) Verifiability These characteristics are explained briefly in the following paragraphs.  Correctness – The SRS exhibits correctness only if every requirement contained in the SRS portrays something required in the final software to be delivered.  Unambiguous – The SRS will be treated as unambiguous if, and only if, every requirement stated therein can be interpreted in only one possible manner. This is a major practical difficulty faced by software practitioners as most of the words and sentences written in English are susceptible to multiple interpretations that can cause major discord between the customer and the development team.  Completeness – The SRS exhibits completeness if everything the software is supposed to do is specified in the SRS. A simple way of checking this is to ascertain whether the contents of the SRS are sufficient for the software designers to create the software.  Consistency – The SRS exhibits consistency if there is no requirement that contradicts another requirement. This is a common problem that developers face.  Ranked for importance – Very often a proposed new system has requirements that are more of wish lists than having any practical value. Some may not be achievable. It is useful to provide this information in the SRS that will help the developers to prioritise the work based on providing the most important functionalities first.

Sikkim Manipal University B1965 Page No. 63 Software Engineering Unit 4

 Verifiability – The SRS exhibits verifiability if, and only if, every stated requirement is verifiable. As an example, it is useless to put in requirements like: “It should provide the user a fast response” and “The system should never crash.” Instead, it would make sense to provide a quantitative requirement like: “Every key tap should provide a user response within 10 milliseconds.” 4.3.4 General layout and structure of a standard SRS In general, a typical SRS must specify requirements on the following:  Functionality  Performance  Design Constraints  Interfaces The above points are briefly explained below:  Functionality – This constitutes the core of the SRS document and forms the bulk of the specifications. All the functionalities that the system should support are specified. All “data/information outputs” for given “inputs” and their relationship thereof are also specified. Furthermore, all the operations the new system is expected to do are also to be specified in the SRS. The behaviour for invalid inputs to the system is also specified.  Performance – This portion of the SRS deals with performance issues of the software. Two types of performance requirements are considered – static and dynamic. The static requirements are also called as capacity requirements and they do not inflict constraint on the processing characteristics of the software system. Some examples of capacity requirements are the number of simultaneous users to be supported, number of website users that can log in simultaneously, number of computer workstations to be supported, and so on. The dynamic requirements typically contain response time and throughput constraints on the software system. An example is “every database query should be answered within 1 second.”  Design Constraints – These constraints include the factors in the client environment that restrict the choices. Some of these restrictions are standard compliance and compatibility with other systems, hardware

Sikkim Manipal University B1965 Page No. 64 Software Engineering Unit 4

limitations, and issues of reliability, fault tolerance, backup and the most important one – security.  Interfaces – These include all the interactions of the software with various components of the software system, namely, people, hardware, other software, database and network. User interface is often regarded as most important because this is the direct “zone of contact” between the user and the system. These days a lot of effort is being put on the area of “natural user interface”, as explained in the earlier units. A very broad general structure of the SRS is displayed below: 1.0 Introduction 1.1 Purpose 1.2 Scope 1.3 Definitions and Abbreviations 1.4 References 1.5 Overview 2.0 Overall Description 2.1 Product Perspective 2.2 Product Functions 2.3 User Characteristics 2.4 General Constraints 2.5 Assumptions and Dependencies 3.0 Specific Requirements 3.1 External Interfaces 3.1.1 User Interfaces 3.1.2 Hardware Interfaces 3.1.3 Software Interfaces 3.1.4 Communication Interfaces 3.2 Functional Requirements 3.2.1 Mode 1 3.2.1.1 Functional Requirement 1.1 3.2.1.n Functional Requirement 1.n 3.2.x Mode x 3.2.x.1 Functional Requirement x.1 3.2.x.n Functional Requirement x.n 3.3 Performance Requirements 3.4 Design Constraints

Sikkim Manipal University B1965 Page No. 65 Software Engineering Unit 4

3.5 Attributes 3.6 Other Requirements 3.7 Behavioural Description 3.8 Validation and Criteria 3.9 Bibliography 3.10 Appendix The above format has been standardised by IEEE. However, as per industry practice, most software companies use their unique improvised version of the IEEE format for the SRS. Self- Assessment Questions 5. Whose viewpoint does a “vision document” contain – the customer or the software developer? 6. The SRS contains both functional and ______functional requirements. 7. Sometimes in an SRS we notice that there are contradictory requirements specified. Such an SRS will fail the test of ______.

4.4 Use Case-Based Software Requirements Traditionally, the approach for SRS has been functional specification, wherein each function desired from the software is clearly specified. Use Case Methodology, a relatively newer technique, has been developed for specifying the functionality rather than the functions per se. A use case, mostly in a story-board textual form, captures a contract between a user and system about some functionality to be provided. This story-telling mode has been found to be very effective as users are able to understand the flow of the story and respond to it appropriately. Use case diagrams portray the interactions between use cases (which symbolise functionalities) and “actors.” Actors are stakeholders of the software system and can be either actual people who interact with the system or any other system that interacts with it. Figure 4.2 shows a use case diagram for an ATM. There are two actors here (customer and bank manager) and four use cases (withdraw cash, check balance, update e-mail ID and block issued cheque). Note that the last use case, that is, “block issued cheque,” can be initiated by both the customer and the bank manager. We can also add one more actor to the diagram by the name of “Credit Appraisal System,” which

Sikkim Manipal University B1965 Page No. 66 Software Engineering Unit 4 would be part of another use case called “Make Payment on Credit Card.” In this case also the new actor would be modelled as a “stick figure.”

Withdraw

Money Check Update Overdraft Limit Mobile No.

Make Payment Block on Credit Issued Card Cheque

Customer

Credit Appraisal Bank System Manager

Fig. 4.2: Use Case Diagram for an ATM A lot of information can be gathered from studying use case diagrams. This is a very simple diagram and yet it shows the required functionality as envisaged by the client. This is a very simple and yet powerful portrayal of what a software system is supposed to deliver in terms of functionalities. 4.4.1 Fundamental concepts in use case methodology As explained in the previous section, an “actor” is a person or a system that interacts with the proposed system to achieve a “goal.” An example of a goal is – for a user of an ATM the goal could be to withdraw cash. We have a terminology called “primary actor” – the main actor who initiates the use case. There is also a “precondition” that has to be fulfilled before the use case can be realised. A “scenario” is a group of actions executed to realise a goal under certain conditions. A scenario can be subdivided into “main success scenario” and “alternative scenario.” When things go normally and the goal is attained, we call it as the main success scenario. When things go wrong and we fail to attain the goals, we call it an alternate scenario.

Sikkim Manipal University B1965 Page No. 67 Software Engineering Unit 4

A use case is a collection of several such scenarios. The use cases specify functionality by elucidating interactions between actors and system. The focus is always on the external behaviour and we leave out the implementation details completely. A very important point to be kept in mind is that the use cases do not complete the SRS – they only concentrate on the functionality part. 4.4.2 An example of a detailed use case  Use case title - Online purchase  Primary actor - Online customer  Goal - Buy from the online store  Precondition - The online customer has logged into the website with his login ID and password  Main Scenario o The online customer selects items and drops them into the “shopping cart” o He proceeds to the checkout for payment o He fills out his billing and shipping details o System presents the pricing information along with shipping costs, if any o He types his credit card details along with the OTP (one-time password, if applicable) o The payment gateway authorises his credit card o System confirms the purchase o System sends a confirmatory e-mail along with e-invoice and informs about the shipping time  Alternative scenarios o 6a: Credit card approval unsuccessful – Allow the online customer to re-type credit card details up to a maximum of three attempts o 3a: For a regular online customer – The system displays the billing and shipping information. Seeks permission from online customer to continue with it or change it – Proceeds to step 4

Sikkim Manipal University B1965 Page No. 68 Software Engineering Unit 4

4.4.3 Developing use cases So far, we have understood that use case is an effective method of specifying functional requirements as clients can respond to it better in terms of understanding and comprehension. The other non-functional requirements discussed in earlier sections need to be identified and represented separately. A complete SRS will contain all the functional requirements (in the form of use cases) along with other non-functional requirements. The use cases form a good platform for brainstorming and eliciting requirements. As mentioned earlier, since the format is in the story-telling manner, all the stakeholders can understand the flow quite easily. Typically, the use cases are evolved in a stepwise manner where fine-tuning is done at each step. The steps, as a quick summary, are as follows:  Identify the actors and the goals  Stipulate the main success scenarios  Stipulate the alternative scenarios (failure conditions)  Stipulate how to handle the alternative scenarios (i.e. failure-handling) Self-Assessment Questions 8. Traditional approach to SRS has been to specify ______. 9. Actors are either actual ______or any other system that interacts with the software system being developed. 10. Failure conditions are also called as ______.

4.5 Summary Let us recapitulate the important concepts discussed in this unit:  Gathering and analysing requirements is a very challenging task for any software development project. This is accomplished through the process of requirements engineering, which is achieved in three generic stages: requirements analysis, requirements specification and requirements validation.  Requirements can be understood by a combination of the following methods: asking questions, observation, prototyping and by formal sessions.

Sikkim Manipal University B1965 Page No. 69 Software Engineering Unit 4

 SRS forms the basis of agreement between the customer and the developer where the functionalities to be provided by the software are clearly laid out.  Traditionally, function-based specification was used to specify the requirements in the SRS. Of late, it has become a common practice to utilise use case–based specifications of functionalities.  The understanding of the business domain requirements coupled with the user requirements leads the business analyst to create a vision document. This vision document sets the tone for defining the functional and non-functional requirements that the software has to deliver.  The IEEE has specified the desirable characteristics of a good SRS and has also given a framework for creating the SRS document.  Use cases can be used very effectively to depict functionality. This is a very simple way of presentation and very often the user can relate to it easily as it is in a story-telling format.

4.6 Glossary Business analyst: A person analysing a business at the business functionality level. Stick figure: A representation of an actor in a use case diagram.

4.7 Terminal Questions 1. Explain the concept of “requirements engineering” along with the three generic tasks. 2. Explain the various methods we can employ in order to elicit requirements from clients. 3. What is an SRS? Explain the need and importance for having such a document. 4. What is a vision document? Explain the general process that is followed for developing a typical SRS. 5. Describe the desirable characteristics of a good SRS. 6. What are the fundamental components of “use case methodology”? Explain each one of them in detail.

Sikkim Manipal University B1965 Page No. 70 Software Engineering Unit 4

4.8 Answers Self -Assessment Questions 1. Agile 2. Specification 3. Software requirements specification 4. Business analysis 5. Customer 6. Non-functional 7. Consistency 8. Functions 9. People 10. Alternative scenarios

Terminal Questions 1. (Refer to Section 4.2 for further information.) 2. (Refer to Section 4.2 for further information.) 3. (Refer to Section 4.3 for further information.) 4. (Refer to Section 4.3 for further information.) 5. (Refer to Section 4.3 for further information.) 6. (Refer to Section 4.4 for further information.)

4.9 Case Study Use Cases for Fab Cabs “Fab Cabs” is a small business that specialises in the manufacturing of standard and custom office cabinets. When they started out a few years ago, there were few enough jobs such that they could simply keep track of the orders on paper. As their reputation grew, however, they started to receive more and more orders. They began to hire new cabinetmakers, and within 3 years had grown to a shop with over 100 employees. Although it was still a relatively small company, Fab Cabs had grown just too large to continue to rely on manual processes. Hence, the promoters roped in a consultant to advise them on the system that would be needed for the same. From the discussions that emanated, the consultant was able to determine that the proposed new system needed to support adding new orders,

Sikkim Manipal University B1965 Page No. 71 Software Engineering Unit 4 modifying existing orders, filling orders, checking current inventory levels and restocking the inventory. When a new order is added, the system would need to notify the accounting system, so that an invoice can be generated.

Discussion Questions: 1. Assume that you are the consultant. You are required to identify at least three use cases for the order processing system. 2. You are also required to elaborate each of the use cases identified, clearly mentioning “Primary Actor,” “Goals of Stakeholders,” “Precondition,” “Main Success Scenario” and “Alternatives.”

References/E-References: References:  Jalote, P, Software Engineering – A Precise Approach, Wiley India Pvt Ltd, 2010  Roger S Pressman, Software Engineering – A Practitioner’s Approach, McGraw-hill Higher Education, 2010 E-References:  www.ieee.org (Retrieved on 4th May 2012)

Sikkim Manipal University B1965 Page No. 72 Software Engineering Unit 5

Unit 5 Software Project Management: Part 1 (Project Planning and Project Estimation) Structure: 5.1 Introduction Objectives 5.2 Project Management Process Initiation phase Planning and estimation phase Scheduling and tracking phase Tracking Risk analysis phase 5.3 Software Project Planning Project scope Resources Tools 5.4 Software Project Estimation Estimation models Empirical estimation model The Constructive Cost Model (COCOMO) COCOMO in a nutshell Delphi model Estimation techniques 5.5 Summary 5.6 Glossary 5.7 Terminal Questions 5.8 Answers 5.9 Terminal Questions 5.10 Case Study

5.1 Introduction In Units 1, 2 and 3, you have studied some important concepts in the software engineering process that include software as a product and a process, important traditional software development process models and the latest paradigm of development called the agile methodology. We have also discussed about the requirements engineering and the most important software document called “software requirements specification” (SRS) that

Sikkim Manipal University B1965 Page No. 73 Software Engineering Unit 5 lists out the functionalities to be provided by the software and also the other non-functional requirements in Unit 4. In this unit, we will study about the first part of software project management including the project management process that has four phases (initiation phase, software planning and estimation phase, scheduling and tracking phase and risk analysis phase). We will also discuss about software project planning and a very important aspect of project management called software project estimation. We will study the Constructive Cost Model (COCOMO) that helps us to estimate software projects in advance. This helps in developing an initial budget and cost plan for the software project. Objectives: After studying this unit, you should be able to:  explain the different project management processes  describe about software project planning  elaborate on project estimation techniques and models

5.2 Project Management Process We begin our discussion with “Project Management Process” as a first step to understanding project management concepts. In order to understand the process better, we will first try to answer a fundamental question – “What is Project Management?” Very broadly, we can define project management as the first phase in the software engineering process. It is generally called as a layer and not as an activity or step, as it covers the entire software development process from the beginning to the end. When a software project is undertaken, you must understand the way in which the task has to be done. Before starting your project, you must proactively analyse some of the risks involved in starting the project such as required resources, tasks to be accomplished, milestones to be tracked and the schedule to be followed. All these will be discussed in Unit 6. The project management process is generally driven by the Capability Maturity Model Integration (CMMI) and is based on a series of several small tasks that are executed depending on the requirement.

Sikkim Manipal University B1965 Page No. 74 Software Engineering Unit 5

The project management process or life cycle has four stages as shown in Figure 5.1.

Fig. 5.1: Project Management Process We will now describe the four phases portrayed in Figure 5.1, in the following subsections. We will also discuss the details of software project planning, software project estimation, software project scheduling, software project tracking and control and software risk management in the subsequent sections. 5.2.1 Initiation phase The “Initiation Phase” is the first phase of software project management and this is where all the information related to the requirements of a software project is garnered. We have studied about this phase in Unit 4 under “requirements engineering.” This is perhaps the most important phase, as the scope of the project gets frozen based on the garnered information. Before any project commences, it is imperative that we establish the objectives and scope of the project. We must also identify the technical and management constraints/difficulties to define accurate information related to cost, break down of project tasks and project schedule and appointing project teams. The objective of the project is to deliver the software under consideration to the customer in such a manner where all the agreed-upon requirements are fulfilled and there is no cost and/or time overrun. The scope of the project is to identify the functionalities of the software. Without understanding and freezing the scope of a project, it is not possible for us to

Sikkim Manipal University B1965 Page No. 75 Software Engineering Unit 5 achieve success and fulfil the customer’s requirements that he has envisaged in the software. Let us now understand the various activities performed under this phase, as shown below:  Analysing business needs  Reviewing the current operations and the existing system  Analysing the financial costs and benefits including budget  Analysing stakeholder, including users and support personnel for the project 5.2.2 Planning and estimation phase This is the second phase of the project management process. In this process, a project team that was appointed in the initiation stage, plans for the next phase and sets up the vision to implement and achieve the goals set for the project. The objectives and the scope of a project are considered in the planning phase. We can make estimations of a project on the basis of past experiences on a project using what we call as historical data. For this, we can compare the new and an earlier project, and if they appear similar, then we may conclude that the new project is more likely to require approximately the same time duration (often expressed in calendar months) and the same effort (often expressed in person-months). Person-month costs for each level of software developer are usually calculated on a yearly basis and simple multiplication of the effort with the person-month cost will give us the approximate cost for the project. Using these base figures for cost and time, we analyse the cost of the entire project and the time required to complete the task along with the human resources involved. If we falter in the estimation task, as a part of the planning phase itself, the chances of project failure become high. There are several software project estimation techniques such as Rayleigh Model, Putnam’s Software Lifecycle Model (SLIM), COCOMO or Delphi Technique, which have their own advantages and disadvantages. The project manager decides the estimation techniques to be used. In typical project estimation, the following attributes are most commonly followed:  Establishment of the project scope in advance  Usage of the past measurements of software metrics to make estimates

Sikkim Manipal University B1965 Page No. 76 Software Engineering Unit 5

 Breakdown of project into small pieces which are estimated individually1 Planning phase consists of the following activities.  Creating a project plan  Creating a resource plan  Creating a financial plan  Creating a quality plan  Creating a risk plan  Creating an acceptance plan  Creating a communication plan  Creating a procurement plan  Contract with the suppliers  Perform phase review2 Sometimes, the management identifies the roles and responsibilities, and the requirements of a project, by conducting several meetings. 5.2.3 Scheduling and tracking phase After taking a bird’s-eye view of the planning and estimation phases of a project, we will now discuss the next phase of project management process, namely, “scheduling.” Every software project needs to be scheduled and must have a scheduled start and end time to which we must adhere, in order to fulfil our goal of delivering the software within the committed time. It also involves budgeting for the project. Goals are set for the project teams for which the team members have to achieve their targets on time. When a project is identified, its various interdependent tasks are also identified and analysed and a schedule is fixed for each of them. For completing each task, the required resources including the number of people at various designations (e.g. project manager, architect, programmer, tester, configuration manager, etc.) are identified. Thus, it creates a “task network” that provides details about the development of time schedule. A project schedule defines the approach to be followed, by selecting the appropriate template for a particular project. We break the respective tasks assigned in a particular project into smaller tasks, and fix the date of completion along with the cost involved for the task. We have to keep in

1 Software Engineering: A Practitioner’s Approach by Roger S. Pressman. 2 Software Engineering: A Practitioner’s Approach by Roger S. Pressman. Sikkim Manipal University B1965 Page No. 77 Software Engineering Unit 5 mind the customer’s detailed requirements and follow the processes in a systematic way as advised by the management. We will also need to take care of the requirements of the project, related to software, hardware and training resources, along with meeting the project schedules. 5.2.4 Tracking When the development activities start in a project, we must start tracking and controlling tasks simultaneously in the project. The tasks that are mentioned in a task network are tracked by the project manager. Each time a task is found to be lagging behind schedule, the manager will use automated project scheduling tools to determine the impact of the schedule slippage and how it can hamper the interdependent tasks and project delivery dates. He will also need to work out the correction path so as to bring the project back on track. Despite the best efforts of the development team, tasks may sometimes lag. Such lags can affect the project and some of the impact of a lagging schedule could be redirection of resources, reordering of tasks, postponing of delivery schedules/commitments, and so on. Nowadays, companies use a lot of tracking methods to ensure that tasks are completed as set, and are also prepared to handle tasks that are running behind schedule. 5.2.5 Risk analysis phase This is the last phase in project management, but not the least, as risk analysis is very essential in any project. The word risk means uncertainty. So, when a software program is built for a particular project, there is some amount of risk involved. Let us now see the different risks involved.  Was the customer’s need understood?  Can the tasks be implemented before project deadlines?  Will there be any hidden technical problem (not appearing to us, but may appear to the customer)?  Will the changes made to a task, impact the other tasks and cause programs to run off schedule? Basically, risk management is a proactive method to ensure that if any of our fears (uncertainty) regarding the project becomes a reality, we will not be caught off-guard as we have taken sufficient precaution.

Sikkim Manipal University B1965 Page No. 78 Software Engineering Unit 5

Although risk analysis is the most crucial part of a project, many projects are undertaken without any consideration of risk. Tom Gilb says, “If you do not actively attack (project and technical) risks, they will actively attack you.”3 We can define risk analysis as a series of risk management steps that enable us to attack risk. The different risk management steps are as follows:  Risk identification  Risk assessment  Risk prioritisation  Risk management strategies  Risk revolution  Risk monitoring Self-Assessment Questions 1. The four stages of project management life cycle are initiation, planning and estimation, scheduling and tracking and ______. 2. Rayleigh Model and COCOMO are project estimation techniques. (True/False) 3. What does “SLIM” in Putnam’s SLIM model stand for?

Activity 1: Imagine you are a project manager in a software company, explain how you will plan a project and implement each steps mentioned in the above section. (Hint: Project management process. Refer section No. 5.2)

5.3 Software Project Planning We will start our discussion with the concept of software project planning which will help us to take our discussion forward. As mentioned in the earlier sections, software project planning is the first phase in the software management process. The process of planning involves a detailed study of the software requirements specification document that you learnt in Unit 4. After studying the document, a framework for the entire software project is created that enables the project manager to decide estimates related to cost, schedule and resources

3 Software Engineering: A Practitioner’s Approach by Roger S. Pressman. Sikkim Manipal University B1965 Page No. 79 Software Engineering Unit 5 needed for the software project. In real-world software projects, the estimates are usually not constant; rather they keep varying depending on the progress of the software project. The main goal of planning a software project is to establish/identify the scope of the project. After identification of the project, it is divided into smaller tasks for easier management. This enables successful completion of the software project. 5.3.1 Project scope We will now study about the scope of a software project. Determining the scope of the software project is the first activity of project planning and it is very important to identify the specific business goals that must be achieved by the software. The objective of the software-delivering project must always address the business needs. The scope under which a project needs to be carried out must be well defined before the commencement of the software project. The executive team must ensure that the following steps are followed:  The project mission must be clear and concise.  The teams must understand the objectives throughout the project.  The overall timelines and schedules are established as part of the goals.4 A software project must always have the following scope:  The functionality and the performance of the project must be unambiguous and clear to both the management and the technical teams.  All data related to the constraints, limitations of the software product, product cost and algorithms must be described clearly.  The cost and schedule-related estimates should be defined.  A software project plan should have a well established and managed set of goals and must be documented. When you start a project, you must make sure that you don’t move away from the set goals, as this can make your project run off schedule and the budget might soar.

4 http://ezinearticles.com/?What-is-Project-Planning-and-Scope?&id=3895197 Sikkim Manipal University B1965 Page No. 80 Software Engineering Unit 5

5.3.2 Resources We have already discussed about the first task of software project planning, namely, scope of a software project. Now, we will discuss the second task of software project planning, which comprises estimating the resources required for a project. There are three different types of resources required for a software project. Human resources – Estimation of human resources includes the selection of the right skilled candidates, so that the project can be completed successfully. We recruit professionals at various organisational positions such as software project manager, software engineer and tester along with the specified domains. The number of people required for a software project is determined by the total effort required for the project expressed in person- months or person-years. Hardware resources – We need to estimate the hardware components required for the project. This includes estimation of all computer-related peripherals used during the development of the software, the “target machine” on which the software is executed, other hardware elements used for software development, and so on. Software resources – Estimation of software resources means the estimation of all the software required for the development of software under consideration. This also includes licensing costs for various other software that are required for the implementation, such as IBM Rational Rose, IBM Rational Clearcase, Microsoft VSS, Microsoft Projects, and so on. 5.3.3 Tools After the discussion on estimation of resources required for a project, let us now familiarise ourselves with different types of tools used in software project planning. Table 5.1 gives a fair idea about the different tools.

Table 5.1: Tools for Software Project Planning

Tool Description Business Systems Provides information related to origin of critical business Planning Tool data. It also provides more information pertaining to its usage, the way it can be transformed through different businesses.

Sikkim Manipal University B1965 Page No. 81 Software Engineering Unit 5

Helps the software developers to create information systems that can route information to those who need it. Enables quick transfer of data and delayed decision making. Project Helps in generating estimates like effort, cost and duration Management Tool of a software project. A work breakdown structure is defined. Helps in planning a workable project schedule and tracking them on a continuous basis. Enables the project managers to collect the metrics that can be used as a baseline for both software productivity and software quality. Support Tools Include different tools such as documentation tools, network system software, electronic mail and databases. Used to control and manage the information that is created during software development. Analysis and Helps the software developer to create a model of the Design Tools system that is to be built. Evaluates the software model’s quality and aids in performing consistency and validity checking on each models. Provides insight to software engineers to eliminate the errors before they are encountered in a program. Programming Tools Editors, system software utilities come under this tool. Powerful programming tools can also be added on to them. The object-oriented programming tool and advanced database query systems fall under this category. Maintenance Tools The maintenance tools provide the software engineer with insight, so that intuition, design sense and human intelligence can be applied to complete the reverse engineering process or re-engineer the application. Framework Tools Used to create an integrated project support environment. These tools provide database management capabilities.

Sikkim Manipal University B1965 Page No. 82 Software Engineering Unit 5

Self-Assessment Questions 4. ______team must ensure that the project mission is clear and concise. 5. In real-world software projects, do the initial estimates change over time? 6. The three different types of resources required for a software project are hardware resources, software resources and ______resources. 7. Which software project-planning tool helps software developers to create information systems that can route information to those who need it?

Activity 2: Imagine yourself as a project manager and explain how you would plan your project. (Hint: Software project planning. Refer section No. 5.3.)

5.4 Software Project Estimation In the previous section, we discussed about the software project planning tasks. In this section, we will discuss some of the different software estimation techniques and models used for estimating a software project. Software project estimation is the first phase of project planning and it is the process of predicting a cost for developing a software product and solving the problem associated with the software project. Many technical and environmental variables can affect the cost and the effort involved in a software project. In order to ensure that we arrive at reliable cost and effort estimates, we need to follow the below-mentioned steps:  Develop an empirical model for both cost and effort.  Use automated estimation tools.  Use simple decomposition techniques to generate project cost and effort estimates. 5.4.1 Estimation models Software is very expensive and estimation errors can make a huge difference between profit and loss to the software vendor. Hence, software estimation plays an important role in a software project management Sikkim Manipal University B1965 Page No. 83 Software Engineering Unit 5 activity. Let us now discuss about the different estimation models involved in a software project. 5.4.2 Empirical estimation model The empirical estimation model uses empirically derived formulae in order to predict the data required for software project planning. These empirical data are derived from a sample taken from earlier projects. Hence, this model is not very appropriate for all software development environments and must be used only after analysing and deciding wisely. 5.4.3 The Constructive Cost Model (COCOMO) We can consider the constructive cost model or COCOMO as a software cost estimation model. This model, proposed by Barry Boehm, uses historical data as well as the current project characteristics. In order to estimate cost, effort and schedule in a project, we use COCOMO model. There are three different types of COCOMO models as given in Figure 5.2.

Single Variable Model

COCOMO Static Multi-Variable Model MODEL TYPES

Dynamic Multi-Variable Model

Fig. 5.2: Types of COCOMO Model  Single variable model – We use single variable COCOMO, where a quick and rough estimate of cost of a software project is to be done. However, it is not very accurate.  Static multi-variable model – The static multi-variable model takes care of the cost drivers which could not be handled in the single variable model.  Dynamic multi-variable model – The dynamic multi-variable model projects the resource requirements as a function of time. If the model is derived empirically, then the resources are defined in a series of time steps, which will allocate a percentage of effort to each step in the software development process.

Sikkim Manipal University B1965 Page No. 84 Software Engineering Unit 5

A complete description of the COCOMO is beyond the scope of this course. However, we present below the model in a nutshell so as to give you some idea of how we do the software estimation even before starting a software project. 5.4.4 COCOMO in a nutshell Step # 1: Choose the COCOMO version There are three versions of COCOMO.  Basic  Intermediate  Detailed Step # 2: Choose the COCOMO mode There are three software development modes.  Organic  Semi-detached  Embedded PARAMETERS FOR IDENTIFYING THE COCOMO MODE: Organic mode characteristics:  Small product size (<50 KLOC) {KLOC stands for ‘thousands lines of code’}  Small, in-house development team  Development team experienced in application area  Relaxed (negotiable, informal) specifications on function and performance requirements  Minimal communication overhead  Stable development environment  Minimal schedule pressure  Existing, proven technology used Some examples are engineering, scientific and business applications, inventory control system, and so on. Semi-detached mode characteristics:  Size may range up to 300 KLOC  Development team personnel is a mix of experienced and inexperienced in the application and development environment Sikkim Manipal University B1965 Page No. 85 Software Engineering Unit 5

 Mix of relaxed and rigid specifications  Lies between the organic and embedded mode  Moderate schedule pressure Examples are DBMS, simple command and control systems Embedded mode characteristics:  Size may vary from 20 to 1000 KLOC  Rigorous specifications  Product must operate within time constraints on internal and external interface service, processing and interrupt service  Product must meet rigid, formal quality standards  Close coupling required among software, hardware and operators to meet function and performance requirements  Extensive testing required  Leading edge technology required  Other system components developed concurrently with software  Strong schedule pressure Examples are avionics software systems, operating systems and real-time systems.

Step # 3: Calculate the nominal estimate of Effort (Enom) in person-months (PM) using the formula b Enom = a * (KLOC) Table 5.2: COCOMO Multipliers and Exponents

Product type Multiplier (a) Exponent (b) Basic Intermediate Organic 2.4 3.2 1.05 Semi-detached 3.0 3.0 1.12 Embedded 3.6 2.8 1.2

Step # 4 : Calculate the nominal development time (Td) 0.38 Organic : Td = 2.5 * (Enom) 0.35 Semi-detached : Td = 2.5 * (Enom) 0.32 Organic : Td = 2.5 * (Enom) If we are using the basic model, we have got the estimates and nothing more needs to be done.

Sikkim Manipal University B1965 Page No. 86 Software Engineering Unit 5

Step # 5: Fine-tune the estimates by computing the Effort Adjustment Multiplier (for Intermediate version only) The 15 cost drivers are: Product Attributes  RELY: Required Level Of Reliability  DATA: Size of database used by the system  CPLX: Complexity of software product Computer Attributes  TIME: Execution Time constraints  STOR: Main storage constraints  VIRT: Virtual Memory Volatility  TURN: Computer Turnaround Time Personnel Attributes  ACAP: Analyst capability  AEXP: Experience in the application area  PCAP: Programmer capability  VEXP: Experience with the host virtual machine  LEXP: Experience with the programming language Project Attributes  MODP: Effect of modern programming practices  TOOL: Use of advanced software development tools  SCED: Schedule constraints Next, categorise the cost drivers as low, very low, nominal, high, very high and extra high. Table 5.3: COCOMO Multipliers for Cost Drivers

Attributes Very Low Nominal High Very Extra low high high Product related RELY 0.75 0.88 1.00 1.15 1.40 * DATA * 0.94 1.00 1.08 1.16 * CPLX 0.70 0.85 1.00 1.15 1.3 1.65

Sikkim Manipal University B1965 Page No. 87 Software Engineering Unit 5

Computer related TIME * * 1.00 1.11 1.30 1.66 STOR * * 1.00 1.06 1.21 1.56 VIRT * 0.87 1.00 1.15 1.30 * TURN * 0.87 1.00 1.07 1.15 * Personnel related ACAP 1.46 1.19 1.00 0.86 0.71 * AEXP 1.29 1.13 1.00 0.91 0.82 * PCAP 1.42 1.17 1.00 0.86 0.70 * VEXP 1.21 1.10 1.00 0.90 * * LEXP 1.14 1.07 1.00 0.95 * * Project related MODP 1.24 1.10 1.00 0.91 0.82 * TOOL 1.24 1.10 1.00 0.91 0.83 * SCED 1.23 1.08 1.00 1.04 1.10 *

The product of the 15 values chosen will be the Effort Adjustment Multiplier of the nominal effort and time calculated for the basic version above. We will work out a numerical problem at the end of the next unit (Unit 6) after you learn about function points. This will enable you to get a better understanding of the COCOMO estimation method in tandem with function point analysis. 5.4.5 Delphi model The Delphi model is based on the “expert opinion.” This model follows a systematic and interactive forecasting method and depends on a panel of experts. A structured group of experts provide a more accurate solution when compared to an unstructured group. The interaction is similar to face- to-face interviews/meetings. Hence, it is widely used for business forecasting.

Sikkim Manipal University B1965 Page No. 88 Software Engineering Unit 5

5.4.6 Estimation techniques After discussing about the estimation models, let us now discuss some techniques used for estimating time and cost of a project. We use estimation techniques to solve problems in a project. The common problems that a software project can face are the problems related to cost and effort. Therefore, it becomes very necessary to incorporate the cost and the effort estimation techniques. We can use the decomposition technique for project estimation. In the decomposition technique, we divide a complicated problem in a project into several smaller and manageable units. Appropriate estimation techniques are used on the basis of the scope of the software to be built. “Lines of Code” (LOC) and “Function Points” (FP) are two decomposition techniques used for estimating the effort in a software project, as given in Table 5.4. Table 5.4: Decomposition Techniques

Line of code Function point  It is a decomposition  It is a decomposition technique technique used on the basis that uses the baseline metrics of the size of line of code in collected from the previous a software project. projects.  The line of code  It uses only the macroscopic decomposition technique details in a program. uses all the intricate details  It is determined indirectly by in a program. estimating the number of inputs,  A direct estimation is done in outputs, data files and external the line of code method. interfaces.

By using data collected from the project, the project planner estimates optimistic, pessimistic and most likely LOC or FP value for each function. Self-Assessment Questions 8. COCOMO stands for ______. 9. The three COCOMO modes are organic, semi-detached and ______. 10. COCOMO was created by Bill Gates. (True/False)

Sikkim Manipal University B1965 Page No. 89 Software Engineering Unit 5

Activity 3: Suppose you are working in a software company. Prepare a list of estimation techniques and estimations models used in software project estimation, in your company. (Hint: Estimation technique and estimation models. Refer Section No. 5.4)

5.5 Summary Let us recapitulate the important concepts discussed in this unit:  The project management process is the first phase in software engineering. This phase includes several tasks such as measuring, scheduling, tracking and analysing the risks involved in a project management process.  The phases of software project planning indicate us about how we can handle a project whenever we are assigned a new project/project task. They enable us to correlate the various techniques and models and implement them in a software project.  Software project estimation is an essential part of software project management. This is very challenging because the estimate has to be made at a very early stage of the project where the requirements are still not totally clear. Errors in the estimation process can lead to two situations: under-quoting for a project (that will lead to financial losses for the developer) or over-quoting for the project (that may lead to losing out on the project if it is in the tendering stage).  COCOMO is an effective model that helps us in estimating the effort (measured in person-months) and also the time duration (in calends- months) required to complete a project from start to finish.

5.6 Glossary Baseline: A line serving as a basis, as for measurement, calculation or location. CMMI (Capability Maturity Model Integrated): It is the certification given by the Software Engineering Institute by the United States. COCOMO (Constructive Cost Model): It is an algorithmic software cost estimation model developed by Barry Boehm. The model uses a basic

Sikkim Manipal University B1965 Page No. 90 Software Engineering Unit 5 regression formula, with parameters that are derived from historical project data and current project characteristics. Delphi: It is a systematic, interactive forecasting method that relies on a panel of experts. The experts answer questionnaires in two or more rounds

5.7 Terminal Questions 1. Define software project management process and briefly explain its phases. 2. Explain the three resources used in project planning and describe the different tools of planning. 3. Describe the COCOMO model and briefly discuss its types. 4. Explain the Delphi model. 5. Describe the various tools used for software project planning.

5.8 Answers Self-Assessment Questions 1. Risk analysis 2. True 3. Software Lifecycle Model 4. Executive 5. Yes 6. Human 7. Business Systems Planning Tool 8. Constructive Cost Model 9. Embedded 10. False

5.9 Terminal Questions 1. (Refer to Section 5.2 for further information.) 2. (Refer to Section 5.3 for further information.) 3. (Refer to Section 5.4 for further information.) 4. (Refer to Section 5.4 for further information.) 5. (Refer to Section 5.3 for further information.)

Sikkim Manipal University B1965 Page No. 91 Software Engineering Unit 5

5.10 Case Study Integrated Project Management System The “Indian Railways” is considered to be the largest rail network in Asia and the second largest under one management as it has a workforce of 2 million. Challenge: The Ahmedabad division managed the various construction projects for that particular region. They were in need of an integrated application that would help them to manage their project estimation, tendering, procurements and tender evaluation process. Apart from this, the application also managed several other systems such as project monitoring, financing, billing and tracking and integration of the billing and accounting systems. It generated various project status reports for submission to other authorities as well as the internal reports. Avalanche software solutions came up with a design and developed and implemented an integrated project management system (IPMS) application. The IPMS provided better project management facilities such as tendering/bidding process, procurement assistance and tender evaluation and contract management which included project tracking and billing and produced customised reports. The most important part of the application was its ability to manage and track actual project expenses, approving bills and overall project accounting. Technology used: VB 6.0, MS Access 2000, Adobe Photoshop 5.0, Crystal Reports 8.05. Discussion Question: Explain the challenges faced by the construction group in Ahmedabad and how they overcame it. (Hint: Project management planning.)

References/E-References: References:  Haug, Michael, Olsen, Eric W., & Bergman, Lars. Software Process Improvement: Metrics, Measurement, and Process Modelling.

4. http://www.indusa.com/government_casestudy4.php?action=microsoft Sikkim Manipal University B1965 Page No. 92 Software Engineering Unit 5

 Kan, Stephen H. Metrics and Models in Software Quality Engineering.  Pressman, Roger S. Software Engineering: A Practitioner’s Approach.

E-References:  www.softstarsystems.com/overview.htm (Retrieved on 17th May 2012)

Sikkim Manipal University B1965 Page No. 93 Software Engineering Unit 6

Unit 6 Software Project Management: Part 2 (Project Scheduling, Tracking and Risk Management) Structure: 6.1 Introduction Objectives 6.2 Software Project Scheduling Gantt chart 6.3 Software Project Tracking and Control 6.4 Software Risk Management Risk analysis Risk identification Risk assessment Risk analysis reports Risk monitoring 6.5 Project Metrics Size-oriented metrics Function-oriented metrics 6.6 Summary 6.7 Glossary 6.8 Terminal Questions 6.9 Answers 6.10 Case Study

6.1 Introduction By now, we have explained to you the important concepts in the software engineering process. So far, we have discussed about software as a product and a process, important traditional software development process models and the latest paradigm of development called the agile methodology. We have also discussed about requirements engineering and the most important software document called the “software requirements specification” (SRS) that lists out the functionalities to be provided by the software and also the other non-functional requirements.

Sikkim Manipal University B1965 Page No. 94 Software Engineering Unit 6

In this unit, we will study about software project management, which includes four phases, namely, initiation phase, software planning and estimation phase, scheduling and tracking phase and risk analysis phase. We will also discuss about project metrics and analyse the size-oriented metrics and function-oriented metrics.

This unit will enable us to analyse how we can measure project management activities using project metrics.

Objectives: After studying this unit, you should be able to:  elaborate the different project management processes  describe project metrics (size-oriented and function-oriented metrics)  explain about software project planning  elucidate project estimation techniques and models  explain project scheduling, tracking and control  elaborate risk management

6.2 Software Project Scheduling In Unit 5, we studied estimation models and techniques and how they help in estimating a software project. Let us now understand how software projects can be scheduled to ensure that the software project is on target.

A software project has to be scheduled accurately, as any kind of schedule slippage can affect the cost and effort involved in the software project. Therefore, while scheduling a project, we must adhere to the following points:  Establish a bridge between chronological time and the human effort.  Use milestones to show progress.  Distribute effort throughout the software engineering process.  Check for availability of scheduling methods.  Represent the schedule and track the progress when a project commences.

Sikkim Manipal University B1965 Page No. 95 Software Engineering Unit 6

 When there are several people involved in a project, the tasks and activities pertaining to the project are done in a parallel manner.  After we have analysed the requirements, we must review them, since review is considered as the foundation for the activities and tasks that need to be performed in a software project.  The technical reviews conducted by the software development teams help us in analysing the design and reducing the errors that were not detected during the initial/early stage of software development. These reviews enhance the productivity and quality of a software product, when it is delivered to the customer.  After all the units/modules of the software project are completed, they are integrated and released to the customer after a validation testing. We will now learn about a tool used to analyse and schedule complex software projects called the “Gantt Chart.”

6.2.1 Gantt chart The Gantt charts are tools used for analysing and scheduling complex projects. We can use these charts to perform the following:  Plan out the task that has to be completed.  Provide scheduling details for the tasks that are to be carried out.  Plan the allocation of resources required to complete the project.  Work out the critical path for a project where a deadline is specified.  A Gantt chart uses two types of activities in scheduling a software project: Sequential activities Activities that are dependent on other activities and need to be completed in a sequence, where every stage is more or less completed before the starting of the next activity, are called sequential activities. They are also known as linear activities. Parallel activities Some of the activities are not dependent on other activities and tasks for their completion and they can be accomplished any time before or after reaching a particular stage, these are called nondependent activities or the parallel activities. We can use the Gantt chart to monitor and check whether

Sikkim Manipal University B1965 Page No. 96 Software Engineering Unit 6 a project is on schedule. If the project is not on schedule, we can pinpoint the remedial action necessary to put the project back on schedule.1 We can use Gantt charts for the following:  Planning and scheduling projects.  Assessing and determining the project duration, resources needed and the order in which the tasks must be carried out.  Monitoring and checking whether a project is on schedule. If the project is not on schedule, we can pinpoint the remedial action necessary to put the project back on schedule.2

Self-Assessment Questions 1. One tool that is used for analysing and scheduling complex projects is ______. 2. The two types activities used in Gantt charts are sequential and ______activities. 3. While scheduling a project, we use ______to show progress charts.

Activity 1: Imagine that you have been assigned the task of scheduling a software project. Explain how you will visualise the sequential and parallel activities and check project schedule. (Hint: software project scheduling. Refer section No. 6.2)

6.3 Software Project Tracking and Control The previous section familiarised us with project scheduling. This section will familiarise us with the way in which we can track and control a project. Project tracking is the way in which projects are managed and it involves a series of tracking activities that are both measured and reported. The objective here is to ensure that we are able to monitor the project’s progress

1 http://www.mindtools.com/pages/article/newPPM_03.htm 2 http://www.mindtools.com/pages/article/newPPM_03.htm Sikkim Manipal University B1965 Page No. 97 Software Engineering Unit 6 and take corrective action in case it is going out of control in terms of schedule slippage, and so on. Some of the activities that you can find in software project tracking are a set of tasks and milestones (very important events). These activities can be achieved by having a set of predefined project results/goals. Project tracking can be undertaken with project management software (like Microsoft Projects), which automates the process of tracking project-related activities. Now, let us see the ways in which tracking can be achieved in an organisation:  By conducting periodic status meetings, where the members of the team report their progress and problems.  By evaluating results of all the reviews conducted throughout the software engineering process.  By determining whether the formal tasks and milestones of the projects have been achieved within the scheduled date and time.  By comparing the actual start date to the planned start date for each project.  By conducting informal meetings with the practitioners and obtaining the assessment details pertaining to the progress in a project and also examining the problem areas where there is a delay in meeting schedules.3 Control is the method used by a project manager to know the status of the activities in a project. A simple way of tracking is to check the number of hours spent by each resource on a task associated with the cost. We can use various tools and techniques to track the projects. The project management software tool is one of the most commonly used tools. This tool helps us in managing, executing, tracking and closing the projects. Automating the project management tasks helps us to have an access to real-time analysis and also enables us to manage the resources efficiently.

3 Software Engineering: A Practitioner’s Approach by Roger S. Pressman. Sikkim Manipal University B1965 Page No. 98 Software Engineering Unit 6

Therefore, we can say that project control enables us to know the status of a project. Let us see some benefits of project control:  Project delivery is done as scheduled considering cost and time.  Accurate reports of the project status.  Able to spot deviations from plan and sort them out.  Potential future problems can be overseen and can be avoided.

Self-Assessment Questions 4. Project tracking is the way in which projects are ______. 5. Project tracking can be undertaken with software like Microsoft Projects, which is a ______software. 6. Project control enables us to know the ______of a project.

Activity 2: Imagine you have been assigned the task of tracking and controlling a project. Explain the steps you would take to track and control the project. (Hint: Tracking and control. Refer Section No. 6.3)

6.4 Software Risk Management After studying the importance of tracking a project and the way the tasks can be controlled, we will now study about software risk management and how it works. We can define risk as the potential dangers that can occur in our simple daily activities. By experience, we have learnt how to handle risks in our lives. In the same way, an organisation has several risks involved in the process of software project development. In software risk management, an approach is made to study about the experiences of both the successful and unsuccessful projects, in order to have a better understanding about the success or failure of projects. This gives us an idea about handling the project under different scenarios. Let us have a look at the top ten software risk items in a software project.  Personnel shortfalls  Scheduling and budgeting unrealistically

Sikkim Manipal University B1965 Page No. 99 Software Engineering Unit 6

 Developing the wrong functions and properties  Developing the wrong user interface  Continuing stream of requirements change  Shortfalls in externally furnished components  Shortfalls in externally performed tasks  Real-time performance shortfalls  Straining computer-science capabilities  Gold-plating (Gold-plating is the method of pampering the customer by adding new fancy features to the product and not billing them. This will make the customer think that you are doing more work for free.) Therefore, managing risk has become a matter of concern, as it involves huge amount in costs. We can conclude that software risk management is a proactive approach to minimise the uncertainty and potential loss associated with a software project. Let us now discuss four risk management activities as shown in Figure 6.1.

Risk Management Activities

Risk Analysis Risk Identification Risk Assessment Risk Monitoring

Fig. 6.1: Risk Management Activities

6.4.1 Risk analysis After a brief discussion about risk, we will now familiarise ourselves with analysing risks associated with a software project. Risk analysis is the process of analysing the dangers on an organisation or an individual due to the adverse effects caused by nature or human-related errors. Risk analysis comprises four different activities, as follows:  Risk identification  Risk projection  Risk assessment  Risk management

Sikkim Manipal University B1965 Page No. 100 Software Engineering Unit 6

We will study about these activities in the later sections. First we will discuss in detail about the steps involved in risk analysis. 1. Identify threats – While analysing risk, we face many threats from individuals or organisations, illness or death, from disruption to supplies and operations from loss of business partner, from failures of accountability, internal system and controls, risks of cost overruns, from business failure, from advances in technology to technical failures, from weather, natural disaster, accident and disease, and so on. 2. Estimate risk – After identification of threats, we must realise and assess its impact. To evaluate risk, we must multiply the probability of the event occurring with the amount that would cost to set right thing. 3. Manage risk – After the value of risk is worked out, you must start to manage them. In order to manage risk, you must always ensure that cost-effective approaches are followed and also ensure that the amount spent must always be less than the cost of the event. Risks can be managed by using existing assets, contingency planning and by investing in new resources. 4. Reviews – A review is done after completing the risk analysis and may involve appropriate planning and system testing. Risk analysis helps us to assess the various risks involved in a software project and the countermeasures to be taken in order to minimise the disruptions that can impact a scheduled plan in a project. 6.4.2 Risk identification Let us now learn about identification of the risks in a software project. Risk identification is a method of either determining the risks that exist or those that are anticipated along with the details of time and their possible outcomes. At times, it becomes impossible to eliminate or minimise risks. So, before taking up a software project, we must identify all the potential risks to the extent possible. We can classify risk categories in many ways, some of them being: 1. Project risks – It includes project schedules, staffing for the project/ personnel, project budget, requirements, resources and their impact on a software project.

Sikkim Manipal University B1965 Page No. 101 Software Engineering Unit 6

2. Technical risks – It covers the factors involving the design of a software project, implementation, verification, interface and issues related to maintenance. Factors such as technical uncertainty, ambiguous specification and “leading edge” technology are also considered as technical risks, as they are difficult to solve than we thought it would be. Technological obsolescence also comes under technical risk. 3. Business risks – Business risks are perhaps the most harmful risks and they unravel/bring out the details of the best software projects. The five top business risks are as follows o Building an excellent product that no one really wants (market risk). o Building a product that no longer fits into the overall product strategy for the company. o Building a product that the sales force does not understand how to sell. o Losing the support of senior management, while starting a project due to a change in the people’s focus. o Losing budgetary or personnel commitment (budget risk).4 Risks cannot be easily predicted and hence, a certain checklist must be followed to identify risks. Risk identification is the first step in managing risk and only then the concerned personnel work on them in the right manner. To run a software organisation or a software project, we must follow a structured risk management methodology in order to identify the risks. Risk identification involves in understanding the project and documenting the likely risk characteristics and also incorporating the possible threats. All these can be done with the help of a “risk table.” Very briefly, the steps required for erecting the risk table are as follows: 1. The project manager lists down all the risks, even the remotest one, in consultation with the project team and other experts.

4 Software Engineering: A Practitioner’s Approach by Roger S. Pressman. Sikkim Manipal University B1965 Page No. 102 Software Engineering Unit 6

2. From his/her experience, he/she figures out the probability for each of the above risks, that a particular risk will become a reality (range is from 1% to 100%). 3. He/she also lists down the impact of a risk becoming a reality on a scale of 1 to 5 where 1 is “negligible” and 5 is “catastrophic.” 4. Next, he/she sorts the table–on probability descending (high to low) and impact ascending (low to high). 5. He/she defines a cut-off (say 40%) below which he/she will not consider any of the risks laid down. 6. All the risks that come above the cut-off probability will be considered. The mitigation for each of these shortlisted risks will be specified in a document called “Risk Mitigation, Monitoring, and Management (RMMM) Plan” where we need to record each shortlisted risk 6.4.3 Risk assessment After discussing the aspects of risk identification, we will now discuss risk assessment. Risk assessment is the first step towards risk management. Risk assessment is examining the factors that can bring about risk in a software project and also taking enough precautions to prevent the risks on the project and the employees in a software company. Hence, risk is considered as an uncertain event that can cause adverse effects on an organisation that is working towards its set goals. By analysing the risks, we arrive at risk assessment which is also called as the “Threat and Risk” assessment. Threat can be defined as a harmful act like illegal network penetration or a virus. Risk is the expected potential damage it can cause to a software project. In order to assess risk, we must first define the risk referent level. The three risk referent levels of a software project are as follows:  Cost  Performance  Schedule

Sikkim Manipal University B1965 Page No. 103 Software Engineering Unit 6

These levels give us information about cost overrun, schedule slippage and performance degradation (including insufficient requirements) and this in turn leads a software project to be terminated. While performing risk assessment, we must follow these steps:  Define the risk referent level for the project.  Attempt to develop a relationship between the referent levels.  Predict the set of referent points that define a region of termination, bounded by a curve or area of uncertainty.  Try to predict how compound combinations of risks will affect a referent level. In order to assess risks, we must analyse the type of risk and determine whether it is a quantitative risk or a qualitative risk. We will conclude our discussion on risk assessment by briefly touching upon the subject of “risk analysis reports.” 6.4.4 Risk analysis reports A risk analysis report gives us a clear picture about how technology-related objectives and business objectives are arranged. There are two types of risk analysis reports. Quantitative risk analysis Quantitative risk analysis gives details about the statistical values pertaining to the adverse effects and the likely losses for a particular software project. In this type of risk assessment, two components are used to calculate risk: the magnitude of the potential loss and the probability of occurrence of loss. Qualitative risk analysis Qualitative risk analysis does not involve numerical data. Instead, it defines the various threats and the extent of damage that could occur, along with the countermeasure plans. The risk analysis report gives you the details about the vulnerability and the cost of recovery caused due to a risk factor. Therefore, several defensive measures are taken by organisations to counter risks whenever they become realities.

Sikkim Manipal University B1965 Page No. 104 Software Engineering Unit 6

6.4.5 Risk monitoring By now, you must have become familiar with the concepts involved in risk analysis after learning the previous sections. Let us now have a brief discussion on risk monitoring. The entire process of software risk management is documented and is used by a project manager as part of a project plan. The documented plan gives you details about the risk monitoring and control methods used in the project. Risk monitoring is the tracking activity of a software project. The following are the three main objectives of risk monitoring:  To assess whether a predicted risk does, in fact, occur.  To ensure that the risk avoidance steps are defined and are also being properly applied.  To collect information that can be used for future risk analysis.5  Most of the problems that occur in a project can be traced back to the risks that were predicted at the commencement of that software project. The four ways in which risks can be reduced in a software project are given below. Risk avoidance – Risk avoidance is basically shunning tasks that are risky. Sometimes, it might reduce the possibility of gains, as you are avoiding risky tasks. Risk reduction – In order to reduce risks, measures that can act against a risk are introduced in the project. Risk retention – In risk retention, we must accept the consequences of a risk involved in a software project. This type of risk proves to be cost- effective to the company. Risk transfer – In risk transfer, a part of a task involved in a project might be outsourced or given to a subcontractor.

5 Software Engineering: A Practitioner’s Approach by Roger S. Pressman. Sikkim Manipal University B1965 Page No. 105 Software Engineering Unit 6

Self-Assessment Questions 7. The act of outsourcing a part of the task is one form of risk reduction. This is an example of ______. 8. The ______levels give us information about cost overrun, schedule slippage and performance degradation. 9. The two types of risk analysis reports are quantitative and ______.

Activity 3: Imagine yourself as a member in the risk analysis committee and explain how you would handle risks in your project. (Hint: Software risk management. Refer section No. 6.4)

6.5 Project Metrics By now, we have become familiar with the concepts of project management process. We will now study about “Project Metrics.” Project metrics provides us an idea about the progress of the software along with quality. In software engineering, it is a difficult task to measure and evaluate the software process. Let us now try to understand the reasons for measuring a software product:  To indicate the quality of the product.  To assess the productivity of the people who produce the product.  To assess the benefits (in terms of productivity and quality) derived from new software engineering methods and tools.  To form a baseline for estimation.  To help justify requests for new tools or additional training estimation. We can classify the process measurement in two ways, namely direct measures and indirect measures, as shown in Figure 6.2.

Sikkim Manipal University B1965 Page No. 106 Software Engineering Unit 6

Fig. 6.2: Measurement of Process Metrics Let us briefly understand these measures. Direct measures – The cost and efforts of software engineering process come under the direct measures. The direct measures of the product are lines of code (LOC) produced execution speed, memory size and defects reported over a set period of time. It is easy to collect data related to cost, effort in man-days and the lines of code only when the correct measuring conventions are established. Indirect measures – These include the functionality aspects of a product such as quality, complexity, efficiency, reliability and maintainability. The maintainability and efficiency are difficult to assess. 6.5.1 Size-oriented metrics We can use the size-oriented metrics for collecting the direct measures of software engineering like defects and human effort related to a software project. When a software company maintains a simple record, a table of size-oriented metrics is created. This table will give you an idea about the different software projects that were completed in the past years along with the size-oriented data for that project. In Table 6.1, we see that the project titled as aaa-01 had 12.1 KLOC (thousand (Kilo) lines of code), that were developed with 24 person-months of effort at a cost of $168,000. This table not only shows the cost and effort-related activities, rather it will provide

Sikkim Manipal University B1965 Page No. 107 Software Engineering Unit 6 details about analysis, design, testing and coding. The project aaa-01 has a 365-page documentation and 29 errors that occurred after the product was released to the customer during the first year of operation.6

Table 6.1: Size-Oriented Metrics Project Effort $ KLOC pgs.doc Errors People aaa-01 24 168 12.1 365 29 3 ccc-04 62 440 27.2 1,224 86 5 fff-03 43 314 20.2 1,050 64 6 iii-02 11 112 9.7 268 13 2 A simple size-oriented production and quality metrics can be developed for each project and an average can be calculated for all other projects. Productivity = KLOC/person-month Quality = defects/KLOC The cost and the documentation involved in the project can also be calculated. Cost = $/LOC Documentation = Pages of documentation/KLOC Due to the complexity of the size-oriented metrics, they are not accepted universally and hence not used to measure the software development process. Also, you will need to understand that brilliant programmers who can create a program with much lesser number of LOC will actually be penalised when we use LOC as the unit of measure! LOC is programming language dependent and cannot adapt to non-procedural languages. In order to estimate, you will require detailed data that are difficult to obtain. Before completing the analysis and design state, you must estimate the LOC. Therefore, we can conclude from the above discussion that although size- oriented metrics are widely used, the validity and applicability of such an approach is still not proven.

6 Software Engineering: A Practitioner’s Approach by Roger S. Pressman. Sikkim Manipal University B1965 Page No. 108 Software Engineering Unit 6

6.5.2 Function-oriented metrics After familiarizing ourselves with size-oriented metrics, we will now study about function-oriented metrics. The function-oriented metrics are indirect software metrics. Instead of the number of LOC, the emphasis is more on the functionality of the product. The function-oriented metrics were first proposed by Albrecht. He suggested a productivity measurement approach known as the Function point method. In this method, function points are used. A function point is a relation that is based on the countable measures of software information domain and assessment of software complexity. Let us see the structure of function-oriented metrics in Figure 6.3.

Fig. 6.3: Function-Oriented Metrics Figure 6.3 depicts how the five information domain characteristics (number of user inputs, number of user outputs, number of user inquiries, number of files and number of external interfaces) are determined and the way in which the counts are provided in the appropriate table location. Let us see how these five information domain values are calculated. Number of user inputs: For calculating the number of user inputs, each user input that has a unique application-oriented data to the software is counted. The inputs and the inquiries are separately counted.

Sikkim Manipal University B1965 Page No. 109 Software Engineering Unit 6

Number of user outputs – For calculating the number of user outputs, each user output that provides application-oriented information to the user is counted. The output refers to the reports, screens and error messages. Individual data items within a report are not counted separately. Number of user inquiries – For calculating the number of user inquiries, each distinct inquiry is counted. We can define an inquiry as an online input that results in the generation of some immediate software response in the form of an online output. Such an output need not be stored in a database as we would do with user outputs. Number of files – For calculating the number of files, each logical master file, that is a logical grouping of data that may be one part of a large database or a separate file, is counted. Number of external interfaces – For calculating the number of external interfaces, all machine-readable interfaces (e.g. data file on tape or disk) that are used to transmit information to another system are counted. When all the aforementioned data pertaining to information domain are collected, a complexity value is associated with each count. Organisations can determine the type of entry with the help of function point methods criteria. Calculation of Function Points You can calculate function points (FP) as follows: Step 1: Calculate the unadjusted function points (UFP) by multiplying each count of simple, average and complex counts with the corresponding weights assigned to simple, average and complex. Step 2: Calculate the degrees of influence (DOI). DOI is the sum total of the values given to the 14 parameters used to assess DOI. The parameters are as follows:7 o Data Communications o Distributed Functions o Performance o Heavily Used Configuration

7Software Engineering: A Practitioner’s Approach by Roger S. Pressman. Sikkim Manipal University B1965 Page No. 110 Software Engineering Unit 6 o Transaction Rate o Online Data Entry o End User Efficiency o Online Update o Complex Processing o Reusability o Installation Ease o Operational Ease o Multiple Sites o Facilitate Change For each of the above parameters, the software professional has to assign a value ranging from 0 to 6 (where 0 implies the least and 6 implies the maximum). Step 3: Calculate the value adjustment factor (VAF) using the formula: VAF = 0.65 + (0.01 * DOI). Step 4: Calculate the adjusted function points (AFP) using the formula: AFP = UFP * VAF It is also possible to calculate the corresponding KLOC from AFP and then applying the COCOMO model to estimate the effort and time required for the project. For this, we can refer to the standard “FP to LOC” conversion table. Let us now work out a problem that includes function points and the COCOMO. Problem: Assume that for a software project, the following function point counts have been established. Table 6.2: FP Counts and Corresponding Weights for a Fictitious Software Project Item Simple Average Complex Inputs 25 12 7 Outputs 45 14 19 Inquiries 12 10 8 Logical master files 56 48 21 External interface files 4 2 0

Sikkim Manipal University B1965 Page No. 111 Software Engineering Unit 6

The values given to “Degree of Influence” attributes are as shown in Table 6.3. Table 6.3: Values Given to “Degree of Influence” Attributes for a Fictitious Software Project Weighting factor Item Simple Average Complex Inputs 3 4 6 Outputs 4 5 7 Inquiries 3 4 6 Logical master files 7 10 15 External interface files 5 7 10

1 Data Communications 5 2 Distributed Functions 5 3 Performance 2 4 Heavily Used Configuration 2 5 Transaction Rate 0 6 Online Data Entry 5 7 End User Efficiency 5 8 Online Update 3 9 Complex Processing 5 10 Reusability 5 11 Installation Ease 0 12 Operational Ease 5 13 Multiple Sites 5 14 Facilitate Change 5

You are required to compute the following: 1. Total unadjusted function points (UFP) 2. Total degrees of influence (DOI) 3. Value adjustment factor (VAF) 4. Total adjusted function points (AFP)

Sikkim Manipal University B1965 Page No. 112 Software Engineering Unit 6

Solution: Step 1: Calculate the UFP as follows: UFP = (25*3 + 12*4 + 7*6) + (45*4 + 14*5 + 19*7) + (12*3 + 10*4 + 8*6) + (56*7 + 48*10 + 21*15) + (4*5 + 2*7 + 0*10) = 1,893 Step 2: Calculate the DOI as follows: DOI = 5 + 5 + 2 + 2 + 0 + 5 + 5 + 3 + 5 + 5 + 0 + 5 + 5 + 5 = 52 Step 3: Calculate the VAF as follows: VAF = 0.65 + (0.01*DOI) = 0.65 + (0.01*52) = 1.17 Step 4: Calculate the AFP as follows: AFP = UFP*VAF = 1,893*1.17 = 2,215 That is, this software project has an estimated 2,215 function points. Now, let us assume that the project is going to be developed in C++ language. For C++, the conversion rate is 59 LOC per function point. Hence, we conclude that this project will have an estimated 59*2,215 = 130,685 LOC or 131 KLOC. We further assume that the project follows the basic version and organic mode of COCOMO (refer Unit 5, section 5.4: Software Project Estimation). Let us now calculate the effort and calendar time required to finish the project.

b We will use the formula Enom = a * (KLOC)

1.05 That is, Enom = 2.4 * (131) = 2.4 * 167.16 = 401 person-months.

0.38 For development time we can from the formula Td = 2.5 * (Enom)

0.38 That is, Td = 2.5 * (401) = 2.5*9.75 = 24.4 calendar-months. Thus, the project requires 401 person-months of effort, to be completed in 24.4 calendar months.

Self-Assessment Questions 10. We can classify the process measurement into two ways, namely direct measures and ______measures. 11. KLOC stands for ______.

Sikkim Manipal University B1965 Page No. 113 Software Engineering Unit 6

12. The raw count of function points are further fine-tuned using DOI and VAF. The final result after the calculations is called as AFP that stands for ______.

Activity 4: Imagine you have been assigned the task of measuring the software product; explain how you would use the size-oriented and the function- oriented metrics in your task. (Hint: Project metrics.)

6.6 Summary Let us recapitulate the important concepts discussed in this unit:  Measurement of a project enables the professionals involved in a project to have a better understanding about the process that is followed and the product that is being developed. Metrics for quality and production can be measured in various ways.  The need for monitoring and controlling a project is very important, since it updates the team and the management about the progress status of the project. If there is any kind of deviation noted, then the project manager can take necessary corrective steps.  Risk is an important aspect of a software project. It is necessary to have a written recovery plan that can address all the risks involved in a software project. A written recovery plan provides comfort to a software organisation in recovering from the disaster which can occur due to a project off schedule and other contingencies.  In order to measure the process and the product, size-oriented and function-oriented metrics are used. Size-oriented metrics are used for measuring the lines of code and defects in a program while function- oriented metrics are used to assess the complexity of a problem.  Finally, in order to produce a quality software product, a software project needs to be managed using systematic well-defined methods and tools by meeting the objectives and goals set.

Sikkim Manipal University B1965 Page No. 114 Software Engineering Unit 6

6.7 Glossary Financial analysis: It involves looking at financial statements to determine if a company is healthy. Stakeholder analysis: It is a tool that is used to assist in decision-making situations where various stakeholders have competing interests, resources are limited and stakeholder needs must be appropriately balanced. This tool can be used for many types of decisions at all levels within an organisation.

6.8 Terminal Questions 1. Differentiate between scheduling and tracking. 2. Explain project metrics and its types in detail. 3. Describe software quality metrics and its measures. 4. Briefly describe the importance of integrating metrics within software engineering. 5. Discuss Software project scheduling using Gantt charts. 6. Explain software project tracking and control. 7. Define software risk management and the ten software risk items of software project and also explain the different systematic activities in risk analysis.

6.9 Answers Self-Assessment Questions 1. Gantt Chart 2. Parallel 3. Milestones 4. Managed 5. Project management 6. Status 7. Risk transfer 8. Risk referent 9. Qualitative 10. Indirect 11. Kilo lines of code 12. Adjusted function points Sikkim Manipal University B1965 Page No. 115 Software Engineering Unit 6

Terminal Questions 1. (Refer to Section 6.2, Scheduling and Tracking phase for further information.) 2. (Refer to Section 6.5, for further information.) 3. (Refer to Section 6.6, Software Quality Metrics for further information.) 4. (Refer to Section 6.6, Software Quality Metrics for further information.) 5. (Refer to Section 6.2 for further information.) 6. (Refer to Section 6.3 for further information.) 7. (Refer to Section 6.4 for further information.)

6.10 Case Study Central Portal System A 20-member Sigma services department executes 60 jobs per week with 150 jobs open at any time. Their projects included four to five people from designing, marketing and advertising. There were no proper scheduling and planning techniques used while planning a project. Due to this, the staff members at sigma services were very frustrated, as they had to meet unrealistic project deadlines. Resource load and deadlines were manually allocated without any updated resource allocation system, which caused the employees to be dissatisfied. The management found that a lot of time was spent on paper work. Challenge: The management needed a tool to manage and improve its project planning, which would integrate the Microsoft office documents with a project tracking system. They wanted to have a clear idea about the real- time project status and capacity planning, based on the resources used, instead of making a guesswork. Solution: By using the Vertabase pro and the Gantt charts, every project could be tracked. As the Vertabase pro was very user-friendly, it was used in most of the tasks and assignments outside their planned workload. Currently, the team uses a resource management report in order to complete more projects ahead of schedule than before.

Sikkim Manipal University B1965 Page No. 116 Software Engineering Unit 6

Results: Resource planning improved and thereby increased employee satisfaction. Mangers could have a better control over their projects using Gantt charts, which helped them in successful task completion. An automated project management system was set, using the Vertabase pro and the Gantt charts. Future projects could be planned based on the past project details. A clear documentation about the tasks completed along with the details of date and time was available. The central repository system helped them to know about daily tasks, send automated e-mail notifications which were previously paper-based. There was increased accountability to commitments and deadlines. Discussion Question: 1. Discuss the problems faced by the sigma services and how they overcame it. (Hint: Project scheduling and tracking.)

References/E-References: References:  Chemuturi, Murali. Software Estimation Best Practices, Tools & Techniques, J Ross Publishing (10 September 2009)  Roger S Pressman, Software Engineering – A Practitioner’s Approach, McGraw-hill Higher Education, 2010

Sikkim Manipal University B1965 Page No. 117 Software Engineering Unit 7

Unit 7 Software Reliability Structure: 7.1 Introduction Objectives 7.2 Software Reliability Metrics Software metrics Software reliability models 7.3 Programming for Reliability Fault avoidance Fault tolerance 7.4 Software Quality Metrics 7.5 Software Reuse Classification of software reuse Advantages of software reuse 7.6 Summary 7.7 Glossary 7.8 Terminal Questions 7.9 Answers 7.10 Case Study 7.1 Introduction By now, you have become familiar with different processes involved in software project development, such as project planning, scheduling, tracking and risk management. In this unit, we will study about software reliability metrics, wherein we will discuss about software metrics and software reliability models. We will study about fault avoidance and fault tolerance, which will help us in understanding how reliability is used in programming during the developmental phase of a software product. In this unit, we will also discuss the software quality metrics, which will help us in understanding the integration of metrics within software engineering process. We will also have a detailed discussion about how software can be reused by using the artefacts that are already available from the previous projects. This is indeed very cost effective and enhances the quality of the software system. This unit will enable us to understand the use of appropriate software metrics while developing a software product.

Sikkim Manipal University B1965 Page No. 118 Software Engineering Unit 7

Objectives: After studying this unit, you should be able to:  elaborate software reliability metrics  explain programming for reliability with respect to fault avoidance and fault tolerance  describe about software quality metrics  elucidate software reuse

7.2 Software Reliability Metrics Let us start our discussion on software reliability with “software reliability metrics.” We can define “reliability” as the capability of being depended on; and “software reliability” as the reliability/dependability of a particular software product. When we speak about the quality of a software product/system, software reliability comes into picture. Several software reliability approaches are used in the field of software engineering in order to have a reliable software system. Due to the complexity in the software product, software reliability becomes difficult at times. Today, computers play a significant role in our day-to-day lives. It has become impossible for us to engage in our daily activities without computers, which are controlled by the software. As we depend more on the software systems, it becomes very necessary for us to have reliable software. The failure of a software system can cause loss of life or money and sometimes even both. Thus, it is imperative for software systems to be very reliable. Let us take the example of the NASA Software Assurance Standard, NASA- STD-8739.8, which defines software reliability as a discipline of software assurance that  Defines the requirements for software-controlled system fault/failure detection, isolation and recovery.  Reviews the software development processes and products for software error prevention and/or reduced functionality states.  Defines the process for measuring and analysing defects and defines/derives the reliability and maintainability factors.

Sikkim Manipal University B1965 Page No. 119 Software Engineering Unit 7

Let us have a look at the two types of software reliability techniques used, which are shown in Figure 7.1.

Fig. 7.1: Software Reliability Techniques

1. Trending reliability – Trending reliability technique is a software reliability technique, which tracks the data of a software system that have failed. The data collected are then used to develop a reliable software system for a specified period of time. Trending reliability is more suitable for the software industry. Based on the operations, we can categorise the trending reliability into four types.  Error seeding – This type of trending reliability involves assessing the number of errors in a program using multi-stage sampling where we can classify the errors into indigenous and induced (seeded) errors. We can assess the number of anonymous indigenous errors from the number of errors that are induced and the ratio of errors obtained from debugging.  Failure rate – We can define this type of trending reliability as the method of studying the failure rate of programs per fault at failure intervals. The failure rate of the program changes depending on the change in the number of remaining faults.  Curve fitting – Curve fitting is a type of trending reliability, which uses the statistical regression analysis in order to study the relationship between the complexity of software and the number of faults in a program along with the failure rate.

Sikkim Manipal University B1965 Page No. 120 Software Engineering Unit 7

 Reliability growth – Reliability growth of trending reliability is used to measure the improvements made in the software reliability programs, and also predicts software reliability by incorporating a process of software testing. The failure rate of a software system is represented as a function of time or as test cases. 2. Predictive reliability – Predictive reliability is another software reliability technique, which predicts or anticipates the possibilities of operational profile of a software system, and is more appropriate for hardware After understanding the two software reliability techniques, we will now study about the various software reliability metrics based on the way they are measured. The mathematical concept of reliability We can define the concept of reliability mathematically by using the following equations. Reliability R(t) is the probability of a system to be successful during the time interval ranging from 0 to t. R(t) = P(T > t), t  0 Where “T” is a random variable denoting the time-to-failure or failure time. In other words, F(t) is the failure distribution function. The following relationship applies to reliability in general. F(t) = P(T  t), t  0. The reliability, R(t), is related to failure probability F(t) by R(t) = 1 − F(t). 7.2.1 Software metrics We have discussed about product metrics in the previous unit; let us now familiarise ourselves with various software reliability metrics. We can categorise software reliability metrics into certain distinct types as shown in Figure 7.2.

Sikkim Manipal University B1965 Page No. 121 Software Engineering Unit 7

Fig. 7.2: Types of Software Reliability Metrics  Product metrics – Product metrics involve instinctive method of measuring the size of the software, on the basis of the “lines of code (LOC),” or more practically “thousand lines of code (KLOC).” This is the simplest method for measuring reliability and we generally use source codes to measure the lines of code in order to determine the size of a software product. We cannot use the product metrics to compare software that is written in different programming languages.  Function point metrics – We can use the function point for the measurement of the functionality of a recommended software development system based on functions such as count of inputs, outputs, master files, inquires and interfaces. Once we identify these functions, we can estimate the size of a software system. The functionality metrics measure the functional complexity of a software program, and they are independent of other programming languages. Generally, we use the functional metrics in business systems, and not much in the scientific applications.  Complexity metrics – We can use complexity metrics for determining the complexity of a software program’s control structure. We can simplify the complexity of the software program code by graphical representation.  Test coverage metrics – We can use test coverage metrics for estimating the fault and reliability of a software program.

Sikkim Manipal University B1965 Page No. 122 Software Engineering Unit 7

 Project management metrics – We know that good management can provide better quality products. Therefore, it is very necessary to establish a synchronous relationship between the development process and the ability to complete projects on time and within the budget, and thereby meet quality objectives. When the development process is not followed in a systematic manner, costs can increase and the software project can run off-schedule. Thus, we can achieve high reliability by using project management metrics.  Process metrics – We can use process metrics for estimating, monitoring and improving the reliability and quality of a software product.  Fault and failure metrics – Fault and failure metrics are used for measuring the number of faults found in the software system during the testing phase (before delivering to the customer) and the failures (reported by the customers) after the delivery of the software product. Software reliability plays a key role in enhancing the quality of a software product. We can classify the study of software reliability into three phases as follows:  Modelling – We can define software reliability modelling as the use of appropriate models for solving a problem in a software system and obtaining suitable results. There is no single model that can be used for all situations in software systems.  Measurements – We can say that software reliability measurement is measuring the software quantitatively to know how good a software product is. We cannot measure software reliability directly; instead, we can measure other factors for estimating software reliability. The faults and failures of the development process are the factors related to software reliability.  Improvements – It is difficult to have software reliability improvements due to insufficient understanding of software reliability with regard to the software characteristics. Time and cost constraints limit the effort put into software reliability improvements. 7.2.2 Software reliability models After familiarising ourselves with software reliability metrics, we will now discuss about software reliability models.

Sikkim Manipal University B1965 Page No. 123 Software Engineering Unit 7

We know that a particular model can work well on certain software, while it may not work at all on another. Typically, a software model contains mathematical functions, assumptions and factors. The mathematical functions contain exponential and logarithmic functions of higher order. These modelling techniques are based on accumulating the failure data and analysing them statistically by observance. Let us understand these techniques by differentiating the two modelling techniques, as given in Table 7.1. Table 7.1: Prediction Modelling and Estimation Modelling Prediction model Estimation model  In the prediction model, we can  Estimation models include predict software reliability very exponential distribution models that early in the software development are known as the fault count/fault process, and thus can be used to rate estimation model. enhance reliability.  The estimation model uses data  The prediction model uses from the current software historical data. development process.  The prediction model predicts  The estimation model estimates reliability at some future point of reliability at either the present or the time. future time.  The prediction models are used  The estimation models are not used before the development or test in the concept and developments phase, and are sometimes used phase of software. They are used in the concept phase. after data are collected for estimation.

Some of the typical software reliability improvement techniques are as follows:  Utilising good engineering methods to improve software reliability.  Examining the software product, certifying, approving and checking whether the customer requirements are met.  Testing the software product in an ad hoc manner to match the various software development projects.  Utilising different analysis tools to minimise the existence of defects after the release of the software product.  Studying and analysing the field data after assembling.  Minimising the occurrence of faults by using fault tolerance and fault forecasting techniques.

Sikkim Manipal University B1965 Page No. 124 Software Engineering Unit 7

Self-Assessment Questions 1. The two types of software reliability techniques are “trending reliability” technique and ______technique. 2. “Error seeding” is a “trending reliability technique.” (True/False) 3. The two software modelling techniques are estimation and ______.

Activity 1: Assume that you have joined as a project manager in a software company. Explain how you would use software reliability metrics in your project. (Hint: Software reliability metrics.Refer Section No. 7.2 )

7.3 Programming for Reliability In the previous section, we studied about the concept of software reliability, and the various metrics involved in estimating and predicting software reliability. In this section, we will discuss about programming for reliability with respect to fault avoidance and fault tolerance. We can define “programming for reliability” as the method of programming, where the codes in the software are made more reliable. Let us have a look at some of the concepts of programming for reliability.  Inconsistent assumptions – Inconsistent assumptions are those assumptions that are relatively avoided during the design phase of writing codes. But, we cannot avoid these assumptions during code maintenance. Code changes are made only to single functions or files; however, assumptions are made throughout the code base. We can see a lot of inconsistent assumptions related to conditions at the exit of a loop, the entry and exit points for functions and error-handling code. The static analysers are used to detect the bugs that are found in the source code of a software program without execution.  Error-handling code – Developers generally program with the intention of implementing the functionality. This method involves handling errors in codes. Sometimes, designing the test cases becomes difficult when they have error paths. The code auditors must specify the need of error- checking and must also emphasise on accuracy of error-handling. An error could have occurred simply because the programmer forgot to free

Sikkim Manipal University B1965 Page No. 125 Software Engineering Unit 7

the memory. An error-exit approach could have been performed to clean up the memory. Thus, the static analysers are once again used to ensure that the rules of consistency are followed even when errors are rarely executed during the phase of testing.  Avoiding mistakes – Every time when a bug is found in the software system by a tester, they are fixed by the developer. Sometimes the same bug/error can re-occur many times. Static analysers can easily find these repeated errors/bugs. The minor mistakes may appear as different types of errors. Sometimes while finding one type of bug, we might end up finding another type. This is a very common happening, during the detection of dead code using static analyser. Dead codes indicate problems in a software system. The static analysers are again used efficiently to examine large volumes of code. 7.3.1 Fault avoidance Since we are studying about the concept of programming for reliability, we will now discuss “fault avoidance” in a software project. We can define “fault avoidance” as the concept of avoiding faults from being introduced into a software project. We can avoid faults in a software project, by forecasting them, well in advance. The aim of fault avoidance is to ensure that the software produced is fault free. In order to produce a fault- free software project, we follow several approaches. Let us briefly discuss some general fault avoidance approaches shown in Figure 7.3.

Fig. 7.3: Fault Avoidance Approaches  Formal or precise specification method – Formal or precise specification method involves in eliminating the errors during the requirements specification and design stages of software development.

Sikkim Manipal University B1965 Page No. 126 Software Engineering Unit 7

By following the formal specification method, it is possible to know how codes can be matched and traced to the specifications thereby enhancing accuracy in programming and reducing the defects. In formal specification method, we use mathematical language like “Z Language” for specifying the requirements. Using mathematical notations ensures that there is absolutely no ambiguity in understanding the requirements, because these notations are universal.  Verification and validation techniques – Verification and validation techniques help us to detect the defects that were not detected earlier in the formal specification method. This method checks the software program in terms of quality and efficiency.  Software testing – Software testing involves testing of the software program using automated tools and detecting the software bugs in the program. In this approach of fault avoidance, the presence of faults is detected rather than its absence. Apart from the software testing activities, documentation of the entire software development process is done. The main objectives of fault avoidance are to:  Prevent the existence of faults in the operational system.  Limit the introduction of faults during system construction by following fault prevention, fault removal and fault forecasting. o Fault prevention – Fault prevention involves preventing the faults from intruding into a software system. o Fault removal – Fault removal is a method of finding and removing all the causes related to the occurrence of errors. o Fault forecasting – Fault forecasting is to predict the errors before their occurrence Therefore, fault avoidance in a software program helps us to improve the quality of a software system, by limiting the occurrence of faults during the development phase of a software system. By following the fault avoidance approaches/methodology, it is possible to protect the software system against the impact of faults during its operation. Sometimes, faults can occur due to constant use of a software system.

Sikkim Manipal University B1965 Page No. 127 Software Engineering Unit 7

7.3.2 Fault tolerance By now you must have become familiar with the concept of fault avoidance; let us now have a brief discussion on fault tolerance. Fault tolerance is the capacity of a software system to withstand/tolerate the faults that occur on it. We can say that basically the software system accepts the faults. In today’s business world, the concern is not about a particular software system’s working; rather the concern is more about the accuracy of a software system, working during mission-critical situations. The fault tolerant techniques enable the software systems to tolerate fault, which thereby enhances the reliability of the software system. Fault tolerance is a concept where your software system will operate accurately in the presence of unavoidable and undetectable faults. The bugs that are found in your software system can be eliminated by performing rigorous testing and debugging. Let us have a quick overview of the two strategies of fault tolerance.  Error processing – We can say that error processing is a method of eliminating errors by using a substituted error-free state in an erroneous state called error recovery or by using compensatory methods for providing redundancy known as error compensation. Errors can be recovered either through forward or backward recovery methods.  Fault treatment – Fault treatment involves preventing faults from creeping into the software system. Fault diagnosis and fault passivation are the two steps used. In both these steps, the nature of the fault details are well analysed and then the strategies are applied to the faults in an effective manner. Therefore, fault tolerance helps in improving the quality of a software system. Self-Assessment Questions 4. Software testing involves testing of the software program using ______tools. 5. The fault avoidance approaches followed in a software project are ______, validation and verification and software testing. 6. The two strategies of fault tolerance are error processing and ______.

Sikkim Manipal University B1965 Page No. 128 Software Engineering Unit 7

Activity 2: Imagine you are a software developer, and have been assigned the task of writing codes as well as finding errors in the code, explain the steps you would follow to check for code efficiency. (Hint: Refer Section 7.3, Programming for Reliability.)

7.4 Software Quality Metrics In Unit 6 (Software Project Management: Part 2), we learnt some of the project metrics such as size-oriented metrics and function-oriented metrics. In this section, we will learn the software quality metrics and how they are used to measure the quality in a software organisation.

Right from the stage of software engineering process till the delivery of the software product to the customer/end user, quality is measured. The metrics that we derive from the software act as the baseline for making testing decisions and design decisions. After a software product is delivered to the customer, we measure the number of defects observed during the maintainability of the system, using software quality metrics. The defect details of the product can be known to the managers only after the product is delivered to the customer.

Quality metrics play a key role in statistical quality assurance. The defects are observed during the maintenance phase along with detailed information about the cause of defect, so that right corrective action can be planned.

It is important to keep a balance between the sensitivity and the selectivity of the quality measures undertaken. The quality of the software product that is delivered to the customer is the main concern. In order to improve an organisation, the software process followed must be enhanced by effective planning, scheduling and tracking the software project along with analysing the risks involved. We require appropriate metrics for knowing the health of the process and the project in an organisation. Metrics actually check whether the quality standards set by an organisation for a particular project are being achieved in a systematic way or not.

Sikkim Manipal University B1965 Page No. 129 Software Engineering Unit 7

We can observe that different organisations follow different dimensions to measure the software quality of their product. The most common software metrics adopted by organisations are as follows:  Code coverage  Bugs per line of code  Cyclomatic complexity  Function point analysis  Number of classes and interfaces  Number of lines of customer requirements  Cohesion  Coupling  Order of growth  Source lines of code

Software quality metrics follow different dimensions to measure the quality of a software product. Metrics help to analyse the defects and take corrective actions to fix them. There are several measures of software quality, but let us consider the most important ones among them:  Correctness – We can define correctness as the accuracy of the program with which it can work or perform the task assigned. A defect per KLOC is the way of measuring the success of a program and the testing team as well. We can do this by counting the number of lines of code a program has. The customer/end-user generally reports the defects after the usage of the software product.  Maintainability – We can define maintainability as the ability of the software to allow us to maintain the software (including enhancements, etc.) after the software is delivered. When an error/bug is reported, we can correct it easily. We can make corrections to the product on the basis of customer request and environmental changes. Since maintainability cannot be measured directly, indirect methods are used. They are time-oriented metrics, so every time an error occurs in the software product, there is a change request.  Integrity – Integrity is the way in which a system protects itself from virus attacks and hackers. A program, a software document or a data

Sikkim Manipal University B1965 Page No. 130 Software Engineering Unit 7

related to a software program can be attacked. Two parameters are used in order to measure integrity. These parameters are as follows: o Threat – It is an estimation of a possibility of an attack and could be either intentional or accidental. o Security – It is the precautions taken to repel the attack on the software.  Usability – A software product must be user-friendly. We can measure usability in terms of four characteristics: o The physical/intellectual skills required to learn the software product. o Time required for becoming moderately efficient in using the software product. o The net increase in productivity by someone who is moderately efficient. o Subjective assessment (users’ opinion about the software product). The standard that is used for evaluating software quality is ISO 9126. It addresses different quality models and the metrics for software development process.  Defect Removal Efficiency (DRE) – It is the measure of counteracting defects. When the DRE is found to be low during the design and analysis phase, it simply means that a lot of time needs to be spent in the technical reviews. DRE = E / (E + D) where E = Number of errors found before delivery of the software. D = Number of errors found after delivery of the software. When the DRE value is 1, it implies that there were no defects found in the system and if the DRE is lower than 1, it implies that the system has some defects. Test coverage = Number of units (KLOC/FP) tested/total size of the system.  Quality of testing – Number of defects found during testing/(No. of defects found during testing + No. of acceptance defects found after delivery) * 100.

Sikkim Manipal University B1965 Page No. 131 Software Engineering Unit 7

Integrating metrics within software engineering process Although, most of the software developers do not find it necessary to have a process of measuring, in today’s world, the process of measuring a software product plays a very important role in a software company. It is a difficult task to implement software metrics in a company, but once their benefits are realised, the task is worth it. The way in which the software process and the software product are developed must be measured, because without following a systematic approach, it is not possible to ascertain/determine that the process followed to develop a product is good. Measurement of any process or product is mandatory, as it is proved to be very beneficial for a project from the technical point of view. In order to improve the software engineering process in an organisation, it is necessary to evaluate both productivity and quality of the process and the product. When a process by which a software product developed is improved, it proves to be of a greater value to the organisation in building its business ties. Prior to implementing the goals for improvement, we must understand the process of software development. Thus, measurement helps us to establish a baseline for a software process and helps in improving an organisation’s software engineering process. The rigorous and time-consuming processes followed in the development process of an organisation give very little time for other activities such as strategic thinking. So, more emphasis is given to issues like project estimation, production of high-quality products and adhering to right delivery schedules. A baseline for establishing the productivity and quality standards of an organisation has to be followed in order to enable better management for estimation. The quality metrics followed in an organisation help to fine-tune the defects that have a greater impact in the software development process. From a technical perspective, it is seen that when software metrics are applied to the product, they provide immediate benefits. So, every time a software product is developed by a software developer, he is very anxious to know about the product that was developed and some of the questions that arise are:  Which of the user requirements are most likely to change?

Sikkim Manipal University B1965 Page No. 132 Software Engineering Unit 7

 Which module in the system is more prone to errors?  How much testing should be planned for each module?  How many errors can be expected when testing commences? By answering all the above questions, it is possible for us to get information on whether the technical guidelines were followed or not. A baseline is a collection of data from the past developed software projects and is a combination of both simple and complex templates. In addition to the size-oriented and function-oriented metrics, baseline is supplemented by quality metrics such as correctness, maintainability, integrity and usability. Therefore, we can conclude from the above discussion that a baseline must have the following characteristics.  Data accuracy – There should be no guesswork made on the past projects.  Data collection – Mandatory collection of data for all the projects.  Data measurement – Consistent measurements must be made, for example if a line of code is used in a project, they must be interpreted. The data required to establish a baseline are collected from the ongoing project. Data collection is done based on the information garnered from earlier projects. Computation of metrics can be done only after the data have been collected. This collected data can range from LOC to function point (FP). The data thus obtained are computed and evaluated and then estimation is done. Data evaluation emphasises on the averages computed and circumstances where data cannot be used. It is necessary for a developer to make note of these points when addressing metrics data so that they are not used blindly. It is not possible to collect all the data from a project. Self-Assessment Questions 7. “Threat” and “security” are parameters used to test the metric called ______. 8. The standard that is used for evaluating software quality is ISO 9216. (True/False) 9. DRE stands for ______.

Sikkim Manipal University B1965 Page No. 133 Software Engineering Unit 7

Activity 3: Prepare a list of software quality metrics we can use for measuring the quality of software. (Hint: Refer Section 7.4, Software Quality Metrics.)

7.5 Software Reuse In the previous section, we studied the concept of programming for reliability, including fault avoidance and fault tolerance. In this section, we will discuss the software reuse. Software reuse is a new approach of building software, using the software that already exists in a company, rather than building software systems from scratch. Therefore, we can define software reuse as a process of developing new software systems from predefined software components or the existing software artefacts or assets. The requirements, specifications, design and manuals along with the test cases, test suites and business processes make up the software assets. Let us try to answer a very important question in today’s business world – “Why is software reuse necessary in today’s business world?” A huge investment is required every time a new project starts. After the completion of the project, the assets of the project remain with the company, and they are reused for other software projects. This way, a company does not have to invest again and again in creating what was already created in earlier projects; instead, for new projects it uses the concept of software reuse, thereby minimising the amount of time required for developing software for future projects. Hence, the risk involved is considerably reduced. So, we can conclude that software reuse enhances quality, reliability and productivity of a software product, and also reduces the cost and time involved in accomplishing a project. 7.5.1 Classification of software reuse We can classify software reuse into two categories, as shown in Figure 7.4.

Sikkim Manipal University B1965 Page No. 134 Software Engineering Unit 7

Fig. 7.4: Types of Software Reuse Let us now discuss about the types of software reuse on the basis of the reuse of the software.  Opportunistic reuse – In opportunistic reuse, the members of the software development team identify the assets that can be reused for another software project. We can consider this type of reuse as a cost- effective method. Scrapheap software development is a type of opportunistic reuse, where the functionalities from the discarded project and systems are reused. There are two types of opportunistic software reuse. o Internal reuse – The software development team will reuse its own software project components. o External reuse – The software development team buys a third-party component for its development purposes. This is called the COST (Commercial off-the-shelf), where a particular technology or a software component is either leased out or sold.  Planned systematic reuse – In this method of reuse, the software development team actually designs components, so that they can be used for the future projects. After studying about the types of software reuse on the basis of reuse of the software, we will now study about the two types of software reuse based on the way the software assets are reused. Let us now have a better

Sikkim Manipal University B1965 Page No. 135 Software Engineering Unit 7 understanding between the horizontal reuse and the vertical reuse from Table 7.2. Table 7.2: Horizontal and Vertical Reuse Horizontal reuse Vertical reuse Horizontal reuse refers to Vertical reuse refers to software assets that are software assets that are used by systems with similar functionality. Thus, used in most of your a new idea of study and application known as applications, for example, domain engineering came into existence. the codes used in Domain engineering provides information programming or GUI regarding the life cycle processes that an (Graphical user interfaces) organisation uses in order to enhance its strategic functions. business objectives. Horizontal reuse also uses Using domain engineering it is possible to the COTS technology, increase the production of application engineering where the software is projects by standardising the product family and bought from a third party. the associated production process. Thus, we Most of the horizontal come across the application engineering, the reusable software codes counterpart of domain engineering. can be found at various Application engineering is a process of developing locations on the internet products based on meeting customer today. requirements. The structure and form of application engineering activity is done by domain engineering. Thus, enabling the individuals working in a project and a business group to have a better understanding about their customers and deliver high-quality products to their customers, which is cost effective and is less prone to risk. Domain engineering focuses more on creation and maintenance of reuse of deposited functional areas. Application engineering emphasises more on the reuse of implementation of new products.

Software reuse has become an important concept for every software company, due to its potential benefits. It also enhances the quality of the software product and decreases the cost and time involved in the development of the software project. The software assets act as a baseline for a software project development.

Sikkim Manipal University B1965 Page No. 136 Software Engineering Unit 7

7.5.2 Advantages of software reuse We can consider software reuse as the most interesting concept in the field of software development, as there are several advantages that an organisation can benefit in the long run. We will now study about some of these advantages of software reuse:  We can systematically develop the reusable components.  We can use the systematic reuse of these components as the building block for creating new systems.  We can reduce software development time and costs.  We can increase software productivity.  We can shorten software development time.  We can improve software system interoperability.  We can develop software with fewer people.  We can move personnel more easily from project to project.  We can reduce software development and maintenance costs.  We can produce more standardised software.  We can produce better quality software and provide a powerful competitive advantage Self-Assessment Questions 10. The methodology of using software assets from previous projects is called as ______. 11. Based on software assets, software reuse can be classified into horizontal and ______. 12. In ______method of reuse, the software development team actually designs components, so that they can be used for the future projects.

Activity 4: Assume that you are put into a software project, where you have to identify the software to be reused for your new project. How will you do it? (Hint: Refer Section 7.5, Software Reuse.)

Sikkim Manipal University B1965 Page No. 137 Software Engineering Unit 7

7.6 Summary Let us now recapitulate the important concepts discussed in this unit:  Reliability is the capability to be relied upon and software reliability is the degree to which we can depend on a particular software.  Software reliability models help us to measure and project the failure rates of software. From the defect details collected, it will be possible for us to define the reliability of the software. Thus, we defined software reliability as a quality characteristic that quantifies the operational profile of a system.  There are approaches followed for software fault avoidance such as formal specification, validation and verification and software testing. These help in reducing the occurrence of fault and also prevent faults in both number and severity in a software system.  Software quality metrics focus more on the quality process involved in both the software process and the software product. By using accurate software quality metrics, it is possible to analyse and develop a methodology that is used to correct the defects in a software organisation. Some of the quality metrics in existence are correctness, maintainability, integrity and usability.  In order to start/commence a metrics program in a software organisation, the three implementation steps required are data collection, metrics computation and data evaluation. Integrating metrics in the field of software engineering is of paramount importance for any software organisation.  Software reuse, the new approach, is a method wherein software artefacts/assets created from earlier projects are reused in newer projects. These provide several advantages to software companies like reducing development time, increasing productivity, and so on.  Finally, we can conclude that software reliability is the need of today’s business world, as there is a great demand for more software products that are reliable.

7.7 Glossary Code auditors: Developers.

Sikkim Manipal University B1965 Page No. 138 Software Engineering Unit 7

Code base: An implementation of source code for an operating system or application. Dead code: Dead code is a computer programming term for code in the source code of a program which is executed but whose result is never used in any other computation. The execution of dead code retards the computation time as its results are never used. Development phase: Development phase involves the activities followed during the process of development. Functional testing: Functional testing is the process of checking whether the functionality of the software product is working as per the requirements specifications of the customer. Static analysis (also called static code analysis): Static analysis is method of detecting the errors in the software program without executing the software program. Test phase: Test phase involves the activities followed during the process of software testing.

7.8 Terminal Questions 1. Define software reliability metrics and explain the different software metrics based in a software development phase. 2. Explain fault avoidance and fault tolerance. 3. Describe software reuse. 4. List out the advantages of software reuse. 5. Describe the concepts involved in programming for reliability.

7.9 Answers Self-Assessment Questions 1. Predictive reliability 2. True 3. Prediction 4. Automated 5. Formal or precise specification 6. Fault treatment 7. Integrity 8. False

Sikkim Manipal University B1965 Page No. 139 Software Engineering Unit 7

9. Defect Removal Efficiency 10. Software reuse 11. Vertical 12. Planned systematic reuse

Terminal Questions 1. (Refer to Section 7.2 for further information.) 2. (Refer to Section 7.3 for further information.) 3. (Refer to Section 7.5 for further information.) 4. (Refer to Section 7.5 for further information.) 5. (Refer to Section 7.3 for further information.)

7.10 Case Study Empirical Software Solutions Empirical Software Systems is a small manufacture-based company with a single product in the public access and security domain. The information system that they possess gives details pertaining to the presence of individuals at specific locations, and also checks and issues security badges. The software of the system is connected to specially designed hardware peripherals along with a well-defined LAN network connection. The system handles several aspects ranging from computing from database manipulation, peripheral hardware to image handling. This company uses both software and hardware, and incorporates latest technologies such as networking and device drivers. Due to the pressure from customers and the competition, they were in need of a structured software process. There was no standardised development process. Most of their work was based on customer requests. Every time a new request from customer came in, more additions were made to the product. A new version of the software was installed at the customer’s site when requested by the customer. All the queries related to technical support, modifications made to the system, were handled by the development team. There was no specific design methodology followed and each developer used his own method of working. Apart from the user manual, there was no other documentation found held.

Sikkim Manipal University B1965 Page No. 140 Software Engineering Unit 7

Challenges:  Introduction of reuse framework and method into the company.  Gain support from the top management for the reuse program, as introduction of a reuse program can affect all parts of the software production process.  Suggestions were made to set up the reuse program along with the associated cost and risk involved in setting up the reuse program.  Study the staff view point and the development process of the company. Solution: A structured process was followed for better future prospectus. 1. Planning and reviews – Meetings were held on a regular basis, in order to plan before the commencement of the project. As the project advanced, meetings were more focused on technical issues to review what is being done so far, and also plan ahead for the next steps involved in the software project. 2. Design – An object-oriented method of design was used to support software reuse, as it has the provision for reusable design techniques and components in software development and maintenance phase. 3. Resource Management – The developers stored the reusable code in the central reusable repository, which could be accessed by all the employees in the company. 4. Documentation – Documentation process was efficiently done and well maintained to avoid discrepancies. 5. An incremental approach was carried out to introduce software reuse, so that working practices could be slowly changed and at the same time fulfil the requirements of their customers. Advantages:  The effective techniques were identified for software development process.  Code reviews were carried out and checked for reusability.  Developers could plan for their project and start writing their code in advance, and also go back to the code, if any kind of restructuring in the code is required, which will help their code to be more object-oriented and reusable.  Developers had a clear picture of what they had to create.

Sikkim Manipal University B1965 Page No. 141 Software Engineering Unit 7

 Instead of the original C++, Fotofile was developed in MS Access which led to the development of another OLE server. Object linking and embedding (OLE) helps in creating and editing documents which are created by multiple applications.  The Fotofile was used to design and print the identification badges.  This will be of great benefit in maintenance, and will also allow the developers, when going back to the code that they have written, to see how the software is currently designed. This should help them to identify useful abstractions which will be reusable  In the finished product, there was a total of just over 20,000 lines of code. Of this code, 43% was inherited from the standard libraries available through the Microsoft Foundation Classes. Of the remaining 57% of the code, 24% was automatically generated by the Visual C++ wizards. Of the remaining code which was written manually, 31% was abstracted into reusable classes that were used more than once within the application. This gives a total reuse factor of 70% for the whole project.1

Discussion Questions: 1. Explain the challenges faced by Empirical software solutions and how did they overcome it. 2. Explain details regarding software code reuse. (Hint: Refer Section 7.5, Software Reuse) References:  Pullum, Laura L. Software Fault Tolerance Techniques and Implementation. Artech House Publishers, September 30, 2001 E-References:  http://artofsoftwarereuse.com/2009/04/02/horizontal-and-vertical- software-assets/ (Retrieved on 15th May 2012)  http://portal.acm.org/citation.cfm?id=1478113 (Retrieved on 15th May 2012)

1 http://students.cs.byu.edu/~pbiggs/smallcomp.html

Sikkim Manipal University B1965 Page No. 142 Software Engineering Unit 8

Unit 8 System Engineering Structure: 8.1 Introduction Objectives 8.2 Computer System 8.3 Computer Systems Engineering Hardware engineering Software engineering Human engineering 8.4 System Analysis 8.5 System Architecture 8.6 System Specification 8.7 Summary 8.8 Glossary 8.9 Terminal Questions 8.10 Answers 8.11 Case Study

8.1 Introduction In the previous unit, we studied the software reliability and why it is so important for software organisations to ensure that the software they deliver to the customer are reliable, as software failures can lead to colossal losses, not only in financial terms but also in terms of loss of human lives. In this unit, we will study about system engineering. We will start our discussion with a computer system. Then, we will discuss about computer systems engineering (also called as “computer engineering”), which is an amalgamation of many fields of engineering, wherein we will discuss about hardware engineering, software engineering and human engineering. Thereafter, we will study about system analysis. We will also familiarise ourselves with system architecture and system architecture specification. Then, we will have a brief discussion on system specification and system specification review. This unit will enable us to understand the different concepts covered in system engineering.

Sikkim Manipal University B1965 Page No. 143 Software Engineering Unit 8

Objectives: After studying this unit, you should be able to:  explain computer systems engineering and its types  elaborate system analysis  describe the system architecture and its specifications  explain system specification review.

8.2 Computer System Let us start this unit with an overview about the computer system. We can define a system as an arrangement of different components, to form an integrated structure, in order to perform a defined task. The computer system is considered as a working system, which includes both the software and the hardware or the external peripherals such as the printer, scanner or router with a common central storage system. The computers that are connected to the central storage system operate independently, and are also able to communicate with other computers. For a computer system to function, the peripheral devices and the software are required. For example, a computer system requires software, such as an operating system, as well as the external peripheral device, a printer, in order to perform the task of printing. So, we can define a computer system as a basic functional unit, with a storage system that is used for executing either part of the program or the entire program. Basics of computer system In today’s world, we can get a better computer for a lesser price as compared to the past years. This is due to the technological improvements. So, every time we buy a computer, we must look into the requirements aspect instead of buying the advanced computer system available in the market. Therefore, we must always buy a computer that fits our needs. Let us now have a quick overview of some of the basics of computers.  Central Processing Unit (CPU) – The central processing unit is considered as the brain of the computer, which performs all the tasks of calculations and makes the programs in your computer work. If you receive the results faster, then your CPU is considered to be fast.

Sikkim Manipal University B1965 Page No. 144 Software Engineering Unit 8

 Random Access Memory (RAM) – The random access memory is called the temporary memory of the computer. The information that you use to run the programs and applications in your computer are stored in the random access memory. If your computer system has more RAM, you will be able to run more number of applications at the same time without affecting the other system operations.  Hard Disk Drive (HDD) – The hard disk of the computer is the permanent memory where all the data related to the computer system are stored; for example, data files such as PowerPoint presentations, spreadsheets and databases. If your hard disk is large, then you can store large volumes of data in it. Although the size of the hard drive does not have an impact on the speed of the program, the speed of your hard drive can have an impact on the retrieval of the files.  Optical Disk Drive (ODD) – These include optical drives such as CD, CD-RW, DVD, DVD-RW and Blu-ray Disks. Out of these, the more common ones are the Compact Disk (CD) drives and the Digital Video Disk (DVD) drives. These drives make use of a laser in order to read the data that are etched on the disk. The optical drives also come with the CD-R, denoting recordable disk, where you can burn the information only once on to the disk and no other editing can be done. The CD-RW denotes a rewritable disk where data can be rewritten as many times as possible, giving you the provision of deleting the old files and adding new ones. You can also come across the CD-ROM, which denotes the read only memory, where data cannot be modified. Blu-ray Disks are the latest addition to the group.  Floppy Disk Drive (FDD) – Floppy disk drives have very small storage capacity (1.44 MB) and are basically used for transferring data from one computer to another. Nowadays, floppy disk drives have become obsolete in most of the computers. The cost of the floppy disk drive is very meagre when compared to the cost of the compact disk drive. In order to hold hundreds of megabytes of memory, the zip drives were used in the past, but today they have been replaced by the CD-RW disks due to less cost. The size of a standard floppy disk is 3.5″.  Video card – A video card enables you to have better graphical display of the items on your display screen. The video card is inserted into the

Sikkim Manipal University B1965 Page No. 145 Software Engineering Unit 8

motherboard of the computer in order to enhance display capabilities. At present, most of the video cards come with an in-built RAM and processor to boost the graphical display. Sometimes, additional video cards are used for multimedia purposes or playing video games.  Sound card – Sound cards are also known as the audio cards, which are the expansion boards, used to enhance the sound quality of the system. Sometimes, computers come with sound chips, and hence there is a requirement to add an additional sound card to improve the sound quality. Self-Assessment Questions 1. The central processing unit acts as the ______of the computer. 2. The compact disk and digital video disks are also known as the ______drives. 3. Spreadsheet is an example of an optical disk drive. (True/False)

Activity 1: Imagine you are a trainer in a small software company. Explain how you would train the new recruits from the college, about the basics of computer and relate the practical use of computers. (Hint: Refer to Section 8.2, Computer System.)

8.3 Computer Systems Engineering In the previous section, you have studied the basics of computers, including the various parts of a computer. In this section, we will study about the different types of computer system engineering. The challenge of designing a computer system involves building a system that consists of both hardware and software components. The concept of building a computer is similar to the task of building any other electronic gadget like digital cameras, robots and embedded systems. In order to build these electronic gadgets, we must first analyse them and then design them as per our requirements. The various facets of design must be justified both technically and economically. All these activities can be clubbed together into a common discipline of study known as “system engineering.”

Sikkim Manipal University B1965 Page No. 146 Software Engineering Unit 8

Computer system engineering is an integration of many disciplines of engineering such as electronics, electrical and computers. The engineers are called computer system engineers, and they undergo training in electronic engineering and the hardware–software integration instead of just undergoing training on software engineering. System engineers are involved in several aspects of computing when it comes to designing the hardware and software. The emphasis is more on how the various components of both the hardware and the software are integrated. Computer engineers do a variety of tasks such as coding for the firmware for embedded microcontrollers, designing operating systems and analogue sensors. In the field of research and robotics, computer engineers depend on digital control systems, and track and monitor the sensors and motors. Today, there is an increase in demand for computer system engineers who will be able to design firmware, hardware and also manage the various computer systems used in an organisation. The study of computer engineering involves both analogue and digital circuitry. The prerequisite for the study of computer engineering is to have a sound knowledge of mathematics and science. A computer systems engineer also involves himself in the evaluation and installation of various types of software and other hardware support equipments in the network area of an organisation. 8.3.1 Hardware engineering Since we are discussing about computer systems engineering, we will now discuss about one of its types, namely, hardware engineering. The branch of hardware engineering has become more and more advanced considering the advancement in the field of software engineering. The field of software engineering is ever changing, and so the hardware engineering industry is also experiencing the same trend, and is considered to be under a spell of boon. Today, there is a huge demand for computer chips. Therefore, the hardware engineers are constantly working in correlation with the software engineers in developing highly capable and reliable computer chips.

Sikkim Manipal University B1965 Page No. 147 Software Engineering Unit 8

The branch of hardware engineering is based on developing and testing the components involved in building a computer system. The hardware engineers design and manufacture the new hardware components and monitor the installation as per the Bureau of Labour Statistics. Components like circuit boards and microchips are designed along with the other accessories like printers and keyboards. The main objective of computer hardware engineering is to bring about improvement in the existing technology, and the systems manufactured must function appropriately and meet the end-user’s needs. Today, most of the hardware engineers work for software companies, as both hardware and software are complementary and go hand-in-hand. We select the hardware for a computer system on the basis of some characteristics that are listed below:  Components packaged as individual building blocks.  Standardisation of interfaces among components.  Availability of numerous off-the-shelf alternatives.  Ability to determine performance, cost and availability very easily. A hardware configuration evolves from a hierarchy of “building blocks” to discrete components like integrated circuits and electronic components, such as resistors, capacitors, and so on. They all are assembled as a printed circuit board that performs assigned operations. The boards are interfaced with the bus in order to form a system component, like a single board computer, which in turn integrates to become the hardware subsystem or hardware system element. The functions that were once available on a set of PC boards with dozens of integrated circuits are now available on a single chip. 8.3.2 Software engineering Let us now study about another type of computer systems engineering, namely, software engineering. We can say that software engineering is a profession that involves designing, modifying and implementing the software in order to obtain high- quality, inexpensive, more reliable and cost-effective components. As mentioned earlier, the term “software engineering” was coined in the year 1968 at the NATO Software Engineering Conference held in Germany. The

Sikkim Manipal University B1965 Page No. 148 Software Engineering Unit 8 software engineering conference was set up to overcome the “software crisis” experienced during the early days. We use the term “software crisis,” when we face difficulty in understanding, verifying and writing the correct software programs. Some of the reasons for software crisis are complexity in code and abrupt change in code. It was always thought that a blend of art and science led to software development. The IEEE Computer Society’s Software Engineering Body of Knowledge has defined “software engineering” as the application of a systematic, disciplined, quantifiable approach to the development, operation and maintenance of software, and the study of these approaches; that is, the application of engineering to software.1 8.3.3 Human engineering We are now familiar with hardware and software engineering. Next, we will learn about human engineering. The need for learning human engineering is due to the fact that there is a human interaction involved in most of the system activities. The interaction can be as small as a dialog that drives the unit function of the system. In the early days, the users had to force themselves to understand and communicate with the computer-based systems. However, in today’s world, the concept of “user-friendliness” is used quite often, in order to make the software system appear less intimidating to the end-user who maybe a novice at handling computers. The main approach here is to ensure that the software system developed is user-friendly. While developing a software system, utmost care is taken to ensure that the software that is being developed is user-friendly. For example, when people from different cultural backgrounds interact, the interaction becomes smoother when a set of rules are followed by both the interacting parties. However, when it comes to interaction between a machine and a human, the interaction is sometimes not smooth, as there are no set rules. Every time when a human interaction is required to perform a certain task or a specific function, the system engineer allocates the required function. The components of the human engineering system are well understood, so that

1 http://en.wikipedia.org/wiki/Software_engineering Sikkim Manipal University B1965 Page No. 149 Software Engineering Unit 8 appropriate functions can be performed. Some of the components of human engineering system are human memory, knowledge representation, thinking and reasoning, visual perception and human dialog construction. We can define human engineering as a multidisciplinary activity that puts into us the knowledge inherited from psychology and technology to specify and design Human–Computer Interaction (HCI) of high quality. Let us now briefly describe the various steps involved in the human engineering process:  Activity analysis – In activity analysis, each activity that is allocated to the human element is first evaluated as per its required interaction with the other elements. Then, these activities are divided into tasks, which are further analysed.  Semantic analysis and design – In semantic analysis and design, the exact meaning of every action required by the user and the corresponding action produced by the machine are defined. The design of a “dialog” brings out the appropriate meaning of the action.  Syntactic and lexical design – In the syntactic and lexical design step, the specific forms of actions and commands are identified, and then the software and hardware are implemented, as per the action or command designed.  User environmental design – In this step, a user environment is established with the help of hardware, software and other elements. This environment will include both the Human–Computer Interaction (HCI) and physical facilities like lighting and space management.  Prototyping – In this step, prototyping takes place. A prototype is required for specifying an HCI. Using the prototyping method, it is possible to evaluate the HCI. Thus, prototyping helps us to evaluate the repetitive applications of all the human engineering steps. Self-Assessment Questions 4. Computer system engineering is also known as ______. 5. The prerequisite for the study of computer engineering is to have a sound knowledge of ______and science.

Sikkim Manipal University B1965 Page No. 150 Software Engineering Unit 8

6. The term software engineering was coined in the year 1968 at the NATO Software Engineering Conference. (True/False)

Activity 2: Imagine you have been assigned the task of checking the various integrated software engineering and human–computer interfaces in your software company. Explain how you will accomplish the task. (Hint: Refer to Section 8.3, Computer Systems Engineering.)

8.4 System Analysis The previous section familiarised us with different types of computer systems engineering. This section will familiarise us with system analysis. “System analysis” is an activity catering to most of the activities of computer system engineering. System analysis mainly focuses on the elements of the system, rather than the software. We conduct a system analysis on the basis of the following objectives:  Determine the needs of the customer.  Assess the system concept for workability.  Carry out economic and technical analysis.  Distribute functions to hardware, software, people, database and other elements of the system.  Set up cost and schedule constraints.  Create a system definition that makes the basis for all consecutive engineering work. In order to meet these objectives, the system engineer must be an expert in the field of hardware, software and also database and human engineering. It has been listed by the industry professionals that time and effort are the most important factors in the system analysis stage, as they are considered to bring out more profits to organisations in the long run. Three important questions that arise while performing system analysis are as follows:  How much effort should be expended on analysis and definition for systems and software?

Sikkim Manipal University B1965 Page No. 151 Software Engineering Unit 8

 Who does it?  Why is it so difficult?

Let us now understand some of the important steps used in system analysis. They are as follows:  Identification of need – Identifying the need is the first step in the system analysis process. The analyst or the system engineer gathers the requirements of the project. The “customer needs” and the “customer wants” are differentiated appropriately. The features critical to the system’s success are the customer needs, while the features which are just added and not really essential for the functioning of a system are called the customers wants. The details gathered during this step are specified in the “system concept document.”  Feasibility study – Feasibility study deals with the evaluation of the resources and time. Risk analysis is conducted to identify how various types of risk can affect the software process so that appropriate steps can be taken to enhance software quality.  Economic analysis – Economic analysis deals with cost–benefit analysis so that correct assessment is made for the software project. The cost–benefit analysis brings out the cost involved for the software project and also the benefits of the software system. The analysis is based on the size of the project, which is to be developed along with the desired investment and strategic plan of the organisation.  Technical analysis – Technical analysis involves evaluating the technical merits of software system and also in gathering information related to performance, reliability and maintainability. Various technical analysis tools such as probability, statistics and mathematical techniques are used.

Self-Assessment Questions 7. Industry professionals list out time and ______as the most important factors in the system analysis stage. 8. Economic analysis deals with ______analysis so that correct assessment is made for the software project.

Sikkim Manipal University B1965 Page No. 152 Software Engineering Unit 8

9. Technical analysis involves evaluating the ______merits of software system and also in gathering information related to performance, reliability and maintainability.

Activity 3: Suppose you are assigned the task to analyse the various factors involved in your project. Explain how you will gather information and proceed with the analysis task. (Hint: Refer to Section 8.4, System Analysis.)

8.5 System Architecture We studied system analysis in the previous section. Let us now study about system architecture. We can define system architecture as a conceptual structure and functional behaviour of a computer system, which is used to determine the overall organisation. It also describes the different components involved in building the system architecture and the way in which they are combined.2 Once the various functionalities of a computer-based system are allocated, we create a system model using an architecture template. We can see that within a template, a system engineer allocates the system elements to the five processing regions in the template, as shown in Figure 8.1.

Fig. 8.1: Architecture Template

2 http://www.answers.com/topic/computer-systems-architecture Sikkim Manipal University B1965 Page No. 153 Software Engineering Unit 8

As per Figure 8.1, an architecture template enables the system engineer to create a detailed hierarchy. System architecture gives us an idea about how the various functionalities and responsibilities of a particular system are divided and allocated to the various components. Thus, each divided system performs the desired set of functionality as defined. The topmost system level handles all major responsibilities of the system. The term “system architecture” is used to describe the overall design and structure of a computer network or system.3 The need for system architecture arose due to the requirement of consolidating all the physical devices. At times, the term “system architecture” is also used to describe very complex software tools that have several modules. The complexity of a system varies from one system to another, and it depends on factors such as user needs, business requirements, funding and availability of resources. System architecture must always be flexible and adhere to the ever changing needs quickly. If the structure is very rigid, then it becomes difficult to assimilate any new hardware or software. Let us now briefly learn about the four main components of system architecture. These components are as follows:  Processing power – The processing power depends on the computer or the server. The correct processor must be selected and installed on to a system. The selection of the processor is based on the software specifications, number of concurrent users and the connection strength. The processing power is considered to be the brain of the system. During the design phase, it becomes difficult to scale the criticality of the processor. Therefore, the system architecture must allow addition of processors without any kind of obstruction.  Storage space – Storage space is related to the capacity of the hard drive along with the built-in device in the system. Cost becomes an important factor because as the cost decreases, the capacity increases, and this is basically due to the production process involved. From the architecture point of view, when an element is added on to the process,

3 http://www.wisegeek.com/what-is-system-architecture.htm Sikkim Manipal University B1965 Page No. 154 Software Engineering Unit 8

the storage capacity increases, which results in a change in the physical shape.  Connectivity – In a network, connectivity is considered as an important aspect of the design of a system. The system performance can be enhanced by correctly maintaining the connectivity between the various aspects of the system. The performance of the system can be increased by upgrading the network cable, switches and routers.  User experience – User experience is the experience of the user, which is based on both the system performance and system architecture. Only when a system is well designed, it can respond to the needs of the user and also support its operations in the long run.

System architecture specification We are now familiar with the system architecture. Let us now familiarise ourselves with the system architecture specification. We can consider a system architecture specification as a high-level design document. This document provides details pertaining to the user’s requirements. The design solutions are bifurcated into hardware and software modules, and the interaction between these modules is also described. The system architecture specification acts as a model for the development of detailed design. We implement the system architecture specification in an organisation, during the early stages of development so that the quality of the system and the functionality are enhanced, thereby leading to increased assurance of correctness. When a particular component performs better than what was predicted in the system architecture section, its details are discussed in the subsection of system architecture section. Sometimes, the details might be specified in the design documents. Also, discussions about the way the particular component is divided and its interactions are mentioned. We must ensure that the design document must always be consolidated in a proper format. The specification documents give us a clear picture about the system architecture, which satisfies the functions and operations of development and also meets the business proposals. This document serves as an

Sikkim Manipal University B1965 Page No. 155 Software Engineering Unit 8 agreement, which states that the system architecture meets the requirements and when changes occur during the development phase, the change control request process has to be adopted. Self-Assessment Questions 10. The term ______is used to describe the overall design and structure of a computer network or system. 11. The system performance can be enhanced by correctly maintaining the ______between the various aspects of the system. 12. System architecture specification can be considered as a ______design document.

Activity 4: Imagine you have joined as a system engineer in a small company. Explain how you would allocate the system elements in to a template. (Hint: Refer to Section 8.5, System Architecture.)

8.6 System Specification In the previous section, we learnt about system specification architecture and its specification. We will now learn about system specification. In order to define requirements, we have to establish the specifications. We can consider the system specification as a document that is the basis/foundation of hardware engineering, software engineering, database engineering and human engineering. The system specification gives us details pertaining to the function and performance of a computer-based system, and also the constraints, which govern during the software development process. These specifications are bound by each system element. A software engineer can gather details about the role played by the software in the entire system, and the various subsystems from the system specifications. The system specifications will give you an idea about the information, which is basically the data, and control that is being input, and the corresponding output from the system. Therefore, we must make sure that the system specification must be considered as a system specification document. The details of the system specifications will be indicated by the system engineering standards.

Sikkim Manipal University B1965 Page No. 156 Software Engineering Unit 8

If the correct requirements are not established, it will lead to problems of ambiguity in the later part of the software development life cycle and thereby lead to off-schedule problems and budgetary issues. Hence, it becomes necessary for us to establish the requirements in a systematic way, so that accuracy is achieved and quality is maintained. Establishing the requirements and implementing the requirements can be achieved only when an organisation has people with sound technical and communication skills. When the requirements are weak, they can become a threat to the dependable systems that are under the phase of development. Thus, the requirements ensure that a system will not enter into an undefined state. Requirements are the first step in the designing process of software development phase. These requirements must be clear and well documented in order to generate the corresponding specifications. The specification phase plays a vital role in the construction of mission-critical systems. For example, errors that surface during the requirements and specifications phase will lead to errors in the upcoming phases of development. Each time when an error is discovered during the phase of development, the engineers trace back to the specifications and fix the errors/bugs. This may lead to wastage of time and other requirement specification errors. Sometimes, we can cite incomplete implementation of specifications or wrong assumptions as the main reasons for requirement flaws. Let us now have a better understanding of requirements and specifications. We can define a requirement as a condition needed by a user to solve a problem or achieve an objective; while a specification is a document that specifies in a complete, precise, verifiable manner, the requirements, design, behaviour or other characteristics of a system and often the procedures for determining whether these provisions have been satisfied.4 To bring more clarity to the definition of requirements and specification, we can take the example of a car. The requirement of a car could be a maximum speed of at least 120 km/h and the specification for this

4 http://www.ece.cmu.edu/~koopman/des_s99/requirements_specs/ Sikkim Manipal University B1965 Page No. 157 Software Engineering Unit 8 requirement will include the technical information regarding specific design aspects. A common term we may come across during the software developmental process is “requirements specification,” which we have comprehensively discussed in Unit 4. As explained earlier, “requirements specification” is a document that specifies the requirements of a system or a component. It includes functional requirements, performance requirements, interface requirements, design requirements along with the development standards. Therefore, requirements specification is the documentation details of all the phases involved in the software development life cycle. System specification review As we are discussing about system specification, we will also discuss about system specification review. The term “system specification review” means evaluating the accuracy of the definitions that are contained in the system specification document. Sometimes, the review phase may be ignored during the development phase. This may lead to problems while writing the source code for the system. We can define review as a process of checking the details of a subject or examining and verifying over and over, in order to ensure accuracy. A review is generally conducted by the developer or the customer to make sure that the following steps are adhered to:  The scope of the project must be correctly delineated/represented or sketched.  Functions, performance and interfaces must be defined properly.  The system must be justified by analysis of environment and development risk.  The developer and the customer must have the same perception about the objectives of the system. We will now briefly discuss about two segments of system specification review shown in Figure 8.2.

Sikkim Manipal University B1965 Page No. 158 Software Engineering Unit 8

Fig. 8.2: Segments of System Specification Review

 Management viewpoint – Management viewpoint is the review that is conducted based on management opinion, on the various business aspects pertaining to software engineering process. The following questions are generated for key management viewpoint: o Has a firm’s business need been established? Does system justification make sense? o Does the specified environment (or market) need the system that has been described? o What alternatives have been considered? o What is the development risk for each system element? o Are resources available to perform development? o Do cost and schedule bounds make sense?5 The aforementioned questions are periodically raised and answered on a regular basis, during the analysis phase of tasks in the system specification review.  Technical evaluation of system elements and functions – “Technical evaluation review” deals with the evaluation of various elements and functions that are involved in the process of software engineering. The details gathered during the technical stage of the system review and the details gathered during the allocation task stage will differ from each other due to the variation in the functions and the tasks assigned.

5 Software Engineering: A Practitioner’s Approach by Roger S. Pressman. Sikkim Manipal University B1965 Page No. 159 Software Engineering Unit 8

Let us now consider some issues that must be addressed by a typical review. These issues are as follows:  Does the functional complexity of the system agree with the assessments of development risk, cost and schedule?  Is the allocation of functions defined with the required details?  Have interfaces among system elements and also with the environment been defined in sufficient detail?  Are performance, reliability and maintainability issues addressed in the specification?  Does the system specification provide sufficient foundation for the hardware and software engineering steps that follow?6 When the system specification review is completed, other parallel path tasks start. Thus, the various elements of system engineering such as software, hardware, database elements and human elements are considered in the technical evaluation review. Self-Assessment Questions 13. System specification is a document. (True/False) 14. The two segments of system specification review are ______and technical evaluation of system elements and functions. 15. A review is conducted by the developer or the ______.

Activity 5: Imagine you are a developer in a small software company. Explain how you will conduct a system specification review. (Hint: Refer to Section 8.6, System Specification.)

8.7 Summary Let us recapitulate the important concepts discussed in this unit:  Computer systems engineering has evolved from different engineering fields such as electronic, electrical, and so on. Its types include hardware engineering, software engineering and human engineering.

6 Software Engineering, A practitioner’s Approach By Roger S. Pressman Sikkim Manipal University B1965 Page No. 160 Software Engineering Unit 8

Computer system engineering is considered as the first step in the evolution of the modern computer-based system.  Considering system analysis as the basis, the system engineer can identify the needs of the customer, determine the economic and technical feasibility and also allocate performance and function to software, hardware, people and the databases, which make up the key system elements.  Architectural models of a system can be produced and developed from each major subsystem. System specification and system specification review contain the documentation details of the various phases involved in the software engineering process.  We concluded that computer system engineering is a necessity, when it comes to developing a software system.

8.8 Glossary Analogue sensors: Analogue sensors measure information that is continuous. The Get operation returns the present state of the sensor, while the Update operation indicates the change state of the sensor. Bus: A bus is a transmission channel through which signals are sent and received at the point where a physical device is attached. CASE (Computer-Aided Software Engineering): CASE tools help the project managers in all the activities involved in the software process. The CASE tools automate the project management activities. This tool helps us analyse, design, code and test. Firmware: Firmware is used to denote the small programs that are found in electronic devices and are used to control the various activities of the electronic device. NATO: The North Atlantic Treaty Organisation is an intergovernmental military alliance. This is a collective defence force, where the member states have a mutual understanding for defence, in response to an attack, by an enemy. Processor (CPU): The processor is also known as the central processing unit and all numeric data are processed. RAM (Random Access Memory): Random access memory is a volatile memory. It loses the stored information, when there is no power. It is different from the non-volatile memory such as a hard disk. Sikkim Manipal University B1965 Page No. 161 Software Engineering Unit 8

8.9 Terminal Questions 1. Explain the basics of computer system. 2. Define computer system engineering and also describe software engineering, hardware engineering and human engineering. 3. Explain system analysis and how does it help in a development life cycle. 4. Explain system architecture and describe specification of system architecture. 5. Describe the system specification review.

8.10 Answers Self-Assessment Questions 1. Brain 2. Optical disk 3. False 4. Computer Engineering 5. Mathematics 6. False 7. Effort 8. Cost–benefit 9. Technical 10. System architecture 11. Connectivity 12. High-level 13. True 14. Management viewpoint 15. Customer Terminal Questions 1. (Refer to Section 8.2 for further information.) 2. (Refer to Section 8.3 for further information.) 3. (Refer to Section 8.4 for further information.) 4. (Refer to Sections 8.5 and 8.6 for further information.) 5. (Refer to Section 8.6 for further information.)

Sikkim Manipal University B1965 Page No. 162 Software Engineering Unit 8

8.11 Case Study Computerised Physician Order Entry Systems for Medications Nishant Health Care System Background: The Nishant Health Care System is a health care system, which is located in the town of Satara. This health care system has several units, which handle the various departments. Each of the unit has its predefined set of goals and objectives, like the research unit, report unit, diagnosis unit and consultation units. For example, the doctors and the research scientists were unable to login to the cases at the same instance of time. The system that is used at present slows down the process when simultaneous access of data occurs. This was due to the other parallel tasks that are ongoing in the system. For example, when the patient information is printed in one of the units, the system slows down and the other unit would not perform the requested function and also when performing a task, there were no prompts and instructions on the display screen, to proceed to the next step. All these drawbacks had to be overcome, and hence an integrated system was thought of. Thus, a Computerised Physician Order Entry (CPOE) System was designed, which helped the health care system authorities to overcome their drawbacks. Issues: Doctors had difficulty in communicating the case data to the research scientists. A common documentation was established across the health care system. Method: The authorities in the nursing home came up with the integration of Software Engineering (SE) and Human–Computer Interface (HCI). Several interesting models and activities were put to practice. The ergonomic perspective of designing an user interaction equipment at the work place, in order to make it more user-friendly, so that the problem which was faced earlier by the health care system, does not repeat again. Also, the other technicalities involved in designing the system were considered.

Sikkim Manipal University B1965 Page No. 163 Software Engineering Unit 8

A comparative study was made between the previous situations and the present situation. Results: The latest techniques helped Nishant Health Care System with a common work support. The cases in the nursing home could be easily accessed by the research scientists as well as the doctors simultaneously. Discussion Question: 1. Explain how “Nishant Health Care Systems,” accomplished having an integrated system of software engineering and human interface.

References/E-References: References:  Pressman, Roger S. Software Engineering: A Practitioner’s Approach. McGraw-hill Higher Education, 2010

Sikkim Manipal University B1965 Page No. 164 Software Engineering Unit 9

Unit 9 Analysis Concepts and Principles

Structure: 9.1 Introduction Objectives 9.2 Requirement Analysis Analysis tasks 9.3 Communication Problem areas Communication techniques 9.4 Analysis Principles Understanding information domain Creating models Partitioning the problem Processing information 9.5 Software Prototyping Prototyping methods and tools 9.6 Software Requirements Specification 9.7 Summary 9.8 Glossary 9.9 Terminal Questions 9.10 Answers 9.11 Case Study

9.1 Introduction In the previous unit, we discussed about system engineering wherein we described the three types of computer systems engineering, namely, hardware engineering, software engineering and human engineering. We also discussed about system analysis and analysed the specifications of system architecture. In this unit, we will revisit requirement analysis in software engineering, study various analysis principles and the scope of communication in software engineering. We will also analyse the problem areas and techniques of communication. We will discuss the importance of software prototyping and various prototyping methods. The need for Software Requirements Specification (SRS) will be reiterated, and we will also study how the specification is reviewed. Sikkim Manipal University B1965 Page No. 165 Software Engineering Unit 9

The unit will enable us to analyse the requirements of both the developer and the user using various principles. We create prototypes or provide the specification documentation to check the requirements. Objectives: After studying this unit, you should be able to:  explain requirement analysis and the analysis tasks  describe the scope of communication  explain the analysis principles  demonstrate software prototyping and software specification

9.2 Requirement Analysis Let us start our discussion by revisiting the concept of requirement analysis. Requirement analysis (or requirements engineering) is one of the tasks performed under the analysis phase of software engineering. We will discuss the other tasks performed under the analysis phase of software engineering later in this section. It is a process of analysing the customer requirements and prospects for a new or changed product. All these requirements should be finite, appropriate and comprehensive. This analysis is carried out through a planned system. We can say that the requirement analysis is a process:  Initiated at the start of a project and it continues throughout the life cycle by constantly undergoing modifications.  That recognises software needs and deals with them by using software configuration management methods.  That adapts to the organisation and project background. You must note that the requirement analysis is a vital aspect of project management. The software requirement analysis links the gap between software design and system engineering as shown in Figure 9.1.

Software Software System requirement design engineering analysis

Fig. 9.1: Requirement Analysis as a Bridge Sikkim Manipal University B1965 Page No. 166 Software Engineering Unit 9

We must understand that requirement analysis is a group work that involves both hardware and software and human factors who are experts in engineering and have talent in dealing with people. The requirement analysis offers you (as a software developer) with a representation of information, function and behaviour that can be transformed to data, architectural, interface and component-level designs. It is the means to assess quality by both the client and the developer while the software is being developed. 9.2.1 Analysis tasks Now that we have recapitulated the requirement analysis phase of software engineering, let us now discuss about the analysis tasks. We know that analysis is an important phase of software engineering. In the analysis phase, we concentrate on the information domain of the software, its main functions, and so on, for analysing the nature of the program to be developed. The main purpose of this phase is to determine the need and specify the problem that is to be solved. Normally, the analysis phase involves the following four tasks or operations.  Feasibility study – This task or operation includes an elaborate study of all the needs for determining the possibility to meet all these needs or requirements. This process may involve a visit by the development team to the client’s premises for their system study. The team examines the requirement for possible software automation within the ambit of the given system.  Broad planning – This task involves the creation of an outline document depicting proper planning of available resources and time.  Technology selection – It comprises identifying, analysing and compiling different tools and technologies, which would be required for the successful accomplishment of the project.  Requirement analysis – This task includes the identification and compilation of different needs of human resources, hardware and software, which would be required for successful accomplishment of the project.

Sikkim Manipal University B1965 Page No. 167 Software Engineering Unit 9

We can categorise software requirement analysis into five domains as shown in Figure 9.2.

Fig. 9.2: Domains of Software Requirement Analysis Let us now briefly describe the domains depicted in Figure 9.2.  Problem identification – This is one of the main tasks performed during the analysis phase. We study the system specification and the software project plan in this task. It is necessary to understand software in a system environment and to review the range of software that is used to produce estimations of planning. After we identify the problem, communication takes place. Communication for analysis is vital in recognising the problem and confirming it. Our main aim is to identify the basic issues as observed by the client/users.  Evaluation and synthesis – In the next domain, we evaluate the issue and propose a solution that turns out to be a great area of effort for analysis. We must describe all visually observable data objects, validate the flow and content of information, describe and explain in detail all software functions, understand software behaviour in the framework of events that affect the system, develop characteristics of system interface and clearly explain the design constraints. All these tasks aid in explaining the problem, so that we can propose a holistic solution.  Modelling – Throughout the valuation and solution proposal activity, we need to develop models of the system to have a better understanding of the data and control flow, functional processing, operational behaviour and information content. The model assists as a base for software design and as the source for creation of specifications for the software.

Sikkim Manipal University B1965 Page No. 168 Software Engineering Unit 9

 Specification – After the analysis of the problem and the essentials, we must detail the requirements in a document named as “Software Requirements Specification (SRS).” This document consists of all the function-related and performance-related requirements, the format for inputs and outputs and all the existing design constraints. You have already learnt in detail about the SRS in Unit 4.  Review – This is the last task performed under the analysis phase. Here, we review and validate the requirements detailed in the SRS. The main purpose of this task is to ensure the presence of all the requirements in the SRS document. We must perform a critical review of the requirements specification. Usually, a group of people including representatives of the client performs this task.

Self-Assessment Questions 1. Requirement analysis is one of the tasks performed under the ______phase of software engineering. 2. The software requirement analysis links the gap between software design and system engineering. (True/False) 3. ______for analysis is vital in recognising the problem and confirming it.

9.3 Communication In the previous section, we had an overview of one element of successful software development, “Requirement Analysis” and its tasks. In this section, we will discuss about another important element of successful software development, namely “Communication.” Communication helps us to gather and form relevant information, share knowledge and create functioning products. Communication provides better vision of the processes and products than a program or code. 9.3.1 Problem areas As we are discussing about communication, let us have an overview of the problematic areas associated with it. You might have seen that an individual works in one or more projects that are carried out in an organisational framework. Communication is very

Sikkim Manipal University B1965 Page No. 169 Software Engineering Unit 9 important for teams that are distributed and also for co-located inter- organisational associations between various projects. Software engineering and human–computer interaction are the two disciplines that lack communication, despite the fact that these two disciplines work simultaneously on different software projects on a daily basis. In both these disciplines, different terminologies are used for the same tasks. In many cases, loss of efficiency takes place because of the highly overlapping functions performed by engineers in these two disciplines, often performed at twice the cost where the functions that can be performed by only one person are performed by two or more persons. Today, we all have acknowledged that the problems in communication are the main reasons behind the delay and failure of software projects. As extensive communication for conveying information both within the development team and with the different stakeholders is expensive and time consuming, therefore one-way communication is opted for in the form of specification documents (such as “SRS”). Some people argue that this is an ineffective form of communication as documentation does not clarify doubts and misunderstandings. Another communication problem that we notice is the presence of organisational barriers that restrict communication among the development teams. For example, in conventional software engineering, the processes and functions to be carried out by various groups of developers/ programmers are classified into several phases. This can restrict the effective and on-time communication among the groups working in different phases. If we try to solve these problems, we can successfully complete our software projects on time and deliver the products to our clients without brooking unnecessary delay if we make an attempt to solve the above problems. 9.3.2 Communication techniques We will now study the types of communications, namely informal and formal communication and the associated techniques. We can define formal communication as the communication through the written specification documents, reports, status meetings, protocols, source

Sikkim Manipal University B1965 Page No. 170 Software Engineering Unit 9 code, and so on. The techniques involved in this form of communication are as follows:  Group, directing group and breakthrough meetings where the entire team (group) is summoned for meetings that are conducted regularly.  Status meetings where the personnel presents the status of the project results.  Formal meetings using communication channels.  Formal documentation that is shared with all the team members and associated people. Informal communication is an explicit communication via diverse communication channels like telephone, video and audio conference, voice mail, e-mail and other verbal communications. The techniques involved in this form of communication are as follows:  Face-to-face discussions such as informal group meetings.  Informal discussions using various communication channels like e-mails, videoconferencing and others.  Any means of ad hoc communication. We can describe the ad hoc activities as interactions forming a logical communicative element, consisting of one or more sequences with internal continuity. They do not have association with ambient process. Ad hoc communication arises when a team member suddenly interrupts another team member by asking questions or to provide unnecessary information that is unwarranted.

Self-Assessment Questions 4. ______helps us in gathering and forming relevant information, sharing knowledge and creating functioning product. 5. ______in communications are the main reasons behind the delay and failure of software projects. 6. The two types of communication are formal and ______. 7. Communication is not important in software engineering. (True/False)

Sikkim Manipal University B1965 Page No. 171 Software Engineering Unit 9

Activity 1: Imagine that you are the manager leading a group of software developers. Prepare a list of all the communication requirements that the team member should possess. What the basic problems you find in the communication of software engineers? (Hint: Refer to Section 9.3.1, Problem areas)

9.4 Analysis Principles By now we have become familiar with analysis concepts. We will now discuss analysis principles. We can observe that many analysis modelling methods have been developed over the past few years. Investigators have identified the analysis issues and the causes for these issues. They have solved the issues by continuously developing various modelling methods. Note that the analysis methods are unique and are associated by a set of operational principles. Let us have a look at these principles below:  Represent and understand the information domain of a problem.  Define the performance functions of the software.  Represent the behaviour of the software.  The hierarchy of the model should be clearly partitioned that depicts information, function and behaviour.  The entire analysis process should go from necessary information towards implementation aspect. We must tackle a problem systematically by using the above principles. The information domain is thoroughly studied to gain an in-depth understanding. We must develop models to make others understand the features and behaviour of function. The problems are partitioned to decrease the complexity. It is necessary to understand the constraints of the software and implementation aspects. The logical constraints are raised due to processing requirements and the physical constraints are due to system elements. Sikkim Manipal University B1965 Page No. 172 Software Engineering Unit 9

We will now learn about these principles one by one.

9.4.1 Understanding information domain Let us now briefly discuss the first principle, which is about understanding information domain. Software applications are collectively called data processing. Software is developed to achieve the following.  Process data  Modify data from one form to another (input to output)  Generate output Events are processed by software. An event is a representation of an aspect of system control, which is a Boolean data (either on or off, true or false, present or not present). For example, a temperature sensor detects the temperature; when the temperature exceeds the threshold value, an alarm signal is sent to the monitoring software. In this example, the event is to control the system behaviour by the alarm signal. Both data and control are constituents of the information domain. You must consider few aspects for understanding the information domain. The following are the aspects of information domain’s data and control and each of these is processed by a software program:  Data model depicting information content and links  Flow of information/Information flow  Structure of information Data model depicting information content and links In the information domain, there needs to be a data model that signifies the information content and links. The information content depicts individual data and control objects, which comprises large collection of information altered by the software. We can refer the content of a control object as the termed system status. It is defined by a bit pattern. Each bit corresponds to a different aspect of information that represents whether a particular device is online or offline. Data and control objects can be linked to other data and control objects.

Sikkim Manipal University B1965 Page No. 173 Software Engineering Unit 9

Flow of information/Information flow The second aspect that we must consider is “information flow” which depicts the way in which the data and control alter as each of them pass through a system. You can see the input objects being transformed to output shown in Figure 9.3.

Inputs Transform 1

Intermediary data and control

Store - Transform 2 Data/Control

Outputs

Fig. 9.3: Pictorial Representation of Information Flow We can add information along the transformation path which is available in the store. The transformations added to the data are functions/sub-functions that a program needs to execute. Structure of information This aspect of “information structure” depicts the internal organisation of different data and control aspects. An assessment of information structure answers all the queries related to information structure such as hierarchical structure, link between different information, and so on.

9.4.2 Creating models After discussing the principle of understanding the information domain, we will now discuss the second principle of “creating models.” Note that functional models are created to demonstrate the creation of models for gaining better knowledge to build the actual entity. If the entity is a physical object, we can create a model that is similar in form and shape to the physical object but smaller in dimension. If the entity is software, the model created should have the capability to represent the information that software transforms, the functions that facilitate the transformation to happen and the behaviour of the system as the transformation happens. We will now briefly demonstrate two types of models: functional models and behavioural models.

Sikkim Manipal University B1965 Page No. 174 Software Engineering Unit 9

Functional models In functional models, information is transformed by software; to do so, the software should perform three functions, namely: input, processing and output. We should focus on functions specific to issues/problems when we create a functional model of an application. The functional model starts with naming the software. Along the process that is a series of repetitions more details of the function are given. The details are given until a thorough description of the entire system functionality is presented. Behavioural models The basis of the behavioural model is the response of software to the events from the outside world (users). A computer program takes various states (such as wait, compute, print), which can be externally observed, and the state changes only when an event occurs. For example, software continues to be in wait state until:  The internal clock indicates that time period has passed.  Interrupt is caused due to external event, or.  Signals or commands are given by an external system to the software to execute in a given manner. A behavioural model creates an illustration of the states of the software and the events that facilitates the software to change state. You might have noticed that the models created during requirements analysis are very important. Let us analyse their importance from the below- mentioned points.  The model helps us to understand the information, function and behaviour of a system. Hence, the requirements analysis task is made easier and systematic.  The model becomes the vital point for review and thus provides solution to determine the completeness, consistency and correctness of the specifications.  The model becomes the base for design; the required representation of the software that can be mapped into an implementation aspect is given to the designer.

Sikkim Manipal University B1965 Page No. 175 Software Engineering Unit 9

9.4.3 Partitioning the problem As we are discussing about the analysis principles and have already discussed about the principle of understanding the information domain and the principle of creating models, we will now discuss another principle, namely, “partitioning the problem.” Problems are always broad and complex to understand. To understand the problem better, we partition the problems into parts for getting a clear picture, and we also establish interfaces between the parts so that the entire function can be accomplished. Theoretically, hierarchical representation is first established and later the uppermost element is partitioned by the following. More details are found by moving vertically in the hierarchy. For example, if we consider Figure 9.4, we can notice the sub-functions related to SafeHome function, illustrated by representing the details vertically in hierarchy. Vertical partitioning

Observe System sensor configuration status

Sensor Check type event poll of event Sensor- SafeHome Sensors to Activate/ software monitor Deactivate Activate Activation alarm of alarm (sound) function Call – dial Interaction phone with number user Fig. 9.4: Vertical Partitioning Decompose the problem functionally by moving horizontally in the hierarchy. For example, if we consider Figure 9.5 where the horizontal decomposition of SafeHome is illustrated, we will notice that the problem is partitioned, showing the functions moving horizontally in the hierarchy.

Sikkim Manipal University B1965 Page No. 176 Software Engineering Unit 9

SafeHome software

System Sensors to Interaction with Configuration monitor user

Horizontal Partitioning

Fig. 9.5: Horizontal Partitioning

9.4.4 Processing information After the problem partition, we will now familiarise ourselves with the principle of “processing information.” There are two views related to information, namely, the essential view and the implementation view. In the essential view, we must present the functions to be accomplished and the information to be processed without considering the implementation details. For example, the essential view of the sensor is to only read the sensor status; it is not concerned about the physical form of the data or the sensor used. The implementation view of the software requirement is the depiction of the real world demonstration of processing functions and information structures. Let us consider an example of SafeHome, which is a device that consists of sensors used to detect all situations. This device can be programmed by the owner and will automatically call a monitoring agency when any situation that requires monitoring is detected. For example, consider a SafeHome input device which is a perimeter sensor. The sensor detects prohibited entry by sensing a break in the electronic circuit. The general features of the sensor should be observed as part of an SRS. We can identify the constraints raised by predefined system elements that are sensors and consider the implementation view of function and information when such a view is relevant.

Self-Assessment Questions 8. The basis of the behavioural model is the ______of software to the events from outside world (users).

Sikkim Manipal University B1965 Page No. 177 Software Engineering Unit 9

9. In the ______view, we must present the functions to be accomplished and the information to be processed without considering the implementation details. 10. In ______models, information is transformed by software.

9.5 Software Prototyping After studying the analysis concepts and principles, we will now have a discussion on “Software Prototyping.” We can define software prototyping as the rapid development of software to evaluate the requirements. Prototype is developed to facilitate you and developers to understand the requirements for the system. Prototype is necessary at the start of the analysis because creating models is the only way through which requirements can be efficiently derived. The model then grows into production software. Thus, the prototype is considered to reduce risk which in-turn reduces requirements risks. Let us have a quick overview of the benefits of establishing a prototype in the software process as given below.  Confusions between software developers and users may be recognised as the system functions are verified.  Missing user services may be spotted.  User services that are difficult to use or confusing can be detected and corrected.  Software development team can find incomplete and/or inconsistent needs as the prototype is established.  Though limited, a working system is readily available to determine the possibility and effectiveness of the application to management.  The prototype offers basis for writing the specification for a production quality system.

9.5.1 Prototyping methods and tools As we are now familiar with the concept of prototyping, let us proceed forward and have a discussion on prototyping methods and tools.

Sikkim Manipal University B1965 Page No. 178 Software Engineering Unit 9

A prototype is said to be effective when it is rapidly developed so that the client or user assesses the results and mentions changes. We can follow any of the techniques given below, to carry out rapid prototyping.  4GT – This is the fourth generation technique that involves extensive collection of database query and reporting languages, program and application generators and other high level languages. 4GT is said to be very ideal for rapid prototyping because it facilitates the software engineer to develop an executable code rapidly.  Formal specification – Many formal specification languages have been developed replacing natural language specification techniques. Currently, developers of formal languages are in the course of developing interactive environments to enable us to interactively create language-based specifications of a software or system, invoke automated tools to modify language-based specifications into executable code and facilitate the client/customer to use the prototype executable code to polish and upgrade formal requirements.  Reusable software elements – This method involves assembling a set of available software elements instead of building a new prototype from scratch. This method of merging prototyping and program element reuse works if library system is developed so that the elements present can be categorised and recovered. The software product that is available can be utilised as a prototype to develop a new and improved product. This is in a way a kind of reusability for software prototyping. If we talk about tools, the tools facilitate designs to be easily explained, shared for review and used to create the specification document. Let us see the four types of tools used to create user interface prototypes.  Manual drawing using pen and paper – This is a good method as it gives the opportunity to anybody to get involved in the design process. We can create layouts of designs not only on paper but also on whiteboards – computers are not involved at all. The hand-drawn designs or pre-existing designs can be used to create a new design. We can quickly create the designs but cannot easily modify them. It is better to effectively utilise the time before laying out the design on paper. During tests and reviews, you should present the effects of user actions on a design.

Sikkim Manipal University B1965 Page No. 179 Software Engineering Unit 9

 Drawing tools – Drawing tools such as Microsoft Visio and others consisting of stencils are used. Many tools are based on graphic images. Graphic editors like Adobe Photoshop are used to create interface mock ups. A wide range of graphic editors are found with web designers. The results of drawing and graphic tools are a set of static screen designs but there is no easy way to dynamically understand how the parts work and the workflow between them. Records of techniques are available to take care of the limitations. Printouts of the screens are taken and are reviewed.  Development tools – Development tools are optional. The advantage is the ability to produce a completely working prototype that acts as a real object even if some real and definite functionality is being simulated with false data.  Specialised prototyping tools – The benefits of drawing tools, development tools and specialised prototyping tools like Graphical User Interface (GUI – an interface between a user and a computer system, using the cursor on a mouse-controlled screen for making choices, starting programs by clicking icons, and so on). “Design Studio” (a GUI design tool for Microsoft Windows, which can be used for rapid creation of demonstration prototypes excluding any coding or scripting) are combined to create software prototypes with elements which allow the interaction and workflow to be undertaken. They are explicit for the design of user interfaces and are very easy to use as they do not require any technical skills.

Self-Assessment Questions 11. ______is a graphical user interface design tool for Microsoft Windows that can be used for rapid creation of demonstration prototypes excluding any coding or scripting. 12. The advantage of ______is the ability to produce a completely working prototype that acts as a real object even if some real and definite functionality is being simulated with false data. 13. 4GT stands for ______.

Sikkim Manipal University B1965 Page No. 180 Software Engineering Unit 9

9.6 Software Requirements Specification The previous section familiarised us with an important aspect of software development, that is, software prototyping. Let us now recapitulate software requirements specification that will help us to understand specifications review. Specification is a document that describes the requirements of a system from the user point of view. SRS is a complete description of the function, performance and environment for the software under development. SRS is provided at the end of analysis task. SRS specifies functional description in detail, represents system behaviour, performance requirements, design constraints, relevant validation conditions and other information related to the requirements such as security, maintainability, reliability, auditability, and so on. Almost all organisations have proposed their own formats for SRS. Let us now briefly describe the sections of SRS (according to the typical format). The sections are as follows:  Introduction – The goals and objectives of the software are specified. They are described in the context of the computer-based system.  Information description – It gives you a detailed description of the issues that the software should resolve. The information content, flow and construction are mentioned. Both hardware and software along with human interfaces are described for external system elements and internal software functions.  Functional description – In this section, we describe all the functions required to solve the issue. We provide every function in a narrative way and we also state design constraints, performance characteristics and graphical representation of the structure of the software and other system components.  Behavioural description – This section specifies the external events that are produced during examination of the operation of software. The operation of the software is examined as a consequence of specification of external events. This section also specifies the control characteristics that are internally generated.

Sikkim Manipal University B1965 Page No. 181 Software Engineering Unit 9

 Validation conditions – This is the most important section of SRS. It specifies certain conditions or measures as to how to identify a successful implementation, the kinds of tests that should be conducted to evaluate function, performance and constraints. This section is noted to be neglected because completing it requires in-depth understanding of system requirements which is something not available at this level. However, specification of validation condition behaves as an implicit review of other requirements.  Bibliography and Appendix – References to all documents that relate to the software are specified in bibliography. It also includes additional software engineering documentation, technical references, vendor- literature and standards. The appendix includes information that complements the specifications. It also includes detailed description of algorithms, results additional information, tabular data, graphs and others. As explained in Unit 4, SRS should be proper, unambiguous, complete, consistent, stable, ranked for importance, verifiable, modifiable and traceable. We may supplement SRS by an executable prototype, a paper prototype or a preliminary user manual. The preliminary user manual gives importance for user input and the corresponding output. The manual serves as a vital tool for detecting issues at the human–machine interface level.

9.6.1 Specifications review After studying the sections of SRS, let us now briefly study about the specifications review. SRS is reviewed by both the software developer and the client. The specification is the base of the development stage and we must take great care in conducting the review. The reviewers attempt to make sure that the specification is complete, consistent and accurate by considering the overall information, functional and behavioural areas. The reviewers can be specialists in reviewing, invited experts, people interested in the product, people from same team or other division of the organisation. Let us see the guidelines for any review, as given below.

Sikkim Manipal University B1965 Page No. 182 Software Engineering Unit 9

1. Before review o Plan formal reviews as a part of project planning. o Keep all the reviewers in the loop. o Assure all participants prepare in advance. 2. During review o Review the product (author should not review) – comments given should be constructive, task-focussed and professional. o Go with the agenda – any deviation should be thwarted by the leader. o Limit debate and rebuttal – issues are noted down for later discussion. o Recognise the problems. o Record the proceedings. 3. After review o Review the complete process. Generally, we follow a checklist too for specifications review. The checklist consists of questions that produce a negative response. Following are few questions specified in the checklist.  Do given goals and objectives for software remain consistent with the system goals and objectives?  Have all data objects been explained?  Are design constraints realistic?  Are technological risks completely described?  Is the behaviour of the software consistent with the information it must process and the functions it must execute?  Have functions been elaborated to a good level of detail? Let us see an example of an extract of a checklist for minimum requirements of an SRS in Table 9.1.

Sikkim Manipal University B1965 Page No. 183 Software Engineering Unit 9

Table 9.1: Checklist for SRS Serial Yes/ Remarks/Co no. No mments 1. Is the project formally accepted by the client? 2. Has the client accepted the final SRS document? 3. Are there any issues in the requirements? 4. Can each requirement be tested and verified? 5. Are interfaces with other hardware /software systems completely specified in the SRS? The specification becomes the contract for software development. During the review, changes can be recommended to the specification. It is difficult to assess the global impact of a change. For example, it is difficult to assess how the requirements of other functions are affected if there is a change in one function. Modern software engineering environments use various tools such as Computer-Aided Software Engineering (CASE) that have been developed to solve these issues.

Self-Assessment Questions 14. Behavioural description section in SRS specifies the external events that are produced during ______of the operation of software. 15. ______is a complete description of the function, performance and environment for the software under development. 16. Software requirements specification is reviewed by both the software developer and the client. (True/False) 17. During the review, changes cannot be recommended to the specification. (True/False)

Activity 2: Assume that you are a project manager for a library management software project. Prepare a checklist for the SRS. (Hint: Refer to section 9.6.1, Specifications review.)

Sikkim Manipal University B1965 Page No. 184 Software Engineering Unit 9

9.7 Summary Let us now recapitulate the important concepts discussed in this unit:  Requirement analysis is the first step in the software process. A general statement of scope of software is developed into a strong specification at this stage which in turn, becomes the base for all software engineering activities.  Requirement analysis specifies a step-wise use of principles, languages, techniques and tools for efficient analysis, documentation and accommodating the continuously growing needs of user, and the specification of visible behaviour of a system with the end goal of meeting the user requirements.  There are five domains of software requirements analysis, namely, problem identification, evaluation and synthesis, modelling, specification and review.  Communication is an integral element of successful software development and can be done by formal as well as informal techniques.  There are two types of models in the context of analysis – functional model and behavioural model. Problems are always broad and complex to understand. To understand the problem better, we partition the problems into smaller parts for getting a clear picture, and we also establish interfaces between the parts so that the entire function can be accomplished. Structure illustrates the core of requirements and details of implementation are developed later.  Prototyping facilitates an alternative method that results in an executable model of the software from which requirements can be developed. Special tools and techniques are used to carry out prototyping, such as drawing tools like Visio, and so on.  The SRS is the final output of the analysis phase. Review is an important aspect to assure that the developer and the client have similar understanding of the system. This helps to reduce “impedance mismatch” between these two.

Sikkim Manipal University B1965 Page No. 185 Software Engineering Unit 9

9.8 Glossary CASE tool: It is a software tool, like a design editor or a program debugger, which is used to support an activity in the software development process. Human factors: Human factors are also called ergonomics. It is the study of how humans act physically and psychologically in relation to particular environments, products or services. User interface design: The process of designing the method in which the system users can access the system functionality and the information generated by the system is displayed. Validation: The method of checking that the system meets the requirements and expectations of the client is validation. Verification: The method of checking that the system meets its specification is verification.

9.9 Terminal Questions 1. Explain requirement analysis. 2. Briefly describe the problem areas of communication. 3. Explain briefly the analysis principles. 4. What is software prototyping? 5. Explain the prototyping techniques and tools. 6. What is a software requirements specification? Explain with an example.

9.10 Answers Self-Assessment Questions 1. Analysis 2. True 3. Communication 4. Communication 5. Problems 6. Informal 7. False 8. Response

Sikkim Manipal University B1965 Page No. 186 Software Engineering Unit 9

9. Essential 10. Functional 11. Design studio 12. Development tools 13. Fourth generation technique 14. Examination 15. SRS 16. True 17. False

Terminal Questions 1. (Refer to Section 9.2 for further information.) 2. (Refer to Section 9.3.1 for further information.) 3. (Refer to Section 9.4 for further information.) 4. (Refer to Section 9.5 for further information.) 5. (Refer to Section 9.5.1 for further information.) 6. (Refer to Section 9.6 for further information.)

9.10 Case Study Failure of a Mission-Critical Software The maiden flight of the Ariane 5 was a failure, about 40 seconds after initiation of the flight sequence. At a height of about 3,700 m above the ground, the launcher deviated from its flight path, broke up and exploded. The failure was due to entire loss of guidance and attitude information. The failure report said “the loss of information was because of specification and design errors in the software of inertial reference system.” Extensive reviews and tests conducted during the launcher’s development programme did not include sufficient analysis and testing of the inertial reference system or of the entire flight control system (FCS).1 The program was reused from Ariane 4 guidance system. The Ariane 4 has different flight features in the first 30 seconds of flight and exception conditions were produced on both inertial guidance system channels of the Ariane 5.

1 Case study referred from http://www.rvs.uni-bielefeld.de/publications/Reports/ariane.html Sikkim Manipal University B1965 Page No. 187 Software Engineering Unit 9

The programming language was also considered. The documents of Ariane 5 were later thoroughly studied. The requirement specification and the design specifications of Ariane 5 were not considered and that the program of Ariane 4 was used which had different requirement specifications. The failure was due to either requirement or design specifications. The faults that caused the failure of the rocket were partly due to programming, design errors and requirement errors. This case study illustrates issues mainly related to requirement specifications, critical systems validation and problems of software reuse. It shows that good software engineering can have problems (reuse). Discussion Questions: 1. List the factors that led to the failure of the rocket. 2. According to you, what is the first step of the process (initial step) to reuse the program from another system? 3. Illustrate a similar scenario or any software engineering issues around you.

References/E-References: E-References:  http://www.itswtech.org/Lec/Rand%28SoftwareEng%29/Software%20 Engineerin%20%20%204.pdf (Retrieved on 15th May 2012)  http://www.rspa.com/checklists/reqspec.html (Retrieved on 15th May 2012)  http://microscotoolsinc.com/Howsrs.php (Retrieved on 15th May 2012)

Sikkim Manipal University B1965 Page No. 188 Software Engineering Unit 10

Unit 10 Software Design Concepts and Principles Structure: 10.1 Introduction Objectives 10.2 Software Design Design concepts 10.3 Design Process Stellar software design process 10.4 Design Fundamentals Principles of design 10.5 Modular Design Advantages and Disadvantages 10.6 Data Design 10.7 Architectural Design Advantages of architectural design 10.8 Procedural Design 10.9 Design Documentation Guidelines for improving design documentation 10.10 Summary 10.11 Glossary 10.12 Terminal Questions 10.13 Answers 10.14 Case Study

10.1 Introduction In the previous unit, we studied analysis concepts and principles, wherein we described the scope of requirement analysis and various analysis tasks, importance of communication and different analysis principles. We also discussed the importance of software prototyping and various prototyping methods and tools, revisited software requirements specification and learnt about specification review. In this unit, we will discuss about software design and its aspects, the design process and fundamentals and different design methods such as modular design, data design, architectural design and procedural design.

Sikkim Manipal University B1965 Page No. 189 Software Engineering Unit 10

We will also analyse design documentation and learn some guidelines that we need to follow while preparing the design documentation. This unit will enable us to analyse the importance of software design, which is the base for all the software engineering, and the steps to follow in order to develop an appropriate design. This unit will familiarise you with the concept of various design methods and their advantages such as how the architectural design helps to develop structural model, subsystem decomposition model, and so on. This unit also presents how the design documentation should be developed which is a means to communicate and record. Objectives: After studying this unit, you should be able to:  describe software design  explain the design process and its fundamentals  demonstrate modular design and data design  illustrate architectural design and procedural design  briefly explain design documentation

10.2 Software Design Let us start our discussion with the concept of software design. The process of depiction of how a particular software is to be developed is called software design. The design also includes requirements, practices, methods, life cycles and guidelines to develop a system. Software design is a structured methodology. There are various methodologies that specify complete set of standards, tools, procedures and documentation. The aim of any methodology should be to establish:  A style and procedure for the way a system is developed or an existing/available system is improved.  Management control should present milestones and checkpoints for the development.  Quality of the product as per the specifications. Software design is applied irrespective of the software process used. This is the first technical task after the software requirements have been analysed

Sikkim Manipal University B1965 Page No. 190 Software Engineering Unit 10 and specified. The design is followed by generating code and testing of the design. Let us see the flow of software design model in Figure 10.1.

Fig. 10.1: Flow of Software Design Model It is commonly known that design is always worthwhile. Yet, in most cases, the product developed will be more or less altered from what was planned earlier. It is not easy to say how much to plan and design and there are various organisations to deal with such issues. Some individuals follow the upfront design, others believe in coding first and then solving the problems as and when they occur. The decisions related to software design are made during the design phase, which will ultimately affect the success of software development and maintenance of the software. We can know the quality of the software by its design. In software engineering, design is the stage where quality is cultivated. The design symbolises software that can be assessed for quality. The customer’s requirements can be converted into a product (software end-product) through design. If a model is developed without design, there is always a risk of developing an unstable model. This unstable model will fail when even small changes are incorporated into the scheme of things. Such unstable models are also difficult to test. The quality of such design cannot be assessed until late in the software process.

Sikkim Manipal University B1965 Page No. 191 Software Engineering Unit 10

10.2.1 Design concepts Let us have a brief discussion on the various concepts developed to describe well-structured/designed object-oriented systems.  Separation of concerns – We can define this concept as a process of separating a program into individual features that coincide in functionality. This is very important in the design phase.  Open closed principle, the single responsibility principle and the Liskov substitution principle – The open closed principle specifies that an application can be structured by adding new functionalities with minimum modification to an existing program. The single responsibility principle facilitates writing small classes and methods, and each class should implement a cohesive set of associated functions. The Liskov substitution principle states that any implementation of an abstraction can be used at any place which accepts that abstraction.  Responsibilities, cohesion and coupling – The system is divided into modules, each with its unique area of responsibility. Cohesion is a measure of class, whether it is well defined, and specifies meaningful responsibility. High cohesion is always preferred. Coupling defines how the class is entangled or dependent with other classes. A loosely coupled design means that classes can be broadly classified independently from one another.  Orthogonal code – We can define it as a process of writing codes based on concepts of loose coupling and high cohesion.  Dependency inversion principle – This principle is used to separate one class from the actual implementation of its dependencies.  Composition is better than inheritance – Composition is better than inheritance because composition offers less coupling and good flexibility. Composition also provides extra objects which can be interconnected. The strategy objects can be dynamically changed at run time in composition. In inheritance, the mix and match of the strategy objects is not possible especially during run time. Self-Assessment Questions 1. Which principle is used to separate one class from the actual implementation of its dependencies?

Sikkim Manipal University B1965 Page No. 192 Software Engineering Unit 10

2. The software design is applied irrespective of the software process used. (True/False) 3. We can define ______as a process of writing codes based on concepts of loose coupling and high cohesion.

10.3 Design Process In the previous section, we discussed about software design and its concepts. In this section, we will briefly discuss about the design process and the process guidelines that help us to achieve a good design. We can define software design as a repetitive (continuously changing) process through which requirements are recognised and noted down, to develop the software which is also called as blueprint. We know that software design is a repetitive process, and in that process the requirements are recognised and noted down. All these requirements that are noted down together constitute the “blueprint,” which is used to develop the software. Note that the blueprint illustrates a basic overall view of the software. As design changes occur, subsequent changes (development) lead to design representations at much lower levels of abstraction. We should establish technical criteria for good design of the software and the methods for evaluating the quality of a design representation. The software design process encourages good design through the application of fundamental design principles, systematic methodology and thorough review. Let us have a look at the guidelines followed for good design. A good design should:  Illustrate the architectural structure that has been developed using clear and understandable design patterns. These design patterns are composed of components that display good design characteristics, and can be implemented in an evolutionary method. This will make implementation and testing easy.  Be modular, that is, the software should be logically divided into components that perform particular functions and sub-functions.  Include unique illustrations of data, architecture and modules.  Direct to data structures that are relevant for objects to be implemented and are taken from specific data patterns. Address data structures that

Sikkim Manipal University B1965 Page No. 193 Software Engineering Unit 10

are appropriate for objects to be implemented. The data structures are derived from specific data patterns.  Direct to elements that show independent functional characteristics.  Direct to interfaces that decrease the complexity of connections between elements and with external environment.  Be derived using a recurring process which is taken by the information that was obtained during software requirement analysis. 10.3.1 Stellar software design process As we are studying the design process of software engineering, let us now study the 12-step program that is followed to get the organisations back on track, that is, to make them understand why their software didn’t perform as expected or why the users make errors unexpectedly: 1. Admit that there is a problem – This is the first step in stellar software design process. This step talks about the program. It is not always possible to develop good usability program. It is preferable to carry out informal customer interviews and to team up with technical support staff. The designer should always think like the user. 2. Believe in a power greater than the designer’s power – This is the second step of the design process. This step is used to find out the end-users – the people who will use the final product. Sometimes, it so happens that the actual end-users do not turn out to be from a particular group for whom the design was originally developed. 3. A decision to be made to identify good design – This is the third step of the stellar software design process. This step talks about the design. Design is not just what it looks like and feels like; design is how it works. 4. To search and invent user’s experience shortcomings – This is the fourth step in the stellar software design process. This step talks about how the design can be explained. We can use illustrations to explain the design. 5. Admit to someone else (other than designers) the nature of problems – This is the fifth step of the design process. This step talks about how the designer should think. The designers should talk as an

Sikkim Manipal University B1965 Page No. 194 Software Engineering Unit 10

equal to users more than getting feedbacks from the users. This helps to sort out many issues. 6. To be ready to solve defects of character – This is the sixth step of the design process. This step specifies how a system should be developed. We will need to develop the system in such a way that it can accept changes without affecting the rest of the system. 7. Take help – This is the seventh step of the design process. This step talks about how designers should take help. It is always preferable to ask for help from related people or other sources. There is no rule that one has to only listen to the feedback given after reviewing. The developers can take an extra step by their own. 8. Prepare a list of all the users who have been affected and then their lives can be made better – This is the eighth step of the design process. This step specifies how to handle the issues. We can take this step to scale from functional to reliable, then from usable to convenient and finally agreeable to meaningful. The developer should be able to assess where he has failed. This step is extremely difficult. 9. Make direct damages – This is the ninth step of the design process. This step talks about how a designer should act when sufficient feedback is not obtained. It is difficult to get feedback from users. If unable to deliver an improvement, it is better to prepare for the worst. Always make failures consciously and undertake testing. 10. Continue the inventory – This is the tenth step of the design process. This step talks about the prior tasks of design. Usability testing is not a one-time event but it is a cycle. Always observe, analyse and then design. 11. Realise that without users, it does not matter – This is the 11th step of the design process. This step specifies how the attitude of developers should be. Usability testing is not only important for users but also equally important for the developers, as it is continuously improved by developers. 12. Pay it forward – This is the 12th step of the design process. A number of resources are present in the software community for offer various courses that can be learned.

Sikkim Manipal University B1965 Page No. 195 Software Engineering Unit 10

Self-Assessment Questions 4. The software design process does not encourage good design through the application of fundamental design principles, systematic methodology and thorough review. (True/False) 5. ______is the first step in stellar software design process. 6. The blueprint illustrates a basic ______view of the software.

10.4 Design Fundamentals We are now familiar with design concepts and process. We will continue our discussion with the study of design fundamentals for developing a design correctly. The fundamental concepts of software design provide guidelines to get the design right. Let us have a quick overview of the design fundamentals.  Abstraction – In abstraction, the issues related to the design are described using the levels of details/language. In software designing, we use two types of abstraction: o Data abstraction – The representation of the data objects is called data abstraction. In data abstraction, data objects are represented. o Procedural abstraction – The representation of instructions or procedures is called procedural abstraction. In procedural abstraction, instructions are represented.  Refinement - In refinement, we polish the design using top-down strategy called as “stepwise refinement.” We begin with the highest level of detail, and refine every step into detailed instructions.  Modularity – In modularity, we divide the software into separate components called modules. These modules are solved separately and then integrated into the complete system.  Software architecture – Software architecture describes the hierarchical structure of procedural components and the structure of data. We transform the analysis model into the design model.  Control hierarchy – We can refer to it as “Program structure.” In the control hierarchy, we organise the elements, which implies that we describe a hierarchy of control, the metrics – depth, width, and so on, and provide visibility and connectivity.

Sikkim Manipal University B1965 Page No. 196 Software Engineering Unit 10

 Data structure – In data structure, we illustrate the links between individual data elements using logical representations. It presents scalar, sequential vector, array, linked list and hierarchical data structure.  Software procedure – It specifies processing details of each element. It provides precise specifications on sequence of events, decision points, repetitive operations and data organisation.  Information hiding – In information hiding, the elements should be categorised by design decisions, and each element is hidden from all the other elements. The elements are designed in a manner that the information within an element is not accessible to other elements. This defines and implements access restrictions. 10.4.1 Principles of design We will now learn about the seven principles of design.  First Principle: The reason of its presence. One reason for a software system to be present is to give value to its users. We should keep this in mind while making all judgements. Prior to specifying system requirements, system functionality, determining hardware platforms or development processes, we should know the answer to the question “does this add real value to the system?” If the answer is no, then there is no point in doing it.  Second Principle: KISS – Keep it simple, Stupid! Software design is not a random process. In any design, we should consider many factors. All the designs should be simple but not simpler. This helps to have a system that can be easily understood and maintained. All the elegant systems are simple in nature when observed. Simple design consumes a lot of thought and work over several repetitions to simplify. Consequently, it results in software which is more maintainable and less vulnerable to error.  Third Principle: Maintain the vision. A clear vision of the software is necessary to gain success in any software project. If the vision towards the software is not clear then the project ends up with low quality. If the project lacks conceptual integrity, it results in a system which is a patchwork of incompatible designs held together by wrong kind of connections. Conceptual integrity is one of the most important considerations in the system design. Architectural vision of the Sikkim Manipal University B1965 Page No. 197 Software Engineering Unit 10 software system is also important. If the architectural vision is weak then the system fails though it is well designed. If the architect has a clear vision of the software and implements compliance then the project becomes successful.  Fourth Principle: What is produced will be consumed/used by others. According to this principle, a product developed is used, maintained and documented by the users/clients, to understand the system. A product should be developed such that the user should understand the specifications, design and implementation. Always keep the implementations in mind while designing. The code should be written with concern for the individuals who maintain and extend the system. The code developed is tested and debugged by the testers. If the work of testers is made easier then further value is added to the system.  Fifth Principle: Be open to the future. As per this principle, the system has more value if it has extensive lifetime. In the present generation computing environments, the specifications of hardware and software change rapidly and become outdated very fast. The lifetime of software is measured in months. However, software that is truly and industrially strong should last longer. To achieve that kind of system, the system should be able to adapt to all changes. Systems that adapt successfully are those that have been designed from the beginning to get adapted easily. The systems should be created such that they solve all the problems not just a particular problem. This results in a system that can be reused entirely.  Sixth Principle: Plan in advance for reuse. According to this principle, time and effort can be saved by reusing the developed software. The reuse of programs and designs has been made possible due to the use of object-oriented technologies. Various methods to realise reuse at every phase of the system development process are available. Communicating about the scope of reuse to others in the organisation is vital. This principle also states that planning ahead for reuse decreases the cost and increases the value of both the reusable elements and the systems into which they are incorporated.

Sikkim Manipal University B1965 Page No. 198 Software Engineering Unit 10

 Seventh Principle: Think. As per this principle, placing clear, complete thought before action produces better results. If the thought is right, then the action will also be right. We can gain knowledge about how to do it again. Thinking helps us individuals to learn how to identify solutions in a situation where the individual is ignorant about something. He can thus find out the answer to that question. The value of a system increases automatically when clear thought is applied to it. Self-Assessment Questions 7. A clear vision of the software is necessary to gain success in any software project. (True/False) 8. As per the ______principle, the system has more value if it has extensive lifetime. 9. A clear ______of the software is necessary to gain success in any software project.

Activity 1: Create a flow chart for the principles followed for designing a software in your company. (Hint: Design Principles.)

10.5 Modular Design As we are now familiar with software design, design concepts, its process and fundamentals, let us discuss about modular design. We can define a modular design as the design of any system made up of separate modules that can be linked together. Modular design facilitates the replacement or addition of any module without affecting the remaining system. We can apply modular design to the hardware and software. It refers to a design strategy in which a system is made up of comparatively small and independent routines that fit together. Let us study the criteria that help to evaluate a design method with reference to its capability to define effective modular system1:

1 Meyer [MEY88] Sikkim Manipal University B1965 Page No. 199 Software Engineering Unit 10

 Decomposability – An effective modular solution of decomposability is achieved when a design method gives a systematic mechanism for decomposing the problem into sub-problems. This reduces complexity of the overall problem of the design.  Understandability – If a module/component can be clearly understood as an individual unit without any reference to other modules, it will result in a module that is easy to develop and easy to modify.  Continuity – If changes in the individual modules occur due to small changes in the system requirements, rather than system-wide changes. The effects of change due to the side effects will be decreased and will be restricted to that module.  Composability – We can achieve the modular composability as a result of assembling of existing design components into a new system.  Protection – The effect of error-induced side effects are reduced whenever an unusual condition occurs within a module and the effects are restricted within that module. 10.5.1 Advantages and Disadvantages Now that we have learnt about modular design, let us study about the advantages and disadvantages of modular design. The advantages of modular design are as follows:  Stabilised design of modular element decreases the development of the final product.  A significant range of products can be developed.  The designs can be brought out to market very quickly.  The designs are very flexible in nature.  The designs provide easy service; faults can be easily identified and can be replaced.  Significant range of product.  High speed-to-market.  Significant flexibility in design.  Easy service, identification of fault and replacements.  Simplified material planning, less inventory due to easily available modular sub-assemblies.

Sikkim Manipal University B1965 Page No. 200 Software Engineering Unit 10

 Less paper work in record, as there is no need to maintain the records of parts used in the modular sub-assemblies. The disadvantages of modular design are as follows:  Development cost is more while making modules that can be reused in other efforts.  For hardware, the product cost can increase whenever interconnects between different modules increase.  The development cost and time are higher if modular libraries are being developed as part of the development effort.  For hardware, interconnections between different modules as subsystem often act as limits for overall performance of hardware.  The interfaces between different modules are frequently common causes of failure. Self-Assessment Questions 10. A ______design is the design of any system made up of separate modules that can be linked together. 11. If modular libraries are being developed as a part of the development effort, the development cost and time are higher. (True/False) 12. High speed-to-market is an advantage of ______.

10.6 Data Design Till now, we have familiarised ourselves with software design, design concepts, its process and fundamentals. Let us now learn about data design. Data design recognises the program elements that function on logical data structures. The benefit of data design is that, it specifies good program structure, effective modularity and decreased complexity. Let us briefly mention the data specification principles.  Apply functional analysis principles to data.  Classify all data structures and associated operations.  Create a data glossary to describe data and program design.  Defer low-level data design decisions.  Illustration of data structure should only be known to elements with direct use of data within the structure.

Sikkim Manipal University B1965 Page No. 201 Software Engineering Unit 10

 Build up a library of useful data structures.  Language should support conceptual data types. Self-Assessment Questions 13. Data design recognises the program elements that function on ______data structures. 14. One of the data specification principles is to create a ______to describe data and program design. 15. “______should support conceptual data types” is another data specification principle.

10.7 Architectural Design Having studied about data design in the previous section, let us now study the architectural design. The architectural design describes the link between major structural elements of the software. The aim of architectural design is to develop a modular program structure and depict the control association between elements. It combines program and data structure by describing interfaces, which allows data to flow throughout the program. It is known to be the holistic view of the software. We will now briefly describe the characteristics of architecture.  Performance – The benefits of architectural design are the localisation of critical operations and reduction in communication. Instead of using fine components, this design uses large components.  Safety – All the safety critical features are localised in small subsystems.  Maintainability – This design uses fine and replaceable elements.  Security – This design is a layered architecture with critical properties in its interior layers.  Availability – The redundant elements and mechanisms for tolerance of fault are available in the system. We can refer to software architecture as a software system’s blueprint which illustrates its components, interactions between components and their interconnections, informal descriptions including boxes and lines, and informal prose (ordinary and understandable language), and a shared,

Sikkim Manipal University B1965 Page No. 202 Software Engineering Unit 10 semantically rich vocabulary consisting of remote procedure calls, client server, layered, object oriented, and so on. 10.7.1 Advantages of architectural design Like other designs, architectural design also has some advantages. Let us study the advantages of architectural design:  The development philosophy is component based.  This design saves cost of architecture.  It is an explicit system structure.  This design provides a framework for fulfilling requirements of the software design.  It can be effectively reused.  It provides technical basis for design.  It avoids architectural erosion.  The structure and interaction details outdo the decision of algorithms and data structures in large or complex systems. During the design process, we can develop various architectural models. Each model consists of different perspectives on the architecture. Let us briefly discuss these perspectives:  Dynamic process model – This represents the process structure of the system.  Static structural model – This indicates all the important system components.  Deployment model – This represents the link between system elements and hosts.  Interface model – The subsystem interfaces are defined here. Self-Assessment Questions 16. ______design recognises the program elements that function on logical data structures. 17. The architectural design describes the link between ____ of the software. 18. Software architecture can be referred to software system’s blueprint. (True/False)

Sikkim Manipal University B1965 Page No. 203 Software Engineering Unit 10

Activity 2: Client-server is a popular distributed architecture. Server modules offer services to client modules, and clients and servers exist on different machines. An example would be a railway reservation system – where the booking clerk can view details that are essentially stored in the server. You are required to identify at least three other areas where client-server can be observed. (Hint: Client-server architecture.section No. 10.8 )

10.8 Procedural Design In the previous section we studied about architectural design. Let us now study about procedural design of software. After data design, system architecture and interface design, procedural design starts. It is essential for us to specify procedural detail after data and program structure have been developed without uncertainty. The goals of procedural design are as follows:  Least effort to complete the task.  Less number of statements to achieve the goal.  Reduced usage of resource so that the cost of resource is reduced.  High transparency.  Maximum output precision is achieved. We can adopt the following methods for achieving the goals:  Coding, top-down and bottom-up – In top-down coding approach, the main module is programmed and implemented, and proceeds to lower level in the hierarchy. In the bottom-up coding approach, the programming begins at lowest level and moves up.  Structured programming – The structure of design function and design behaviour is provided in structured programming.  Use of information hiding principle – If there is a change in the structure or process, it is easy to maintain by using this principle.  Programming style – Each individual has a style of coding. But one has to follow certain standard rules while coding.

Sikkim Manipal University B1965 Page No. 204 Software Engineering Unit 10

 Internal documentation within the program – The entire process is recorded in the documentation to help the developers and users understand the process. For example, the document includes functionality, roles and usage of parameters, characteristics of input, and so on. The documentation should also include referential data such as recent modified date, author of the program, and so on. The details given in the documentation will facilitate modifications. Self-Assessment Questions 19. In bottom-up coding approach, the main module is programmed and implemented, and goes to lower level in the hierarchy. (True/False) 20. All the process is recorded in the ______to help the developers and users understand the process. 21. The ______principle makes it easy to maintain if there is a change in the structure or process.

10.9 Design Documentation In previous sections, we discussed about various kinds of design methods. Now let us now study about an important aspect of software design, “Design Documentation.” In general, the design document enables people to review the design and improve it. It contains all the design decisions along with the reasoning. The design process results in design documentation. The design documentation explains the following.  Necessities used to guide the design process.  What system or part of the system this design document describes.  Explains the important problems that had to be solved.  The likely substitutes that were considered.  The final decision and the rationale for the decision.  Assures traceability by providing reference to the requirements that are being implemented by this design.  Advises a designer to be clear and to consider the important issues before starting implementation. Now we will see the inclusions in typical design documentations, namely:  A pictorial representation of the design. The diagram helps the reader to quickly get a basic idea of the design.

Sikkim Manipal University B1965 Page No. 205 Software Engineering Unit 10

 The information its readers need to learn.  The rationale for the design which allows the reader to understand the design better, helps reviewers to determine whether good decisions were made, and helps the maintenance team determine how to change the design. We can define the design document as a kind of document that provides reference to the requirements being implemented by this design. We should write the design document for those who:  Will implement the design such as programmers.  Will need to modify the design in future.  Need to create systems or subsystems that interface with the system being designed. The design specification provides various concepts of design model and the software representation of the designer. It describes the scope of design effort. Description of database structure, external file structures, internal data structures and cross references that connect data objects to specific files are contained in it. The architectural design shows that the program architecture is derived from analysis model, and to indicate module hierarchy, structure charts are used. The external and internal program interface designs are indicated and human–machine interface is described in detail. A GUI prototype is provided wherever required. Separate elements of software such as subroutines, functions, procedures and others are described in narrative style. This narration describes the procedural function of a module. We use the procedural design tool for converting the procedural function into a structured description. The design specification consists of cross reference. The use of cross reference is to ascertain that all needs have been fulfilled by software design, and to show which components are essential to the implementation of specific requirements. The initial step on the development of test documentation is also present is the design document. After developing the program structure and interfaces, guidelines for testing each module separately and the integration of the complete entity can be developed.

Sikkim Manipal University B1965 Page No. 206 Software Engineering Unit 10

Design restrictions like physical memory limitations or requirement for a particular external interface may dictate special requirements for assembling or packaging of software. Special reflections caused by the need for program overlay, virtual memory management, high-speed processing and other factors may cause change in design derived from information flow or structure. This also explains the approach we will need to use in order to move software to a customer site. The last part of the design documentation includes additional data. It includes algorithm explanations, alternative procedures, data, results, extracts from other documents, and other information as a note or separate appendix. The preliminary operations or the installation manual can be included in appendix of the design document. 10.9.1 Guidelines for improving design documentation We know that the key to success of design documentation are good organisation and clear writing. So, we should follow the below-mentioned guidelines for improving the documentation: 1. Know the audience The needs of the audience should be addressed by writing effective design documentation. Before starting the documentation, the author should find out what the audience wants and who the audience is. The author should know how the audience is likely to use the documentation and which the times it will be used. It is important to know the language of the audience including the kinds of references they use and in which manner. The medium of documentation in terms of suitability should be decided – whether hard copy paper documents, presentations or other media. The document should integrate into the audience’s culture but should not disrupt it. The author can start writing as soon as all the above criteria are known. In the due course of writing, it is better to double check to ensure that the writing is on track and that it will provide the audience with what they require. 2. Narrate The aim of the design documentation in the early stages of a project is to educate its users about the value of the design and make them understand

Sikkim Manipal University B1965 Page No. 207 Software Engineering Unit 10 that the product is worth constructing and producing. To facilitate this, we must narrate the concepts like a story. Narration is done using characters, scenarios and walk-throughs. 3. Describe the foundation and inferences of the design While documenting a design, it is not enough to explain the working of product and how it looks; we should also explain the basis on which the design was developed wherever feasible. We must support the design decision or solution by understanding how it serves the needs of users. We must also describe in detail how each decision will facilitate the user requirement fulfil the user goal. While providing the justifications for the decision made, we must answer the users’ questions. We must be able to explain the design in terms of business requirements. Design principles can be used to back up interface behaviours to assure the programmers that their code is sensible. 4. Follow standard format The layout of the document should be well organised. If the contents are not readable though they are good, the effort goes waste. The format should be visually clear and consistent in all pages. This is an important aspect of documentation. To get started, templates that provide consistent page layout grid can be obtained by applications such as InDesign, Adobe FrameMaker and others. 5. Use active voice, present tense The design documentation specifies about a product; the tone of writing should convey what the product is. When the sentences are written with conviction, the confidence and belief in the design is high and the same is carried to the users and makes the design influential to the audience and vice versa. 6. Review After the documentation, the draft has to be reviewed and edited. The editor should be familiar with the design and project. The editor can be a colleague or a member of the development team. Both the writer and the editor should analyse whether the design has been correctly described, whether the key points have been covered, whether the important technical implications have been addressed, and so on. A regular

Sikkim Manipal University B1965 Page No. 208 Software Engineering Unit 10 meeting with the editor is necessary. It becomes easier to deal with issues when they occur during the early drafts. The main aim of editing is to get the best design developed and reach the audience. Self-Assessment Questions 22. ______is the final outcome of the design process. 23. After the documentation, the draft need not be reviewed and edited. (True/False) 24. The needs of the audience should be addressed by writing ______design documentation.

10.10 Summary Let us recapitulate the important concepts discussed in this unit:  Software design is the technical core of software engineering.  Continuous refinement of data structure, architecture, interfaces and procedural detail of software elements are developed, reviewed and documented during the design phase.  The results of design in the form of software can be measured for quality.  Design principles help the software engineer as the design process progresses. The basic criteria for design quality are provided by design concepts.  Four types of design methods are important – modular design, data design, architectural design and procedural design.  Architectural and procedural designs have several advantages and some disadvantages as well.  Design documentation is produced at the end of the design process.  Design documentation helps the user and developer to understand the process holistically. Reviewers review the document and necessary changes are incorporated.  Certain procedures exist for ensuring writing a good documentation; it makes sense to adopt such procedures.

10.11 Glossary Adobe FrameMaker: It is an application for desktop publishing and help authoring. This is published by Adobe Systems.

Sikkim Manipal University B1965 Page No. 209 Software Engineering Unit 10

Architectural erosion: Architectural erosion is a phenomenon where the initial architecture of an application is altered to such a point where its basic properties no longer exist. Design pattern: Design pattern is a generally a repeatable solution to a commonly arising problem. Explicit system structure: A clear structure of the system is established. This kind of system avoids confusions. InDesign: This application is used to create posters, brochures, flyers, books and magazines. This is published by Adobe Systems. Interface design: It is a process of establishing the structure and work flow for a user interface in software engineering. Module: Module is an individual unit of hardware or software.

10.12 Terminal Questions 1. What is a software design? 2. Briefly explain the design process. 3. Briefly explain the design fundamentals. 4. What is a modular design? 5. What is a data design? 6. Explain architectural design in detail. 7. Explain procedural design in detail. 8. Describe design documentation.

10.13 Answers Self-Assessment Questions 1. Dependency inversion principle 2. True 3. Orthogonal code 4. False 5. “Admit that there is a problem” 6. Overall 7. True 8. Fifth 9. Vision 10. Modular

Sikkim Manipal University B1965 Page No. 210 Software Engineering Unit 10

11. True 12. Modular design 13. Logical 14. Data glossary 15. Language 16. Data design 17. Major structural elements 18. True 19. False 20. Documentation 21. Use of information hiding 22. Design Documentation 23. False 24. Effective Terminal Questions 1. (Refer to Section 10.2 for further information.) 2. (Refer to Section 10.3 for further information.) 3. (Refer to Section 10.4 for further information.) 4. (Refer to Section 10.5 for further information.) 5. (Refer to Section 10.6 for further information.) 6. (Refer to Section 10.7 for further information.) 7. (Refer to Section 10.8 for further information.) 8. (Refer to Section 10.9 for further information.)

10.14 Case Study An Example Showing the Essentiality of a Software System Movie World is a Delhi-based company in DVD rental business. It has 4,000 DVD titles covering all subjects and languages. Each title is originally bought in 6–12 numbers depending upon its rating in the entertaining field. The company has 14 branch libraries spread over the city. It is the policy of the company’s management to add over 150 titles every year, based on reviews and feedback from the market. The terms and conditions of the company are the following: Membership subscription of Rs.4,500 per annum per head; if a member borrows a DVD then the member has to pay Rs. 80 with the condition that the DVD is

Sikkim Manipal University B1965 Page No. 211 Software Engineering Unit 10 returned within 36 hours. The company has more than 8,000 members. The business operations are as follows. 1. A person pays Rs.4,500 for 1 year and receives membership card after filling in the form. 2. When a member wants a DVD, the member visits the branch and requests for their choice. If it is available, it is given. If it is not present then the member has to fill the reservation slip. The branch manager handles all these situations. 3. If the DVD is collected and returned within 36 hours, an extra charge of Rs.15 per hour is collected, before the next DVD is issued to the member. The method of returning the DVD is – the member has to drop the DVD in a drop box with the return coupon filled, which includes the membership number, time of return and date. The staff regularly checks the drop box and places back the DVD in its shelf. All titles are bar coded with complete data about the DVD and main attributes such as language, rating and others. The company’s policy is to scrap the DVD if it is issued more than 60 times, and new purchase of the DVD is automatically made. The basic systems of registration, accounting, billing and recovery are functioning well. The systems are independent. The systems are not integrated and decisions are made based on summary of month end issued by individual system head. Every branch has five desktops and a data server to meet transaction processing and accounting. The management wants to take up the following actions to improve the revenue. 1. Service to member is quicker and effective. 2. Titles are present when asked by the member. 3. The member should be able to select the title, check its availability and make a request for home delivery. 4. Reservation system to book the title. 5. Improved accounting and analysis system should be set up for recovery of membership fees, overdue, extra charges and others. 6. The company wants all the branches to be networked to facilitate quicker movement of DVDs and for members to get their choice of titles in less duration.

Sikkim Manipal University B1965 Page No. 212 Software Engineering Unit 10

Discussion Questions: 1. Analyse the problems of the company. 2. Develop a software system solution to overcome the issues. References/E-References:  http://www.computerworld.com/s/article/9049262/12_steps_to_stellar_s oftware_design (Retrieved on 15th May 2012)  http://www.cc.gatech.edu/classes/AY2000/cs3802_fall/Lecture6/index.ht m (Retrieved on 15th May 2012)  http://www.c2.com/cgi/wiki?SevenPrinciplesOfSoftwareDevelopment (Retrieved on 15th May 2012)

Sikkim Manipal University B1965 Page No. 213 Software Engineering Unit 11

Unit 11 Software Testing Techniques and Technical Metrics Structure: 11.1 Introduction Objectives 11.2 Software Testing Fundamentals Testing objectives Test information flow Test case design 11.3 White Box Testing 11.4 Control Structure Testing 11.5 Black Box Testing 11.6 Testing Real-Time Systems 11.7 Automated Testing Tools 11.8 Summary 11.9 Glossary 11.10 Terminal Questions 11.11 Answers 11.12 Case Study

11.1 Introduction In the previous unit, we discussed about software design and its aspects, the design process and fundamental and different design methods such as modular design, data design, architectural design and procedural design. We also analysed the design documentation and learnt some guidelines to follow while preparing the design documentation. In this unit, we will discuss about software testing fundamentals and its objectives. We will analyse the process of test information flow and case design. We will also discuss various testing methods such as white box testing, black box testing and control structure testing. We will also discuss briefly about various methods of testing real-time systems and various kinds of automated testing tools. This unit will enable us to use an appropriate method for software testing, and the manner in which that particular method will help us in conducting successful testing.

Sikkim Manipal University B1965 Page No. 214 Software Engineering Unit 11

Objectives: After studying this unit, you should be able to:  describe software testing fundamentals  elaborate white box testing  explain black box testing  briefly discuss about control structure testing  describe the testing of real-time system  list out the automated testing tools

11.2 Software Testing Fundamentals Let us start our discussion on software testing fundamentals by defining software testing. We can define software testing as the activity that aims at evaluating the capability of a program or system. It finds out whether the program meets the required results or not. It also identifies errors in the coding of the application that have to be eventually fixed. 11.2.1 Testing objectives Let us briefly describe the objectives of software testing.  Quality assurance – The effects of bugs are very severe, especially in critical software systems like the ones pertaining to avionics, health care, and so on. Bugs or errors cause huge losses and disasters, sometimes catastrophic. Some examples of bugs that have caused major disasters are aircraft navigation failure resulting in mid-air collision (e.g. the mid-air collision over Charkhi Dadri village in Haryana in 1996, when two airplanes crashed into each other), stoppage of stock market trading, and so on. The quality of software is a vital aspect in the modern, computerised world, where our lives have been taken over completely by computers. Quality is conformation to the specified design requirement. Debugging is conducted to find out defects in design developed by the programmers. It is not so easy for a developer to develop a program that is error free. We ensure good quality by finding the problems and fixing them by adopting a process called “debugging.”  Reliability estimation – We can associate many aspects of software including structure, and the amount of testing it has been subjected to, with software reliability. Testing serves as a statistical sampling method

Sikkim Manipal University B1965 Page No. 215 Software Engineering Unit 11

to obtain failure data for reliability estimation based on operational profile. Software testing is expensive, but the software used for testing is more expensive. It is not easy to solve software testing problems. We can never be sure that the software is correct and also the specifications. There is no verification system that can verify each and every correct program. And we can never be certain that a verification system is correct.  Verification and validation – We cannot test quality directly; so we test related factors to make quality visible. Quality consists of certain factors. Good testing evaluates all relevant factors. For the testing to be effective, it should evaluate each relevant factor and thus compel quality to become substantial and visible. Tests that aim at validating the product are called clean tests or “positive tests.” A contrary method of testing is “negative tests,” which aim at breaking the software or showing that the program does not work. The software should have a good number of handling capabilities in order to emerge victorious for a significant level of negative tests. 11.2.2 Test information flow As we have now become familiar with the term “software testing” and its objectives, let us briefly discuss about the flow of test information. Test information flow is an arrangement to check and maintain the right flow of information during software testing. In Figure 11.1, we feed the software and test configuration specifications to the testing block that generates test results. Then, these test results are fed into the evaluation block, along with the expected results and error rate data. The expected results and the test results are compared and errors are generated. These errors are then fed into the debug block. The debug block corrects the errors and produces corrected results. Let us see a typical test information flow shown in Figure 11.1.

Sikkim Manipal University B1965 Page No. 216 Software Engineering Unit 11

Expected results Software configuration Test results Errors Testing Evaluation Debug

Corrections Test configuration Error rate data

Reliability Model

Predicted reliability Fig. 11.1: Representation of Test Information Flow

11.2.3 Test case design We will now study about a very important aspect called test case design. We can define test case as a test that is designed to validate a case outline. We define the process of testing, units to be tested and tools used during different levels of testing in the test plan. The test cases are designed on the basis of the method specified in the test plan, and the characters to be tested. Let us see a test case design specification in Table 11.1.

Table 11.1: Example of Test Case Specifications

Requirement Condition to be Test data and Likely output number tested settings

We can add extra columns if necessary, such as an extra column to note the result of different rounds of testing. Test case design is an important activity in the testing process. We should select the test cases carefully for proper testing, which will fulfil the required criteria and approach specified. A test case design has the following benefits:  To assure that the set of test cases used is of good quality.  The entire testing of the unit and the effect of total set of test cases is visible to the testers.  The test cases are optimised, as evaluation of test set might indicate that few test cases are redundant.

Sikkim Manipal University B1965 Page No. 217 Software Engineering Unit 11

A design is said to be testable if we can validate and maintain it easily. Testability is an important design rule for software development though testing needs significant effort, time and cost. We can say that a test case is good if it has a high possibility of finding the undiscovered error. Also, a test is said to be successful if it discloses undiscovered error. From the above discussion, we can conclude that the objective of test case design is to find out errors in a program. Self-Assessment Questions 1. It is not easy for a developer to develop a program which is ______. 2. Test information flow is an ______to check and maintain the right flow of information during software testing. 3. A design is said to be ______, if we can validate and maintain it easily. 4. The objective of test case designs is to find out errors in a ______.

11.3 White Box Testing In the previous section, we studied about software testing fundamentals. In this section, we will study about a testing method called white box testing. We can define “white box testing” as a kind of testing where the test groups should have complete knowledge of the internal structure of the software. White box testing is also called structural testing (and sometimes glass-box testing). Structural testing is based on testing where the tests are derived from knowledge of the software’s structure and implementation. We can apply structural testing to small program units like subroutines, operations related to objects, and so on. The tester analyses the program and uses the knowledge about the structure of a component to get test data in this method of testing. The number of test cases required to assure that all statements in the program are executed at least once during the testing process can be found out by analysing the code. It is important to note that boundary conditions should be tested in white box testing – for example, in a “for” loop where the loop returns 20 times, we will need to execute the program for the 19th and 20th loops. The white box testing is carried out on the basis of knowledge of how the system is implemented. White box testing needs access to the source code. However, white box testing can be done

Sikkim Manipal University B1965 Page No. 218 Software Engineering Unit 11 any time after the code is developed; it is a good practice to carry out the test during the unit testing phase. White box testing is carried out to:  Validate code whether the code implementation follows intended design.  Validate applied security functionality.  Discover usable vulnerabilities. Let us understand the requirements of white box testing now.  The basic requirement is to comprehend and analyse available design documentation, source code and other related development artefacts.  The tester should think like an attacker for creation of tests and ensure that he breaks apart the code in order to identify uncovered errors.  The testers should know the various tools and techniques present for white box testing, so that they can perform testing effectively. We will now briefly discuss the white box testing process shown in Figure 11.2.

Inputs

Activities

Outputs

Fig. 11.2: Process of White Box Testing

As per Figure 11.2, white box testing process includes three components.  Inputs – The inputs to the white box testing include: o Source code – Access to the source code is an important requirement to carry out white box testing. o Design documentation – We require this to enhance program understanding and to establish effective test cases that evaluate design decisions and assumptions. If the design document is not available or insufficient, the test team should have direct access to the design team for extensive question and answer sessions.

Sikkim Manipal University B1965 Page No. 219 Software Engineering Unit 11

o Architectural and design risk analysis report – This includes the test plans, test case creation, test data selection, test technique selection and test exit criteria selection. If risk analysis is incomplete for the system, this should be the first task performed as a part of white box testing. o Security specifications – Security specifications are required to understand and validate the security functionality of the software which is under test. If the security specifications are not sufficient, the test team should get this information from stakeholders, design team and business owner of the software. o Security testers’ documentation – The testers should have access to quality assurance documentation to understand the software’s quality with respect to its planned functionality. Test strategy, test plans and error reports should be included in quality assurance documentation.  Activities – The second component, namely, activities include: o Risk analysis – The white box testing is based on architecture and design level risk analysis. White box testing should use a risk-based approach, both in the system’s implementation and the attacker’s frame of mind and abilities. o Test strategy – This is the first step developed on the basis of risk analysis in planning white box testing. The test strategy is developed to clarify major activities involved, key decisions made and challenges faced in the testing effort. o Test plan – The aim of the test plan is to organise the subsequent testing process. The test plan includes test areas covered, test technique implementation, test case and data selection, test cycles, test results validation and others. o Test case development – The test case details include preconditions, generic or specified test inputs, expected results and steps to execute the test. The aim of the test case is to note what the specific test is designed to achieve. Risk analysis, test strategy and test plan should monitor test case development. o Test automation – They offer automated support for the process of managing and executing tests, particularly for iterating past tests.

Sikkim Manipal University B1965 Page No. 220 Software Engineering Unit 11

White box testing needs software development to support executing specific tests. o Test environment – It is very important to establish and manage a proper test environment. The test environment consists of computers for basic applications and it can become very complex for enterprise level software systems. o Test execution – In test execution, the first step is to validate the infrastructure required for running tests in the first place. This infrastructure primarily involves the test environment and test automation, and also stubs that may be required to run individual components, artificial data used for testing databases that the software need to run and other applications that interact with the software. o Testing techniques and tools – Various tools and techniques are used to conduct the white box testing. The techniques are used to understand the program and develop test cases and analyse other features of the code. The tools are used to check the source code to detect errors efficiently.  Outputs – The aim of testing is to ensure that the software that is undergoing testing meets the security goals of the system and is capable of thwarting unwanted attacks. Various kinds of errors are discovered during white box testing and are very context sensitive to the software under test. Let us look at some common errors discovered during testing.  Sensitive data being visible to unauthorised users.  Data inputs compromising security restrictions.  Design flaws not appearing to have emanated from the design specification.  Inappropriate control flow compromising security.  Inappropriate implementation of security functionality.  Boundary constraints not appearing at the interface level. White box testing improves overall test effectiveness and test coverage. It enhances productivity in discovering bugs that are difficult to identify.

Sikkim Manipal University B1965 Page No. 221 Software Engineering Unit 11

Basis path testing Let us now discuss basis path testing which is used for devising a white box test case. Basis path testing is a method for assuring that all independent paths through a code module have been tested at least once. Any path through the code that establishes at least one new set of processing statements or a new condition is called an independent path. Basis path testing offers a minimum, lesser bound on the number of test cases that need to be written. The test paths in a basis set (a set of linearly independent paths that are used to create any path through the program flow graph) fulfil the requirements of branch testing and test all the paths that can be used to create random path through the graph. Let us see the four steps of basis path testing:1 1. The first step is to compute the program graph. 2. The second step is to calculate the cyclomatic complexity. 3. The third step is to select a basis set of paths. 4. The fourth step is to generate test cases for each of these paths. We can depict any function as a control flow graph in a program. The program statements are the nodes shown in the graph, and the flow of control is the directed edges. We may connect two nodes by an edge in either direction or by an edge in each direction. When we trace a path from supply to destination, the edge leads back to a node that has already been visited. We can call this as back-edge. A control flow graph contains one supply node and one destination node. A supply/source node is a node that has no incoming edges. A destination/sink node is a node with no outgoing edges. Sometimes, a program may have more than one destination. Let us see a simple control flow graph in Figure 11.3.

1 McCabe Sikkim Manipal University B1965 Page No. 222 Software Engineering Unit 11

Source/Supply

a b

c d

Sink/Destination

Fig. 11.3: Control Flow Graph In Figure 11.3, we see four edges: a, b, c and d. We represent the path bd by the vector [0 1 0 1], and then combine the paths by adding or subtracting the paths’ vector representations. We cannot form every path in the basis set as a combination of other paths in the basis set, but can form any path through control flow graph as a combination of paths in the basis set. The complete flow graph does not have two edges going to the same sink. A basis set for the figure is {ac, ad, bc}. The path bd may be constructed by the combination bc + ad − ac as shown in Table 11.2.

Table 11.2: Calculation of Path

bc + ad − Edge bd bc bc + ad ac a 0 0 1 0 b 1 1 1 1 c 0 1 1 0 d 1 1 1

{ac, bd} is not a basis set, as there is no way to construct the path ad. The set {ac, ad, bd} is basis set. Basis sets are not unique, and hence a flow graph can have more than one basis set. We can consider the decisions as independent in the basis path method. If the decision is taken at the source node, it is irrespective of the impact taken on a node further down the graph.

Sikkim Manipal University B1965 Page No. 223 Software Engineering Unit 11

Self-Assessment Questions 5. Structured testing is applicable to large program. (True/False) 6. Test strategy is a management activity. (True/False) 7. The first step in basis path testing is to compute _____.

11.4 Control Structure Testing As we are now familiar with the method “white box testing,” we will study about a component of white box testing called “control structure testing.” Control structure testing helps us to broaden the testing coverage area and improve the quality of white box testing. Let us study about the methods of control structure testing.  Condition testing – It is a test construction method that aims at exercising the logical conditions in a program module. The errors in the condition are due to various errors such as Boolean, operator, variable, parenthesis, relational operator and arithmetic expression. In multiple conditions testing, the testing needs all true–false combinations of simple conditions to be run at least once. Hence all statements, conditions and branches are considered in this manner.  Branch testing – This is also called decision testing. For every decision each branch should be executed at least once. The decision statements are “if,” “for,” “switch” and “while.”  Loop testing – Algorithms need loops and they are required to be thoroughly checked. There are four types of loops, which are as follows: o Simple – In simple loop, “n” is the maximum number of allowable passes through the loop. o Nested – Simple loop testing is carried out here. o Concatenated – Simple loop testing is used if the loops are independent. If the loops are dependent, they are treated as nested loops. o Unstructured – Here, the test is not conducted but the software is redesigned.  Data flow testing – This selects the test paths according to the location of definitions and usage of variables. This is a refined technique and is not practical for general use. The testing should be directed to modules with “nested if” and “loop” statements.

Sikkim Manipal University B1965 Page No. 224 Software Engineering Unit 11

Self-Assessment Questions 8. Control structure testing helps to improve the quality of white box testing. (True/False) 9. Branch testing handles the implicit paths that result from ______. 10. Loop testing should be directed to modules with “nested if” and “loop” statements. (True/False)

11.5 Black Box Testing In the previous section, we discussed about white box testing. Let us now discuss about another testing method, namely, black box testing. Black box testing comes under unit testing. In unit testing, the components are tested individually to assure that they operate correctly. The black box testing depends on the specification of the component which is being tested to draw test cases. It has concerned about the inputs and the outputs that are produced as a result of the test. It is a functional testing process to validate if the unit fulfils its requirements or not. The unit is “black box,” and the behaviour is determined by learning its inputs and outputs. Black box testing checks that necessary and correct functionality has been built into the software, the interface works correctly, data structures behind the interface work correctly, and the behaviour and performance of the system are within the right boundaries. It also checks that the initialisation and termination of the program are accurate. We use requirements to verify the right outputs of black box testing. The test cases are used to validate that the correct software is being developed. The different forms of black box testing are integration testing, functional testing, system testing, acceptance testing, beta testing and regression testing. A minimum black box test group should consist of one test case for every requirement of the application. Equivalent partitioning, boundary value analysis, decision tables and diabolical test cases should be further created to optimise testing. We will now briefly discuss some basic black box test design techniques.  Decision table testing – The decision tables are a specific and compact method to model complex logic. The decision tables are indicated in the form of flow charts, switch case and if-then-else statements, and associate conditions with actions to perform.

Sikkim Manipal University B1965 Page No. 225 Software Engineering Unit 11

 All pairs testing – We can also call it as pair-wise testing. It is a combinatorial software testing method where we conduct the tests on all possible different combinations of parameters, for all pairs of input parameters to a system.  State transition tables – We can define these tables as tables that represent what state a finite semi-automation or finite state machine will move to, based on the present state and other inputs. We can define a state table as a truth table where current state signifies the input, and the next state signifies the output, along with other outputs.  Equivalence partitioning – It is a software testing technique that partitions the input data of the software unit into parts of data from which the test cases can be drawn. This technique helps to define test cases that discover classes of errors, thus decreasing the total number of test cases that should be developed.  Boundary value analysis – It is a software testing technique where the tests are designed to include representatives of boundary values. The values could be either input or output limits of a software component. Since these boundaries are common, positions for errors that effect in software failures they are often implemented in test cases.

Activity 1: Create a flow for black box testing in your organisation. (Hint: Black box testing techniques.Refer section 11.5)

Self-Assessment Questions 11. Glass-box testing is another name for ______testing. 12. ______is a software testing technique that partitions the input data of the software unit into parts of data from which the test cases can be drawn. 13. Regression testing is a ______testing method.

11.6 Testing Real-Time Systems In the previous section, we studied about black box testing; let us now learn about testing real-time systems.

Sikkim Manipal University B1965 Page No. 226 Software Engineering Unit 11

There is a rising awareness about software engineering practice as software is becoming more and more complex with each passing day. We require both formal verification techniques and testing techniques for handling the growing complexity. This is predominantly true in areas such as embedded systems used in consumer electronics, communication protocols from telecommunication industry and time-dependent systems happening in mission-critical systems such as avionics, health care, banking, stock markets, and so on. The real-time application presents a new and potentially difficult element to testing. The test case designer should consider white box and black box test cases along with interrupt processing, timing of the data and other factors. In many circumstances, when a real-time system is present in one state and the test data is given as input it leads to proper processing. When system is in a different state, and if the same data is given as input, it may lead to an error. Sometimes, the link that is present between real-time software and its hardware environment leads to testing problems. Let us briefly describe the strategies for test case design that have evolved for real-time systems.  Task testing – This is the first step of real-time software testing. This method is used to test each task independently. White box and black box tests are designed and executed for every task. During these tests, each task is executed independently, and the errors are discovered in logic and function. The timing and behaviour are not shown in task testing.  Behavioural testing – This is the second step of real-time software testing. The behaviour of a real-time system is simulated using system models and it is studied as a result of external events. All these analysis activities serve as a basis for design of test cases. It is conducted when real-time software is being built. It this testing, the behaviour of the system model and the executable software are compared. The behaviour of the software is inspected to uncover behaviour errors.  Inter-task testing – This is the third step of real-time software testing. After the isolation of errors in individual tasks and in system behaviour, the testing process moves to time-related errors. Asynchronous tasks that interact with one another are tested with various data rates and processing load. This is done to determine if inter-task synchronisation Sikkim Manipal University B1965 Page No. 227 Software Engineering Unit 11

errors are likely to occur. Also, the tasks that interact through a message queue or data store are tested to discover errors in the sizing of these data storage fields.  System testing – This is the fourth step of real-time software testing. The complete range of system tests are conducted on the integrated hardware and software. This is done in an attempt to find out errors in software–hardware interface. Interrupts are mainly processed by real- time systems. Thus, testing the handling of these Boolean events is important. The tester develops a list of all probable interrupts using state transition diagram and control specification, and also the consequential processing that arises as a result of interrupts. A new framework for testing real-time systems has been proposed. The steps of this framework are as follows:  A method for generating test sequences is proposed.  The constraints that guarantee the execution of test sequences are determined.  Next, a procedure and test architecture to execute test sequences is proposed.

Self-Assessment Questions 14. The errors are discovered in logic and ______in task testing. 15. The behaviour of the system model and the executable software is compared in inter-task testing. (True/False) 16. All probable interrupts are developed using ______and control specifications.

Activity 2: Suppose you are assigned the task of testing real-time system in your organisation. Write the steps you will follow for the same. (Hint: Strategies of real-time testing. Refer section No. 11.6)

11.7 Automated Testing Tools We discussed about testing real-time system in the previous section; let us now discuss about automated testing tools.

Sikkim Manipal University B1965 Page No. 228 Software Engineering Unit 11

It is very important to use the appropriate testing tool at the right time in a software project. The testing tool increases the efficiency of testing by automating processes as it helps to increase communication, promote best practices and reuse tests and test data. We can describe automated testing as the process of running test cases where manual involvement is not required to run each test case. Different tools are available for automated testing process including commercial products, in-house tools, open source tools and others. Open source tools are not updated regularly and do not support present technology, and are less expensive. Commercial products are based on present technology and trends. In-house tools are developed for particular operations by the software organisation. Let us have a quick overview of some available automated testing tools.  Automated Test Designer (ATD) The tool is a Windows client and/or server tool intended to create test cases, t data and automated test scripts.  Compuware – TestPartner and QARun Compuware provides automated, that is, computerised functional and regression testing tools. TestPartner gives reasonable assurance that testing efforts are complete when testing complex applications based on Microsoft, Java and web-based technologies.  BSSE System and Software Engineering – DARTT It is a tool for automated, that is, computerised testing over subprogram parameter range. We can use the DARTT tool (Dynamic Ada Random Test Tool) for verification of software and for quality analysis of the inspected code. This tool estimates the test results and produces documents or graphical reports. For subprogram testing, DARTT sets the test environment on the basis of the subprogram’s condition. We can also use DARTT as quality analysis tool, for identification of unhandled exceptions or significant changes of output.  Hewlett-Packard Company – Mercury TestDirector for Quality Center It offers a method for collection of requirements, planning and scheduling of tests, analysis of results and management of defects and problems.

Sikkim Manipal University B1965 Page No. 229 Software Engineering Unit 11

 Hitex Development Tools GmbH – Tessy It is an automated unit testing tool, which computerises the unit testing of embedded software written in C. The testing tool “Tessy” provides code coverage and creates test documentation in different formats. It also maintains some cross compilers and debuggers made for embedded systems and hence is able to execute the tests on real hardware. We can say that the tool is well suited for regression tests.  Mercury – QTP and WinRunner They provide a complete solution for functional test, GUI test and regression test automation. These tools support almost every software application and environment.  Odin Technology – Axe We can define Axe as a new class of process-oriented tools related to business, which permit users (non-technical) to automate testing. It offers a way to rapidly organise automated testing systems, which can be used by workers without expert automation talent thereby reducing training efforts and costs.  Reactive Systems, Inc – Reactis Tester It is a model-based automated testing tool, which produces test cases for implementations from models. Then, we compare these outputs to determine whether or not the code adapts to its model. We can specify how extensive the testing should be. The tool removes the need for producing test groups manually and decreases the time spent in testing by assuring that unnecessary tests are avoided.  Software Research, Inc – SMARTS It is an automated test management tool, which is referred to as a software preservation and regression test system functioning as a stand-alone product or as part of the entirely integrated Test-Works or Regression multi-platform set of testing tools. SMARTS computerises and simplifies the testing process by organising tests into a hierarchical tree. It provides the ability to automatically execute all or a subset of tests, and generating a range of reports based on test results.

Sikkim Manipal University B1965 Page No. 230 Software Engineering Unit 11

Self-Assessment Questions 17. It is very important to use the appropriate testing tool at the right time in a software project. (True/False) 18. Commercial products for automated testing are based on ______. 19. Which tool computerises the unit testing of embedded software written in C?

Activity 3: Prepare a list of commonly used automated testing tools. Hint: Refer section No. 11.8

11.8 Summary Let us recapitulate the important concepts discussed in this unit:  Software testing is an activity that aims at evaluating the capability of a program or system. It finds out whether the program meets the required results or not. It also identifies errors in the coding of the application that have to be eventually fixed.  There are three important kinds of testing – white box testing, black box testing and control structure testing.  White box testing helps in ensuring software’s security and effectiveness.  Black box testing is designed to validate functional requirements irrespective of the program’s internal working.  Control structure testing exercises logical conditions present in a program unit.  Real-time systems, which are growing more and more complex, need their own strategies for testing like task testing, behavioural testing, inter-task tasking and system tasking.  Various kinds of automated testing tools have been introduced by leading companies that can be effectively used for the purpose of testing and uncovering unknown errors.

Sikkim Manipal University B1965 Page No. 231 Software Engineering Unit 11

11.9 Glossary Acceptance testing: It is the testing performed on a system before the system is delivered to a live environment. Beta testing: It is the testing of a re-release of software product carried out by customers. Branch testing: It is a kind of testing where all branches in the code are tested at least once. Combinatorial software testing method: It addresses generation of test cases for issues that involve multiple parameters and combinations. Cyclomatic complexity: Software metric that is used to indicate the complexity of the program. It calculates the number of linearly independent paths through a source code. Debugging: It is the process of identifying and fixing bugs in a software code or hardware device. Functional testing: It is a type of user interface testing where functionality of application is tested. Integration testing: It is a development process where the program units are combined and tested as groups. Interrupt processing: An event that changes the sequence in which the processor executes instructions is called an interrupt. To handle interrupt, methodical procedures are implemented. This activity is called interrupt processing. Regression testing: Retesting of an earlier tested program following alterations that faults are not introduced or exposed as a result of modifications made. Stubs: Stubs are the name given to replacements for unavailable components that the components being tested will call as part of the test. System testing: In system testing, various tests are carried on system to find out functionality or to find out problems.

11.10 Terminal Questions 1. Explain software testing fundamentals. 2. What is white box testing? 3. Explain in detail the black box testing.

Sikkim Manipal University B1965 Page No. 232 Software Engineering Unit 11

4. What is control structure testing? 5. Explain testing of real-time systems.

11.11 Answers Self-Assessment Questions 1. Error free 2. Arrangement 3. Testable 4. Program 5. False 6. True 7. Program graph 8. True 9. Compound conditionals 10. False 11. Black box 12. Equivalence partitioning 13. Black box 14. Function 15. False 16. State transition diagrams 17. True 18. Present technology and trends 19. Hitex Development Tools GmbHTessy

Terminal Questions 1. (Refer to Section 11.2 for further information.) 2. (Refer to Section 11.3 for further information.) 3. (Refer to Section 11.4 for further information.) 4. (Refer to Section 11.5 for further information.) 5. (Refer to Section 11.6 for further information.)

11.12 Case Study Effective Implementation of Software Testing Technique An organisation is involved in an online business. It was in the process of establishing an online e-commerce website. In an effort to facilitate the

Sikkim Manipal University B1965 Page No. 233 Software Engineering Unit 11 customers to electronically and effectively transfer funds from customer checking accounts to organisation accounts, the organisation outsourced its payment processing to a third party, Internet enabled transaction payment firm. This third party payments software gave customised interfaces to help payment processing between customers and the organisation. A thorough security risk analysis was carried on the system. Problems faced: Risk assessment recognised transactions processing between payments interface and the application as one of the risks. The effect of false transaction is severe for both the customer and the organisation. Because of this, the customers might suffer financial loss resulting from unauthorised transactions that can reduce account balances. The credibility and the reputation of the organisation could be seriously damaged as a result of false transactions. A high-level white box testing was carried out on the modules using the payments interface. The steps involved in this case are as follows: 1. All the component interfaces were recognised and depicted as interface figures. 2. On the component interactions, the trust relationship boundaries were laid. 3. Data flows between components were drawn. Solution: Misuse cases were established on the basis of this information. One of the misuse cases stated to exercising the payments processing functionality as an unidentified user. The data flow showed a way where inputs from all the users were not validated or genuine. A test case was created to submit an account transfer from an external account to the organisation account anonymously and the account transfer was completed successfully, which is a vital software error — illegal transactions through false path were allowed. The risk assessment also recognised a weak confirmation component in the payment customer service component of the system. After the analysis and testing, it was shown that an attacker could achieve direct access to the organisation administrative accounts. With this access, an attacker could readdress transactions from organisation account to another, non- organisation account.

Sikkim Manipal University B1965 Page No. 234 Software Engineering Unit 11

With the use of above two described exploits, white box testers showed that an attacker could obtain payments from unknowing customer to the organisation account and then redirect the transaction from the organisation account to a non-organisation account. The two bugs together form a severe crack of security with major business impact. The above discussed scenario shows that risk analysis produces business- related results and addresses specific exposed areas of the software. Discussion Questions: 1. Explain the scope of white box testing. 2. How are the bugs identified?

References/E-references:  http://www.answers.com/topic/black-box-testing  http://www.computer.org/portal/web/csdl/doi/10.1109/RTCSA. 2000.896424

Sikkim Manipal University B1965 Page No. 235 Software Engineering Unit 12

Unit 12 Software Testing Strategies Structure: 12.1 Introduction Objectives 12.2 A Strategic Approach to Software Testing Verification and validation Organising software testing A software testing strategy Criteria for completion of testing 12.3 Strategic Issues 12.4 Unit Testing Unit test considerations Unit test procedures 12.5 Integration Testing Top-down integration Bottom-up integration Regression testing Smoke testing Comments on integration testing Integration test documentation 12.6 Validation Testing Validation test criteria Configuration review Alpha and beta testing 12.7 System Testing Recovery testing Security testing Stress testing Performance testing 12.8 The Art of Debugging The debugging process The psychological consideration Debugging approaches 12.9 Summary 12.10 Glossary 12.11 Terminal Questions 12.12 Answers 12.13 Case Study

Sikkim Manipal University B1965 Page No. 236 Software Engineering Unit 12

12.1 Introduction In the previous unit, we discussed about software testing fundamentals and objectives. We also analysed the process of test information flow and case design. We discussed various testing methods such as white box testing, black box testing and control structure testing. We also studied various methods of testing real-time systems and various kinds of automated testing tools. In this unit, we will study about strategic approach to software testing and strategic issues. We will also discuss about different kinds of testing such as unit testing, integration testing, validation testing and system testing. We will also study the art of debugging along with its process and approaches. This unit will enable us to get an overall view of software testing strategies and approaches. It will also enable us to carry out testing successfully by using various testing methods. It will also enable us to carry out debugging correctly.

Objectives: After studying this unit, you should be able to:  define strategic approach to software design  describe strategic issues  explain unit testing and integration testing  describe validation testing and system testing  elaborate the art of debugging

12.2 A Strategic Approach to Software Testing Let us start our discussion with the concept of strategic approach to software testing. We can define “testing” as an activity which is planned and carried out methodically. Prior to this, an outline for testing is defined. All the guidelines in the outline are called as the testing strategies. These testing strategies provide:  Incorporation of software test case design practices into a well- organised set of steps. This results in successful software development.  Description about the steps to be carried out during testing and the amount of effort, time and resources required.

Sikkim Manipal University B1965 Page No. 237 Software Engineering Unit 12

 Specifications of test plan, case design, execution and resultant data collection and evaluation.  Flexibility to support an adapted testing approach.  Strength to promote realistic planning and management tracking as the project proceeds.  Various test practices that are combined to present a new approach and philosophy. The project manager, software engineers and testing experts develop the strategy. Testing is very important in the life cycle of the software. Testing needs more project effort than any other software engineering activity. If it is carried out unsystematically, it leads to wastage of time and effort, and the errors will escape from the tester without being detected. Later on, they can surface as defects after delivery to the customer, which can not only result in huge financial losses that will have to be rectified, but also cause quite a bit of embarrassment for the software company. Let us now have a brief discussion about some aspects of software testing 12.2.1 Verification and validation Let us first discuss about verification and validation. Validation and verification are important stages in testing. Validation is basically checking whether the developers are developing the right product or not. The software should function in the manner the user wants. Verification is checking whether or not the developers are developing the product right. The software should match its provided specifications. Validation and verification should be implemented at every stage in the software process. The objectives of validation and verification are to:  Discover defects in the system.  Evaluate the system to check whether it is usable in operational situations or not. 12.2.2 Organising software testing We will now describe how to organise software testing, with the help of the following steps: 1. The software engineer analyses models, and then develops a computer program and its documentation. Testing is destructive according to the

Sikkim Manipal University B1965 Page No. 238 Software Engineering Unit 12

software engineer’s perception because testing attempts to break the software which the engineer has developed. 2. Testing should not be done by a developer. It should be done without any partiality. Testers should be involved when testing steps are about to start in the project. 3. Eliminate related issues by allowing the developer who has developed the product to do so. 12.2.3 A software testing strategy After “organising software testing,” we will now learn about software testing strategy. We know that the software engineering process begins with system engineering that describes the software as a part of the system, and proceeds to software requirements analysis where the information domain, function, behaviour, performance, limitations and validation criteria for software are identified. After the validation criteria are recognised, the design is established and finally the coding is done. Following the coding work, we provide a plan for software testing. Software testing includes four different types of testing – unit testing, integration testing, validation testing and system testing. 1. The first step is unit testing. Unit testing focuses on each unit (components) of the code. This testing makes sure that the unit functions correctly. 2. The second step is integration testing. All the components are integrated to form a complete software package. Integration testing handles the issues related with the dual problems of verification and program construction. After the software is integrated, a set of high-order tests are conducted. 3. The third step is validation testing. Validation criteria should be tested. Validation testing offers final assurance that the software fulfils functional, behavioral and performance requirements. 4. The fourth step is system testing. System testing verifies whether all elements are interconnected correctly, and it checks whether the entire system performance has been achieved or not. 12.2.4 Criteria for completion of testing Let us now analyse the criteria for completion of testing.

Sikkim Manipal University B1965 Page No. 239 Software Engineering Unit 12

“When to stop testing?” is indeed a very difficult question to answer, because there is no possibility of knowing whether the error detected is the last error in the code. Thus, after sufficient testing is done, a software engineer requires certain criteria to determine successfully the completion of testing. By using statistical modelling and software reliability theory, we can establish models of software failures as a function of execution time. These failures are uncovered during testing. The standard that is used to measure a test objective is called “completion criteria.” The criteria can be quantitative or qualitative which needs to be determined by the test team whenever a test objective is accomplished. For each test objective, one or more completion criteria should be specified. The following are the common criteria:  The testing is stopped when the planned time for testing expires.  The testing is stopped when all the test cases are unsuccessful, that is, when all test cases have been executed without finding errors. Self-Assessment Questions 1. Unit testing focuses on ____ of the software as implemented in the code. 2. The question “Are developers developing the right product?” pertains to ______. 3. Both validation and verification are same. (True/False)

12.3 Strategic Issues After studying about a strategic approach to software testing, we will now study about strategic issues. The testing always starts at component level and moves upwards, that is, towards testing the complete system. This is called the testing strategy. The initial focus is on testing modules, and later the modules are integrated and tested. A software developer conducts the testing and test groups assist the software developer for big projects. Testing and debugging are different actions. In any testing strategy, debugging should be included. There are certain strategic issues which should be considered. Let us have a look at some of these strategic issues.  We have to specify the product requirements in a measurable manner before testing – A good strategy assesses quality

Sikkim Manipal University B1965 Page No. 240 Software Engineering Unit 12

characteristics such as maintainability, portability and usability along with finding errors.  We have to state testing objectives clearly – Specific goals of testing are mentioned such as test effectiveness, test coverage and the cost to detect and solve defects.  We have to understand the user of the software and profile should be developed for each – Cases should be used to explain interaction scenario for every class of user. This decreases testing effort by focusing testing on the actual use of the product.  We should develop strong software which is designed to test itself – The method of designing software should be such that it uses anti- bugging methods. Software should be able to diagnose errors. The design should include regression and automated testing.  Technical reviews should be conducted before testing – Technical reviews (called as walk-throughs) reduce testing effort needed to construct high-quality software.  Continuous improvement approach should be developed – Testing strategy should be precise. The metrics gathered during testing should be used as statistical process control approach for testing.

12.4 Unit Testing The previous section familiarised us with strategic issues in testing. This section will focus on unit testing. To understand unit testing, let us first understand the meaning of “unit.” The smallest building blocks of software are called units. Units are made up of individual functions in a language like C. We can define “unit testing” as the method of validating small basic blocks of a complicated system, before testing an integrated big module or the whole system. We will now have a quick overview of the benefits of unit testing. Unit testing is able to:  Test parts of a project without waiting for the other parts to be created.  Accomplish parallelism in testing, by being able to test and fix problems simultaneously by several developers working in tandem.  Detect and remove errors at a much lower cost as compared to removing them at later stages of testing. The cost comprises the effort taken for organising the test cases, executing the test cases, analysing the results and fixing the defects. Sikkim Manipal University B1965 Page No. 241 Software Engineering Unit 12

 Take advantage of a number of formal testing techniques present for unit testing.  Simplify debugging by restricting to a small unit the probable code areas in which to look for bugs.  Test internal conditions that cannot be reached easily by external inputs in large integrated systems.  Accomplish high level of structural coverage of the code.  Prevent lengthy compile-build-debug cycles while debugging complex problems. 12.4.1 Unit test considerations Let us now learn about some unit test considerations. The interface module is tested to check the information flow in and out of the program. The local data structure is inspected to assure that the data stored momentarily maintains its integrity in all steps in a code’s execution. To make sure that all statements in a module are executed at least once, all independent paths through control structure are implemented. Finally, all error handling paths are tested. Before any other test starts, the data flow across a module interface should be tested. During unit testing, the local data structures should be implemented and the impact on global data should be determined. During unit testing, selective testing of execution paths is an important task. To uncover errors due to wrong computations, control flow and comparisons, test cases should be designed. The two effective techniques to discover path errors are basis testing and loop testing. You must note that the common errors in computation are as follows:  Misunderstood or wrong arithmetic precedence.  Varied mode operations.  Wrong initialisation.  Wrong symbolic representation of an expression. Test cases should discover errors, such as:  Evaluation of unlike data types.  Wrong logical operators or precedence.  Probability of equality when precision error makes equality improbable.  Improper comparison of variables.

Sikkim Manipal University B1965 Page No. 242 Software Engineering Unit 12

 Incorrect or missing loop termination.  Failure to exit while divergent iteration has come across unexpectedly.  Incorrectly altered loop variables. 12.4.2 Unit test procedures Let us now study about unit test procedures. Usually, we consider “unit testing” as an addition to the coding stage. Unit test case starts after source level code is developed, reviewed and verified for association to component-level design. A review of design information offers direction for establishing test cases. Each test case should be combined with a set of expected results. For every unit, test drivers and/or stubs are developed as the component is not a separate program. Driver can be defined as a main program that allows test case data to be passed to the component, and finally prints the relevant results. Stubs act as replacement modules which are subordinate to the components being tested. A stub or a dummy subprogram utilises the subordinate modules’ interface, does minimum data manoeuvring, prints verification of entry and returns control to the module. Drivers and stubs are individual programs that are developed to test the module but they are not delivered to the user. Thus, drivers and stubs symbolise overhead. If the drivers and stubs are simple then overhead will be comparatively low. We cannot test many components effectively with simple overhead software. In these cases, complete testing is postponed till the integration testing. Unit testing is minimised when a unit with large cohesion is designed. When the unit has one function, the number of test cases is minimised and errors are easily expected and discovered. Self-Assessment Questions 4. A review of _____ offers direction for establishing test cases. 5. Unit testing is more ____ compared to the other stages of testing. 6. Boundary conditions are tested to assure that the module operated correctly at ______established to limit processing.

Sikkim Manipal University B1965 Page No. 243 Software Engineering Unit 12

Activity 1: Consider a source code and document all the possible test cases for unit testing in your organisation. (Hint: Certain errors are identified by test cases. Refer Section No. 12.4)

12.5 Integration Testing We studied about unit testing in the previous section; let us now study about integration testing. We can say that the integration testing is the logical extension of unit testing, where we combine two tested units into a component and test the interface between them. Practically, we combine many units into components, which are aggregated into larger parts of the program. The combinations of pieces are tested and finally the process is expanded to test modules with other groups. Finally, all the modules making up a process are tested together. If the program is made up of more than one process, we should test them in pairs, instead of testing all at once. Integration detects issues that arise when units are combined. The errors discovered when combining units are mostly related to interface between units. We have to follow the given steps for integration testing: 1. First, we create a test plan. 2. Next, we create test cases and test data. 3. We create scripts to run test cases, if required. 4. Then, test cases are executed after the integration of components. 5. In the next step, we fix the bug and retest the code. 6. The test cycle is repeated until the components are successfully integrated. 12.5.1 Top-down integration Let us now discuss one of the methods of integration testing, namely, top- down integration. We can state an incremental approach to develop a program as top-down integration. In top-down integration, we first recognise the control hierarchy. This helps us to identify and categorise the modules. The modules that are subordinate to the main control module are integrated to the bigger structure. Depth-first or breadth-first approach is used for integrating.

Sikkim Manipal University B1965 Page No. 244 Software Engineering Unit 12

We first integrate all modules on a control path, in depth-first approach. Modules that are directly subordinate at each level are integrated together in breadth-first approach. Figure 12.1 explains the top-down approach.

Fig. 12.1: Top-Down Approach In Figure 12.1, you can notice that the sequence of integration of depth-first approach is (Module 1, Module 2, Module 4), Module 6, Module 8, Module 5, Module 7 and Module 3; the sequence of integration of breadth- first approach is (Module 1, Module 2, Module 3), (Module 4, Module 5), Module 6, Module 7 and Module 8.

12.5.2 Bottom-up integration After top-down integration testing, we will now study about bottom-up integration testing. The bottom-up integration test commences at the atomic module level. The lowest levels in the program structure are atomic modules. In this approach, stubs are not needed as modules are integrated from bottom-up, and processing needed for modules which are subordinate to a given level is always present. Let us have a look at the steps followed in bottom-up integration: 1. Combine low-level modules forming clusters which execute particular software sub-function. Clusters are also called builds. 2. Write control program to co-ordinate test case input and output. 3. Test the build.

Sikkim Manipal University B1965 Page No. 245 Software Engineering Unit 12

4. Remove drivers and combine the clusters moving upwards in the program structure. Figure 12.2 explains the program modules.

Fig. 12.2: Bottom-up Integration Bottom-up integration implemented to program modules

12.5.3 Regression testing Figure 12.2 illustrates bottom-up integration. The program structure changes when a new model is added. This results in new data flow paths, input/output, control logic and others. All these changes will affect the tested modules. We conduct “regression test” to recognise the errors and ensure that new errors have not crept into the units being tested. The number of regression tests can increase as integration testing continues. Hence, regression test set should be designed to include tests that handle one or more errors in every major program functions.

Sikkim Manipal University B1965 Page No. 246 Software Engineering Unit 12

In the previous section, we discussed about bottom-up integration technique; let us now discuss about another technique used in integration testing, namely, regression testing. Regression testing is done whenever an implementation is modified within a program. It is conducted by rerunning available tests against the altered code to verify the effects after modifications and new tests are written wherever required. For regression test, small amount of time should be spent without decreasing the possibility that the tester will find failures in the code which is already tested. Let us see the following strategies and factors that are considered during this process of regression testing.  Fixed bugs should be tested. The developer handles the symptoms, but not the cause for the bug.  When the bugs are fixed, the side effects of it should be noted. This is because new bugs can be created when the old ones are fixed.  For each bug fixed, regression test should be written.  When more than two tests are the same, identify which test is not effective and remove it.  Recognise tests that the code consistently passes and record them.  Functional issues should be focused on and not on issues related to design.  Modify data and identify resultant data corruption.  Effects of modifications on program memory should be traced. The establishment of library of tests is an effective way to carry out regression testing. The library of tests includes standard battery of test cases which are run every time when a new version of the code is developed. Few software development organisations incorporate only tests which have found bugs. The issue in such a case is that the specific bug may have been identified and fixed. To remove redundant or unnecessary tests, the regression test library should be regularly reviewed. 12.5.4 Smoke testing In the previous section we studied about regression testing. Let us now study about smoke testing. Smoke testing is basically related to the concept of project control, where variations of the actual project outputs are compared with required outputs. Time, cost and performance are the factors used in project control.

Sikkim Manipal University B1965 Page No. 247 Software Engineering Unit 12

The project outputs should be assessed frequently in projects where time is the limitation. Smoke testing comes into the picture from here. The following steps are followed to carry out smoke testing: 1. The first step in smoke testing is to design the built. Built is a functional unit in smoke testing. It brings together code, data files and libraries that work together to provide the functionality to the software product. 2. A series of tests are conducted to find out errors which have maximum probability to interfere with properly functioning software. The tests are carried out on modules. Various modules are combined and functionality stability between inter- modules is tested. There are many benefits of smoke testing, especially for complex projects where time is a limitation. Smoke testing should be done on high testing frequency basis whereby the errors will show up on time. The mid-level integration of different modules reduces the risk of inappropriateness at later levels. As smoke testing is an incremental approach, it helps to maintain the right schedule with respect to time. 12.5.5 Comments on integration testing Till now, we have studied about different techniques of integration testing; let us now consider some important comments on integration testing. Every strategy has its own advantages and disadvantages. The disadvantage of top-down integration is that it requires stubs, which have their own testing difficulties. The disadvantage of bottom-up integration is that the code individually does not live till the last module is added. Integration strategies should be selected on the basis of software characters and project agenda. It is better to use a combined approach which uses top- down tests for upper levels and bottom-up tests for subordinate levels of the program structure. Regression tests should take care on critical module function. 12.5.6 Integration test documentation After studying some important comments on integration testing, we will now study about integration test documentation.

Sikkim Manipal University B1965 Page No. 248 Software Engineering Unit 12

Integration test documentation includes the entire plan for integration of software and description of tests. The document includes test plan and procedure. The document plays an important role in software configuration. Test plan explains the entire strategy for integration. We can separate testing into phases and builds, which specify particular functional and behavioural characters of software. For all test phases, we apply the following criteria:  Functional validity – These are the tests conducted to discover functional errors.  Performance – These are the tests conducted to check performance limits established during software design.  Interface integrity – When each module is included into the program structure, internal and external interfaces are tested.  Information content – These are the tests conducted to find errors related to local or global data structures. Test Pla also includes the timeline for integration, development of overhead software and associated topics. Start and end dates of each phase and required test environments and resources are explained. Hardware configurations, special simulators and tools, and others are also described. Test procedure needed to carry out the test plan is provided in detail. The integration order and related tests at all integration levels are described. It also includes test cases and results. The test specification contains all the test results and problems. The information provided in the specification is very important at the time of software maintenance. It also includes references and appendices. According to the organisation’s requirement the test specification format can be created. Self-Assessment Questions 7. The logical extension of unit testing is the ______testing. 8. The ______is conducted by rerunning available tests against the altered code. 9. Integration strategies should be selected based on software characteristics and ______.

Sikkim Manipal University B1965 Page No. 249 Software Engineering Unit 12

Activity 2: Consider a source code of your choice, modify the implementation and carry out regression testing. Generate the document after testing. (Hint: Regression testing steps, Documentation criteria. Refer section No. 12.5)

12.6 Validation Testing In the previous section, we studied about integration testing and various methods associated with it; let us now study about validation testing. Validation testing is carried out after integration testing where software is assembled and errors related to interface are discovered and fixed. Validation works well when software functions in a way which can be expected by the client. 12.6.1 Validation test criteria We will start our discussion with validation test criteria. Software validation is done by a set of black box tests which illustrates conformity with requirements. It uses a test plan and test procedure. Test plans and procedures are developed to assure that all functional requirements are fulfilled, all behavioural characters, performance requirements are attained, documentation is proper and human-engineered and other requirements are fulfilled. After every validation test that is conducted, any two possible conditions exist – either a deviation from the specification is discovered and a deficiency list is generated or the function and performance features conform to specifications and are accepted. Deviation or fault discovered at this level in a project can sometimes be corrected before scheduled delivery. It is required to negotiate with the client to establish a method to resolve deficiencies. 12.6.2 Configuration review Configuration review is an important element of validation process. The goal of review is to ensure that all the elements of software configuration are correctly developed and catalogued and it contains all the required information to strengthen the support phase of software life cycle. The configuration review is known as audit.

Sikkim Manipal University B1965 Page No. 250 Software Engineering Unit 12

12.6.3 Alpha and beta testing Before releasing the software product into the market it should be tested. For this a formal test strategy is planned and then executed. Alpha and beta testing are conducted after completion of formal phases of testing. Before the software is released for public use, alpha testing is conducted. Alpha testing is carried out by using white box testing methods. The aim of this is to simulate real users and carry out tasks and operations that a usual user performs. Alpha testing is conducted in a lab environment and not in usual work environments. Beta testing is the next phase of testing. The goal of beta testing is to perform a rationality check before the product is released. During this stage errors can be found out, hence the software distribution is limited. Feedback is usually taken from outsourced testing companies to fix the errors. The techniques used in a public beta test are limited to black box testing methods. This is because the common people do not have knowledge of the software program under test.

Self-Assessment Questions 10. Software validation is done by a set of ______which illustrates conformity with requirements. 11. Alpha testing is conducted in a work environment. (True/false) 12. The goal of ______is to perform a rationality check before the product releases.

12.7 System Testing In the previous section, we studied about validation testing; let us now study about system testing. The system testing is conducted based on unit and integration testing. It is a very important step in quality management process. For system testing, the following are the prerequisites:  Unit test should be conducted on all the components.  Integration testing is conducted after integration of all components.  Complete the testing.  Create an environment resembling the production environment.

Sikkim Manipal University B1965 Page No. 251 Software Engineering Unit 12

The following are the steps carried out to do system testing: 1. The first step is to create a test plan. 2. The second step is to create test cases. 3. The third step is to build data that are used as input for testing. 4. The fourth step is to create scripts if required to build environment and to automate execution of test cases. 5. The fifth step is to execute test cases. 6. In the sixth step, bugs are fixed if present and code is retested. 7. In the seventh step, the test cycle is repeated.

12.7.1 Recovery testing We will now discuss about the various techniques of system testing, beginning with recovery testing. Recovery testing is conducted to check how fast and better the application can recover against any kind of crash or hardware failure, and others. The objectives of recovery testing are:  To assure continuity of operations after failure.  To check recovery process and effectiveness of recovery process.  To ensure sufficient backup data are retained and secured.  Document recovery procedures.  Develop recovery tools and make them available. The following are the methods to show how recovery tests are used:  To evaluate adequacy assess procedures, methods, tools and techniques.  Failure can be introduced in the system after it is developed and verify whether the system can recover.  A simulated disaster is conducted on particular aspects of the application system. 12.7.2 Security testing Let us now learn about another technique of system testing, namely, security testing. Computer-based systems that handle sensitive data or cause actions that can harm individuals are often the target for illegal penetration. Illegal penetration includes activities such as hacking, employees gaining access to systems for malicious acts, and so on.

Sikkim Manipal University B1965 Page No. 252 Software Engineering Unit 12

Security testing is conducted to check the protection mechanisms built into a system to see whether they will protect the system from illegal penetration or not. In security testing, the tester will act as an attacker who attempts to get into the system. The tester tries to get passwords through external clerical ways, might attack the system with custom software, thereby denying service to others, might deliberately cause system errors, get into the system during recovery, browse through insecure data and hope to get the key to system entry. When sufficient time and resources are provided, a good security testing will eventually penetrate the system. The system designer should make penetration cost more than the value of the information that can be stolen in acts of illegal penetration.

12.7.3 Stress testing After security testing, we will now discuss about stress testing. Stress testing is carried out to evaluate a system or component at or beyond the boundaries of its particular requirements to determine the load under which it fails and how. It finds defects whose consequences are certain but which are hidden in complex code, and hence will be difficult to find when inspecting. Stress testing involves thinking of what could go wrong without really studying the software. Stress testing needs attention of the tester in detail. 12.7.4 Performance testing In the previous section, we discussed about stress testing; let us now study about another technique of system testing, namely, performance testing. Performance testing is carried out to understand the application or World Wide Web site’s scalability or to benchmark the performance in an environment of third party products like servers and middleware for purchase. This type of testing is specifically used to find out the performance of restricted access in applications of high use. The testing includes automated test set to allow easy simulation of normal, peak and exceptional load conditions. To test run-time performance of software within the background of an integrated system, performance test is designed. Performance testing is conducted throughout all the levels of testing process. But the true

Sikkim Manipal University B1965 Page No. 253 Software Engineering Unit 12 performance of a system can be ascertained only when all the system elements are integrated. Performance tests are combined with stress testing, and need hardware and software instrumentation to measure resource utilisation in an executing method. The tester can discover situations that result in degradation and probable system failure by using instrumentations in a system. Self-Assessment Questions 13. The ______is conducted to check how fast and better the application can recover against any kind of crash or hardware failure. 14. To check the protection mechanisms built into a system ______testing is conducted. 15. To test run-time performance of software within the background of an integrated system ______is designed.

Activity 3: Prepare a list of techniques you can use in system testing. Give some examples. (Hint: System testing steps. Refer section no. 12.7 )

12.8 The Art of Debugging In the previous section, we discussed about system testing, let us now study about the art of debugging. We can define “debugging” as the method of tracing and fixing errors in a computer program or hardware device. To debug a program or hardware device, we should start with a known problem, segregate the source of the problem and later fix it. An important process in software or hardware development process is debugging. Debugging is carried out regularly throughout the process for complicated products. After debugging is finished, the software program is released for general use. Though the product is released after thorough debugging, debugging continues as a maintenance practice for the product’s lifetime.

12.8.1 The debugging process Let us now have a brief discussion about the debugging process.

Sikkim Manipal University B1965 Page No. 254 Software Engineering Unit 12

The debugging process includes many steps to fix the detected error and check that the error does not appear again. The goal is to detect, classify, fix and verify the error. The following are the five steps in the debugging process in software. 1. The first step is to identify the problem. We check the presence of bug, and describe the problem caused by the bug and verify what the code is supposed to do. 2. The second step is to collect information. We gather all the comments and feedback from the users and note down the personal observations. We collect the test cases and also the environmental information. 3. The third step is to assess the problem and classify it. The theory behind the causes of the problem should be developed. The code should be reviewed. The problem is classified into categories such as syntax errors, memory problem and others. 4. The fourth step is to fix the root cause of the problem or bug after classifying the problem. 5. The fifth and final step is to test the software again to verify the fix.

12.8.2 The psychological consideration In the previous section, we discussed about the debugging process; let us now discuss about the psychological consideration while debugging. Debugging ability is an inborn human characteristic. Some are good at debugging and some are not. Shneiderman states on the human aspects of debugging1—“debugging is one of the frustrating parts of programming. It has elements of problem solving or brain teasers, coupled with annoying recognition that you have made a mistake. Heightened anxiety and the unwillingness to accept the possibility of errors increases the task difficulty. Fortunately, there is a great sigh of relief and a lessening of tension when the bug is ultimately corrected.” Though it is difficult to learn debugging, many approaches to the problem are provided.

1SHN80 Sikkim Manipal University B1965 Page No. 255 Software Engineering Unit 12

12.8.3 Debugging approaches As we are discussing about the art of debugging, we will now discuss about the approaches used by programmers, for debugging, as shown in Figure 12.3.

Fig. 12.3: Debugging Approaches

 Brute Force Method – The common method of debugging is the brute force method. This method is not very efficient. This method includes loading print statements into the program, and printing the intermediate values. The results are printed to recognise the faulty statement. With the use of symbolic debugger, this method becomes more systematic since the values of various variables are checked easily, and break points and watch points are set easily to test the values of variables.  Backtracking – In this method, the source code is traced backwards starting from the statement where an error symptom is identified till the next error is found. Correspondingly, as the source lines to be tracked backwards increases, the number of backward path also increases. The number of paths may increase in this method.  Cause Elimination Method – In this method, a list of causes that could probably have contributed to the error symptom is identified, and tests are conducted to remove each cause. A related technique of identification of the error from the error symptom is the software fault tree analysis.  Program Slicing – Program slicing is similar to backtracking. Slices are defined to reduce the search space. At a specific statement for a specific variable, a slice of program is the set of source lines leading this statement. The slice of program influences the value of that variable.

Sikkim Manipal University B1965 Page No. 256 Software Engineering Unit 12

Self-Assessment Questions 16. The process of tracing and fixing errors in a computer software or hardware is called ______. 17. The first step in debugging process is identifying the ______. 18. ______method includes loading print statements into the program, and printing the intermediate values.

12.9 Summary Let us recapitulate the important concepts discussed in this unit:  “Testing” is an activity that is planned and carried out methodically. Prior to the actual testing work, an outline for testing is defined. All the guidelines in the outline are called the testing strategies.  Testing is a very important part of the software life cycle development. Errors, if untraced due to inadequate testing, can surface as defects later at the customer end, and this can lead to both financial losses and embarrassments.  Verification and validation are two important concepts in testing. Validation is checking whether the developers are developing the right product or not. Verification is checking whether the developers are developing the product right or not.  Testing, within the framework of software engineering, is done in a series of four steps that are implemented successively—unit testing, integration testing, validation testing and system testing.  “Debugging” is a method of tracing and fixing errors in a computer program or hardware device. The art of debugging is an important criterion of software testing and is accomplished in five steps—identify the problem, collect information, assess the problem and classify it appropriately, fix the root cause of the problem or bug and test the software again to verify the fix.  Psychological consideration is very important during the debugging process.

12.10 Glossary Break point: It is a point in computer code at which execution can be held for some time to allow manual or automated monitoring of a program.

Sikkim Manipal University B1965 Page No. 257 Software Engineering Unit 12

Hardware configuration: The arrangement of computer hardware for the required specification is called hardware configuration. Simulator: It is a tool, calculation or experiment, to reconstruct a particular condition in test conditions to model or monitor the results. Software fault tree analysis: It is a software failure analysis where an unwanted state of a system in analysed using Boolean logic. Symbolic debugger: Symbolic debugger is a source code debugger.

12.11 Terminal Questions 1. Explain strategic approach to software debugging in detail. 2. What are strategic issues? 3. Explain unit testing. 4. Explain integration testing in detail. 5. What is validation testing? 6. Describe system testing. 7. Explain debugging and its approaches.

12.12 Answers Self-Assessment Questions 1. Each unit 2. Validation 3. False 4. Design information 5. Cost effective 6. Boundaries 7. Integration 8. Regression testing 9. Project agenda 10. Black box tests 11. False 12. Beta testing 13. Recovery testing 14. Security 15. Performance test 16. Debugging

Sikkim Manipal University B1965 Page No. 258 Software Engineering Unit 12

17. Problem 18. Brute force

Terminal Questions 1. (Refer to Section 12.2 for further information.) 2. (Refer to Section 12.3 for further information.) 3. (Refer to Section 12.4 for further information.) 4. (Refer to Section 12.5 for further information.) 5. (Refer to Section 12.6 for further information.) 6. (Refer to Section 12.7 for further information.) 7. (Refer to Section 12.8 for further information.)

12.13 Case Study A Solution to Issues in Software Testing An organisation with decentralised global IT operations wanted to decrease operating expenses, while increasing efficiency and consistency within IT and quality assurance organisations. Executive management directed constant process improvement, but the environment required stable processes or tools to manage. Problem: Software testing within this organisation was managed primarily at the project level, without formal process, methodology, tools, metrics collection or reporting. All testing was conducted in the organisation with significant cost. Solution: The organisation took help from an organisation dedicated to provide testing services. This service provider developed well-defined software testing processes for the organisation, including estimation models, process road maps and other necessary structures. The service provider was able to decrease post-production errors through structured requirement analysis and complete traceability to test cases. Regression test cycle times were also minimised by automating test cases. The service provider also used process improvement awareness to assist complete metrics gathering and reporting. This improved perceptibility and appearance for IT and its services.

Sikkim Manipal University B1965 Page No. 259 Software Engineering Unit 12

Discussion Questions: 1. What were the steps taken to solve the issues of the organisation? 2. List out the benefits which the organisation gained.

References/E-References: E-References:  http://www.mobilein.com/WhitePaperonUnitTesting.pdf  http://www.exforsys.com/tutorials/testing/integration-testing- whywhathow.htmlhttp://www.aptest.com/testtypes.html

Sikkim Manipal University B1965 Page No. 260 Software Engineering Unit 13

Unit 13 Software Verification

Structure: 13.1 Introduction Objectives 13.2 Code Reading 13.3 Static Analysis 13.4 Symbolic Execution 13.5 Proving Correctness 13.6 Code Inspection or Reviews 13.7 Summary 13.8 Glossary 13.9 Terminal Questions 13.10 Answers 13.11 Case Study

13.1 Introduction We studied about strategic approach to software testing and strategic issues in the previous unit. We also discussed about different kinds of testing such as unit testing, integration testing, validation testing and system testing. Furthermore, we also studied the art of debugging, its process and approaches. In this unit, we will study about the different techniques of software verification such as code reading and the concept of static analysis. We will also discuss about symbolic execution. We will also analyse the concept of proving correctness. Finally, we will study about code inspection. This unit will enable you to carry out software verification successfully by analysing the verification techniques such as code reading, static analysis, symbolic execution, proving correctness, code inspection and provide guidelines to conduct software verification.

Objectives: After studying this unit, you should be able to:  describe code reading  explain static analysis  describe about symbolic execution

Sikkim Manipal University B1965 Page No. 261 Software Engineering Unit 13

 illustrate proving correctness  explain code inspection

13.2 Code Reading As we are going to discuss about different techniques of software verification, let us first discuss about the meaning of software verification. We can define software verification as one of the disciplines of software engineering that focuses on checking whether the software meets the requirements completely or not. This discipline has different techniques associated with it. Let us have a look at these techniques shown in Figure 13.1.

Fig. 13.1: Software Verification Techniques In this section, we will discuss about the first technique of software verification. We can define code reading as the process where the reviewer carefully reads the code to detect any divergence or disagreement between the provided design specifications and the actual implementation. It is one of the methods for code verification. The software engineer should know the technique of code reading. Code reading involves the following two steps: 1. In the first step, we determine the abstraction of module. 2. In the second step, we compare the design specifications. The process of code reading and designing is reverse in nature. In the code reading technique, it is necessary to understand the documents, software specifications and software design. This helps us to determine the consistency and correctness of the code. In the code reading process, it is preferable that the code is read beginning with the inner structure of module and radiated outwards. In the code reading process, we have to first determine the behaviour of the module abstract and then present the

Sikkim Manipal University B1965 Page No. 262 Software Engineering Unit 13 abstraction. The code reading process continues till the end of the module is reached. The abstract behaviour of the module will be known to the reader by the time the reader reaches the end of the module. Then, we compare the specifications to determine the disagreement. Code reading is very efficient because it has the ability to detect errors that cannot be detected by testing. As reading is an approach of stepwise abstraction, the code should also be programmed in a method favourable to this process. This results in producing well-structured programs. Code reading is performed to improve the software code, without completely changing the program or with lesser disruption in the present functionality of the program. This also focuses on inspecting the code and eliminating errors. Let us have a look at the general conventions we should follow while reading the software code. The steps are as follows: 1. The first convention is to find out what is important. Importance should be given to find out graphical techniques – italics or bold, and positions – start and end of the software code while reading the code. The necessary comments should be highlighted in the introduction or at the end of the code. The level of details should be according to the requirement of software code. 2. The second convention is to read what is important. The reading should be done with the intention to check syntax and structure like loops, brackets and functions instead of non-essentials like name of the developer who has developed the code.

Self-Assessment Questions 1. The abstraction of module is the first step in the _____ process. 2. Code reading is performed to improve the software code to completely change the program or with disruption in the present functionality of the program. (True/False) 3. Code reading is considered efficient because it has the ability to detect ______that cannot be detected by testing.

Sikkim Manipal University B1965 Page No. 263 Software Engineering Unit 13

Activity 1: Consider that you are a reviewer and you have to conduct a code reading process for a program of your choice. Find out the conventions you will follow for the same. (Hint: Conventions.)

13.3 Static Analysis After discussing about the code reading technique, we will now discuss about another software verification technique, namely, static analysis. We can define “static analysis” as an analysis of programs by sequentially analysing the program text without executing the program. We can perform “static analysis” by manual inspections, and also mechanically by using software tools. In this analysis, the program text acts as input to the tools, and the program is not executed. The goals of static analysis tools are to find errors or to generate information about the structure of the program, which can be helpful for documentation or to understand the program. We can design different kinds of static analysis tools to perform different types of analysis. Static analysis tools are used frequently. There are tools that cannot detect errors, and the errors escape in the code. Hence, we use static tools to prevent such omissions. Static analysis saves the effort of detecting the error from the data, because the errors itself get detected. Warnings are provided, if potential errors are present, and also a picture of the program’s structure is provided by the static analysis exercise. We use static analysis to verify contraventions of local programming standards, which are not detected by standard compilers. There are two forms of static analysis, namely, limited static analysis (static analysis that is performed on compilers) and data flow analysis. The data flow analysis focuses on the data used by programs and detects data flow irregularities. The irregularities are not errors but a symptom of errors, which are caused due to carelessness in typing or error in coding. If a code has data flow irregularities, it is a cause of concern which should be appropriately handled. The main objectives of static analysis are as follows:  Proscriptive analysis – It aims at detecting real or potential flaws in the program.

Sikkim Manipal University B1965 Page No. 264 Software Engineering Unit 13

 Descriptive analysis – It provides explanations of what is going on in the program.  Prerequisite for structural testing – Static analysis is a prerequisite for white box testing to find out parts of the program that are to be exercised during testing. Let us now briefly discuss about some static analysis tools. We use three types of static analysis tools, and they are as follows:  Code-based testing tools – In code-based testing tools, the source code is the input. The tool accepts the input, carries out analysis and finally test cases are generated. Using a description of program input and procedural design as a guide, static testing tools derive test cases using path coverage, condition testing and information flow criteria.  Specialised testing languages – These languages help software engineers to write detailed test specifications that describe each test case and the logistics for its execution. Yet, such tools do not help tester in designing test cases.  Requirements-based testing tools – These tools isolate particular user requirements and suggest test cases that will exercise the requirements. To work correctly, the tools should have access to a formal specification for the software. All the static testing tools have the ability to document and they list out all the tests conducted. They conduct comparisons of test output to see differences between expected and actual results.

Self-Assessment Questions 4. ______is defined as analysis of programs by sequentially analysing the program text without executing the program. 5. Static analysis is used to verify contraventions of ______which are not detected by standard compilers. 6. ______tools isolate particular user requirements and suggest test cases that will exercise the requirements.

Sikkim Manipal University B1965 Page No. 265 Software Engineering Unit 13

Activity 2: Prepare a list of software analysis tools. Give examples of the companies using those tools. (Hint: Refer to Section 13.3, Static Analysis.)

13.4 Symbolic Execution In the previous section, we discussed about static analysis; let us now study about symbolic execution, which is also a software verification technique. We can define “symbolic execution” as a process where the program is executed by replacing real variable values with symbolic input values, and to represent the values of program variables as symbolic expressions. As a result, the output values computed by a program are expressed as a function of the input symbolic values. The symbolic execution is carried out just like a normal execution; the only difference is that the values are symbolic formulae over the input symbols. Symbolic values of program variables, program counter and path condition are the states of symbolically executed program. Sometimes constraints are provided with which the inputs should agree. This helps the path condition to specify the conditions to execute the code in a specific path. The path condition is a Boolean formula over the symbolic inputs. The next statement to be executed is defined by the program counter. The execution paths tracked in symbolic execution of programs are represented by a symbolic execution tree. The program states are indicated as nodes and transitions between states are indicated by arcs. The path condition keeps track of constraints on symbolic values and determines the control flow path yielding the state. For example, when a conditional jump instruction is executed, to determine whether the jump condition and its cancellation are met under the present path condition, a decision procedure is raised. If both are met, we divide the present state into two next states, and add the path condition of each, with the clause determining which branch is executed. The symbolic execution of conditional branch type statements is difficult to handle. The symbolic execution along a path signifies unlimited numeric executions that may occur along that path. The advantages of symbolic execution are as follows:

Sikkim Manipal University B1965 Page No. 266 Software Engineering Unit 13

 It provides solid representation of the program state space, where large set of numeric values are represented by symbols, potentially limiting state explosion during analysis.  It allows analysis of software modules separately by initialising them with symbolic values, thus performing modular verification. We apply the symbolic execution to languages with numeric types. Symbolic execution, when considering languages that allow references and dynamic memory can be carried out with lazy initialisation. The probable initial values of symbolic reference are calculated by lazy initialisation, only when it is used first during execution. A large number of states are generated in later phases of symbolic execution, when all probable values are used first. Therefore, variants have been proposed to delay further the set of probable values which should be considered to minimise state explosion. Let us have a look at the symbolic execution tree shown in Figure 13.2. Consider a code fragment that illustrates symbolic execution tree as shown in Figure 13.2, which swaps the values of integer variables “a” and “b,” when “a” is greater than “b.” Initially, path condition is true and “a” and “b” have symbolic values “A” and “B,” respectively. Path condition is updated with assumptions about the inputs at each branch point to help choose between alternative paths. We can use symbolic execution to determine conditions under which a specific control flow path is taken. The symbolic execution in-turn helps to identify impracticable program paths and also those “forbidden” paths that should not be taken. It is basically to generate test data for the execution of particular parts and paths in a program.

Sikkim Manipal University B1965 Page No. 267 Software Engineering Unit 13

Fig. 13.2: Symbolic Execution Tree The effect of execution of deriving a logical representation is necessary to be given in a methodical way, which helps to compare a program’s probable behaviour to a formal specification. However, the basic methods of formal verification, including symbolic execution, support practical techniques in software analysis and testing. Let us now briefly discuss about few uses of symbolic execution and its techniques. They are as follows:  Rigorous proofs of properties of critical subsystems, such as a safety kernel of a medical device.  Formal verification of critical properties, which are specifically resistant to dynamic testing.  Formal verification of algorithm descriptions and logical designs, which are less complex than their implementations in program code. The basis of symbolic execution is tracing execution with symbolic values and expressions. When tracing execution with concrete values, it becomes

Sikkim Manipal University B1965 Page No. 268 Software Engineering Unit 13 clear as to what to do with a branch statement. For example, an “if” or “while” test – the test predicate is evaluated with the current values, and the appropriate branch is taken. If the values bound to variables are symbolic expressions, both the “true” and “false” results of decision may be possible. We can trace execution through the branch in either direction, and interpret the execution of the test as adding a constraint to record the outcome. We can say that symbolic execution acts as a bridge from an operational view of program execution to logical and mathematical statements. The symbolic execution technique is based on hand-execution method, that is, using symbols rather than concrete values. To use symbolic execution for loops, procedure calls and data structures present in modules, symbols are represented hierarchically that are continuous and without any break. This is done by composing facts about small parts into facts about larger parts. Symbolic execution is a basic technique that finds many different applications. The symbolic execution technique is used for test data generators to draw constraints on input data. Symbolic execution techniques are used by many development tools to perform or check program transformations, for example, re-factoring source code or unrolling a loop for performance. Software developers can rarely carry out symbolic execution of program code in detail, but often use it for reasoning about algorithms and data structure designs. The widely used approaches in programming are to specify pre-conditions, post-conditions and invariants. All these are supported by tools used for run-time checking assertions.

Self-Assessment Questions 7. The process where the program is executed by replacing real variable values with symbolic input values is called ______. 8. The states of symbolically executed program are program variables, ______and path condition. 9. The symbolic execution technique is based on ______method.

13.5 Proving Correctness After studying about the symbolic execution, we will now study about another software verification technique, namely, “proving correctness.”

Sikkim Manipal University B1965 Page No. 269 Software Engineering Unit 13

Proving correctness is one of the techniques of formal verification of the software. We can define “proving correctness of a program” as the process of demonstrating the correctness of the program, by proving the code’s consistency with its specification. Theoretical and mathematical models are used to prove the correctness of a program. It is carried out without executing the program. Many verification conditions can be generated that represent the correctness of the code mathematically. Once we use formal proof systems, the correctness of the code with respect to the requirement specification is guaranteed. Let us take a look at the following points which are necessary conditions in assuring correctness:  Development of program within a logical calculus is feasible.  It is methodically helpful to interpret programs as executable specifications.  Computer-supported verification is practicable for middle-size programs.  The question of scaling up to large systems remains open and the levels of exertion are high. For software and system technology, the ability to develop software systems that can be applied to a large scale and strive for correctness is of high importance. It is not possible to assert correctness for complex, heterogeneously constructed systems without the help of mathematical methods. The quality assurance and evidence of correctness will become increasingly important in the future years, when the demands for evidence of a dependable software product will become part of the established compulsory prerequisites. The correctness has to be proved for all steps during development. The two benefits of attempting the proof are as follows:  If successful, the proof guarantees that the program, or part of it, is indeed correct.  If failed, the proof may be a very effective tool for error detection, particularly if carried out at the high design level. Proving correctness of the program is the only reliable technique to show the program’s correctness. It should be used whenever correctness is of utmost importance, as in mission-critical systems where human lives are at stake. In the case of mission-critical systems, usually a small part of the

Sikkim Manipal University B1965 Page No. 270 Software Engineering Unit 13 code is responsible for its reliability, thus making the formal proof an economically feasible task. It basically aims towards analysing objects that are supposed to be correct or close to being correct. Sometimes individuals think that proving correctness of program should be reserved for parts of the program that are most likely to be incorrect and testing may be instrumental in the identification of those parts.

Self-Assessment Questions 10. We can define ______as the process of demonstrating the correctness of the program, by proving the code’s consistency with its specification. 11. Proving correctness of the program is the only reliable technique to show the program’s correctness. (True/False) 12. Proving correctness technique uses ______and mathematical models to prove the correctness of a program without executing the program.

13.6 Code Inspection or Reviews In the previous section, we discussed about proving correctness. Let us now discuss about code inspection which is also called reviews. We can define “code inspection” as one of the techniques of formal method to review a software product. The goal of code inspection is to detect errors caused due to typological mistakes and incorrect programming. Code inspections are highly structured and require proper training for all individuals. This kind of review is different from other reviews, such as peer review and walk-throughs. Code inspection technique requires someone else to learn and understand the material being presented, potentially giving a different dimension and interpretation at the inspection meeting. The individuals or the persons appointed to inspect the code are called inspectors. Every inspector is given the task of reviewing the code from a different point of view such as a user, a tester or a product support person. This helps to get different views of the product under review and frequently recognises the problem. To ensure that the material is covered evenly and completely, one inspector is assigned with the task of reviewing the code backwards – that is, from end to start.

Sikkim Manipal University B1965 Page No. 271 Software Engineering Unit 13

The software is presented to project managers and users for their comments and eventual agreement. The review and inspection team’s inspectors include a moderator who conducts meetings, checks errors and makes sure that the inspection process is followed, a reader who translates or interprets the operations of code, a recorder who records each error in the code to help others to think thoroughly about the code without missing anything, and the author who is a spectator and observes the code inspection process. An individual designated as the author should observe the code inspection process silently and should intervene only when necessary. The author should understand the errors detected in the code. A section of code from a computer language is translated to a common language (English) by the reader. After a general inspection meeting, the inspectors meet again to discuss the defects they had identified and to work with the moderator to prepare a written report that identifies the rework necessary to address the problems. The programmer then makes the modifications and the moderator verifies whether the changes are being made correctly or not. Re-inspection may be conducted depending on the scope and magnitude of changes and on how critical the software is to find any remaining bugs. As the main aim of review is to detect defects in code, one evident coding defect is that the code fails to implement the design. There can be a difference between the function implemented by a module and the function actually specified. And also there can be difference between the interface of modules and the interface specified in the design. Also the input–output format assumed by a module may be inconsistent with the format specified in the design. We can classify other code defects into logic and control operations and computations, and data operations and computations. Infinite loops, incorrect predicate, improper nesting of loops and branches and others are few logic and control defects. Incorrect access of array components, improper initialisation, misuse of variables and others are few data defects. Code inspections are very effective in finding bugs in a software product, particularly in design documents. As organisations and product

Sikkim Manipal University B1965 Page No. 272 Software Engineering Unit 13 development teams have begun to realise the benefits of code inspection, it is now becoming popular. Let us see the steps followed to conduct code inspection. 1. Planning – This is the first step of code inspection. The author submits the findings to the moderator after compilation and after ascertaining the absence of errors and warning messages in the code. Moderator then forms an inspection team. Moderator gives out the listings and other documents such as design documents to each team member after the inspection team is formed. Inspection meetings are planned by the moderator and he regularly co-ordinates with the team members. 2. Overview – This is the second step in the process of code inspection. This step is required when the inspection team members do not know the functioning of the project. The author provides details to enable the team members to understand the code. 3. Preparation – This is the third step in code inspection. The code and its related materials are examined by each inspection team member individually. To make sure that each problem area is verified, the members use a checklist. All the members maintain this checklist, where all the problematic areas are stated. 4. Inspection meeting – This is the fourth step in code inspection. This is done to review the software code. The inspection meeting is conducted with all the team members. The code under review is discussed with inspection team members by the moderator. We can use two checklists for recording the result of code inspection, which are code inspection checklist and inspection error checklist. The summary of all different kinds of errors seen in the software code is maintained in code inspection checklist. This is used to understand the effectiveness of the inspection process. The aspect of each error that needs rework is maintained in the inspection error checklist (i.e. the details of errors that necessitate the entire coding process to be repeated). 5. Rework – This is the fifth step in code inspection process. In this step, all the defects are corrected efficiently by the author. 6. Follow-up – This is the sixth step in code inspection process. In this step, the moderator or the entire team checks whether all the

Sikkim Manipal University B1965 Page No. 273 Software Engineering Unit 13

corrections are effective and that no other errors have been introduced into the software. In the inspection checklist, we categorise all the errors into major and minor errors. If an error results in problems and the user comes to know of it later, then the error is said to be major. Spelling errors and non-conformity with standards are minor errors. The list of errors categorised helps us to deliver the software to the user without missing anything and it helps us to review all errors present in the code whenever we have less time to review and we need to prioritize. At the end of the code inspection meeting, decisions are taken on whether the code should be accepted in the present form or sent back for rework. The author makes all corrections, if the code requires rework and later the code is compiled. The code is presented back to the moderator after the reworked code appears to be error free. The reworked code is again checked by the moderator. The inspection formally ends when the moderator agrees to the sanctity of code without any conflicts. Let us have a look at some points which we can include in the code review checklist:  Are all loops terminated?  Are divisors tested for zero wherever applied?  Are imported data tested for validity?  Wherever required are the pointers set to NULL?  Are the branch conditions right?  Are actual and formal parameters matching?  Are initialisations of indexes right?  Is it possible to place the statements present within the loop outside?

Self-Assessment Questions 13. The goal of ______is to detect errors caused due to mistake and incorrect programming. 14. During code inspection, the ______translates or interprets the operation of the code. 15. The first step of code inspection is ______.

Sikkim Manipal University B1965 Page No. 274 Software Engineering Unit 13

Activity 3: Form a team in your organisation, categorise them as inspectors, moderators, authors and recorders. Conduct a meeting to discuss about issues related to software product available at your organisation. Prepare a checklist for the same. (Hint: Steps of code inspection, Checklist.)

13.7 Summary Let us recapitulate the important concepts discussed in this unit:  Software verification can be conducted by various techniques such as code reading, static analysis, symbolic execution, proving correctness and code inspection.  Code reading is a software verification technique that helps us to read the code efficiently by inspecting the code and removing the errors from it.  Static analysis technique helps us to analyse the code without executing it.  The three types of static analysis are code-based testing tools, specialised testing languages and requirements-based testing tools.  Symbolic execution is a software verification technique that helps to analyse the code by replacing real values with symbolic values.  Proving correctness is a software verification technique which is used for proving the code correct.  Code inspection is a software verification method that helps us to formally verify the code to detect errors caused due to wrong programming methods.  Code inspection is conducted in a series of steps, namely, planning, overview, preparation, inspection meeting, rework and follow-up.  All the software verification techniques help us to verify the program code effectively.

Sikkim Manipal University B1965 Page No. 275 Software Engineering Unit 13

13.8 Glossary Abstraction of module: It is the specification of problem that has been extracted from the module which is essential and relevant information. Peer reviews: It is a face-to-face discussion held between the programmer and the reviewer. Walk-throughs: This is an informal code analysis method. In this method, all syntax errors are eliminated after a module is coded and compiled.

13.9 Terminal Questions 1. What is code reading? 2. Explain static analysis. 3. Describe symbolic execution. 4. What is proving correctness? 5. Describe code inspection.

13.10 Answers Self-Assessment Questions 1. Code reading 2. False 3. Errors 4. Static analysis 5. Local programming standards 6. Requirements-based testing 7. Symbolic execution 8. Program counter 9. Hand-execution 10. Proving correctness of a program 11. True 12. Theoretical 13. Code inspection 14. Reader 15. Planning

Sikkim Manipal University B1965 Page No. 276 Software Engineering Unit 13

Terminal Questions 1. (Refer to Section 13.2 for further information.) 2. (Refer to Section 13.3 for further information.) 3. (Refer to Section 13.4 for further information.) 4. (Refer to Section 13.5 for further information.) 5. (Refer to Section 13.6 for further information.)

13.11 Case Study An Effective Tool to Identify the Software Bugs ABC Company is known for developing complex software used in advanced communications technologies. The program codes are written in C, C++, Java and SDL, code length being 2 to 2.5 million lines long. The ABC Company wanted the best testing solution to remove bugs early in the development life cycle of software. Challenge: ABC Company wanted advanced testing solutions to detect and eliminate software bugs from application code with complex software being developed. The manager had to find appropriate tools that would assist with early identification and removal of software bugs from code. This company was struggling with usual quality issues such as writing bug-free code that was easy to understand, maintain and extend. The manager looked for tools that would help them to find defects early, not only source code defects but also architectural problems, buffer overflows and security problems. There was a requirement in this company to increase the quality of software that the organisation company was developing, and increase developer’s productivity by freeing them from expensive code reviews and inspections. Solution: ABC Company checked static analysis tool that found bugs within a very short period of time. After analysing the results in detail, the company concluded that the static analysis tool found more bugs than other tools. The tool had good user interface and was completely featured tool than the others. ABC Company’s software development team was very impressed with the tool for a particular issue. The team had been struggling with a bug in the

Sikkim Manipal University B1965 Page No. 277 Software Engineering Unit 13 application that led to an infinite loop occurring under random, special conditions. Several man-weeks of development effort had already been allocated in order to track the problem down. Discussion Questions: 1. What were the issues faced by the ABC Company? 2. Why did ABC Company go for static analysis tool?

References/E-References: References:  Jalote, P. An Integrated Approach to Software Engineering.  Laski, J., & Stanley, W. Software Verification and Analysis.

E-References:  http://openseminar.org/se/modules/184/index/screen.do (Retrieved on 18th May 2012)

Sikkim Manipal University B1965 Page No. 278 Software Engineering Unit 14

Unit 14 Capability Maturity Model for Software Structure: 14.1 Introduction Objectives 14.2 Five Maturity Levels Components of CMM 14.3 Key Process Areas (KPAs) Common features 14.4 ISO 9000 Series of Standards for Quality Management Systems 14.5 Mapping ISO 9001 to the CMM 14.6 Summary 14.7 Glossary 14.8 Terminal Questions 14.9 Answers 14.10 Case Study

14.1 Introduction In the previous unit, we studied about software verification, wherein we studied about code reading, static analysis, symbolic execution, proving correctness of the software and the inspection or review of code for our software under development. In this unit, we will study about Capability Maturity Model (CMM), which is related to the area of software development. This model can be applied as a “generally applicable model” to assist in gaining knowledge about the process capability maturity of organisations in areas such as software engineering, system engineering, project management, software maintenance, risk management, system acquisition, information technology (IT) and personnel management. We will also study about the levels of CMM. This unit will also familiarise us with the key process areas of CMM, wherein we will discuss about the common features of CMM. We will have a brief discussion on the ISO 9000 series of standards for quality management. We will also analyse how to map ISO 9001 to CMM. This unit will enable us to use CMM for our software.

Sikkim Manipal University B1965 Page No. 279 Software Engineering Unit 14

Objectives: After studying this unit, you should be able to:  elaborate the levels of CMM for software  enlist the key process areas of CMM  briefly describe the common features of CMM

14.2 Five Maturity Levels In this section, we will study about the five maturity levels of CMM. But to understand it in a better way, we will first understand what CMM is. CMM can be defined as a unique model of organisational development and change. It offers very effective guidance to software organisations for creating programs for process improvement. The CMM comprises five maturity levels. We can characterise each maturity level by the execution of several clusters of practices (i.e. process areas) that add to the development capability attained at that level. According to the SEI (Software Engineering Institute, Carnegie-Mellon University, USA), “Predictability, effectiveness, and control of an organisation’s software processes are believed to improve as the organisation moves up these five levels. While not rigorous, the empirical evidence to date supports this belief.” Let us briefly discuss about the five levels in CMM, as given in Figure 14.1.

Fig. 14.1: Levels of CMM

Sikkim Manipal University B1965 Page No. 280 Software Engineering Unit 14

Level 1: Initial – It is the starting point for using a new process. At this level, the company has no standard process for software development. It is undocumented and in a state of active change, which tends to be driven in an unplanned, uncontrolled and reactive manner by users or events. Growth processes are rarely defined, and sound practices are often neglected to meet unreasonable schedules. In this level, organisations lack the capability to meet commitments consistently. No company would like to be assessed at this level and hence, companies wait for a few years for their processes to stabilise before they attempt to get the CMM certification. Level 2: Repeatable – As per this second level of CMM, the organisation creates policies based on software engineering techniques and successful prior projects. In this, we establish the basic project management processes, which help in tracking cost, schedule and functionality. Note that there may not be any similarity between the processes or repetition for all projects in the organisation. Here, the groups can deal with similar projects based on their experiences. Thus, we can say that Level 2 attempts to develop the capabilities of project managers for the following: o Planning attainable assurance o Creating control of requirement baselines This is also not a preferred level of certification for software companies. Level 3: Defined – The basis for Level 3 is the organisation’s set of standard processes, which are identified and improved over time. These standard processes are used to ascertain reliability across the organisation. You must note that the projects create their distinct processes by the collection of standard processes according to guidelines of the organisation. The management of the organisation creates the objectives of the process, and on the basis of the organisation’s set of standard processes, ensures that these objectives are properly addressed. Only relatively newer companies will announce to the world that they have been certified at Level 3. Older, established companies would not prefer to be in this level of certification. Level 4: Quantitatively managed – According to this level, the tasks of monitoring and controlling an organisation's processes are performed by the organisation itself through data collection and analysis. Accurate measures in management can efficiently control the software development attempt. At

Sikkim Manipal University B1965 Page No. 281 Software Engineering Unit 14 this level, a goal related to the quantitative quality is set by the organisation, not only for software process but also for software maintenance. Sub- processes that considerably add to the overall process performance are selected. We manage these selected sub-processes with the help of statistical techniques and some other quantitative techniques. Although software companies aspire to reach Level 5, certification at Level 4 is also a matter of pride. Level 5: Optimising – This level of CMM states that process management comprises planned process optimisation or process improvement. This level focuses on repeatedly improving the process performance through both incremental and inventive technological improvements. Also, we identify the quantitative process – improvement goals for the organisation, revise them frequently for reflecting the different business goals and use them as criteria in managing process improvement. We measure and assess the effects of organised process improvements against the quantitative process – improvement goals. The processes that are defined and the organisation’s set of measured processes as well are targets of the improvement activities that are assessable. Process improvements address common causes of process difference and take the organisation’s processes to the next level. They are identified, evaluated and deployed. Optimisation of the processes that are quick, compliant and innovative is dependent on the involvement of an authorised workforce, which is aligned with the business values and goals of the organisation. The ability of the organisation to quickly respond to changes and prospects is enhanced by finding ways to hone and share learning. As mentioned earlier, software companies endeavour to reach Level 5 as it represents the highest certificate of process quality. The biggest benefit a company draws from this Level 5 certification is that it can compete at par in the global marketplace with all other established giants. It is interesting to note that a majority of CMM Level 5 companies have their operations in India. 14.2.1 Components of CMM We can use a maturity model as a standard for assessment and as an aid to analyse the maturity software process. For example, for relative assessment of different organisations, where there is some commonality, the model can

Sikkim Manipal University B1965 Page No. 282 Software Engineering Unit 14 be utilised as a base for comparison. Like other models, CMM also has some components, which include the following. Maturity levels – We can define maturity levels as well-defined levels, which help in achieving a mature software process.1 The five maturity levels provide the top-level structure of the CMM. In this structure, the uppermost (5th) level is a theoretical ideal state where the processes are methodically managed by an arrangement of process optimisation and non-stop process improvement. Process capability – It refers to a variety of expected results that can be attained by implementing software process. It provides a means to foresee the possible results to be expected from the next software project that the organisation undertakes. Key Process Areas (KPAs) – This is an important component of CMM. We can define KPA as a cluster of related activities that, when performed collectively, aids to attain a set of goals considered to establish process capability at the maturity level. Goals – This component of CMM recapitulates the key practices of a KPA and determines whether an organisation or project has effectively implemented it or not. The goal signifies the scope and purpose of all the KPAs. Common features – “Common features” of CMM are aspects which signify whether the implementation of a KPA is capable, and can be done repetitively while being sustainable. We can divide it into the following five features: o Commitment to perform o Ability to perform o Activities performed

1 Maturity software process: CMM delineates the characteristics of a mature, capable software process. The progression from an immature, unrepeatable software process to a mature, well-managed software process is also described in terms of maturity levels in the model. Sikkim Manipal University B1965 Page No. 283 Software Engineering Unit 14 o Measurement and analysis o Verifying implementation Self-Assessment Questions 1. CMM is a unique model of ______and change. 2. Software development successes are repeatable. It is significant to create a steady environment that aids the repetition of successful practices. (True/False) 3. At maturity Level 4, developments are concerned with addressing special causes of ______and providing statistical predictability of the results. 4. “Common features” of CMM are aspects that indicate whether the implementation of a key process area is effective, repeatable and lasting. (True/False) 5. At maturity Level 5, processes are concerned with addressing frequent causes of ______and altering the process.

Activity 1: Assume that you are given a project on quality management implementing CMM in it. Prepare a list of the levels of CMM. (Hint: The five maturity levels. Refer section no. 14.2)

14.3 Key Process Areas (KPAs) The previous section familiarised us with the CMM levels and its components. This section will familiarise us with one of the important components of CMM, namely, KPAs. In CMM, the KPAs determine a collection of relevant actions which when executed collectively accomplishes a set of goals acknowledged as important for promoting the capability of the process. It contains goals that must be achieved in order to improve software key practices. After defining the KPA, you have to set up performance goals or objectives for each KPA. CMM in general allocates two to four goals per KPA. As every level of CMM has its own KPAs, the challenge is to accumulate two to four performance goals of each KPA in your current level. Thus, it is essential to have well-created KPAs in the current level before you get to

Sikkim Manipal University B1965 Page No. 284 Software Engineering Unit 14 the next level. You need to think in terms of the management for the defined results. Let us take a look at the levels of CMM and their relative KPAs. This is shown in Figure 14.2. As you can see in Figure 14.2, every level except Level 1 has some KPAs, which signifies the areas requiring improvement for their respective software processes. Since KPAs at Level 1 are not discrete, getting to Level 2 is often an obstacle in moving through CMM. To get to Level 2, an organisation needs to have procedures that begin to experience repeatable success and similarly, you begin to eliminate your failures.

Fig. 14.2: Key Process Areas

Sikkim Manipal University B1965 Page No. 285 Software Engineering Unit 14

14.3.1 Common features We will now have a brief discussion on the “common features” component of CMM. As discussed earlier, common features can be defined as aspects that determine whether the execution and institutionalisation of a KPA is capable, and whether it can be done repetitively while being sustainable. We organise every KPA into five sections. These sections are called “common features” of CMM. Let us have a quick overview of these five features:  Performance commitment – It (also known as “commitment to perform”) details the actions that an organisation must perform for ensuring that the process is created, and will continue. It comprises practices on policy and leadership.  Performance ability – It (also called “ability to perform”) details the requirement that must exist in the project or organisation to execute the software process proficiently. It comprises practices on resources, organisational structure, training and tools.  Performed activities – It (also called “activities performed”) details the roles and events necessary to execute a KPA. It comprises practices on plans, procedures, work performed, tracking and corrective action.  Measurement and analysis – It details the need to measure the processes and examine the measurements.  Verification of implementation – It (also called “verifying implementation”) explains the steps to ensure that the activities are performed in line with the process that has been established. It comprises preparation on re-assessment of management and audits. Self-Assessment Questions 6. Performance ability describes the requirement that must exist in the project or organisation, to execute the software process proficiently. (True/False) 7. Segmented consumer markets are easier for companies and marketers to target with advertising and marketing strategies. (True/False) 8. Since KPAs at Level 1 are not discrete, getting to ______is often an obstacle in moving through CMM.

Sikkim Manipal University B1965 Page No. 286 Software Engineering Unit 14

Activity 2: Imagine that you have opened a new outlet of fast-food restaurant. List the steps you would take to implement the key practices that explain the infrastructure and performances of your restaurant. (Hint: Key Process Areas)

14.4 ISO 9000 Series of Standards for Quality Management Systems In the previous section, we studied about the two important components of CMM, namely, KPAs and common features. In this section, we will study about the ISO 9000 series of standards for quality management systems. The basis of Quality System Requirements (QS) 9000 is the 1994 edition of ISO 9001, but it comprises added needs that are specific to the automotive industry. The ISO community of accreditation bodies and registrars acknowledges these added needs as automotive “interpretations”. QS-9000 is related to suppliers of the following:  Production materials  Production and service parts  Heat treating  Painting and plating and other finishing services Many truck companies have accepted QS-9000 and are signatories to the document. Some other companies in the automotive industry are also accepting QS-9000 as their supplier quality requirement, and non- automotive industries are watching the implementation of QS-9000. They are acknowledging its use as a model for evolving ISO 9001 on the basis of requirements for their industries. For example, it is the common supplier quality standard for DaimlerChrysler Corporation, Ford Motor Company and General Motors Corporation.2

2 manage2020.com/down/qs9000.doc Sikkim Manipal University B1965 Page No. 287 Software Engineering Unit 14

Standards are essential for ensuring the effective operation and control of processes, because they define the criteria required to judge the acceptability of the process capability and product quality. The standard propels the organisation for putting a quality management system into action in accordance with the requisites of ISO 9001. Thus, implementation applies to the use and operation of the management system following its construction and integration. Also, it is relevant to the routine operation of a system that is already created, documented and is in perpetual operation. The following are the quality concepts addressed by these standards:  An organisation should bring about and maintain the quality of the product or service created, so as to meet the stated or implied needs of the purchaser.  An organisation should show commitment to its own management that the expected quality is being achieved and sustained.  An organisation should ensure to the purchaser that the planned quality is being, or will be, achieved in the product or service given. The ISO 9000 standard requires the organisation to make sure that the mandatory information for assisting the operation and monitoring of the identified processes should be available if required. The standard requires very few (seven) procedures. These specific, documented procedures are required for the following:  Document control – It is an intrinsic part of every work process because the inputs to every process pass through a number of stages, each adding value to result in the success of defined objectives.  Control of records – It is a basic part of every work process which is similar to document control. These include preparation, storage, access, maintenance and disposal tasks.  Conducting audits – It is an activity with a defined objective. Without the provision of able personnel and an appropriate environment, audits will not achieve their goals no matter how many times the procedure is implemented.  Non-conformity control – It is a basic element of certain work processes. The order of tasks is not in the form of a continuing series.

Sikkim Manipal University B1965 Page No. 288 Software Engineering Unit 14

The order may be determination, documentation, separation, review, remedial action and disposal.  Corrective action – It forms a part of every process rather than being a separate process. It is an action in which the methods are diverse but the outcomes are the same, that is, non-conformity is prohibited from recurring. Many issues are thwarted from recurring by not implementing a process, albeit by the designer, the producer, the supplier or a manager. They identify the crises they had faced the previous time and do it differently the next time, that is, they learn from their mistakes.  Preventive action – This action is similar to corrective actions. However, preventive actions are implemented. Preventive actions are built into these processes, and similar to corrective action, they are part of every process design. ISO 9001 provides the organisation with guidelines for it to decide what it needs for the effective operation and control of its processes.

14.5 Mapping ISO 9001 to the CMM After studying about the ISO 9000 Series of Standards for Quality Management Systems, we will now study about the mapping of ISO 9001 to CMM. There are similar concerns for CMM and ISO 9001 and they are inter- related. It consists of software development and maintenance, which categorises the minimum requirements for a quality system. CMM caters to software, while ISO 9001 caters to hardware, software, processed materials and services. ISO 9001 has 20 clauses which are compared with the practises in CMM.3 Let us now learn about them.

3 The comparison is based on an analysis of ISO 9001, ISO 9000-3, TickI and the TickIT training materials [Lloyd’s 94]. Sikkim Manipal University B1965 Page No. 289 Software Engineering Unit 14

Clause 1: Management Responsibility o In ISO 9001 – It requires the organisation to define, document, understand, implement and maintain quality. The responsibilities of all personnel should be specific and monitored. The employees should be trained and funded. An elected manager certifies that the quality program is executed and maintained. o In CMM – It addresses management responsibility for quality policy and verification activities. These are chiefly dealt with in Software Quality Assurance, both Software Project Planning and Software Project Tracking, and include activities that identify responsibilities for performing all project roles. This includes the following: . Recognising accountability for implementing all project roles . Establishing a trained software quality assurance group . Assigning senior management Clause 2: Quality System o In ISO 9001 – It requires an organisation to document quality systems, including procedures and instructions. ISO 9000-34 characterises this quality system as an integrated process throughout the entire life cycle. o In CMM – It deals with quality system activities. The methods that would be implemented are spread throughout the KPAs in various “performed activities.” The explicit events and principles that a software project would use are specified in the software development plan described in Software Project Planning. Software Product Engineering involves defined tasks, and integrated and reliable performance, which syncs directly with the ISO 9000-3 guidance for interpreting this clause. ISO 9001 involves the supplier’s quality system; it does not include the connection between organisational support and project implementation.

4 ISO 9000-3 provides guidelines for applying ISO 9001 to the development, supply, and maintenance of software. Sikkim Manipal University B1965 Page No. 290 Software Engineering Unit 14

CMM includes all these things. ISO 9000-3, on the other hand, has two sections on quality planning. Clause 3: Contract Review o In ISO 9001 – It requires organisations to review contract to determine whether the requirements are sufficiently defined, agree with the bid and can be implemented. o In CMM – The organisation must review and document the customer requirement allocated by the management. It evaluates the attainment of software through subcontracting as described in Software Subcontract Management. Contracts may be with an external customer or with a subcontractor. Since the CMM is restricted to software viewpoint, customer requirements are beyond the scope of the requirements. The software organisation (supplier) ensures that the system requirements assigned to software are standardised and reassessed, and that missing or uncertain needs are clarified. Since the CMM is linked to the software viewpoint, the customer requirements are beyond the scope of this KPA. Software Project Planning explains the progress of a proposal, a report of work and a software development plan, which are reassessed by the software engineering group and by senior management, in establishing external (contractual) commitments. Clause 4: Design Control o In ISO 9001 – It requires an organisation to establish procedures to control and verify designs, which include the following: . Planning . Designing activities . Identifying inputs and outputs . Verifying the design . Controlling design changes ISO 9000-3 declares that the supplier must bring out re-evaluation to make sure that the requirements are met and design methods are correctly carried out. o In CMM – It defines the life cycle activities of requirements analysis, design, code and test that are described in Software Product

Sikkim Manipal University B1965 Page No. 291 Software Engineering Unit 14

Engineering. Planning these actions is explained in Software Project Planning. Software Project Tracking and Oversight explains management of these life cycle activities, and Software Configuration Management describes configuration management of software work products generated by these activities. Peer review is also included in it. These reviews act as the KPA which supports the process throughout the life cycle, from requirements analysis through testing. Clause 5: Document Control o In ISO 9001 – It requires an organisation to distribute and modify documents and data. o In CMM – It describes the configuration management practices that are documented and controlled. The in-depth actions, standards and other documents are scattered all over the KPAs. Clause 6: Purchasing o In ISO 9001 – It needs organisations to guarantee that the purchased products are in line with their specified requirements. This includes the estimation of probable subcontractors and authentication of purchased products. o In CMM – It is explained in Software Subcontract Management. Assessment of subcontractors is in Clause 2 (Quality System), while acceptance testing of subcontracted software clause is explained in Clause 12 (Inspection and Test Status). Clause 7: Purchaser-Supplied Product o In ISO 9001 – It requires that the purchaser-supplied material be verified and maintained. o In CMM – It describes the use of identifying off-the-shelf or reusable software as part of development. Integration of off-the-shelf and reusable software is one of the areas where the CMM is weak. This clause, especially as expanded in ISO 9000-3, cannot be considered adequately covered by the CMM. Clause 8: Product Identification and Traceability o In ISO 9001 – It requires an organisation to identify and trace a product during all stages of production, delivery and installation.

Sikkim Manipal University B1965 Page No. 292 Software Engineering Unit 14 o In CMM – It includes the clause chiefly at Level 2 in the perspective of configuration management, but it states the need for reliability and traceability between software work products at Level 3. Clause 9: Inspection and Testing o In ISO 9001 – It requires that the materials be inspected or verified before use and that in-process inspection and testing be performed. Final inspection and testing are performed prior to release of finished product. Records of inspection and test are kept. o In CMM – It explains testing of software product engineering. In-process assessment in the software sense is addressed in peer reviews.

Clause 10: Inspection, Measuring and Test Equipment o In ISO 9001 – It requires the organisation to assess the equipment used to demonstrate conformance be controlled, regulated and maintained. When test hardware or software is used, it is checked before use and rechecked at prescribed intervals. The organisation must also perform final inspection and testing before the finished product is released and should also keep the inspection and test records. o In CMM – It deals with issues surrounding the inspection of incoming material. This has been explained in Clause 7. Clause 11: Process Control o In ISO 9001 – It requires an organisation to describe and hone its manufacturing processes. This includes implementation of production under controlled conditions according to documented instructions. If organisations cannot assess the results of a procedure after the fact, it must constantly monitor and control the development. o In CMM – The specific procedures and standards used in the software- production process are specified in the software development plan. The definition and integration of software-production processes are described at Level 2 and the tools to support these processes are described at Level 3, and Level 4 addresses the quantitative aspect of control, exemplified by statistical process control. However, an organisation typically would not have to demonstrate this level of control to satisfy this clause.

Sikkim Manipal University B1965 Page No. 293 Software Engineering Unit 14

Clause 12: Inspection and Test Status o In ISO 9001 – It requires an organisation to maintain the status of inspections and tests, for objects, as they shift during various processing steps. o In CMM – It tackles practices on problem reporting and arrangement status at Level 2 and by testing practices at Level 3.

Clause 13: Control of Non-Confirming Product o In ISO 9001 – It requires an organisation to control a non-conforming product that does not satisfy particular requirements and to prevent unplanned use or installation. ISO 9000-3 maps this concept to clauses on design and implementation and configuration management. o In CMM – It does not specifically address non-conforming products. In ISO 9000-3, the control issue essentially disappears among a number of related processes spanning the entire software life cycle.

Clause 14: Correction and Prevention5 o In ISO 9001 – It requires an organisation to recognise the causes of a non-conforming product. Corrective action is aligned towards the removal of the causes of definite non-conformities. Preventive action is concentrated towards the removal of the causes of potential non- conformities. o In CMM – Corrective action addresses non-compliance that is recognised in an audit, be it external or internal. This explanation compares to the CMM’s Level 2 KPA, Software Quality Assurance. Clause 15: Handling, Storage, Packaging, Prevention and Delivery o In ISO 9001 – It requires organisations to create and sustain procedures for handling, storage, packaging and delivery.

5 ISO 9001-3 quotes this clause verbatim with no elaboration. Sikkim Manipal University B1965 Page No. 294 Software Engineering Unit 14 o In CMM – It does not cover replication, delivery and installation. It addresses the creation and release of software products at Level 2, and acceptance testing at Level 3. Clause 16: Control of Quality Records o In ISO 9001 – It requires an organisation to collect and maintain quality records. o In CMM – It includes the practices that define the preservation of quality records. These records are circulated throughout the KPAs as part of the “activities performed” common feature. Clause 17: Internal Quality Audits o In ISO 9001 – It requires an organisation to plan and perform audits. The results of audits are passed onto the management and any deficiencies that maybe found are corrected. o In CMM – It describes the auditing process at Level 2. Auditing practices help the organisations with the specified standards and procedures. Clause 18: Training o In ISO 9001 – It requires an organisation to recognise training needs, provide training and maintain training records. o In CMM – It identifies explicit training needs in the training and direction practices in the “ability to perform” common feature. It explains the common training infrastructure, including maintaining training records, at Level 3. Clause 19: Servicing o In ISO 9001 – It requires an organisation to execute servicing activities even when such activities are part of a specified requirement. o In CMM – It is implemented in software development and maintenance environments. The methods in CMM do not directly address the unique features that symbolise the maintenance environment. Organisations must precisely understand these practices in the development or maintenance situation.

Sikkim Manipal University B1965 Page No. 295 Software Engineering Unit 14

Clause 20: Statistical Techniques o In ISO 9001 – It requires that organisations must identify sufficient statistical techniques and use them to verify the suitability of process capability and product characteristics. o In CMM – In CMM, product measurement is included into a variety of practices within the “performed activities” common feature. Process measurement is explained as a division of the “measurement and analysis” common feature. Few auditors ask for an organisation-level historical database and the use of simple statistical control charts. Self-Assessment Questions 9. In______, a designated manager ensures that the quality program is implemented and maintained. 10. Process measurement is described as part of the “measurement and analysis” common feature. (True/False) 11. Inspection and Testing requires that the materials be ______or verified before use and that in-process inspection and testing be performed CMM.

Activity 3: Suppose that you are working as a “Quality Manager” in an organisation and you are given the responsibility of creating the strategic planning team to monitor the performance of CMM and ISO 9001 in the organisation. Create a PowerPoint presentation based on mapping ISO to CMM.

14.6 Summary Let us recapitulate the important concepts discussed in this unit:  Many software organisations have poorly designed processes, which are operated at high costs and often result in late delivery of projects. A maturity model helps an organisation to develop and support its processes. It also helps an organisation to accomplish its work with high quality and low cost and to control complexity of today’s huge systems.  There are five maturity levels of CMM, namely, initial level, repeatable level, defined level, managed level and optimising level. We also

Sikkim Manipal University B1965 Page No. 296 Software Engineering Unit 14

discussed that each KPA is organised into five sections known as common features.  CMM focuses strictly on software, while ISO 9001 includes hardware, software, processed materials and services.  ISO 9001 has 20 clauses which can be compared against the practices in CMM.

14.7 Glossary Audit: It is an official examination and verification of an organisation’s performance. Benchmarking: It refers to a standard by which something can be measured or judged. Business process: It is a collection of related, structured activities or tasks that produce a specific service or product. Maturity model: It is a method used to expand and improve an organisation’s software development process.

14.8 Terminal Questions 1. Explain the five-level maturity model. 2. Explain the components of CMM. 3. Explain the common features included in KPA. 4. Explain the procedures involved in ISO 9000 series.

14.9 Answers Self-Assessment Questions 1. Organisational development 2. True 3. Process variation 4. True 5. Process differences 6. True 7. True 8. Level 2 9. Management responsibility 10. True 11. Inspected

Sikkim Manipal University B1965 Page No. 297 Software Engineering Unit 14

Terminal Questions 1. (Refer to Section 14.2 for further information.) 2. (Refer to Section 14.2 for further information.) 3. (Refer to Section 14.3 for further information.) 4. (Refer to Section 14.4 for further information.)

14.10 Case Study Success with CMM – 9001 Company: ABC Software Division, a Fortune 100 information services provider, delivers products and services like semiconductor system design, microcomputer systems, software development, network solutions, consulting and systems integration. It leverages its process expertise to conduct detailed research on the implementation of CMM Level 5, and on the use of process automation tools for software process improvement in the integrated environment. Challenge: The client’s objective was as follows: o Analyse ABC Software Division’s experience in the execution of CMM Level 3 to Level 5, and implement it in their organisation. o Study the employment of Software Process Improvement (SPI) tools for enhanced productivity, better data analysis and corrective action. Solution: This research assignment cut across functions to involve professionals from the quality, delivery and support groups at ABC Software Division. The research findings were documented to serve as project deliverables, produced in both English and Japanese. o Organisation’s processes for implementation of CMM Levels 3, 4 and 5, as also the best practices adopted. This included the following: definition of all key process area (KPAs); relationship between various CMM levels; goals, benefits and methodology for defining/refining KPAs. o Road map for transition from ISO 9001 framework to CMM Level 5. o Organisation structure for CMM implementation, audit process, SQA facilitation/review process and metrics.

Sikkim Manipal University B1965 Page No. 298 Software Engineering Unit 14 o SPI tools that could be developed internally or purchased off-the-shelf to fulfil the requirements of CMM. This included the methodology for tool selection and deployment, and a study of features of popular commercial off-the-shelf tools. Benefits: A practitioner’s approach to process improvement presented with a research focus complemented well with quality journey of ABC Software Division. Clarity in the process integration exercise in respect of integration of various quality frameworks and adoption of process automation. Significant cost-benefits accrued from the offshore execution of the research project. Discussion Questions: 1. What were the challenges faced by ABC Software Division? 2. What were the steps taken by the company to overcome it?

References/E-References  Burwick, Diane M. How to Implement the CMM, .Bps Pub; 2 edition (March 20, 2001)  Paulk, Mark C., Weber, Charles V., Curtis, Bill, & Chrissis, Mary Beth. The Capability Maturity Model: Guidelines for Improving the Software Process, Pearson Education india, (2007)

Sikkim Manipal University B1965 Page No. 299 Software Engineering Unit 15

Unit 15 CMM-Based Process Improvement

Structure: 15.1 Introduction Objectives 15.2 Management Role Management sponsorship Commitments and management by fact 15.3 Process Focus 15.4 Useful Processes 15.5 Training 15.6 Risk Management 15.7 Customer–Supplier Relationship 15.8 Peer Reviews Types of peer reviews Peer-review process 15.9 Summary 15.10 Glossary 15.11 Terminal Questions 15.12 Answers 15.13 Case Study

15.1 Introduction In the previous unit, we discussed about the “Capability Maturity Model (CMM) for Software,” which provides software organisations with assistance on how to achieve control of their processes for developing and maintaining software and how to advance towards a culture of software engineering and management excellence. In this unit, we will discuss about the CMM-based process improvement. We will discuss about management sponsorship, which plays an important role in such processes. We will also have a brief discussion about commitments and management by fact. We will analyse the focus of CMM-based process, which will also help us in analysing the objectives of CMM-based process. We will also study about CMM-based useful processes in this unit including the role of training in CMM-based processes. We will also study about the role risk management plays in CMM-based processes. We will have a

Sikkim Manipal University B1965 Page No. 300 Software Engineering Unit 15 discussion on the customer–supplier relationships in CMM-based processes, wherein we will learn about the peer reviews, their types and process. This unit will enable us to appreciate the role of CMM-based processes. Objectives: After reading this unit, you should be able to:  describe management sponsorship  briefly describe the concepts of commitments and management by fact  elaborate CMM-based process training and useful processes  point out the customer–supplier relationship in CMM-based processes

15.2 Management Role We know that management plays an important role in all fields. So, we will now discuss about the management role in CMM-based process improvement by looking into two aspects, namely, management sponsorship and commitments and management by fact. Let us first discuss about management sponsorship and how it contributes to CMM-based process improvement. 15.2.1 Management sponsorship It is important to understand that obtaining senior management sponsorship is a crucial component that is required in building the organisational capability. This is because, you, as an individual, can practice professionalism and discipline within your area of control. However, when an organisation as a whole is to change its performance, then its senior management needs to actively support the change. Effective sponsorship can be achieved only when there is significant dissatisfaction with the current status. Some of the activities of sponsorship involve the setting up of policies and providing resources for the process work. However, the most important factor, according to the senior management involved in the strategic importance of process improvement, is demonstration of support which is to be achieved by paying attention. Let us look into how paying attention improves the process. People tend to increase their efforts which in turn improve the productivity and quality of work.

Sikkim Manipal University B1965 Page No. 301 Software Engineering Unit 15

If process improvement is the true priority, then the management will monitor it closely. It is done by setting aggressive improvement goals. This, however, requires a long-term commitment to continual process improvement. CMM-based improvement is most effective when carried out in a systematic approach. It is mandatory for the individuals involved in the same to possess good interpersonal skills.

15.2.2 Commitments and management by fact After discussing about management sponsorship, we will now discuss about commitments and management by fact. “Management by fact” is based on a measurement foundation for most organisations. To make data analysis useful, you need to first understand what the data mean. Only then is it possible to analyse the same meaningfully. People have a tendency to focus their efforts where the management pays attention. If management pays attention only to schedule, then the quality is likely to suffer. Thus, it is the responsibility of the management to ensure that adequate attention is noticeably paid to all the critical aspects of the project. This includes aspects that are difficult to measure and not just those that are easy to measure and track. You need to design an internal commitment process based on what you know you can do. It is important for the management to seek worker feedback when establishing commitments. This is because, once the workers agree to a set of commitments, even if they are aggressive, they develop a feeling of personal commitment towards the task. This not just ensures the timely completion of the task but also instils a sense of responsibility towards the commitment in the worker.

Self-Assessment Questions 1. Effective sponsorship can be achieved only when there is significant dissatisfaction with the status. (True/False) 2. CMM-based improvement is most effective when carried out in a ______approach. 3. “Management by fact” is based on a ______foundation for most organisations.

Sikkim Manipal University B1965 Page No. 302 Software Engineering Unit 15

4. If management pays attention only to schedule, then nothing is likely to suffer. (True/False)

15.3 Process Focus In the previous section, we studied about the management role and understood it by looking into two aspects, that is, management sponsorship and commitments and management by fact. Let us look into the CMM- based process focus. The first step involved in the CMM-based process focus is the formation of a Software Engineering Process Group (SEPG). This is done in order to harmonise process definition, improvement and deployment activities. The SEPG should be formed early so as to hire staff for the same with both managerial and technical skills. It is crucial that these individuals possess good interpersonal skills. This is because the success of SEPG is dependent on their ability to communicate, teach, negotiate and consult. One of the reasons for dedicating resources to SEPG is to ensure follow- through on appraisal findings. Many improvement programs have failed simply because no action resulted from the appraisal findings. Improvement comes from the following:  Action planning.  Assigning individuals to do the task.  Piloting and deploying improved processes.  Maintaining a management oversight throughout. It is important to keep in mind that software process improvement occurs in a business perspective. It might happen that there may be many other critical business issues being worked on simultaneously; there may even be a Total Quality Management (TQM) initiative under way. CMM-based improvement is an application of TQM principles to software. Hence, the synergy of aligning these initiatives is inevitable. Most of the efficient software process improvement programs have been operated under the umbrella of a TQM initiative. CMM process focuses on the standardisation of the software production, which provides a standard to assess the maturity of software organisations, provides an evolutionary framework with the form of ladder to advance the

Sikkim Manipal University B1965 Page No. 303 Software Engineering Unit 15 process capability of software organisations and then the software process maturity will be escalated subsequent to this framework. The Software Capability Maturity Model (CMM) being one of the most sought-after standards of the software process management emphasises on the advancement of the software development process and utilises efficient, well-organised management and plans to constantly improve and enhance the quality of software products. To set up the organisational responsibility for software process functions that improve the organisation as a whole, software process capability is one of the focus areas of CMM-based organisational process focus.

Self-Assessment Questions 5. The first step involved in the CMM-based process focus is the formation of a ______. 6. ______is an application of TQM principles to software. 7. CMM process focuses on the standardisation of the software production. (True/False)

15.4 Useful Processes Now that we have gained insight into process focus, let us look into some of the CMM-based useful processes. To improve the maturity of software processes in terms of an evolutionary path form ad hoc, chaotic processes to mature, disciplined software processes; the CMM describes the principles and practises underlying software process. During the initial process (Level 1) of CMM, the professionals are driven from crisis-to-crisis by unplanned priorities and unmanaged change. Such groups are difficult to recognise. However, over time, they are easy to identify because they generally do not meet commitments. Senior management makes operating plans, and when one group does not meet commitments, the total organisation misses its plan. When new plans are successively missed, the management’s frustration increases. For creative professionals, the most frustrating part of an organisation is that the same problem constantly recurs.

Sikkim Manipal University B1965 Page No. 304 Software Engineering Unit 15

It is important to realise that the CMM-based software process is complex and involves a host of various activities, such as:  Planning models – Software models can be helpful in making product plans, but we should handle them with care. If we do not calibrate models to the particular organisation’s experience, errors can occur in varied ranges as shown by experts. When we use models to produce software cost estimates, we often blindly accept their outcomes and do not develop the project plan properly. The people in the organisation do not understand the project, appreciate their roles or feel committed to the plan.  Once the size and resource estimates have been made, it is necessary to spread these resources over the planned schedule. The most frustrating software processes are often caused by poor configuration management.  The repeatable process – After conducting an assessment, the organisation is in a position to address its key improvement priorities. The role of the management system is to ensure that projects are successfully completed. It also needs a continuing management focus on the progress of each project. The ground work for software project management is the commitment discipline. This is supported by plans, estimates, reviews and tracking systems, which focus on ensuring that the organisation meets its commitments. Commitments are not met by reviews, procedures or tools; however, they are met by committed people.  The defined process – We can say that a standard is a rule or foundation for comparison that is used to assess the size, content, value or quality of an object or activity. In software, two kinds of standards are used to define the way the software is developed and maintained. One class of standard describes the nature of the object to be produced, while the other defines the way the work is to be performed. Procedures are closely related to standards. There are many different ways to establish standards for an organisation. A standard is appropriate when no further judgement is needed. Standardisation makes sense when items are arbitrary and must be done uniformly or when there is one clear best alternative. Some standards are essential to the maintenance of business or technical control. Therefore, we can say that a defined Sikkim Manipal University B1965 Page No. 305 Software Engineering Unit 15

software process provides an organisation with a consistent process framework while permitting adjustment to unique needs. Some guidelines on developing and using process architecture are as follows: o Establish objectives. o Define the basic process architecture. o Make sure it meets the needs of the project. o Enforce it to an overall process framework.

Self-Assessment Questions 8. After conducting an ______, the organisation is then in a position to address its key improvement priorities. 9. In software, three kinds of standards are used to define the way the software is developed and maintained. (True/False) 10. The ground work for software project management is the ______discipline.

Activity 1: Imagine you are the manager of a software organisation. Explain the CMM-based process involved in delivering a software product. (Hint: Refer to Section 15.4, CMM-Based Useful Processes.)

15.1 Training The previous section familiarised us with the CMM-based useful processes; so let us now familiarise ourselves with the CMM-based process training. Documented processes are of little value if they are not effectively deployed. Training, by means of a broad variety of mechanisms, is crucial to consistent and effective software engineering and management. The reason for training employees in an organisation is to develop skills. Apart from formal class room training, there are various training mechanisms that can be effective in building skills. The one that needs serious consideration is the formal mentoring problem. Inefficient teams can cripple good teams; hence, it is important to provide management training to all the teams. Individuals are generally promoted to the managerial levels based on their technical skills. Hence, it is the responsibility of the organisation to provide such individuals with necessary

Sikkim Manipal University B1965 Page No. 306 Software Engineering Unit 15 interpersonal skills. Software organisations are facing challenges to cut down cost, enhance quality and enhance productivity and customer satisfaction and also to accelerate access to data and information that will enable stronger business processes. The CMM was developed to assist organisations for getting better quality of their processes through implementation of processes that are mature. (These processes have a high predictability of results and low risk of encountering unfamiliar variables or situations.) The CMM-oriented models are used to measure how much an organisation uses defined processes to manage some activity. The training on CMM-based processes must be attended by the below- mentioned list of people:  Data governance professionals  Data custodians  Data architects  Enterprise architects  Data administrators  Business analysts  Project managers  IT professionals  Subject matter experts The learning objectives of the training include the following:  Understanding the history and the purpose of CMM-based processes.  Learning about the CMM benefits.  Understanding the basic structure of the CMM and related maturity models.  Understanding the CMM content and structure (key process areas, key process indicators, levels, and so on).  Developing a basic plan for measuring maturity in the organisation for data management, process improvement and governance.  Implementing activities within the organisation for CMM and related maturity efforts.

Sikkim Manipal University B1965 Page No. 307 Software Engineering Unit 15

Self-Assessment Questions 11. Documented ______are of little value if they are not effectively deployed. 12. The reason for training employees in an organisation is to ______. 13. The learning objectives of the training do not include “learning about CMM benefits.” (True/False)

15.6 Risk Management In the previous section, we studied about the CMM-based process training. Let us study about the risk management involved in the CMM-based process. We can define risk management as the identification, assessment and prioritisation of risks. This is followed by synchronised and economical application of resources to reduce, monitor and manage the probability of unfortunate events to maximise the realisation of opportunities. The principles of risk management have been mentioned below:  Create value.  Be an essential part of organisational processes.  Be part of decision making.  Explicitly address uncertainty.  Be specific and structured.  Be based on the best available information.  Be tailored.  Take into account human factors.  Be transparent and inclusive.  Be dynamic, iterative and responsive to change.  Be capable of constant improvement and enhancement. In case of project management, risk management includes the following activities:  To plan as to how risk will be managed in the particular project. Plan should include risk management tasks, responsibilities, activities and budget.  Maintain live project risk database.

Sikkim Manipal University B1965 Page No. 308 Software Engineering Unit 15

 Prepare mitigation plans for risks that are chosen to be mitigated.  Summarise planned and faced risks, effectiveness of mitigation activities and effort spent for the risk management. Some people in software companies always argue that software project management is a risk. In one sense, the software CMM is about managing risk. An attempt is always made to establish stable requirements so that we can make an early plan to manage things effectively. However, business changes rapidly and perhaps chaotically. Although processes that help in managing the risks of a chaotic world can be established, a change needs to be implemented. Key processes or systems that are recognised as relevant to the development effort for risk assessment must be documented along with appropriate rationale for selection. For processes that don’t require risk assessment, a brief narrative describing the rationale for the decision must be included in the software. If a contract demands the supplier to maintain a specific level of maturity in relation to the CMM for software, the minimum set of key processes identified or risk assessment will be those related with that level along with any customer imposed tasks. The new CMM model has elevated risk management to a complete process area. This is a significant change for those organisations that currently use the CMM for software. The purpose of risk management is to recognise potential problems before they occur, to mitigate adverse impacts on achieving objectives. Risk management is a constant, forward-looking process, integral to both business and technical management. It encompasses defining a risk management strategy, identifying and analysing risks.

Self-Assessment Questions 14. Software project management is a ______; this is always being argued by some people in the organisation. 15. The new CMM model has elevated risk management to a complete process area. (True/False) 16. The purpose of risk management is to ______potential problems before they occur, to mitigate adverse impacts on achieving objectives.

Sikkim Manipal University B1965 Page No. 309 Software Engineering Unit 15

Activity 2: Briefly explain the process of risk management in CMM-based processes. (Hint: Refer to Section 15.6, Risk Management in CMM-Based Processes.)

15.7 Customer–Supplier Relationship In the previous sections, we have understood the focus, training and the risk management involved in CMM-based processes. We shall look into some of the customer–supplier relationships involved in a CMM-based process in this section. Setting up a good, functional relationship with the customer and end-user is based on open communication and integrity. This requires assistance from the customer, and the danger of customer irrationality is always preset. Building good customer–supplier relationships is a long-term endeavour, but if the organisation has (or wants to have) a stable customer base, the customer must appreciate the complexities of software engineering, just as the supplier must understand the application domain and business environment for the software product. In case of CMM-based processes, the teams do not talk to their customer. One of the motives behind Software Capability Evaluations (SCE) is the customer’s desire for predictable costs and schedules.

15.8 Peer Reviews Peer review is one of the best kinds of review that you can benefit from. We can define peer review as a tool for removing defects from the software product early and efficiently. To spot the defects and areas where changes are needed, a systematic examination of the software product by the producer’s peers is involved. The explicit products that will experience a peer review are recognised in the project’s defined software process and scheduled as part of the software project planning activities. The CMM defines the goals of peer reviews to be as follows:  Plan review activities.  Identify and remove software defects early in the process.

Sikkim Manipal University B1965 Page No. 310 Software Engineering Unit 15

To execute peer reviews, the CMM requires that the project follow a written organisational policy. In addition, sufficient resources and funding must be provided for performing peer reviews on each software product to be reviewed. Leaders obtain training as to how to lead peer reviews. Reviewers, who take part, obtain the essential training in the objectives, principles and methods of peer reviews. Peer reviews are planned and the plans are executed as per a documented procedure. The data on the conduct and results are recorded. We can make and use measurements to determine the status of the peer-review activities. The activities and work products for peer reviews undergo an audit or group review. This is done by the software quality assurance group. Peer reviews are often considered to be expensive and timely and as a result, we often term them as not being worth the effort. In addition, they are slow to evolve with a company’s software process, and hence are reactive instead of proactive.

15.8.1 Types of peer reviews Since we are discussing about the peer reviews, let us have a brief discussion on the different types of peer reviews. There are several types of peer reviews currently in use. Each of these is conducted with the purpose of locating software defects. A few of them involve significant investment from the project teams, while others include a simple inspection of someone else’s code. The key to obtaining payback on a peer review is to choose the appropriate method, depending on the magnitude of the project. The method that we used in the past, to meet the peer-review requirement, has been the traditional “code-walk-through,” where the programmer runs the peers through a program code and justifies their process and data flow creation. Such meetings are often expensive. Any process should allow for the five implementation methods that have been mentioned below. At the same time, these implementation methods are dependent on project scope and their impact. The scope in software development varies as drastically as that of constructing building. Let us briefly discuss the five major peer-review techniques in use, identified from a study.  Inspections  Structured walk-through

Sikkim Manipal University B1965 Page No. 311 Software Engineering Unit 15

 Hybrid inspection or walk-through  Desk checking  Round-robin We will now discuss these types of peer reviews in detail, as shown in Figure 15.1.

Fig. 15.1: Types of Peer Reviews  Inspections - We can say that inspections are meticulous static analysis techniques. These techniques involve the training of the inspection team, well-defined roles that include a facilitator and the complete measurement of defects encountered. We can cover many software products including requirements, design, code, user documentation, test plans and test cases by inspections. Let us have a look at the advantages of inspection: o It is the most efficient tool that is used to remove any form of defect. o The only technique to achieve efficiencies of 75% or more in field conditions and may be tailored for the project. The disadvantage is that o It is expensive and time consuming.

Sikkim Manipal University B1965 Page No. 312 Software Engineering Unit 15

 Structured walk-throughs - These are static analysis techniques in which a designer or programmer gives a walk through to the members of the development team and other concerned parties through documentation or code; the participants raise questions and make comments about possible errors, violation of development standards and other problems. We should find and log defects during the review with the assigned action items. Upon the closure of the review, we take a decision on how to proceed. After the review, we resolve the uncovered errors along with tracking and communicate their status. The advantages of structured walk-throughs are as follows: o It is the second most efficient method for removing defects; it may be tailored to the project. o It is not as expensive as full inspection. The disadvantage of structured walk-through is that o It requires a moderate size group of reviewers.  The hybrid inspection or walk-through - This technique is a customised approach in which a group of participants, consisting of the author, the moderator and reviewers perform the review. Reviewers are wrought in such a way that the anticipated benefits exceed the minimum necessary support required by the individuals who are asked to participate. Software review metrics are gathered and monitored so as to determine the effectiveness of the reviews. The advantages of this technique are as follows: o It requires a small group of reviewers. o The roles may be combined. o It endeavours on finding defects. The disadvantage of this technique is that o It loses effectiveness if too much analysis is done on defect evaluation.  Desk checking - This is a camouflaged review and debugging methodology carried out by individual programmers and analysts who were involved in the software product creation. Errors are found and logged during the review.

Sikkim Manipal University B1965 Page No. 313 Software Engineering Unit 15

The advantages of this technique are as follows: o It is inexpensive. o It is easy to schedule and complete. The disadvantages of this technique are as follows: o It is typically the least effective review method. o The effectiveness depends largely on the reviewer.  The round-robin review - This technique is a process of desk checking by multiple peers in a chronological manner. The primary checker makes his/her review, identifies and logs errors, then passes the folder to the next reviewer who performs the review adding and logging any additional error. This continues until all the reviewers have participated and the folder is returned to the author. The advantages of this technique are as follows: o It is more efficient than simple desk checking. o Multiple reviewers are involved. o Roles can be assigned, typically a lower cost than other review techniques. The disadvantage of this technique is that o It is not efficient as inspections.

15.8.2 Peer-review process Now that we have understood the different types of peer reviews, let us look into the process involved in peer review. In order to locate and remove the software defects during the early stages, the organisation needs to ensure that the steps provided below are followed. Let us look at these steps: 1. Identifying which software work products are to be reviewed. 2. Choosing the appropriate peer-review technique by weighing the software work product’s scope and business impact with the amount of time worthy to be spent on a peer review. 3. Documenting the peer-review plan, schedule and types. 4. Publishing the peer-review schedule during the project planning stage.

Sikkim Manipal University B1965 Page No. 314 Software Engineering Unit 15

Self-Assessment Questions 17. ______technique is a process of desk checking by multiple peers in a chronological manner. 18. Which peer review is called as a “concealed review”? 19. Identification of the software products that are to be reviewed is the first step in the peer-review process. (True/False)

Activity 3: Suppose you have to conduct a peer review of a CMM-based process in a software company. Briefly explain the process of peer review in CMM-based processes. (Hint: Refer to Section 15.8.2, Peer-review process.)

15.9 Summary Let us recapitulate the important concepts discussed in this unit:  CMM-based improvement is the most effective systematic approach to software process improvement.  Management by fact is a paradigm shift for most organisations which must be based on a measurement foundation.  Management sponsorship is the most important element in the creation of organisational capability. Commitments and management by fact play an important role in every process, irrespective of whether it is a CMM- based process or not.  The main focus of CMM-based processes is standardisation of software production. CMM-based processes are often difficult to understand.  Training is extremely important in CMM-based processes.  Software project management is always a risk from a practical standpoint. It is prudent to minimise this risk by attempting to follow CMM-based processes.  Building good customer–supplier relationships is a long-term endeavour, but if the organisation has (or wants to have) a stable customer base, the customer must appreciate the complexities of software engineering, just as the supplier must understand the application domain and business environment for the software product.

Sikkim Manipal University B1965 Page No. 315 Software Engineering Unit 15

 Peer review is the best type of review. Inspections, structured walk- through, hybrid inspection, desk checking and round-robin review are some of the types of peer reviews practiced by the software organisations.

15.10 Glossary Paradigm: A set of forms all of which contain a particular element. Total Quality Management (TQM): A method by which management and employees can get involved in the continuous improvement of the production of goods.

15.11 Terminal Questions 1. Describe the CMM-based useful processes. 2. Briefly explain about the CMM-based process training. 3. Briefly explain risk management in CMM-based processes. 4. Explain the concept of peer reviews. 5. Explain in detail the types of peer reviews.

15.12 Answers Self-Assessment Questions 1. True 2. Systematic 3. Measurement 4. False 5. Software Engineering Process Group (SEPG) 6. CMM-based improvement 7. True 8. Assessment 9. False 10. Commitment 11. Processes 12. Develop skills 13. False 14. Risk 15. True 16. Recognise

Sikkim Manipal University B1965 Page No. 316 Software Engineering Unit 15

17. Round-robin review 18. Desk checking 19. True Terminal Questions 1. (Refer to Section 15.4 for further information.) 2. (Refer to Section 15.5 for further information.) 3. (Refer to Section 15.6 for further information.) 4. (Refer to Section 15.8 for further information.) 5. (Refer to Section 15.8.1 for further information.)

15.13 Case Study Improving the Quality of Software Development Process XYZ Technologies are amongst the largest global IT services and product engineering services. XYZ makes an ideal partner for organisations looking at transformational IT solutions because of its core capabilities, vast human resources, commitment to quality and the global infrastructure to deliver a wide range of technology and business consulting solutions. XYZ is the forefront of technological and business co-innovation and invention disclosures. Challenge: A need for high degree of requirements was there along with ever-changing requirements. The already existing requirement was not strong enough to handle this. There was a soaring degree of post release defects handled by the support team which was not being fed back to the development team. The review process was also not sufficient enough to analyse the captured review data. Any process adding-up or process improvement initiative was looked upon as a cost to the product life cycle. Response: An early assessment was done to analyse the gaps in the existing system. In project planning, new project management roles were defined. The organisation focused on defect management rather than defect prevention.

A methodology for tracking effort was laid down and a tool was created to implement track efforts. A new estimation methodology was also drafted.

Sikkim Manipal University B1965 Page No. 317 Software Engineering Unit 15

The XYZ consultants provided the necessary training and mentoring to the process action team members as well as the practitioners. The business benefits include that the specific pain areas identified by the client were addresses and new processes were defined. The XYZ consultants also identified gaps in the existing process with respect to CMM-level requirements that helped the client in drawing up the future road map. Discussion Question: 1. Explain in detail the steps taken by XYZ Technologies to improve the quality of the entire software development process.

References/E-References:  Hunter, R. B. Process Improvement in Quality Management Systems by Software Process Improvement, IEEE Computer Society, (2001)  Oivo, M., & Seija. Product Focused Software Process Improvement, Springer- Verlag Berlin Heidelberg New York.(2002)

Sikkim Manipal University B1965 Page No. 318 Software Engineering Unit 16

Unit 16 Software Quality Assurance Structure: 16.1 Introduction 16.2 Software Quality Assurance 16.3 Quality Concepts 16.4 Quality Movement 16.5 Reviews Software review Formal Technical Review (FTR) 16.6 Software Reliability 16.7 Background Issues 16.8 Software Quality Assurance Activities 16.9 SQA Plan 16.10 Summary 16.11 Glossary 16.12 Terminal Questions 16.13 Answers 16.14 Case Study

16.1 Introduction In the previous unit, we discussed about Capability Maturity Model (CMM)- based process improvement. We analysed that CMM-based improvement is most effective within a systematic approach to software process improvement. In this unit, we will discuss about Software Quality Assurance (SQA), wherein we will study about the standards and procedures of quality assurance. We will also study about the various concepts related to quality and the quality movement. We will also have a brief discussion on software reviews and Formal Technical Reviews (FTRs). We will also study about the tools used for formal technical reviews. This unit will also familiarise us with software reliability. We will also analyse the background issues, and activities related to quality assurance. This unit will enable us to understand how to go about the task of software quality assurance of a software product.

Sikkim Manipal University B1965 Page No. 319 Software Engineering Unit 16

Objectives After reading this unit you should be able to:  explain quality concepts and quality movement  describe software reviews and formal technical reviews  enlist SQA activities  describe the SQA plan

16.2 Software Quality Assurance We will first understand the meaning of Software Quality Assurance (SQA). We often use the word “quality” and we know that quality can be good or bad. Literally, quality assurance refers to the assurance of quality. Thus, we can say that SQA means assurance of high software quality. It is a combination of a means of monitoring the software engineering processes and methods that are used to ensure quality. We can define SQA as a planned and systematic approach to the evaluation of the quality and solidarity to software product standards, processes and procedures. The main role of SQA is assuring that standards and procedures are adhered to and are followed all the way throughout the software development life cycle. Quality assurance approval points are incorporated in the software development and control processes, whereas an SQA evaluation of the product may be done in connection to the applicable standards. The two key principles that characterise SQA are the following:  Fit for purpose, that is, the product should be suitable for the intended purpose.  Right first time, that is, mistakes should be eliminated. You must note that SQA is a collection of activities like monitoring the quality of raw materials, products and components, services linked to production, management and inspection process. We can say that SQA is an activity that gets more priority than just testing the quality aspects of a product, service or facility; it also analyses the quality to ensure that it conforms to particular requirements and complies with established plans related to the project. Standards and procedures In case of software development, establishment of standards and procedures is critical, since a framework is provided by the standards

Sikkim Manipal University B1965 Page No. 320 Software Engineering Unit 16 through which the software evolves. These standards are documentation standards (standards related to the documentation of the project), design standards (standards that indicate the type and content of the design of the product) and code standards (standards that specifies the coding language of the project). The software products are compared with established standards. To develop software, procedures and standards, we need to establish prescribed methods. The role of SQA is to make sure that the existence and adequacy of these prescribed methods and standards are proper in place. We know that a plan is important for every project. Standards and procedures are also significant for every project as they add value to the software project. The two important bodies of quality standards are the Malcolm Baldrige assessment and ISO 9000. We can define ISO 9000 as a set of standards of quality management. ISO maintains these standards and certification bodies administer them. ISO 9000 standards need the procedures that are documented and cover all the parts of the organisation. Self-Assessment Questions 1. The software products are compared with standards which is a traditional criterion. (True/False) 2. To develop______, procedures and standards establish the prescribed methods. 3. Standards and procedures add value to the software project. (True/False) 4. The two vital bodies of quality standards are the ______assessment and ISO 9000.

Activity 1: Suppose you have been given an opportunity to be a “SQA Engineer.” Which principles of SQA you will follow? (Hint: Refer to Section 16.2, Software Quality Assurance.)

16.3 Quality Concepts In the previous section, we studied about SQA and its standards and procedures. Now we will study about certain quality concepts such as

Sikkim Manipal University B1965 Page No. 321 Software Engineering Unit 16 quality control, quality assurance and cost of quality. To understand these concepts in a better way, we will first need to study the concept of quality. Quality We can define quality as a concept that aims at meeting the customer’s requirements at all times in terms of factors such as cost, service and the schedule of delivery. In the same manner, we can define software quality in terms of factors such as failures, reliability and customer satisfaction. We can say that a software product is of good quality, if:  Few failures occur, when it is used by the customer.  It is dependable, that is, reliable, which means that it rarely fails when used by the customer.  It satisfies the needs of a huge number of customers. Quality Control (QC) We can define the concept of QC as a set of activities, namely, inspection of the software product, review and testing the software product that is used throughout the software process. The main focus of QC is on the techniques that are operational, and on the activities that are used to meet and check the quality requirements. Implementation of QC needs procedures, practices and resources, which comprises the following:  A training program.  Policies and standards.  Review and audit procedure.  Dedicated and trained employees.  A program for measurement.  A process for planning.  Effective techniques and tools for testing. Quality Assurance (QA) We can define QA as a process of checking whether the product or service that is being developed meets the requirements of the customer or not. QA plan must be prepared beforehand. We know that QA covers all aspects influencing the product or service quality, either individually or collectively. Cost of quality We can define this quality concept as the total cost incurred in maintaining the quality of a product that meets the customer’s requirements. Cost of quality includes three types of costs:

Sikkim Manipal University B1965 Page No. 322 Software Engineering Unit 16

 Costs of prevention – We can define these costs as the total cost of activities that are undertaken for preventing bad quality. Examples are costs of surveys for analysing supplier capabilities, costs incurred in making quality plans, and so on.  Costs of appraisal – We can define these costs as the sum of costs that are related to the measurement, evaluation or trial of products or services for assuring conformance to the standards of quality and the requirements for good performance. Examples are costs of in-process or final testing, costs incurred in the audits process, and so on.  Costs of failure – We can define such costs as the aggregate costs that result from those products or services that do not conform to the needs of the customer. These costs may occur either before the delivery of the product or service, or after the delivery of product or service. Examples are costs of rework, costs of warranty claims, and so on. Self-Assessment Questions 5. Implementation of _____ needs procedures, practices, and resources. 6. Cost of failure may occur either before the delivery of the product or service, or after the delivery of product or service. (True/False) 7. Costs of prevention are the total costs of activities that are particularly for ______bad quality. 8. QA plan must be prepared beforehand. (True/False)

16.4 Quality Movement In the previous section, we discussed about the quality concepts. In this section, we will discuss about the quality movement. First, you must note that the movement of quality is not bound to any specific industry. In the last few decades, there has been a more targeted approach towards quality. The quality movement was established in North America in 1940 and has grown and expanded since then having developed through many milestones like quality circles and quality management. Today, organisations such as the National Quality Institute (NQI) and the American Society for Quality (ASQ) continue to advance individual, organisational and community excellence through quality improvements, learning and knowledge exchange.

Sikkim Manipal University B1965 Page No. 323 Software Engineering Unit 16

As per Gregory Watson, former president of ASQ, “Total quality movement is superior due to the reason of what we have studied, as initiatives have been implemented. Motivation for performance excellence and business results is the next focus for quality. We need to synthesize our efforts and continue to build upon our quality book of knowledge.” In 1954, Dr. Joseph M. Juran stressed the importance of systems—thinking that starts with product designs, prototype testing and accurate process feedback. A move from Statistical Quality Control (SQC) (a term used to describe the set of statistical tools used by quality professionals) to Total Quality Control (TQC) conveys the importance of quality to customers. In 1968, Kaoru Ishikawa, one of the fathers of TQC in Japan, had outlined the elements of TQC management. They are as follows:  Quality comes first, not short-term profits.  The customer comes first, not the producer.  Decisions are based on facts and data.  Management is driven by cross-functional committees covering product planning, production planning, purchasing, manufacturing and sales and distribution. One of the TQC methodologies developed in Japan is referred to as the Ishikawa or Cause and Effect diagram, which is shown in Figure 16.1.

Fig. 16.1: Cause and Effect Diagram As per Figure 16.1, materials frequently differ, when sources of supply or size requirements vary. Equipment or machines also operate in a different way based on variations in their own parts and they operate sufficiently for

Sikkim Manipal University B1965 Page No. 324 Software Engineering Unit 16 only part of the time. Processes or work methods have even superior variations. Finally, measurement also varies.

Self-Assessment Questions 9. In _____ the quality movement was established in North America. 10. One of the TQC methodologies developed in Japan is referred to as the ______. 11. According to cost and effect diagram, measurement also varies. (True/False)

16.5 Reviews In the previous section, we discussed about the concept of quality movement. In this section, we will discuss about software reviews. To start with, let us first discuss about reviews. We know that generally reviews are conducted to detect errors and correct them. We can classify reviews into five types, namely, code review (review of source code of the computer), technical review (review for examining the suitability of the software product for its defined use), inspection (simple review to find defects), walk-through (review, in which people ask questions, and have a walk-through of the software product) and software review (review of the software). We can define software review as a process or a meeting during which a software product is screened by project personnel, managers, users, customers, user representatives or other concerned parties for comment or approval. If we talk about a software product we can refer to it as a technical document or partial document, produced as a deliverable of a software development activity. This may consist of documents such as contracts, project plans and budgets, requirements documents, specifications, designs, source code, user documentation and other types of specialist work product. 16.5.1 Software review We can consider software review as a process that is industry-proven, and is used in the improvement of quality of the software product and reduction in the time and costs of software development life cycle.

Sikkim Manipal University B1965 Page No. 325 Software Engineering Unit 16

We can divide software reviews into three categories. They are as follows:  Software peer reviews – The author of the work product or one or more colleagues of the author conduct these reviews for evaluating the technical content and/or quality of the work.  Software management reviews – Management representatives conduct these reviews for evaluating the status of work done and for taking decisions regarding downstream activities.  Software audit reviews – Persons who are external to the software project conduct these reviews for evaluating compliance with specifications, standards, contractual agreements or other criteria related to software reviews. 16.5.2 Formal Technical Review (FTR) After discussing about software review, we will now discuss about another type of review called formal technical review. The term software inspection is sometimes used interchangeably to mean FTR. Technical reviews must be done by a team of members. The document is reviewed by the reviewer and also the person who prepares it. The reviewer and the author of the document sit together and do the review of the document. To arrive at a technically superior version of the work, products must be reviewed. FTR comes into the picture whenever there is a recommendation for doing so, if any modification has been done, or there has been an introduction of alternative methods. Now, let us have a look at the participants whose inclusion is recommended by IEEE 1028 to fill the following roles while performing a technical review.  The decision maker – This is specially meant for the team that requires mandatory technical review. This determines if the review objectives have been met or not.  The review leader – He/she is accountable for performing administrative tasks pertaining to the review, making sure decorum is maintained, and ensuring that the review meets its objectives.  The recorder – He/she identifies anomalies, action items, decisions and suggestions provided by the review team.  Technical staff – They are active participants in the review and evaluation of the software product. Sikkim Manipal University B1965 Page No. 326 Software Engineering Unit 16

 Management staff – They may participate in the review for the purpose of culling out issues that require management intervention.  Customer or user representatives – They may fill roles determined by the review leader prior to the review. Tools for formal technical review As we are discussing about FTRs, let us have a look at some tools that support the FTR.  Code striker – It is a Perl CGI script that supports collaborative code review.  Instant QA – It inspects applications for critical and failure-causing defects.  Review Pro – It is a commercial tool developed by Software Development Technologies Corporation. This runs on windows and UNIX platforms.  Check mate – It enables a software inspection group to automatically inspect C and C++ source code against predetermined coding policy. Check mate is available for all windows platforms with UNIX/VMS.  Asynchronous/Synchronous Software Inspection Support Tool (ASSIST) – It is a common tool designed to permit the enforcement and support of any inspection process.

Self-Assessment Questions 12. A ______is a process or a meeting during which a software product is screened by project personnel, managers. 13. Software audit reviews are conducted by the persons who are external to the software project. (True/False) 14. In case of software management ______, management representatives conduct these reviews for evaluating the status of work done. 15. The ______is specially meant for the team that requires mandatory technical review. 16. Code striker is a ______script that supports collaborative code review. 17. ______inspects applications for critical and crash causing defects. 18. Check mate is available for all windows platforms with ______.

Sikkim Manipal University B1965 Page No. 327 Software Engineering Unit 16

19. The recorder determines anomalies, action items, decisions and suggestions done by the review team. (True/False)

Activity 2: Suppose you are given a task to review software. Enlist the types of software reviews you can opt for doing the same. (Hint: Refer to Section 16.5.1, Software review.)

16.6 Software Reliability In the previous section, we discussed about FTRs. In this section, we will revisit the concept of software reliability as studied in Unit 7—Software Reliability. We can define software reliability as the chance of failure-free software operation for a predetermined period of time in a proper environment. Software reliability is an important factor affecting system reliability. We can classify the software reliability techniques into two categories, as shown in Figure 16.2.

Fig. 16.2: Software Reliability Techniques

 Trending reliability techniques – These reliability techniques refer to the techniques that trace the failure data generated by the software

Sikkim Manipal University B1965 Page No. 328 Software Engineering Unit 16

system for evolving a reliability operational profile of the system over a given time limit. These reliability techniques are more suitable for software of a system. We can further classify these techniques as: o Error seeding – We use this technique for estimating errors in a program. This technique uses multistage sampling in which we classify the errors into primitive and seeded errors. o Failure rate – We use this technique for studying the rate of failure of a program at the failure intervals. o Curve fitting – We use this technique for studying the relationship between the complexity of software and the total number of program faults or the failure rate. We do so with the help of statistical regression analysis. o Reliability growth – We use this technique for measuring and predicting the amendment of the programs related to reliability via the testing process.  Predictive reliability – It refers to the reliability that allocates probabilities to the operational profile of a software system. This reliability technique is more suitable for the hardware of a system.

Self-Assessment Questions 20. ______technique is used for estimating errors in a program. 21. Trending reliability techniques are more suitable for ______of a system. 22. Predictive reliability technique is more suitable for the hardware of a system. (True/False)

16.7 Background Issues In the previous section, we studied about the concept of software reliability. In this section, we will study about the background issues related to quality assurance. We know that the most essential activity for any business that produces products to be used by others is quality assurance. Prior to the twentieth century, the sole responsibility of the craftsperson who built a product was quality assurance. In 1916 at Bell Labs, introduction of the first formal quality assurance and control function took place which was swiftly spread

Sikkim Manipal University B1965 Page No. 329 Software Engineering Unit 16 across the manufacturing world. More formal approaches were suggested during 1940. Today, almost each and every organisation has mechanisms to ensure quality in its products. In fact, explicit statements of an organisation’s concern for quality have become a marketing joy during the past few decades. The record of quality assurance in software development goes hand in hand with the record of quality in hardware manufacturing. It was in military contract that software standards for quality assurance for software were introduced. In more precise terms, we can define software quality as a planned and systematic pattern of actions that are needed to ensure high quality in software. The implication of software is that several members of the development team have SQA responsibility. These include software engineers, project managers, customers, salespeople and the individuals who serve within an SQA group. The SQA group serves as the customer’s in-house representative. This means the people who execute SQA must look at the software from the customer’s point of view. Self-Assessment Questions 23. The ______group serves as the customer’s in-house representative. 24. Today, almost every organisation has mechanisms to ensure ______in its products. 25. The record of ______in software development goes hand in hand with the record of quality in hardware manufacturing.

16.8 Software Quality Assurance Activities In the previous section, we discussed about the background issues related to quality assurance. In this section, we will discuss about software quality assurance activities. We know from the previous sections that SQA is conducted with a variety of tasks linked with two different constituencies. These two different constituencies are:  Software engineers who perform the technical work.

Sikkim Manipal University B1965 Page No. 330 Software Engineering Unit 16

 SQA group that is responsible for quality assurance plans, oversight, record maintenance and analysis and reporting. Software engineers address quality by applying solid technical methods and measures, conducting FTRs and performing well-organised software testing. SQA consists of a set of activities that address planning, record keeping, analysis and reporting of quality assurance. Note that individual SQA groups perform these activities. Let us have a quick overview of these activities.  Build up SQA plan for the project – This is the first activity of SQA. We have to create a plan for the software project. This plan covers the identification of the evaluations to be carried out, audits and reviews to be carried out, applicable standards to the project, error reporting and tracking procedures and the documents which the SQA group has to generate.  Take part in the software process description development of the project – This stage involves the software team picking out the software process which is to be carried out. SQA group reviews this software process’s description.  Review – In this stage, the software team reviews different activities of software engineering such as analysis, design, construction, verification and management to check their agreement with the process which was defined in the previous activity.  Audit – In this stage, SQA group also checks that mistakes have been corrected and reports the result to their manager at specified intervals of time.  Review for deviations – In this stage, SQA group makes sure of the documentation of the deviations occurring in the software project plan, process description and applicable standards.  Recording – In this stage, the SQA team records the non-compliance items (items which do not conform to the project details) with evidence, until they are resolved. The team also reports about non-conformities to the manager.

Sikkim Manipal University B1965 Page No. 331 Software Engineering Unit 16

Self-Assessment Questions 26. Software engineers address quality by applying solid technical methods and measures, conducting formal technical reviews and performing well-organised software testing. (True/False) 27. In ______, SQA group also checks that mistakes have been corrected and reports the result to their manager at specified intervals of time. 28. While reviewing for deviations, SQA group makes sure of the documentation of the deviations occurring in the software project plan, process description and applicable standards. (True/False)

16.9 SQA Plan As we are now familiar with the QA activities, let us study about SQA planning, which is an important aspect of SQA. Depending on how well the planning is done, the SQA’s complete operation is estimated. In smaller businesses, planning might not actually indicate the flow of SQA. But in case of larger businesses, SQA planning plays the main role. Without planning, each component or department that functions on the application will be affected and will not function. We can say that SQA planning is not only a document that describes who gets to do a particular task but also includes different stages in the SQA plan. In case of smaller organisations, planning may be limited to the particular stage of the application. But, when the scenario changes, its only through planning that everyone will know where they are currently and where they are headed towards in terms of SQA. Let us have a look at what all we can include in a SQA plan. SQA plan content - An SQA plan is a detailed description of the project and its approach for testing. We can divide an SQA plan into four phases, as per certain standards (IEEE to be more specific). These four phases are:  SQA plan for software requirements – In this first phase, the activities connected to software requirements are written in detail. During this phase, the team creates steps and phases on how the software requirements are analysed. To ensure that the plan works out, the team can refer to additional documents as well.  SQA plan for architectural design – In this phase, the team analyses in detail the preparation of the development team for detailed design of

Sikkim Manipal University B1965 Page No. 332 Software Engineering Unit 16

the plan. This stage is a rough presentation of the program, but it still has to go through meticulous scrutiny before reaching the next stage.  SQA plan for detailed design and production – This phase handles the quality assurance plan for detailed design and actual product and is probably the lengthiest among all phases. The tools and their approaches are written by the SQA team in detail as per the plan. The team starts planning on the transfer phase as well.  SQA plan for transfer – The final stage is the QA plan for transfer of technology to the operations. The process through which transfer of technology through training and support are monitored as per the QA plan.

Self-Assessment Questions 29. In smaller businesses, planning might not actually indicate the flow of SQA. (True/False) 30. The final stage of the SQA plan content is the QA plan for ______of technology to the operations. 31. SQA plan can be divided into _____ phases.

Activity 3: Imagine you are the manager of a software organisation. Design an SQA plan to assure the quality of the product. (Hint: Refer to Section 16.9, SQA Plan.)

16.10 Summary Let us recapitulate the important concepts discussed in this unit:  SQA is a process of verifying whether the software product or service meets the requirements of the customer or not.  There are three main quality concepts, namely, quality control, quality assurance and cost of quality.  Software reviews are an important means of ensuring statistical quality assurance. There are three types of software reviews, namely, software peer reviews, software management reviews and software audit reviews.

Sikkim Manipal University B1965 Page No. 333 Software Engineering Unit 16

 FTRs or walk-throughs are another method of review where the author, reviewer and other designated personnel come together and conduct the review process jointly.  Software reliability helps us in analysing how much we can rely on software. There are two types of software reliability techniques, namely, trending reliability techniques and predicting reliability techniques.  SQA activities include building up the SQA plan for the project, taking part in the software process description development of the project, reviewing, auditing, reviewing for deviations and recording.

16.11 Glossary Anomalies: An occurrence of the object that is strange. IEEE: It is the world’s leading technical professional association for industry- based standards. Statistical Regression Analysis: Techniques for modelling and analysing different variables.

16.12 Terminal Questions 1. Describe the concept of Software Quality Assurance. 2. Briefly explain quality concepts. 3. What are software reviews? Briefly explain. 4. Describe the tools used in case of formal technical reviews. 5. Briefly explain the SQA plan.

16.13 Answers Self-Assessment Questions 1. True 2. Software 3. True 4. Malcolm Baldrige 5. Quality control 6. True 7. Preventing 8. True 9. 1940

Sikkim Manipal University B1965 Page No. 334 Software Engineering Unit 16

10. Ishikawa or Cause and Effect diagram 11. True 12. Software review 13. True 14. Reviews 15. Decision maker 16. Perl CGI 17. Instant QA 18. UNIX/VMS 19. True 20. Error seeding 21. Software 22. True 23. SQA 24. Quality 25. Quality Assurance 26. True 27. Audit 28. True 29. True 30. Transfer 31. Four

Terminal Questions 1. (Refer to Section 16.2 for further information.) 2. (Refer to Section 16.3 for further information.) 3. (Refer to Section 16.5 for further information.) 4. (Refer to Section 16.5.2 for further information.) 5. (Refer to Section 16.9 for further information.)

16.14 Case Study A Perfect Example of Achieving Product Quality XYZ Technologies is a world renowned antivirus development company. The company is headquartered in Lithuania. XYZ Technologies has several companies on the group with more than 300+ specialists all over. The services of XYZ Technologies are successfully used by all industry experts,

Sikkim Manipal University B1965 Page No. 335 Software Engineering Unit 16 leaders and IT start-up companies. They are able to do complex, science- intensive projects with a lot of science and innovations involved, as well as specialised projects. One of the problems with which a client approached XYZ Technologies was to perform QA activities on one of their products. The product was of web- based and was built on the advanced technologies. The primary objective was to perform meticulous testing to make it ready for launch within a scheduled timeline. Challenge: 1. The client wanted a cost-effective and experienced input to boost their QA work simultaneously with the deadlines. 2. The team had to get domain knowledge and product knowledge in the absence of documentation. 3. Build a strong and efficient framework to communicate with the development team as the task was time critical. Response: The XYZ team gathered business domain knowledge and product understanding while spending strong 2 weeks with the development and management team. A communication framework development for bug reporting, build-update was covered in the 2-week onsite and offsite effort. This was very essential to integrate QA model developed by the XYZ team as per the client’s development team to minimise work and time together. Actual strength in the model lies in its flexibility and flawless integration with the client activities while completing the QA tasks remotely. This resulted in: 1. Elimination of the fixed costs of having a complete QA department. 2. Increase in the profits through the savings. By combining the testing expertise with the development expertise of client, several milestones were achieved effectively and on time. The quality team of XYZ added substantial value to the product by giving suggestions in cases of improvements in process flow, business flow and feature usability. Thus, the XYZ team successfully avoided the cost overrun with a satisfaction level regarding both product quality and services to the client.

Sikkim Manipal University B1965 Page No. 336 Software Engineering Unit 16

Discussion Question: 1. Briefly explain the challenges faced by XYZ and also the measures taken by them to achieve the challenges.

References/E-References: References:  Gordon Schulmeyer, G. Software Quality Assurance. Artech House, Incorporated, 2008  Granato, G. E. Data Quality objectives and Criteria for Basic Information, Acceptable Uncertainty and Quality Assurance, U.S. Department of the Interior, U.S. Geological Survey, 1998.

E-References:  http://www.scribd.com/doc/13926561/Quality-Concepts (Retrieved on 18th May 2012)  http://www.wisegeek.com/what-is-quality-assurance.htm (Retrieved on 18th May 2012)

______

Sikkim Manipal University B1965 Page No. 337