Need to write about 350-word summary of EACH CHAPTER, so that it contains: (part 1) important concepts of the chapter (part 2) ex

Chapter 2. The Maintenance Framework

2.1 Definitions

2.2 Components of Maintenance Frame Work

(maintenance Factors)

2.3 Relationship between the maintenance factors

1

2.1 Definitions

Framework: a set of ideas, conditions or assumptions that determine how some things are approached, perceived or understood.

Software maintenance framework:

the context and environment in which software maintenance activity is carried out.

i.e., a set of ideas, conditions or assumptions that determine how software maintenance is approached, perceived or understood.

2

 Environment: the totality of conditions and influences which act from outside upon entity

– Operational Environment: all software and hardware that influence the software in any way

– Non-operational (organizational) environment: all non- software/hardware that influence the software

 Maintenance Process: any activity carried out or an action taken, either by machine or maintenance personnel during software maintenance

 Information gap: the discrepancy between the body of knowledge that system users/maintainer possess and the body of knowledge that are needed to have in order to satisfy a request for change (maintenance)

3

2.2 Components of the Software Maintenance Frame Work (SMF)

A software maintenance framework is used to discuss the factors that affect the maintenance activities.

In order to understand the source of software maintenance difficulties, one needs to understand the following factors, and their interactions.

Factor 1. User Requirements: User is any individual who uses the software regardless of their involvement in its development or maintenance.

Who Requests for additional functionality, refine existing functions, better structure, better documentation, more understandable for future maintenance

4

Factor 2. Environment (operational or non-operational)

• Operational environment: hardware and/or software innovation

• Non-operational environment: policy change, Market competition

 Factor 3. Maintenance Process:

The maintenance process itself is the most important part in the software maintenance framework. It covers the following tasks:

5

• Capturing the requirement: this is the process of finding out what changes are required

• Variation in programming practice: means the differences in approaches used for writing and maintaining the software => different approaches used for writing and maintaining programs. Basic guidelines (e.g. meaningful identifiers, no 'GOTO's) avoid this problem.

• Paradigm shift: refers to an alteration in the way we develop and maintain software, i.e., use of techniques and tools if necessary => There are still many systems in use developed in low-level programming languages.

• Error detection and correction: the early an error is detected and corrected, the cost is lower (up to several hundred fold)

6

FrpFrom

7

From Chapter 1

• “Dead” paradigms for “living” systems: refers to difficulties to accommodate the changing needs of the users and their organizations once the system has been delivered to users.

“Fixed Point Theorem” leads to the development of “dead” systems, system that are designed to meet the needs of the users at one time but not “living” system that are designed to “breathe”, i.e., adapt to changes.

=> Develop software changes in mind

8

Factor 4. Software Product software products are seldom static but continuously

subject to change. The aspects of the such challenge

include:

• Maturity and difficulty of the application domain: the mature application domain, the easier to change

• Quality of the documentation: lack of up-to-date documentation is one of the major problem. The better documentation, the easier the change.

• Malleability of the program: “soft” nature of software product makes it more vulnerable to undesirable change (one of the inherent problems of the software – F.P. Brooks)

• Inherent quality: tendency for the system to decay as more changes are undertaken

9

10

Factor 5. Maintenance Personnel • Staff Turnover: Maintainers are NOT original developers

due to turnover

• Domain Expertise: lack of domain expertise can make the changes difficult

• Working Practice: the way the changes are carried out

11

12

2.3. Relationship between the maintenance factors Figure 1

Chapter 3. Fundamentals of Software Change

3.1 Classification/Categorization of Changes

3.2 Relationship between software changes

3.3 Ongoing support

3.4 Eight Lehman’s “Laws”

1

3.1 Classification/Categorization of Change

(Corrective, Adaptive, Perfective and Preventive)

Why is it important to categorize?

 Some changes require a faster response than others

 Understanding the nature of the changes to be implemented allows more effective prioritization of the change request

 Different changes may require different approaches.

=> different resource allocations, different time-line etc.

2

Different Prioritizations

3

Fig. 3.1

4

 Corrective Change Two kinds: Emergency and Scheduled corrective

Fig. 3.2

5Fig. 3.3

 Corrective Change: refers to modification initiated by defects in the software. Examples are: Design Error, Logic error, Coding error as well as the documentation error, spec errors etc.

6

Table 1

7

8

9

 Adaptive Change: is a change driven by the need to accommodate the modifications in the environment (operating and non-operating) of the software system.

10Fig. 3.4

 Perfective Change:

is used to describe changes undertaken to expand the requirements.

Expansion refers to enhancing the existing system functionality or improvement in computational efficiency (fine-tuning).

Typically, the software grows in size with successive enhancements.

11

12

Requirement Management

Fig. 3.5

 Preventive Change:

changes done to address the problem of deteriorating structure. It is typically undertaken to prevent malfunctions or to improve maintainability of the software.

Similar to perfective changes,

 Not all candidates will be selected

 They will be evaluated and put on the queue

13

3.2 Relationship between software changes3.2 Relationship between software changes

14

Adaptive Perfective

Corrective

Preventive

For example: Adaptive maintenance may lead to Corrective and Preventive maintenance

Changes done to software are usually released incrementally, i.e., not all together. Major enhancements are typically planned, announced and released and minor changes are made at that time

Fig. 3.6

3.3 Ongoing support  Ongoing support refers to non-programming related

maintenance work

• Effective communication: Maintenance is customer- intensive activity. Hence, to establish a good customer relations and co-operation through effective communication increase the customer’s satisfaction.

• Training of users (technology transfer): it is important to equip the users with sufficient knowledge and skills to use the changed system.

 Examples of such equipping process are: manual, online help, on-site visits, or user group training.

• Provide business information: Providing users with various types of timely and accurate information to enable them take strategic business decision. For examples, technical spec for the change, cost, release time.

15

3.4 Eight Lehman’s “Laws” (applies mostly to Perfective Maintenance)

16

Describe the principles common to “large”, “live” software systems.

• Def: E-type system: actively used and embedded systems in a real world domain. Once such systems are operational, they are judged by the results (performance) they deliver, satisfaction of the users. (vs. S-type system: Specification based system) (vs. P-type system: Problem based system)

Lehman’s System Types

 S-system: formally defined, derivable from a specification

e.g., Matrix manipulation

 P-system: requirements based on approximate solution to a problem, but real-world remains stable

e.g., Chess program

 E-system: embedded in the real world and changes as the world does

e.g., Software to predict how economy functions (but economy is not completely understood)

17

S-System

 Problem solved is related to the real world

Fig. 3.7

18

P-System

 The solution produces information that is compared with the problem

Fig. 3.8

19

E-System

 It is an integral part of the world it models

 The changeability depends on its real-world context

Fig. 3.9

20

• Law I (1974) Continuing Change: E-type systems must be continually adapted else they become

progressively less satisfactory in use

 Law II (1974) Increasing Complexity: As an E-type system is evolved its complexity increases unless

work is done to maintain or reduce it.

 Law III (1974) Self Regulation: Global E-type system (system developed in wider organizational

context) evolution processes are self-regulating, i.e., Positive and negative feedback controls within wider context ultimately determine the way the system evolves

=> System attributes such as size, time between releases, and the number of reported errors is approximately invariant for each system release.

21

 Law IV (1978) Conservation of Organizational Stability (Invariant work rate):

Unless feedback mechanisms are appropriately adjusted, average effective global activity rate in an evolving E- type system tends to remain constant over product lifetime (Mythical Man-month) regardless of the resources dedicated

22

 Law V (1978) Conservation of Familiarity: In general, the incremental growth and long term growth rate

of E-type systems tend to decline

From Lehman’s paper: “One of the factors that determines the progress of a software development is the familiarity of all involved with its goals.

The more changes & additions [in a] particular release, the more difficult is for all concerned to be aware, to understand and to appreciate what is required of them…

The larger the work package the more challenging mastery of the matter to be acquired.”

23

 Law VI (1991) Continuing Growth: The functional capability of E-type systems must be

continually increased to maintain user satisfaction over the system lifetime

 Law VII (1996) Declining Quality: Unless rigorously adapted to take into account changes

in the operational environment, the quality of E-type systems will appear to be declining

(the system is perceived as older and less useful)

24

 Law VIII (Recognized 1971,formulated 1996) Feedback System:

E-type evolution processes are multi-level, multi-loop, multi-agent feedback systems.

Multi-loop means that it is an iterative process and multi-level refers to the fact that it occurs in more than one aspect of the software and its documentation.

25

Chapter 4. Limitation and Economic Implications to Software Change

1

4.1 Economic Implications of Software Change

4.2 Limitations to Software Change

4.3. Potential Solutions to Maintenance Problem

2

4.1 Economic Implications of Software Change

A large portion of computing resources is spent towards software maintenance.

Studies have shown that the cost ranges between 60 – 75 % of computing resources.

Based on the study by Lientz and Swanson, the allocation for each maintenance type is as follows:

Perfective (50 %),

Adaptive (25 %),

Corrective (20%)

Preventive (5%)

The actual maintenance costs may differ based on applications and settings.

Based on the study by Lientz and Swanson, the allocation for each maintenance type is as follows:

Perfective (50 %),

Adaptive (25 %),

Corrective (20%)

Preventive (5%)

The actual maintenance costs may differ based on applications and settings.

3

4.2 Limitations to Software Change All changes requested/required cannot be

performed due to the following reasons

 Resources limitation: Lack of skilled maintainer, suitable tools and environment, insufficient budget

 Quality of the existing system: Quality becomes so poor that change is virtually impossible and is no longer viable

4.2 Limitations to Software Change All changes requested/required cannot be

performed due to the following reasons

 Resources limitation: Lack of skilled maintainer, suitable tools and environment, insufficient budget

 Quality of the existing system: Quality becomes so poor that change is virtually impossible and is no longer viable

4

 Organizational strategy: enough budget is not allocated based on the object analysis of the problem, rather based on the desire to be a par with other organizations.

 Inertia: the resistance to change by users (adapt to changes)

 Skilled staff: difficulty of attracting and retaining skilled maintenance personnel

5

4.3. Potential Solutions to Maintenance Problem

 a) Budget and Effort Reallocation: Allocate less resource to un-maintainable or difficult to maintainable system.

More resource should be allocated to specification and design of more maintainable system

 b) Complete Replacement of the software: Develop a new system rather than maintaining a legacy system

4.3. Potential Solutions to Maintenance Problem

 a) Budget and Effort Reallocation: Allocate less resource to un-maintainable or difficult to maintainable system.

More resource should be allocated to specification and design of more maintainable system

 b) Complete Replacement of the software: Develop a new system rather than maintaining a legacy system

6

 c) Maintenance of existing software: solutions a) and b) are somewhat unrealistic in many cases.

E.g., Provide more cutting edge technology, use- driven functionalities, tools, methods

=> The tool and techniques are subjects in this course!

7

8

9

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

1

 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

5

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

6

 1952 First compiler – A0

by Grace Hopper at UNIVAC for a simple Natural Language

 1958 ALGOL 58 Compiler and CLIP

(the First compiler / compiler)

7

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

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

8

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

9

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.

10

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.

11

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)

12

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

“Brook’s law”

13

 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”

14

 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.

15

 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)

.

16

 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

17

 Software Life cycle (SLC) steps

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

18

 Why is it important to go thru steps?

19

20

 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

21

 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)

22

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)

23

 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.

25

Possible Silver Bullets?

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

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

26

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)

27

28

1.2 Problem with Maintenance (Fig. 2)

M. is very expensive

29

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

30

Wrong Estimation of Time and Cost (Fig. 4)

31

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

32

 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

34

 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

35

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

36

 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

37

 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%))

38

 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)

39

1.4 Performing the Maintenance

A. Flow of Event based on the type

40

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

42

 Change Control

43

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)

44

END

45