software engineering - jaipur national universityjnujprdistance.com/assets/lms/lms jnu/mca/sem...

Software Engineering

Board of Studies

Prof. H. N. Verma Prof. M. K. GhadoliyaVice- Chancellor Director, Jaipur National University, Jaipur School of Distance Education and Learning Jaipur National University, JaipurDr. Rajendra Takale Prof. and Head AcademicsSBPIM, Pune

___________________________________________________________________________________________

Subject Expert Panel

Dr. Ramchandra G. Pawar Ashwini PanditDirector, SIBACA, Lonavala Subject Matter ExpertPune

___________________________________________________________________________________________

Content Review Panel

Gaurav Modi Shubhada PawarSubject Matter Expert Subject Matter Expert

___________________________________________________________________________________________Copyright ©

This book contains the course content for Software Engineering.

First Edition 2013

Printed byUniversal Training Solutions Private Limited

Address05th Floor, I-Space, Bavdhan, Pune 411021.

All rights reserved. This book or any portion thereof may not, in any form or by any means including electronic or mechanical or photocopying or recording, be reproduced or distributed or transmitted or stored in a retrieval system or be broadcasted or transmitted.

___________________________________________________________________________________________

I

Index

ContentI. ...................................................................... II

List of FiguresII. ........................................................... V

List of TablesIII. ...........................................................VI

AbbreviationsIV. ....................................................... VII

ApplicationV. ............................................................. 124

BibliographyVI. ......................................................... 136

Self Assessment AnswersVII. ................................... 139

Book at a Glance

II

Contents

Chapter I ....................................................................................................................................................... 1Introduction to Software Engineering ....................................................................................................... 1Aim ................................................................................................................................................................ 1Objective ........................................................................................................................................................ 1Learning outcome .......................................................................................................................................... 11.1 The Problem Domain ............................................................................................................................... 2 1.1.1 Industrial Strength Software .................................................................................................... 2 1.1.2 Software: Late and Unreliable ................................................................................................. 2 1.1.3 Software: Maintenance and Rework ........................................................................................ 31.2 Software Engineering Challenges ............................................................................................................ 4 1.2.1 Scale ......................................................................................................................................... 5 1.2.2 Quality and Productivity .......................................................................................................... 6 1.2.3 Consistency and Repeatability ................................................................................................. 6 1.2.4 Change ..................................................................................................................................... 71.3 Software Engineering Approach .............................................................................................................. 7 1.3.1 Phased Development Process .................................................................................................. 8 1.3.2 Managing the Process .............................................................................................................. 8 1.3.2.1 Requirement Analysis ............................................................................................... 8 1.3.2.2 Software Design ........................................................................................................ 8 1.3.2.3 Coding ....................................................................................................................... 8 1.3.2.4 Testing ....................................................................................................................... 9Summary ..................................................................................................................................................... 10References ................................................................................................................................................... 10Recommended Reading ..............................................................................................................................11Self Assessment .......................................................................................................................................... 12

Chapter II ................................................................................................................................................... 14Software Process ........................................................................................................................................ 14Aim .............................................................................................................................................................. 14Objectives .................................................................................................................................................... 14Learning outcome ........................................................................................................................................ 142.1 Introduction to Software Process ........................................................................................................... 152.2 Software Process Model ........................................................................................................................ 17 2.2.1 Linear Sequential Model ........................................................................................................ 18 2.2.2 Prototyping Model ................................................................................................................. 202.3 RAD Model ............................................................................................................................................ 202.4 Evolutionary Software Process Model ................................................................................................... 22 2.4.1 The Incremental Model .......................................................................................................... 22 2.4.2 The Spiral Model ................................................................................................................... 24 2.4.3 The Concurrent Development Model .................................................................................... 262.5 Component Based Model ....................................................................................................................... 272.6 Process Technology ................................................................................................................................ 29Summary .................................................................................................................................................... 30References ................................................................................................................................................... 30Recommended Reading ............................................................................................................................. 31Self Assessment ........................................................................................................................................... 32

Chapter III .................................................................................................................................................. 34Software Development Life Cycle ............................................................................................................ 34Aim .............................................................................................................................................................. 34Objectives .................................................................................................................................................... 34Learning outcome ........................................................................................................................................ 343.1 Introduction to Software Development Life Cycle ................................................................................ 35

III

3.2 Requirement Analysis ............................................................................................................................ 353.3 Feasibility Study .................................................................................................................................... 363.4 Coding .................................................................................................................................................... 363.5 Testing .................................................................................................................................................... 363.6 Integration and Testing ........................................................................................................................... 373.7 Maintenance ........................................................................................................................................... 383.8 Systems Analysis and Design ................................................................................................................ 40Summary .................................................................................................................................................... 41References ................................................................................................................................................... 41Recommended Reading ............................................................................................................................. 42Self Assessment ........................................................................................................................................... 43

Chapter IV .................................................................................................................................................. 45Software Requirement Specification ........................................................................................................ 45Aim .............................................................................................................................................................. 45Objectives .................................................................................................................................................... 45Learning outcome ........................................................................................................................................ 454.1 Waterfall Model ..................................................................................................................................... 464.2 Prototyping Model ................................................................................................................................. 484.3 Iterative Model ....................................................................................................................................... 494.4 Spiral Model ........................................................................................................................................... 504.5 Role of Management in Software Development .................................................................................... 534.6 Problem Analysis ................................................................................................................................... 544.7 Requirement Specification ..................................................................................................................... 56Summary .................................................................................................................................................... 59References ................................................................................................................................................... 59Recommended Reading ............................................................................................................................. 60Self Assessment ........................................................................................................................................... 61

Chapter V .................................................................................................................................................... 63System Design ............................................................................................................................................. 63Aim .............................................................................................................................................................. 63Objectives .................................................................................................................................................... 63Learning outcome ........................................................................................................................................ 635.1 Problem Partitioning .............................................................................................................................. 645.2 Abstraction ............................................................................................................................................. 645.3 Top-Down and Bottom-Up Design ........................................................................................................ 655.4 Structured Approach .............................................................................................................................. 665.5 Function v/s Object Oriented Approach ................................................................................................ 675.6 Design Specification and Verification.................................................................................................... 68Summary .................................................................................................................................................... 70References ................................................................................................................................................... 70Recommended Reading ............................................................................................................................. 71Self Assessment ........................................................................................................................................... 72

Chapter VI .................................................................................................................................................. 74Coding ......................................................................................................................................................... 74Aim .............................................................................................................................................................. 74Objectives .................................................................................................................................................... 74Learning outcome ........................................................................................................................................ 746.1 Top-Down and Bottom Up Approach .................................................................................................... 756.2 Structured Programming ........................................................................................................................ 756.3 Information Hiding ................................................................................................................................ 766.4 Programming Style ................................................................................................................................ 776.5 Internal Documentation ......................................................................................................................... 80

IV

Summary .................................................................................................................................................... 82References ................................................................................................................................................... 82Recommended Reading ............................................................................................................................. 83Self Assessment .......................................................................................................................................... 84

Chapter VII ................................................................................................................................................ 86Testing ......................................................................................................................................................... 86Aim .............................................................................................................................................................. 86Objectives .................................................................................................................................................... 86Learning outcome ........................................................................................................................................ 867.1 Levels of Testing .................................................................................................................................... 87 7.1.1 Functional Testing .................................................................................................................. 87 7.1.2 Structural Testing ................................................................................................................... 88 7.1.3 Test Plan ................................................................................................................................. 93 7.1.4 Test Cases Specifications ....................................................................................................... 96 7.1.5 Reliability Assessment ........................................................................................................... 98Summary .................................................................................................................................................. 101References ................................................................................................................................................. 101Recommended Reading ........................................................................................................................... 101Self Assessment ........................................................................................................................................ 102

Chapter VIII ............................................................................................................................................. 104Software Project Management .............................................................................................................. 104Aim ............................................................................................................................................................ 104Objectives .................................................................................................................................................. 104Learning outcome ...................................................................................................................................... 1048.1 Cost Estimation .................................................................................................................................... 1058.2 Project Scheduling ............................................................................................................................... 1078.3 Staffing ................................................................................................................................................. 109 8.3.1 Benefits and drawbacks of IT staffing: ................................................................................1108.4 Software Configuration Management ...................................................................................................1128.5 Quality Assurance .................................................................................................................................1148.6 Project Monitoring ................................................................................................................................1158.7 Risk Management .................................................................................................................................116Summary .................................................................................................................................................. 121References ................................................................................................................................................. 121Recommended Reading ........................................................................................................................... 121Self Assessment ......................................................................................................................................... 122

V

List of Figures

Fig. 1.1 Hardware-software cost trend ........................................................................................................... 3Fig. 1.2 Basic problem ................................................................................................................................... 4Fig. 1.3 The problem of scale ........................................................................................................................ 5Fig. 1.4 Software quality attributes ................................................................................................................ 6Fig. 1.5 The iron triangle ............................................................................................................................... 7Fig. 2.1 Software process ............................................................................................................................. 15Fig. 2.2 Phases of a problem solving loop [RAC95] ................................................................................... 17Fig. 2.3 Phases within phases of the problem solving loop [RAC95] ......................................................... 18Fig. 2.4 Linear sequential model .................................................................................................................. 19Fig. 2.5 RAD model ..................................................................................................................................... 21Fig. 2.6 Incremental model .......................................................................................................................... 23Fig. 2.7 A typical spiral model .................................................................................................................... 24Fig. 2.8 One element of the concurrent process model ................................................................................ 26Fig. 2.9 Component based development ...................................................................................................... 28Fig. 3.1 Analysis as a bridge between system engineering and software design ......................................... 35Fig. 3.2 Integration and test stage ................................................................................................................ 37Fig. 4.1 Waterfall model ............................................................................................................................. 46Fig. 4.2 Prototyping model .......................................................................................................................... 48Fig. 4.3 The iterative enhancement model ................................................................................................... 49Fig. 4.4 Spiral life cycle model ................................................................................................................... 51Fig. 4.5 Factors of management dependency ............................................................................................... 53Fig. 4.6 Context diagram for the restaurant ................................................................................................. 55Fig. 7.1 Software verification vs software validation testing ..................................................................... 89Fig. 7.2 Configuration for a structural unit test .......................................................................................... 90Fig. 7.3 Incremental integration structural testing ...................................................................................... 92Fig. 7.4 Test plan .......................................................................................................................................... 93Fig. 7.5 Effective testing window ............................................................................................................... 97Fig. 7.6 Reliability measurement process .................................................................................................... 99Fig. 8.1 Filled-in estimation form .............................................................................................................. 106Fig. 8.2 Initial estimates ............................................................................................................................. 107Fig. 8.3 Identify dependencies ................................................................................................................... 108Fig. 8.4 Create the schedule ....................................................................................................................... 109Fig. 8.5 Software engineering institute ......................................................................................................114Fig. 8.6 Project monitoring .........................................................................................................................116Fig. 8.7 Risk management process .............................................................................................................117

VI

List of Tables

Table 8.1 Possible software risks ................................................................................................................117Table 8.2 Types of risk ...............................................................................................................................118Table 8.3 Risk analysis ..............................................................................................................................119Table 8.4 Risk management strategies ........................................................................................................119Table 8.5 Risk factors ................................................................................................................................ 120

VII

Abbreviations

CA - Configuration AuthenticationCBD - Component-Based DevelopmentCI - Configurable ItemCMM - Capability Maturity ModelCOIs/CTIs - Critical Operational and/or Technical IssuesCVS - Concurrent Versions System DFD - Data Flow DiagramFDA - Food and Drug AdministrationIT - Information Technology IUT - Implementation Under TestKLOC - Kilo Lines of CodeKPA - Key Process AreasOO - Object Oriented OOD - Object Oriented Design OS - Operating System Q&P - Quality and ProductivityQSM - Quantitative Software ManagementRAD - Rapid Application DevelopmentRCS - Revision Control System SCCS - Source Code Control System SDM - Structured Design MethodologySEI - Software Engineering InstituteSRS - Software Requirements SpecificationUML - Unified Modeling LanguageWBS - Work Breakdown Structure

1

Chapter I

Introduction to Software Engineering

Aim

The aim of this chapter is to:

explain the concept of problem domain•

explicate the software engineering challenges•

describe software engineering approach•

Objective

The objectives of this chapter are to:

determine the steps taken towards software engineering challenges•

explain the changes arising in software engineering•

elucidate the scale required for the software development•

Learning outcome

At the end of this chapter, you will be able to:

evaluate quality of software development•

determine consistency in a software•

understand the effect of repeatability of software engineering•


2

1.1 The Problem DomainIn software engineering there is nothing to deal with programs which are developed by people to exemplify something. Instead the problem area is the software that solves some problem of required users where larger systems or businesses may depend on the software, and where problems in the software can lead to major direct or indirect loss.

1.1.1 Industrial Strength SoftwareA student system is primarily meant for demonstration purposes; it is generally not used for solving any real problem of any organisation. The software is generally not designed with quality issues like:

portability•robustness •reliability•usability •

An industrial strength software system is built to solve some problems of a client and is used by the client’s organisation for operating some part of business. In other words, important activities depend on the correct functioning of the system.Amalfunctionofsuchasystemcanhavehugeimpactintermsoffinancialorbusinessloss,inconvenienceto users, or loss of property and life.

The software system needs to be of high quality with respect to properties like dependability• reliability• user-friendliness•

Industrial strength software has other properties which do not exist in student software systems. Typically, for the same problem, the detailed requirements of what the software should do increase considerably. Besides quality requirements, there are requirements of

backup and recovery•fault tolerance•following of standards•portability•

The size of the industrial strength software system may be two times or more than the student system for the same problem.

Forexample,ifone-fifthofproductivity,andanincreaseinsizebyafactoroftwoforthesameproblem,anindustrialstrength software system will take about 10 times. The thumb rule says that industrial strength software may cost about 10 times the student software. The software industry is largely interested in developing industrial strength software, and the area of software engineering focuses on how to build such systems. The discipline dealing with the development of software should not deal only with developing programs, but with developing all the things that constitute software.

1.1.2 Software: Late and UnreliableRegardlessofsignificantprogressintechniquesfordevelopingsoftware,softwaredevelopmentremainsaweakarea.Inasurveyofover600firms,morethan35%reportedhavingsomecomputer-relateddevelopmentprojectthat they categorised as a runaway. A fugitive is not a project that is somewhat late or somewhat over budget. It is one where the budget and schedule are out of control. The problem has become so rigorous that it has spawned an industry of its own; there are consultancy companies that advise how to rein such projects.

3

Forexample,inadefencesurvey,itwasreportedthatmorethan70%ofalltheequipmentfailureswereduetosoftware. And this is in systems that are loaded with electrical, hydraulic, and mechanical systems. This just indicates that all other engineering disciplines have advanced far more than software engineering, and a system comprising theproductsofvariousengineeringdisciplinesfindsthatsoftwareistheweakestcomponent.Manybankshavelostmillions of dollars due to factual error and other problems in their software. In software, failures occur owing to bugs or errors that get introduced during the design and development process. Hence, even though a software system may fail after operating correctly for some time, the bug that causes that failure was there from the start.

1.1.3 Software: Maintenance and ReworkOnce the software is delivered and deployed, it enters the maintenance phase. Software needs to be maintained not because some of its components wear out and need to be replaced, but because there are often some enduring errors remaining in the system that must be removed as they are revealed. The errors, once discovered, need to be removed, leading to the software being changed. This is sometimes called corrective maintenance. Even without bugs, software frequently experience change. The main reason is that software often must be upgraded and improved toincludemorefeaturesandprovidemoreservices.Thisalsorequiresmodificationofthesoftware.Onceasoftwaresystem is deployed, the environment in which it operates changes. Hence, the needs that commence the software developmentalsochangetoreflecttheneedsofthenewenvironment.Hence,thesoftwaremustadapttotheneedsof the changed environment. The changed software then changes the environment, which in turn requires further change. This phenomenon is sometimes called the law of software evolution. Maintenance due to this phenomenon is sometimes called adaptive maintenance.

For example if we consider the total life of software, the cost of maintenance generally exceeds the cost of developing the software. The maintenance-to-development-cost ratio has been variously suggested as 80:20, 70:30, or 60:40. Figure below also shows how the maintenance costs are increasing:

100

80 Hardware Software Development

Software Maintenance

60

40

20

1955 1970 1985

Fig. 1.1 Hardware-software cost trend


4

Maintenance work is based on existing software. Understanding the software involves understanding not only the codebutalsotherelateddocuments.Duringthemodificationofthesoftware,theeffectsofthechangehavetobeclearlyunderstoodbythemaintainerbecauseintroducingundesiredsideeffectsinthesystemduringmodificationis easy. Thus, maintenance involves

understanding the existing software•understanding the effects of change•making changes to both the code •making changes to the documents•

Maintenance is one form of change that typically is done after the software development is completed and the software has been deployed. Changing requirements and associated rework are a major problem of the software industry. Itisestimatedthatreworkcostsare30to40%ofthedevelopmentcost.Inotherwords,ofthetotaldevelopmenteffort,reworkduetovariouschangesconsumesaround30to40%oftheeffort.Theproblemofreworkandchangeisnotjustareflectionofthestateofsoftwaredevelopment,aschangesarefrequentlyinitiatedbyclientsastheirneeds change.

1.2 Software Engineering ChallengesSoftware engineering is defined as the systematic approach to the development, operation,maintenance, andretirement of software. The use of the term “systematic approach” for the development of software implies that methodologies are used for developing software which is repeatable. If the methodologies are applied by different groups of people, similar software will be produced. In essence, the goal of software engineering is to take software development closer to science and engineering and away from ad-hoc approaches for development whose outcomes are not predictable but which have been used heavily in the past and still continue to be used for developing software. Industrial strength software is meant to solve some problem of the client. The problem therefore is to systematically develop software to satisfy the needs of some users or clients. This fundamental problem that software engineering dealswithisshowninthefigurebelow.

Lessthan5%

Morethan95%

Used with changes

Used with changes

Major Rework Req’d

Delivered But Unusable

Paid for But Not Delivered

Required changes or was unusable

Fig. 1.2 Basic problem(Source: http://t3.gstatic.com/images?q=tbn:ANd9GcTVy7DXXzueaOrI8HKS4V3akhJMHi8zxMB54qnscD5Lv

BTNItVD)

5

Though the basic problem is to systematically develop software to satisfy the client, there are some factors which affect the approaches selected to solve the problem. These factors are the primary forces that drive the progress and developmentinthefieldofsoftwareengineering.

1.2.1 ScaleA fundamental factor that software engineering must deal with is the issue of scale. Development of a very large system requires a very different set of methods compared to developing a small system. The methods that are used for developing small systems generally do not scale up to large systems. For example, consider the problem of counting people in a room versus taking a census of a country. Both are essentially counting problems. But the methods used for counting people in a room will just not work when taking a census. Different set of methods will have to be used for conducting a census, and the census problem will require considerably more management, organisation, and validation, in addition to counting. Methods that one can use to develop programs of a few hundred lines cannot be expected to work when software of a few hundred thousand lines needs to be developed. A different set of methods must be used for developing large software. Any large project involves the use of engineering and project management. In small projects, informal methods for development and management can be used. However, forlargeprojects,bothhavetobemuchmoreformal,asshowninthefigurebelow.

Small projects

Formal

Formal

Large Complex Projects

Development Methods

Proj

ect M

anag

emen

t

Informal

Informal

Fig. 1.3 The problem of scale

When dealing with a small software project, the engineering capability required is low and the project management requirement is also low. However, when the scale changes to large, to solve such problems properly, it is essential that we move in both directions. The engineering methods used for development need to be more formal, and the project management for the development project also needs to be more formal. There is no universally acceptable definitionofwhata“small”projectisandwhatisa“large”project,andthescalesareclearlychangingwithtime.However, we can use the order of magnitudes and say that a project is small if its size is less than 10 KLOC, medium if the size is less than 100 KLOC. large if the size is less than one million LOC, and very large if the size is many million LOC.


6

1.2.2 Quality and ProductivityAn engineering discipline is driven by practical parameters of cost, schedule, and quality. A solution that takes enormous resources and many years may not be acceptable. Similarly, a poor-quality solution, even at low cost, may not be of much use. Like all engineering disciplines, software engineering is driven by three major factors: cost, schedule, and quality. The cost of developing a system is the cost of resources used for the system, which, in case of software, is dominated by manpower cost, as development is largely labour-intensive. Schedule is an important factor in many projects. Business trends are dictating that time to market of a product should be reduced; that is, the cycle time from concept to delivery should be small. Productivity in terms of output per person-month can adequately capture both cost and schedule concerns. If productivity is higher, it should be clear that the cost in terms of person-months will be lower. Similarly, if productivity is higher, the potential of developing the software inshortertimeimprovesateamofhigherproductivitywillfinishajobinlessertimethanasame-sizeteamwithlower productivity. Productivity is a key driving factor in all businesses and desire for high productivity dictates, to a large extent, how things are done. According to the quality model adopted by this standard, software quality comprisesofsixmainattributesasshowninfig.1.4.

Software Quality

Functionality Reliability Usability Efficiency Maintainability Portability

Fig. 1.4 Software quality attributes

These six attributes have detailed characteristics which are considered the basic ones and which can and should bemeasuredusingsuitablemetrics.At the top level, forasoftwareproduct, theseattributescanbedefinedasfollows:

Functionality - The capability to provide functions which meet stated and implied needs when the software is •used.Reliability-Thecapabilitytomaintainaspecifiedlevelofperformance.•Usability- The capability to be understood, learned, and used.•Efficiency-Thecapabilitytoprovideappropriateperformancerelativetotheamountofresourcesused.•Maintainability -The capability to bemodified for purposes ofmaking corrections, improvements, or•adaptation.Portability-Thecapabilitytobeadaptedfordifferentspecifiedenvironmentswithoutapplyingactionsormeans•other than those provided for this purpose in the product.

There are two important consequences of having multiple dimensions to quality. First, software quality cannot be reducedtoasinglenumber.Andsecond,theconceptofqualityisproject-specific.Foreachsoftwaredevelopmentproject,aqualityobjectivemustbespecifiedbeforethedevelopmentstarts,andthegoalofthedevelopmentprocessshould be to satisfy that quality objective. Despite the fact that there are many quality factors, reliability is generally accepted to be the main quality criterion.

1.2.3 Consistency and RepeatabilityA key challenge that software engineering faces is how to ensure that successful results can be repeated, and there can be some degree of consistency in quality and productivity. We can say that an organisation that develops one system with high quality and reasonable productivity, but is not able to maintain the quality and productivity levels for other projects, does not know good software engineering. An organisation involved in software development not only wants high quality and productivity, but it wants these consistently. In other words, a software development organisation would like to produce consistent quality software with consistent productivity. Consistency of performance is an

7

important factor for any organisation; it allows an organisation to predict the outcome of a project with reasonable accuracy, and to improve its processes to produce higher-quality products and to improve its productivity. Without consistency,evenestimatingcostforaprojectwillbecomedifficult.Thisrequirementofconsistencywillforcesomestandardised procedures to be followed for developing software. However, within an organisation, consistency is achieved by using its chosen methodologies in a consistent manner. Frameworks like ISO9001 and the Capability Maturity Model (CMM) encourage organisations to standardise methodologies, use them consistently, and improve them based on experience.

1.2.4 ChangeIn today’s world change in business is very rapid. As businesses changes, it requires that the software supporting it also changes. Overall, as the world changes faster, software has to change faster. Rapid change has a special impact on software. As software is easy to change due to its lack of physical properties that may make changing harder, the expectation is much more from software for change. Therefore, one challenge for software engineering is to accommodate and embrace change. Different approaches are used to handle change. But change is a major driver today for software engineering. Approaches that can produce high quality software at high productivity but cannot accept and accommodate change are of little use today.

1.3 Software Engineering ApproachThe view of high quality and productivity (Q&P) is the basic objective which is to be achieved consistently for large scale problems and under the dynamics of changes. The Q&P achieved during a project will clearly depend on many factors, but the three main forces that govern Q&P are the people, processes, and technology, often called theIronTriangle,asshowninthefigurebelow.

Technology People

Process

Quality &

Productivity

Fig. 1.5 The iron triangle

For high Q&P good technology has to be used, good processes or methods have to be used, and the people doing the job have to be properly trained. In software engineering, the focus is primarily on processes. Process is what takesusfromuserneedstothesoftwarethatsatisfiestheneeds.Thebasicapproachofsoftwareengineeringistoseparate the process for developing software from the developed product. The premise is that to a large degree the software process determines the quality of product and productivity achieved. Hence, to tackle the problem domain and successfully face the challenges that software engineering faces, one must focus on the software process. Design of proper software processes and their control then becomes a key goal of software engineering research. Most other computing disciplines focus on some type of product—algorithms, operating systems, databases, etc.—while software engineering focuses on the process for producing the products. It is essentially the software equivalent of “manufacturing engineering.”


8

1.3.1 Phased Development ProcessAdevelopmentprocessconsistsofvariousphases,eachphaseendingwithadefinedoutput.Thephasesareperformedinanorderspecifiedbytheprocessmodelbeingfollowed.Themainreasonforhavingaphasedprocessisthatitbreaks the problem of developing software into successfully performing a set of phases, each handling a different concern of software development. This ensures that the cost of development is lower than what it would have been if the whole problem was tackled together. A phased process allows proper checking for quality and progress at some definedpointsduringthedevelopment.Withoutthis,onewouldhavetowaituntiltheendtoseewhatsoftwarehasbeen produced. Clearly, this will not work for large systems. Hence, for managing the complexity, project tracking, and quality, all the development processes consist of a set of phases. A phased development process is central to the software engineering approach for solving the software crisis.

1.3.2 Managing the ProcessMost organisations that follow a process have their own version. In general, we can say that any problem solving insoftwaremustconsistofrequirementspecificationforunderstandingandclearlystatingtheproblem,designfordeciding a plan for a solution, coding for implementing the planned solution, and testing for verifying the programs. For small problems, these activities may not be done explicitly, the start and end boundaries of these activities may notbeclearlydefined,andnowrittenrecordoftheactivitiesmaybekept.Forlargesystems,eachactivitycanitselfbeextremelycomplex,andmethodologiesandproceduresareneededtoperformthemefficientlyandcorrectly.Though different process models will perform these phases in different manner, they exist in all processes.

1.3.2.1 Requirement AnalysisRequirements analysis is done in order to understand the problem the software system is to solve. The emphasis in requirements analysis is on identifying what is needed from the system, not how the system will achieve its goals. Forcomplexsystems,evendeterminingwhatisneededisadifficulttask.Thegoaloftherequirementsactivityistodocumenttherequirementsinasoftwarerequirementsspecificationdocument.Understandingtherequirementsofasystemthatdoesnotexist isdifficultandrequirescreative thinking.Theproblembecomesmorecomplexbecause an automated system offers possibilities that do not exist otherwise. Once the problem is analysed and the essentialsunderstood,therequirementsmustbespecifiedintherequirementspecificationdocument.Therequirementsdocument must specify all functional and performance requirements; the formats of inputs and outputs; and all design constraints that exist due to political, economic, environmental, and security reasons. A preliminary user manual that describes all the major user interfaces frequently forms a part of the requirements document.

1.3.2.2 Software DesignThepurposeofthedesignphaseistoplanasolutionoftheproblemspecifiedbytherequirementsdocument.Thisphaseisthefirststepinmovingfromtheproblemdomaintothesolutiondomain.Thedesignactivityoftenresultsin three separate outputs architecture: design, high level design, and detailed design. Architecture focuses on looking at a system as a combination of many different components. The high level design identifiesthemodulesthatshouldbe built for developing the system and the specificationsofthesemodules.Indetaileddesign, the internal logic ofeachofthemodulesisspecified.Inarchitecturethefocusisonidentifyingcomponentsorsubsystemsandhowthey connect; in high level design the focus is on identifying the modules; and during detailed design the focus is on designing the logic for each of the modules.

1.3.2.3 CodingThe goal of the coding phase is to translate the design of system into code in a given programming language. The coding phase affects both testing and maintenance profoundly. Well written code can reduce the testing and maintenance effort. During coding the focus should be on developing programs that are easy to read and understand, and not simply on developing programs that are easy to write. Simplicity and clarity should be strived for during the coding phase.

9

1.3.2.4 TestingTesting’s basic function is to detect defects in the software. After coding, computer programs are available that can be executed for testing purposes. This implies that testing not only has to uncover errors introduced during coding, but also errors introduced during the previous phases. The starting point of testing is unit testing, where the different modules or components are tested individually. As modules are integrated into a system, integration testing is performed, which focuses on testing the interconnection between modules. After the system is put together, system testing is performed. Finally, acceptance testing is performed to demonstrate to the client, on the real-life data of theclient,theoperationofthesystem.Thetestingprocessstartswithatestplanthatidentifiesallthetesting-relatedactivitiesthatmustbeperformedandspecifiestheschedule,allocatestheresources,andspecifiesguidelinesfortesting.Duringthetestingoftheunit,specifiedtestcasesareexecutedandtheactualresultiscomparedwiththeexpectedoutput.Thefinaloutputofthetestingphaseisthetestreportandtheerrorreport,orasetofsuchreports.Each test report contains a set of test cases and the result of executing the code with these test cases.


10

SummaryIn software engineering there is nothing to deal with programs that are developed by people to exemplify •something. Instead the problem area is the software that solves some problem of required users where larger systems or businesses may depend on the software, and where problems in the software can lead to major direct or indirect loss.A student system is primarily meant for demonstration purposes; it is generally not used for solving any real •problem of any organisation. An industrial strength software system is built to solve some problem of a client and is used by the client’s •organisation for operating some part of business.Industrial strength software has other properties which do not exist in student software systems.•The size of the industrial strength software system may be two times or more than the student system for the •same problem. Regardlessofsignificantprogressintechniquesfordevelopingsoftware,softwaredevelopmentremainsaweak•area. Once the software is delivered and deployed, it enters the maintenance• phase. Software needs to be maintained not because some of its components wear out and need to be replaced, but because there are often some enduring errors remaining in the system that must be removed as they are revealed.Maintenance work is based on existing software. Understanding the software involves understanding not only •the code but also the related documents.Maintenance is one form of change that typically is done after the software development is completed and the •software has been deployed. Changing requirements and associated rework are major problems of the software industry.Softwareengineering isdefinedasasystematicapproach to thedevelopment,operation,maintenance,and•retirement of software. The use of the term “systematic approach” for the development of software implies that methodologies are used for developing software which is repeatable.A fundamental factor that software engineering must deal with is the issue of scale. Development of a very large •system requires a very different set of methods compared to developing a small system. The methods that are used for developing small systems generally do not scale up to large systems.An engineering discipline is driven by practical parameters of cost, schedule, and quality. A solution that takes •enormous resources and many years may not be acceptable. Similarly, a poor-quality solution, even at low cost, may not be of much use.A key challenge that software engineering faces is how to ensure that successful results can be repeated, and •there can be some degree of consistency in quality and productivity.In today’s world change in business is very rapid. As businesses change, they require that the software supporting •to change. Overall, as the world changes faster, software has to change faster. Rapid change has a special impact on software.The view of high quality and productivity (Q&P) is the basic objective which is to be achieved consistently for •large scale problems under the dynamics of changes.Adevelopmentprocessconsistsofvariousphases,eachphaseendingwithadefinedoutput.•

ReferencesSundar, D., 2010. • Software Engineering, Laxmi Publications, Ltd.Mall, R., 2004. • Fundamentals of Software Engineering, PHI Learning Pvt. Ltd.www.SPMN.com, 2010. • SPMN Focus Team Lessons Learned [Online] Available at: <http://www.spmn.com/lessons.html#eleven> [Accessed 7 November 2011].CSE IIT Kharagpur, • Characteristics of Software Maintenance [Pdf] Available at: <http://nptel.iitm.ac.in/courses/Webcourse-contents/IIT%20Kharagpur/Soft%20Engg/pdf/m14L36.pdf>[Accessed7November2011].

11

Prof. N. L., 2008. • Lecture - 2 Introduction to Software Engineering [Video online] Available at: <http://www.youtube.com/watch?v=AN5I6fFxyfs> [Accessed 7 November 2011].Prof. N. L., 2008. • Lecture - 3 Overview of Phases [Video online] Available at: <http://www.youtube.com/watch?v=nzCufJMc5Xk&feature=relmfu> [Accessed 7 November 2011].

Recommended ReadingSaleh, A. K., 2009. • Software Engineering, J. Ross Publishing.Vliet, V. H., 2000. • Software engineering: principles and practice, 2nd ed., John Wiley.Jawadekar, S. W., 2004. • Software Engineering: Principles and Practice, Tata McGraw-Hill Education.


12

Self Assessment Which phase comes after a software is delivered and deployed?1.

Maintenancea. phaseDevelopment phaseb. Organisation phase c. Dispatch phase d.

_______________istheprocessoffindingerrorandonceitisdiscovered,errorisremoved,leadingittochange2. the software.

Development phasea. Organisation phase b. Dispatch phase c. Corrective maintenanced.

The changed software then changes the environment, which in turn requires further change. This phenomenon 3. is sometimes called the __________________.

law of software evolutiona. organisation phase b. dispatch phase c. corrective maintenanced.

___________isdefinedasasystematicapproachtothedevelopment,operation,maintenance,andretirement4. of software.

Computer engineeringa. Software engineeringb. Electronic engineering c. Design engineering d.

Which of the following statements is true?5. An engineering discipline is driven by practical parameters of cost, schedule, and quality.a. An engineering discipline is driven by practical parameter of planning. b. An engineering discipline is driven by practical parameters of rules. c. An engineering discipline is driven by practical parameter of development. d.

___________ is the capability to provide functions which meet stated and implied needs when the software is 6. used.

Reliability a. Functionalityb. Usabilityc. Efficiencyd.

_____________isthecapabilitytomaintainaspecifiedlevelofperformance.7. Reliability a. Functionalityb. Usabilityc. Efficiencyd.

13

____________ is the capability to be understood, learned, and used.8. Reliability a. Functionalityb. Usabilityc. Efficiencyd.

_________ is the capability to provide appropriate performance relative to the amount of resources used.9. Reliability a. Functionalityb. Usabilityc. Efficiencyd.

_______________is the capability to bemodified for purposes ofmaking corrections, improvements, or10. adaptation.

Maintainabilitya. Functionalityb. Usabilityc. Efficiencyd.


14

Chapter II

Software Process

Aim


explain the concept of software process •

enlist the process maturity levels •

discuss the linear sequential model •

Objectives


explain software process model •

describe software requirement analysis •

discuss prototyping model •

Learning outcome


identify RAD model •

understand data modeling •

describe process modeling •

15

2.1 Introduction to Software ProcessAsoftwareprocesscanbecharacterisedasshowninthefigurebelow.

A commonprocess framework is establishedbydefining a small number of framework activities that are•applicable to all software projects, regardless of their size or complexity. A number of tasks set a collection of software engineering work tasks, project milestones, work products, and •quality assurance points which enable the framework activities to be adapted to the characteristics of the software project and the requirements of the project team. Finally, umbrella activities such as software quality assurance, software configurationmanagement, and•measurement overlay the process model. Umbrella activities are independent of any one framework activity and occur throughout the process.•

Tasks

Milestones, deliverables

SQA points

Task sets

Framework activities

Umbrella activities

Common process framework

Fig. 2.1 Software process

Work products, and quality assurance points enable the framework activities to be adapted to the characteristics •of the software project and the requirements of the project team. Finally, umbrella activities such as software quality assurance, software configurationmanagement, and•measurement overlay the process model. Umbrella activities are independent of any one framework activity and occur throughout the process. There has •beenasignificantemphasison“processmaturity.”The Software Engineering Institute (SEI) has developed a comprehensive model predicated on a set of software •engineering capabilities that should be present as organisations reach different levels of process maturity. To determine an organisation’s current state of process maturity, the SEI uses an assessment that results in a •fivepointgradingscheme.The SEI approach provides a measure of the global effectiveness of a company’s software engineering practices •andestablishesfiveprocessmaturitylevelsthataredefinedinthefollowingmanner:


16

Level 1: InitialThe softwareprocess is characterisedas adhocandoccasionallyevenchaotic.Fewprocesses aredefined, andsuccess depends on individual effort.

Level 2: RepeatableBasic project management processes are established to track cost, schedule, and functionality. The necessary process discipline is in place to repeat earlier successes on projects with similar applications.

Level 3:DefinedThe software process for both management and engineering activities is documented, standardised, and integrated into an organisation wide software process.

Level 4: ManagedDetailed measures of the software process and product quality are collected. Both the software process and products are quantitatively understood and controlled using detailed measures.

Level 5: OptimisingContinuous process improvement is enabled by quantitative feedback from the process and from testing innovative ideas and technologies.

The SEI has associated key process areas (KPAs) with each of the maturity levels. The KPAs describe those software engineering functions (e.g., software project planning, requirements management) that must be present to satisfy good practice at a particular level. Each KPA is described by identifying the following characteristics:

Goals: the overall objectives that the KPA must achieve.•Commitment: requirements (imposed on the organisation) that must be met to achieve the goals or provide proof •of intent to comply with the goals. Abilities: those things that must be in place (organisationally and technically) to enable the organisation to meet •the commitments.Activities:thespecifictasksrequiredtoachievetheKPAfunction.•Methods for monitoring implementation: the manner in which the activities are monitored as they are put into •place.Methodsforverifyingimplementation:themannerinwhichproperpracticefortheKPAcanbeverified.•

EighteenKPAs(eachdescribedusingthesecharacteristics)aredefinedacrossthematuritymodelandmappedintodifferent levels of process maturity. The following KPAs should be achieved at each process maturity level:

Software subcontract management•Software project tracking and oversight•Software project planning•Requirements management•

Process maturity level 3Peer reviews•Intergroup coordination•Software product engineering•Integrated software management•Training program•Organisationprocessdefinition•Organisation process focus•

17

Process maturity level 4Software quality management•Quantitative process management•

Process maturity level 5Process change management•Technology change management•Defect prevention•

EachoftheKPAsisdefinedbyasetofkeypracticesthatcontributetosatisfyingitsgoals.Thekeypracticesarepolicies, procedures, and activities that must occur before a key process area has been fully instituted.

2.2 Software Process ModelTo solve actual problems in an industry setting, a software engineer or a team of engineers must incorporate a development strategy that encompasses the process, methods, and tools layers and the generic phases. This strategy is often referred to as a process model or a software engineering paradigm.

A process model for software engineering is chosen based on the nature of the project and application, the •methods and tools to be used, and the controls and deliverables that are required.

Technicaldevelopment

Solutionintegration

Problemdefinition

Statusquo

Fig. 2.2 Phases of a problem solving loop [RAC95]


18

Statusquo

statusquo

technicaldevelop-

ment

solutionintegration

problemdefinition

statusquo

technicaldevelop-

ment

solutionintegration

problemdefinition

statusquo

technicaldevelop-

ment

solutionintegration

problemdefinition

statusquo

technicaldevelop-

ment

solutionintegration

problemdefinition

statusquo

technicaldevelop-

ment

solutionintegration

problemdefinition

statusquo

Fig. 2.3 Phases within phases of the problem solving loop [RAC95]

All software development can be characterised as a problem solving loop in which four distinct stages are •encountered:statusquo,problemdefinition,technicaldevelopment,andsolutionintegration.Statusquo“represents thecurrentstateofaffairs”;problemdefinition identifies thespecificproblemtobe•solved; technical development solves the problem through the application of some technology, and solution integration delivers the results.

2.2.1 Linear Sequential ModelSometimes called the classic life cycle or the waterfall model, the linear sequential model suggests a systematic, sequential approach to software development that begins at the system level and progresses through analysis, design, coding, testing, and support.

Figure shown below illustrates the linear sequential model for software engineering.•Modelled after a conventional engineering cycle, the linear sequential model encompasses the following •activities: System/information engineering and modeling. Because software is always part of a larger system (or business), work begins by establishing requirements for all system elements and then allocating some subset of these requirements to software. This system view is essential when software must interact with other elements such as hardware, people, and databases. System engineering and analysis encompass requirements gathering at the system level with a small amount •of top level design and analysis.

19

Analysis Design Code Test

System/informationengineering

Fig. 2.4 Linear sequential model

Software requirements analysisTherequirementsgatheringprocessisintensifiedandfocusedspecificallyonsoftware.Tounderstandthenatureofthe program(s) to be built, the software engineer (“analyst”) must understand the information domain.

DesignSoftware design is actually a multistep process that focuses on four distinct attributes of a program:

Data structure•Software architecture•Interface representations•Procedural (algorithmic) details•

Thedesignisdocumentedandbecomespartofthesoftwareconfiguration.

Code generationThe design must be translated into a machine-readable form. The code generation step performs this task.

TestingOnce code has been generated, program testing begins. The testing process focuses on the logical internals of the software, ensuring that all statements have been tested, and on the functional externals; that is, conducting tests to uncovererrorsandensurethatdefinedinputwillproduceactualresultsthatagreewithrequiredresults.

SupportSoftware will undoubtedly undergo change after it is delivered to the customer. Change will occur because errors have been encountered, because the software must be adapted to accommodate changes in its external environment e.g., a change required because of a new operating system or peripheral device, or because the customer requires functional or performance enhancements.

The linear sequential model is the oldest and the most widely used paradigm for software engineering. Among the problems that are sometimes encountered when the linear sequential model is applied are:

Real projects rarely follow the sequential flow that themodel proposes.Although the linearmodel can•accommodate iteration, it does so indirectly. As a result, changes can cause confusion as the project team proceeds.Itisoftendifficultforthecustomertostateallrequirementsexplicitly.Thelinearsequentialmodelrequiresthis•andhasdifficultyaccommodatingthenaturaluncertaintythatexistsatthebeginningofmanyprojects.


20

The customer must have patience. A working version of the program(s) will not be available until late in the •project time-span. A major blunder, if undetected until the working program is reviewed, can be disastrous.

2.2.2 Prototyping ModelAcustomerdefinesasetofgeneralobjectivesforsoftwarebutdoesnotidentifydetailedinput,processing,oroutputrequirements.

Inothercases,thedevelopermaybeunsureoftheefficiencyofanalgorithm,theadaptabilityofanoperating•system, or the form that human/machine interaction should take. In these, and many other situations, a prototyping paradigm may offer the best approach. The prototyping •paradigm begins with requirements gathering. Developerandcustomermeetanddefinetheoverallobjectivesforthesoftware,identifywhateverrequirements•areknown,andoutlineareaswherefurtherdefinitionismandatory.A “quick design” then occurs. The quick design focuses on a representation of those aspects of the software •that will be visible to the customer/user e.g., input approaches and output formats. The quick design leads to the construction of a prototype. The prototype is evaluated by the customer/user and •usedtorefinerequirementsforthesoftwaretobedeveloped.Iteration occurs as the prototype is tuned to satisfy the needs of the customer, while at the same time enabling •the developer to better understand what needs to be done.Ideally, the prototype serves as a mechanism for identifying software requirements.•If a working prototype is built, the developer attempts to use existing program fragments or applies tools e.g., •report generators, window managers that enable working programs to be generated quickly.Theprototypecanserveas“thefirstsystem.”Itistruethatbothcustomersanddevelopersliketheprototyping•paradigm.

Prototyping can also be problematic for the following reasons:The customer sees what appears to be a working version of the software, unaware that the prototype is held •together “with chewing gum and baling wire,” unaware that in the rush to get it working no one has considered overall software quality or long-term maintainability. When informed that the product must be rebuilt so that highlevelsofqualitycanbemaintained,thecustomercriesfoulanddemandsthat“afewfixes”beappliedtomake the prototype a working product.The developer often makes implementation compromises in order to get a prototype working quickly. An •inappropriate operating system or programming language may be used simply because it is available and known; aninefficientalgorithmmaybeimplementedsimplytodemonstratecapability.Although problems can occur, prototyping can be an effective paradigm for software engineering. The key is •todefinetherulesofthegameatthebeginning;thatis,thecustomeranddevelopermustbothagreethattheprototypeisbuilttoserveasamechanismfordefiningrequirements.

2.3 RAD ModelRapid application development (RAD) is an incremental software development process model that emphasises an extremely short development cycle.

The RAD model is a “high-speed” adaptation of the linear sequential model in which rapid development is •achieved by using component-based construction.Used primarily for information systems applications, the RAD approach encompasses following phases:•

21

Business modelingTheinformationflowamongbusinessfunctionsismodelledinawaythatanswersthefollowingquestions:

What information drives the business process? •What information is generated? •Who generates it? •Where does the information go? •Who processes it?•

Data modelingTheinformationflowdefinedaspartofthebusinessmodelingphaseisrefinedintoasetofdataobjectsthatareneededtosupportthebusiness.Thecharacteristics(calledattributes)ofeachobjectareidentifiedandtherelationshipsbetweentheseobjectsdefined.

Team #1

BusinessmodelingBusinessmodeling

Businessmodeling

Datamodeling

BusinessmodelingProcess

modeling

Businessmodeling

Applicationgeneration

BusinessmodelingTesting &turnover



Businessmodeling

Applicationgeneration

Businessmodeling

ApplicationgenerationBusiness

modelingProcess

modeling

BusinessmodelingProcess

modeling

Businessmodeling

Datamodeling

Businessmodeling

Datamodeling



Team #2

Team #3

60–90 days

Fig. 2.5 RAD model


22

Process modelingThedataobjectsdefinedindatamodelingphasearetransformedtoachievetheinformationflownecessaryto•implement a business function. Processing descriptions are created for adding, modifying, deleting, or retrieving a data object. •

Application generationRAD assumes the use of fourth generation techniques. •Rather than creating software using conventional third generation programming languages the RAD process •works to reuse existing program components when possible or create reusable components when necessary.In all cases, automated tools are used to facilitate construction of the software. •

Testing and turnoverSince the RAD process emphasises reuse, many of the program components have already been tested. This reduces overall testing time.

Obviously, the time constraints imposed on a RAD project demand “scalable scope”. •If a business application can be modularised in a way that enables each major function to be completed in less •than three months using the approach described previously, it is a candidate for RAD.

Like all process models, the RAD approach has drawbacksForlargebutscalableprojects,RADrequiressufficienthumanresourcestocreatetherightnumberofRAD•teams.RADrequiresdevelopersandcustomerswhoarecommittedtotherapid-fireactivitiesnecessarytogetasystem•complete in a much abbreviated time frame. If commitment is lacking from either constituency, RAD projects will fail.Not all types of applications are appropriate for RAD. If a system cannot be properly modularised, building the •components necessary for RAD will be problematic. If high performance is an issue and performance is to be achieved through tuning the interfaces to system components, the RAD approach may not work.RAD is not appropriate when technical risks are high. This occurs when a new application makes heavy use •of new technology or when the new software requires a high degree of interoperability with existing computer programs.

2.4 Evolutionary Software Process ModelThere is growing recognition that software, like all complex systems, evolves over a period of time.

Business and product requirements often change as development proceeds, making a straight path to an end •product unrealistic; tight market deadlines make completion of a comprehensive software product impossible, but a limited version must be introduced to meet competitive or business pressure. Software engineers need a process model that has been explicitly designed to accommodate a product that •evolves over time.Evolutionary models are iterative. •They are characterised in a manner that enables software engineers to develop increasingly more complete •versions of the software.

2.4.1 The Incremental ModelThe incremental model combines elements of the linear sequential model (applied repetitively) with the iterative philosophy of prototyping.

Referringtofigurebelow,theincrementalmodelapplieslinearsequencesinastaggeredfashionascalendar•time progresses. Each linear sequence produces a deliverable “increment” of the software. •

23

Forexample,word-processingsoftwaredevelopedusing the incrementalparadigmmightdeliverbasicfile•management,editing,anddocumentproductionfunctionsinthefirstincrement;moresophisticatededitinganddocument production capabilities in the second increment; spelling and grammar checking in the third increment; and advanced page layout capability in the fourth increment. Itshouldbenotedthattheprocessflowforanyincrementcanincorporatetheprototypingparadigm.•Whenanincrementalmodelisused,thefirstincrementisoftenacoreproduct.Thatis,basicrequirements•are addressed, but many supplementary features some known, others unknown remain undelivered. The core product is used by the customer or undergoes detailed review. As a result of use and/or evaluation, a plan is developed for the next increment. Theplanaddressesthemodificationofthecoreproducttobettermeettheneedsofthecustomerandthedelivery•of additional features and functionality. This process is repeated following the delivery of each increment, until the complete product is produced.•

Analysis Design Code Test

System/informationengineering

Increment 1

Delivery of1st increment

Analysis Design Code Test Delivery of2nd increment

Increment 2

Analysis Design Code Test Delivery of3rd increment

Increment 3

Analysis Design Code Test Delivery of4th increment

Increment 4

Calendar time

Fig. 2.6 Incremental model

The incremental process model, like prototyping and other evolutionary approaches, is iterative in nature. But unlike prototyping, the incremental model focuses on the delivery of an operational product with each •increment. Earlyincrementsarestrippeddownversionsofthefinalproduct,buttheydoprovidecapabilitythatservesthe•user and also provide a platform for evaluation by the user. Incrementaldevelopment isparticularlyusefulwhenstaffing isunavailable foracomplete implementation•by the business deadline that has been established for the project. Early increments can be implemented with fewer people. If the core product is well received, then additional staff (if required) can be added to implement the next •increment. In addition, increments can be planned to manage technical risks. •For example, a major system might require the availability of new hardware that is under development and •whose delivery date is uncertain. It might be possible to plan early increments in a way that avoids the use of this hardware, thereby enabling partial functionality to be delivered to end-users without inordinate delay.


24

2.4.2 The Spiral ModelThe spiral model, originally proposed by Boehm, is an evolutionary software process model that couples the iterative nature of prototyping with the controlled and systematic aspects of the linear sequential model.

It provides the potential for rapid development of incremental versions of software. •Using the spiral model, software is developed in a series of incremental releases. •During early iterations, the incremental release might be a paper model or prototype. •During later iterations, increasingly more complete versions of the engineered system are produced. •A spiral model is divided into a number of framework activities, also called task regions.•Typically, there are between three and six task regions. Fig. 2.7 depicts a spiral model that contains six task •regions:

Customer communicationTasks required establishing effective communication between developer and customer.

PlanningTasksrequireddefiningresources,timelines,andotherprojectrelatedinformation.

Risk analysisTasks required to assess both technical and management risks.

EngineeringTasks required building one or more representations of the application.

Construction and releaseTasks required constructing, testing, installing, and providing user support (e.g., documentation and training).

Customer evaluation Tasks required obtaining customer feedback based on evaluation of the software representations created during the engineering stage and implemented during the installation stage.

Construction & releaseCustomerevaluation

Risk analysisPlanning

Customercommunication

Engineering

Project entrypoint axis

Product maintenance projects

Product enhancement projects

New product development projects

Concept development projects

Fig. 2.7 A typical spiral model

25

Each of the regions is populated by a set of work tasks, called a task set, that are adapted to the characteristics •of the project to be undertaken. For small projects, the number of work tasks and their formality is low. •Forlarger,morecriticalprojects,eachtaskregioncontainsmoreworktasksthataredefinedtoachieveahigher•level of formality. Inallcases, theumbrellaactivities (forexample, softwareconfigurationmanagementandsoftwarequality•assurance) noted in is applied. As this evolutionary process begins, the software engineering team moves around the spiral in a clockwise •direction, beginning at the center. Thefirstcircuitaroundthespiralmightresultinthedevelopmentofaproductspecification;subsequentpasses•around the spiral might be used to develop a prototype and then progressively more sophisticated versions of the software. Each pass through the planning region results in adjustments to the project plan. Cost and schedule are adjusted •based on feedback derived from customer evaluation. In addition, the project manager adjusts the planned number of iterations required to complete the software. •Unlike classical process models that end when software is delivered, the spiral model can be adapted to apply •throughout the life of the computer software. An alternative view of the spiral model can be considered by examining the project entry point axis, also shown •infig.2.8.Each cube placed along the axis can be used to represent the starting point for different types of projects. •A “concept development project” starts at the core of the spiral and will continue (multiple iterations occur along •the spiral path that bounds the central shaded region) until concept development is complete. If the concept is to be developed into an actual product, the process proceeds through the next cube (new product •development project entry point) and a “new development project” is initiated. The new product will evolve through a number of iterations around the spiral, following the path that bounds •the region that has somewhat lighter shading than the core. In essence, the spiral, when characterised in this way, remains operative until the software is retired. There are •times when the process is dormant, but whenever a change is initiated, the process starts at the appropriate entry point (for example, product enhancement). The spiral model is a realistic approach to the development of large-scale systems and software. Because •software evolves as the process progresses, the developer and customer better understand and react to risks at each evolutionary level. The spiral model uses prototyping as a risk reduction mechanism but, more important, enables the developer •to apply the prototyping approach at any stage in the evolution of the product. It maintains the systematic stepwise approach suggested by the classic life cycle but incorporates it into an •iterativeframeworkthatmorerealisticallyreflectstherealworld.The spiral model demands a direct consideration of technical risks at all stages of the project and, if properly •applied, should reduce risks before they become problematic. Butlikeotherparadigms,thespiralmodelisnotapanacea.Itmaybedifficulttoconvincecustomers(particularly•in contract situations) that the evolutionary approach is controllable.It demands considerable risk assessment expertise and relies on this expertise for success. If a major risk is not •uncovered and managed, problems will undoubtedly occur. Finally, the model has not been used as widely as the linear sequential or prototyping paradigms. •Itwill takeanumberofyearsbeforeefficacyof this importantparadigmcanbedeterminedwithabsolute•certainty.


26

2.4.3 The Concurrent Development ModelThe concurrent development model is sometimes called concurrent engineering.

The concurrent process model can be represented schematically as a series of major technical activities, tasks, •and their associated states.Figure below provides a schematic representation of one activity with the concurrent process model. •The activity analysis may be in any one of the 10 states noted at any given time.•Similarly, other activities (for example, design or customer communication) can be represented in an analogous •manner. All activities exist concurrently but reside in different states. For example, early in a project the customer •communicationactivity(notshowninthefigure)hascompleteditsfirstiterationandexistsintheawaitingchanges state. The analysis activity (which existed in the none state while initial customer communication was completed) •now makes a transition into the under development state. If, however, the customer indicates that changes in requirements must be made, the analysis activity moves •from the under development state into the awaiting changes state.

Under review

Baselined

Done

Underrevision

Awaitingchanges

Underdevelopment

None

Analysis activity

Represents a state of asoftware engineered activity

Fig. 2.8 One element of the concurrent process model

27

Theconcurrentprocessmodeldefinesaseriesofeventsthatwilltriggertransitionsfromstatetostateforeach•of the software engineering activities. For example, during early stages of design, an inconsistency in the analysis model is uncovered. This generates •the event analysis model correction which will trigger the analysis activity from the done state into the awaiting changes state. The concurrent process model is often used as the paradigm for development of client/server applications. •A client/server system is composed of a set of functional components. When applied to client/server, the concurrent •processmodeldefinesactivitiesintwodimensions:asystemdimensionandacomponentdimension.System level issues are addressed using three activities: design, assembly, and use. The component dimension •is addressed with two activities: design and realisation. Concurrency is achieved in two ways: System and component activities occur simultaneously and can be modelled using the state-oriented approach •described previously.A typical client/server application is implemented with many components, each of which can be designed and •realised concurrently.In reality, the concurrent process model is applicable to all types of software development and provides an •accurate picture of the current state of a project. Rather than confining software engineering activities to a sequence of events, it defines a network of•activities. Each activity on the network exists simultaneously with other activities.• Events generated within a given activity or at some other place in the activity network trigger transitions among •the states of an activity.

2.5 Component Based ModelObject-oriented technologies provide technical framework for a component-based process model for software engineering.

The component-based development (CBD) model incorporates many of the characteristics of the spiral •model. It is evolutionary in nature, demanding an iterative approach to the creation of software. However, the component-•based development model composes applications from pre-packaged software components called classes.Theengineeringactivitybeginswiththeidentificationofcandidateclasses.Thisisaccomplishedbyexamining•the data to be manipulated by the application and the algorithms that will be applied to accomplish the manipulation.Corresponding data and algorithms are packaged into a class.•


28

Customerevaluation

RiskanalysisPlanning

Customercommunication

Identifycandidate

components

Constructnth iteration

of system

Put newcomponents

in library

Look upcomponents

in library

Extractcomponentsif available

Engineeringconstruction & release

Buildcomponents

if unavailable

Fig. 2.9 Component based development

The component-based development model leads to software reuse, and reusability provides software engineers •withanumberofmeasurablebenefits.Based on studies of reusability, QSM Associates, Inc., reports component assembly leads to a 70 percent •reduction in development cycle time; an 84 percent reduction in project cost, and a productivity index of 26.2, compared to an industry norm of 16.9. Theunifiedsoftwaredevelopmentprocess is representativeofanumberofcomponent-baseddevelopment•models that have been proposed in the industry.UsingtheUnifiedModelingLanguage(UML),theunifiedprocessdefinesthecomponentsthatwillbeusedto•build the system and the interfaces that will connect the components.

The formal methods modelThe formalmethodsmodel encompasses a set of activities that leads to formalmathematical specification ofcomputer software.

Formal methods enable a software engineer to specify, develop, and verify a computer-based system by applying •a rigorous, mathematical notation. A variation on this approach, called clean room software engineering, is currently applied by some software •development organisations. When formal methods are used during development, they provide a mechanism for eliminating many of the •problemsthataredifficulttoovercomeusingothersoftwareengineeringparadigms.Ambiguity, incompleteness, and inconsistency can be discovered and corrected more easily, not through ad hoc •review but through the application of mathematical analysis. Whenformalmethodsareusedduringdesign,theyserveasabasisforprogramverificationandthereforeenable•the software engineer to discover and correct errors that might go undetected.Although it is not destined to become a mainstream approach, the formal methods model offers the promise of •defect-free software. Yet, the following concerns about its applicability in a business environment have been voiced:

29

The development of formal models is currently quite time consuming and expensive. �Because few software developers have the necessary background to apply formal methods, extensive �training is required.Itisdifficulttousethemodelsasacommunicationmechanismfortechnicallyunsophisticatedcustomers. �

These concerns notwithstanding, it is likely that the formal methods approach will gain adherents among software •developers who must build safety-critical software (for example, developers of aircraft avionics and medical devices) and among developers that would suffer severe economic hardship should software errors occur.

2.6 Process TechnologyThe process models discussed in the preceding sections must be adapted for use by a software project team.

To accomplish this, process technology tools have been developed to help software organisations analyse their •current process, organise work tasks, control and monitor progress, and manage technical quality.Process technology tools allow a software organisation to build an automated model of the common process •framework, task sets, and umbrella activities. Themodel,normallyrepresentedasanetwork,canthenbeanalysedtodeterminetypicalworkflowandexamine•alternative process structures that might lead to reduced development time or cost.Once an acceptable process has been created, other process technology tools can be used to allocate, monitor, •andevencontrolallsoftwareengineeringtasksdefinedaspartoftheprocessmodel.Each member of a software project team can use such tools to develop a checklist of work tasks to be performed, •work products to be produced, and quality assurance activities to be conducted. The process technology tool can also be used to coordinate the use of other computer-aided software engineering •tools that are appropriate for a particular work task.


30

Summary Acommonprocess framework is establishedbydefining a small number of framework activities that are•applicable to all software projects, regardless of their size or complexity. A number of tasks set each a collection of software engineering work tasks, project milestones, work products, •and quality assurance points enable the framework activities to be adapted to the characteristics of the software project and the requirements of the project team. The Software Engineering Institute (SEI) has developed a comprehensive model predicated on a set of software •engineering capabilities that should be present as organisations reach different levels of process maturity. To determine an organisation’s current state of process maturity, the SEI uses an assessment that results in a •fivepointgradingscheme.To solve actual problems in an industry setting, a software engineer or a team of engineers must incorporate •a development strategy that encompasses the process, methods, and tools layers and the generic phases. This strategy is often referred to as a process model or a software engineering paradigm. Sometimes called the classic life cycle or the waterfall model, the linear sequential model suggests a systematic, •sequential approach5 to software development that begins at the system level and progresses through analysis, design, coding, testing, and support. Software will undoubtedly undergo change after it is delivered to the customer. Change will occur because •errors have been encountered, because the software must be adapted to accommodate changes in its external environment e.g., a change required because of a new operating system or peripheral device, or because the customer requires functional or performance enhancements.Inothercases,thedevelopermaybeunsureoftheefficiencyofanalgorithm,theadaptabilityofanoperating•system, or the form that human/machine interaction should take. In these, and many other situations, a prototyping paradigm may offer the best approach. The prototyping •paradigm begins with requirements gathering. Developerandcustomermeetanddefinetheoverallobjectivesforthesoftware,identifywhateverrequirements•areknown,andoutlineareaswherefurtherdefinitionismandatory.The customer sees what appears to be a working version of the software, unaware that the prototype is held •together “with chewing gum and baling wire,” unaware that in the rush to get it working no one has considered overall software quality or long-term maintainability. When informed that the product must be rebuilt so that highlevelsofqualitycanbemaintained,thecustomercriesfoulanddemandsthat“afewfixes”beappliedtomake the prototype a working product.The developer often makes implementation compromises in order to get a prototype working quickly. An •inappropriate operating system or programming language may be used simply because it is available and known; aninefficientalgorithmmaybeimplementedsimplytodemonstratecapability.

ReferencesLeach, J. R., 2000. • Introduction to software engineering, CRC Press.Jalote, P., 2008. • A concise introduction to software engineering, Springer.The Software Experts, • Software Process Models [Online] Available at: <http://www.the-software-experts.de/e_dta-sw-process.htm> [Accessed 7 November 2011].Scribd.Inc, 2011. • Software Process Models [Online] Available at: <http://www.scribd.com/doc/25465086/Software-Process-Models> [Accessed 7 November 2011].www.softwaretestingmodels.com, 2008. • Software Development Life Cycles: Waterfall Model, V-Model [Video online] Available at: <http://www.youtube.com/watch?v=KaPC0gsEQ68> [Accessed 7 November 2011].SelectBusinessSolns. 2011• . The Software Process [Video online] Available at: <http://www.youtube.com/watch?v=YMbAdgb6pG8> [Accessed 7 November 2011].

31

Recommended ReadingJalote, P., 2002. • Software Project Management in Practice, Pearson Education India.Agarwal, B. B. and Tayal, P. S., 2007. • Software Engineering, Firewall Media.Puntambekar, A. A., 2009. • Software Engineering, Technical Publications.


32

Self AssessmentThe __________ process is characterised as adhoc and occasionally even chaotic.1.

design a. softwareb. hardware c. code d.

Basic ______________ management processes are established to track cost, schedule, and functionality.2. projecta. service b. development c. machine d.

The software process for both _______________ activities is documented, standardised, and integrated into an 3. organisation wide software process.

organisation and development a. management and engineeringb. system and software c. scheduling and budgeting d.

The SEI has associated Key Process Areas with each of the ________ levels.4. managing a. manipulating b. maturityc. manufacturing d.

TheKeyProcessAreasisdefinedbyasetofkeypracticesthatcontributetosatisfyingits___________.5. goalsa. department b. sequence c. objectives d.

System _____________________encompass requirements gathering at the system level with a small amount 6. of top level design and analysis.

management and engineeringa. system and software b. scheduling and budgeting c. engineering and analysisd.

Which of the following step performs that the design must be translated into a machine-readable form? 7. Code generation a. Task performance b. Programming c. Executing d.

33

The _______________ model is the oldest and the most widely used paradigm for software engineering.8. random sequencing a. linear sequentialb. rapid sequencing c. data d.

Rapid application development is a/ an __________software development process model that emphasises an 9. extremely short development cycle.

incrementala. decremented b. linear c. random d.

Which generation uses the RAD techniques? 10. First generation a. Second generation b. Fourth generation c. Third generation d.


34

Chapter III

Software Development Life Cycle

Aim


explain software development life cycle •

elucidate requirement analysis •

discuss feasibility study •

Objectives


explain the concept of coding •

describe the concept of testing •

enlist various types of maintenance •

Learning outcome


understand system analysis and design •

highlight the preventive maintenance •

describe adaptive maintenance •

35

3.1 Introduction to Software Development Life CycleThe product developed which achieves customer satisfaction is not done in a single step.

It involves series of steps in a software development process. This is needed to develop quality products with error •free products to achieve customer satisfaction. There are many models available in the software development process. But majority of software development process follow the model named as software development life cycle. This software develop life cycle has number of steps in it. The below article describes about the software development life cycle and the steps involved into it. Software development life cycle model is also called as waterfall model which is followed by majority of •systems. This software development life cycle process has the following seven stages in it namely

System requirements analysis �Feasibility study �Systems analysis and design �Code generation �Testing �Maintenance �Implementation �

Let us discuss each of these to have an overview about each of the following steps in software development •life cycle.

3.2 Requirement AnalysisRequirements analysis is a software engineering task that bridges the gap between system level requirements engineering and software design.

System engineering

Software design

Software requirements

analysis

Fig. 3.1 Analysis as a bridge between system engineering and software design


36

Requirements engineering activities result in:•Thespecificationofsoftware’soperationalcharacteristicsfunction,data,andbehaviour. �Indicate software’s interface with other system elements �Establish constraints that software must meet. �

Requirements analysis allows the software engineer (analyst) to improve the software allocation and build •models of the data, functional, and behavioural domains that will be treated by software. Requirements analyses provide the software designer with a representation of information, function, and behaviour •that can be interpreted to data, architectural, interface, and component-level designs. Therequirementsspecificationgivesthedeveloperandthecustomerwiththemeanstoassessqualityonce•software is built.

Software requirements analysis may be divided into five areas of effort:Problem recognition•Evaluation and synthesis•Modeling•Specification•Review•

3.3 Feasibility StudyAfter making an analysis in the system requirement the next step is to make analysis of the software requirement. In other words feasibility study is also called software requirement analysis.

In this phase development team has to make communication with customers and make analysis of their •requirement and analyse the system. Bymakinganalysisthiswayitwouldbepossibletomakeareportofidentifiedareaofproblem.•By making a detailed analysis on this area a detailed document or report is prepared in this phase which has details •like project plan or schedule of the project, the cost estimated for developing and executing the system, target dates for each phase of delivery of system developed and so on. This phase is the base of software development process since further steps taken in software development life cycle would be based on the analysis made on this phase and so careful analysis has to be made in this phase.

3.4 CodingThe system design needs to be implemented to make it a workable system. This demands the coding of design into computer understandable language, i.e., programming language. This is also called the programming phase in which theprogrammerconvertstheprogramspecificationsintocomputerinstructions,whichwerefertoasprograms.

Itisanimportantstagewherethedefinedproceduresaretransformedintocontrolspecificationsbythehelpof•a computer language. The programs coordinate the data movements and control the entire process in a system.•It is generally felt that the programs must be modular in nature. This helps in fast development, maintenance •and future changes, if required.

3.5 TestingBefore actually implementing the new system into operation, a test run of the system is done for removing the bugs, if any. It is an important phase of a successful system. After codifying the whole programs of the system, a test plan should be developed and run on a given set of test data. The output of the test run should match the expected results. Sometimes, system testing is considered a part of implementation process.

37

Using the test data following test run are carried out:Program test•System test•

Program testWhen the programs have been coded, compiled and brought to working conditions, they must be individually tested with the prepared test data. Any undesirable happening must be noted and debugged (error corrections)

System testAfter carrying out the program test for each of the programs of the system and errors removed, then system test is done. At this stage the test is done on actual data. The complete system is executed on the actual data. At each stage of the execution, the results or output of the system is analysed. During the result analysis, it may be found that the outputs are not matching the expected output of the system. In such case, the errors in the particular programs areidentifiedandarefixedandfurthertestedfortheexpectedoutput.Whenitisensuredthatthesystemisrunningerror-free, the users are called with their own actual data so that the system could be shown running as per their requirements.

3.6 Integration and TestingDuring the integration and test stage, the software artifacts, online help, and test data are migrated from the development environment to a separate test environment.

At this point, all test cases are run to verify the correctness and completeness of the software. •Successfulexecutionofthetestsuiteconfirmsarobustandcompletemigrationcapability.•Duringthisstage,referencedataisfinalisedforproductionuseandproductionusersareidentifiedandlinked•to their appropriate roles. Thefinalreferencedataorlinkstoreferencedatasourcefilesandproductionuserlistarecompiledintothe•Production Initiation Plan.

UpdatedProject Plan& Schedule

IntegratedSoftware

Integration& Test Stage

OnlineHelp

ImplementationMap Test PlanSoftware

OnlineHelp

ProductionInitiation Plan

AcceptancePlan

ImplementationMap

Fig. 3.2 Integration and test stage


38

The outputs of the integration and test stage include •An integrated set of software �An online help system, an implementation map �A production initiation plan that describes reference data and production users �Anacceptanceplanwhichcontainsthefinalsuiteoftestcases �An updated project plan �

3.7 MaintenanceMaintenance is necessary to eliminate errors in the system during its working life and to tune the system to any variations in its working environments. It has been seen that there are always some errors found in the systems that must be noted and corrected. It also means the review of system from time to time. The review of the system is done for:

Knowing the full capabilities of the system•Knowing the required changes or the additional requirements•Studying the performance.•

If a major change to a system is needed, a new project may have to be set up to carry out the change. The new project will then proceed through all the above life cycle phases.

Types of maintenanceThere ismuchmore tomaintenancethanfixingbugs.ThecategoriessuggestedbySwanson2andextendedbyReutter1 are widely accepted.

Corrective maintenanceThe objective of corrective maintenance is to remove errors or bugs from the software, the procedures, the hardware, the network, the data structures, and the documentation.

Correctivemaintenanceactivitiesincludebothemergencyrepairs(firefighting)andpreventive(orcorrective)•repairs. For example, maintenance programmers are concerned with such tasks as removing residual software bugs, •improving the integrity and reliability of the programs, streamlining and tightening data validation routines, correcting invalid processing and reporting, and minimising downtime.Maintenance programmers use such traditional debugging tools as static code analysers, on-line debuggers, •and dynamic debugging tools. On-line debuggers are used to trace the order in which modules are executed or to exhibit the names and data •values of selected variables as they change. Dynamicdebuggingtoolsareusedtoidentifyallthepossiblepathstoagivenstatement,toflagallthestatements•that modify or access a given data element, or to allow the programmer to determine what happens if the value of a given variable is changed.In an ideal world, systems and software are so reliable that the need for corrective maintenance does not exist, •but that ideal world does not exist and probably never will.Usingtoolsasgivenbelow,cansignificantlyimprovesoftwarereliability:•

Database management software �Application development systems �Program generators �Fourth-generation languages �Structured techniques �Object-oriented techniques �

39

Adaptive maintenanceThe point of adaptive maintenance is to enhance the system by adding features, capabilities, and functions in •response to new technology, upgrades, new requirements, or new problems. Note that adaptive maintenance is reactive. Theideaistofixthesystemwhenthegeneralbusinessclimate,competition,growth,newtechnology,ornew•regulations make change necessary. The key to minimising adaptive maintenance costs is to separate system-dependent features.•

Perfective maintenanceThepointofperfectivemaintenanceistoenhancethesystembyimprovingefficiency,reliability,functionality,ormaintainability, often in response to user or system personnel requests.

Corrective and adaptive maintenance are reactive. •Bugsarefixedastheyarediscovered.•An upgrade to an operating system can necessitate a change to application software. Perfective maintenance, •in contract, is proactive. Theideaistofixthesystembeforeitbreaks.•Without changing how the system works or what it does, restructuring efforts are aimed at enhancing •performance. Thecodemightbeconvertedtoamoreefficientlanguageorrunthroughanoptimisingcompiler.•Code conversion software might be used to reorganise the code or convert the logic to a more structured •form. Note that the code is not rewritten, just restructured.•The point of reengineering is to change the system to make it better without affecting its functionality or external •behaviour. The idea is togradually“cleanup themess”bydoingsuch thingsas restructuringfilesanddatabasesand•encasing old code in a wrapper of well-structured or object-oriented code. Reengineered software is easier to reverse engineer or to farm out to subcontractors.•The objective of reverse engineering is to extract an abstract model from the system’s physical documentation •and then use the model as a base for creating a functionally equivalent system. For example, an analysis of a set of source code might generate a structure chart, a set of data dictionary entries, •or an entity-relationship diagram. Reverse engineering has been applied to software almost as long as software has existed.•For example, Microsoft might reverse engineer its Excel spreadsheet program to produce equivalent programs •to run on different computers or to create an object-oriented version of Excel.

Preventive maintenanceAlthough not explicitly part of the Swanson/Reutter model (except by implication), ongoing preventive maintenance is an important part of any system’s standard operating procedures.

The objective of preventive maintenance is to anticipate problems and correct them before they occur. •Files and databases must be updated, periodically reorganised, and regularly backed up. •Control totals must be reset. •New software releases must be installed.•System performance monitoring is an important key to preventive maintenance. •The idea is to conduct periodic audits and to run regular benchmark tests to determine if the system is continuing •to perform to expectations.Both hardware and software are monitored to measure system load and system utilisation. •The information derived from performance monitoring provides an early warning of potential system problems •and often initiates other forms of maintenance.


40

3.8 Systems Analysis and DesignThis is an important phase in system development. Here analysis is made on the design of system that is going to be developed.

Inotherwordsdatabasedesign,thedesignofthearchitecturechosen,functionalspecificationdesign,lowlevel•design documents, high level design documents and so on takes place. Care must be taken to prepare these design documents because the next phases namely the development phase •is based on these design documents. If a well structured and analysed design document is prepared it would reduce the time taken in the coming •steps namely development and testing phases of the software development life cycle.

41

Summary Software development life cycle model is also called waterfall model which is followed by majority of •systems.Requirements analysis is a software engineering task that bridges the gap between system level requirements •engineering and software design.Requirementsanalysisallowsthesoftwareengineer(analyst)torefinethesoftwareallocationandbuildmodels•of the data, functional, and behavioural domains that will be treated by software.Requirements analysis provides the software designer with a representation of information, function, and •behaviour that can be translated to data, architectural, interface, and component-level designs.After making an analysis in the system requirement the next step is to make analysis of the software requirement. •In other words feasibility study is also called as software requirement analysis.The system design needs to be implemented to make it a workable system. This demands the coding of design •into computer understandable language, i.e., programming language. This is also called the programming phase inwhichtheprogrammerconvertstheprogramspecificationsintocomputerinstructions,whichwerefertoasprograms. After codifying the whole program of the system, a test plan should be developed and run on a given set of test •data. The output of the test run should match the expected results. Sometimes, system testing is considered a part of implementation process.When the programs have been coded, compiled and brought to working conditions, they must be individually •tested with the prepared test data. Any undesirable happening must be noted and debugged (error corrections)After carrying out the program test for each of the programs of a system and errors removed, then system test •is done. At this stage the test is done on actual data. The complete system is executed on the actual data.Maintenance is necessary to eliminate errors in the system during its working life and to tune the system to any •variations in its working environments. It has been seen that there are always some errors found in the systems that must be noted and corrected.Correctivemaintenanceactivitiesincludebothemergencyrepairs(firefighting)andpreventive(orcorrective)•repairs.Dynamicdebuggingtoolsareusedtoidentifyallthepossiblepathstoagivenstatement,toflagallthestatements•that modify or access a given data element, or to allow the programmer to determine what happens if the value of a given variable is changed.The point of adaptive maintenance is to enhance the system by adding features, capabilities, and functions in •response to new technology, upgrades, new requirements, or new problems. Note that adaptive maintenance is reactive. Thepointofperfectivemaintenanceistoenhancethesystembyimprovingefficiency,reliability,functionality,•or maintainability, often in response to user or system personnel requests.

ReferencesSage, P. A., 1992• . Systems engineering, Wiley-IEEE.Blanchard, S. B., 2004. • System engineering management, John Wiley and Sons.exforsys.com, 2006. • Software Development Life Cycle [Online] Available at: <http://www.exforsys.com/tutorials/programming-concepts/software-development-life-cycle.html> [Accessed 07 November 2011].Tobassam, 2010. • SDLC Phases [Video online] Available at: <http://www.youtube.com/watch?v=b9IAbldXAmg&feature=related> [Accessed 9 October 2011].Tobassam, 2010. • SDLC Maintenance Phase [Video online] Available at: <http://www.youtube.com/watch?v=3KWVMbyAGCI&feature=related> [Accessed 9 October 2011].edulevel, 2011. • Software Development Life Cycle [Video online] Available at: <http://www.youtube.com/watch?v=1zFSNfp3R64> [Accessed 9 October 2011].


42

Recommended ReadingMartin, N. J., 1997. • Systems engineering guidebook: a process for developing systems and products, CRC Press.Langer, M. A., 2007. • Analysis and design of information systems, 3rd ed., Springer.Rajaraman, V., 2004. • Analysis and design of information systems, 2nd ed., PHI Learning Pvt. Ltd.

43

Self AssessmentWhich of the following is alias of software development life cycle model? 1.

downfalla. stream b. river c. waterfalld.

Requirements analysis is a software engineering task that bridges the gap between system level requirements 2. engineering and____________.

software designa. tool design b. data model c. debugging d.

Requirementsspecificationgivesthedeveloperandcustomerthemeanstoassessqualityonce__________is3. built.

floora. design b. softwarec. hardware d.

Before actually implementing the new system into operation, a test run of the system is done for removing 4. the__________, if any.

argument a. flawsb. bugsc. subroutine d.

After codifying the whole programs of the system, a test plan should be developed and run on a given set of 5. ________.

tool a. code b. test datac. program d.

During the integration and test stage, the software artifacts, online help, and test data are __________ from the 6. development environment to a separate test environment.

copied a. migratedb. removed c. added d.


44

______________ is necessary to eliminate errors in the system during its working life and to tune the system 7. to any variations in its working environments.

Maintenancea. Testing b. Designing c. Developing d.

The objective of ______________ is to remove errors or bugs from the software, the procedures, the hardware, 8. the network, the data structures, and the documentation.

adaptive maintenance a. corrective maintenanceb. preventive maintenance c. perfective maintenance d.

____________activitiesincludebothemergencyrepairs(firefighting)andpreventive(orcorrective)repairs.9. adaptive maintenance a. corrective maintenanceb. preventive maintenance c. perfective maintenance d.

Which of the following is true? 10. Maintenance programmer’s uses traditional debugging tools as static code analysers, on-line debuggers, a. and dynamic debugging tools. Testing programmers uses traditional debugging tools as static code analysers, on-line debuggers, and b. dynamic debugging tools. Designing programmers uses traditional debugging tools as static code analysers, on-line debuggers, and c. dynamic debugging tools.Developing programmers uses traditional debugging tools as static code analysers, on-line debuggers, and d. dynamic debugging tools.

45

Chapter IV

Software Requirement Specification

Aim


explain the concept of waterfall model •

elucidate project output in a waterfall model •

discuss prototyping model •

Objectives


explain the concept of iterative model •

highlight spiral model •

describe role of management in software development •

Learning outcome


understand the concept of problem analysis •

identify informal approach •

describedataflowmodeling•


46

4.1 Waterfall ModelThe simplest software development life cycle model is the waterfall model, which states that the phases are organised in a linear order.

A project begins with feasibility analysis. •On the successful demonstration of the requirements analysis, feasibility analysis and project planning •begins. The design starts after the requirements analysis is done. And coding begins after the design is done. Once the •programming is completed, the code is integrated and testing is done. On successful completion of testing, the system is installed. After this the regular operation and maintenance •of the system takes place. Thefollowingfiguredemonstratesthestepsinvolvedinwaterfalllifecyclemodel.•

Requirement Analysis Planning

System Design andspecification Coding and

verificationTesting and integration

Maintenance

Fig. 4.1 Waterfall model

With the waterfall model, the activities performed in a software development project are requirements analysis, •project planning, system design, detailed design, coding and unit testing, system integration and testing.Linear ordering of activities has some important consequences. •First, to clearly identify the end of a phase and beginning of others.•Somecertificationmechanismhas tobeemployedat theendofeachphase.This isusuallydonebysome•verificationandvalidation.Validationmeansconfirmingtheoutputofaphaseisconsistentwithitsinput(whichistheoutputoftheprevious•phase) and that the output of the phase is consistent with overall requirements of the system.Theconsequencesoftheneedofcertificationarethateachphasemusthavesomedefinedoutputthatcanbe•evaluatedandcertified.Therefore,when theactivitiesofaphasearecompleted, thereshouldbeanoutputproduct of that phase and the goal of a phase is to produce this product. The outputs of the earlier phases are often called intermediate products or design document.•For the coding phase, the output is the code. From this point of view, the output of a software project is to justify •thefinalprogramalongwith theuseofdocumentationwith the requirementsdocument,designdocument,project plan, test plan and test results.Another implication of the linear ordering of phases is that after each phase is completed and its outputs are •certified,theseoutputsbecometheinputstothenextphaseandshouldnotbechangedormodified.However, changing requirements cannot be avoided and must be faced. Since changes performed in the output •of one phase affect the later phases that might have been performed. These changes have to be made in a controlled manner after evaluating the effect of each change on the •project. Thisbringsustotheneedforconfigurationcontrolorconfigurationmanagement.•

47

Thecertifiedoutputofaphasethatisreleasedforthebestphaseiscalledbaseline.Theconfigurationmanagement•ensures that any changes to a baseline are made after careful review, keeping in mind the interests of all parties that are affected by it. There are two basic assumptions for justifying the linear ordering of phase in the manner proposed by the •waterfall model.For a successful project resulting in a successful product, all phases listed in the waterfall model must be •performed anyway.Any different ordering of the phases will result in a less successful software product.•

Project output in a waterfall modelAswehaveseen,theoutputofaprojectemployingthewaterfallmodelisnotjustthefinalprogramalongwithdocumentation to use it. There are a number of intermediate outputs, which must be produced in order to produce a successful product.

The set of documents that forms the minimum that should be produced in each project are:Requirement document•Project plan•System design document•Detailed design document•Test plan and test report•Final code•Software manuals (user manual, installation manual, etc.)•Review reports•

Except for the last one, these are all the outputs of the phases. In order to certify an output product of a phase before the next phase begins, reviews are often held. Reviews are necessary especially for the requirements and designphases,sinceothercertificationmeansarefrequentlynotavailable.Reviewsareformalmeetingtouncoverdeficienciesinaproduct.Thereviewreportsaretheoutcomeofthesereviews.

Advantages of waterfall life cycle modelsEasy to explain to the user•Stagesandactivitiesarewelldefined•Helps to plan and schedule the project•Verificationateachstageensuresearlydetectionoferrors/misunderstanding•

Limitations of the waterfall life cycle modelThe waterfall model assumes that the requirements of a system can be frozen (i.e. basedline) before the design •begins. This is possible for systems designed to automate an existing manual system. But for absolutely new system,determiningtherequirementsisdifficult,astheuserhimselfdoesnotknowtherequirements.Therefore,having unchanging (or changing only a few) requirements is unrealistic for such project.Freezing the requirements usually requires choosing the hardware (since it forms a part of the requirement •specification).Alargeprojectmighttakeafewyearstocomplete.Ifthehardwareisselectedearly,thenduetothespeedatwhichhardwaretechnologyischanging,itisquitelikelythatthefinalsoftwarewillemployahardware technology that is on the verge of becoming obsolete. This is clearly not desirable for such expensive software.


48

Thewaterfallmodel stipulates that the requirements shouldbe completely specifiedbefore the rest of the•developmentcanproceed.Insomesituationsitmightbedesirabletofirstdevelopapartofthesystemcompletely,and then later enhance the system in phase. This is often done for software products that are developed not necessarilyforaclient(wheretheclientplaysanimportantroleinrequirementspecification),butforgeneralmarketing, in which the requirements are likely to be determined largely by developers.

4.2 Prototyping ModelThegoalofprototypingbaseddevelopmentistocounterthefirsttwolimitationsofthewaterfallmodeldiscussedearlier.

The basic idea here is that instead of freezing the requirements before a design or coding can proceed, a throwaway •prototype is built to understand the requirements. This prototype is developed based on the currently known requirements. Development of the prototype obviously undergoes design, coding and testing. But each of these phases is not •done very formally or thoroughly. By using this prototype, the client can get an “actual feel” of the system, since the interactions with prototype •can enable the client to better understand the requirements of the desired system.Prototyping is an attractive idea for complicated and large systems for which there is no manual process or •existing system to help determining the requirements. In such situations letting the client “plan” with the prototype provides invaluable and intangible inputs which •helps in determining the requirements for the system. It is also an effective method to demonstrate the feasibility of a certain approach. This might be needed for •novel systems where it is not clear that constraint can be met or that algorithms can be developed to implement the requirements. Theprocessmodeloftheprototypingapproachisshowninthefigurebelow.•

Start

Stop

Requirement gathering

Customer Evaluation

RefiningPrototypeEngineer Product

Quick design Building Prototype

Fig. 4.2 Prototyping model

The basic reason for little common use of prototyping is the cost involved in this built-it-twice approach. However, •some argue that prototyping need not be very costly and can actually reduce the overall development cost. The prototype is usually not complete systems and many of the details are not built in the prototype.•The goal is to provide a system with overall functionality. •In addition, the cost of testing and writing detailed documents are reduced. These factors help to reduce the •cost of developing the prototype. On the other hand, the experience of developing the prototype will very useful for developers when developing •thefinalsystem.Thisexperiencehelpstoreducethecostofdevelopmentofthefinalsystemandresultsinamorereliableand•better designed system.

49

Advantages of prototypingUsers are actively involved in the development.•It provides a better system to users, as users have natural tendency to change their mind in specifying requirements •and this method of developing systems supports this user tendency.Since in this methodology a working model of the system is provided, the users get a better understanding of •the system being developed.Errors can be detected much earlier as the system is mode side by side.•Quicker user feedback is available leading to better solutions.•

DisadvantagesLeads to implementing and then repairing way of building systems.•Practically, this methodology may increase the complexity of the system as scope of the system may expand •beyond original plans.

4.3 Iterative ModelThe iterative enhancement life cycle model counters the third limitation of the waterfall model and tries to combine thebenefitsofbothprototypingandwaterfallmodel.

The basic idea is that the software should be developed in increments, where each increment adds some functional •capability to the system until the full system is implemented. Ateachstepextensionsanddesignmodificationscanbemade.•An advantage of this approach is that it can result in better testing, since testing each increment is likely to be •easier than testing entire system like in the waterfall model.Furthermore, as in prototyping, increment provides feedback to the client which is useful for determining the •finalrequirementsofthesystem.Inthefirststepofiterativeenhancementmodel,asimpleinitialimplementationisdoneforasubsetofthe•overall problem. This subset is the one that contains some of the key aspects of the problem which are easy to understand and implement, and which forms a useful and usable system. A project control list is created which contains, in an order, all the tasks that must be performed to obtain the •finalimplementation.Thisprojectcontrollistgivesanideaofhowfartheprojectisatanygivenstepfromthefinalsystem.Each step consists of removing the next step from the list.•Designing the implementation for the selected task, coding and testing the implementation, and performing an •analysis of the partial system obtained after this step and updating the list as a result of the analysis. These three phases are called the design phase, implementation phase and analysis phase. The process is iterated •untiltheprojectcontrollistisempty,atthetimethefinalimplementationofthesystemwillbeavailable.Theprocessinvolvediniterativeenhancementmodelisshowninthefigurebelow.•

Design 0 Implement 0 Analysis 0

Design 1Implement 1Analysis 1

Design 2 Implement 2 Analysis 2

Fig. 4.3 The iterative enhancement model


50

The project control list guides the iteration steps and keeps track of all tasks that must be done. •The tasks in the list can be including redesign of defective components found during analysis. •Each entry in that list is a task that should be performed in one step of the iterative enhancement process, and •should be simple enough to be completely understood.Selecting tasks in this manner will minimise the chances of errors and reduce the redesign work. •

4.4 Spiral ModelSpiral model is a recent model that has been proposed by Boehm. As the name suggests, the activities in this model can be organised like a spiral.

The spiral has many cycles. The radial dimension represents the cumulative cost incurred in accomplishing •the steps dome so far and the angular dimension represents the progress made in completing each cycle of the spiral. Thestructureofthespiralmodelisshowninthefiguregivenbelow.•Eachcycleinthespiralbeginswiththeidentificationofobjectivesforthatcycleandthedifferentalternatives•are possible for achieving the objectives and the imposed constraints.The next step in the spiral life cycle model is to evaluate these different alternatives based on the objectives and •constraints. This will also involve identifying uncertainties and risks involved. The next step is to develop strategies that resolve the uncertainties and risks. This step may involve activities •such as benchmarking, simulation and prototyping. Next, the software is developed by keeping in mind the risks. Finally the next stage is planned.•

51

Determine objectives, alternatives, constraints

Commitment Partition

Plan next phases

Develop verify next-level product

Requirement plan life-cycle plan Concept of

operation Software requirements

Requirements validation

Development Plan

Integration and test

plan

Design validation andverification

Implementation Acceptance test

Integration and test

Unit test

Code

Detailed design

Operation Prototype

Prototype 1

Risk Analy-sis

Risk Analysis

Risk Analysis

Risk Analysis

Evaluate alternatives identify, resolve risks

Progress through steps

Cumulativecost

Prototype 2

Prototype 3

Simulation models, benchmarks

Fig. 4.4 Spiral life cycle model

The next step is to determine the remaining risks. For example, its performance or user-interface risks are •considered more important than the program development risks. The next step may be evolutionary development that involves developing a more detailed prototype for resolving •the risks. On the other hand, if the program development risks dominate and previous prototypes have resolved all the •user-interface and performance risks; the next step will follow the basic waterfall approach.Theriskdrivennatureof thespiralmodelallows it toaccommodateanymixtureofspecification-oriented,•prototype-oriented, simulation-oriented or some other approach.An important feature of the model is that each cycle of the spiral is completed by a review, which covers all the •products developed during that cycle, including plans for the next cycle. The spiral model works for developed as well as enhancement projects.

Spiral model descriptionThedevelopmentspiralconsistsoffourquadrantsasshowninthefigureabove

Although a spiral, as depicted, is oriented toward software development, the concept is equally applicable to systems, hardware, and training, for example. To better understand the scope of each spiral development quadrant, let’sbrieflyaddresseachone.


52

Quadrant 1: Determine objectives, alternatives, and constraintsActivities performed in this quadrant include:

Establish an understanding of the system or product objectives namely performance, functionality, and ability •to accommodate change.Investigate implementation alternatives namely procure, design, reuse and procure/ modify•Investigate constraints imposed on the alternatives namely technology, cost, schedule, support, and risk. Once the •system or product’s objectives, alternatives, and constraints are understood, Quadrant 2 (Evaluate alternatives, identify, and resolve risks) is performed.

Quadrant 2: Evaluate alternatives, identify, and resolve risksEngineeringactivitiesperformedinthisquadrantselectanalternativeapproachthatbestsatisfiestechnical,•technology, cost, schedule, support, and risk constraints. The focus here is on risk mitigation. Each alternative is investigated and prototyped to reduce the risk associated with the development decisions. •Boehm describes these activities as follows:

Prototyping �Simulation �Benchmarking �Reference checking �Administering user questionnaires �Analytic modeling �Other risk resolution techniques �

The outcome of the evaluation determines the next course of action. If critical operational and/or technical issues •(COIs/CTIs) such as performance and interoperability (i.e., external and internal) risks remain, more detailed prototyping may need to be added before progressing to the next quadrant. Dr. Boehm notes that if the alternative chosen is “operationally useful and robust enough to serve as a low-risk •base for future product evolution, the subsequent risk-driven steps would be the evolving series of evolutionary prototypesgoingtowardtheright(handsideofthegraphic)...theoptionofwritingspecificationswouldbeaddressed but not exercised.” This brings us to Quadrant 3.

Quadrant 3: Develop, verify, next-level productIf a determination is made that the previous prototyping efforts have resolved the COIs/CTIs, activities to develop, verify, next-level product are performed.

As a result, the basic “waterfall” approach may be employed meaning concept of operations, design, development, •integration, and test of the next system or product iteration.If appropriate, incremental development approaches may also be applicable.•

Quadrant 4: Plan next phasesThe spiral development model has one characteristic that is common to all models which is the need for advanced •technical planning and multidisciplinary reviews at critical staging or control points. Each cycle of the model culminates with a technical review that assesses the status, progress, maturity, merits, •risk, of development efforts to date; resolves critical operational and/or technical issues (COIs/CTIs); and reviews plansandidentifiesCOIs/CTIstoberesolvedforthenextiterationofthespiral.Subsequent implementations of the spiral may involve lower level spirals that follow the same quadrant paths •and decision considerations.

53

4.5 Role of Management in Software DevelopmentThe management of software development is heavily dependent on four factors: People, Product, Process, and Project.Orderofdependencyisasshowninfiguregivenbelow.

24

1

3

Dependencyorder ProductProject

People

Process

Fig. 4.5 Factors of management dependency

Software development is a people centric activity. Hence, success of the project is on the shoulders of the people who are involved in the development.

The peopleSoftware development requires good managers.•Managers, who can understand the psychology of people and provide good leadership, a good manager cannot •ensure the success of the project, but can increase the probability of success. The areas to be given priority are: proper selection, training, compensation, career development, work culture •etc.Managers face challenges. It requires mental toughness to endure inner pain. •We need to plan for the best, be prepared for the worst, expect surprises, but continue to move forward •anyway. Charles Maurice once rightly said “I am more afraid of an army of one hundred sheep led by a lion than an army •of one hundred lions led by a sheep”.Hence, manager selection is most crucial and critical. After having a good manager, project is in safe hands. •It is the responsibility of a manager to manage, motivate, encourage, guide and control the people of his/her •team.

The productObjectivesandscopeofworkshouldbedefinedclearlytounderstandtherequirements.Alternatesolutions•should be discussed. It may help the managers to select a “best” approach within constraints imposed by delivery deadlines, budgetary •restrictions, personnel availability, technical interfaces etc. Withoutwelldefinedrequirements,itmaybeimpossibletodefinereasonableestimatesofthecost,development•time and schedule for the project.


54

The processThe process is the way in which we produce software. •It provides the framework from which a comprehensive plan for software development can be established. If •the process is weak, the end product will undoubtedly suffer.There are many life cycle models and process improvements models. •Depending on the type of project, a suitable model is to be selected. •Now-a-days CMM (Capability Maturity Model) has become almost a standard for process framework. •The process priority is after people and product, however, it plays very critical role for the success of the •project.

The projectA proper planning is required to monitor the status of development and to control the complexity. •Mostoftheprojectsarecominglatewithcostoverrunsofmorethan100%.•In order to manage a successful project, we must understand what can go wrong and how to do it right. •Weshoulddefineconcreterequirementsalthoughverydifficultandfreezetheserequirements.•Changes should not be incorporated to avoid software surprises. Software surprises are always risky and we •should minimise them.All four factors People, Product, Process and Project are important for the success of the project.•

4.6 Problem AnalysisThe basic aim of problem analysis is to obtain a clear understanding of the needs of the clients and the users, what exactly is desired from the software.

Frequently the client and the users do not understand or know all their needs, because the potential of the new •system is often not fully appreciated. The analysts have to ensure that the real needs of the clients and the users are uncovered, even if they don’t •know them clearly. That is, the analysts are not just collecting and organising information about the client’s organisation and its •processes, but they also act as consultants who play an active role of helping the clients and users identify their needs.

Informal approachTheinformalapproachtoanalysisisonewherenodefinedmethodologyisused.•Like in any approach, the information about the system is obtained by interaction with the client, end users, •questionnaires, study of existing documents, brainstorming, etc. However, with this approach no formal model is built of the system. •The problem and the system model are essentially built in the minds of the analysts or the analysts may use some •informal notation for this purpose and are directly translated from the minds of the analysts to the SRS.

Data flow modelingData-flow based modeling, often referred to as the structured analysis technique, uses function-based •decomposition while modeling the problem. It focuses on the functions performed in the problem domain and the data consumed and produced by these •functions. Itisatop-downrefinementapproach,whichwasoriginallycalledstructuredanalysisandspecification,and•wasproposedforproducingthespecifications.However,wewilllimitourattentiontotheanalysisaspectofthe approach.

55

Beforewedescribe theapproach, letus describe thedataflowdiagramanddatadictionaryonwhich the•technique relies heavily.

An exampleArestaurantownerfeels thatsomeamountofautomationwillhelpmakeherbusinessmoreefficient.Shealsobelieves that an automated system might be an added attraction for the customers. So she wants to automate the operation of her restaurant as much as possible. Here we will perform the analysis for this problem. Details regarding interviews, questionnaires, or how the information was extracted are not described. First let us identify the different parties involved.

Client: The restaurant owner•Potential Users: Waiters, cash register operator•

Thecontextdiagramfortherestaurantisshowninfiguregiven.Theinputsandoutputsoftherestaurantareshownin this diagram. However, no details about the functioning of the restaurant are given here.

Usingthisasastartingpoint,alogicalDFDofthephysicalsystemisgiveninfigurebelow(thephysicalDFDwasavoided for this, as the logical DFD is similar to the physical and there were no special names for the data or the processes in the physical system).

Observing the operation of the restaurant and interviewing the owner were the basic means of collecting raw information for this DFD. Now we must draw a DFD that models the new system to be built. After many meetings and discussions with the restaurant owner, the following goals for the new system were established:

Automate much of the order processing and billing.•Automate accounting.•

Make supply ordering more accurate so that leftovers at the end of the day are minimised and the orders that cannot besatisfiedduetonoavailabilityarealsominimised.Thiswasbeingdonewithoutacarefulanalysisofsales.

Supplier

Customer

Restaurants

Order for supplies

Supplies

Menu

Payment

Order

Receipt

Final Bill

Served Meals

Sale Information

Supplies information

Fig. 4.6 Context diagram for the restaurant


56

The owner also suspects that the staff might be stealing/eating some food/supplies. She wants the new system •to help detect and reduce this.The owner would also like to have statistics about sales of different items.•

4.7 Requirement SpecificationThefinaloutputisthesoftwarerequirementsspecificationdocument(SRS).Forsmallerproblemsorproblemsthatcaneasilybecomprehended,thespecificationactivitymightcomeaftertheentireanalysisiscomplete.However,itismorelikelythatproblemanalysisandspecificationaredoneconcurrently.

An analyst typically will analyse some parts of the problem and then write the requirements for that part.•In practice, problemanalysis and requirements specification activities overlap,withmovement fromboth•activities to the other. However,astheinformationforspecificationcomesfromanalysis,wecanconceptuallyviewthespecification•activity as following the analysis activity. Thefirstquestionthatarisesis:Ifformalmodelingisdoneduringanalysis,whyaretheoutputsofmodelingthe•structures that are built (for example, DFD and DD, Object diagrams) not treated as an SRS? The main reason is that modeling generally focuses on the problem structure, not its external behaviour. •Consequently, things like user interfaces are rarely modelled, whereas they frequently form a major component •of the SRS. Similarly, for ease of modeling, frequently “minor issues” like erroneous situations (e.g., error in output) are •rarelymodelledproperly,whereasinanSRS,behaviourundersuchsituationsalsohastobespecified.Similarly, performance constraints, design constraints, standards compliance, recovery, etc., are not included •inthemodel,butmustbespecifiedclearlyintheSRSbecausethedesignermustknowaboutthesetoproperlydesign the system. It should therefore be clear that the outputs of a model cannot form a desirable SRS. •Forthesereasons,thetransitionfromanalysistospecificationshouldalsonotbeexpectedtobestraightforward,•even if some formal modeling is used during analysis. Itisnotthecasethatinspecificationthestructuresofmodelingarejustspecifiedinamoreformalmanner.• A good SRS needs to specify many things, some of which are not satisfactorily handled during modeling. •Furthermore, sometimes the structures produced during modeling are not amenable for translation into external •behaviourspecification(whichiswhatistobespecifiedinanSRS).For example, the object diagram produced during a 00 analysis is of limited use when specifying the external •behaviour of the desired system.Essentially,what passes from requirements analysis activity to the specification activity is the knowledge•acquired about the system. The modeling is essentially a tool to help obtain a thorough and complete knowledge about the proposed •system. The SRS is written based on the knowledge acquired during analysis. •Asconvertingknowledgeintoastructureddocumentisnotstraightforward,specificationitselfisamajortask,•which is relatively independent. A consequence of this is that it is relatively less important to model “completely,” compared to specifying •completely. As the primary objective of analysis is problem understanding, while the basic objective of the requirements •phase is to produce the SRS, the complete and detailed analysis structures are not critical. In fact, it is possible to develop the SRS without using formal modeling techniques. •The basic aim of the structures used in modeling is to help in knowledge representation and problem partitioning; •the structures are not an end in themselves.

57

Withthisinmind,letusstartourdiscussiononrequirementsspecification.Westartbydiscussingthedesirable•characteristics of an SRS.

Characteristics of an SRSTo properly satisfy the basic goals, an SRS should have certain properties and should contain different types of requirements.

In this section, we discuss some of the desirable characteristics of an SRS and components of an SRS. A good •SRS is:

Correct �Complete �Unambiguous �Verifiable �Consistent �Ranked for importance and/or stability �Modifiable �Traceable �

AnSRSiscorrectifeveryrequirementincludedintheSRSrepresentssomethingrequiredinthefinalsystem.•An SRS is complete if everything the software is supposed to do and the responses of the software to all classes ofinputdataarespecifiedintheSRS.Correctnessandcompletenessgohand-in-hand;whereascorrectnessensures thatwhat is specified isdone•correctly,completenessensuresthateverythingisindeedspecified.Correctness is an easier property to establish than completeness as it basically involves examining each •requirement to make sure it represents the user requirement. Completeness,ontheotherhand,isthemostdifficultpropertytoestablish;toensurecompleteness,onehas•todetecttheabsenceofspecifications,andabsenceismuchhardertoascertainthandeterminingthatwhatispresent has some property.An SRS is unambiguous if and only if every requirement stated has one and only one interpretation. •Requirements are often written in natural language, which are inherently ambiguous. If the requirements •are specified inanatural language, theSRSwriterhas tobeespeciallycareful toensure that therearenoambiguities. Onewaytoavoidambiguitiesistousesomeformalrequirementsspecificationlanguage.Themajordisadvantage•of using formal languages is the large effort required to write an SRS, the high cost of doing so, and the increased difficultyreadingandunderstandingformallystatedrequirements(particularlybytheusersandclients).AnSRSisverifiableifandonlyifeverystatedrequirementisverifiable.Arequirementisverifiableifthere•existsomecost-effectiveprocessthatcancheckwhetherthefinalsoftwaremeetsthatrequirement.Thisimpliesthattherequirementsshouldhaveaslittlesubjectivityaspossiblebecausesubjectiverequirementsaredifficultto verify. Unambiguityisessentialforverifiability.Asverificationofrequirementsisoftendonethroughreviews,italso•implies that an SRS is understandable, at least by the developer, the client, and the users.Understand ability is clearly extremely important, as one of the goals of the requirements phase is to produce •a document on which the client, the users, and the developers can agree. An SRS is consistent if there is no requirementthatconflictswithanother.Terminology can cause inconsistencies; for example, different requirements may use different terms to refer •to the same object.Theremaybelogicalortemporalconflictbetweenrequirementsthatcausesinconsistencies.Thisoccursifthe•SRScontainstwoormorerequirementswhoselogicalortemporalcharacteristicscannotbesatisfiedtogetherby any software system.


58

For example, suppose a requirement states that an event • e is to occur before another event f. But then another set of requirements states (directly or indirectly by transitivity) that event f should occur before event e. InconsistenciesinanSRScanreflectofsomemajorproblems.Generally,alltherequirementsforsoftwareare•not of equal importance.Some are critical, others are important but not critical, and there are some which are desirable but not very •important. Similarly, some requirements are “core” requirements which are not likely to change as time passes, while others are more dependent on time. An SRS is ranked for importance and/or stability if for each requirement the importance and the stability of the •requirement are indicated. Stabilityofarequirementreflectsthechancesofitchanginginfuture.Itcanbereflectedintermsoftheexpected•change volume.WritinganSRSisaniterativeprocess.Evenwhentherequirementsofasystemarespecified,theyarelater•modifiedastheneedsoftheclientchange.HenceanSRSshouldbeeasytomodify.AnSRSismodifiableifitsstructureandstylearesuchthatanynecessarychangecanbemadeeasilywhile•preserving completeness and consistency. Presenceofredundancyisamajorhindrancetomodifiability,asitcaneasilyleadtoerrors.Forexample,assume•that a requirement is stated in two places and that the requirement later needs to be changed. Ifonlyoneoccurrenceoftherequirementismodified,theresultingSRSwillbeinconsistent.AnSRSistraceable•if the origin of each of its requirements is clear and if it facilitates the referencing of each requirement in future development. Forward traceability means that each requirement should be traceable to some design and code elements. •Backward traceability requires that it be possible to trace design and code elements to the requirements they support. Traceability aidsverification andvalidation.Of all these characteristics, completeness is perhaps themost•important (and hardest to ensure). Oneofthemostcommonproblemsinrequirementsspecificationiswhensomeoftherequirementsoftheclient•arenotspecified.Thisnecessitatesadditionsandmodificationstotherequirementslaterinthedevelopmentcycle, which are often expensive to incorporate. Incompleteness is also a major source of disagreement between the client and the supplier. The importance of •having complete requirements cannot be overemphasised will help in completely specifying the requirements. Here we describe some of the system properties that an SRS should specify. The basic issues an SRS must address are:

Functionality �Performance �Design constraints imposed on an implementation �External interfaces �

Conceptually, any SRS should have these components. If the traditional approach to requirement analysis is being •followed, then the SRS might even have portions corresponding to these. However, functional requirements mightbespecifiedindirectlybyspecifyingtheservicesontheobjectsorbyspecifyingtheusecases.

59

Summary The simplest software development life cycle model is the waterfall model, which states that the phases are •organised in a linear order. Theoutputofaprojectemployingthewaterfallmodelisnotjustthefinalprogramalongwithdocumentation•to use it. There are a number of intermediate outputs, which must be produced in order to produce a successful product.Thewaterfallmodel stipulates that the requirements shouldbe completely specifiedbefore the rest of the•developmentcanproceed.Insomesituationsitmightbedesirabletofirstdevelopapartofthesystemcompletely,and then later enhance the system in phase. This is often done for software products that are developed not necessarilyforaclient(wheretheclientplaysanimportantroleinrequirementspecification),butforgeneralmarketing, in which the requirements are likely to be determined largely by developers.Thegoalofprototypingbaseddevelopmentistocounterthefirsttwolimitationsofthewaterfallmodeldiscussed•earlier. The basic idea here is that instead of freezing the requirements before a design or coding can proceed, a throwaway •prototype is built to understand the requirements. This prototype is developed based on the currently known requirements. The iterative enhancement life cycle model counters the third limitation of the waterfall model and tries to •combinethebenefitsofbothprototypingandthewaterfallmodel.The spiral has many cycles. The radial dimension represents the cumulative cost incurred in accomplishing •the steps dome so far and the angular dimension represents the progress made in completing each cycle of the spiral. Engineeringactivitiesperformedinthisquadrantselectanalternativeapproachthatbestsatisfiestechnical,•technology, cost, schedule, support, and risk constraints. The focus here is on risk mitigation. The spiral development model has one characteristic that is common to all models the need for advanced technical •planning and multidisciplinary reviews at critical staging or control points. Software development is a people centric activity. Hence, success of the project is on the shoulders of the people •who are involved in the development.The basic aim of problem analysis is to obtain a clear understanding of the needs of the clients and the users, •what exactly is desired from the software.Theinformalapproachtoanalysisisonewherenodefinedmethodologyisused.•Data-flow based modeling, often referred to as the structured analysis technique, uses function-based •decomposition while modeling the problem. It focuses on the functions performed in the problem domain and the data consumed and produced by these •functions. Thefinaloutputisthesoftwarerequirementsspecificationdocument(SRS).Forsmallerproblemsorproblems•thatcaneasilybecomprehended,thespecificationactivitymightcomeaftertheentireanalysisiscomplete.However,itismorelikelythatproblemanalysisandspecificationaredoneconcurrently.

ReferencesWiegers, E. K., 2009. • Software Requirements, 2nd ed., O’Reilly Media, Inc.Lauesen, S., 2002. • Software requirements: styles and techniques, Addison-Wesley.Freetutes.com, • Waterfall Software Development Life Cycle Model [Online] Available at: <http://www.freetutes.com/systemanalysis/sa2-waterfall-software-life-cycle.html> [Accessed 7 October 2011].OneStopTesting.com, 2003. • Iterative Model [Online] Available at: <http://www.onestoptesting.com/sdlc-models/iterative-model.asp> [Accessed 7 November 2011].LesChambers1, 2011. • Specifying Software Requirements [Video online] Available at: <http://www.youtube.com/watch?v=SBfBq5DmxD8> [Accessed 7 October 2011].


60

Prof. Bellur, U., 2008. • Requirements Engineering / Specification [Video online] Available at: <http://www.youtube.com/watch?v=wEr6mwquPLY&feature=related> [Accessed 7 November 2011].

Recommended ReadingKotonya, G. and Sommerville, I., 1998. • Requirements engineering: processes and techniques, J. Wiley.Sommerville, I. and Sawyer, P., 1997. • Requirements engineering: a good practice guide, John Wiley & Sons.Young, R. R., 2004• . The requirements engineering handbook, Artech House.

61

Self AssessmentThe simplest software development life cycle model is the waterfall model, which states that the phases are 1. organised in a __________ order.

lineara. non-linear b. random c. casual d.

The ______________ enhancement life cycle model counters the limitation of the waterfall model and tries to 2. combinethebenefitsofbothprototypingandthewaterfallmodel.

Iterativea. Data modelling b. SDLC c. RAPd.

Who proposed the Spiral model?3. Bella. Newton b. Boehmc. Philip Abelsond.

Which of the following is true? 4. The spiral has 2 cycle a. The spiral has square shapeb. The spiral has many cyclesc. The spiral is pentagond.

The management of ____________________ is heavily dependent on four factors which are people, product, 5. process, and project.

software tool a. software design b. software developmentc. software codingd.

It is the responsibility of a _____________ to manage, motivate, encourage, guide and control the people of 6. his/her team.

organiser a. developerb. designerc. managerd.

Process is the way in which we produce_____________.7. hardware a. software b. design c. code d.


62

In order to manage a_________________, we must understand what can go wrong and how to do it right. 8. successful projecta. coding b. people c. product d.

The basic aim of ___________ is to obtain a clear understanding of the needs of the clients and the users, what 9. exactly is desired from the software.

data model a. software b. informal approach c. problem analysisd.

The_____________toanalysisisonewherenodefinedmethodologyisused.10. data model a. software b. informal approach c. problem analysisd.

63

Chapter V

System Design

Aim


explain the concept of problem partitioning •

elucidate concept of abstraction •

discuss the top-down design •

Objectives


explain structural approach •

compare function vs object oriented approach •

enlistdesignspecification•

Learning outcome


understandtheconceptofdesignverification•

discusssamplechecklistofdesignverification•

describe bottom-up design •


64

5.1 Problem PartitioningWhen solving a small problem, the entire problem can be tackled at once. The complexity of large problems and the limitations of human minds do not allow large problems to be treated as huge monoliths.

For solving larger problems, the basic principle is the time-tested principle of “divide and conquer.” Clearly, •dividing in such a manner that all the divisions have to be conquered together is not the intent of this wisdom. This principle, if elaborated, would mean “divide into smaller pieces, so that each piece can be conquered separately.” For software design, therefore, the goal is to divide the problem into manageably small pieces that can be solved •separately. It is this restriction of being able to solve each part separately that makes dividing into pieces a complex task and that many methodologies for system design aim to address. The basic rationale behind this strategy is the behalf that if the pieces of a problem are solvable separately, the •cost of solving the entire problem is more than the sum of the cost of solving all the pieces.However, the different pieces cannot be entirely independent of each other, as they together form the system. •The different pieces have to cooperate and communicate to solve the larger problem. This communication adds complexity, which arises due to partitioning and may not have existed in the original problem. As the number of components increases, the cost of partitioning, together with the cost of this added complexity, •may become more than the savings achieved by partitioning. It is at this point that no further partitioning needs to be done. The designer has to make the judgment about when to stop partitioning. As discussed earlier, two of the most •important quality criteria for software design are simplicity and understand ability. It can be argued that maintenance is minimised if each part in the system can be easily related to the application •andeachpiececanbemodifiedseparately.Ifapiececanbemodifiedseparately,wecallitindependentofotherpieces.IfmoduleAisindependentof•module B, then we can modify A without introducing any unanticipated side effects in B. Total independence of modules of one system is not •possible, but the design process should support as much independence as possible between modules. Dependence between modules in a software system is one of the reasons for high maintenance costs. •Clearly, proper partitioning will make the system easier to maintain by making the design easier to understand. •Problempartitioningalsoaidsdesignverification.Problem partitioning, which is essential for solving a complex problem, leads to hierarchies in the design. That •is, the design produced by using problem partitioning can be represented as a hierarchy of components. The relationship between the elements in this hierarchy can vary depending on the method used. For example, •the most common is the “whole-part of” relationship. In this, the system consists of some parts; each part consists of subparts, and so on. This relationship can be naturally represented as a hierarchical structure between various system parts. In general, hierarchical structure makes it much easier to comprehend a complex system. Due to this, all design •methodologies aim to produce a design that employs hierarchical structures.

5.2 AbstractionAbstraction is a very powerful concept that is used in all engineering disciplines. It is a tool that permits a designer to consider a component at an abstract level without worrying about the details of the implementation of the component. Any component or system provides some services to its environment.

An abstraction of a component describes the external behaviour of that component without bothering with the •internaldetailsthatproducethebehaviour.Presumably,theabstractdefinitionofacomponentismuchsimplerthan the component itself. Abstraction is an indispensable part of the design process and is essential for problem partitioning. Partitioning •essentially is the exercise in determining the components of a system. However, these components are not isolated from each other; they interact with each other, and the designer has to specify how a component interacts with other components.

65

To decide how a component interacts with other components, the designer has to know, at the very least, the •external behaviour of other components. If the designer has to understand the details of the other components to determine their external behaviour, we have defeated the purpose of partitioning isolating a component from others. To allow the designer to concentrate on one component at a time, abstraction of other components is used. •Abstraction is used for existing components as well as components that are being designed. •Abstractionofexistingcomponentsplaysanimportantroleinthemaintenancephase.Tomodifyasystem,thefirst•step is understanding what the system does and how. The process of comprehending an existing system involves identifying the abstractions of subsystems and components from the details of their implementations. Using these abstractions, the behaviour of the entire system can be understood. This also helps determine how •modifying a component affects the system. During the design process, abstractions are used in the reverse manner than in the process of understanding a •system.Duringdesign,thecomponentsdonotexist,andinthedesignthedesignerspecifiesonlytheabstractspecificationsofthedifferentcomponents.The basic goal of system design is to specify the modules in a system and their abstractions. Once the different •modulesarespecified,duringthedetaileddesignthedesignercanconcentrateononemoduleatatime.The task in detailed design and implementation is essentially to implement the modules so that the abstract •specificationsofeachmodulearesatisfied.There are two common abstraction mechanisms for software systems: functional abstraction and data •abstraction.Infunctionalabstraction,amoduleisspecifiedbythefunctionitperforms.Forexample,amoduletocompute•the log of a value can be abstractly represented by the function log. Similarly, a module to sort an input array canberepresentedbythespecificationofsorting.Fictionalabstractionisthebasisofpartitioninginfunction-oriented approaches. That is, when the problem is being partitioned, the overall transformation function for the system is partitioned into smaller functions that comprise the system function. The decomposition of the system is in terms of functional modules. The second unit for abstraction is data •abstraction. Any entity in the real world provides some services to the environment to which it belongs. Oftentheentitiesprovidesomefixedpredefinedservices.Thecaseofdataentitiesissimilar.Certainoperations•are required from a data object, depending on the object and the environment in which it is used. Data abstraction supports this view. Data is not treated simply as objects, but is treated as objects with some •predefinedoperationsonthem.Theoperationsdefinedonadataobjectaretheonlyoperationsthatcanbeperformedonthoseobjects.•From outside an object, the internals of the object are hidden; only the operations on the object are visible.•In using this abstraction, a system is viewed as a set of objects providing some services. Hence, the decomposition •of the system is done with respect to the objects the system contains.

5.3 Top-Down and Bottom-Up DesignA system consists of components, which have components of their own; indeed a system is a hierarchy of components. The highest-level component corresponds to the total system.

To design such a hierarchy there are two possible approaches: top-down and bottom-up. The top-down approach •starts from the highest-level component of the hierarchy and proceeds through to lower levels. By contrast, a bottom-up approach starts with the lowest-level component of the hierarchy and proceeds through •progressively higher levels to the top-level component. A top-down design approach starts by identifying the major components of the system, decomposing them into •their lower-level components and iterating until the desired level of detail is achieved. Top-downdesignmethodsoftenresultinsomeformofstepwiserefinementstartingfromanabstractdesign,•ineachstepthedesignisrefinedtoamoreconcretelevel,untilwereachalevelwherenomorerefinementisneeded and the design can be implemented directly.


66

The top-down approach has been promulgated by many researchers and has been found to be extremely useful •for design. Most design methodologies are based on the top-down approach. A bottom-up design approach starts with •designing the most basic or primitive components and proceeds to higher-level components that use these lower-level components. Bottom-up methods work with layers of abstraction. Starting from the very bottom, operations that provide a •layer of abstraction are implemented. The operations of this layer are then used to implement more powerful operations and a still higher layer of •abstraction, until the stage is reached where the operations supported by the layer are those desired by the system. Atop-downapproach issuitableonly if thespecificationsof thesystemareclearlyknownand thesystem•development is from scratch. However, if a system is to be built from an existing system, a bottom-up approach is more suitable, as it starts from some existing components. So, for example, if an iterative enhancement type ofprocessisbeingfollowed,inlateriterations,thebottom-upapproachcouldbemoresuitable(inthefirstiteration a top down approach can be used). Pure top-down or pure bottom-up approaches are often not practical. For a bottom-up approach to be successful, •we must have a good notion of the top to which the design should be heading. Withoutagoodideaabouttheoperationsneededatthehigherlayers,itisdifficulttodeterminewhatoperations•the current layer should support. Top-downapproachesrequiresomeideaaboutthefeasibilityofthecomponentsspecifiedduringdesign.The•componentsspecifiedduringdesignshouldbeimplementable,whichrequiressomeideaaboutthefeasibilityof the lower-level parts of a component. A common approach to combine the two approaches is to provide a layer of abstraction for the application domain •of interest through libraries of functions, which contains the functions of interest to the application domain. Then use a top-down approach to determine the modules in the system, assuming that the abstract machine •available for implementing the system provides the operations supported by the abstraction layer. This approach is frequently used for developing systems. It can even be claimed that it is almost universally used these days, as most developments now make use of the •layer of abstraction supported in a system consisting of the library functions provided by operating systems, programming languages, and special-purpose tools.

5.4 Structured ApproachCreating a software system design is a major concern of the design phase. Many design techniques have been proposed over the years to provide some discipline in handling the complexity of designing large systems.

The aim of design methodologies is not to reduce the process of design to a sequence of mechanical steps but •to provide guidelines to aid the designer during the design process. Here we describe the structured design methodology for developing system designs.Structured design methodology (SDM) views every software system as having some inputs that are converted •into the desired outputs by the software system. The software is viewed as a transformation function that transforms the given inputs into the desired outputs, •and the central problem of designing software systems is considered to be properly designing this transformation function. Due to this view of software, the structured design methodology is primarily function-oriented and relies heavily •on functional abstraction and functional decomposition.The concept of structure of program lies at the heart of a structured design method. During design, structured •designmethodologyaimstocontrolandinfluencethestructureofafinalprogram.The aim is to design a system so that programs implementing the design would have a hierarchical structure, •with functionally cohesive modules and as few interconnections between modules as possible.

67

In properly designed systems it is often the case that a module with subordinates does not actually perform much •computation. The bulk of actual computation is performed by its subordinates, and the module itself largely coordinatesthedataflowbetweenthesubordinatestogetthecomputationdone.The subordinates in turn can get the bulk of their work done by their subordinates until the “atomic” modules, •which have no subordinates, are reached. Factoring is the process of decomposing a module so that the bulk of its work is done by its subordinates. A system is said to be completely factored if all the actual processing is accomplished by bottom-level atomic •modules and if non-atomic modules largely perform the jobs of control and coordination. SDM attempts to achieve a structure that is close to being completely factored.The overall strategy is to identify the input and output streams and the primary transformations that have to be •performed to produce the output. High-level modules are then created to perform these major activities, which arelaterrefined.Therearefourmajorstepsinthisstrategy:

Restatetheproblemasadataflowdiagram �Identify the input and output data elements �First-level factoring �Factoring of input, output, and transform branches �

We will now discuss each of these steps in more detail. The design of the case study using structured design •will be given later. For illustrating each step of the methodology as we discuss them, we consider the following problem:Thereisatextfilecontainingwordsseparatedbyblanksornewfines.Wehavetodesignasoftwaresystemto•determinethenumberofuniquewordsinthefile.

5.5 Function v/s Object Oriented ApproachThe following are some of the important differences between function-oriented and object oriented design.

Unlike function-oriented design methods, in OOD, the basic abstractions are not real world functions such as sort, •display, track, etc, but real-world entities such as employee, picture, machine, radar system, etc. For example in OOD, an employee pay-roll software is not developed by designing functions such as update-employee record, get-employee-address, etc. but by designing objects such as employees, departments, etc. In object-oriented design, software is not developed by designing functions such as update-employee-record, •get-employee-address, etc., but by designing objects such as employee, department, etc. In OOD, state information is not represented in a centralised shared memory but is distributed among the objects •of the system. For example, while developing an employee pay-roll system, the employee data such as the names of the •employees, their code numbers, basic salaries, etc. are usually implemented as global data in a traditional programming system; whereas in an object-oriented system these data are distributed among different employee objects of the system. Objects communicate by passing messages. Therefore, one object may discover the state information of another object by interrogating it. Of course, somewhere or the other the real-world functions must be implemented. •Function-oriented techniques such as SA/SD group functions together if, as a group, they constitute a higher-•level function. On the other hand, object-oriented techniques group functions together on the basis of the data they operate on.

To illustrate the differences between object-oriented and function-oriented design approaches, an example can be considered.


68

5.6 Design Specification and VerificationDesignspecificationandverificationisexplainedbelow:SpecificationUsing some design rules or methodology, a conceptual design of the system can be produced in terms of a structure chart.

As seen earlier, in a structure chart each module is represented by a box with a name. The functionality of the •module is essentially communicated by the name of the box, and the interface is communicated by the data items labelling the arrows. This is alright while the designer is designing but inadequate when the design is to be communicated. Toavoid theseproblems,adesignspecificationshoulddefine themajordata structures,modulesand their•specifications,anddesigndecisions.Duringsystemdesign,themajordatastructuresforsoftwareareidentified;withoutthese,thesystemmodules•cannotbemeaningfullydefinedduringdesign.Inthedesignspecification,aformaldefinitionofthesedatastructuresshouldbegiven.•Modulespecificationisthemajorpartofsystemdesignspecification.•Allmodulesinthesystemshouldbeidentifiedwhenthesystemdesigniscomplete,andthesemodulesshould•bespecifiedinthedocument.Duringsystemdesignonlymodulespecificationisobtained,becausetheinternaldetailsofmodulesaredefined•later. To specify a module, the design document must specify:•

The interface of module (all data items, their types, and whether they are for input and/or output), �The abstract behaviour of module (what the module does) by specifying the module’s functionality or its �input/output behaviour, and Allothermodulesusedbythemodulebeingspecifiedthisinformationisquiteusefulinmaintainingand �understanding the design.

Hence,adesignspecificationwillnecessarilycontainspecificationofthemajordatastructuresandmodules•in the system. Afteradesignisapproved(usingsomeverificationmechanism),moduleswillhavetobeimplementedinthe•targetlanguage.Thisrequiresthatthemodule“headers”forthetargetlanguagefirstbecreatedfromthedesign.This translation of design for the target language can introduce errors if it’s done manually. To eliminate these translation errors, if the target language is known (as is generally the case after the requirements •havebeenspecified),itisbettertohaveadesignspecificationlanguagewhosemodulespecificationscanbeused almost directly in programming. This not only minimises the translation errors that may occur, but also reduces the effort required for translating the design to programs. It also adds incentive for designers to properly specify their design, as the design is no longer a “mere” document •that will be thrown away after review it will now be used directly in coding. Inthecasestudy,adesignspecificationlanguageclosetoChasbeenused.Promthedesign,themoduleheaders•for C can easily be created with some simple editing.To aid the comprehensibility of design, all major design decisions made by the designers during the design •process should be explained explicitly. The choices that were available and the reasons for making a particular choice should be explained. This makes •a design more visible and will help in understanding the design.

VerificationTheoutputofthesystemdesignphase,liketheoutputofotherphasesinthedevelopmentprocess,shouldbeverifiedbefore proceeding with the activities of next phase.

If the design is expressed in some formal notation for which analysis tools are available, then through tools it can •becheckedforinternalconsistencye.g.,thosemodulesusedbyanotheraredefined,theinterfaceofamoduleis consistent with the way others use it, data usage is consistent with declaration, etc.

69

Ifthedesignisnotspecifiedinaformal,executablelanguage,itcannotbeprocessedthroughtools,andother•meansforverificationhavetobeused.Themostcommonapproachforverificationisdesignrevieworinspections.Wediscussthisapproachhere.•Thepurposeofdesignreviewsistoensurethatthedesignsatisfiestherequirementsandisof“goodquality.”•Iferrorsaremadeduringthedesignprocess,theywillultimatelyreflectthemselvesinthecodeandthefinal•system. As the cost of removing faults caused by errors that occur during design increases with the delay in detecting •the errors, it is best if design errors are detected early, before they manifest themselves in the system. Detecting errors in design is the purpose of design reviews. The system design review process is similar to the •inspection process, in that a group of people get together to discuss the design with the aim of revealing design errors or undesirable properties. The review group must include a member of both the system design team and detailed design team, the author of •requirements document, the author responsible for maintaining design document, and an independent software quality engineer. As with any review, it should be kept in mind that the aim of the meeting is to uncover design errors not to try •tofixthem;fixingisdonelater.The number of ways in which errors can come in a design is limited only by the creativity of the designer. •However, there are some forms of errors that are more often observed.Perhapsthemostsignificantdesignerrorisomissionormisinterpretationofspecifiedrequirements.•Clearly,ifthesystemdesignerhasmisinterpretedornotaccountedforsomerequirementitwillbereflectedlater•as a fault in the system. Sometimes, this design error is caused by ambiguities in the requirements.There are some other quality factors that are not strictly design errors but that have implications on the reliability •and maintainability of the system. An example of this is weak modularity (that is, weak cohesion and/or strong coupling). Duringreviews,elementsofdesignthatarenotconducivetomodificationandexpansionorelementsthatfail•to conform to design standards should also be considered “errors.”

A sample checklistThe use of checklists can be extremely useful for any review. The checklist can be used by each member during private study of the design and during review meeting. For best results the checklist should be tailored to the project athand,touncoverproblem-specificerrors.Herewelistafewgeneralitemsthatcanbeusedtoconstructachecklistfor a design review:

Is each of the functional requirements taken into account?•Are there analyses to demonstrate that performance requirements can be met?•Are all assumptions explicitly stated, and are they acceptable?•Are there any limitations or constraints on the design beyond those in the requirements?•Areexternalspecificationsofeachmodulecompletelyspecified?•Have exceptional conditions been handled?•Are all the data formats consistent with the requirements?•Are the operator and user interfaces properly addressed?•Is the design modular, and does it conform to local sta• ndards?Arethesizesofdatastructuresestimated?Areprovisionsmadetoguardagainstoverflow?•


70

Summary When solving a small problem, the entire problem can be tackled at once. The complexity of large problems •and limitations of human minds do not allow large problems to be treated as huge monoliths. For solving larger problems, the basic principle is the time-tested principle of “divide and conquer.” This principle, •if elaborated, would mean “divide into smaller pieces, so that each piece can be conquered separately.” For software design, therefore, the goal is to divide the problem into manageably small pieces that can be solved •separately. It is this restriction of being able to solve each part separately that makes dividing into pieces a complex task and that many methodologies for system design aim to address. Problem partitioning, which is essential for solving a complex problem, leads to hierarchies in the design. That •is, the design produced by using problem partitioning can be represented as a hierarchy of components. Abstraction is a very powerful concept that is used in all engineering disciplines. It is a tool that permits a •designer to consider a component at an abstract level without worrying about the details of the implementation of the component. An abstraction of a component describes the external behaviour of that component without bothering with the •internal details that produce the behaviour. A system consists of components, which have components of their own; indeed a system is a hierarchy of •components. The highest-level component corresponds to the total system. To design such a hierarchy there are two possible approaches: top-down and bottom-up. •The top-down approach starts from the highest-level component of the hierarchy and proceeds through to lower •levels. Creating the software system design is the major concern of the design phase. Many design techniques have been •proposed over the years to provide some discipline in handling the complexity of designing large systems. The aim of design methodologies is not to reduce the process of design to a sequence of mechanical steps but •to provide guidelines to aid the designer during the design process. Here we describe the structured design methodology for developing system designs.Unlike function-oriented design methods, in OOD, the basic abstractions are not real world functions such as •sort, display, track, etc, but real-world entities such as employee, picture, machine, radar system, etc. In object-oriented design, software is not developed by designing functions such as update-employee-record, •get-employee-address, etc., but by designing objects such as employee, department, etc.

ReferencesBruegge, B., 2004. • Object-Oriented Software Engineering: Using Uml, Patterns And Java, 2nd ed., Pearson Education India.Aggarwal, K. K., 2005. • Software engineering, New Age International.NYS Project Management Guidebook, • System Design [Pdf] Available at: <http://www.cio.ny.gov/pmmp/guidebook2/SystemDesign.pdf> [Accessed 7 November 2011].George, J., • Traditional versus Object-Oriented Approach [Online] Available at: <http://www.georgejojo.com/index.php?option=com_content&view=article&id=60:information-report-traditional-and-object-oriented-methodology-for-system-development> [Accessed 7 November 2011].Prof. Joshi, K. R., 2008. • Lecture - 14 Software Design - Primary Consideration [Video online] Available at: <http://www.youtube.com/watch?v=izAq05SBvMI> [Accessed 7 November 2011].Prof. Biswajit, 2011. • 20 - System Design – I [Video online] Available at: < http://www.youtube.com/watch?v=OM9uJuOtgE4&feature=results_video&playnext=1&list=PL0A0C5C062C10A3E5> [Accessed 7 November 2011].

71

Recommended ReadingPeters, F. J., 2007. • Software Engineering An Engineering Approach, Wiley-India.Sharma P., 2004. • Software Engineering, APH Publishing.Kelkar, A. S., 2007. • Software Engineering: A Concise Study, PHI Learning Pvt. Ltd.


72

Self Assessment______________ is a tool that permits a designer to consider a component at an abstract level without worrying 1. about the details of the implementation of the component.

Abstractiona. Problem partitioning b. Top-down c. Bottom- up d.

______________ of a component describes the external behaviour of that component without bothering with 2. the internal details that produce the behaviour.

Problem partitioning a. Top-down b. Abstractionc. Bottom-up d.

Abstraction is an indispensable part of the design process and is essential for______________ .3. problem partitioning a. top-down b. abstractionc. bottom- up d.

________________ is used for existing components as well as components that are being designed. 4. Problem partitioning a. Top-down b. Abstractionc. Bottom- up d.

Which of the following statements is true?5. Abstraction of existing components plays an important role in the design phase.a. Abstraction of existing components plays an important role in the maintenance phase.b. Abstraction of existing components plays an important role in the development phase.c. Abstraction of existing components plays an important role in the managing phase. d.

There are two common ____________ mechanisms for software systems that are functional abstraction and 6. data abstraction.

problem partitioning a. top-down b. abstractionc. bottom- up d.

A____________approachissuitableonlyifthespecificationsofthesystemareclearlyknownandthesystem7. development is from scratch.

Problem partitioning a. Top-down b. Abstractionc. Bottom- up d.

73

Which of the following statements is true? 8. Bottom-up methods work with layers of abstraction.a. Top-down methods work with layers of abstraction.b. Partitioning methods work with layers of abstraction.c. Data modelling methods work with layers of abstraction.d.

Structured design methodology views every ______________ as having some inputs that are converted into 9. the desired outputs by the software system.

hardware designa. software systemb. data model c. abstraction d.

In_________________ state information is not represented in a centralised shared memory but is distributed 10. among the objects of the system.

functional data structure a. object oriented b. data model c. software design d.


74

Chapter VI

Coding

Aim


explain the concept of top-down and bottom- up approach•

elucidate structured programming •

discuss information hiding •

Objectives


explain programming style •

explain internal documentation •

enlist the rules to make code easy•

Learning outcome


recognise control constructor •

identifyuserdefineddatatype•

understand the concept of naming conversion•

75

6.1 Top-Down and Bottom Up ApproachTop-down and bottom-up are strategies of information processing and knowledge ordering, mostly involving software,butalsootherhumanisticandscientifictheories.

In practice, they can be seen as a style of thinking and teaching. In many cases top-down is used as a synonym •of analysis or decomposition, and bottom-up of synthesis. A top-down approach is essentially breaking down a system to gain insight into its compositional sub-•systems. Inatop-downapproachanoverviewofthesystemisfirstformulated,specifyingbutnotdetailinganyfirst-level•subsystems. Eachsubsystemisthenrefinedinyetgreaterdetail,sometimesinmanyadditionalsubsystemlevels,untilthe•entirespecificationisreducedtobaseelements.Atopdownmodelisoftenspecifiedwiththeassistanceof“blackboxes”thatmakeiteasiertomanipulate.•However, black boxes may fail to elucidate elementary mechanisms or be detailed enough to realistically validate the model. A bottom-up approach is essentially piecing together systems to give rise to grander systems, thus making the •original systems sub-systems of the emergent system. Inabottom-upapproachindividualbaseelementsofthesystemarefirstspecifiedingreatdetail.•

6.2 Structured ProgrammingAs stated earlier the basic objective of coding activity is to produce programs that are easy to understand. It has been argued by many that structured programming practice helps develop programs that are easier to understand.

The structured programming movement started in the 1970s, and much has been said and written about it. •Now the concept pervades so much that it is generally accepted even implied that programming should be •structured. Though a lot of emphasis has been placed on structured programming, the concept and motivation behind structured programming are often not well understood. Structured programming is often regarded as “goto-less” programming. Although extensive use of gotos is •certainly not desirable, structured programs can be written with the use of gotos. Here we provide a brief discussion on what structured programming is. A program has a static structure as well •as a dynamic structure. Static structure is the structure of text of a program, which is usually just a linear organisation of statements of •the program. The dynamic structure of a program is the sequence of statements executed during the execution of the program. •In other words, both the static structure and dynamic behaviour are sequences of statements; where the sequence representingthestaticstructureofaprogramisfixed,thesequenceofstatementsitexecutescanchangefromexecution to execution. The general notion of correctness of a program means that when the program executes, it produces the desired •behaviour. To show that a program is correct, we need to show that when a program executes, its behaviour is what is •expected. Consequently, when we argue about a program, either formally to prove that it is correct or informally to debug •it or convince ourselves that it works, we study the static structure of the program (i.e., its code) but try to argue about its dynamic behaviour. In other words, much of the activity of program understanding is to understand the dynamic behaviour of the •program from the text of the program.It will clearly be easier to understand the dynamic behaviour if the structure in the dynamic behaviour resembles •the static structure.


76

The closer the correspondence between execution and text structure, the easier the program is to understand, •and the more different the structure during execution, the harder it will be to argue about the behaviour from the program text. The goal of structured programming is to ensure that the static structure and the dynamic structures are the same. •That is, the objective of structured programming is to write programs so that the sequence of statements executed during the execution of a program is the same as the sequence of statements in the text of that program. As the statements in a program text are linearly organised, the objective of structured programming becomes •developingprogramswhosecontrolflowduringexecutionislinearisedandfollowsthelinearorganisationofthe program text. Clearly, no meaningful program can be written as a sequence of simple statements without any branching •or repetition(whichalso involvesbranching).So,howis theobjectiveof linearsing thecontrolflowtobeachieved? By making use of structured constructs. In structured programming, a statement is not a simple assignment •statement, it is a structured statement. The key property of a structured statement is that it has a single-entry and a single-exit That is, during execution, •theexecutionofthe(structured)statementstartsfromonedefinedpointandtheexecutionterminatesatonedefinedpoint.Withsingle-entryandsingle-exitstatements,wecanviewaprogramasasequenceof(structured)statements. And if ah statements are structured statements, then during execution, the sequence of execution of these •statements will be the same as the sequence in the program text. Hence, by using single-entry and single-exit statements, the correspondence between the static and dynamic structures can be obtained. The most commonly used single-entry and single-exit statements are:•Selection: if B then S1 else S2if B then S1Iteration: While B do Srepeat S until BSequencing: S1; S2; S3;Itcanbeshownthatthesethreebasicconstructsaresufficienttoprogramanyconceivablealgorithm.•Modernlanguageshaveothersuchconstructsthathelplinearisedthecontrolflowofaprogram,which,generally•speaking, makes it easier to understand a program. Hence, programs should be written so that, as far as possible, single-entry, single-exit control constructs is used. The basic goal, as we have tried to emphasise, is to make the logic of the program simple to understand. •No hard-and-fast rule can be formulated that will be applicable under all circumstances. •Structured programming practice forms a good basis and guideline for writing programs clearly.•

6.3 Information HidingA software solution to a problem always contains data structures that are meant to represent information in the problem domain. That is, when software is developed to solve a problem, the software uses some data structures to capture the information in the problem domain.

In general, only certain operations are performed on some information. That is, a piece of information in the problem domain is used only in a limited number of ways in the problem domain.

Forexample,aledgerinanaccountant’sofficehassomemuchdefineduses:debit,credit,checkthecurrent•balance, etc. An operation where all debits are multiplied together and then divided by the sum of all credits is typically not •performed.

77

So,anyinformationintheproblemdomaintypicallyhasasmallnumberofdefinedoperationsperformedon•it. When the information is represented as data structures, the same principle should be applied, and only some definedoperationsshouldbeperformedonthedatastructures.This,essentially,istheprincipleofinformationhiding. The information captured in data structures should be hidden from the rest of the system, and only the access •functions on data structures that represent operations performed on information should be visible. In other words, when the information is captured in data structures and then on the data structures that represent •some information, for each operation on the information an access function should be provided. And as the rest ofthesystemintheproblemdomainonlyperformsthesedefinedoperationsontheinformation,therestofthemodules in the software should only use these access functions to access and manipulate the data structures. Information hiding can reduce the coupling between modules and make the system more maintainable. •Information hiding is also an effective tool for managing the complexity of developing software by using •information hiding we have separated the concern of managing the data from the concern of using the data to produce some desired results. Many of the older languages, like Pascal, C, and FORTRAN, do not provide mechanisms to support data •abstraction. With such languages, information hiding can be supported only by a disciplined use of the language. That is, the access restrictions will have to be imposed by the programmers; the language does not provide them. Most modern OO languages provide linguistic mechanisms to implement information hiding. •

6.4 Programming StyleThe concepts discussed above can help in writing simple and clear code with few bugs. There are many programming practices that can also help towards that objective. We discuss here a few rules that have been found to make code easier to read as well as avoid some of the errors.

Control constructs: As discussed earlier, it is desirable that as much as possible single-entry, single-exit constructs •be used. It is also desirable to use a few standard control constructs rather than using a wide variety of constructs, just because they are available in the language. Gotos: Gotos should be used sparingly and in a disciplined manner. Only when the alternative to using gotos •ismorecomplexshouldthegotosbeused.Inanycase,alternativesmustbethoughtofbeforefinallyusinga goto. If a goto must be used, forward transfers (or a jump to a later statement) are more acceptable than a backward jump. Information hiding: As discussed earlier, information hiding should be supported where possible. Only the •access functions for the data structures should be made visible while hiding the data structure behind these functions.User-definedtypes:Modernlanguagesallowuserstodefinetypesliketheenumeratedtype.Whensuchfacilities•are available, they should be exploited where applicable. For example, when working with dates, a type can bedefinedforthedayoftheweek.Usingsuchatypemakestheprogrammuchclearerthandefiningcodesforeach day and then working with codes.Nesting: If nesting of if-then-else constructs becomes too deep, then the logic become harder to understand. In •caseofdeeplynestedif-then-elses,itisoftendifficulttodeterminetheifstatementtowhichaparticularelseclauseisassociated.Wherepossible,deepnestingshouldbeavoided,evenifitmeansalittleinefficiency.Forexample, consider the following construct of nested if-then-elses:if C1 then S1;else if C2 then S2;else if C3 then S3;else if C4 then S4;


78

If the different conditions are disjoint (as they often are), this structure can be converted into the following structure:if C1 then S1;if C2 then S2;if C3 then S3;if C4 then S4;This sequence of statements will produce the same result as the earlier sequence (if the conditions are disjoint), •but it is much easier to understand. Thepriceisalittleinefficient.ModuleSize:Wediscussedthisissueduringsystemdesign.•A programmer should carefully examine any function with too many statements (say more than 100). •Large modules often will not be functionally cohesive. There can be no hard-and-fast rule about module sizes •the guiding principle should be cohesion and coupling.Module interface: A module with a complex interface should be carefully examined. As a rule of thumb, any •modulewhoseinterfacehasmorethanfiveparametersshouldbecarefullyexaminedandbrokenintomultiplemodules with a simpler interface if possible.Side effects: When a module is invoked, it sometimes has side effects of modifying the program state beyond •themodificationofparameterslistedinthemoduleinterfacedefinition,forexample,modifyingglobalvariables.Such side effects should be avoided where possible, and if a module has side effects, they should be properly documented.Robustness: A program is robust if it does something planned even for exceptional conditions. A program might •encounter exceptional conditions in such forms as incorrect input, the incorrect value of some variable, and overflow.Ifsuchsituationsdoarise,theprogramshouldnotjust“crash”or“coredump”;itshouldproducesome meaningful message and exit gracefully. Switch case with default: If there is no default case in a “switch” statement, the behaviour can be unpredictable •if that case arises at some point of time which was not predictable at development stage. Such a practice can result in a bug like NULL dereference, memory leak, as well etc other types of serious bugs. It is a good practice to always include a default case.switch (i){case 0 : { s=malloc(size) }s[0] = y; /* NULL dereference if default occurs*/Empty Catch Block: An exception is caught, but if there is no action,it may represent a scenario where some of the operations to be done are notperformed. Whenever exceptions are caught, it is a good practice to takesome default action, even if it is just printing an error message.try {FilelnputStreamfis=newFileInput Stream ("Input File" );>catch (IOException ioe) { }//not a good practiceEmpty if, while Statement: A condition is checked but nothing isdone based on the check. This often occurs due to some mistake and shouldbecaught.Othersimilarerrorsincludeemptyfinally,try,synchronised,empty static method, etc. Such useless checks should be avoided.

79

if (x == 0) {} /* nothing is done after checking x */else {>Read Return to be Checked: Often the return value from reads is not checked, assuming that the read returns •the desired values. Sometimes the result from a read can be different from what is expected, and this can cause failures later. There may be some cases where neglecting this condition may result in some serious error. Forexample,ifreadfromscanf()ismorethanexpected,thenitmaycauseabufferoverflow.Hencethevalue•of read should be checked before accessing the data read. Return From Finally Block: One should not return fromfinallyblock,ascasesitcancreatefalsebeliefs.Forexample,considerthecode

public String foo() {try {throw new Exception ("An Exception" );}catch (Exception e) {throwe;}finally{return "Some value";}}

In this example, a value is returned both in exception and nonexception scenarios. Hence at the caller site, the user will not be able to distinguish between the two.

Another interesting case arises when we have a return from try block. •Inthiscase,ifthereisareturninfinallyalso,thenthevaluefromfinallyisreturnedinsteadofthevaluefrom•try. Correlated Parameters: Often there is an implicit correlation between the parameters. For example, in the code •segment given below, “length” represents the size of BUFFER. If the correlation does not hold, we can run into aseriousproblemlikebufferoverflow.Hence, it is a good practice to validate this correlation rather than assuming that it holds. In general, it is desirable •to do some counter checks on implicit assumptions about parameters.In this example, a value is returned both in exception and nonexception scenarios. Hence at the caller site, the •user will not be able to distinguish between the two. Another interesting case arises when we have a return fromtryblock.Inthiscase,ifthereisareturninfinallyalso,thenthevaluefromfinallyisreturnedinsteadofthe value from try.

void (char*src, int length , char destn [ ] ) {strcpy(destn,src);/*Cancausebufferoverflowif length > MAX.SIZE */}

Trusted Data sources: Counter checks should be made before accessing the input data, particularly if the input data is being provided by the user or is being obtained over the network.

For example, while doing the string copy operation, we should check that the source string is null terminated, •or that its size is as we expect. Similar is the case with some network data which may be sniffed and prone to somemodificationsorcorruptions.To avoid problems due to these changes, we should put some checks, like parity checks, hashes, etc., to ensure •the validity of the incoming data.


80

Give importance to exceptions: Most programmers tend to give less attention to the possible exceptional cases •andtendtoworkwiththemainflowofevents,control,anddata.Thoughthemainworkisdoneinthemainpath, it is the exceptional paths that often cause software systems to fail. To make a software system more reliable, a programmer should consider all possibilities and write suitable •exception handlers to prevent failures or loss when such situations occur.

6.5 Internal DocumentationProgrammers spend far more time reading code than writing code. Over the life of the code, the author spends a considerable time reading it during debugging and enhancement.

People other than the author also spend considerable effort in reading code because the code is often maintained •by someone other than the author. In short, it is of prime importance to write code in a manner that it is easy to read and understand. •Coding standards provide rules and guidelines for some aspects of programming in order to make code easier •to read. Most organisations that develop software regularly develop their own standards. In general, coding standards •provideguidelinesforprogrammersregardingnaming,fileorganisation,statementsanddeclarations,andlayoutand comments. To give an idea of coding standards (often called conventions or style guidelines), we discuss some guidelines •for Java, based on publicly available standards.

Naming conventionsSome of the standard naming conventions that are followed often are:

Package names should be in lower case (for example, mypackage, edu.iitk.maths)•Type names should be nouns and should start with uppercase (for example, Day, DateOfBirth, EventHandler) •Variable names should be nouns starting with lower case (for example., name, amount)•Constant names should be all uppercase (for example, PI, MAXJTERATIONS)•Method names should be verbs starting with lowercase (for example., getValue())•Privateclassvariablesshouldhavethe_suffix(forexample,“privateintvalue_”).•Variables with a large scope should have long names; variables with a small scope can have short names; loop •iterators should be named i, j , k, etc.Theprefixisshouldbeusedforbooleanvariablesandmethodstoavoidconfusion(forexample.,isStatusshould•be used instead of status); negative boolean variable names (for example., isNotCorrect) should be avoided.Thetermcomputecanbeusedformethodswheresomethingisbeingcomputed;thetermfindcanbeused•wheresomethingisbeinglookedup(forexample,computeMean(),findMin().)ExceptionclassesshouldbesuffixedwithException(forexample,OutOfBound-Exception.)•

FilesThereareconventionsonhowfilesshouldbenamed,andwhatfilesshouldcontain,suchthatareadercangetsomeideaaboutwhatthefilecontains.Someexamplesoftheseconventionsare:

Javasourcefilesshouldhavetheextension.Javathisisenforcedbymostcompilersandtools.•Eachfileshouldcontainoneouterclassandtheclassnameshouldbesameasthefilename.•Line length should be limited to less than 80 columns and special characters should be avoided. If the line is •longer, it should be continued and the continuation should be made very clear.

81

StatementsThese guidelines are for the declaration and executable statements in the source code. Some examples are given below. Note, that not everyone will agree to these. That is why organisations generally develop their own guidelines thatcanbefollowedwithoutrestrictingtheflexibilityofprogrammersforthetypeofworktheorganisationdoes.

Variables should be initialised where declared, and they should be declared in the smallest possible scope.Declare related variables together in a common statement. Unrelated variables should not be declared in the •same statement.Class variables should never be declared public.•Use only loop control statements in a for loop.•Loop variables should be initialised immediately before the loop.•Avoid the use of break and continue in a loop.•Avoid the use of do ... while construct.•Avoid complex conditional expressions introduce temporary Boolean variables instead.•Avoid executable statements in conditionals.•


82

Summary A top-down approach is essentially breaking down a system to gain insight into its compositional sub-•systems. Inatop-downapproachanoverviewofthesystemisfirstformulated,specifyingbutnotdetailinganyfirst-level•subsystems. Static structure is the structure of text of a program, which is usually just a linear organisation of statements of •the program. The dynamic structure of the program is the sequence of statements executed during the execution of the program. •In other words, both the static structure and the dynamic. The closer the correspondence between execution and text structure, the easier the program is to understand, •and the more different the structure during execution, the harder it will be to argue about the behaviour from the program text. The goal of structured programming is to ensure that the static structure and the dynamic structures are the •same. The objective of structured programming is to write programs so that the sequence of statements executed during •the execution of a program is the same as the sequence of statements in the text of that program. A software solution to a problem always contains data structures that are meant to represent information in the •problem domain. That is, when software is developed to solve a problem, the software uses some data structures to capture the information in the problem domain. Modernlanguagesallowuserstodefinetypesliketheenumeratedtype.Whensuchfacilitiesareavailable,•theyshouldbeexploitedwhereapplicable.Forexample,whenworkingwithdates,atypecanbedefinedforthedayoftheweek.Usingsuchatypemakestheprogrammuchclearerthandefiningcodesforeachdayandthen working with codes.If nesting of if-then-else constructs becomes too deep, then the logic becomes harder to understand. In case of •deeplynestedif-then-elses,itisoftendifficulttodeterminetheifstatementtowhichaparticularelseclauseisassociated.A module with a complex interface should be carefully examined. As a rule of thumb, any module whose •interfacehasmorethanfiveparametersshouldbecarefullyexaminedandbrokenintomultiplemoduleswitha simpler interface if possible.Whenamoduleisinvoked,itsometimeshassideeffectsofmodifyingtheprogramstatebeyondthemodification•ofparameterslistedinthemoduleinterfacedefinition,forexample,modifyingglobalvariables.Suchsideeffectsshould be avoided where possible, and if a module has side effects, they should be properly documented.

ReferencesDooley, J., 2011. • Software Development and Professional Practice, Apress.Tsui, F. F. and Karam, O., 2007. • Essential of Software Engineering, Jones & Bartlett Learning.Plum, T., 1984. • General Style and Coding Standards for Software Projects [Pdf] Available at: <http://www.cse.buffalo.edu/~rapaport/code.documentation.Excerpts.pdf> [Accessed 7 November 2011].IEEE Software, 1996. • Missing in Action: Information Hiding [Online] Available at: <http://www.stevemcconnell.com/ieeesoftware/bp02.htm> [Accessed 7 November 2011].StanfordUniversity, 2008. • Lecture 1 | Programming Methodology (Stanford) [Video online] Available at: < http://www.youtube.com/watch?v=KkMDCCdjyW8> [Accessed 7 November 2011].Blueoptimasupport, 2010. • [1 of 5] Coding Effort: Taking Software Development Process Improvement to the Next Level [Video online] Available at: <http://www.youtube.com/watch?v=2oB5VQQUlzc> [Accessed 7 November 2011].

83

Recommended ReadingSaleh, A. K., 2009. • Software Engineering, J. Ross Publishing.Vliet, V. H., 2000. • Software engineering: principles and practice, John Wiley.Blum, I. B., 1992. • Software engineering: a holistic view, Oxford University Press.


84

Self Assessment A _____________ approach is essentially breaking down a system to gain insight into its compositional 1. sub-systems.

bottom-up a. top-downb. structure programming c. static structure d.

____________ is often regarded as “goto-less” programming.2. bottom-up a. top-downb. structure programming c. static structure d.

The _________________ is the structure of text of a program, which is usually just a linear organisation of 3. statements of the program.

bottom-up a. top-downb. structure programming c. static structure d.

The __________________ of a program is the sequence of statements executed during execution of the 4. program.

bottom-up a. dynamic structureb. structure programming c. static structure d.

________________ can reduce the coupling between modules and make the system more maintainable. 5. Information hidinga. Modern language b. Nesting c. Robustness d.

_________________allowuserstodefinetypesliketheenumeratedtype.6. Information hidinga. Modern language b. Nesting c. Robustness d.

If ________________ of if-then-else constructs becomes too deep, then the logic becomes harder to 7. understand.

Information hidinga. Modern language b. Nesting c. Robustness d.

85

Which of the following is true?8. A program is robust if it does something planned even for exceptional conditions.a. A program is static if it does something planned even for exceptional conditions.b. A program is dynamic if it does something planned even for exceptional conditions.c. Aprogramisflexibleifitdoessomethingplannedevenforexceptionalconditions.d.

Javasourcefilesshouldhavetheextension____________thisisenforcedbymostcompilersandtools.9. .docxa. .jpgb. .jpegc. .Javad.

Which of the following is true? 10. Package names should be in sentence case. a. Package names should be in lower case. b. Package names should be in upper case. c. Package names should be in toggle case. d.


86

Chapter VII

Testing

Aim


explain levels of testing •

elucidate functional testing •

explicatedataverification•

Objectives


explain concept of validation •

elaborate concept of data integration •

explicatedatafieldchecks•

Learning outcome


understandnumericfields•

identifyalphanumericfieldschecks•

describe structural testing •

87

7.1 Levels of TestingTesting is usually relied upon to detect the faults remaining from earlier stages, in addition to the faults introduced during coding itself. Due to this, different levels of testing are used in the testing process; each level of testing aims to test different aspects of the system.

The basic levels are unit testing, integration testing, and system and acceptance testing. These different levels •of testing attempt to detect different types of faults. The relation of the faults introduced in different phases.•Thefirstleveloftestingiscalledunittesting.Inthis,differentmodulesaretestedagainstthespecifications•produced during design for the modules. It is typically done by the programmer of the module. A module is considered for integration and use by others only after it has been unit tested satisfactorily.•

7.1.1 Functional TestingTesting web application is certainly different than testing desktop or any other application. Within web applications, there are certain standards which are followed in almost all the applications. Having these standards makes life easier for use, because these standards can be converted into checklist and application can be tested easily against the checklist.

LinksCheck that the link takes you to the page it said it would.•Ensure to have no orphan pages (a page that has no links to it)•Check all of your links to other websites•Are all referenced web sites or email addresses hyperlinked?•If we have removed some of the pages from our own site, set up a custom 404 page that redirects your visitors •to your home page (or a search page) when the user try to access a page that no longer exists.Check all mailto links and whether it reaches properly•

FormsAcceptance of invalid input•Optionalversusmandatoryfields•Inputlongerthanfieldallows•Radio buttons•Default values on page load/reload(Also terms and conditions should be disabled)•If command button can be used for HyperLinks and Continue Links?•Is all the data inside the combo/list box are arranged in chronological order?•Areallofthepartsofatableorformpresent?Correctlylaidout?Canyouconfirmthatselectedtextsareinthe•“right place?Does a scrollbar appear if required?•

Data verification and validationIstheprivacypolicyclearlydefinedandavailableforuseraccess?•At no point of time, the system should behave awkwardly when an invalid data is fed.•Check to see what happens if a user deletes cookies while in site.•Check to see what happens if a user deletes cookies after visiting a site.•


88

Data integrationCheckthemaximumfieldlengthstoensurethattherearenotruncatedcharacters?•Ifnumericfieldsacceptnegativevaluescanthesebestoredcorrectlyonthedatabaseanddoesitmakesense•forthefieldtoacceptnegativenumbers?If a particular set of data is saved to the database check that each value gets saved fully to the database i.e., •beware of truncation (of strings) and rounding of numeric values.

Date field checksAssure that leap years are validated correctly and do not cause errors/miscalculations.•Assure that Feb. 28, 29, 30 are validated correctly and do not cause errors/ miscalculations.•Is copyright for all the sites includes Yahoo co-branded sites are updated.•

Numeric fieldsAssure that lowest and highest values are handled correctly.•Assurethatnumericfieldswithablankinposition1areprocessedorreportedasanerror.•Assurethatfieldswithablankinthelastpositionareprocessedorreportedasanerroranerror.•Assure that both + and - values are correctly processed.•Assure that division by zero does not occur.•Include value zero in all calculations.•Assure that upper and lower values in ranges are handled correctly. (Using BVA)•

Alphanumeric field checksUse blank and non-blank data•Include lowest and highest values•Include invalid characters and symbols•Include valid characters•Includedataitemswithfirstpositionblank•Include data items with last position blank•

7.1.2 Structural TestingStructural testing encompasses three critical phases of software development and testing; yet, one or more of these phases is often deliberately bypassed, overlooked, or performed in a less than rigorous manner because either the technicaladvantagesarenotfullyconsideredor,moreoften,thecostandschedulebenefitsarenotappreciated.

While structural testing is required by the FDA for medical devices of moderate and major level of concern, •this testing should be done for all software, regardless of the level of concern. Also, it should be noted that there is no fundamental difference between structural testing of software used in a •medical device and that used in a manufacturing process or a manufacturer’s quality system (or, for that matter, in any other software). An understanding of these considerations and, thus, the importance of performing structural testing, are discussed •below.

Definition of software structural testingSoftware structural testing is meant to challenge the decisions made by the program with test cases based on the structure and logic of the design and source code.

Completestructuraltestingexercisestheprogram’sdatastructuressuchasconfigurationtablesanditscontrolandprocedural logic at the test levels discussed below.

89

Structural testing should be done at the unit, integration, and system levels of testing.Structural testing assures the program’s statements and decisions are fully exercised by code execution. •Forexample,itconfirmsthatprogramloopconstructsbehaveasexpectedattheirdataboundaries.•Forconfigurablesoftware,theintegrityofthedatainconfigurationtablesareevaluatedfortheirimpacton•program behaviour. Attheunitlevel,structuraltestingalsoincludestheidentificationof“deadcode,”whichiscodethatcannotbe•reached for execution by any code pathway.Integrationstructuraltestingshouldbeperformedafterallverificationtestingoftheunitsinvolvedandbefore•system-level structural testing. Figureshownbelowillustratesthegeneralrelationshipbetweensoftwareverificationandvalidation.•Softwareverificationconfirmsthattheoutputofeachphaseofsoftwaredevelopmentistrueto(i.e.,isconsistent•with) the inputs to that phase. Performancequalificationtestingconfirmsthefinalsoftwareproduct,runninginits intendedhardwareand•environment, is consistentwith the intendedproduct as defined in theproduct specifications and softwarerequirements.

Concept

Product Specification

Software Requirements

Design

Source Code

(Test)

Maintenance

Execute code Hardware

Verification

Verification

Verification

Performance Qualification

Verification

Fig. 7.1 Software verification vs software validation testing


90

Figureshownbelowillustratesatypicalconfigurationforastructuralunittest.Theunitiscompiledandlinked•with a driver and stubs, as needed. The driver is a substitute for any actual unit that will eventually call the unit-under-test, and if the driver passes •data to the unit-under-test, it is set up to pass test case variable values such as maximum, minimum, and other nominal and “stress-test” values. The stubs are substitutes for any units called by the unit-under-test. As with the driver, if the stubs return data •to the unit-under-test, they also pass “stress test” and nominal data values, as appropriate.The interface of the drivers and stubs, including their names, are the same as the true units’ interfaces, allowing •the set of units to be linked without altering the unit-under-test.

Driver Simulating “Compute Y”

Get Formatted ABC

Stub Simulating “Format ABC”

Stub Simulating “Notify operation of

invalid data”

Unit- Under –Test

Fig. 7.2 Configuration for a structural unit test

Unit-level structural tests can be conducted on the actual target hardware, on an emulator or simulator of the •actual hardware, or, if the situation requires, on a totally different processor. The latter case may occur, for example., if the actual hardware has no provision for determining the results of a •unit’s tests, but where the code is written in a higher order language. Thus, the higher order source code (such as C or C++) can be compiled and linked to run on another computer that supports reading the test results where the target computer (for example, an embedded microprocessor) could not support the tests. Structural testing (a.k.a. white-box testing) is performed with the item-under-test, in this case the unit, being •viewed internally for purposes of determining how the item should behave for example, in determining all possible code branches.The primary purpose of unit-level structural testing is to verify the code complies with the design, including •logic, algorithms’ correctness, and accuracy (versus parallel code or hand calculations), and the correctness of the data’s engineering units. This requires, for each unit, complete branch tests, complete code tests (including verifyingthereisnodeadcode),andstresstests(todetect,forexample,overflowandunderflowconditionsaswell as nominal and maximum loop-control data values). The detailed design is used to develop the acceptance criteria.•

91

The environment for both integration-level and system-level structural testsIt is best to set up the integration and system structural tests using the actual hardware and environment to the extent practical.

Thereareseveralreasonsforthis,butthetwomostsignificantare•The software may have subtle conditions, both good and bad, that will only show up when running on the �actual hardware. Thefinalcomputerisedsystem,includingtheintendedhardwareandsoftware,mustbequalifiedrunningon �that hardware, and the structural tests should advance the software development towards that end. However, therearealsogoodandsufficient reasons toperformstructural testspartiallyorwholly inasimulatedenvironment.

Inconsideringestablishingsimulationcapabilities,thetwomostcommonconfigurationsaretoeitheremulatethe•computer and simulate the environment used most often when the actual computer is an embedded microprocessor anditisdifficulttostimulateknowninputsand/orreadtheoutputsofatest)ortosimulateboththecomputerand the environment (used, for example, if an emulator of the target computer is not available. The principal advantages, then, in using a simulation of the environment and, at times, the computer include •the following:

The ability to set up absolutely known input values, such that the results can be predetermined to establish �the acceptance criteria of each test; A simulator makes it easy to establish inputs that are over, under, and at the exact limits of critical data �values; Itiseasytosetupillegalinputstotestallerrorandfailureconditions;and,finally, �The results of each test can be readily seen. �

Integration-level structural testingIntegration structural testing combines functionally cohesive units of verified code (which includes unit-levelstructurally tested code) by compiling and/or assembling and linking the code, along with any drivers and stubs needed.

The structure is then loaded into the actual or simulated environment for execution. This allows the tester to focus •onthatonefunctionalpackagetoconfirmitscorrectoperation,includingallinternalandexternalinterfaces.Following completion of each functional package’s test, the next functional package may be either separately •tested or added to (i.e., linked with) the previously tested package(s). Regression testing (i.e., running a selected subset of previous, successfully run test cases) must be performed •onthepreviouslytestedpackagestoconfirmtheyarenotadverselyaffectedbythenewlyintroducedfunctionalpackage.Figure shown below illustrates a building-block, or incremental approach to structural testing. •Whilethefigure’sillustrationisrelatedtoastructureddesign,thesameapproachisusedforallotherdesign•methods,includingflowchartandobject-orienteddesign.Infigureshownbelow,thefirstfunctionneedstwostubs,“GetFormattedABC”and“OutputYtoDeviceX,”•where a stub is a simple software dummy needed to link successfully, but is not part of the software being tested. The stubs in thefigurehavenocalls to additionalunits.The secondand third functions requirenodriver•because they use the actual “Compute Y” and they require no stubs because they use the actual “Output Error Messages” unit.


92

Compute Y

Get Formatted ABC

Output Y to device X

Notify operator if device X is

Off-Line Format ABC

Notify operator of invalid data

Initialise Data

Open File

Notify operator of any errors

1st Function

2nd Function 3rd Function

Output Error messages

Fig. 7.3 Incremental integration structural testing

The incremental approach to integration-level structural tests is the best for software developers (as opposed to •third party, validation testers), especially if the program is large or complex. In this approach, selected small, functionally cohesive portions of the software are compiled, linked, and tested. •This approach is used regardless of the software life cycle development method being employed, including any of the following three methods. Inthewaterfallmethod,alloftherequirementsaredeveloped,thenthedesigniscompleted,and,finally,selected•“threads” are coded and structurally tested. In the spiral method, a major element of the software system is discussed and then the requirements, design, •and code are developed, and the element’s structural test is performed prior to going on to discuss and develop the next major element. Finally,intheincrementalsoftwaredevelopmentmethod,allofthespecificationsandrequirementsmaybe•developed, but the design and implementation are developed one function at a time. In any case, if the operating system was uniquely developed for the system-under-test, that operating system •shouldbestructurallytestedfirst.Thisportionofthecodeitselfshouldbebrokendownintofunctionallycohesivepackages if it is large and/or complex; otherwise, it can be structurally tested as an entity. The second portion of the code to be tested is normally the unique input/output section. If there are diverse input/•output devices, these may be structurally tested separately. But it is often best to select a thread that includes both the ability to input data and to see the resulting output for each structural test. The third step is to select and structurally test a functionally cohesive portion of the application and the utilities •needed to support that application. Then, select the next functionally cohesive portion of the application software and associated application utilities •for the next structural test, and so on. All previously tested functions should be regression tested, as appropriate.•

93

7.1.3 Test PlanA software test plan is a document describing the testing scope and activities. It is the basis for formally testing any software/product in a project.

ISTQB definitionTest plan: A document describing the scope, approach, resources and schedule of intended test activities. It •identifiesamongstotherstestitems,thefeaturestobetested,thetestingtasks,whowilldoeachtask,degreeoftester independence, the test environment, the test design techniques and entry and exit criteria to be used, and the rationale for their choice, and any risks requiring contingency planning. It is a record of the test planning process.Master test plan: A test plan that typically addresses multiple test levels.•Phase test plan: A test plan that typically addresses one test phase.•

Project Name Money Generator Suite

Product Name Coin generator

Product release version 9.1.8

Cash Incorporated

Master Test Plan Document Version: 1.0

Date: 01/02/2059 Prepared by: John Doe

Master_Test_Plan Master_Test_Plan

Fig. 7.4 Test plan


94

Test plan typesOne can have the following types of test plans:

Mastertestplan:Asinglehigh-leveltestplanforaproject/productthatunifiesallothertestplans.•Testinglevelspecifictestplans:Plansforeachleveloftesting.•

Unit test plan �Integration test plan �System test plan �Acceptance test plan �

Testingtypespecifictestplans:Plansformajortypesoftestinglikeperformancetestplanandsecuritytest•plan.

Test plan templateThe format and content of a software test plan vary depending on the processes, standards, and test management tools being implemented. Nevertheless, the following format, which is based on IEEE standard for software test documentation, provides a summary of what a test plan can/should contain.

Test plan identifierProvideauniqueidentifierforthedocument.(AdheretotheConfigurationManagementSystemifyouhaveone).

IntroductionProvide an overview of the test plan•Specify the goals/objectives•Specify any constraints•

ReferencesList the related documents, with links to them if available, including the following:

Project plan•Configurationmanagementplan•

Test itemsList the test items (software/products) and their versions.

Features to be testedList the features the software/product to be tested.•ProvidereferencestotheRequirementsand/orDesignspecificationsofthefeaturestobetested•

Features not to be testedList the features of the software/product which will not be tested.•Specify the reasons these features won’t be tested.•

ApproachMention the overall approach to testing.•Specify the testing levels, the testing types, and the testing methods.•

Item pass/fail criteriaSpecify the criteria that will be used to determine whether each test item (software/product) has passed or failed testing.

95

Suspension criteria and resumption requirementsSpecify criteria to be used to suspend the testing activity.•Specify testing activities which must be redone when testing is resumed.•

Test deliverablesList test deliverables, and links to them if available, including the following:

Test plan (this document itself)•Test cases•Test scripts•Defect/enhancement logs•Test reports•

Test environmentSpecify the properties of test environment: hardware, software, communications etc.•List any testing or related tools.•

EstimateProvide a summary of test estimates (cost or effort) and/or provide a link to the detailed estimation.

ScheduleProvide a summary of the schedule, specifying key test milestones, and/or provide a link to the detailed schedule.

Staffing and training needsSpecifystaffingneedsbyroleandrequiredskills.•Identify training that is necessary to provide those skills, if not already acquired.•

ResponsibilitiesList the responsibilities of each team/role/individual.

RisksListtherisksthathavebeenidentified.•Specify the mitigation plan and the contingency plan for each risk.•

Assumptions and dependenciesList the assumptions that have been made during the preparation of this plan.•List the dependencies.•

ApprovalsSpecify the names and roles of all persons who must approve the plan.•Provide space for signatures and dates. (If the document is to be printed.)•

Test plan guidelinesMaketheplanconcise.Avoidredundancyandsuperfluousness.Ifyouthinkyoudonotneedasectionthathas•been mentioned in the template above, go ahead and delete that section in your test plan.Bespecific.Forexample,whenyouspecifyanoperatingsystemasapropertyofatestenvironment,mention•the OS Edition/Version as well, not just the OS Name.Make use of lists and tables wherever possible. Avoid lengthy paragraphs.•


96

Have the test plan reviewed a number of times prior to base lining it or sending it for approval. The quality of •your test plan speaks volumes about the quality of the testing you or your team is going to perform.Update the plan as and when necessary. An out-dated and unused document stinks.•

7.1.4 Test Cases SpecificationsCASESpecisaveryflexibletoolfordevelopingrequirementsaswellastestcases.Itprovidestheaccountabilityand traceability that you need for your projects.

Specification flexibilityCASESpecprovidestheflexibilityforspecifyingyourrequirementsandtestcases.Testcasescanbespecifiedwith steps, tables, images and diagrams. Use CASE Spec’s user-friendly interface to specify your test cases effortlessly.

Effective testingAs technology progresses, so do the customer’s expectations for bug-free, fully functional software. This expectation for a requirements-exact product has given rise to a new understanding of the importance of software testing as a critical pre-release activity.

With CASE Spec, users can easily trace test cases to requirements and other artifacts. Our traceability feature enables users to easily identify the impact of requirement changes on test cases. User requirements can be effectively validated to increase user acceptance of the system.

CASESpecalsoprovidesauniquefeatureforlinks.Relationships(links)canbeidentifiedwithlinktypesthathaveuser-definedattributes.Forexample,atestconditionlinkedtoafeaturemaybeidentifiedwithalinktypetestcase,with an attribute Status that indicates the values “passed” or “failed.” This capability is very useful in managing and simplifying the test case management process.

Links also provide the information needed to trace relationships between artifacts. For example, using links, we can easily determine the following:

All test conditions for a given feature•All failed test cases for a given feature•All features with no executed test cases•

These results can be viewed in both graphical- and grid-based (matrix) formats.

CASESpecmakesiteasyforuserstoimplementefficientandeffectivesoftwaretesting,therebyguaranteeingthequalityandvalueofthefinalproductforcustomers.

Other useful CASE Spec features for the test-tracking process include automatic versioning of test cases and relationships,notifications,andeasyreporting.

97

Fig. 7.5 Effective testing window

TraceabilityUse CASE Spec’s award winning tools for traceability and gap analysis. Use graphical tools for linking test cases with other artifacts (for example, design, requirements, use cases, tasks, issues). Establish parent-child and peer-to peer links for traceability.

Forexample,withgapanalysistoolsyoucanfindtestcasesthatarenotlinkedtorequirementsand/orusecases.

Change managementUse CASE Spec’s automatic change management tools for versioning, base lining and reverting to previous versions. Use CASE Spec’s traceability tools for impact analysis of test case change on project artifacts.

Workflow managementManageworkflowwithCASEspec’sbuilt-inworkflowfeature.

Documents and reportsGenerate documents with embedded objects, tables of contents and cover pages. You can also generate analysis reportswithsorting,groupingandfiltering.Thereportscanbeexportedinvariousformats(excel,xml,html,pdf,rtf, etc.)

CollaborationCASESpecisazeroconfigurationandadministrationtoolthatcanbeeasilydeployedforcollaborationoflocalandglobally dispersed teams. Your team can collaborate on test cases effectively by using user access control, change management and concurrency control tools.


98

Test specificationThetestcasespecificationsshouldbedevelopedfromthetestplanandarethesecondphaseofthetestdevelopmentlifecycle.Thetestspecificationshouldexplain“how”toimplementthetestcasesdescribedinthetestplan.

Test specification itemsEachtestspecificationshouldcontainthefollowingitems:

CaseNo.:Thetestcasenumbershouldbeathreedigitidentifierofthefollowingform:c.s.t,where:c-isthe•chapter number, s- is the section number, and t is the test case number.Title: Is the title of the test.•ProgName: Is the program name containing the test.•Author:Isthepersonwhowrotethetestspecification.•Date: Is the date of the last revision to the test case.•Background: (Objectives, Assumptions, References, Success Criteria): Describes in words how to conduct the •test.Expected Error(s): Describes any errors expected•Reference(s):Listsreferencedocumententationusedtodesignthespecification.•Data:(TxData,PredictedRxData):DescribesthedataflowsbetweentheImplementationUnderTest(IUT)•and the test engine.Script: (Pseudo Code for Coding Tests): Pseudo code (or real code) used to conduct the test.•

Example test specificationTest specification

Case No. 7.6.3 Title: Invalid Sequence Number (TC)•ProgName: UTEP221 Author: B.C.G. Date: 07/06/2000•Background: (Objectives, Assumptions, References, Success Criteria)•

Validate that the IUTwill reject a normalflowPIUwith a transmission header that has an invalid sequencenumber.

Expected Sense Code: $2001, Sequence Number Error•Reference - SNA Format and Protocols Appendix G/p. 380•Data: (Tx Data, Predicted Rx Data)•

IUT<-------- DATA FIS, OIC, DR1 SNF=20<-------- DATA LIS, SNF=20--------> -RSP $2001Script: (Pseudo Code for Coding Tests)SEND_PIU FIS, OIC, DR1, DRI SNF=20SEND_PIU LIS, SNF=20R_RSP $2001

7.1.5 Reliability AssessmentIngeneral,manypropertiesofengineeringartifcats,suchasreliability,aremeasuredandverifiedinthisway.Forinstance, the reliability of an electrical appliance may be measured in terms of its probability of failure within given time. This measure is helpful; whenever we cannot guarantee absence of failure absolutely. Software reliability is theprobabilityoffailure-freeoperationofacomputerforaspecifiedtimeinaspecifiedenvironment.

99

Theprocessofmeasuringthereliabilityofasystemisillustrateinthefiguregivenbelow

Identify operationalprofiles

Prepare test data set

Apply tests to system

Compute observed realiblity

Fig. 7.6 Reliability measurement process

This process involves four stages:Existingsystemofthesametypearestudiestoestablishanoperationalprofile.Anoperationalprofileidentifies•different classes of system inputs and the probability of theses inputs in normal use. Asetoftestdataisconstructed(Sometimeswiththehelpoftestdatageneratorsthatreflecttheoperational•profile).The system is tested with these data and the number of number of failure is observed. The times of these failures •are also logged; the time units chosen should be appropriate for the reliability metric used. After a statistically significantnumberof failureshavebeenobserved, the software reliabilitycan thenbe•computed. You can then work out the appropriate reliability metric value. Thisapproachtoreliabilitymeasurementisnoteasytoapplyinpractice.Theprincipledifficultieswhichariseare due to: Operationalprofileuncertainty:Theoperationalprofilemaynotbeanaccuratereflectionofrealuseofthe•system Highcostsoftestdatageneration:Definingalargeamountoftestdatatakesalongtimeifitnotpossibleto•generate this data automatically. Statisticaluncertaintywhenhighreliabilityisspecified.Itisimportanttogenerateastatisticalsignificantnumber•of failures to allow accurate reliability measurements.

Software reliability assessment by statistical analysis of operational experience Statistical testing represents a well-founded approach to the estimation of software reliability. Its major drawback namelytheprohibitivetestingeffortitusuallyrequirescanbeovercomebyefficientexploitationofoperationalevidencegainedwithpre-developedsoftwarecomponentsandbytheloss-freecombinationofcomponent-specificreliability estimates.

The application of software systems in safety-critical environments requires that prescribed reliability targets •aredemonstratedusingextremelyrigorousverificationandvalidationprocedures.For such systems, statistical testing offers an adequately well-founded approach. While the effort required to •apply this technique at a system level may lead to prohibitively extensive testing phases, this can be largely mitigated by the exploitation of past testing and/or operational experience gained with individual components or functionalities.The potential usefulness of assessing the operational evidence gained with software-based applications is •arousing the interest of developers in different industrial domains, especially concerning application variants based on pre-developed components. Among them, the automotive industry plays a major role; a study is being conducted on software reliability •assessments tailored to its particular needs, and making use of the considerations presented in this article.


100

Statisticalsamplingtheoryallowsforanygivenconfidencelevelßandsufficientlylargeamountnofcorrect•operational runs (say n > 100) an upper bound of the failure probability p to be derived, assuming the following testingpre-conditionsarefulfilled:Theselectionofatestcasedoesnotinfluencetheselectionoffurthertestcases.•Theexecutionofatestcasedoesnotinfluencetheoutcomeoffurthertestcases.•Test cases are selected in accordance with the expected frequency of occurrence during operation.•No failure occurs during the execution of any of the test cases selected.•Failure probability can be expected to be approximately invariant over the input space.•Under these conditions, statistical sampling theory allows the following conservative reliability estimate to be •derivedatconfidencelevelb:

Forexample,46052successfullyprocessedrunsfulfillingallfiveconditionswouldallowthereliability �statementp≤10-4tobevalidatedataconfidencelevelof99%.For the purpose of applying this theory to operational data gained with software components, the latter must �berecorded,analysedandappropriatelyfiltered.A practicable procedure for extracting relevant operational information is currently applied within an �industrial research project using a software-based automatic gear control system. This is structured as follows:

Delimitation of scopeIdentificationofsoftwarefunctionalitytobeusedtoassessreliability•Modelling of operational runs including only input parameters relevant to the functionality considered.•

Analysis of operational experienceIdentificationofmemory-lesssuites,i.e.,sequencesofrunswhosebehaviourdoesnotdependonhistory.•Determination of frequency of functional demands during operation.•Extraction of an operationally representative subset of independent operational data.•

Assessment of operational evidenceValidationofextractedoperationalevidencewithrespecttoidentificationofincorrectruns.•Assessment of software reliability by statistical sampling theory (as illustrated above).•If required, extension of operational experience in order to validate a prescribed reliability target.•

The economics of this approach are particularly appealing in the case of pre-developed components for which a certain amount of operational data may already have been collected in the context of past applications.

Onceinterpretedinthelightoftheirfutureoperationalprofile,thestatisticalanalysisofsuchoperationaldatayieldsa conservative reliability estimate for each reusable functionality considered.

For component-based systems consisting of a number of such pre-developed functionalities, the assessor is still faced withtheproblemofcombiningseveralcomponent-specificreliabilityinequalitiesintooneoverallconservativesystemreliabilityestimateofhighsignificance.State-of-the-artcombinationapproachesbasedonmeresuperimpositionofinequalitiesprovokeasubstantialreductioninconfidence.

101

Summary Testing is usually relied upon to detect the faults remaining from earlier stages, in addition to the faults introduced •during coding itself. Testing web application is certainly different than testing desktop or any other application. Within web •applications, there are certain standards which are followed in almost all the applications.Structural testing encompasses three critical phases of software development and testing; yet, one or more of •these phases is often deliberately bypassed, overlooked, or performed in a less than rigorous manner because eitherthetechnicaladvantagesarenotfullyconsideredor,moreoften,thecostandschedulebenefitsarenotappreciated. Software structural testing is meant to challenge the decisions made by the program with test cases based on •the structure and logic of the design and source code. Structural testing assures the program’s statements and decisions are fully exercised by code execution. •Unit-level structural tests can be conducted on the actual target hardware, on an emulator or simulator of the •actual hardware, or, if the situation requires, on a totally different processor.Integrationstructuraltestingcombinesfunctionallycohesiveunitsofverifiedcode(whichincludesunit-level•structurally tested code) by compiling and/or assembling and linking the code, along with any drivers and stubs needed.A Software test plan is a document describing the testing scope and activities. It is the basis for formally testing •any software/product in a project.CASESpecisaveryflexibletoolfordevelopingrequirementsaswellastestcases.Itprovidestheaccountability•and traceability that you need for your projects.As technology progresses, so do the customer’s expectations for bug-free, fully functional software. This •expectation for a requirements-exact product has given rise to a new understanding of the importance of software testing as a critical pre-release activity.The reliability of an electrical appliance may be measured in terms of its probability of failure within given •time. Statistical testing represents a well-founded approach to the estimation of software reliability. •

ReferencesOuld, A. M. and Unwin, C., 1986. • Testing in software development, Cambridge University Press.Copeland, L., 2004. • A practitioner’s guide to software test design, Artech House.Halili, H. E., 2011. • Functional Testing [Online] Available at: <http://www.webreference.com/authoring/jmeter/> [Accessed 7 November 2011].Doe, J., 2011. • Test Plan [Online] Available at: <http://softwaretestingfundamentals.com/test-plan/> [Accessed 7 November 2011].Prof. Joshi, R. K., 2008. • Lecture - 18 Software Testing – I [Video online] Available at: <http://www.youtube.com/watch?v=zZdQ6HXXDiE&feature=results_video&playnext=1&list=PL709425D63691F722> [Accessed 7 November 2011].Prof. Joshi, R. K., 2008. • Lecture - 19 Software Testing – II [Video online] Available at: < http://www.youtube.com/watch?v=B_yYAbQVitQ&feature=relmfu> [Accessed 7 November 2011].

Recommended ReadingCraig, D. R. and Jaskiel, P. S., 2002. • Systematic software testing, Artech House.Patton, 2006. • Software Testing, Pearson Education India.Desikan• , S. and Ramesh,G., 2006. Software Testing: Principles and Practice, Pearson Education India.


102

Self Assessment Thefirstleveloftestingiscalled_____________.1.

Hardware testing a. Software testing b. Unit testingc. Code testing d.

____________ is usually relied upon to detect the faults remaining from earlier stages, in addition to the faults 2. introduced during coding itself.

Testinga. Developing b. Driving c. Executing d.

Which of the following is true?3. Structural testing encompasses three critical phases of software development and testing. a. Structural testing encompasses critical phase of software development. b. Structural testing encompasses seven critical phases of software development and testing. c. Structural testing encompasses two critical phases of software development and testing. d.

Software structural testing is meant to challenge the decisions made by a program with test cases based on the 4. structure and logic of the ___________________ code.

server and main a. reserve and saved b. design and sourcec. desired and deallocate d.

Integration structural testing should be performed after all _____________ of the units involved and before 5. system-level structural testing.

hardware testing a. software testing b. unit testingc. verificationtestingd.

The _____________ have subtle conditions, both good and bad, that will only show up when running on the 6. actual hardware.

Hardware a. Software b. Unit c. Code d.

A _______________ is a document describing the testing scope and activities.7. master test plan a. software test planb. phase test plan c. apply test plan d.

103

_______________ is a test plan that typically addresses multiple test levels.8. Master test plan a. Software Test Planb. Phase test plan c. Apply test plan d.

Which of the following addresses the one test phase? 9. Master test plan a. Software test Planb. Phase test plan c. Apply test plan d.

Thetestcasespecificationsshouldbedevelopedfromthe___________andarethesecondphaseofthetest10. development life cycle.

test plana. code b. rules c. software d.


104

Chapter VIII

Software Project Management

Aim


explain the concept of cost estimation •

elucidate estimation session •

discuss project scheduling •

Objectives


explain creating scheduling •

elaborate identifying dependency •

describetheconceptofstaffing•

Learning outcome


understand the concept of outsourcing •

highlight in-house employees •

describe direct freelancers •

105

8.1 Cost EstimationA sound estimate starts with a work breakdown structure (WBS). A WBS is a list of tasks that, if completed, will producethefinalproduct.Thewaytheworkisbrokendowndictateshowitwillbedone.Ausefulthumbruleisthat any project can be broken down between 10 and 20 tasks.

Once the WBS is created, the team must create an estimate of the effort required to perform each task.•The most accurate estimates are those that rely on prior experience. •Teammembersshouldreviewpreviousprojectresultsandfindhowlongsimilartasksinpreviousprojectstook•to complete. Sources of delays in the past should be taken into account when making current estimates. Postmortem reports •are a good source of this information. No estimate is guaranteed to be accurate. •People get sick or leave the organisation; teams run into unforeseen technical problems; the needs of the •organisation change. The unexpected will almost certainly happen. Therefore, the goal of estimation is not to predict the future.•A project manager can help the team create more accurate estimates by reducing the uncertainty about the •project. The most effective way to do this is to do a thorough job creating a vision and scope document the more accurate •and detailed it is the more information the team has to work with when generating their estimate. The project manager can also ensure that the team has reached a consensus on the tasks that must be •performed.

Assumptions make estimates more accurateFor the estimates to be most effective, the assumptions must be written down.

Important information is discovered during the discussion that the team will need to refer back to during the •development process, and if that information is not written down, the team will have to have the discussion all over again.If an assumption turns out to be incorrect, the schedule will need to be adjusted; they will be able to point to the •exact cause of the delay by showing that a documented assumption turned out to be incorrect. This will help the project manager explain any resulting schedule delay to others in the organisation and avoid •that source of delays in the future.The assumptions also provide a way to keep a record of team decisions, share those decisions with others, and •finderrorsintheirdecisions.


106

WBS# or.tsEytiroirp

DeltasnoitpmussA1Task name

Delta2

Delta3

Delta4 Total

Delta

NameGoal statement

Estimation form

Total

DateUnits

Category goal tasks quality tasks waiting time project overhead

Fig. 8.1 Filled-in estimation form

Estimation sessionTheestimationsessionstartswitheachestimatorfillingoutanestimationform.Blankestimationformsshouldbe handed out tomeeting participants,whofill in the tasks and their initial estimates from their individualpreparations.

During the estimation session, the team members will use these estimation forms to modify their estimates. •After the estimation session, they will serve as a record of each team member’s estimates for the individual •tasks, which the project manager uses when compiling the results.

The moderator then leads the team through estimation sessionThe moderator collects all of the estimate forms. The estimates are tabulated on a Whiteboard by plotting the •totals on a line. The forms are returned to the estimators.

107

10 20 30 40 50 60 70 80

Effort estimates (not including overhead or calendar waiting time)

Round 10

Fig. 8.2 Initial estimates

Eachestimatorreadsoutclarificationsandchangesthetasklistwrittenontheestimationform.Anynewor•changed tasks, discovered assumptions, or questions are raised.The team resolves any issues or disagreements that are brought up. Since individual estimate times are not •discussed, these disagreements are usually about the tasks themselves, and are often resolved by adding assumptions.Theestimatorsallrevisetheirindividualestimatesbyfillinginthenext“Delta”columnontheirforms.•

8.2 Project SchedulingThe project schedule is a calendar that links the tasks to be done with the resources that will do them.

Before a project schedule can be created, the project manager must have a work breakdown structure (WBS), •an effort estimate for each task, and a resource list with availability for each resource.If these are not yet available, it may be possible to create something that looks like a schedule, but it will •essentiallybeaworkoffiction.A project manager’s time is better spent on working with the team to create a WBS and estimates than on trying •to build a project schedule without them. The reason for this is that a schedule itself is an estimate: each date in the schedule is estimated, and if those •dates do not have the buy-in of the people who are going to do the work, the schedule will almost certainly be inaccurate.There are many project scheduling software products which can do much of the tedious work of calculating the •schedule automatically, and plenty of books and tutorials dedicated to teaching people how to use them.However, before a project manager can use these tools, he should understand the concepts behind the WBS, •dependencies, resource allocation, critical paths.Gantt charts and earned value. These are the real keys to planning a successful project.•The most popular tool for creating a project schedule is Microsoft Project. There are also free and open source •project scheduling tools available for most platforms which feature task lists, resource allocation, predecessors and Gantt charts.Other project scheduling software packages include:•

Open Workbench �dotProject �netOffice �TUTOS �Allocate resources to the tasks �

Thefirststepinbuildingtheprojectscheduleistoidentifytheresourcesrequiredtoperformeachofthetasks•required to complete the project.


108

A resource is any person, item, tool, or service that is needed by the project that is either scarce or has limited •availability.Many project managers use the terms “resource” and “person” interchangeably, but people are only one kind •of resource. The project could include computer resources like shared computer room, mainframe, or server time, locations •trainingrooms,temporaryofficespace,andservicesliketimefromcontractors,trainers,orasupportteam,andspecial equipment that will be temporarily acquired for the project. Most project schedules only plan for human resources the other kinds of resources are listed in the resource •list, which is part of the project plan.One or more resources must be allocated to each task. •Todothis,theprojectmanagermustfirstassignthetasktopeoplewhowillperformit.•For each task, the project manager must identify one or more people on the resource list capable of doing that •task and assign it to them. Once a task is assigned, the team member who is performing it is not available for other tasks until the assigned •task is completed. While some tasks can be assigned to any team member, most can be performed only by certain people.If those people are not available, the task must wait.•

Identify dependenciesOnce resources are allocated, the next step in creating a project schedule is to identify dependencies between tasks.

A task has a dependency if it involves an activity, resource, or work product that is subsequently required by •another task. Dependencies come in many forms: a test plan can’t be executed until a build of the software is delivered; •code might depend on classes or modules built in earlier stages; a user interface can’t be built until the design is reviewed. If Wideband Delphi is used to generate estimates, many of these dependencies will already be represented in •the assumptions. It is the project manager’s responsibility to work with everyone on the engineering team to identify these •dependencies. The project manager should start by taking the WBS and adding dependency information to it: each task in •the WBS is given a number, and the number of any task that it is dependent on should be listed next to it as a predecessor. Thefollowingfigureshowsthefourwaysinwhichonetaskcanbedependentonanother.•

Until the predecessor is

finished

The dependent

cannot start

The dependent

cannot start

The dependent cannotfinish

The dependent cannotfinish


finished


starts


starts

Finish- to- start (FS) Start – to –Start (SS) Start –to- Finish (SF) Finish- to – Finish (FF)

Fig. 8.3 Identify dependencies

109

Create the scheduleOncetheresourcesanddependenciesareassigned,thesoftwarewillarrangethetaskstoreflectthedependencies.

The software also allows the project manager to enter effort and duration information for each task; with this •information,itcancalculateafinaldateandbuildtheschedule.ThemostcommonformforthescheduletotakeisaGanttchart.Thefollowingfigureshowsanexample:•

Task A

Task C

Task D

Task E

Task B

Time

Fig. 8.4 Create the schedule

8.3 StaffingTherearemultipleapproachesyoucantaketostaffingwhenitcomestoITprojects.

You can deal directly with full-time or freelance/contracted employees, or you can outsource using local or •offshoredevelopmentfirms.Determiningwhichofthesemethodsofstaffingsoftwaredevelopmentprojectsisrightforyourcompanycan•be a challenging endeavour, and three opposing characteristics of business need to be considered: cost, risk and convenience. Eachofthesethreeconceptsdemandsextensiveconsiderationinthespecificcontextoftheprojectandthe•organisation as a whole.BelowisanoverviewofwhatyouneedtoconsiderandtheprosandconsofeachoptionforITstaffing.•

ConvenienceFirst and foremost, you must decide whether to work with individuals or development companies. •Regardless of if you were working with developers in-house, or remotely, or if they’re full-time or contracted, •thefirstdecisionyouneedtomakeiswhetheryouwanttoworkwithindividualdevelopersorcompaniesthatspecialise in outsourced development.Full-timeemployees,freelancers(directly)orcontracts(throughstaffingcompanies)•


110

Thisapproachallowsyourcompanytomaintaintotalcontrolasitmanagesthefinedetailsoftheproject.Outsourcing(localdevelopmentcompanyoroffshorefirm)•

This option allows your company to step away from the “day-to-day” responsibilities of managing individuals and project details and instead focus on the project’s big picture.

The underlying questions to ask here are simple•Do you want to manage the small details of the project? �Do you have the time, expertise and desire to handle this responsibility? �Or, would you rather use your time for something else and leave those details up to an expert? �

RiskRisk management is about assessing and minimising the likelihood of delays or failures. Minimising the effects of unforeseendifficultiesisalsocritical.

Basically, you want to reduce the likelihood of anything that affects the bottom line.•Throwing money at a project does not always guarantee the best outcome, however, being prepared to commit •to the appropriate budgeting often does. In other words, a company that is prepared to fund success is more likely to achieve that success.•You can minimise risk by performing due diligence when selecting a company or individual to work with, clearly •definingtheprojectscope,expectationsandmilestonesinanydevelopmentcontracts,andallocatingenoughmoney to hire competent developers.

CostThe most talented technical candidates do demand higher hourly rates, but as indicated already, their expertise •reduces risk and the number of required project hours. Spending additional money also allows the convenience of implementing the exact approach your company •desires, while at the same time potentially simplifying the candidate selection process.Theunderlyingquestionhere(relatedtoconvenience)ishowmuchtimedoyouwanttodedicatetofindingthe•mostqualifiedtalent?Howconfidentareyouinbeingeffectiveintheselectionprocess?•Does your budget line up with expectations?•

8.3.1 Benefits and drawbacks of IT staffing:LetustakeadeeperlookatsomeofthebenefitsanddrawbacksofeachmethodofITstaffing:In-House Employees

Moderate convenience•Moderate cost•Moderate risk•

BenefitsLonger term (employee) commitment to company•Permanent employment builds the internal talent pool•Allows most control over employees’ daily activity•Employees have the greatest familiarity with a company’s personnel and procedures•

111

DrawbacksEmployeecostssuchasbenefits,vacations,taxes,healthinsurance,etc.•Skills might not be applicable to next project•Employee turnover loss of company provided training and knowledge•

Contractors through staffing companyHigh convenience•Moderate cost•Moderate risk•

BenefitsImmediate pool of talent•Performance guarantees to a certain degree•Quickramp-upstaffingupanddownwithchangingprojectrequirements•

DrawbacksMark ups on contractor hourly rates•Unknown interview process•Inconsistentgoalsstaffingfirmsmakemoneybyplacingcandidates,notnecessarilyeffectiveones•

Direct freelancersLow convenience•Moderate cost•High risk•

BenefitsNo middleman in business relationship•Flexibility of contract terms•Many potential candidates•

DrawbacksUnknownreliability(itcanbedifficulttoassurereliability)•Too many potential candidates (requiring sifting through job board responses and resumes)•Thorough interview and reference checking process “required” (high risk)•No business entity standing behind work•

OutsourcingHigh convenience•High cost•Low risk•

BenefitsExisting structures for successful project implementation•Proven track record of success (documented)•Quickly staff up and staff down as needed•


112

DrawbacksSeemingly higher cost (potentially fewer hours)•Hiring company needs to extended greater level of trust and give up a certain amount of control•

Off-shoringModerate convenience•Low cost•High risk•

BenefitsCheaper rates•Ready pool of talent•Strong desire of most companies and its employees to succeed•

DrawbacksCommunication issues (language barriers)•Potentiallyhigherrateofprojectfailuresanddifficulties•Questionable enforcement of non-disclosure agreements (international laws)•Time zone differences (many questions/tasks unseen until next day)•

8.4 Software Configuration ManagementTraditionalSCMprocessislookeduponasthebestfitsolutiontohandlingchangesinsoftwareprojects.TraditionalSCMprocessidentifiesthefunctionalandphysicalattributesofsoftwareatvariouspointsintimeandperformssystematic controlof changes to the identifiedattributes for thepurposeofmaintaining software integrityandtraceability throughout the software development life cycle.

TheSCMprocessfurtherdefinestheneedtotracethechangesandtheabilitytoverifythat thefinaldeliveredsoftware has all the planned enhancements that are supposed to be part of the release.

ThetraditionalSCMidentifiesfourproceduresthatmustbedefinedforeachsoftwareprojecttoensureagoodSCMprocess is implemented. They are

Configurationidentification•Configurationcontrol•Configurationstatusaccounting•Configurationauthentication•

Most of this section will cover traditional SCM theory. Do not consider this as boring subject since this section definesandexplainsthetermsthatwillbeusedthroughoutthisdocument.

Configuration identificationSoftware is usually made up of several programs. Each program, its related documentation and data can be called asa“configurableitem”(CI).ThenumberofCIinanysoftwareprojectandthegroupingofartifactsthatmakeupa CI is a decision made of the project. The end product is made up of a bunch of CIs.

The status of the CIs at a given point in time is called as a baseline. The baseline serves as a reference point in the software development life cycle. Each new baseline is the sum total of an older baseline plus a series of approved changes made on the CI

A baseline is considered to have the following attributes.

113

Functionally completeAbaselinewillhaveadefinedfunctionality.Thefeaturesandfunctionsofthisparticularbaselinewillbedocumentedand available for reference. Thus the capabilities of the software at a particular baseline are well known.

Known qualityThequalityofabaselinewillbewelldefined.i.e.allknownbugswillbedocumentedandthesoftwarewillhaveundergoneacompleteroundoftestingbeforebeingputdefineasthebaseline.

Immutable and completely recreatableAbaseline,oncedefined,cannotbechanged.ThelistoftheCIsandtheirversionsaresetinstone.Also,alltheCIswill be under version control so the baseline can be recreated at any point in time.

Configuration controlThe process of deciding, co-ordinating the approved change for the proposed CIs and implementing the changes •ontheappropriatebaselineiscalledConfigurationcontrol.Itshouldbekeptinmindthatconfigurationcontrolonlyaddressestheprocessafterchangesareapproved.The•act of evaluating and approving changes to software comes under the purview of an entirely different process called change control.

Configuration status accountingConfigurationstatusaccountingisthebookkeepingprocessofeachrelease.Thisprocedureinvolvestracking•what is in each version of software and the changes that lead to this version.Configurationstatusaccountingkeepsarecordofallthechangesmadetothepreviousbaselinetoreachthe•new baseline.

Configuration authenticationConfigurationauthentication (CA) is theprocessofassuring that thenewbaselinehasall theplannedand•approved changes incorporated. The process involves verifying that all the functional aspects of the software is complete and also the completeness of the delivery in terms of the right programs, documentation and data are being delivered.Theconfigurationauthenticationisanauditperformedonthedeliverybeforeitisopenedtotheentireworld.•

Tools that aid software configuration managementFree Software Tools TODO: need some write-up here on each tool. Free software tools that help in SCM are

Concurrent Versions System (CVS)•Revision Control System (RCS)•Source Code Control System (SCCS)•

Commercial toolsRational ClearCase•PVCS•Microsoft Visual SourceSafe•

SCM and SEI capability maturity modelTheCapabilityMaturityModeldefinedby theSoftwareEngineeringInstitute(SEI) forSoftwaredescribes theprinciples and practices to achieve a certain level of software process maturity.

The model is intended to help software organisations improve the maturity of their software processes in terms •of an evolutionary path from ad hoc, chaotic processes to mature, disciplined software processes. The CMM is designed towards organisations in improving their software processes for building better software •faster and at a lower cost.


114

TheSoftwareEngineeringInstitute(SEI)definesfivelevelsofmaturityofasoftwaredevelopmentprocess.•They are denoted pictorially below.

Optimising (5)

Managed (4)

Defined(3)

Repeatable (2)

Initial (1)

Continuously improving process

Predictable process

Standard consistent process

Disciplinedprocess

Fig. 8.5 Software engineering institute

Associated with each level from level two onwards are key areas which an organisation is required to focus on •to move on to the next level. Such focus areas are called as Key Process Areas (KPA) in CMM parlance. •Aspartoflevel2maturity,oneoftheKPAsthathavebeenidentifiedisSCM.•

8.5 Quality AssuranceEven the most jaded software developers will agree that high-quality software is an important goal. But how do wedefinequality?

A wag once said, “Every program does something right, it just may not be the thing that we want it to do.” •Manydefinitionsofsoftwarequalityhavebeenproposedintheliterature.•Forourpurposes,softwarequalityisdefinedasConformancetoexplicitlystatefunctionalandperformance•requirements, explicitly documented development standards, and implicit characteristics that are expected of all professionally developed software.Thedefinitionservestoemphasisethreeimportantpoints:•

Software requirements are the foundation from which quality is measured. Lack of conformance to �requirements is lack of quality.Specifiedstandardsdefineasetofdevelopmentcriteriathatguidethemannerinwhichsoftwareisengineered. �If the criteria are not followed, lack of quality will almost surely result.A set of implicit requirements often goes unmentioned (e.g., the desire for ease of use and good �maintainability). If software conforms to its explicit requirements but fails to meet implicit requirements, software quality is suspect.

Quality assurance consists of the auditing and reporting functions of management.•

115

The goal of quality assurance is to provide management with the data necessary to be informed about product •quality,therebygaininginsightandconfidencethatproductqualityismeetingitsgoals.Of course, if the data provided through quality assurance identify problems, it is management’s responsibility •to address the problems and apply the necessary resources to resolve quality issues.

Cost of qualityThe cost of quality includes all costs incurred in the pursuit of quality or in performing quality-related activities. Cost of quality studies are conducted to provide a base line for the current cost of quality, identify opportunities for reducing the cost of quality, and provide a normalised basis of comparison.

Quality costs may be divided into costs associated with prevention, appraisal, and failure. Prevention costs include:

quality planning•formal technical reviews•test equipment•training•

Appraisal costs include activities to gain insight into product condition the “first time through” eachprocess.Examples of appraisal costs include:

in-process and interprocess inspection•equipment calibration and maintenance•testing•

Failure costs are those that would disappear if no defects appeared before shipping a product to customers. Failure costs may be subdivided into internal failure costs and external failure costs. Internal failure costs are incurred when we detect a defect in our product prior to shipment. Internal failure costs include:

rework•repair•failure mode analysis•

External failure costs are associated with defects found after the product has been shipped to the customer. Examples of external failure costs are

complaint resolution•product return and replacement•help line support•warranty work•

8.6 Project MonitoringSoftware project monitoring focuses on the following activities:

Consistently and regularly collecting measurements•Analyzing the data•Representingandpresentingthedataforadefinedsetofreports•Making projections and making recommendations based on the analysis of the data•

Software project management, like any other project management situation, involves a heavy dosage of “people” management. Therefore, the project monitoring component must include the soft art of both physically and virtually “walking around the hallway” and tapping into day-to-day issues, concerns, and morale.


116

Initiating

Applying project management tools and techniques Estimating, Requirements Management, WBS, Risk Management, Quality Management, etc.

Planning

Requirement for project

Product

Monitoring & Controlling Closing

Executing

Project Plan and Performance Report

Fig. 8.6 Project monitoring

8.7 Risk ManagementRisk management is increasingly seen as one of the main jobs of project managers.

It involves anticipating risks that might affect the project schedule or the quality of the software being developed •and taking action to avoid these risks (Hall, 1998) (Ould, 1999). The results of the risk analysis should be documented in the project plan along with an analysis of the consequences •of a risk occurring. Effective risk management makes it easier to cope with problems and to ensure that these do not lead to •unacceptable budget or schedule slippage. Risks may threaten the project, the software that is being developed or the organisation. There are, therefore, •three related categories of risk:

Project risks are risks that affect the project schedule or resources. An example might be the loss of an �experienced designer.Product risks are risks that affect the quality or performance of the software being developed. An example �might be the failure of a purchased component to perform as expected.Business risks are risks that affect the organisation developing or procuring the software. For example, a �competitor introducing a new product is a business risk.

Of course, these risk types overlap. If an experienced programmer leaves a project, this can be a project risk •because the delivery of the system may be delayed.It can also be a product risk because a replacement may not be as experienced and so may make programming •errors. Finally, it can be a business risk because the programmer's experience is not available for bidding for future •business. The risks that may affect a project depend on the project and the organisational environment where the software •is being developed. However, many risks are universal some of the most common risks are shown in table given below.

117

Risk management is particularly important for software projects because of the inherent uncertainties that most •projects face. Thesestemfromlooselydefinerequirements,difficulties inestimating the timeandresources requiredfor•software development, dependence on individual skills and requirements changes due to changes in customer needs.

Risk Risk Type Description

Staff turnover Project Experienced staff will leave the project before itisfinished.

Management change Project There will be a change of organisational management with different priorities.

Hardware unavailability Project Hardware which is essential for the project will not be delivered on schedule.

Requirements change Project and product There will be a larger number of changes to the requirements than anticipated.

Specificationdelays Project and product Specificationofessentialinterfacesisnotavailable on schedule.

Size underestimate Project and product The size of the system has been underestimated.

CASE tool under performance Product CASE tools which support the project do not perform as anticipated.

Technology change BusinessThe underlying technology on which the system is built is suspended by new technology.

Product competition Business A competitive product is marked before the system is completed.

Table 8.1 Possible software risks

Risk identification

List of potential risks

Prioritised risk list

Risk avoidance and contingency

plans

Risk assessment

Risk Analysis

Risk Planning

Risk Monitoring

Fig. 8.7 Risk management process

Theprocessofriskmanagementisillustratedinfiguregivenabove.Itinvolvesseveralstages:•Riskidentification:Possibleproject,productandbusinessrisksareidentified. �Risk analysis: The likelihood and consequences of these risks are assessed. �Risk planning: Plans to address the risk either by avoiding it or minimising its effects on the project is �drawn up.


118

Risk monitoring: The risk is constantly assessed and plans for risk mitigation are revised as more information �about the risk becomes available. The risk management process, like all other project planning, is an iterative process which continues throughout the project. Once an initial set of plans are drawn up, the situation is monitored.

You should document the outcomes of the risk management process in a risk management plan. This should •include a discussion of the risks faced by the project, an analysis of these risks and the plans that are required to manage these risks.

Risk identificationRiskidentificationisthefirststageofriskmanagement.

It is concerned with discovering possible risks to the project. •In principle, these should not be assessed or prioritised at this stage, although, in practice, risks with very minor •consequences or very low probability risks are not usually considered.To help the process, a checklist of different types of risk may be used. There are at least six types of risk that •can arise:

Type of Risk Description

Technology risks Risks that derive from the software or hardware technologies that are used to develop the system.

People risks Risks that is associated with the people in the development team.

Organisational risks Risks that derive from the organisational environment where the software is being developed.

Tools risks Risks that derive from the CASE tools and other support software used to develop the system.

Requirements risks Risks that derive from changes to the customer requirements and the process of managing the requirements change.

Estimation risks Risks that derive from the management estimates of the system characteristics and the resources required to build the system.

Table 8.2 Types of risk Risk analysisDuringtheriskanalysisprocess,youhavetoconsidereachidentifiedriskandmakeajudgementabouttheprobabilityand the seriousness of it.

There is no easy way to do this you must rely on your own judgement and experience, which is why experienced •project managers are generally the best people to help with risk management. These risk estimates should not generally be precise numeric assessments but should be based around a number •of bands:

Theprobabilityoftheriskmightbeassessedasverylow(<10%),low(l(0-25%),moderate(25-50%),high �(50-75%)orveryhigh(>75%).Theeffectsoftheriskmightbeassessedascatastrophic,serious,tolerableorinsignificant. �

Risk type Possible risks

TechnologyThe database used in the system cannot process as many transactions per second as expected. Software components which should be reused contain defects which limit their functionality.

People It is impossible to recruit staff with the skills required. Key staffs are ill and unavailable at critical times. Required training for staff is not available.

119

OrganisationalThe organisation is restructured so that different management are responsible fortheproject.Organisationalfinancialproblemsforcereductionsintheprojectbudget

Tools The code generated by CASE tools is inefficient CASE tools cannot be integrated.

Requirements Changes to requirements which require major design rework are proposed. Customers fail to understand the impact of requirements changes.

EstimationThe time required to develop the software is underestimated.The rate of defect repair is underestimatedThe size of the software is underestimated.

Table 8.3 Risk analysis

Oncetheriskshavebeenanalysedandranked,youshouldassesswhicharemostsignificant.•

Risk planningTheriskplanningprocessconsiderseachofthekeyrisksthathavebeenidentifiedandidentifiesstrategiestomanagethe risk.

Again, there is no simple process that can be followed to establish risk management plans.

Risk Strategy

Organisationalfinancialproblems

Prepareabriefingdocumentforseniormanagementshowinghowthe project is making a very important contribution to the goals of the business.

Recruitment problems Alertcustomerofpotentialdifficultiesandthepossibilityofdelays,investigate buying-in components.

Staff illness Reorganise team so that there is more overlap of work and people therefore understand each other’s jobs.

Defective components Replace potentially defective components with bought-in components of known reliability.

Requirements changes Derive traceability information to assess requirements change impact, maximise information hiding in the design.

Organisational restructuring

Prepareabriefingdocumentforseniormanagementshowinghowthe project is making a very important contribution to the goals of the business.

Database performance Investigate the possibility of buying a higher-performance database.

Underestimated development time

Investigate buying-in components, investigate the use of a program generator.

Table 8.4 Risk management strategies


120

Risk monitoringRiskmonitoringinvolvesregularlyassessingeachoftheidentifiedriskstodecidewhetherornotthatriskis•becoming more or less probable and whether the effects of the risk have changed.Risk monitoring should be a continuous process, and, at every management progress review, you should consider •and discuss each of the key risks separately.

Risk Type Potential Indicators

Technology Late delivery of hardware or support software, many reportedtechnology problems.

People Poor staff morale, poor relationships amongst team members,job availability.

Organisational Organisational gossip, lack of action by senior management.

Tools Reluctance by team members to use tools, complaints about CASE tools, demands for higher-powered workstations.

Requirements Many requirements change requests, customer complaints.

Estimation Failure to meet agreed schedule, failure to clear reported defects.

Table 8.5 Risk factors

121

Summary A sound estimate starts with a work breakdown structure (WBS). A WBS is a list of tasks that, if completed, •willproducethefinalproduct.Theestimationsessionstartswitheachestimatorfillingoutanestimationform.•A project manager’s time is better spent on working with the team to create a WBS and estimates than on trying •to build a project schedule without them. A task has a dependency if it involves an activity, resource, or work product that is subsequently required by •another task. Dependencies come in many forms: a test plan can’t be executed until a build of the software is delivered; •code might depend on classes or modules built in earlier stages; a user interface can’t be built until the design is reviewed. Risk management is about assessing and minimising the likelihood of delays or failures. Minimising the effects •ofunforeseendifficultiesisalsocritical.The most talented technical candidates do demand higher hourly rates, but as indicated already, their expertise •reduces risk and the number of required project hours. Spending additional money also allows the convenience of implementing the exact approach your company •desires, while at the same time potentially simplifying the candidate selection process.TraditionalSCMprocessislookeduponasthebestfitsolutiontohandlingchangesinsoftwareprojects.•TraditionalSCMprocessidentifiesthefunctionalandphysicalattributesofsoftwareatvariouspointsintime•andperformssystematiccontrolofchangestotheidentifiedattributesforthepurposeofmaintainingsoftwareintegrity and traceability throughout the software development life cycle.Software is usually made up of several programs. Each program, its related documentation and data can be •calledasa“configurableitem”(CI).

ReferencesHughes, B. and Cotterell, M., 2009. • Software Project Management, McGraw-Hill Higher Education.Henry, J., 2004. • Software Project Management: A Real-World Guide To Success, Pearson Education India.Devedzic, V., • Software Project Management [Pdf] Available at: < http://devedzic.fon.rs/publications/SEKE-Handbook-2.pdf> [Accessed 8 November 2011].BSSC, 1995. • Guide to software project management [Pdf] Available at: < http://cisas.unipd.it/didactics/STS_school/Software_development/Guide_to_the_SW_project_mangement-0508.pdf> [Accessed 8 November 2011].AJPconsulting, 2011. • Project Estimation [Video online] Available at: < http://www.youtube.com/watch?v=N66kA-J-9xI&feature=related> [Accessed 8 November 2011].AJPconsulting, 2011. • Project Risk Management [Video online] Available at: < http://www.youtube.com/watch?v=vEQ2sh3u9Xc&feature=related> [Accessed 8 November 2011].

Recommended ReadingSundar, D., 2010. • Software Engineering, Laxmi Publications, Ltd.Futrell, T. R., Shafer, F. D. and Shafer, L., 2002. • Quality software project management, Prentice Hall Professional.Thayer, H. R., 1997. • Software engineering project management, IEEE Computer Society.


122

Self AssessmentIn_______________,possibleproject;productandbusinessrisksareidentified.1.

Riskidentificationa. Risk analysisb. Risk planningc. Risk monitoringd.

In ______________ , the likelihood and consequences of the risks are assessed.2. Riskidentificationa. Risk analysisb. Risk planningc. Risk monitoringd.

In ___________ , plans to address the risk either by avoiding it or minimising its effects on the project is drawn 3. up.

riskidentificationa. risk analysisb. risk planningc. risk monitoringd.

In ___________ , the risk is constantly assessed and plans for risk mitigation are revised as more information 4. about the risk becomes available.

riskidentificationa. risk analysisb. risk planningc. risk monitoringd.

Which of the following statement is true?5. Risk management is increasingly seen as one of the main jobs of project managers. a. Risk management is increasingly seen as one of the main jobs of company. b. Risk management is increasingly seen as one of the main jobs of administrator. c. Risk management is increasingly seen as one of the main jobs of organisation. d.

_______________ is like any other project management situation that involves a heavy dosage of “people” 6. management.

Riskidentificationa. Risk analysisb. Risk planningc. Software project managementd.

__________________ are associated with defects found after the product has been shipped to the customer.7. External failure costsa. Riskidentificationb. Risk analysisc. Risk planningd.

123

______________ are those that would disappear if no defects appeared before shipping a product to 8. customers.

Product cost a. Main cost b. Total cost c. Failure costsd.

_______________ is to be divided into costs associated with prevention, appraisal, and failure.9. Quality costsa. Main costsb. Total costs c. Failure costsd.

_________________ consists of auditing and reporting functions of management.10. Risk a. Cost b. Quality assurancec. Failure cost d.


124

Application I

Course Scheduling

Problem DescriptionThe computer science department in a university offers many courses every semester, which are taught by many instructors. These courses are scheduled based on some policy directions of the department. Currently the scheduling isdonemanually,butthedepartmentwouldliketoautomateit.Wehavetofirstunderstandtheproblemandthenproduce a requirements document based on our understanding of the problem.

Problem AnalysisWedotheproblemanalysishere—therequirementsspecificationdocumentisavailablefromtheWebsiteofthebook.Foranalysis,wefirstidentifythepartiesinvolved.

Client: Chairman of the computer science department.

End Users: Department secretary and instructors.

Eachinstructorspecifies,onasheetofpaper,thecourseheisteaching,expectedenrollment,andhispreferencesforlecturetimes.Thesepreferencesmustbevalidlecturetimes,whicharespecifiedbythedepartment.Thesesheetsare given to the department secretary, who keeps them in the order they are received. After the deadline expires, thesecretarydoesthescheduling.Copiesofthefinalschedulearesenttotheinstructors.TheoverallDFDforthesystem is shown in Figure below:

Collected Forms

Inst

ruct

or

Collect Schedule Schedule

Form In

stru

ctor

Fig. 1 Top Level DFD for the current scheduling system

This DFD was discussed with the chairman and the department secretary and approved by them. We now focus on the scheduling process, which is our main interest. Prom the chairman we found that the two major policies regarding scheduling are: (1) the post-graduate (PG) courses are given preference over undergraduate (UG) courses, and (2) no two PG courses can be scheduled at the same time.

Thedepartmentsecretarywasinterviewedatlengthtofindoutthedetailsoftheschedulingactivity.Theschedulesof the last few semesters, together with their respective inputs (i.e., the sheets) were also studied. It was found that the basic process is as follows. The sheets are separated into three piles—one for PG courses with preferences, one for UG courses with preferences, and one for courses with no preference. The order of the sheets in the three piles was maintained. First the courses in the PG pile were scheduled and then the courses in the UG pile were scheduled. The courses were scheduled in the order they appeared in the pile. During scheduling no backtracking was done, i.e., once a course is scheduled, the scheduling of later courses has no effect on its schedule. After all the PG and UG courses with preferences were processed, courses without any preferences were scheduled in the available slots. It was also found that information about classrooms and the department-approved lecture times was tacitly used during the scheduling. The DFD for the schedule process is shown in Figure below

125

The secretary was not able to explain the algorithm used for scheduling. It is likely that some hit-and-miss approach is being followed. However, while scheduling, the following was being checked:

Classroomcapacityissufficientforthecourse.1. A slot for a room is never allotted to more than one course.2.

Thetwobasicdataflowsarethesheetscontainingpreferencesandthefinalschedule.Thedatadictionaryentryforthese is:

Collect_forms = [instructor_name + course_number + [preferences] *]Schedule = [course_number class_room lecture_time]*

Collected Forms

PG Courses

Partial Schedule

UG-Courses Courses without Preferences

Partial Schedule

Schedule

Separate Schedule PG

Schedule UG

Schedule Rest

Fig. 2 The DFD for the schedule process

NowwehavetodefinetheDFDfortheneworfutureautomatedsystem.Automatingschedulingcanaffectthepreference collection method, so boundaries of change include the entire system. After discussion with the chairman, the instructors, and the secretary, the following decisions were made regarding what the automated system should do and what the new environment should be:

The preferences will be electronically mailed to the secretary by the instructors. The secretary will put these 1. preferencesfordifferentcoursesinafileintheorderinwhichtheyarereceived.Thesecretarywillalsomakeentries for all courses for which no response has been given before the deadline. Entries for these courses will have no preferences.The format for each course entry should be similar to the one currently being used.2. Entries might have errors, so the system should be able to check for errors.3. The current approach for scheduling should be followed. However, the system should make sure that scheduling 4. of UG courses does not make a PG course without any preference unscheduled. This is not being done currently, but is desired.Areasonforunschedulabilityshouldbegivenforthepreferencesthatarenotsatisfiedorforcoursesthatcannot5. be scheduled.Informationaboutdepartmentcourses,classrooms,andvalidlecturetimeswillbekeptinafile.6.


126

Dept-DB

Schedule

Conflictreport

Send E-mail

Combine into File

Schedule

Pref-File

Pref

Man-Machine Boundary

Fig. 3 DFD for new system

TheDFDforthenewlogicalsystem(onewithautomation)canbeseenintheabovefigure.ThetwoimportantdataentitiesarethetwofilesintheDFD.

The data dictionary entry for these is:

Prefs_file=[pref]*Pref = course_number + enrollment + [Preferences]*Dept_DB = [class_room]* + dept_course_list + [valid_lecture_time]*Class_rooms = room_no + capacity

It is decided that the scheduling process will be automated. The rest (such as combining preferences) will be done manually. Based on the format currently used in the sheets, a detailed format for the course entries was decided and approvedbytheinstructors.Adetailedformatforthedept_DBfilewasalsochosenandapproved.

(Source: Jalote, P., 2005. An integrated approach to software engineering, Birkhäuser.)

QuestionsWhat is the Problem Analysis for Course Scheduling?1. AnswerTherequirementsspecificationdocumentisfortheanalysis;wefirstidentifythepartiesinvolved.

Client: Chairman of the computer science department.

End Users: Department secretary and instructors.

Eachinstructorspecifies,onasheetofpaper,thecourseheisteaching,expectedenrollment,andhispreferencesforlecturetimes.Thesepreferencesmustbevalidlecturetimes,whicharespecifiedbythedepartment.Thesesheets are given to the department secretary, who keeps them in the order they are received. After the deadline expires, the secretary does the scheduling.

127

Thedepartmentsecretarywasinterviewedatlengthtofindoutthedetailsoftheschedulingactivity.Thescheduleof the last few semesters, together with their respective inputs (i.e., the sheets) was also studied. It was found that the basic process is as follows. The sheets are separated into three piles one for PG courses with preferences, one for UG courses with preferences, and one for courses with no preference. The order of the sheets in the three piles was maintained. First the courses in the PG pile were scheduled and then the courses in the UG pile were scheduled. The courses were scheduled in the order they appeared in the pile. During scheduling no backtracking was done, i.e., once a course is scheduled, the scheduling of later courses has no effect on its schedule. After all the PG and UG courses with preferences were processed, courses without any preferences were scheduled in the available slots. It was also found that information about classrooms and the department-approved lecture times was tacitly used during the scheduling.

The secretary was not able to explain the algorithm used for scheduling. It is likely that some hit-and-miss approach is being followed. However, while scheduling, the following was being checked:

Classroomcapacityissufficientforthecourse.•A slot for a room is never allotted to more than one course.•

What are the conditions for new environment of the system?2. AnswerThe new environment should be:

The preferences will be electronically mailed to the secretary by the instructors. The secretary will put these •preferencesfordifferentcoursesinafileintheorderinwhichtheyarereceived.Thesecretarywillalsomake entries for all courses for which no response has been given before the deadline. Entries for these courses will have no preferences.The format for each course entry should be similar to the one currently being used.•Entries might have errors, so the system should be able to check for errors.•The current approach for scheduling should be followed. However, the system should make sure that •scheduling of UG courses does not make a PG course without any preference unschedulable. This is not being done currently, but is desired.Areasonforunscheduledcourseshouldbegivenforthepreferencesthatarenotsatisfiedorforcourses•that cannot be scheduledInformationaboutdepartmentcourses,classrooms,andvalidlecturetimeswillbekeptinafile.•

What is the decision taken for the scheduling process?3. AnswerIt is decided that the scheduling process will be automated. The rest (such as combining preferences) will be done manually. Based on the format currently used in the sheets, a detailed format for the course entries was decided andapprovedbytheinstructors.Adetailedformatforthedept_DBfilewasalsochosenandapproved.


128

Application II

Software cost estimation using use case points: Getting use case transactions straight

An important part of the decision-making around starting a new software development project is what it will cost. Estimating these costs has troubled system analysts, project managers, and software engineers for decades. The firsthurdleisgettingthescopeoftheprojectright.Whatshouldthesystembeabletodo?Capturingfunctionalrequirements in use cases has helped considerably in communicating requirements in a form that is understandable for users and other domain experts. Early in the project a use case model is made, containing a list of all actors (users or external systems) and use cases in the system, their names, and a brief description. Capturing this information makes it easier to reach agreement on the size of the system early in the project.

Theusecasepoint’smethod,whichwe’llsketchbelow,isapromisingestimationmethodthatfitsinnicelywiththeuse case approach to describing requirements. At its basis lies the concept of a use case transaction, the smallest unit of size measurement. There are, unfortunately, many diverging assumptions on the notion of a use case transaction.In this article we take a look at some of these views and how well they work in practice. We start with a sketch of the usecasepoint’smethod,followedbyadiscussiononwhatdefinitionofausecasetransactionworksbest.Wealsoshow how use case transactions are connected to other concepts around use cases. We conclude with a discussion on how (not) to count them.

Use case pointsThe use case point’s method is a well-documented approach for estimating software development activities. No estimation method, however, should be used just by itself, but needs to be balanced by other methods. Here we focus on use case points. Figure 1 presents its main ideas. At its basis lies the use case model, which consists of actorsandusecases.Thenumberandweightoftheusecasesidentifiedisthemostimportantcomponentinthecalculation of the so-called unadjusted use case points. The size of a system is calculated from the unadjusted use case points by adjusting them with the technical complexity factor, obtained from a consideration of the system’s technical properties.

Once you have an estimation of a system’s size, you can start to think about calculating the effort. You do this by calculatingtheenvironmentalfactor(EF)fromtheteam’squalificationsandotherenvironmentalinfluences.Averyimportant environmental factor is the stability of requirements. You should also look at how many hours per use case point (H) are needed. Finally, add the supplementary effort (SE) not accounted for in the use case points model (such as project management hours, integration testing) and the effort estimation is complete.

129

+

Has Realised by

1..**

Describes usage

1..**

1..**Contains

Calculated from

Calculated from

Calculated from

Calculated from

Calculated from

Actor Weight

*

Unadjusted use case points

Size

Technical comp-lexity factor

Environment factor

Hours per use case point

Supplementary Efforts

Effort

Size* HF*H+SE

Use case weight

Consist of

Use Case model

Actor

Team properties

Other environ-mental factors

Technical Properties Project

Use case

Use Case model

Use Case transaction

Fig. 1 Main concepts of the use case point’s method

The weight of a use case is determined by the number of different use case transactions in the interaction between the actor and the system to be built.

According to the use case point’s method, the criteria to assign a weight to a use case are:Simple use case -- 1 to 3 transactions, weight = 5•Average use case -- 4 to 7 transactions, weight = 10•Complex use case -- more than 7 transactions, weight = 15•

Hence,assumptionsaboutthenatureofatransactionandthestrategyusedtocounttransactionshighlyinfluenceyour estimation.

What is a use case transaction?The concept of a (use case) transaction helps to deal with the variation in length and conciseness typical of use casedescriptions.usecasespecificationscanbeterselywritten,orberatherverbose/detailed,dependingontheusecase template used, the approach adopted, the business context involved, or the personal taste of the Requirements Specifier.Thenumberofstepsinausecaseflow,whichdescribestheinteractionbetweenanactorandthesystem,can also vary widely both across and within scenarios. You can test for “sameness of size” by detecting and counting theusecasetransactionsthatareinvolvedinyourusecasespecifications.Iftwousecasespecificationshavethesame number of unique transactions, they have the same size.


130

A use case transaction is a “round trip”Ivar Jacobson, inventor of the use case, describes a use case transaction as a “round trip” from the user to the system backtotheuser;atransactionisfinishedwhenthesystemawaitsanewinputstimulus.Inotherwords,inonetransaction the actor performs some action which is input for the system. Then the system reacts; i.e., it processes the input and returns the result to the Actor. A new transaction starts when the actor reacts to the result, which in turn is input for the system.

A use case transaction is not always a use case stepJacobson’sstatementalsoimpliesthatausecasetransactionisnotbydefinition“astepintheusecaseflow.”Thisisonlytrueifastepinausecaseflowitselfconsistsofa“roundtrip.”Althoughsomeapproachesonwritingusecases prescribe this alternate method of delineating use case transactions, it is by no means the standard way.

A use case transaction is not a “stimulus” as suchSomeauthorssuggestthat“theexistenceofastimulusperformedbyanactoriswhatdefinesatransaction.”.Althougha transaction starts with a stimulus (the actor does something that triggers the system), the stimulus itself is not the complete transaction. Suppose you have a use case description that reads:The user selects an X. ...(n)The user submits. ...

Then it is unclear whether the system reacts to the stimuli in steps (1) and (n) in one reaction, or whether the system instead reacts to steps (1) and (n) separately. Hence, two stimuli could make up one transaction or two. This depends not on the stimuli but on the combination of stimulus and response.

Use case transaction is not a database activityInmanydiscussionsontheWeb,youfindausecasetransactiondefinedas“asetofactivities,whichiseitherperformedentirely,ornotatall.”.Thisdefinitionsoundslikethatofatransactionalmechanisminadatabasemanagementsystem, in which a step can be rolled back if it is not performed correctly. In our experience, this is not a good way to isolate one piece of content from another in a use case description. It may give rise to the idea that a transaction is somehow related to a read or write action on a database. However, it is quite possible that in a round trip, the system does not have to consult the database at all. There may not even be a database involved, or data may come from outside the system. Thus it is not appropriate to conclude that use case transactions are necessarily linked to transactions on a database.

A use case transaction is not a system stepThe response of the system in a use case transaction may be written as one step. On the surface, one could get the impression that a use case transaction just is a system step. A system step, however, is not a good basis for delineating ausecasetransaction,foritdependsonthegranularityofthedescriptionofaflowhowmanystepsyoucount.Moreover, system steps alone don’t say much about the interaction taking place between an Actor and the system. In other words, your estimation should be based on transactions being “round trips,” not system steps.

An example: complex user interfacesThe “round trip” approach to use case transactions shows its value in the case of estimating the complexity of user interfaces. Our example to follow stems from a job portal project, in which a job search machine was designed. In the early estimation based on the use case model (Survey), the job search interface was regarded as simple; it was expectedthattheuserwouldselectsearchitemsfromacoupleofdrop-downmenusandthenfirehisselection.However,intheusersessionsdedicatedtoproducingtheusecasespecificationitbecameobviousthattheusabilityof the application would be enhanced if the system could respond to selections already made, and change the content of subsequent drop-down menus. In other words, what was regarded to be one transaction turned out to be two.Hereisthefirstdraftoftheusecasespecification:

131

The user selects and X and Ys and submits 1. } Transaction 1The system searches for hits and shows the results2.

This text was expanded as follows:

The user selects an X 1. } Transaction 1The system shows the Ys connected with this X2. The user also selects one or more Ys and submits 3. }The system searches for hits and shows the results Transaction 24.

Youseethetwo“roundtrips”clearlyhere.Withtheusecasespecificationastestimony,itbecameeasytoseetherationale for adjusting the initial estimation.

Keep use case transactions at the appropriate levelIf a use case transaction is a stimulus followed by a system response, would then just about anything not count as a transaction? For example, if I type a character ‘K’ on my keyboard, this is a stimulus, with the system responding to it byproducingafewpixelsonthescreenthatareidentifiableas‘K’.Soisn’tthedefinitionwe’vebeenrecommendingthen much too narrow?

No, it is not. This objection shows that you should interpret use case transactions at the same level at which the use case itself is meant to be interpreted. Nowadays, you typically would not be interested in the phenomenon of typing a character, which then appears somewhere on the screen. You just take it for granted; you don’t have to build something in the system to produce this result. However, if your context is a description of the interaction of a keyboard module and a graphical renderer, such a use case transaction makes perfect sense.

How to count transactionsNow that you’ve seen a clear rationale for deciding what is and what is not a use case transaction, let’s examine some of the challenges of counting transactions within use cases. As stated above, the weight of a use case is determined by the number of different use case transactions it contains. But exactly when does the system’s reaction to a stimulus count as different?

Use case transactions and flowsLetusbeginbyexaminingthesearchflowofthejobportalintroducedabove.Iftheactorlooksforajobinthecategory of “Java,” he selects Java and the system will search its database for all jobs in that category. When the actor looks for a job in the category of “.Net,” he selects .Net and the system will search its database for all jobs inthatcategory.Arethesetwodifferenttransactions?Clearlynot.Theusecasespecificationitselfisabstractorgeneric,inthesensethatyoudon’texpectdifferentflowsfordifferentsearchterms.Thisisjustadifferenceininstantiation.However,youwouldexpectdifferentflowsfor,say,asearchusingpredefinedcategoriesorafree-format text search.

Handlingexceptions,ontheotherhand,isagreyarea.Supposeyouhaveaninputscreenwithsevenfields,allofthemwithdifferentconstraints.Youhaveadatefield,apostalcode,afieldwhoseinputisconditionaluponthecontentofanother,andsoon.Eachcheckmaybedescribedinaseparateflow,andhencemaycountasatleastonetransaction.Alternatively,agenericexceptionflowmaybeprovided.Thispresupposesthatthereisaframeworkinplaceinwhichseveralexceptiontypesarehandledeasily.Inthiscase,youshouldcounttheflowasonetransaction.

Usecasetransactions,beingroundtrips,shouldbeexpectedeverywhereintheusecase.Sinceausecasespecificationhasatleastabasicflow,italsohasatleastonetransaction.Aflowwithoutatransactionisnotmeaningful,fortheneither the system would do something without stimulus, or the actor would provide one or more stimuli without it being clear what the system’s reaction would be.

Therearenearlyalwaysflowsthatdescribehandlinganexception(hence,“exceptionflows”).Everyexceptionflowcontainsatleastonetransaction.Thesameistrueforanalternativeflow;hereyouhaveatleastonetransactionperalternativeflow.Itmaybethecasethatyouhavetolookinthebasicflowtoseethestimulusofthetransactioninyouralternativeflow;thisdependsonyourspecificguidelinesfordetailingausecase.


132

Thisgivesusanindicationoftheminimumamountofusecasetransactionsinanyusecasespecification:thereareatleastasmanytransactionsasthereareflows.8

Showing and (not) countingGiven the ability to identify your use case transactions, do you have to take each and every transaction equally seriously? Our strategy is to show each and every transaction (if applicable), but sometimes not to count them in weight. This strategy is more straightforward to follow than just to ignore transactions if they seem “too light.” It is also easier to adjust the original estimation, if necessary.

In this way, you are able to show the value of frameworks. If a use case counts ten transactions, but only seven of them need effort and three “follow” from the framework, that use case is average rather than complex. Table 1 shows an example.

Use case #Transactions #Counted Reason UC Weight

1 Apply for job 4 3 Simple

2 Find job 3 3 Simple

3 Assess application 10 7 Framework Average

Table 1 Transactions counted across hypothetical use cases

Many system steps could well be a new use caseIs there no way to account for the difference between many system steps implied by one use case transaction versus just one system step? Your intuition says that it takes more effort to build six system steps than one. Indeed, we completely agree. However, you should not try to solve this little puzzle by counting system steps as transactions, but by isolating the functionality involved in these extra system steps. If you have an obvious heap of functionality, then probably it is a use case in itself. Be careful not to promote just any heap of functionality to the status of ‘use case’ -- that would be functional decomposition -- but apply the following rule: Candidate use cases must always have a clear goal, matching the interest of at least one stakeholder (not necessarily identical with the actor).9

An example could be the use case “Generate annual balance.” In the course of this use case several reports are generated,eachbeingofinteresttoaspecificstakeholder.Thereareseveralsystemstepsinvolvedinthegenerationofeachreport.Definingaseparateusecaseforeachreporthelpsyoutofindtherightstakeholder--andnottobotherotherstakeholders.Inthisway,weareabletoprovideamorefinegrainedestimation.

Batch jobsIf it is true that a use case should also be used in the absence of user interaction (and we have good experiences in doing so), then how can you apply the concept of a transaction as a round trip? Well, frankly, it does not apply here. You need other ways to estimate the weight of such use cases. Mostly, this is done by expert estimation. Table 2 shows how this could look in your spreadsheet.

Use case #Transactions #Counted Reason UC Weight

1 Apply for job 4 3 Simple

2 Find job 3 3 Simple

3 Assess application 10 7 Framework Average

4readflatintodatabase -- -- Expert estimate Complex

Table 2 Transaction count with batch job added

http://www.ibm.com/developerworks/rational/library/edge/09/mar09/collaris_dekker/#notes

http://www.ibm.com/developerworks/rational/library/edge/09/mar09/collaris_dekker/#notes

133

Very complex use casesSomeauthorsseeadifficultyin theusecasepointsmethodbecausethereisnodistinctionbetweenacomplexuse case of, say, eight transactions, and a complex use case of sixteen transactions. In our experience, use cases consisting of more than twelve transactions serve more than one goal. So, they are a sign of a problematic use case model. In other words, it is worthwhile to consider a new use case if at any point you have a use case of more than twelve transactions.

Counting use case transactions early in the projectCountingtransactionsiseasywhenallusecasespecificationsarewritten.Ontheotherhand,estimationisexpectedearly in the project. At that point, you only have the use case model, with a brief description per use case. In order to envisiontheflowsthatwillmakeuptheusecasesandtheusecasetransactionstheyinvolve,youneedexperience.Ifyou don’t have this experience yourself, don’t hesitate to consult colleagues who have worked with similar systems andcontexts.StartbycreatingaspreadsheetliketheoneinTable2,andfillintheenvisionedtransactions.Thiswill form a basis for managing the scope of the use cases, for you will be able to explain in detail which use cases involve more transactions than initially envisioned by the customer.

ConclusionIn order to apply the use case point’s method to the estimation of software effort estimation, it is important to have a good idea of its basic constituents. The notion of a use case transaction is such a constituent, and it is best taken to bearoundtrip,fromtheactor-initiatedstimulustothesystem’sresponse.Thetransactionisfinishedifthesystemawaits a further stimulus.

Working with this notion, we have made some suggestions on how and when to count transactions. While this is more an art than a science, applying these recommendations along with common sense and experience can help you make more accurate effort and costs estimates earlier in a project.

(Source: Collaris, A. R. & Dekker, E., 2009. Software cost estimation using use case points: Getting use case transactions straight [Online] Available at: < http://www.ibm.com/developerworks/rational/library/edge/09/mar09/collaris_dekker/> [Accessed 9 November 2011].)

QuestionsWhat are the steps to be followed for cost estimation?1. Which are the factors to be considered while estimating cost for the software engineering?2. What are the elements of successful cost estimation?3.


134

Application III

Software testing series: A case study

Why we needed something (The Problem)Bugsinthissoftwareregularlyledto10sto100sofhours(perbug)incostwhentheyreachedthefield.Thesebugswouldalsointroduceariskoflostsalesorprofits.Thismanagerwasresponsiblefordevelopmentandtesting,butnot requirements.

Thisexistingenterpriseapplicationwaswrittenabouttenyearsago,hadsignificantchangesineverymonthlyrelease,andhadasmalldevelopmentteamaveragingaboutfivepeople,withregularrotationsontoandofftheproject.Therewere over a quarter of a million lines of code in this application. The application had a very large user interface, and complicated integration with other systems. The team had an existing process of manual testing, both by developers and dedicated testers, and a large suite of automated blackbox system tests. The developers did not have practical experience in creating unit tests or applying unit test automation.

An analysis of the bugs revealed a majority of them as being introduced in the development cycle, with requirements bugs in second place.

The objectiveImmediately improve the perception of quality of the software by outside organisations.•Improve quality measurably for the long term.•Reduce the cost of quality for the software from existing levels.•

The ConstraintsNo personnel changes – any changes must be supported by the current team (no permanent additions or 1. replacements).No changes in existing committments to stakeholders – commitments are in place for 6 months (at the full 2. capacity of the team).Smallbudgetfortheproject–aone-timecostoflessthan5%oftheoperatingbudget(forthecurrentteam),3. with long term costs offset by other gains in productivity.

The StrategyImprove existing automated regression testing to improve quality for the long term.1. Change the development process to include regression testing as part of code-promotion (versus the current 2. practice of regression testing release candidates).

The TacticsUseunittesting(specificallywhiteboxtesting)toaugmentexistingtestframework1. - overall, a gray box testing process. To minimise the maintenance effort over time, the testing framework was developed to use data-driven scripts that represent user sessions with the software. This allowed the team to easily create (and delegate creation of) scripts that represented user sessions. These scripts were combined with a set of inspections that tested the application for particular parameters, outputs, and behaviours. The intersections of scripts and inspections result in unit tests.Immediately start writing test for all new code. We 2. flipped a switch and required developers “from this day forward” to replace their current manual feature testing for ongoing development with creation of automated unittestsforongoingdevelopment.KentBeckfirstsuggestedthistechniquetomeaboutfiveyearsagoasawayto“addtesting”toanexistingapplication.Histheoryisthattheareasofthecodethatarebeingmodifiedare the areas of the code most likely to be broken – existing code is less likely to spontaneously break, and is notthetoppriorityfortesting.Overtime,ifallofthecodegetsmodified,thenallofthecodegetstested.

135

Jump starts a small initial test suite3. . We timeboxed a small initial effort to identify the “high risk” areas of the application usagebydefiningthemostcommonusagepatterns.Thesepatternswerethenembodiedinasetofscriptsthat were used in the testing framework. We also set aside time for creating a set of initial inspections designed toprovidevaluableinsightintothegutsoftheapplication.Thedevelopersidentifiedthosethingsthatthey“commonly looked at” when making changes to the application. These inspections instrumented elements of the application (like a temperature gauge in your car – it tells you if the coolant is too hot, even if it doesn’t tell you why).

Unfortunately, we can’t share the results beyond the client’s internal team. Anecdotally, a very similar approach for a differentclient,team,andapplicationnetteda10%reductionindevelopmenteffortandhadadramaticallypositiveaffect on both quality and perceived quality. At Tyner Blain, we strongly encourage using this approach.

Top seven tips for rolling out this plan effectivelySet expectations. A key constraint for this approach was “don’t spend a bunch of money.” The process is •designed to improve quality over time, with little (and dwindling) incremental cost. Every month, as more tests areaddedalongwithnewcode,theopportunityforbugstobereleasedtothetestteam(muchlesstothefield)goes down. The rate of quality improvement will be proportional to the rate of change in the code base. Also point out that only those bugs introduced in the development cycle will be caught – requirements bugs will not be caught.Educate the development team. When asking developers to change the way they’ve been writing and releasing •code for a decade, it can be tricky to get acceptance. Responses can be as bad as “We don’t have a problem with quality” or “I know how to do my job – you’re telling me that I don’t?” if this isn’t done. Start with education aboutthetechniquesandhighlightthetangiblebenefitstodevelopers.Therewillbereducedcomplaintsaboutthe quality of the code – most developers are proud of their work, and will gladly adopt any technique that helps them improve it – as long as they don’t feel defensive about it.Educate the managers. Help managers understand that unit testing isn’t a silver bullet – it can’t catch every bug, •but done correctly, unit testing will catch the most bugs per dollar invested.Educate the test team. No, we’re not automating you out of a job. A gray box testing strategy is comprehensive. •Automating regression testing effectively allows manual testers to focus on system level testing and overall quality assurance. The time saved can be applied to testing that should be, but isn’t being done today.Establish ownership. The developers are being asked to take ownership • explicitly for something they already own implicitly. Before incorporating regression testing as part of the development cycle, the contract with the test team was “The new stuff works. Let me know if I broke any of the old stuff.” With this process in place, the contract between the development team and the test team becomes “The new stuff works, some of the old stuff still works, and the new stuff will continue to work forever.”Providefeedback.Trackthemetrics,suchasbugsversuslinesofcode(existingandmodified)orbugsversus•usersessions.Absolutenumbers(bugsinthefield,bugsfoundintest,numbersofinspections and scripts and unit tests) are also good. Communicate these and other metrics to everyone on the team – managers, developers, testers. Provide the feedback regularly (at least with every release). This will help the project gain momentum and visibility. That will validate the ideas, and help propagate the approach to other software development cycles.Leverage the feedback cycle to empower the team members to make it even better.•

(Source: Sehlhorst, S., 2006. Software testing series: A case study [Online] Available at: < http://tynerblain.com/blog/2006/01/22/software-testing-series-a-case-study/> [Accessed 9 November 2011].)

QuestionsWhich are the levels of testing?1. WhatareTestcasesspecifications?2. What are Test plans?3.


136

Bibliography

References Aggarwal, K. K., 2005. • Software engineering, New Age International.AJPconsulting, 2011. • Project Estimation [Video online] Available at: <http://www.youtube.com/watch?v=N66kA-J-9xI&feature=related> [Accessed 8 November 2011].AJPconsulting, 2011. • Project Risk Management [Video online] Available at: <http://www.youtube.com/watch?v=vEQ2sh3u9Xc&feature=related> [Accessed 8 November 2011].Blueoptimasupport, 2010. • [1 of 5] Coding Effort: Taking Software Development Process Improvement to the Next Level [Video online] Available at: <http://www.youtube.com/watch?v=2oB5VQQUlzc> [Accessed 7 November 2011].Bruegge, B., 2004. • Object-Oriented Software Engineering: Using Uml, Patterns And Java, 2nd ed., Pearson Education India.BSSC, 1995. • Guide to software project management [Pdf] Available at: <http://cisas.unipd.it/didactics/STS_school/Software_development/Guide_to_the_SW_project_mangement-0508.pdf> [Accessed 8 November 2011].Copeland, L., 2004. • A practitioner’s guide to software test design, Artech House.CSE IIT Kharagpur, • Characteristics of Software Maintenance [Pdf] Available at: <http://nptel.iitm.ac.in/courses/Webcourse-contents/IIT%20Kharagpur/Soft%20Engg/pdf/m14L36.pdf>[Accessed7November2011].Devedzic, V., • Software Project Management [Pdf] Available at: <http://devedzic.fon.rs/publications/SEKE-Handbook-2.pdf> [Accessed 8 November 2011].Doe, J., 2011. • Test Plan [Online] Available at: <http://softwaretestingfundamentals.com/test-plan/> [Accessed 7 November 2011].Dooley, J., 2011. • Software Development and Professional Practice, Apress.Freetutes.com, • Waterfall Software Development Life Cycle Model [Online] Available at: <http://www.freetutes.com/systemanalysis/sa2-waterfall-software-life-cycle.html> [Accessed 7 October 2011].George, J., • Traditional versus Object-Oriented Approach [Online] Available at: <http://www.georgejojo.com/index.php?option=com_content&view=article&id=60:information-report-traditional-and-object-oriented-methodology-for-system-development> [Accessed 7 November 2011].Halili, H. E., 2011. • Functional Testing [Online] Available at: <http://www.webreference.com/authoring/jmeter/> [Accessed 7 November 2011].Henry, J., 2004. • Software Project Management: A Real-World Guide To Success, Pearson Education India.Hughes, B. and Cotterell, M., 2009. • Software Project Management, McGraw-Hill Higher Education.IEEE Software, 1996. • Missing in Action: Information Hiding [Online] Available at: <http://www.stevemcconnell.com/ieeesoftware/bp02.htm> [Accessed 7 November 2011].Jalote, P., 2008. • A concise introduction to software engineering, Springer.Lauesen, S., 2002. • Software requirements: styles and techniques, Addison-Wesley.Leach, J. R., 2000. • Introduction to software engineering, CRC Press.LesChambers1, 2011. • Specifying Software Requirements [Video online] Available at: <http://www.youtube.com/watch?v=SBfBq5DmxD8> [Accessed 7 October 2011].Mall, R., 2004. • Fundamentals of Software Engineering, PHI Learning Pvt. Ltd.NYS Project Management Guidebook, • System Design [Pdf] Available at: <http://www.cio.ny.gov/pmmp/guidebook2/SystemDesign.pdf> [Accessed 7 November 2011].OneStopTesting.com, 2003. • Iterative Model [Online] Available at: <http://www.onestoptesting.com/sdlc-models/iterative-model.asp> [Accessed 7 November 2011].Ould, A. M. and Unwin, C., 1986. • Testing in software development, Cambridge University Press.

137

Plum, T., 1984. • General Style and Coding Standards for Software Projects [Pdf] Available at: <http://www.cse.buffalo.edu/~rapaport/code.documentation.Excerpts.pdf> [Accessed 7 November 2011].Prof. Bellur, U., 2008. • Requirements Engineering / Specification [Video online] Available at: <http://www.youtube.com/watch?v=wEr6mwquPLY&feature=related> [Accessed 7 November 2011].Prof. Biswajit, 2011. • 20 - System Design – I [Video online] Available at: <http://www.youtube.com/watch?v=OM9uJuOtgE4&feature=results_video&playnext=1&list=PL0A0C5C062C10A3E5> [Accessed 7 November 2011].Prof. Joshi, R. K., 2008. • Lecture - 14 Software Design - Primary Consideration [Video online] Available at: <http://www.youtube.com/watch?v=izAq05SBvMI> [Accessed 7 November 2011].Prof. Joshi, R. K., 2008. • Lecture - 18 Software Testing – I [Video online] Available at: <http://www.youtube.com/watch?v=zZdQ6HXXDiE&feature=results_video&playnext=1&list=PL709425D63691F722> [Accessed 7 November 2011].Prof. Joshi, R. K., 2008. • Lecture - 19 Software Testing – II [Video online] Available at: <http://www.youtube.com/watch?v=B_yYAbQVitQ&feature=relmfu> [Accessed 7 November 2011].Prof. N. L., 2008. • Lecture - 2 Introduction to Software Engineering [Video online] Available at: <http://www.youtube.com/watch?v=AN5I6fFxyfs> [Accessed 7 November 2011].Prof. N. L., 2008. • Lecture - 3 Overview of Phases [Video online] Available at: <http://www.youtube.com/watch?v=nzCufJMc5Xk&feature=relmfu> [Accessed 7 November 2011].Scribd.Inc, 2011. • Software Process Models [Online] Available at: <http://www.scribd.com/doc/25465086/Software-Process-Models> [Accessed 7 November 2011].SelectBusinessSolns. 2011• . The Software Process [Video online] Available at: <http://www.youtube.com/watch?v=YMbAdgb6pG8> [Accessed 7 November 2011].StanfordUniversity, 2008. • Lecture 1 | Programming Methodology (Stanford) [Video online] Available at: <http://www.youtube.com/watch?v=KkMDCCdjyW8> [Accessed 7 November 2011].Sundar, D., 2010. • Software Engineering, Laxmi Publications, Ltd.The Software Experts, • Software Process Models [Online] Available at: <http://www.the-software-experts.de/e_dta-sw-process.htm> [Accessed 7 November 2011].Tsui, F. F. and Karam, O., 2007. • Essential of Software Engineering, Jones & Bartlett Learning.Wiegers, E. K., 2009. • Software Requirements, 2nd ed., O’Reilly Media, Inc.www.softwaretestingmodels.com, 2008. • Software Development Life Cycles: Waterfall Model, V-Model [Video online] Available at: <http://www.youtube.com/watch?v=KaPC0gsEQ68> [Accessed 7 November 2011].www.SPMN.com, 2010. • SPMN Focus Team Lessons Learned [Online] Available at: <http://www.spmn.com/lessons.html#eleven> [Accessed 7 November 2011].

Recommended Reading Agarwal, B. B, and Tayal, P. S., 2007. • Software Engineering, Firewall Media.Blum, I. B., 1992. • Software engineering: a holistic view, Oxford University Press.Craig, D. R. and Jaskiel, P. S., 2002. • Systematic software testing, Artech House.Desikan• , S. and Ramesh, G., 2006. Software Testing: Principles and Practice, Pearson Education IndiaFutrell, T. R., Shafer, F. D. and Shafer, L., 2002. • Quality software project management, Prentice Hall Professional.Jalote, P., 2002. • Software Project Management in Practice, Pearson Education India.Jawadekar, S. W., 2004. • Software Engineering: Principles and Practice, Tata McGraw-Hill Education.Kelkar, A. S., 2007. • Software Engineering: A Concise Study, PHI Learning Pvt. Ltd.Kotonya, G. and Sommerville, I., 1998. • Requirements engineering: processes and techniques, J. Wiley.Langer, M. A., 2007. • Analysis and design of information systems, 3rd ed., Springer.


138

Martin, N. J., 1997. • Systems engineering guidebook: a process for developing systems and products, CRC Press.Patton, 2006. • Software Testing, Pearson Education India.Peters, F. J., 2007. • Software Engineering An Engineering Approach, Wiley-India.Puntambekar, A. A., 2009. • Software Engineering, Technical Publications.Rajaraman, V., 2004. • Analysis and design of information systems, 2nd ed., PHI Learning Pvt. Ltd.Saleh, A. K., 2009. • Software Engineering, J. Ross Publishing.Sharma P., 2004. • Software Engineering, APH Publishing.Sommerville, I. and Sawyer, P., 1997. • Requirements engineering: a good practice guide, John Wiley and Sons.Sundar, D., 2010. • Software Engineering, Laxmi Publications, Ltd.Thayer, H. R., 1997. • Software engineering project management, IEEE Computer Society.Vliet, V. H., 2000. • Software engineering: principles and practice, 2nd ed., John Wiley.Young, R. R., 2004• . The requirements engineering handbook, Artech House.

139

Self Assessment Answers

Chapter Ia1. d2. a3. b4. a5. b6. a7. c8. d9. d10.

Chapter IIb1. a2. b3. c4. a5. d6. a7. b8. a9. c10.

Chapter III d1. a2. c3. c4. c5. b6. a7. b8. b9. a10.

Chapter IVa1. a2. c3. c4. c5. d6. b7. a8. a9. c10.


140

Chapter Va1. c2. a3. c4. d5. c6. b7. a8. b9. b10.

Chapter VIa1. c2. d3. b4. a5. b6. d7. a8. d9. b10.

Chapter VIIc1. a2. a3. c4. d5. b6. b7. a8. c9. a10.

Chapter VIIIa1. b2. c3. d4. a5. d6. a7. d8. d9. c10.