SE-381 Software Engineering

BEIT-VLecture no. 5

Software Engineering Processes1 of 3

Quality Product

• For a quality software product, both the quality of product itself and quality of software process are important.

• The cost of error recovery in the later phases of software is many times more than in earlier phases, so more attention should be paid in the earlier phases, and these should be made error-free.

Boehm 1987 - ‘Industrial Sw Metrics Top 10 List’1. Finding and fixing a Sw problem after delivery, costs 100 times more than

finding and fixing the problem in early design phases2. You can compress Sw development schedule 25% of nominal, but no

more3. For every $1 you spend on development, you will spend $2 on

maintenance4. Sw Development and maintenance costs are primarily a function of the

number of SLOC or DLOC – Delivered Lines of Code5. Variations among people account for the biggest differences in Sw

productivity6. The overall ratio of Sw : Hw costs is still growing, in 1955 it was 15:85, in

1985, 85:15 {and in 2011 it is almost 95:5}7. Only 1/6th or about 15 -16% of sw development effort is devoted to

programming8. Sw products typically cost 3 times as much per SLOC as individual Sw

programs, Sw systems (i.e. system of systems) cost 9 times as much Sw programs (Sw pgm : Sw Product : Sw Sys :: 1:3:9)

9. Walkthroughs catch 60% of the errors10. 80% of the contribution comes from 20% of the contributors – Corollary

of Pareto Law

Pareto Analysis or Principle

In any series of elements to be controlled, a selected, small fraction, in terms of the numbers of elements, always accounts for a large fraction in terms of effect.

– Vilfredo Pareto (1848-1923) – an economist and sociologist

Pareto Analysis or Principle implies

• Focus on the problem and try to identify “the vital or significant few versus the trivial many”

• Few examples

– Only a small percentage of the thousands of inventory items in a department store account for 80% of the dollar sales (large stores capitalize on this)

– Less than10% of employees in an organization will account for most of the absenteeism

– A few percent of the kinds of illnesses are the cause of admission for a great majority of hospital patients

– Steve M Erickson (1981); Management Tools for Everyone: Twenty Analytical Techniques That Are Easy to Learn and Valuable to Know; Petrocelli Books Inc. New York, USA

– A detailed analysis of patients revealed that 80% of common diseases, like fever, cough, cold etc are ‘minor’ diseases and can be cured by educating masses about hygiene

– Dr Ijaz Bashir, Chairman, Decent Welfare Society, Gujrat, Pakistan – Sept 2010– Some figures from Proceedings of the Seminar on CORPORATE

AGRICULTURE: ISSUES & OPTIONS; UAAR (2001)• 93% people own 37% of the land whereas the rest 7% own 63% of the land• Over 80% of the farmers either own less than 2 hectors of land or are landless

tenants• Over 70% of the land holdings are below 12.5 acres• Less than 6% own over 60 hectors of land

• 1 Hectare = 10,000 m2 and 1 acre = 4840 Yards2 = 4047 m2

Maintenance Aspects

– 1970s Development-then-Maintenance Model+ Well defined two stages- Changing Application Environments- Every product developed from Scratch - No reuse

– Maintenance is a process that occurs when‘Software undergoes modifications to code and associated documentation due to a problem or the need of improvement or adaptation’ [ISO/IEC ‘95]

• For every 1$ spent on development, 2$s are spent on maintenance• In 1992, 60%-80% of R & D staff at HP was involved in

Maintenance, and Maintenance constituted 40-60% of the total cost of Software [Colman et al 1994]• Organizations devote upto 80% of their time and effort

to maintenance [Yourdon 1996]• Maintenance is an extreme phase, so techniques

efficient for Maintenance result in overall saving

Maintenance Aspects (Contd.)

Failure Curve for Hardware

Software doesn’t wear out but it deteriorates

Idealized and Actual Failure Curve for Software

Increased Failure rate due to side effects and corrections or bug fixes madeSoftware Engineering methods strive to reduce the magnitude of the spikes and the slope of the actual curve

Software ProcessIs a set of activities and associated results which produce a Software Product. These activities are carried out (mostly) by humans, using different tools (including CASE tools) and predefined methods.

The main four fundamental activities which are common to all Sw processes are:Specification, Development, Validation and Evolution.

There exist a number of Sw Processes, initiated by different individuals and organizations. Different processes can be used to develop the same product, but they do have their own specificities.

Software Processes

Software Process ..

To introduce visibility in the process different graphical notations are used to produce different design documents. Since different methods have different origins, so these are different and have different notations for their deliverable documents. Now effort is being made to unify them.

Different metrics have been devised to control and optimize the software process to produce ‘Quality’ product.

Paradigm or MethodologyIs collection of consistent methods used to support all activities or phases of software development life cycle. Each phase being the part of the process, has its own inputs and deliverables, so these need to conform, semantically and as well as in notations.

Software Process and Its Components

Software Process

Product Engineering Processes

Process Management Process

Development Process

Project Management Process

Software Configuration Process

Characteristics of Software Process

• Process should be – Predictable– Support Testability and Maintainability – Support Change– Early Error or Defect Removal– Process Improvement and Feedback

SE-381 Software Engineering

BEIT-VLecture no. 6

Software Engineering Processes2 of 3

Software Paradigms

• Classical or Structured Paradigm• Data Structures and Behavior is loosely connected• Data Structures are identified using Entity Relationship and

Attribute Analysis• Behavior of the system is understood by analyzing the data flow

with in the system, among different data structures. Data Flow Diagrams are used to portray this transition of data

• Functions performed by the system are resolved into different strongly-cohesive and loosely-coupled modules

• Modules and their interaction are presented in Structure Charts, and their functionality is written in un-ambiguous ‘structured English’

• The system is considered as a whole – one lump.

• Object Oriented Paradigm• Is a new way of thinking about problems using models organized

around real-world concepts• Fundamental construct is Object, which combines Data structure

and behavior in one entity (Encapsulation)• Software is collection of discrete objects• OO approach exploits the four characteristics – Identity,

Classification, Polymorphism and Inheritance• Users functional requirements are represented thru Use Case

Diagrams, Classification of objects represented using Class Diagrams, interaction of different objects and Classes is shown using Sequence Diagrams, all activities are shown using Activity Diagrams, etc.

• There are different methodologies which support OO paradigm for all/some phases of software development

• Object Modeling Technique (OMT) is one such methodology which supports from Requirement phase thru Design and Implementation phases to Maintenance phase of the SDLC

Software Paradigms .

Client, User & Developer

• ClientWho initiates and pays for the product and effort incurred therein, can be a person or an organization

• UserPerson(s) who will be using the product, on Client’s behalf

• DeveloperPerson(s) involved in any of the phases of software development, from Analysis to Implementation and Testing

Personal / Groups Involved in SD• Developers

Software Analysts, Architects, Designers, Programmers or Coders, Testers, Document Writers etc

• Project ManagersLooking after the execution of software project, it includes planning, monitoring and control and termination phases

• Configuration ControllersInvolved in Configuration Control or Sw Configuration Management Process

• SQA Division or SectionSolely responsible for assuring quality of the produced products, directly reporting to CEO. Has qualified members having expertise in all Software development areas

• SQA GroupSoftware Quality Assurance group will be responsible for assuring quality of the product at a particular phase or stage. Depending upon product size, its composition (and size) could vary for each phase, must of at least 4-5 members, representatives from Client, previous stage, current stage and next stage, should be headed by an experienced person from SQA division

• Software Engineering Process Group (SEPG)Involved in managing the managing the Process Management Process activities

Re-Cap• For efficiency and cost effectiveness– Software should be developed using a phased process– Testing and Maintenance being two very costly phases, so to

benefit for maximum saving these two phases should be focused

– Errors introduced in early stages, if not identified and eradicated early then these cost a lot

HenceIntegrated Approach to Software Development should be adopted, according to this at each stage testing should be carried out [Jalote05] calls it ETVX Approach, whereas [Schach96] specifies What needs to be tested at each stage!!!

Desired Process Properties

• Provide high Quality and Productivity (Q&P)– Support testability as testing is the most expensive

task; testing can consume 30 to 50% of total development effort

– Support maintainability as maintenance can be more expensive than development; over the life of the product, up to 80% of total cost

– Remove defects early, as cost of removing defects increases with latency

ETVX Specification

• ETVX approach is to specify at each phase or step– Entry criteria: what conditions must be satisfied for

initiating this phase– Task: what is to be done in this phase– Verification: the checks done on the outputs of this

phase– eXit criteria: when can this phase be considered

done successfully• A phase also produces information for

management

ETVX approach

Testing at Different Phases of Software Development

• Main Testing TypesTesting could be of Two Types; Non-executable and Executable

• PhasesRequirements Phase , Specification Phase, Planning Phase, Design Phase

Implementation Phase, Integration Phase, Maintenance Phase and Retirement Phase

Ref: Stephen R. Schach (2007); Software Engineering, 7th Edition, Tata McGraw-Hill Publishing Company Limited, New Delhi

Requirements Phase

• Input– Clients (and Users) tell what

they want– Client’s description of project– Meetings to understand

‘what they want’– Client believes the Sw will

help him– Find out the ‘constraints’

• Problems– Client don’t know

what he wants– Description is vague,

ambiguous, contradictory or simply impossible to achieve

– Clarify the time and budget constraints

Requirements Phase

• Do– Clarify the constraints, refine

‘What Client wants’ and ‘what is needed’

– Meetings with development team to address constraints

– Analyze the possible problem areas

– Rapid Prototyping helps

– Requirements Document finalized

• Testing– SQA group should

ensure the Clients needs are satisfied

– Confirm the final version of Rapid Prototype is acceptable to Client/User and meets their needs

– Safeguard ‘moving target problem’

Specification Phase

• Input– Requirements Doc

• Goal– Specification Doc

should explicitly describe• Functionality• Constraints and• Input/Output of the

product

• Problems– Specification Doc is the basis

for the Contract, so must be• Precise• Unambiguous• Clear• No Contradictory or multi-

meaning statements– In case of lawsuits it works as

an evidence

Specification Phase

• Do– Consult Client whenever

needed to clarify the requirements

– Write clearly avoiding mentioned problems

– Validate errors in the input data and ensure all cases are covered

– Specification (Software Requirements Specification – SRS) Document finalized

• Testing– SQA group should ensure

Specification Doc is• Complete• Unambiguous• Non-contradictory

– Ascertain that the promised functionality can be delivered and it’s true reflection of clients requirements

• Review of joint team from Client and Developer and SQA group helps

SE-381 Software Engineering

BEIT-VLecture no. 7

Software Engineering Processes3 of 3

Planning Phase• Input

– Specification Doc– Resources Available– Organizational structure– SDLC,CASE Tool, Detailed

Schedule for Budget• Purpose

– Exact Time and Budget Estimates

– Erroneous estimates may lead to loss of contract or financial penalty to Company.

• How to Do:– All Specification

Document functions are addressed and estimated

– Task Assignments to personnel

– Time estimates, Costs incurred, detailed schedules

Planning Phase

• Outputs– Major Components of the

product, • Milestones / Gantt Charts• Time & Cost Budget• Deliverables and their

timelines

– Software Project Management Plan• With who is doing what and

when information

• Testing– Validate that Time

and Budget estimates are correct

– A good way to do it, obtain two alternate plans from different teams and note the differences and reconcile

– Formal Review is another good technique to test

Design PhaseThe Most Important Phase– Specification describes

‘What’ and Design tells ‘How’ the functionality can be provided

– Design is a CREATIVE activity• Input– Specification / SRS

Document• How Done– Determine the Internal

Structure of the product

– Decide for Algorithms and Data Structures

– Determine I/O of the product from SRS Doc

– Analyze Internal Data Flows

– Decompose Product into ‘Modules’

– Specify ‘functionality’ and ‘Interface’ to each module

– Record all design decisions explicitly

Design Phase• Design has 2 or 3 Parts

– Architectural Design • Break Down of System into

Subsystems, Components and modules of the product• Structure Charts to represent

– Detailed Design• Functionality and Interface of

all modules is developed• Algorithms and Data

Structures of each module identified

• Testing– Re-trace – That every

function in Spec (SRS) Doc have a module supporting it and the vice versa

– Test Cases written for all modules be validated with the Spec Doc i.e. they conform to specs.

Implementation Phase• Input

– Detailed Design for all the modules

– Test Cases for the respective modules

• How to Do– Consider language

and platform dependencies here, if any

– Code the modules with sufficient comments

– Provide extra documentation like decision trees/tables, flow-charts etc for maintenance

• Testing– Test all the modules

using already prepared test cases

• Output– Code for Modules

Integration Phase

• Input– Specifications of

Modules, Subsystems, and System; Test Cases, Structure Chart(s), Modules’ Code

• How to Do– Top-Down, Bottom-

up or incremental integration

• Testing– Module, sub-systems and system

all perform according to the specifications,

– Product testing– Acceptance testing at Clients

site, – Shrink-wrapped products –

alpha, beta testing

Test Cases Results with Used/produced I/O, Source Code, Acceptance Test proof

Maintenance Phase • Maintenance starts after

delivery!!

• But – Maintenance must be kept in

focus while Designing/Coding …

– Should be integral part of Software Development process

• Testing– Ensure proper documentation– Careful change insertion and

Regression Testing i.e. after making a change run all test cases to ensure that no further error has been introduced.

Up-to-Date ‘Change Document’, Regression Test results

Retirement Phase• When to Retire?

– Further Maintenance is not Cost-effective

– Write-Only code– The documentation has

rendered Obsolete– Hardware Advancement

• Like a ‘record in sports’ new record improves the old one

• True retirement is Rare in Sw domain, it is always a replacement, with improved version

• Testing / Utility– A complete review of

functionality and operations the Sw performed

– Incorporation of keynote functions into the replacement

References / Reading Assignment

[Jal97/05] Pankaj Jalote (1997,2005); An Integrated Approach to Software Engineering; 2nd /3rd Edition, Narosa Publishing House, New Delhi – Ch 2 Software Processes pp:21-66

[Sch96] Stephen R Schach (1996);Classical and OO Software Engineering; Irwin McGraw Hill, Boston – Ch 3 Software Life-Cycle Models

[Bel05] Douglas Bell (2005); Software Engineering for Students, 4th Edition, Pearson Education, New Delhi – Ch 21 The Waterfall Model and Ch 23 Prototyping

The relevant parts of the above chapters to be read at home.

SE-381Software Engineering

BEIT-VLecture no. 8

Software Process Models1 of 3

Software Process Models– Software Development

• Needs to be performed in a series of well-defined steps, so that the process could be managed to develop fault-free software product in the given budgetary and time constraints

– Software Process Model • is a way or the order in which these steps/stages or phases of

software development are executed,• is a framework for portraying the specific sequence of these

phases

There are a number of Software Process Models

Some Software Process Models– Build-n-Fix Model– Classical Waterfall Model and its variants– Prototyping Models

• Rapid or Throwaway Prototyping Model• Evolutionary Prototyping Model

– Incremental Model– Risk Based Models

• Spiral Model– eXtreme Programming– Synchronise and Stabilize Model– Object Oriented Life Cycle Models

• Fountain Model• Agile Model• Unified Process Model

Build and Fix Model

• Pros– Simplest– Used by students for

classroom assignments– Build-use-modify-use-modify

cycle continues until client is satisfied

• Cons– No specification or design

stages– Works for very small (<300-

400 LOCs) codes– Unreliable product– Very high cost of the

produced product– Maintenance is in fact not

possible without specification and design documents

Build and Fix Model

A Software Development Life Cycle Model must be chosen before the work on the product is initiated

Waterfall Model• Pros

– Oldest, Since 1970s– Found by Winston Royce in

1970– Most Widely used (in

Aerospace Industry, even today)

– Divides complex task into smaller, more manageable tasks and executes them in Linear order

– Each task/stage is well defined has deliverables and well specified inputs and outputs

– Iterations accommodated in Modified version

– ‘Something is better than nothing’ - at least a systematic method then a haphazard approach

– Project Management Possible

Waterfall ModelMany organizations still cling to the waterfall model because, even with its shortfalls, it provides the most fully elaborated management guidelines on how to proceed in a given software situation.

Barry Boehm, April 1998

Although 20 years back problems in WF model approach were highlighted but still 40% of companies using this approach –

IEEE Software 2003 survey [Som04]

Classical Waterfall Model

Stage-wise Inputs / Outputs

Waterfall Model with Inter-stage Feedback

Jal97 – Waterfall Model

Waterfall Model

Waterfall Model .• Problems

– Real-life systems don’t work in a simple sequential mode (so Iterations implemented)

– Problems CROP UP in the later stages effecting earlier stages

– Uncertainty in user specification CANNOT be specified at the outset

– Design errors are numerous and persistent

– Software delayed, user has to wait for long time

– Specifications frozen at early stages, so the product may NOT conform to what user wanted

Waterfall Model ..

Thus limitations of WF model are:– Requirements of a system are frozen before design begins; could

work for automation of a legacy system but not for new systems– Freezing of Requirements may include the choice of HW, so on

completion the new system may be dependent on a obsolete technology, as technology is ever improving

– WF Model stipulates that the requirements are completely specified before the SD can proceed. In reality, for many systems including COTs a part of the system is fully developed and sold to customers, and then functionality is added to the system and it is redeveloped

– Early freezing of specifications and absence of not many iterations, can not guarantee Users Satisfaction

– The ‘Document Driven’ nature of Waterfall Model has its own Pros & Cons

Prototyping Model

• Can be used to clarify Requirements, to design Use Interface, demonstrate feasibility, verify the new technology will work, or to provide a training system• Cannot be used for embedded software, real-time

control software or scientific or Engineering numerical computational software• Tools for developing good quick prototypes are

scarce, some HLLs are providing routine libraries, whereas systems like Smalltalk could not survive or capture markete

Prototyping Model

• Ensures that customer gets what s/he wanted• Customer is provided a working version of software i.e.

prototype at a very early stage• Customer plays with it and suggests needed

amendments and developer incorporates them into the prototype• User/customer needs/requirements are thus refined

and defined, and the software could be developed using these requirements

Prototyping ModelPrototyping Model could be of two types:• Rapid or Throwaway prototype Model• Evolutionary Prototype Model

Rapid or Throwaway Prototyping ModelUses rapid techniques to construct prototypes that are thrown away once users’ requirements have been established

Evolutionary Prototyping ModelEvolves the initial prototype into the final software as the requirements are clarified

Prototyping Model

Pressman (1992) – SEPA3

Prototyping Model• Problems & Real-life

– Prototyping is a historical technique of Engineering Discipline, Chemical Engg, Aerodynamics

– User not aware what he wants

– Developer not sure how good his Algorithms or Code would perform

– Client ignorant of expected output. Changes to come by use of the Sw Product

• Different Types– Paper Prototype– PC Based Screen layouts– Software developed to

initiate User Interaction with the system

• How Done– Client & Developer meet

and sort out Requirements– A quick design– Implementation– User Feedback

accommodation

Prototyping Model .

• Cons• The developed Prototype should not be taken as Product• According to Brooks 1975, it should be a ‘Throwaway Version’ of

the product but is it possible?• Customer Pressure to take Prototype as Product, and Developer

Shortcuts to get the Prototype working• Should be used as a tool for Requirement Phase

• Client be explained at the outset that after getting Prototype accepted the ‘Product’ will be re-engineered.

Rapid Prototyping Model

Jal97 – Prototyping Model

[Bel05] Throwaway Prototype Model

Rapid Prototyping Model• Pros

– A new model, using the developed Prototype as a Front-end to your SD process, to gather – User

Requirements,– Clients’

experience with the Sw (Prototype)

– Insight to the Algorithms used and how efficient these are

– A tool/guide for all who are involved in SD of the product to improve their area

• Prototype used as– A tool for

Requirements phase

• Rest Follow the remaining phases linearly

• Iteration introduced by– Maintenance phase, for

– Corrective– Adaptive and– Perfective changes

[Bel05] Evolutionary Prototype Model

Evolutionary Versus Rapid Prototypes

– Rapid Prototypes start from incomplete specifications, go through a ‘quick’ design and development and these are improved on users’ or clients’ response. The final output is the clarified Requirements. These are used to develop the system

– Evolutionary Prototypes start from initial specifications, designed thoroughly and incorporate the users’/clients’ response. The evolved system turns out to be the final system

Prototyping Model – An Example

Problem Statement

Write a software program that can check the general knowledge of a user, specifically his/her knowledge about geography and history of Pakistan and its neighbors.

This is to be used by general public, so its implementation in national language will be preferred.

References

[Bel05] Douglas Bell (2005); Software Engineering for Students, 4th Edition, Pearson Education, New Delhi – Ch 21 The Waterfall Model and Ch 23 Prototyping

[Jal97] Pankaj Jalote (1997); An Integrated Approach to Software Engineering; 2nd Edition, Narosa Publishing House, New Delhi – Ch 2 Software Processes

[Sch96] Stephen R Schach (1996);Classical and OO Software Engineering; Irwin McGraw Hill, Boston – Ch 3 Software Life-Cycle Models

The relevant parts of the above chapters to be read at home.