software engineering – i cscs 300 – fall 2009 ms. saira anwar

SOFTWARE ENGINEERING – I

CSCS 300 – Fall 2009

Ms. Saira Anwar

SOFTWARE Definition Computer software is the product that software

engineers design, build and support. Software is

Most widely used in all fields Medical Telecommunication Military Industry etc

When executed provide desired

features, functions and performance

Enable to adequately manipulate information

Describe operation and use of programs

DUAL ROLE OF A SOFTWARE

A product itself Computing Potential Information transformer

Managing, Producing, Acquiring, Modifying, Displaying

Vehicle to deliver a product Control of computer

Operating Systems

Communication of information Networks

Creation of programs Software tools and environments

TYPES OF SOFTWARE

Generic software Stand-alone systems produced by a development

organization and sold on the open market to any customer

for example word processors, spreadsheets and games

Customized software Systems commissioned by a particular customer. for example web sites, air-traffic control

systems and software for managing the finances of large organizations

Some Software Characteristics Software is engineered or developed, not manufactured

in the traditional sense.Software does not wear out in the same sense as hardware.

Some Software Characteristics In theory, software does not wear out at all.

BUT,

Hardware upgrades.Software upgrades.

Some Software CharacteristicsThus, reality is more like this.

Most serious corporations control and constrain changes

Most software is custom built, and customer never really knows what she/he wants.

ENGINEERING

Definition Implementation of a solution to a

practical problem activity which aims at

solving a problem completing a task (definition, design, and specification)

Analysis, design, construction, verification, and management of technical (or social) entities.

11

WHAT IS SOFTWARE ENGINEERING? Engineering approach to develop

software. Building Construction Analogy.

Systematic collection of past experience: techniques, methodologies, guidelines.

SOFTWARE ENGINEERING Definition

Establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines.

WHY SOFTWARE ENGINEERING

Organized, systematic, and controlled software development

Software engineering is concerned with theories, methods and tools for professional software development

Customer wants low cost and short time for software development

14

Why study software engineering?

To acquire skills to develop large programs. Exponential growth in complexity

and difficulty level with size.

15


Ability to solve complex programming problems: How to break large projects into

smaller and manageable parts? Learn techniques of:

specification, design, interface development, testing, project management, etc.

16


To acquire skills to be a better programmer:

Higher Productivity Better Quality Programs

IMPORTANCE OF SOFTWARE ENGINEERING

Software crisis Software quality

18

SOFTWARE CRISIS Software products:

fail to meet user requirements. frequently crash. expensive. difficult to alter, debug, and

enhance. often delivered late. use resources non-optimally.

19

FACTORS CONTRIBUTING TO THE SOFTWARE CRISIS

Larger problems, Lack of adequate training in

software engineering, Increasing skill shortage, Low productivity improvements.

DIFFERENCE

Software Engineering Concerned with the

practicalities of developing and delivering useful software

A field of study deals with practicalities of software development

Computer science Concerned with theory

and fundamentals

A field of study deals with theories and practices of computation, communication, automation, coordination and data manipulation.

DIFFERENCE System engineering

Concerned with all aspects of computer-based systems development, including hardware, software, and process engineering

Software engineering Part of system

engineering Deals with

software only

COMPARING SOFTWARE ENGINEERING AND RELATED FIELDS For further information, check this link

http://en.wikipedia.org/wiki/Comparing_software_engineering_and_related_fields

SOFTWARE MYTHS (MANAGEMENT PERSPECTIVES)

SOFTWARE MYTHS (MANAGEMENT PERSPECTIVES)As long as there are good standards and clear procedures in my company, I shouldn’t be too concerned.

But the proof of the pudding is in the eating;

not in the Recipe !


SOFTWARE MYTHS (MANAGEMENT PERSPECTIVES)As long as my software engineers(!) have access to the fastest and the most sophisticated computer environments and state-of-the-art software tools, I shouldn’t be too concerned.

The environment is only one of the several factors

that determine the quality of the end software product!


SOFTWARE MYTHS (MANAGEMENT PERSPECTIVES)When my schedule slips, what I have to do is to start a fire-fighting operation: add more software specialists, those with higher skills and longer experience - they will bring the schedule back on the rails! (Mongolian Horde Concept)

Unfortunately, software business does not

entertain schedule compaction beyond a limit!

Adding people to a late software projectsMake it later

SOFTWARE MYTHS(CUSTOMER PERSPECTIVES)

SOFTWARE MYTHS(CUSTOMER PERSPECTIVES) A general statement of objectives is

sufficient to get started with the development of software. Missing/vague requirements can easily be incorporated/detailed out as they get concretized.

Application requirements can never be stable; software can be and has to be made flexible enough to allow changes to be incorporated as they happen.

SOFTWARE MYTHS(DEVELOPER PERSPECTIVES)SOFTWARE MYTHS(DEVELOPER PERSPECTIVES)

Once the software is demonstrated, the job is done.

Usually, the problems just begin!

Until the software is coded and is available for testing, there is no way for assessing its quality.

Usually, there are too many tiny bugs inserted at every stage that grow in size and complexity

as they progress thru further stages!

SOFTWARE MYTHS(DEVELOPER PERSPECTIVES)

SOFTWARE MYTHS(DEVELOPER PERSPECTIVES)

The only deliverable for a software development project is the tested code.

The code is only the externally visible component

of the entire software complement!

SOFTWARE MYTHS(DEVELOPER PERSPECTIVES)SOFTWARE MYTHS(DEVELOPER PERSPECTIVES)

SOFTWARE PRODUCTSOFTWARE PRODUCT

is a product designated for delivery to the user

sourcecodes

sourcecodes

objectcodes

objectcodes

plansplans

reportsreports

manualsmanuals

documentsdocuments

test suitestest suitesprototypesprototypes

datadata

test resultstest results

Software Myths Myth: It’s in the software. So, we can easily change it.

Reality: Requirements changes are a major cause of software degradation.

Myth: We can solve schedule problems by adding more programmers.

Reality: Maybe. It increases coordination efforts and may slow things down.

Myth: While we don’t have all requirements in writing yet, we know what we want and can start writing code.

Reality: Incomplete up-front definition is the major cause of software project failures.

Software Myths Myth: Writing code is the major part of creating a

software product.Reality: Coding may be as little as 10% of the effort, and 50 - 70% may occur after delivery.

Software MythsMyth: I can’t tell you how well we are doing until I get parts of it running.

Reality: Formal reviews of various types both can give good information and are critical to success in large projects.

Myth: The only deliverable that matters is working code.

Reality: Documentation, test history, and program configuration are critical parts of the delivery.

Myth: I am a (super) programmer. Let me program it, and I will get it done.

Reality: A sign of immaturity. A formula for failure. Software projects are done by teams, not individuals, and success requires much more than just coding.

BOEHM’S TOP TENINDUSTRIAL SOFTWARE METRICS




Finding and fixing a software problem after delivery of the product is 100 times more expensive than defect removal during requirements and early design phases.

11

EFFORT TO REPAIR SOFTWARE(WHEN DEFECTS ARE DETECTED AT DIFFERENT STAGES)

EFFORT TO REPAIR SOFTWARE(WHEN DEFECTS ARE DETECTED AT DIFFERENT STAGES)

0.15 0.5 12

5

20

0

5

10

15

20

rela

tive

effo

rt to

re

pa

ir

Reqmts Coding Acc. Test

Nominal software development schedules can be compressed up to 25% (by adding people, money, etc.) but no more.

22



Maintenance costs twice what the development costs. 33



Development and maintenance costs are primarily a function of the size. 44



Variations in humans account for the greatest variations in productivity. 55



The ratio of software to hardware costs has gone from 15:85 in 1985 and continues to grow in favor of software as the dominant cost.

66



HARDWARE VS SOFTWARE COSTSHARDWARE VS SOFTWARE COSTS

0

20

40

60

80

100

1960 1970 1980 1990

Hardware

Software

Only about 15% of the development effort is in coding. 77



DISTRIBUTION OF EFFORTACROSS PHASES

DISTRIBUTION OF EFFORTACROSS PHASES

2030

4515

30

40

20

15

545

2510

T raditionalenvironment

Structuredtechniques

CASE environment

Analysis Design Coding Testing

Testing

Coding

Design

Analysis

Applications products cost three times as much per instruction as individual programs; system software products cost nine times as much.

88



Walkthroughs catch 60% of the errors. 99



DISTRIBUTION OF ACTIVITIESIN DEFECT REMOVAL

DISTRIBUTION OF ACTIVITIESIN DEFECT REMOVAL

65

10

10 5 10

walkthru

unit test

evaluation

integration

other

20%20%modules modules

80%80%cost cost

Many software processes obey a Pareto distribution.1010





80%80%errors errors




80%80%cost cost to fix to fix





80%80%exec time exec time




20%20%tools tools

80%80%useuse




54

SYMPTOM OF SOFTWARE CRISIS

10% of client/server apps are abandoned or restarted from scratch

20% of apps are significantly altered to avoid disaster

40% of apps are delivered significantly late

Source: 3 year study of 70 large c/s apps 30 European firms. Source: 3 year study of 70 large c/s apps 30 European firms. Compuware (12/95)Compuware (12/95)

PROGRAMS VERSUS SOFTWARE PRODUCTS

Programs Software Products

Usually small in size Large number of users

Author himself is sole userSingle developer

Team of developersWell-designed interface

Lacks proper user interfaceLacks proper documentation

Well documented & user-manual prepared

Ad hoc development. Systematic development

software engineering – i cscs 300 – fall 2009 ms. saira anwar

Documents