dr. (prof). rajendra prasad mahapatra - …khannabooks.com/image/catalog/file/95940-pages from...

Dr. (Prof). RAJENDRA PRASAD MAHAPATRAME(CSE), Ph.D(CSE)

Associate DeanProfessor & HOD

Department of Computer Science & Engineering SRM UNIVERSITY NCR CAMPUS

GHAZIABAD (U.P.)

GOVIND VERMAM-Tech(CSE)

Assistant ProfessorDepartment of Computer Science & Engineering

SRM UNIVERSITY NCR CAMPUSGHAZIABAD (U.P.)

Software Engineering

SOFTWARE ENGINEERING.indd 1 05-08-2015 16:57:46

Software Engineering R.P. Mahapatra and Govind Verma

Copyright © Khanna Book Publising Co. (P) Ltd.This book is sold subject to the condition that it shall not, by way of trade or otherwise, be lent, resold, hired out, or otherwise circulated without the publisher’s prior consent in any form of binding or cover other than that in which it is published and without a similar condition including this condition being imposed on the subsequent purchaser and without limiting the rights under copyright reserved above, no part of this publication may be reproduced, stored in or introduced into retrieval system, or transmitted any form or by any means (electronic, mechanical, photocopying, recording or otherwise), without the prior written permission of both the copyright owner and the above mentioned publisher of this book.

ISBN: 978-93-82609-68-1

Edition: 2016

Published by:

KHANNA BOOK PUBLISHING CO. (P) LTD.4C/4344, Ansari Road, Darya Ganj, New Delhi-110 002Phone: 011-23244447-48 Mobile: +91-9910909320E-mail: [email protected]

Typeset and Cover Design by:Book One Graphics, New Delhi

Printed in India by:India Book Printers & Binders, Delhi


Dedicated toIn Memory of

My Parents and brothersAnd

With my wife and loving son SAI

RAJENDRA PRASAD MAHAPATRA

In Memory ofMy Parents and brothers

And My Family with my loving Nephew

HARSHGOVIND VERMA


| v |

Preface

The importance of Software Engineering is well known in various engineering fields. Overwhelming response to my books on various subjects inspired me to write this book. The book is structured to cover the key aspects of the subject Software Engineering.

This book provides logical method of explaining various complicated concepts and stepwise methods to explain the important topics. Each chapter is well supported with necessary illustrations, practical examples and solved problems. All the chapters in the book are arranged in a proper sequence that permits each topic to build upon earlier studies. All care has been taken to make students comfortable in understanding the basic concepts of the student.

Some of the books cover the topics in great depth and detail while others cover only the most important topics. Obviously no single book on this subject can meet everyone’s needs, but many lie to either end of spectrum to be really helpful. At the low end there are the superficial ones that leave the readers confused or unsatisfied. Those at the high end cover the subject with such thoroughness as to be overwhelming.

The present edition is primarily intended to serve the need to students preparing for B. Tech, M. Tech and MCA courses. This book is an outgrowth of our teaching experience. In our academic interaction with teachers and students, we found that they face considerable difficulties in using the available books in this growing academic discipline. The authors simply presented the subjects matter in their own style and make the subject easier by giving a number of questions and summary given at the end of the chapter.

Dr. (Prof). RAJENDRA PRASAD MAHAPATRA

GOVIND VERMA


| vii |

Acknowledgements

We are very much grateful to our reserved Chancellor Dr. T.R. Pachamuthu SRM UNIVERSITY and Chairman Mr. Ravi Pachamoothoo SRM UNIVERSITY for his encouragement in continuing our effort in bringing out this book.

Our sincere thanks our Director Dr. Prof. Manoj Kumar Pandey, SRM UNIVERSITY NCR Campus, Ghaziabad and Administrative Officer Dr. S. Vishwanathan SRM UNIVERSITY NCR Campus Ghaziabad for their kind co-operation.

We thank our family members for their moral support to bring out this book.

Dr. (Prof). RAJENDRA PRASAD MAHAPATRA

GOVIND VERMA


| ix |

Contents

Preface ...... ..................................................................................................................... v

Acknowledgements ......................................................................................................... vii

Chapter 1: Computer Programming and Languages ........................................................... 11.1 Introduction ................................................................................................. 11.2 Developing A Program ................................................................................... 11.3 Program Development Cycle .......................................................................... 21.4 Programming Paradigms ............................................................................... 4 1.4.1 Unstructured Programming ............................................................. 4 1.4.2 Structural Programming .................................................................. 4 1.4.3 Object-Oriented Programming ......................................................... 51.5 Characteristics of a Good Program ................................................................. 81.6 Programming Languages ............................................................................... 91.7 Types of Programming Languages ................................................................ 91.8 Features of a Good Programming Language .................................................... 9Exercise .............................................................................................................. 12

Chapter 2: Software Engineering ................................................................................... 132.1 Introduction ............................................................................................... 132.2 Software .................................................................................................... 14 2.2.1 Software Characteristics ................................................................ 15 2.2.2 Classification of Software ............................................................... 15 2.2.3 Software Myths ............................................................................. 172.3 The Software Engineering Discipline Evolution and impact ............................ 18 2.3.1 Evolution of an Art to an Engineering Discipline ............................. 18 2.3.2 A Solution to the Software Crisis .................................................... 19 2.3.3 Programs Vs Software Products .................................................... 202.4 Why Study Software Engineering ................................................................ 202.5 Software Engineering .................................................................................. 21 2.5.1 Software Engineering Layers .......................................................... 22 2.5.2 Software Engineering Management ............................................... 23 2.5.3 The Software Engineer .................................................................. 232.6 Software Development Life Cycle (SDLC) ...................................................... 25 2.6.1 Phased Development Process ......................................................... 262.7. Software Engineering Goals ......................................................................... 272.8 Relationship of Software Engineering to other Disciplines .................................... 292.9 Emergence of Software Engineering ............................................................ 30


| x | Contents

2.9.1 Early Computer Programming ........................................................ 30 2.9.2 High-Level Language Programming ................................................ 30 2.9.3 Control Flow-Based Design ............................................................ 30 2.9.4 Data Structures-Oriented Design ................................................... 32 2.9.5 Data Flow-Oriented Design ............................................................. 33 2.9.6 Object-Oriented Design .................................................................. 34 2.9.7 Other Developments ...................................................................... 342.10 Notable Changes in Software Development .................................................. 34Exercise .............................................................................................................. 36

Chapter 3: Software Process ............................................................................................ 373.1 Introduction ............................................................................................... 373.2 Process, Project, and Product ...................................................................... 38 3.2.1 Software Process Components ....................................................... 39 3.2.2 Process Framework ....................................................................... 403.3 Process Patterns ........................................................................................ 423.4 Software Life Cycle Models ......................................................................... 43 3.4.1 Waterfall Model ............................................................................. 44 3.4.2 Prototyping Model ......................................................................... 46 3.4.3 Incremental Process Model ............................................................ 48 3.4.4 The Rapid Application Model (RAD) Model ...................................... 49 3.4.5 V model ........................................................................................ 50 3.4.6 Timeboxing Model ......................................................................... 52 3.4.7 Spiral Model .................................................................................. 53 3.4.8 The Formal Methods Model ............................................................ 553.5 The Unified Process .................................................................................... 55 3.5.1 The Phases of the Unified Process .................................................. 56 3.5.2 Unified Process Work Products ....................................................... 583.6 Selection of a Life Cycle Model ..................................................................... 61 3.6.1 Characteristics of Requirements .................................................... 61 3.6.2 Status of Development Team .......................................................... 61 3.6.3 Involvement of Users ..................................................................... 62 3.6.4 Type of Project and Associated Risk ................................................ 62Exercise .............................................................................................................. 63

Chapter 4: Software Requirements and Specification ........................................................ 654.1 Introduction ............................................................................................... 654.2 What is Software Requirement? ................................................................... 66 4.2.1 Requirements Gathering and Analysis ............................................. 66 4.2.2 Types of Requirements................................................................... 67 4.2.3 Requirements Engineering Process ................................................ 71


Contents | xi |

4.3 Feasibility Study .......................................................................................... 72 4.3.1 Types of Feasibility ....................................................................... 72 4.3.2 Feasibility Study Process ................................................................ 734.4 Requirements Elicitation ............................................................................. 75 4.4.1 Elicitation Technique ...................................................................... 754.5 Requirements Analysis ............................................................................... 77 4.5.1 Data flow Diagrams ....................................................................... 78 4.5.2 Data Dictionaries .......................................................................... 80 4.5.3 Entity-relationship Diagrams ......................................................... 81 4.5.4 Software Prototyping .................................................................... 864.6 Requirements Documentation ..................................................................... 87 4.6.1 Nature of the SRS ......................................................................... 87 4.6.2 Characteristics of SRS ................................................................... 88 4.6.3 Organization of the SRS ................................................................. 894.7 Requirement Validation .............................................................................. 98 4.7.1 Requirements Reviews .................................................................. 99 4.7.2 Prototyping ................................................................................. 1014.8 Requirements Management ....................................................................... 101 4.8.1 Requirement Management Planning .............................................. 102 4.8.2 Requirements Change Management ............................................. 1024.9 Requirements Engineering Tools ............................................................... 103Exercise ............................................................................................................ 104

Chapter 5: Software Design ........................................................................................... 1065.1 Introduction ............................................................................................ 1065.2 Basics of Software Design ......................................................................... 106 5.2.1 Conceptual and Technical designs ................................................ 107 5.2.2 What is a good software design? .................................................. 109 5.2.3 Cohesion and Coupling ................................................................. 111 5.2.4 Developing a design model ........................................................... 1145.3 Strategy of Design .................................................................................... 115 5.3.1 Bottom-Up Design ...................................................................... 116 5.3.2 Top-Down Design ....................................................................... 116 5.3.3 Hybrid Design ............................................................................. 1175.4 Data Design .............................................................................................. 1175.5 Architectural Design.................................................................................. 118 5.5.1 Architectural Style ....................................................................... 1185.6 Component Level Design ........................................................................... 1225.7 Function-Oriented Design ......................................................................... 123 5.7.1 Structured Analysis .................................................................... 123


| xii | Contents

5.7.2 Structured Design ...................................................................... 1295.8 Objet Oriented Design .............................................................................. 132 5.8.1 Basic Mechanisms ...................................................................... 1335.9 Software design review process ................................................................. 137Exercise ............................................................................................................ 139

Chapter 6: Software Coding .......................................................................................... 1396.1 Introduction ............................................................................................ 1396.2 Features of software code ........................................................................ 1396.3 Coding Guidelines ..................................................................................... 140 6.3.1 Implementing Coding Guidelines ................................................... 142 6.3.2 Advantages of Coding Guidelines ................................................. 1436.4 Coding Methodology ................................................................................. 1446.5 Programming Practices ............................................................................. 145 6.5.1 Top-down Programming .............................................................. 146 6.5.2 Bottom-up Programming ............................................................. 146 6.5.3 Structured Programming ............................................................. 146 6.5.4 Information Hiding ..................................................................... 1476.6 Code verification techniques ...................................................................... 148 6.6.1 Code Reading .............................................................................. 148 6.6.2 Static Analysis ............................................................................. 149 6.6.3 Symbolic Execution ..................................................................... 149 6.6.4 Code Review ............................................................................... 1506.7 Coding Tools ............................................................................................. 1526.8 Code Documentation ................................................................................ 1536.8.1 Code Documentation tools ......................................................................... 153Exercise ............................................................................................................ 154

Chapter 7: Software Testing ..........................................................................................1567.1 Introduction ............................................................................................. 1567.2 Software Testing Basics ............................................................................ 156 7.2.1 Testability ................................................................................... 159 7.2.2 Characteristics of Software Test ................................................... 160 7.2.3 Design of Test Cases .................................................................... 1617.3 Test Plan .................................................................................................. 1617.4 Software Testing Strategy ........................................................................ 1637.5 Test Activities .......................................................................................... 1657.6 Types of Testing ...................................................................................... 166 7.6.1 Stages of SDLC ............................................................................ 166 7.6.2 Techniques of Testing .................................................................. 167 7.6.3 By specialized testing to test specific objectives ........................... 167


Contents | xiii |

7.6.4 Testing Strategies ........................................................................ 1687.7 Black Box Testing ..................................................................................... 169 7.7.1 Equivalence Partitioning ............................................................... 169 7.7.2 Boundary Value Analysis (BVA) ..................................................... 1717.8 White Box Testing ..................................................................................... 1717.9 Structural Testing ..................................................................................... 172 7.9.1 Condition Testing ........................................................................ 172 7.9.2 Loop Testing ............................................................................... 1727.10 Debugging ............................................................................................... 1757.11 Compliance with Design and Coding standards .......................................... 176 7.11.1 Advantages of coding standards .................................................. 176 7.11.2 Coding standards ....................................................................... 176 7.11.3 Coding guidelines ........................................................................ 1777.12 Clean-room Software Development ............................................................ 177 7.12.1 Teams involved in cleanroom software development ...................... 179 7.12.2 Merits and Demerits of cleanroom engineering .............................. 179Exercise ............................................................................................................ 179

Chapter 8: Software Maintenance ..................................................................................1818.1 Introduction ............................................................................................. 1818.2 Basics of Software Maintenance ................................................................. 181 8.2.1 Characteristics of Software Evaluation .......................................... 182 8.2.2 Special problems associated with software maintenance ............... 183 8.2.3 Factors affecting software maintenance ....................................... 1848.3 Categories of Maintenance ......................................................................... 1868.4 The Maintenance Process .......................................................................... 188 8.4.1 Program Understanding .............................................................. 188 8.4.2 Generating Particular Maintenance Proposal .................................. 188 8.4.3 Ripple Effect ............................................................................... 188 8.4.4 Modified Program Testing ............................................................ 189 8.4.5 Maintainability ............................................................................. 1898.5 Maintenance Model ................................................................................... 189 8.5.1 Quick-fix Model ............................................................................ 190 8.5.2 Iterative Enhancement Model ...................................................... 190 8.5.3 Reuse-Oriented Model ................................................................. 191 8.5.4 Boehm’s Model ........................................................................... 191 8.5.5 Taute Maintenance Model ............................................................ 1928.6 Estimation of maintenance costs ............................................................... 193 8.6.1 Belady and Lehman Model ........................................................... 193 8.6.2 Boehm Model .............................................................................. 194


| xiv | Contents

8.7 Regression Testing .................................................................................. 196 8.7.1 Development Testing versus Regression Testing ............................ 196 8.7.2 Regression Test Selection ............................................................. 1978.8 Reverse Engineering ................................................................................ 198 8.8.1 Scope and Tasks ......................................................................... 198 8.8.2 Levels of Reverse Engineering ...................................................... 199 8.8.3 Reverse Engineering Tools ........................................................... 2008.9 Documentation ........................................................................................ 201 8.9.1 User Documentation ................................................................... 202 8.9.2 System Documentation ............................................................... 202 8.9.3 Other Classification Schemes ........................................................ 203Exercise ............................................................................................................ 203

Chapter 9: Software Reliability ......................................................................................2049.1 Introduction ............................................................................................. 2049.2 Basic Concepts ........................................................................................ 204 9.2.1 What is Software Reliability? ....................................................... 205 9.2.2 Software Reliability and Hardware Reliability ................................. 206 9.2.3 Failures and Faults ...................................................................... 2069.3 Reliability Metrics ..................................................................................... 2079.4 Reliability Growth Model .......................................................................... 2099.5 Environment ............................................................................................ 2099.6 Statistical Design ..................................................................................... 2119.7 Uses have been Reliability Studies ............................................................. 212Exercise ............................................................................................................ 213

Chapter 10: Software Metrics ........................................................................................21410.1 Introduction ............................................................................................. 21410.2 Software Measurement ............................................................................. 21410.3 Software Metrics ...................................................................................... 215 10.3.1 Measured Data ............................................................................ 216 10.3.2 Measures, Measurement, Metrics and Indicators ........................... 21610.4 Designing Software Metrics ....................................................................... 21710.5 Types of Software Metrics ......................................................................... 218 10.5.1 Process Metrics ........................................................................... 218 10.5.2 Product Metrics........................................................................... 220 10.5.3 Project Metrics ............................................................................ 22610.6 Object Oriented Metrics ............................................................................ 22710.7 Issues in software metrics ......................................................................... 22810.8 Metrics or source code .............................................................................. 229


Contents | xv |

10.9 Metrics for testing ................................................................................... 23010.10 Metrics for maintenance ........................................................................... 231Exercise ............................................................................................................ 231

Chapter 11: Software Quality ........................................................................................ 23311.1 Introduction ............................................................................................. 23311.2 Software Quality ....................................................................................... 234 11.2.1 ISO 9126 Quality Factors ............................................................. 234 11.2.2 McCall’s Quality Factors .............................................................. 23511.3 Software Quality Assurance ....................................................................... 236 11.3.1 Software Quality Assurance Plan ................................................... 23711.4 Software Reviews ..................................................................................... 237 11.4.1 Walkthroughs .............................................................................. 239 11.4.2 Formal Technical Reviews (FTR) ................................................... 23911.5 Software Quality Managements System ...................................................... 240 11.5.1 Evaluation of Quality Systems ..................................................... 24111.6 ISO 9000.................................................................................................. 242 11.6.1 What is ISO Certification? ............................................................ 242 11.6.2 ISO 9000 for Software Industry .................................................... 242 11.6.3 Why Get ISO Certification? ........................................................... 243 11.6.4 How to get ISO 9000 Certification ............................................... 243 11.6.5 Summary of ISO Requirements .................................................... 244 11.6.6 Salient Features of ISO 9001 Requirements .................................. 245 11.6.7 Shortcomings of ISO 9000 Certification ........................................ 24611.7 SEI Capability Maturity Model (CMM) ........................................................ 246 11.7.1 Comparison between ISO 9000 Certification and SEI/CMM ............. 249 11.7.2 Is ISO CMM applicable to small organization? ................................ 24911.8 Personal Software Process (PSP) ............................................................... 24911.9 Six Sigma ................................................................................................. 25011.10 Total Quality Management (TQM) .............................................................. 251 11.10.1 Key Elements of TQM .................................................................. 252 11.10.2 Requirements of TQM .................................................................. 252Exercise ............................................................................................................ 253

Chapter 12: Software Planning and Scheduling ..............................................................25412.1 Introduction ............................................................................................ 25412.2 Responsibilities of Project Manager ............................................................ 25412.3 Defining the Problem ................................................................................ 255 12.3.1 Goals and Requirement ............................................................... 25612.4 Planning the development process ............................................................. 260


| xvi | Contents

12.5 Software Configuration Management (SCM) Process ................................... 261 12.5.1 Configuration identification ......................................................... 263 12.5.2 Change control ........................................................................... 264 12.5.3 Status accounting and auditing ................................................... 26712.6. Quality Assurance Plans ........................................................................... 267 12.6.1 Verification and validation (V&V) .................................................. 268 12.6.2 Inspections and Reviews ............................................................. 26812.7 Scheduling ................................................................................................ 272 12.7.1 Work Breakdown Structure ......................................................... 273 12.7.2 Activity Networks and Critical Path Methods ................................ 274 12.7.3 Gantt Charts ............................................................................... 276 12.7.4 PERT Charts ............................................................................... 276 12.7.5 Project Monitoring and Control ................................................... 27712.8 Organization and Team Structures ............................................................ 277 12.8.1 Organization Structure ................................................................ 278 12.8.2 Team Structure............................................................................ 27912.9 Staffing 281 12.9.1 Who is a Good Software Engineer? .............................................. 28212.10 Risk Management .................................................................................... 283 12.10.1 Risk Management Overview ........................................................ 283 12.10.2 Risk Assessment ........................................................................ 285 12.10.3 Risk Control ................................................................................ 288Exercise ............................................................................................................ 289

Chapter 13: Software Cost Estimation .......................................................................... 29013.1 Introduction ............................................................................................ 29013.2 Software product cost factors ................................................................... 29113.3 Software Cost Estimation Process ............................................................ 29213.4 Decomposition Techniques ........................................................................ 295 13.4.1 Problem-based estimation ............................................................ 296 13.4.2 Process-based estimation ............................................................ 296 13.4.3 Use-case-based estimation ........................................................... 29713.5 Empirical Estimation Models ..................................................................... 297 13.5.1 The COCOMO II Model ................................................................. 298 13.5.2 The Software Equation ................................................................ 30013.6 Estimation for object-oriented projects ...................................................... 30113.7 Specialized estimation techniques .............................................................. 301 13.7.1 Estimation for agile development ................................................ 301 13.7.2 Estimation for WebApp projects ................................................... 302Exercise ............................................................................................................ 302


Contents | xvii |

Chapter 14: Software Project Management ...................................................................30414.1 Introduction ............................................................................................ 30414.2 Responsibilities of a software project manger ............................................ 304 14.2.1 Job responsibilities of a software project manager ....................... 304 14.2.2 Skills necessary for software project management ........................ 30514.3 Project Planning ....................................................................................... 305 14.3.1 The SPMP Document .................................................................. 30614.4. Metrics for Project Size Estimation ........................................................... 307 14.4.1 Lines of Code (LOC) ..................................................................... 308 14.4.2 Function Point Metric .................................................................. 30914.5 Project Estimation Techniques .................................................................. 311 14.5.1 Empirical Estimation Techniques ................................................. 311 14.5.2 Heuristic Techniques ................................................................... 311 14.5.3 Analytical Estimation Techniques .................................................. 31214.6 Empirical Estimation Techniques ............................................................... 312 14.6.1 Expert Estimation Technique ....................................................... 312 14.6.2 Delphi Cost Estimation ................................................................ 31214.7 COCOMO-A Heuristic Estimation Technique ................................................ 313 14.7.1 Basic COCOMO Model .................................................................. 314 14.7.2 Intermediate Model ..................................................................... 317 14.7.3 Complete COCOMO ...................................................................... 31714.8 Halstead’s software science – An analytical technique ................................. 318 14.8.1 Operators and Operands for the ANSI C Language ......................... 319 14.8.2 Length and Vocabulary ................................................................ 319 14.8.3 Program Volume .......................................................................... 319 14.8.4 Potential Minimum Volume ........................................................... 320 14.8.5 Effort and Time ........................................................................... 320 14.8.6 Length Estimation ...................................................................... 32014.9 Staffing Level Estimation .......................................................................... 321 14.9.1 Norden’s Work ............................................................................ 321 14.9.2 Putman’s Work............................................................................ 322 14.9.3 Effect of schedule change on cost................................................. 323 14.9.4 Jensen’s Model ........................................................................... 32414.10 Software Configuration Management Activities ......................................... 324 14.10.1 Need of SCM ............................................................................... 325 14.10.2 Baseline ...................................................................................... 325 14.10.3 Software Configuration Item ......................................................... 325 14.10.4 Introduction to SCM Process ....................................................... 326Exercise ............................................................................................................ 327


| xviii | Contents

Chapter 15: Software Re-Engineering ...........................................................................32915.1 Introduction ............................................................................................ 32915.2 Software Re-engineering ........................................................................... 329 15.2.1 Principles of Re-engineering ........................................................ 330 15.2.2 Levels of Abstraction .................................................................. 33115.3 A Reuse approach ..................................................................................... 331 15.3.1 Domain Analysis .......................................................................... 331 15.3.2 Components Classification ........................................................... 332 15.3.3 Searching ................................................................................... 333 15.3.4 Repository Maintenance .............................................................. 333 15.3.5 Reuse without Modifications ....................................................... 33315.4 Reuse at organization level ........................................................................ 334 15.4.1 Current State of Reuse ................................................................. 33515.5 A software re-engineering process model ................................................... 336 15.5.1 Inventory analysis ........................................................................ 336 15.5.2 Document restructuring .............................................................. 337 15.5.3 Reverse Engineering ................................................................... 337 15.5.4 Code Restructuring ..................................................................... 337 15.5.5 Data restructuring ...................................................................... 337 15.5.6 Forward engineering ................................................................... 33815.6 Reverse Engineering ................................................................................ 338 15.6.1 Reverse Engineering to Understand Data ...................................... 33915.7 Restructuring .......................................................................................... 340 15.7.1 Code Restructuring ..................................................................... 340 15.7.2 Data Restructuring ...................................................................... 34015.8 Forward Engineering ................................................................................ 34015.9 Software Re-engineering activates ............................................................. 34215.10 Business Process Reengineering .............................................................. 343 15.10.1 Business processes ..................................................................... 343 15.10.2 A BPR Model ............................................................................... 343 15.10.3 The Economics of reengineering .................................................. 344 15.10.4 Business Process Re-engineering Tools ......................................... 345Exercise ............................................................................................................ 346


| 1 |

1.1 IntroductionA computer system consists of hardware, the electronic devices that are capable of computing and manipulating information, and software (set of instructions) that carries out predefined tasks to complete a given job. As we know, a computer cannot think or perform on its own. It performs operations like addition, subtraction multiplication and division only when the user instructs it to do so. The user issues instructions and the CPU acts in accordance with the instructions. The sets of instructions, which control the sequence of operations, are known as programs, and collectively programs are called software. It is an intangible commodity, that is, the part of computer system that users cannot touch.

We can equate hardware and software with human body and human intelligence, respectively. All human physical actions such as walking and eating are based on the thoughts and feelings, which is raised by the brain. If the brain does not raise thoughts and feelings, we do not perform any physical activity. Similarly, the actions functioning of every hardware equipment is driven by software. The combination of physical equipment (hardware) and logical instructions (software) gives modern computing systems their power and versatility.

Computers work on a set of instructions called computer program, which clearly specify the ways to carry out a task. An analogy of this may be thought of as the instructions given by the manager or team leader to its team. The team members follow those instructions and accordingly perform their duties. Similarly, a computer also takes instructions, the form of computer programs, and carries out the requested task. Now the question arises that how human beings instruct computers. We, as human beings, use natural languages such as Hindi, English, Spanish or French to communicate. Similarly, a user communicates with the computer in a language understood by it. Note that human beings cannot interact directly with the computer using natural languages because thus far we have not developed such computers that can comprehend natural languages. Rather the instructions, provided in the form of computer programs are developed using computer or programming languages.

1.2 Developing A ProgramAs discussed earlier, a program consists of a series of instructions that a computer processes to perform the required operation. In addition, it also includes some fixed data, required to perform the instructions, and the process of defining those instructions and data. Thus, in order to design a program a programmer must determine three basic tasks:

1. The instructions to be performed.

Computer Programming and Languages

C H

A P

T E

R

1


| 2 | Software Engineering

2. The order in which those instructions are to be performed.

3. The data required to perform those instructions.

To perform a task using a program, a programmer has to consider various inputs of the program along with the process, which is required to convert the input desired output. Suppose we want to calculate the sum of two numbers, A and B, and store the sum in C, here A and B are the inputs, addition is the process, and C is the output of the program.

A, BINPUT

C=A+BPROCESSING

COUTPUT

Figure 1.1: Programs Performing a Task

1.3 Program Development CycleBefore starting the process of writing s program (coding), the programmer has to determine the problem that needs to be solved. There are different approaches to problem solving. Most require breaking the problem into a series of smaller steps, independent of the programming language. One common technique is the use the program development cycle, with the number of steps that may vary according to the person who has formalised the development. Often the process runs in a loop, for example, as the current process is completed, new demands appear and the development process commences again. Development cycle of a program includes the following phases:

1. Analyse/Define the Problem: Firstly, the problem is analysed precisely and completely. Based on understanding, the developer known about the scope within which the problem needs to be developed.

2. Task Analysis: After analysing the problem, the developer needs to develop various solutions to solve the given problem. From these solutions, the optimum solution (by experimenting with all the solution) is chosen, which can solve the problem comfortably and economically.

3. Developing Algorithm: After selecting the appropriate solution, algorithm is developed to depict the basic logic of the selected solution. An algorithm depicts the solution in logical steps (sequence of instructions). Further algorithm is represented by flowcharts and pseudo- codes. These tools make program logic clear and they eventually help in coding.

4. Testing the Algorithm for Accuracy: Before converting the algorithms into actual code, it should be checked for accuracy. The main propose of checking algorithm is to identify major logical errors at an early stage, because logical errors are often difficult to detect and correct at later stages. The testing also ensures that the algorithm is the “true” one and it should work for both normal as well as unusual data.

5. Coding: After meeting all the design considerations, the actual coding of the program takes place in the chosen programming language. Depending upon application domain available resources, a program can be written by using computer languages of different levels such as machine, assembly or high level languages.

6. Test and Debug the Program: It is common for the initial program code to contain errors. A program compiler and programmer-designed test data machine tests the code for syntax errors. The results obtained are compared with results calculated manually from this test


Computer Programming and Languages | 3 |

data. Depending upon the complexity of the program, several rounds of testing may be required.

7. Documentation: Once the program is free from all the errors, it is the duty of the program developers to ensure that the program is supported by suitable documentation. These documents should be supplied to the program users. Documenting a program enables the user to operate the program correctly. It also enables other persons to understand the program clearly so that it may, if necessary, be modified, or corrected by someone other than the original programmer.

8. Implementation: After performing all the above mentioned steps, the program is installed on the end user’s machine. In this stage, users are also provided with all the essential documents so that they can understand how the program works. The implementation can be viewed as the final testing because only after using the program, the user can point out the drawbacks, if any, to the developers. Based on the feedback, the programmers can be modify or enhance the program.

9. Maintenance and Enhancement: After the program is implemented, it should be properly maintained taking care of the changing requirements of its users and system. The program should be regularly enhanced by adding additional capabilities. This phase is also concerned with detecting and fixing the errors, which were missed in testing phase. Since this step generates user feedback, the programming cycle continues as the program is modified or reconstructed to meet the changing needs.

Figure 1.2: Program Development Cycle



1.4 Programming ParadigmsPreviously, we have discussed that programming involves many hardships in terms of labour, time and money. Usually a programmer is busy in maintaining an existing application rather than creating a new one. Hence, different types of programming paradigms have been developed in order to minimise the programming efforts. Programming paradigm refers to how a program is written in order to solve a problem. Essentially, it is a way to think about programs and programming. The programming paradigm provides (and determine) the view that the programmer has to the execution of the program.

Broadly, programming can be classified in the following three categories: unstructured programming, structural programming and object oriented programming.

1.4.1 Unstructured Programming Unstructured style programming refers to writing small and simple programs consisting of only one main program. All the actions such as providing input, processing and displaying output are done within one program only. This style of programming is generally restricted for developing a small application but if the application becomes large then it poses real difficulties in terms of clarity of the code, modifiability and ease of use. Although this type of programming style is not recommended, still most programmers learn using this technique.

1.4.2 Structural Programming The programs generated using unstructured approaches are meant for simple and small problems. If the problem gets lengthy, this approach becomes too complex and obscure. After some time, even the programmers themselves may find it difficult to understand their own program. Hence, programming should be performed using a “structured” (organized) approach. Using structural programming, a program is broken down into small independent tasks that are small enough to be understood easily, without having to understand the whole program at once. Each task has its own functionality and performs a specific part of the actual processing. These tasks are developed independently, and each task can carry out the specified task on its own, without the help of any other task. When these tasks are completed they are combined together to solve the problem. In this way, designers map out the large scale structure of a program in terms of smaller operations, implement and test the smaller operations, and then tie them together into a whole program. Structural programming can be performed in two ways:

1. Procedural Programming: This programming has a single program that is divided into small pieces called procedures (also known as functions, routines, subroutines). These procedures are combined into one single location with the help of return statements. From the main or controlling procedure, a procedures call is used to invoke the required procedure. After the sequence is processed, the flow of control continues from where the call was made. The main program coordinates calls to procedures and hands over appropriate data as parameters. The main is processed by the procedures and once the program has finished, the resulting data is displayed.

2. Modular Programming: The programs coded with procedural paradigms usually fits into a single code file and it is meant for relatively smaller programs. However, if the program gets large, then modular way of programming is recommended. In case of modular programming large programs are broken down into a number of smaller program units known as modules.



Each module is designed to perform a specific function. A program, therefore, is divided into several smaller parts that interact through procedure calls and build the whole program.

Program File 1Main Module

Program File 2Module 1



Main Procedures

Procedures 1 Procedures 1 Procedures 1

Figure 1.3: Structural Programming

1.4.3 Object-Oriented Programming Object-oriented programming (abbreviated as OOP) is a style of computer programming, which promotes building of independent pieces of code that interact with each other. It is an evolutionary form of modular programming, with more formal rules. It allows pieces of programming code to be reused and interchanged between programs. In object-oriented programming, programs are organized as cooperative collections of object, each of which represents as instance of some class, and whose classes are all members of a hierarchy of classes united by way of inheritance relationships. In such programs, classes are generally viewed as static, where objects typically have a much a more dynamic nature, which is encouraged by the existence of polymorphism. Object-oriented programming paradigm emphasises on the following aspects:

zz Objects

zz Classes

zz Abstraction

zz Encapsulation

zz Inheritance

zz Polymorphism

Object: Objects are key to understanding object-oriented paradigm. An object is like a ‘black box’ which contains code (sequence of computer instructions) and data (information which are instructions operates on). Traditionally, code and data have been kept apart. For example, in a procedural language like C, units of code are called procedures, while units of data are called structures. Procedures and structures are not formally connected in C. A procedure can operate on more than one type of structure, and more than one procedure can operate on the same structure. As a procedural program grows in size, the network of interaction between procedures and data becomes increasingly complex and hard to manage. However, in object-oriented programming, code and data are merged into a single item-an object. Objects can be combined into structured networks to form a complete program, similar to how the pieces in a puzzle fit together to create a picture. The data in an object specifies its attributes, while the code specifies the actions. For example, a car (object) has attributes like four wheels and five gears, and actions like accelerating and changing gears.

Class: The concept of class is fundamental to the notion of object-oriented programming. A class in an abstraction that captures the common structure and common behaviour of set of objects. It



defines and objects or group of objects and how the objects should behave. In other words, the class is a template or blueprint that defines the characteristics of an object and describes how the object should look and behave. All objects in a given class are identical in form and behaviour but contain different data in their variables. It means that a class does not represent an object; it represents all the information a typical object should have as well as all the methods it should have.

In the real world, there are many objects of the same kind. For example, the car object falls under vehicle class. It has some attributes (gears, wheels) and actions (change gears, apply brakes) that are common with other vehicle objects like bus or truck. However, each vehicle’s attribute is independent and can be different from that of the other one. For example, a car has four wheels while a bus can have six wheels.

Class: Vehicle

Object: Car Object: BusAttribute: 6 Gears

4 WheelsAttribute: 6 Gears

4 Wheels

Attribute:

Action:

Number of GearsNumber of wheelsChanging GearsAcceleration

Figure 1.4: Class and Objects

Abstraction: Abstraction is the ability of a program to ignore some aspects of the information it is manipulating and focusing on the essential elements. According to this principle, a general description of an entire class of objects is defined instead of defining each object individually. For example, we do not think of a car as a set of hundreds of individual parts. Rather, we view a car as an object with its own unique behaviour. This abstraction allows us to drive a car without being bothered by the complexity of the parts involved in making of the car. Hence, we can ignore the details of how the engine and braking system works and focus only on using the object, in the case, driving.

Encapsulation: Previously, we used the ‘black box’ metaphor for explaining the concept of object. A primary rule of object-oriented programming is as the user of an object, one should never need to peek inside the box. The main reason behind it is that objects communicate with each other using messages. Messages define the interface to the object, that is, the only thing an object knows about another object is that it exists. Each object’s attribute and method is ‘encapsulated’ from other objects. This allows the developer to separate and object’s implementation from its behaviour. This separation creates a ‘black box’ effect where the user is isolated from implementation changes. As long as the interface remains the same, any change to the internal implementation is transparent. For example, if the wheel message is sent to the car object, it does not matter to the user how the developer implemented the code to handle this message. All the sending object need is the correct protocol for interacting with the car object. The developer can change the implementation at any time, but the same message would still work because the interface is the same.



Methods Data

Figure 1.5: Encapsulation and Objects

Polymorphism: Polymorphism is the idea of allowing the same code to be used with different types, resulting in more general and abstract implementations. It allows two or more objects to respond to the same message. An analogy of polymorphism in daily life is how students respond to a school bell. When the bell (message) rings, however, it has its own meaning to different students (objects). Some students go home, some go to the library, and some go to other classes. Every student responds to the bell, but their response is different. The sending object does not have to know how the receiving object implements the message. Only the receiving objects worries about that.

Inheritance: Inheritance is the way to extend or change already existing parent class (also known as super class), and make a child class (also known as subclass or derived class) that stays linked with its parent class. It allows a class to have the same behaviour as another class and extend or tailor that behaviour to provide special action for specific needs. The subclass inherits all the existing messages, and therefore, all the behaviour of the original class. This is the key for code-reusability. Programmers do not have to start from scratch when writing a new program. They can simply reuse an existing repertoire of classes that have behaviours similar to what they need in the new program. For example, after creating the class shapes, one might make a subclass called triangle, which defines some triangle-specific messages, like hypotenuse.

Shapes

Ovals Triangles Quadrilaterals

CirclesEquilateralTriangles Squares Rectangles

Figure 1.6: Inheritance



1.5 Characteristics of a Good ProgramEvery computer requires appropriate instruction set (programs) to perform the required task. The quality of the processing depends upon the given instructions. If the instructions are improper or incorrect then it is obvious that the result will also be superfluous. Therefore, proper and correct instructions should be provided to the computer so that it can fulfil its duties appropriately. Hence, a program should be developed in such a way that it ensures proper functionality of the computer. In addition, a program should be written in such a manner that it is easier to underlying logic. A few important characteristics that a computer should posses are:

1. Portability: Portability refers to the ability of an application to run on different platforms (operation systems) with or without minimal changes. Due to rapid development in hardware and the software, nowadays platform change is a common phenomenon. Hence, if a program is developed for a particular platform then the life span of the program is severely affected.

2. Readability: The program should be written in such a way that it makes other programmers or users follow the logic of the program without much effort. If a program is written structurally, it helps the programmers to follows their own program in a better way. Even if some computational efficiency needs to be sacrificed for better readability, it is advisable to use a more user-friendly approach, unless the application’s processing is of utmost importance.

3. Efficiency: Every program requires certain processing time and memory to process the instructions and data. As you must have realised, processing time and memory to process the precious resources of a computer, a program should be laid out in such a manner that it utilises the least amount of memory and processing time.

4. Structural: To develop a program, the task must be broken down into a number of subtasks. These subtasks are developed independently, and each subtask is able to perform the assigned job without the help of any other subtask. If a program is developed structurally, the program not only becomes more readable, but the testing and documentation process also gets easier.

5. Flexibility: A program should be flexible enough to handle most of the changes without having to rewrite the entire program. Most of the programs are developed for a certain period and they require modifications from time to time. For example, in case of payroll management, as the time progresses, some employees may leaves the company while some others may join. Hence, the payroll application should be flexible enough to incorporate all the changes without having to reconstruct the entire application.

6. Generally: Apart from flexibility, the program should also be general. By generality, we mean that if a program is developed for a particular task then it should also be used for all similar tasks of the same domain. For example, if a program is developed for a particular organisation then it should suit all the other similar organizations.

7. Documentation: Documentation is one of the most important components of an application development. Even if a program is developed following the best programming practices, it will be rendered useless if the end user is not able to fully utilise the functionality of the application. A well documented application is also useful for programmers because even in the absence of the author, other programmers can understands it.



1.6 Programming LanguagesPreviously, we discussed that a computer needs to be instructed using computer programs to perform all its tasks, for this, programs are written in special computer languages. A natural language is not used to instruct the computer even though a programming language consists of a set of characters, symbols, and usage rules that allows the user to communicate with computers, just as in natural languages. The main reason behind it is that natural languages (English, Spanish) are ambiguous, vaguely structured, and has very large (and ever changing) vocabularies. Computer languages have relatively few, exactly defined, rules for composition of programs, and strictly controlled vocabularies in which unknown words must be defined before they can be used. A programming language has to follow syntax rules to create an accurate program so that the computer can yield desired results. In case of natural languages, we can understand even while using poor grammar and vocabulary. However, in case of programming language, the rules are very rigid, thus the programmer has to follow all the specified rules.

1.7 Types of Programming Languages Computers understand only one language and that is binary language or the language of 0s and 1s. Binary language is also known as machine or low-level language. In the initial years of computer programming, all the instructions were given in binary form only. Although these programs were easily understood by the computer, it proved too difficult for a normal human being to remember all the instructions in the form of 0s and 1s. Therefore, the computer remained a mystery to a common person until other languages such as assembly and high-level languages were developed which were easier to learn and understand. These languages use commands that have some degree of similarity with English (such as ‘if else’, ‘exit’). Programming languages can be divided into three major categories:

1. Machine Language: It is the native language of computers. It uses only 0s and 1s to represent data and the instructions written in this language, consists of series of 0s and 1s.

2. Assembly Language: It correspondences symbolic instructions and executable machine codes and was created to use letters instead of 0s and 1s to run a machine.

3. High-Level Language: These languages are written using a set of words and symbols following some rules similar to a natural language such as English. The programs written in high-level languages are known as source programs and these programs are converted into machine-readable form by using compilers or interpreters.

NOTE: Together, machine and assembly language are also known as low-level languages.

1.8 Features of a Good Programming LanguageThe features of one programming language may differ from the other. One can be easy and simple while where can be difficult and complex. We judge the success and strength of a programming language with respect to standard features. To begin the language selection process, it is important to establish some criteria for what makes a language good.

1. Ease of use: The language should be easy in writing codes for the programs and executing them. The ease and clarity of a language depends upon its syntax. It should be capable enough to provide clear, simple, and unified set of concepts. The vocabulary of the language



should resemble English (or some other natural language). Symbols, abbreviations, and jargon should be avoided unless they are already known to most people. Any concept that cannot easily be explained to amateurs should not be included in the language. Simplicity helps in the readability of the language. A simple language is easier to grasp and code. Developing and implementing a compiler or interpreter is also easier for simple languages as compared to complex ones.

2. Portability: The language should support the construction of code in a way that it could be distributed across multiple platforms (operating systems). Computer languages should be independent of any particular hardware or operating system, that is, programs written on one platform should perform accurately.

3. Naturalness for application: The language should have a syntax which allows the program structure to show the underlying logical structure of algorithm. A programming language should provide a conceptual framework for thinking through algorithms and means of expressing those algorithms through flowcharts. The advantage of displaying a program in algorithms and flowcharts is that even a novice can understand them easily without leaning any programming language.

4. Reliability: The language should support construction of components that can be expected to perform their intended functions in a satisfactory manner throughout its lifetime. Reliability is concerned with making a system failure free, and thus is concerned with all possible errors. The language should have the support of error detection as well as prevention. It should make some kinds of errors impossible. For example, some errors can be prevented by a strict syntax checking. Apart from prevention, the language should also be able to detect and report errors in the program. For example, errors such as arithmetic overflow and assertions should be detected properly and reported to the programmers immediately so that the error can be rectified. The language should provide reliability by supporting explicit mechanisms for dealing with problems that detected when the system is in operation (exception handling).

5. Safety: It is concerned with the extent to which the language supports the construction of safety critical system, yielding systems that are fault-tolerant, fail-safe, or robust in the face of systemic failures. The system must always do what is expected and be able to recover from any situation that might lead to mishap or actual system hazard. Thus, safety tries to ensure that any failure that results in minor consequence and potentially dangerous failures are handled in a fail-safe fashion. Language can facilitate this through such features as built-in consistency checking and exceptional handling.

6. Performance: By performance, we mean that the language should not only be capable of interacting with the end users, but also with the hardware. The language should also support software engineering mechanism, discouraging or prohibiting poor practices and supporting maintenance activities. Nowadays, the hardware has become very sophisticated and quiet fast. Hence, the application developed using a good language should tap the maximum resources of the available hardware power in terms of speed and memory efficiency.

7. Cost: Cost component is a primary concern before developing a language at the commercial level. It includes several costs such as

zz Program execution and translation cost.zz Program creation, testing and use.zz Program maintenance



8. Promote structural programming: We know that structural programming is the best way to create an application. Hence, a good language should be capable of supporting structural programming. Since, by nature, structural programming facilitate ease in understanding the code, a program is easier to create, debug, and maintain. A structured program also helps programmers to visualize the problem in a logical way, thereby reducing the portability of errors in the code.

9. Compact code: A language should promote compact coding, that is, the intended operations should be coded in a maximum number of lines. Even if the language is powerful, and is not able to perform the tasks in small amount of code, then it is of no use. The main reason behind it is that large code requires more testing and developing time, thereby increasing the cost of developing an application.

10. Maintainability: Creating an application is not the end of the system development. It should be maintained regularly so that it can easily modify to satisfy new requirement or to correct deficiencies. Maintainability is actually facilitated by most of the language, which makes it easier to understand and them change the software. Maintainability is closely linked with the structure of the code. If the original code is written in an organized way (structural programming) then it would be easy to modify or add new changes.

11. Reusability: The language should facilitate the adaptation of code for use in other applications. Code is reusable when it is impendent of other codes. It is very common, for example, to reuse common data structures, such as stacks, queues and trees. When these have been defined with common operations on the structures, these abstract data types are easy to reuse.

12. Provides interface to other language: From the perspective of the language, interface to other language refers to the extent to which the selected language supports interfacing features to other languages. This type of support can have a significant impact on the reliability of the data, which is exchanged between two applications, developed with different languages. In case of data exchange between units of different languages, without specific language support, no checking may be done on the data or even on their existence. Hence, the potential for unreliability becomes high.

13. Concurrency support: Concurrency support refers to the extent to which inherent language supports the construction of code with multiple threads of control (also known as parallel processing). For some applications, multiple threads of control are very useful or even necessary. This is particularly true for real time systems and those running on architecture with multiple processors. Although, concurrency is rarely supported by a language support can make concurrent processing more straightforward and understandable, and it can also provide the programmer with more control over its implementation.

14. Standardisation: Standardisation means the extent to which the language definition has been formally standardised (by recognised bodies such as ANSI and ISO) and the extent to which it can be reasonably expected that this standard will be followed in a language translator. Non standard languages may soon become obsolete, rendering it inferior and difficult to use, producing inferior code, which is difficult to maintain. Lack of appropriate support compromises developer productivity and system quality. It also compromises the ease of development, as well as performance and reliability of the code. If the reliability of the code is compromised, not only will the system perform below expectations, but it will also become much more costly during its lifetime.



X R I EE E SC

1. Explain program development cycle with the help of a block diagram.

2. Programming is the art and science to explain.

3. Discuss the three basic program control structures with suitable examples.

4. Explain the features of a good programming language.

5. Describe the classification of programming languages.

6. State the difference between program and software. Why have documents and documentation become very important?

7. Explain the features of an object oriented programming.

8. What is the difference between inheritance and polymorphism with example?

9. Discus major areas of the application of the programs

10. Write short notes on the following:

zz Objects

zz Encapsulation

zz Modular Programming

zz Programming Paradigms

zz Polymorphism

zz Inheritance


| 13 |

2.1 IntroductionComputers have been used for commercial purposes for the fifty years. Initially, computers were very slow and lacked sophistication. The computational power and sophistication of computers have increased ever since, while their prices have reduced dramatically. The improvements in their speed and reductions in their costs have been the result of several technological breakthroughs which occurred at regular intervals.

The more powerful a computer is the more sophisticated programs it can run. Therefore, with every aspect of improvement in the of computers, software engineers have been tasked to solve larger and more complex problems and that too in cost effective and efficient way. Software engineers have admirably coped with this challenge by innovating and by building upon their past programming experience. All those past innovations and experiences of writing good quality programs in cost-effectives and efficient ways have been systematically organized into a body of knowledge. This knowledge forms the foundation of the software engineering principles. From this point of view, we can say that the discipline of software engineering discusses systematic and cost-effective software development approaches which have come about from past innovations and lessons learnt from mistakes.

Alternatively, we can view software engineering as the engineering approach to develop software. In earlier times, software was simple in nature and hence, software development was a simple activity. However, as technology improved, software became more complex and software projects grew larger. Software development now necessitated the presence of a team, which could prepare detailed plans and designs, carry out testing, develop intuitive user interfaces, and integrate all these activities into a system. This new approach led to the emergence of a discipline known as software engineering. What exactly is an engineering approach to develop software? Let us try to answer this question using an analogy. Suppose you ask a petty contractor to build a small house for you. Petty contractors are not really expert’s in house building. They normally carry out minor repair works and at most undertake very small building works such as the construction of boundary walls, etc. Now faced with the task of building a complete house, your petty contractor would draw upon all the limited knowledge he has of house building. Yet, he would often be left with no clue as to what to do. For example, he might not know the optimal proportion of cement and sand mix to realize sufficient structural strength. In such situations, he would have to fall back upon his intuitions. He would most probably succeed in his work, if the house you asked him to construct was sufficiently small. Even this small house constructed by him would perhaps not look as good as the one constructed by a

Software Engineering

C H

A P

T E

R

2



professional. The house might lack proper planning, display several defects and imperfections. It may even cost more and take longer to build.

Now, suppose you entrust your petty contractor to build a large 50-storeyed commercial complex for you. He might exercise prudence, and politely refuse to undertake your request. On the other hand, he might be ambitious and agree to undertake the task. In the later case, he is sure to fail. The failure might come in several forms: the building might collapse during the construction stage itself due to his ignorance of the theories concerning the strengths of materials; the construction might get unduly delayed, If he does not prepare proper estimations and delayed plans regarding the type and quantity of raw materials required, the times at which these may be required, and so forth. In short, to be successful in constructing a building of large magnitude, one needs a thorough knowledge of civil and architectural engineering techniques such as analysis, estimation, prototyping, planning, designing, testing and so on. Similar things happen in case of software development projects. For sufficiently small sized problems, one might processed according one’s intuition and succeeds. Of course ,the solution might have several imperfections ,cost more ,take longer to complete ,and so forth .But failure is almost certain if one undertakes a large scale-software development work without sound applications of the software engineering principles.

From the building construction analogy, we can say that there exit several fundamental similarities between software engineering and other engineering approaches such as civil engineering. These are characterized by the following aspects:

zz Heavy use of past experiences. The past experiences are systematically arranged and theoretical basis for them are also provided wherever possible. Whenever no reasonable theoretical justification can be provided, the past experiences are adopted as rules of thumb.

zz While designing a system, several conflicting goals might have to be optimized. In such situations, there may not be any unique solution and thus several alternative solutions may be proposed. While selecting an appropriate solution, various trade-offs are considered. To arrive at the final design, several iterations and backtracking may have to be performed.

zz A pragmatic approach to cost-effectiveness is adopted and economic concerns are addressed.

2.2 SoftwareSoftware is defined as a collection of programs, documentation and operating procedures. The Institute of Electrical and Electronic Engineers (IEEE) defines software as a ‘collection of computer programs, procedures, rules and associated documentation and data’. It is responsible for controlling, integrating and managing the hardware components of a computer and to accomplish specific tasks. In other words, software tells the computer what to do and how to do it. For example, software instructs the hardware what to display on the user’s screen, what kinds of input to take from the user, and what kinds of output to generate. Thus, software communicates with the hardware by organizing the control sequences, and the hardware carries out the instructions defined by the software.

A set of programs, which are specifically written to provide the user a precise functionality likes solving a specific problem is termed as a software package. For example, word processing software package provides functionality to the computer so that it can be used to create text documents like letters and mailing lists. Similarly, an image processing software package assists a user in drawing and manipulating graphics.


Software Engineering | 15 |

2.2.1 Software CharacteristicsDifferent individuals judge software on different basis. This is because they are involved with the software in different ways. For example, users want the software to perform according to their requirements. Similarly, developers involved in designing, coding and maintenance of the software evaluate the software by looking at its internal characteristics, before delivering it to the user. Software characteristics are classified into six major components, which are shown in Figure 2.1.

1. Functionality: Refers to the degree of performance of the software against its intended purpose.

2. Reliability: Refers to the ability of the software to provide desired functionality under the given conditions.

3. Usability: Refers to the extent to which the software can be used with ease.

4. Efficiency: Refers to the ability of the software to use system resources in the most effective and efficient manner.

5. Maintainability: Refers to the ease with which the modifications can be made in a software system to extend its functionality, improve its performance, or correct errors.

6. Portability: Refers to the ease with which software developers can transfer software from one platform to another, without (or with minimum) changes. In simple terms, it refers to the ability of software to function properly on different hardware and software platforms making any changes in it.

In addition to the above mentioned characteristics, robustness and integrity are also important. Robustness refers to the degree to which the software can keep on functioning in spite of being provided with invalid data while integrity refers to the degree to which unauthorized access to the software or data can be prevented.

Usability

Functionality

Efficiency

SOFTWARECHARACTERISTICS

Reliability

Maintainability

Portability

Figure 2.1: Software Characteristics

2.2.2 Classification of SoftwareSoftware can be applied in countless fields such as business, education, social sector and other fields. It is designed to suit some specific goals such as data processing, information sharing, communication, and so on. It is classified according to the range of potential of applications. These classifications are listed below.



zz System software: This class of software manages and controls the internal operations of a computer system. It is a group of programs, which is responsible for using computer resources efficiently and effectively. For example, an operating system is system software, which, controls the hardware, manages memory and multitasking functions, and acts as an interface between application programs and the computer.

zz Real-time software: This class of software observes, analyze, and controls real world events as they occur. Generally, a real time system guarantees a response to an external event within a specified period of time. An example of real-time software is the software used for weather forecasting that collects and processes parameters like temperature and humidity from the external environment to forecast the weather. Most of the defence organizations all over the world use real-time software to control their military hardware.

zz Business software: This class of software is widely used in areas where management and control of financial activities is of utmost importance. The fundamental component of a business comprises payroll, inventory, and according software that permit the user to access relevant data from the database. These activities are usually performed with the help of specialized business software that facilities efficient framework in business operations and in management decisions.

zz Engineering and scientific software: This class of software has emerged as a powerful tool in the research and development of next generation technology. Applications such as the study of celestial bodies, under-surface activities, and programming of an orbital path for space shuttles are heavily dependent an engineering scientific software. This software is designed to perform precise calculations on complex numerical data that are obtained during real-time environment.

zz Artificial intelligence (AI) software: This class of software is used where the problem solving technique is non algorithmic in nature. The solutions of such problems are generally non-agreeable to computation or straightforward analysis. Instead, these problems require specific problem-solving strategies that include expert system, pattern recognition, and game playing techniques. In addition, they involve different kinds of search techniques which include the use of heuristics. The role of artificial intelligence software is to add certain degrees of intelligence to the mechanical hardware in order to get the desired work done in an agile manner.

zz Web-based software: This class of software acts as an interface between the user and the internet. Data on the internet is in the form of text, audio, or video format, linked with hyperlinks. Web browser is a software that retrieves web pages from the internet. The software incorporates executable instructions written in special scripting languages such as CGI or ASP. Apart from providing navigation on the web, this software also supports additional features that are useful while surfing the internet.

zz Personal computer software: This class of software used for both official and personal use. The personal computer software market has grown over in the last two decades from normal text editor to word processor and from simple paintbrush to advanced images-editing software. This software is used predominantly in almost every field, whether it is database management system, financial accounting package, or multimedia-based software. It has emerged as a versatile tool for routine applications.



2.2.3 Software MythsThere are number associated with software development community. Some of them really affect the way, in which software development should take place. In this section, we list few myths, and discuss their applicability to standard software development [PIER99, LEVE95].

1. Software is easy to change: It is true source code files are easy to edit, but that is quite different than saying that software is easy to change. This is deceptive because source code is so easy to alter. But making changes without introducing errors is extremely difficult, particularly in organizations with poor process maturity. Every change requires that the complete system be re-verified. If we do not take proper care, this will be an extremely tedious and expensive process.

2. Computers provide greater reliability than the devices they replace: It is true that software does not fail in the traditional sense. There are no limits to how many times a given piece of code can be executed before it “wears out”. In any event, the simple expression of this myth is that our general ledgers are still not perfectly accurate, even though they have been computerized. Back in the days of manual accounting systems, human error was a fact of life. Now, we have software error as well.

3. Testing software or ‘proving’ software correct can remove all the errors: Testing can only show the presence of errors. It cannot show the absence of errors. Our aim is to design effective test cases in order to find maximum possible errors. The more we test, the more we are confident about our design.

4. Reusing software increases safety: This myth is particularly troubling because of the false sense of security that codes re-use can create. Code re-use is a very powerful tool that can yield dramatic improvement in development efficiency, but it still requires analysis to determine its suitability and testing to determine if it works.

5. Software can work right the first time: If we go to an aeronautical engineer, and ask him to build a jet fighter craft, he will quote us a price. If we demand that it is to be put in production without building a prototype, he will laugh and may refuse the job. Yet, software engineers are often asked to do precisely this sort of work, and often accept the job.

6. Software can be designed thoroughly enough to avoid most integration problems: There is an old saying among software designers: “Too bad, there is no compiler for specifications”. These points out the fundamental difficulty with detailed specifications. They always have inconsistencies, and there is no computer tool to perform consistency checks on these. Therefore, special care is required to understand the specifications, and if there is an ambiguity, that should be resolved before proceeding for design.

7. Software with more features is better software: This is, of course, almost the opposite of the truth. The best, most enduring programs are those which do one thing well.

8. Addition of more software engineers will make up the delay: This is not true in most of the cases. By the process of adding more software engineers during the project, we may further delay the project. This does not serve any purpose here, although this may be true for any civil engineering work.

9. Aim is to develop working programs: The aim has been shifted from developing working programs to good quality, maintainable programs. Maintaining software has become a very critical and crucial area for software engineering community.



This list is endless. These myths, poor quality of software, increasing cost and delay in the delivery of the software have been the driving forces behind the emergence of software engineering as a discipline. In addition, following are the contributing factors:

zz Change in ratio of hardware to software costs

zz Increasing importance of maintenance

zz Advances in software techniques

zz Increased demand for software

zz Demand for larger and more complex software systems

2.3 The Software Engineering Discipline Evolution and impactIn this section, we briefly review how the software engineering discipline has slowly come into existence, starting with a humble beginning about five decades ago. We also point out that in spite of all shortcomings of this discipline; it is the best bet to apply for a solution to the software crisis.

2.3.1 Evolution of an Art to an Engineering Discipline Software engineering principles have evolved over the past fifty years with contributions from numerous researches and software professionals. The early programmers used an exploratory programming style. In an exploratory programming style, every programmer himself evolves his own software development techniques solely guided by his intuition, experience, whims, and fancies. The exploratory style of writing programs is also the one that is normally adopted by all students who do not have exposure to software engineering principles. We can consider the exploratory development style as an art-since, art is mostly guided by intuition. There are many stories about programmers in the past who were like proficient artists and could write good programs based on some esoteric knowledge. In modern software industry, programmers rarely make use of such esoteric knowledge. If we analyze the evolution of software development style over the past fifty years, we would see that it has changed from an esoteric art form to craft form, and has slowly emerged as an engineering discipline. As a matter of fact, this growth pattern is not very different from that of any other engineering discipline. Irrespective of the area involved, evolution of technology has followed strikingly similar patterns. A schematic representation of this technology development pattern is shown in Figure 2.2.

Example, let us consider the evolution of iron making technology. In ancient times, very few people knew about iron making. Those who knew about it, kept it a closely-guarded secret. This esoteric knowledge used to get transferred from generation to generation as a family secret. Slowly, technology graduated

Ratio ofhardware

cost tosoftware

cost

1960 Year 2000Figure 2.2: Technology development with time



from art to craft form, where tradesmen shared their knowledge with their apprentices and the knowledge pool continued to grow. Much later, through a systematic organization of knowledge, and incorporation of scientific basis, modern steel-making technology has evolved.

Critics point out that many of the methodologies and guidelines provided by the software engineering discipline lack scientific basis, are subjective, and are often inadequate. Yet, there is no denying the fact adopting software engineering technique facilities development of high quality software in a cost effective and efficient manner. Software engineering practices have proven to be indispensable to the development of large software products-through exploratory styles can often be successfully used to develop small programs.

2.3.2 A Solution to the Software CrisisSoftware engineering appears to be among the few options available to tackle the present software crisis. What exactly is the present software crisis? To explain the present software crisis in simple words, consider the following. The expenses that organizations all around the world are incurring on software purchases compared to those on hardware purchases have been showing a worrying trend over the years (see Figure 2.3).

Organizations are spending larger and larger portions of their budget on software. Not only are the software products turning out to be more expensive than hardware, but they also present a host of other problems to the customers: software products are difficult to alter, debug, and enhance; use resources non-optimally; often fail to meet the user requirements; are far from being reliable; frequently crash; and are often delivered late. Among these, the increasing trend in software costs is probably the most important symptom of the present software crisis. If this trend continues, we might soon have a rather amusing scenario. Not long ago, when you bought any hardware products, the essential software that ran on it came free with it. But, unless some sort of a revolution happens, in not very distant future, hardware prices would become insignificant compared to software prices-when you buy any software product the hardware on which the software runs would come free with the software!!! But, what factors have contributed to the making of the present software crisis? Apparently, there are many factors: larger problem sizes, lack of adequate training in software engineering, increasing skill shortage, and low productivity improvements. What is the remedy? It is believed that the only satisfactory solution to the present software crisis can possibly come from a spread of software engineering practices among the engineers, coupled with further advancements in the software engineering discipline itself.

With this brief introduction to the evolution and impact of software engineering, we now examine the difference between programs and software products.

Ratio ofhardware

cost tosoftware

cost

1960 Year 2000Figure 2.3: Changes in the relative cost of hardware and software

over time.



2.3.3 Programs Vs Software Products Programs are developed by individuals for their personal use. They are, therefore, small in size and have limited functionality. Further, since the author of a program himself uses and maintains his programs, these usually lack good user-interface and proper documentation. For example, the programs developed by a student as part of his class assignments are programs and not software products. On the other hand, software products have multiple users and, therefore, have good user-interface, proper users, manuals, and good documentation support. Since, a software product has a large number of users; it is systematically designed, carefully implemented, and thoroughly tested. In addition, a software product consists not only of the program code but also of all associated documents such as the requirements specification document the design document, the test document, the users manuals, and so on. A further difference is that the software products often are too large to be developed by any individual. A software product is usually developed by a group of engineers working in a team.

We will distinguish between software engineers who develop software products and programmers who write programs. Since a group of software engineers usually work together in a team to develop a software product, it is necessary for them to adopt some systematic development methodology. Otherwise, they would find it very difficult to interface each other’s work, produce a coherent set of documents, and understand each other’s work.

Even though software engineering principles are indented primarily for use in the development of software products, many results of software engineering are appropriate for development of small programs as well. However, when developing small programs for personal use, rigid adherence to software engineering principles in often worthwhile. An ant can be killed using a gun, but it would be ridiculously inefficient and inappropriate. CAR Hoare [1994] has rightly observed that using software engineering principles to develop toy programs is very much like employing civil and architectural engineering principles to build sand castle for children to play.

2.4 Why Study Software Engineering Let us examine the skills you could be acquiring from a study of the software engineering principles. Possibly the most important skill you could be acquiring is the skill for developing large software products. We have seen that the exploratory program development style comes naturally to everybody, but is suitable for development of small programs only. The exploratory development approach breaks down when the size of the program increases. But, what are the reasons behind the exploratory style breaking down with increase in product size? A major part of the problem lies in the exponential growth in the perceived complexity and difficulty with program size if one attempts to write the program for a problem without suitable decomposing the problem. Consequently, the time and effort required to develop a software product also grow exponentially if you are trying to develop it without decomposing it (see Figure 2.4).

(But, why does the program development difficulty increase exponentially with the program size?) Unless we know how to decompose a problem into a set of smaller and independent parts, we would be overwhelmed by the problem. In fact, a major emphasis of every software design technique concerns how to effectively decompose a large problem into manageable parts. We would learn in this text that suitable problem decomposition to handle complexity is the essence of any good software design technique. Handling complexity in a software development problem is a central theme of the software engineering discipline. You would learn that abstraction and decomposition are two well


dr. (prof). rajendra prasad mahapatra - …khannabooks.com/image/catalog/file/95940-pages from...

Documents