intro pro mngt

8/7/2019 Intro Pro Mngt

1/45

Software Engineering (Classical)-IPrakash Jagdale


2/45

What?

Applying sound engineering principles andmethodologies during software development for

Enterprise Applications and Software Products

The course will focus on upfront activities in thesoftware engineering lifecycle with emphasis onRequirements engineering and ProjectManagement.


3/45

How?

Stress on activity and group discussions and use of supporting tools The software engineering activities will be learnt by discussing their basic

principles as well applying them on a mock project.

Demonstration and use of Tools to capture and manage requirements,project management tools

Industry standard Unified Software Development methodology will beillustrated with course material adopted from IBM Rational Company. Preparation of industry standard artifacts such as Vision document, SRS,

Project Plan, Formal Technical Reviews shall be adopted.

(some) Research papers from reputed Journals and Conferenceshighlighting issues


4/45

Grading???

Evaluation will be in theform of quizzes, tests,

classroom participationand lifecycle project workand submissions.

Evaluation type weightage

Quizzes( 2-4) 10%

Mid Term Test 15%

Use Case model 10%

Vision document 10%

Project Plan 10%

Individual Presentation 15%

Classroom participation 5%

End Term Test 25%


5/45

Books & References

Pankaj Jalote An Integrated Approach to SoftwareEngineering 3rd edition Narosa Publishers

Dean Leffingwell & Don Widrig Managing SoftwareRequirements a Unified Approach Pearson Education

Writing Effective Use Cases by Allistair Cockburn, LPEAddison Wesley

Walker Royce, Software Project Management: A UnifiedFramework, Pearson Education Asia

Fred Brooks, Mythical Man-Month


6/45

Software development is about

People - A wide-range of people, with differentskill-sets

Technologies - Infrastructure upon whichsoftware will be based

Tools - Software development and project

management tools Organizational Patterns - How team members

interact


7/45

Software Goal

Primary goal

Delivering working software which satisfies current

requirements and is flexible for future enhancements

Secondary goal

Documents and other artifacts


8/45

Few things to note

The debris you leave on the road as you walkthrough a process

Reflect a transformation of information from oneform into another

Serve as maps in understanding decision-making

which occurs during artifact development and attimes more important than the artifact itself


9/45

Why Methodology at all?

Introducing and substituting people

Delineating and fixing responsibilities

Impressing and demonstrating visible progress

Methodology itself does not guarantee results


10/45

Software Development

Its a high risk business

Four control variables in Software Development

Cost

Time

Scope

Quality If you fix three variables, fourth gets defined


11/45

Hardware / Programmers costs

Factor 1965 2005

Cost of Computer(256K)

$750000 $1000

Cost of programmer $2500/year $75000/year

Software Projects Late Late

Buggy Buggy

Inflexible Inflexible


12/45

Software Crisis (Late 1980s)

All major projects were late by an average of 30months!

Maintenance consumed over 70% of the budget

Quality

Pathetic!

Difficult to debug high maintenance costs Small changes had bad side effects.


13/45

Russell'sLawsof Software Relativity

Asa software projectapproachesrelease, itsmass increases.

The energy required torelease asoftware projectisinversely

proportionaltothe time before ascheduled release.

Ittakesinfinite energy torelease afinished producton time;therefore, allsoftware projectsare both incomplete and late.

Time isrelative tothe observerofasoftware project. The lastmonth

ofdevelopmentappearstotake ayear.

Ifasoftware projectbecomestoolarge, itwill collapse intoablackhole. Time and money are absorbed butnothing ever comesout.


14/45

Properties of Failing software Redundancy

Duplication and little reuse

Interconnectedness High coupling between so called modules Fragility

Low understandability Obsolete documentation

Human factors Human resource management crisis


15/45

Cost of fixing defects

Average cost of fixing defects based on when they areintroduced when they are detected

Time Introduced Requirements Architecture Construction System Test Post Release

Requirements 1 3 5 to 10 10 10 to 100

Architecture * 1 10 15 25 to 100

Construction * * 1 10 10 to 25


16/45

Typical ApplicationsBusiness System Mission Critical

SystemEmbedded Life-Critical Systems

Internet Site Embedded Software Avionics software

Intranet Site Games Embedded software

InventoryManagement

Internet site Medical devices

Games Packaged software Operating systems

MIS Software tools Packaged software

Payroll Web services


17/45

SE: The Problem Domain

Industrial Strength Software

Software is expensive

Software is late and unreliable

Maintenance & Rework


18/45

Industrial strength software

Student programs for a problem & industrial strengthsoftware are two different things

Key difference is in quality (including usability, reliability,portability, etc.) High quality requires heavy testing, which consumes 30-50% of

total development effort

Requires development to be broken in stages such that bugs can

be detected in each Good UI, backup, fault-tolerance, following of standards etc.

increase the size for the same functionality


19/45

Industrial strength software

If 1/5th productivity, and increase in size by afactor of 2, industrial strength software will take

10 times effort Brooks thumb-rule: Industrial strength software

costs 10 time more than student software

Domain of Software Engg: Industrial strength

software In Software Engg. and in this course, software

means industrial strength software


20/45

Software is Expensive

Let us look at costs involved

Productivity = 500 LOC/PM

Cost to the company = $10K/PM Cost per LOC = $20

i.e, each line of delivered code costs about $20.

A simple application for a business may have 20KLOC to50KLOC Cost = $100K to $1Million

Can easily run on $10K-$20K hardware

So HW costs in an IT solution are small as compared to SW costs.


21/45

Software is Expensive

The HW/SW ratio for a computer system hasshown a reversal from the early years.

In 50s , HW:SW :: 80:20

In 90s , HW:SW :: 20:80

So , SW is very expensive

Importance of optimizing HW is not much

More important to optimize SW


22/45

Late & Unreliable

20-25% of SW projects never complete Because after some time they realize that the final cost

will be much higher Many companies report runaways

budget & cost out of control

consulting companies to help control them

One defence survey found that 70% of theequipment problems are due to SW

Many examples of software failures


23/45

Unreliable

SW failures are different from failures ofmechanical or electrical systems

In software, failures are not due to aging relatedproblems

Failures occur due to bugs or errors that getintroduced during development

i.e. the bug that causes a failure exists from start,only manifests later


24/45

Maintenance & Rework

Once SW delivered, it enters maintenance phase

Why is maintenance needed for SW when it does not wear

with age? Residual errors requiring corrective maintenance

Upgrades and environment changes adaptive maintenance

Over SW life, maintenance can cost more than thedevelopment cost of SW ~60:40

Rework: changes made during the development

Rework cost: ~30 to 40% of development cost


25/45

SE Challenges

SE (IEEE): systematic approach todevelopment, operation, maintenance and

retirement of software Systematic approach: methodologies and

practices that can be used to solve a problemfrom problem domain

repeatable


26/45

Basic Problem


27/45

SE Challenges

The problem of producing software to satisfy userneeds drives the approaches used in SE

Software is Industrial strength SW

But there are other factors that drive the selectionof approaches

These factors include considerations of scale,quality, productivity, consistency, change,


28/45

Scale

SE must deal with problem of scale

methods for solving small problems do not scale up for largeproblems

industrial strength SW problems tend to be large

SE methods must be scalable

Two clear dimensions in this engineering methods

project management

For small, both can be informal or ad-hoc, for large bothhave to be formalized


29/45

Scale


30/45

Scale

An illustration of issue of scale is counting thenumber of people in a room vs taking a census

Both are counting problems

Methods used in first not useful for census

For large scale counting problem, must use differenttechniques and models

Management will become critical


31/45

Scale: Examples

GCC 980KLOC C, C++, yacc

Perl 320 KLOC C, perl, sh

Apache 100 KLOC C, sh

Linux 30,000 KLOC C, C++

Windows XP 40,000 KLOC C, C++


32/45

Productivity

An engineering project driven by cost & schedule

In SW cost is mainly manpower cost, measured in

person-months

Schedule is in months/weeks very important inbusiness context

Productivity capture both of these If P is higher, cost is lower

If P is higher, time taken can be lesser

Approaches used by SE must deliver high P


33/45

Quality

Quality is the other major driving factor

Developing high Q software is a basic goal

Quality of software is harder to define

Approaches used should produce a high Qsoftware


34/45

Quality ISO standard


35/45

Quality ISO std ISO std has six attributes

Functionality Meet stated & implied needs

Reliability Maintain specified level of performance

Usability Understand, learn, use

Efficiency Judicious use of resources

Maintainability Corrections, improvements, adaptation

Portability Adapt to different environments


36/45

Quality

Multiple dimensions mean that not easy to reduceQ to a single number

Concept of Q is project specific For some reliability is most important

For others usability may be more important

Reliability is generally considered the main Qcriterion


37/45

Quality

Reliability = Probability of failure hard to measure

approximated by no. of defects in software To normalize Quality = Defect density

Quality = No. of defects delivered / Size

Defects delivered - approximated with no. of

defects found in operation Current practices: less than 1 def/KLOC

What is a defect?


38/45

Consistency and repeatability Sometimes a group can deliver quality software Key SE challenge: how to ensure that success can

be repeated SE wants methods that can consistently produce

high Q software with high P A software organization, wants to deliver high Q &

P consistently across projects Frameworks like ISO and CMM focus on this

aspect a lot


39/45

Change

Only constant in business is change!

Software must change to support the changing

business needs

SE practices must accommodate change

Methods that disallow change, even if high Q and P,are of little use


40/45

SE Approach

Consistently develop software with high Q&Punder large scale and changes

Q&P governed by people, processes, andtechnology


41/45

Iron Triangle


42/45

SE Approach

SE focuses mostly on processes for achieving thegoals

Systematic approach is really about processesbeing used

SE separates process for developing softwarefrom the developed product (i.e software)

Premise: Process largely determines Q&P, hencesuitable processes will lead to high Q&P


43/45

SE Approach

Design of proper processes and their control is akey challenge SE faces

This focus on process makes SE different frommany CS courses

Software process is the equivalent ofmanufacturing process


44/45

SE Approach

The development process used in SE is typicallyphased

Phases separate concerns with each phasefocusing on some aspect

Requirements, architecture, design, coding, testing arekey phases

This phased process has to be properly managedto achieve the objectives

Metrics and measurement important for process &product


45/45

Summary

SE aims to provide methods for systematicallydeveloping industrial strength software

Main goal is to high Q&P with consistency, underlarge scale and changes

Basic approach of SE is to separate process fromproducts and define metrics for each