What is Software Engineering Historical Aspects

Software Engineering CEN 4010

What is Software Engineering

•Historical Aspects•NATO group coined the phrase during a 1968 meeting in Garmisch, Germany ( a very pretty place). •They believed the development of software should be an engineering discipline to solve what has been termed a “software crisis. •The crisis continues.

•Goals of Software Engineering•Software is fault Free (Bugs)•Software is delivered on-time •Software is delivered within budget•Satisfies users needs. •Can be maintained and modified with the same properties.


Different Phases of the Software Life Cycle

•Requirements Phase: Concept is explored and customers requirements are elicited. •Specification (Analysis ) Phase: Requirements are analyzed and a specification document is produced. Customer signs off on specification. •Planning Phase: A plan is drawn up. Cost, Schedule, Resources, Risks, Assumptions, etc. •Design Phase: Requirements are translated one-to-one to a design of how to solve them. •Implementation (Coding) Phase: Do the design.

•Alpha Test: Internal test with real data. •Beta Test: External test with a real customer, usually involves parallel running with old system.

• Maintenance Phase: First version is released and modifications are coming back,•Retirement Phase: System is no longer used or is no longer maintained by a software organization.


Maintenance 67%

Integration 8%Module Coding/Testing 12%

Design6%

Planning1%

Specification 4%

Requirements 2%

Approximate relative costs of the phases of the software life cycle


Approximate relative cost to detect and correct a fault

1 2 3 4 10

52

368

0

100

200

300

400

Req

uir

emen

ts

Sp

ecif

icat

ion

Pla

nn

ing

Des

ign

Imp

lem

enta

tio

n

Inte

gra

tio

n

Mai

nte

nan

te

Cost inThousands


Economic Aspects of Software Engineering

•Does the resulting system, after development perform one or more of the following functions:

•Simplify a process•Make a process more accurate•Decrease the cost of operations•Increase productivity•Increase the quality of the product•Provide a new and useful capability•and Eventually through the features above, recoup the cost of the development of the system.

•Ensure the resulting system does not do the following;

•Increase maintenance and operation costs•Increase work complexity•Create work•Perform a negative aspect of what a system should do.


Specification and Design

•The relative costs of fixing and correcting faults within a system increase at each of the various phases. Why?

•All phases that have been accomplished to date must be re-accomplished for the fault and all modules affecting the fault.

•How do you avoid this:•Detailed requirements analysis•Hire quality and experienced personnel•Detailed and documented design reviews•Automate the process as much as possible•Attention to detail is of the utmost importance.


Team Programming

• A single programmer acting as analyst, coder, configuration manager, tester, documentation specialist, and help desk is the most efficient use of a programmer.

•Almost all commercial products are a result of a team programming effort, however this has it’s own share of problems:

•Doubling the number of personnel does not double the productivity•Each additional person complicates communication requirements•Management needed to control resources does not increase productivity, just merely makes sure it is completed. •Meetings and conferences use time otherwise would have been dedicated to development and testing.


Object Oriented Paradigm

• Consist both of the action and data views•A more realistic abstraction of the “Real World” •What is it?“ Superficially the term object oriented means that we organize software as s collection of discrete objects that incorporate both data structure and behavior”

•Four basic aspects of OOP•Identity•classification•polymorphism•inheritance


IDENTITY OF OOP •The data is quantified into discrete, distinguishable entities called objects. Examples;

•Paragraph in document•A window on a work station, •A white queen on a chess board

•Each object can be uniquely identified•Each object has characteristics•An object can be concrete in the physical world sense or conceptual such as a scheduling routine inside a computer.


CLASSIFICATION OF OOP •Objects with the same data structure (attributes) and behavior (operations) are grouped into a class.

•Paragraphs •Windows on a work station •Pieces on a chess board•Each object is said to be an instance of that class.

•Each object can be uniquely identified•Each object has characteristics•An object can be concrete in the physical world sense or conceptual such as a scheduling routine inside a computer.


POLYMORHPISM OF OOP

•Means the same operation may behave differently on different classes.

•Multiplication is different in basic arithmetic then it is in matrix algebra. •The move operation is different in Windows and Chess. •Adding two records is different then adding two numbers.

•The point is to use the appropriate operation for the data and scenario.


Inheritance OF OOP •Is the sharing of attributes and operations among classes based on a hierarchical relationship.

•A class can be defined broadly and then refined into successively finer subclasses. •Each subclass incorporates, or inherits, all of the properties of the superclass. •Scrolling Window and Fixed Window are all subclasses of Windows and inherit its properties.


StructureParadigm

Object OrientedParadigm

Requirements Phase Requirements Phase

Specification Phase Object-OrientedAnalysis Phase

Planning Phase Planning Phase

Design Phase Object-OrientedDesign Phase

ImplementationPhase

Object-OrientedProgramming Phase

Integration Integration

Maintenance Maintenance

Retirement Retirement


Structured Paradigm

Operations

- Move_Dot_left- Move_Dot_Right- Move_Dot_Up- Move_Dot-Down


Operation

- Move_Dot( direction)

Object Oriented Paradigm

This has a few advantages. If we want to create a new direction such as diagonal directions, we do not have to create a new routine for the programmer but allow a new parameter and just modify the basic moves to the class.


Build 1stVersion

ModifyUntil User is satisfied

Operations Mode

Retirement

Build and FixModel


Rapid Prototype

Verify

Specification

Verify

Planning

Verify

Design

Verify

Implementations

Test

Integration

Test

Operations

Change Requirement

Verify

The basicWaterfall Model


Requirements

Verify

Specification

Verify

Planning

Verify

Design

Verify

Implementations

Test

Integration

Test

Operations

Change Requirement

Verify

Rapid PrototypeModel


Requirements

Verify

Specification

Verify

Planning

Verify

Architectural DesignVerify

Operations

Incremental Model

For each build: Do a detailed design, implementation, integration, and test

Operations Mode

Retirement


Risk AnalysisRapid PrototypeVerify

Risk AnalysisSpecificationVerify

Risk AnalysisPlanningVerify

Risk AnalysisDesignVerify

Risk AnalysisImplementationVerify

Risk AnalysisIntegrationVerify

Operations

Retirement

Risk AnalysisChange Req. Verify


Capability Maturity Model (CMM)

Ref: 1986 by Watts Humphrey of the Software Engineering Institute at Carnegie-Mellon University. The Model incorporates both technical and managerial aspects of software production.

CMM Level 1: Lowest level. There are essentially no sound software engineering practices. Success of projects is entirely dependent upon competent staff. Usual pattern is time and cost overruns. Most all organizations fall into this category.

CMM Level 2: Basic software management practices are in place. Measurements are used to spot problems and avoid crisis. Planning and management are based upon experience with previous products. (Repeatable processes)

CMM Level 3: Software production is fully documented. Management and technical aspects are clearly defined. Training both management and technical staff is of equal importance. CASE tools are used to improve the quality and efficiency. Level 3 is the highest an organization has reached to date.


Capability Maturity Model (CMM)

CMM Level 4: Organizations set quality and productivity goals for each product. The two quantities are continually measured and corrective action taken. A simple example of statistical quality is the number of faults per 1000 lines of code. The goal is to continually reduce this.

CMM Level 5: The highest level means there are controls in place to have continuous process improvement. The knowledge gained from each product is used in all future products. The process thus incorporates a positive feedback loop, resulting in a steady improvement in productivity and quality over time.

Chart from Schach Page 75

CMM Level Months Man Months Faults Faults Cost Found left 1 29.8 593.5 1,348 61 $5,440K 2 18.5 143.0 328 12 $1,311K 3 15.2 79.5 182 7 $ 728K 4 12.5 42.8 97 5 $ 392K 5 9.0 37.0 37 1 $ 146K

What is Software Engineering Historical Aspects

Documents