Chapter Note

Chapter1Intro.pdf

Home >Computer Science homework help >Chapter Note

Chapter 1. Introduction

1.0 Basic Concepts (from Book)

1.1 History of Computing/SE 1.2 Maintenance Problem 1.3 Types of Maintenance 1.4 Performing the Maintenance 1.5 Concepts that helps Maintenance

 Software maintenance is a discipline with changes related to a Software System after delivery has been made

Changes are typically needed - to enhance the functionality and/or

to improve the performance (perfective),

- to correct errors (corrective)

- to prevent future troubles (preventive)

- to move to a different platform (adaptive)

It is a challenging task to manage and control these changes

It is estimated that these changes can take 40 – 70% of the entire SLC

1.0 Basic Concepts

 Motivation for Maintenance

- To provide continuity of service: Maintenance activities are aimed at keeping a system operational include bog-fixing, recovering from failure and accommodating changes in the operating system and hardware

- To support the mandatory upgrades: e.g.,, new tax laws, competitive edges

- To support user requests for improvements.

- To facilitate future maintenance work

Maintenance Engineer needs a far wider range of skills than just programming.

Amongst other things, the engineer needs comprehension skills and wide ranging analytical power.

 Definitions

Evolution: process of continuous change from lower, simpler or worse

to higher, more complex and better state

Maintenance: the act of keeping an entity in an existing state of repair to

efficiency, or validity; to preserve from failure and decline.

Maintainability: the ease with which the maintenance can be carried out

Software: the programs, documentation and operating procedures by which computers can be made useful

Software Maintenance: modification of software product after delivery, to correct faults, to improve performance or other attributes, or to adapt the product to a modified environment

1.1 History of Computing/SE

A. Early years of computing (1940 – 1960) Electronic Numeric Integrator and Computer (ENIAC) 

Eckert & Mauchly

Some numbers for ENIAC: - 18K Vacuum Tubes - 30 tons - 1500 SQ feet - 150 KW consumed -yet, Performed basic functions, such as, add,

subtract, divide, multiply etc - 5000 adds or 1000 subtractions per second

 1952 First compiler – A0

by Grace Hopper at UNIVAC for a simple Natural Language

 1958 ALGOL 58 Compiler and CLIP

(the First compiler / compiler)

1957 –1961 SAGE Sponsored by DOD. Semi Automated Ground Environment Detect ICBM from Russia

Characteristics: ~ $250m ~ 1000 people employed ~ 1m assembly instructions

Problems:

• Flexibility => requirement changes

• People  skills vary => “off from the

street”  Organizational (structure).

• Coding does not begin until SPEC. finished

• Integration of many Codes/modules/groups

Solution / Suggestions:  Early spec is a must  Early system integration plan ->

precise interface among users  Early Test Planning  Lean staffing in the beginning.  Have project plan and reviews.

B. Middle years (1960 – mid 1980 ties)

Wave of bigger projects (>Million lines).

 the manned space program (1967)

Apollo project by NASA (IBM)

Characteristics:

~300 – 600 people employed

~ more than 1 billion $

~ more than 1 mil. Fortran/Assembly code.

SABRE by United / American Airlines

OS360 by IBM (F.P. Brooks) Characteristics:

• Over 200 M $

• More than 1M instructions (400 Modules)

• Did not stabilize until 16 releases (up to 40% rewrites)

“Mythical Man-Month” by F.P. Brooks, the manager of the OS 360

“Brook’s law”

 Problem •How to specify a big system •How to produce quality software •How to produce flexible software (different platforms) •How to educate of people •=> 1st conference in Garmisch (sponsored by NATO) 50 people from industry, Academia, Government => “Software Crisis”

 Solutions/Suggestions:

• Use of HLL (not Machine or Assembly)

• Use Multi-Programming (Time Sharing Operation – TSO)

• Need to “engineer software “

=> structured techniques (1970 - )

• Use Modularity and Structured Programming (Dijkstra)

• In this sense, SE is about 45 years old.

 Then, What is SE?

• Definition of SE: IEEE: SE is application of systematic and disciplined, quantifiable approach to the development, operation and maintenance of software. i.e. Application of engineering of software and the study of approaches in it.

Schach: A discipline whose aim is the production of fault-free software that satisfies user’s needs and is delivered on time and within budget. (PQCT = Productivity, Quality, Cost, Time)

 Foundation of SE The process, i.e., the way we build the software which includes life-cycle/process models (SLC), methods, tools & management.

• SLC/process model provides how we view the software development, operation and maintenance (SLC steps)

• Methods provide the technical How-To for a SLC model

• Tools provide support for realization of methods in a semi- or full- Automated manner

 Software Life cycle (SLC) steps

 Requirement Analysis  Specification  Preliminary/Architectural Design  Detailed Design  Implementation  Testing (Validation)  correction proof  Operation  Maintenance  Retire (Kill it)

 Why is it important to go thru steps?

 Management Issues

• Hiring / firing programmer • Interface of the people • Education of the people • Predicting cost (CoCoMo,

CoCoMo II) by Boehm • Predicting time • Technology Transfer • Process Improvement

 In short: SE Scope Includes • Technology life cycle models

methods

Tools

• Management organizational problems

projecting cost / time

Process Improvement

 The Idea of SE is:

Changing Software Construction from

“Magic”(only few people can do this – Magician) To

“Art” (some people can do this – artists)

To “A Science” (Many people can do this – Scientists)

C. Late Years (late 1980 - ) Problem (Fig.1 )?

Problem

Conjecture: The cost of HW decreases by 50% every 12-18 months. e.g., IBM PC 1980ties ($ 3k, 164K Floppy, 64K memory, NO HDD)

 Why? Described in F.P. Brooks Paper

Computer Magazine 1987 24

Inherent Problems of Software •Complexity •Conformity •Changeability •Invisibility

vs.

Accidental Problem that can be solved suing new technology, TSO, HLL, Software Development Environment, GUI, C++ etc.

Possible Silver Bullets?

NO: Correctness Proof, ADA, AI, Expert Systems, Automatic Programming

YES: BUY, Rapid Prototyping, Education of good Engineers, Incremental Development

OO Technology: “Silver Bullet” ?  OOA, OOD, OOI. (1990 ~ )

Booch, Rambough, Jacobson.

• Development method using OO (UML)

• UML is a notation(including graphical) for software development and product. Supported by Rational Rose (1996) and to be OMG standard (1998)

1.2 Problem with Maintenance (Fig. 2)

M. is very expensive

Cost compared with Iceberg (which shows 10 % of the Ice) (Fig. 3)

Wrong Estimation of Time and Cost (Fig. 4)

Fig. 5

 What is maintenance?

- Maintenance refers to changes that are made after

the software has been delivered to customer.

- Maintainability: the ease with which the maintenance can be carried out

- Evolution: process of continuous change from lower, simpler or worse to higher, more complex and better state

 Motivation for Maintenance To provide continuity of service: Maintenance activities are aimed at keeping a system operational include bog-fixing, recovering from failure and accommodating changes in the operating system and hardware • To support the mandatory upgrades: e.g.,, new tax laws,

competitive edges • To support user requests for improvements. • To facilitate future maintenance work

 Maintenance Engineer needs a far wider range of skills than just programming. Amongst other things, the engineer needs comprehension skills and wide ranging analytical power.

 Why is it so expensive and time consuming?

Some reasons:

• No SE technology has been used

• No/little documentation (difficult to understand)

• Not Assessing the impact of change

• Little M. is thought when developing

 Some Possible Solutions:

• Build in the maintainability when constructed

- Use SE technology to develop  more docs

- Think about maintenance when developing

Ex: put all modules that may change under one

Subsystem

• Use tools for M (SCM, RE, Debugger, RT )

• More Basic Research about M  Not many books

1.3 Types of Maintenance?

 Perfective (50 - 55%) is an activity of adding new capabilities and also making some general enhancements. E.g., • Adding/Changing requirements • Adding on-line help features • Enhancing the performance • Improve the terminal dialog to make it user

friendly • Improve the GUI etc

 Adaptive (20-25%) is an activity that modifies software to properly interface with changing processing environment.

E.g., • Implementation of new DB • Work with new OS • Work on new HW (CPU, IO device…) • Work on w new PL

 Corrective (20%) is an activity that includes the diagnosis and correction of defects of an existing system

E.g., • Program failures/aborts (execution error) • Produces results that do not match with RA • REQ/SPC do not match with the system (Documentation

error) • Misleading User manual • Major sources of defects ( logic (25%), interface(15%), I/O(15%), Computational (15%), data manipulation (15%), DB(10%), others (5%))

 Preventive (5%) is an activity to improve the future maintenance or reliability, or to provide better base for future enhancement.

E.G., • Upgrade the documentation • Y2K • Restructuring poorly designed code or otherwise Restructuring is transformation from one representation form to another at the same relative abstraction level while preserving the system’s external behavior (functionality and semantics)

1.4 Performing the Maintenance

A. Flow of Event based on the type

Fig. 6

1.5 Concepts to help maintenance

A. Software Configuration Management (SCM) Involves the development and application of procedures and standards for managing evolving systems products

We need SCM to

 Control the change  Access the impact analysis (side effects)  Manage versions and Revisions  Assure the quality of changes 41

SCM activities are:

 identify the change (Identification)

 control the change (Version and change control)

 ensure the changes are properly implemented (Auditing)

 report the change (Reporting

 Change Control

Fig. 7

B. Reverse Engineering (RE)

is a technique to abstract higher level of abstractions

(such as design, specification or Requirements) from

source code.

 Goals and benefits of RE

The goal of RE is to facilitate change by allowing a

software system to be understood in term of what it

does, how is works and its architectural representation

(requirements, specification and design)

END