Ingen bildrubrik

1
Software Evolution and Maintenance32Lecture 7
Software ageing Maintainability Preventive
Maintenance Y2K-problem
This lecture is based on Chapters 31-35
Bild 1
2
Software ageing

• Pollution
• Embedded knowledge
• Poor lexicon
• Coupling
• Architectures

Bild 2
3
Pollution

• Duplicate programs
• Obsolete programs
• Sourceless programs
• Useless components
• Dead data
• Dead code

Bild 3
4
Duplicate programs
Software system
Program 1
Program 2
Subroutine
Data
Object code
Name Age address
00011110001010010100100111111010101

• A software system contains at least two versions
  of the same program. These programs
• Call the same subroutines
• use the same files and data
• at least one of them have a corresponding object
  code

Bild 4
5
Obsolete and sourceless programs
Software system
Program 2
Object code
00011110001010010100100111111010101

• Some programs
• only have a source code
• or exist only in their executable forms

5
6
Useless components
Software system
Useless reports
Program 1
Program 2
Data
Name Age address

• Some components
• create useless reports
• create or modify files used to generate useless
  reports

6
7
Dead data and dead code
Program
Program 1
Data
Data
Data
Entry
Name Age address
Data
Name Age address
Name Age address
never used
Write lrejerj afdjasldjf afadslafjsjf
Name Age address
never used
Exit

• Data declarations never used by any components
• Program statements never reached by any program
  control flow

Bild 7
8
Chapins Categorisation

Bild 8
9
Embedded knowledge
System knowledge
Software system
Program 1
Program 2
System knowledge
System knowledge
Data
Object code
Name Age address
00011110001010010100100111111010101
Program 3
System knowledge
System knowledge
System knowledge

• Documentation is missing.
• The knowledge of the application domain is spread
  in the software data and code instead.

Bild 9
10
Poor lexicon

• The names of data declarations and components
• have little lexical meaning
• inconsistent with the meaning of the components
  they identify

10
11
Architectures

• Useless (obsolete) files
• Semantically redundant data
• Computationally redundant data
• Structure data

The systems architecture consists of several
different solutions that can no longer be
distinguished.
11
12
Useless (obsolete) files
Software system
Program 1
Program 2
Create a temporary file
Use the temporary file
Temporary file
Subroutine
Record 1 Record 2 ...

• No program uses them any more.

Bild 12
13
Semantically computationally redundant data
the two data sources can be interpreted in the
same way
Bild 13
14
Structure data
Unnormalised and/or Denormalised data
Person name Street Zip code City
Person name Street Zip code
Normalised data
Zip code City
Bild 14
15
Maintainability Quality

15
16

Although good quality may be difficult to define
and measure, poor quality is glaringly apparent.
Adrian Branstad and Cherniavisky, 1982 in
Validatioin, Verification, And Testing of
Computer Software, ACM Computing Surveys, 14,
no. 2 (June 1982), 1959-92.
Bild 16
17
Software Maintainability Definitions
The ease with which software can be maintained,
enhanced, adapted, or corrected to satisfy
specified requirements (FIPS 1984).
Maintainability is as a set of attributes that
bear on the effort needed to make specified
modifications (ISO/IEC 8402 1986).
Bild 17
18
How do organisations determine maintainability
Product A
Product B
Program X Variable var1 Interger
var2 Char Function erase ..dsfasfjk end ..
Program X Variable var1 Interger
var2 Char Function erase ..dsfasfjk end ..
Unfortunetly, most organizations do not have any
methodology for determining maintainability
today.
Bild 18
19
A decomposition of maintainability(Fenton, page
340)
Factor Criteria Metrics
Closure time Isolate/fix time Fault
rate Statement coverage Branch coverage Test
plan completeness Resource prediction Effort
expenditure Change effort Change size Change rate
Fault counts
Correctability
Degree of testing
Maintainability
Testability
Effort
Expandability
Change counts
Bild 19
20
Software Quality Characteristics Tree (Boehm)
Accountability - ansvarighet
Bild 20
21
Maintainability model 3McCall
OPERABILITY
Criteria
TRAINING
COMMUNICATIVENESS
I/O VOLUME
I/O RATE
ACCESS CONTROL
ACCESS AUDIT
Factor
STORAGE EFFICIENCY
USABILITY
EXECUTION EFFICIENCY
INTEGRITY
Use
TRACEABILITY
EFFICIENCY
COMPLETENESS
Product operation
ACCURACY
CORRECTNESS
ERROR TOLERANCE
RELIABILITY
CONSISTENCY
MAINTAINA- BILITY
SIMPLICITY
Product revision
CONCISENESS
TESTABILITY
INSTRUMENTATION
FLEXIBILITY
EXPANDABILITY
GENERALITY
REUSABILITY
Product transition
SELF-DESCRIPTEVENESS
PORTABILITY
MODULARITY
iNTEROPRABILITY
MACHINE INDEPENDENCE
S/W SYSTEM INDEPENDENCE
COMMS COMMONALITY
Bild 21
DATA COMMONALITY
22
Maintainability model 4
SOURCE CODE
Cody Typography. Naming and Commenting
Control Structure
Information Structure
Component Complexity Use of Structured
Constructs Use of Uncondi- tional
Branching Nesting Span of Control
Structure Cohesion
Component Local Data Types Local Data
Structures Data Coupling Initialisation
Integrity Span of Data
Component Statement Formatting Vertical
Spacing Horisontal spacing Intramodule
Commenting
System Modularity Complexity Consistency Nesti
ng Control Coupling Encapsulation Module
Reuse Control Flow Consistency
System Global Data Types Global Data
Structures System Coupling Data Flow
Consistency Nesting I/O Complexity I/O
Integrity
System Overall Program Formatting Overall
Program Commenting Module Separation Naming
Symbols and Case
Bild 22
23
Refactoring

• Refactoring is a disciplined technique for
  restructuring an existing body of code.
• One alters its internal structure without
  changing its external behavior.
• It consists of a series of small transformations
  without changing the behavior.
• It improves code readability or simplifies its
  structure.
• Each transformation is called a 'refactoring.
• It does little, but a sequence of transformations
  can produce a significant restructuring.
• Since each refactoring is small, it's less likely
  to go wrong.
• Many refactorings can be automated.

23
24
Refactoring, cont.

• In agile methods, refactoring is an integral part
  of the development cycle.
• Developers alternate between adding new tests
  and functionality and refactoring the code.
• Refactoring neither fixes bugs nor adds new
  functionality.
• When refactoring, one may use a known catalogue
  of common useful refactoring methods

24
25
Goals with refactoring

• To groom code
• To improve code readability
• To simplify code structure
• To avoid needless clutter
• To remove dead code
• To make future maintenance easier.
• When adding new behavior, a developer refactors
  code first to make it easy, and then adds the new
  behavior.

25
26
The meaning of refactoring

• The term refactoring means breaking down
  something into smaller, more easily maintained
  functions.
• It originated in computer programming, but it is
  also applied when modifying any text.
• In the context of text, refactoring refers to the
  process of rewriting and reorganizing text to
  shorten it while preserving content.
• Text refactoring can include
• removing superfluous content
• summarizing long passages,
• and any other means that alter the text.

26
27
Collapse Hierarchy Refactoring

• A superclass and subclass are not very different.
• Merge them together.

27
28
Conditional Expression
if (isSpecialDeal()) total price 0.95
else total price 0.98 send() send()
if (isSpecialDeal()) total price 0.95
send() else total price 0.98
send()

• The same fragment of code is in all branches of a
  conditional expression.
• Move it outside of the expression.

28
29
Refactoring in Extreme Programming
29
30
Refactoring, cont.

• Refactoring combined with patterns
• Database refactoring

30
31
Maintainability - an attribute of
perfective or preventive
maintenance, or maybe both?

• Maintainability is an attribute of perfective
  maintenance (IEEE)
• Maintainability is an attribute of preventive
  maintenance (the majority of the software
  community)

IEEE definition
Perfective maintenance - software maintenance
performed to improve the performance,
maintainability, or other attributes of a
computer program.
31
32
How come that maintainability is an attribute of
both perfective and preventive maintenance?
Bases of Software Maintenance (Lientz and
Swanson) A. Corrective performed in response to
failures. 1. Processing failure 2.
Performance failure 3. Implementation
failure B. Adaptive performed in response to
changes in data and processing
environments. 1. Change in data
environment 2. Change in processing
environment C. Perfective performed to
eliminate processing inefficiencies,
enhance performance, or improve maintainability.
1. Processing inefficiency 2.
Performance enhancement 3. Maintainability
Bild 32
33
Defining maintainability is very difficult

• There is no universally accepted detailed
  definition of maintainability.
• There is no universally accepted detailed model
  of maintainability.
• We have universal process certification.
• We do not have any universal product
  certification.
• We believe that better processes will lead to
  better products.

Bild 33
34
Problems within research

• We cannot create development, evolution and
  maintenance models/methods providing guidelines
  for building in and preserving maintainability.
• We cannot create models/methods for evaluating,
  assessing and measuring maintainability.
• We cannot understand the relationship between
  the product and the process.
• We cannot not restructure products to a common
  maintainaiblity level.

Bild 34
35
Problems within industry

• Difficulties to evolve and maintain software
  products
• Building and maintaining body of product
  knowledge
• Making maintainability comparisons across
  products and organisations.
• Difficulties to introduce new paradigms
• Difficulties in reusing software
• Choice of a common quality standard
• Difficulties in creating own maintainability
  models
• Problems to calculate resources.

Bild 35
36
Ingredients in a maintainability model

• Product part
• Process part

37
Bild 37
38
Impact

• Industry
• Academia
• Standards

Bild 38
39
Impact within industry

• Individual engineer
• Software organisations
• Support Line 1 and 2
• Collaborating organisations
• Open-source development
• Customer

Bild 39
40
Impact within research

• Individual researchers
• Research groups
• Global research

Bild 40
41
Maintainability Model

• Master thesis Choose part of the overall
  maintainability model and create a model of it.

41
42
Preventive maintenance
Bild 42
43
Constructing EM3
Preventive Maintenance Maturity Model (PM3)
Maintenance Maturity Model
Corrective Maintenance Maturity Model
Preventive Maintenance Maturity Model
Adaptive Maintenance Maturity Model
Perfective Maintenance Maturity Model
Other Non-Corrective Maintenance
Bild 43
Bild 43
44
Is it possible to create a process model for
preventive software maintenance?

Preventive maintenance Maintenance performed for
the purpose of preventing problems before they
occur.
Bild 44
45
Panel Debate on IEEE International Conference on
Software MaintenanceSilicon Valley, 2000

• Panel leader Mira Kajko-Mattson (Stockholm
  University)
• Panelists
• Prof. Burton Swanson (UCLA, USA).
• Prof. Ned Chapin (Journal of Software Maintenance
  and Evolution, USA).
• Prof. Ivica Crnkovic (ABB University of
  Mälardalen, Sweden).
• Dr. Shawn Bohner (Meta Group, USA).
• Mr. Jan-Ola Kruger (SAAB Gripen, Sweden).
• Mr. Risto Vehviläinen (DPM Consulting Oy,
  Finland).

Bild 45
46
Preventive Maintenance combats two types of
ageing

• Software product ageing
• degradation in quality in software code and
  documentation by frequent maintenance
• Software process execution ageing
• degradation in performance or transient failures
  in continuously running software systems

Bild 46
47
Opinions about preventive maintenanceA
prevention of obsolence (Swanson)

• Software wear-out through continuous change
  (deteriorated maintainability)
• modernisation of software
• methods for measuring the obsolescence
• modernisation methods for renovating the software
  systems such as reengineering methods.
• Obsolescence with respect to its environment
  (adaptive maintenance)

Bild 47
48
Opinions about preventive maintenance

• Prevention of unnecessary change
• Risk management
• Scheduled maintenance
• Reengineering should run concurrently with the
  maintenance process
• Determinant - the maintainability level, not the
  modification rate.

Release 1
Release 2
Release 3
Release N
Opportunity to introduce change Opportunity to
conduct preventive maintenance
Bild 48
49
Opinions about preventive maintenance

• Programming guidelines
• Writing reusable components
• Announcement of new releases

Version 1
Changing software prior to customer complaints
Revision 1
Revision 2
Revision 3
Resolved problems in Revisions 1-3
Requirement Specification
Version 2
Bild 49
50
Opinions about preventive maintenance

• Maintaining customer (user) knowledge
• 20-25 of problem reports are the result of the
  customers lack of product knowledge (On, Line)
• Discount to the customers if they pass a test
  showing that they possess the product knowledge
  (Ericsson)
• Rigorous software development (evolution - SAAB
  Gripen)

Bild 50
51
Software process execution

• The performance characteristics of a software
  system get degraded over time through continuous
  running
• The effects become manifest in
• reduced service performance and/or failures
  (system crashes or hangs), data inconsistency,
  memory leakage, unreleased file-locks, data
  corruption, storage space fragmentation and
  accumulation of round-off errors.
• Software rejuvenation a preventive maintenance
  measure.
• Periodically stop software and restart it

Bild 51
52
Hardware maintenance

• The hardware maintenance phase far outweighs the
  hardware development phase in terms of time and
  cost
• The goal is to keep installations in normal
  operating conditions, avoid the deterioration of
  its components, and prevent them from outage
  and/or failures
• Hardware components wear out as they get older
• Their time to failure is age- and/or
  usage-related
• Substantial ripple-effect
• Hardware components may be attended to in two
  ways either by being repaired or replaced.

Bild 52
Bild 52
53
Hardware preventive maintenance

• Hardware Corrective Maintenance
• Other terms breakdown or run-to-failure
  maintenance
• Restores a system to a state of functioning
• Best suited for non-critical systems where the
  capital costs are small, the consequences of
  failures are slight, there are no safety risks
• Planned Preventive Maintenance
• Other term hardware preventive maintenance.
• Scheduled maintenance performed at predefined
  ages of the system
• replacement invoked by MTBF, number of failures
  and the hard life of the hardware component.
• Suited for hardware having a clear wear-out
  characteristics.

Bild 53
54
Hardware preventive maintenance

• Hardware On-condition Maintenance
• Other term Condition based maintenance
• Triggered by some predefined values indicating
  the deteriorated health of a hardware system
• Continuous monitoring of the state of the
  hardware devices to trigger maintenance actions
• Maintenance plan with predetermined event types
  and their values revealing the deteriorated state
  of the hardware component
• Opportunistic Hardware Maintenance
• spontaneous preventive actions during corrective,
  planned or on-condition maintenance
• Hardware Evolutionary Maintenance
• The ideal situation is to replace components just
  before they are about to fail.
• Tends towards prolonging the hard life without
  increasing the risk of failure
• Maintenance schedule is continuously adjusted
  after every service on the basis of the condition
  of the hardware component at the moment of the
  maintenance service

Bild 54
55
Taxonomyof preventive measures

• Master thesis Create a taxonomy of preventive
  measures.

Bild 55
56
Preventive maintenance process
- Identify candidates - Attend to the identified
quality problems
- Identify candidates - Attend to the identified
quality problems
- Identify candidates - Attend to the identified
quality problems
Release XXX
Release XXX1
Release XXX
Bild 56
57
Software re-engineering
Re-engineering improves the system structure,
creates new system documentation and makes it
easier to understand

• Software re-engineering is concerned with
  re-implementing systems to make them more
  maintainable.
• Advantages over more radical approaches to system
  evolution
• Reduced risk
• Reduced cost

58
Forward and re-engineering
The critical distinction between re-engineering
and new software development is the starting
point for the development. Rather than start with
a written specification, the old system acts as a
specification for the new system.
59
The re-engineering process
Modularised
Pr
og
ram
Orig
inal data
Orig
inal
prog
ram
documentation
prog
ram
Reverse
eng
ineering
Data
Prog
ram
Source code
re-eng
ineering
modularisation
translation
Prog
ram
structure
improvement
Structured
Re-eng
ineered
prog
ram
data
Program re-engineering may not necessarily
require all of these steps
60
Re-engineering approaches
61
Legacy systemsGhezzi Fundamentals of Software
Engineering, page 24.

• The term legacy software refers to software that
  already exists in an organisation and usually
  embodies much of the organisations processes and
  knowledge. Therefore, such software holds
  considerable value for the organisation,
  represents past investments, and may not be
  replaced easily. On the other hand, because of
  its age, it is usually written in older languages
  and uses older software engineering technology.
  Legacy software is, therefore, difficult to
  modify and maintain.

Bild 61
62
Legacy systemsPressman Software Engineering,
page 21.

• The term legacy programs is an euhpemism for
  older, often poorly designed and documented
  software that is business critical and must be
  supported over many years.

Euhpemism försönande omskrivning
Bild 62
63
Legacy systemsLawrence Pfleeger Software
Engineering, page 469.

• We speak of having legacy systems, built earlier
  when our needs and environment were different.

Bild 63
64
Legacy systems

• Different system parts have been implemented by
  different teams.
• no consistent programming style across the whole
  system
• Part or all of the system may be implemented
  using an obsolete programming language.
• System documentation is often inadequate and out
  of date, or is simply missing.
• The system structure is corrupted through many
  years of maintenance.
• The system may have been optimised for space
  utilisation or execution speed rather than
  written for understandability.
• The data processed by the system may be
  maintained in different files which have
  incompatible structures.
• There may be data duplication and the data itself
  may be out of date, inaccurate and incomplete.

65
Legacy system evolution

• Organisations that rely on legacy systems must
  choose a strategy for evolving these systems
• Scrap the system completely
• the system does not support business process
• Replace the system with a new system
• i.e., new hardware does not allow to keep the
  system
• Continue maintaining the system
• the system is fairly stable, few changes are made
• Transform the system in some way to improve its
  maintainability
• the system quality is degraded.
• The strategy chosen should depend on the system
  quality and its business value.

These options are not exclusive. Where a system
is composed of several different programs,
different options may be applied to different
parts of that system.
66
Replacing a legacy system is a risky business
strategy for a number of reasons.

• There is rarely a complete specification of the
  legacy system.
• Business processes and the ways in which legacy
  systems operate are often inextricably
  intertwined.
• Important business rules may be embedded in the
  software and may not be documented elsewhere.
• New software development is itself risky so that
  there may be unexpected problems with a new
  system.

67
System quality and business value
High business value
High business value
Low quality
High quality
Continue with evolution and maintenance
Candidate for transformation or replacement
9
1
0
8
6
7
Low business value
Low business value
High quality
Business value
Low quality
2
5
3
4
Candidate for scrapping
1
Candidate for scrapping or continued maintenance
S
ystem quality
68
System quality assessment

• Business process assessment
• How well does the business process support the
  current goals of the business?
• Environment assessment
• How effective is the systems environment and how
  expensive is it to maintain?
• Application assessment
• What is the quality of the application software
  system?

69
RaMoLeS
Bild 69
70
Retirementprocess
70
71
Retirement model

• Master thesis Suggest a complete model of
  retirement using Miras outline.

Urgent!!!!
71
72
Y2K-problem
Y2K problem is about whether computers will be
able to recognise a date. The largest collective
project the computer industry has ever faced.
Regarded as a complicated, expensive and
unromantic problem. It will take and has taken
several years to complete.
Bild 72
73
What is Y2K-problem?
The data field representing the year has space
for only two digits. The date is used to
determine time-dependent information and business
events. It appears in programs, databases,
networks, reports, screens, embedded in software
and hardware, archives and other.
Bild 73
74
Y2K is a must-do project
The year 2000 (Y2K) Century Date Change (CDC)
was described as doomsday. - The two-digit date
affects data manipulation (subtraction, addition,
comparison). Companies claimed that they could
not afford to correct every program with a date
problem. - It was a pay now or pay later
situation. - You could not afford to ignore it.
Bild 74
75
Date representation formats
Dates are displayed differently across the
globe. Their format MMDDYY, YYMMDD, DDMMYY,
Asian and the Near East formats What is the
correct interpretation of 020304? Feb. 3,
2004, 4th March 2002 or March 2, 2004?
Bild 75
76
Embedded Dates in Software
Embedded dates could appear in formats such
as YYMMXXXX (Invoice ), XXXXYYMM (Policy
), XXYYMMXX (Licence ) YYMMDDHHMMSS.SSXXX
(Transaction Stamping or some event stamping)
Bild 76
77
Embedded Dates in Hardware
Embedded dates appear in chips, elevator
controls motor vehicle electronics videocasette
recorders grocery store scanners domestic devices
with timers A large bank in Canada tested one of
its facilities and found that three out of four
elevators would fail on the big day. Thousands
of remote monitoring sites for railways,
meteorological services, mines, forestry
concerns, electrical installations, and other
purposes would fail if the date was part of their
reporting, sampling, or summarising
functionality.
Bild 77
78
Archiving Historical Data
Most organisations store data for a minimum of
seven years. In reality, some of them store for
15 years. Stored data must be available
for auditing historical-inquiry
purposes emergency backups.
Bild 78
79
How big is the problem?
10 of the contents of most systems is
date-related. Affects data manipulation in terms
of subtractions, additions and comparisons.
This varies according to application type, age
and other factors.
Bild 79
80
How will it affect us?
The year 2000 was described as doomsday or the
big day. An issue of business survival Many
businesses would fail or succeed depending on
their readiness to meet year 2000. Some systems
would stop working (theyd crash). Risk to human
life, organisations survival at stake Other
systems would produce incorrect
information. confusion, irritation. The whole
nation can be affected and its economy.
Bild 80
81
Examples
When determining the age of a person present
year - birth year 00-60 - 60 When determining
interest spanning the years 1999 and 2000
Computers might calculate 99 years of
interest. When determining prisoners release
date The prisoner should be released on 1/10/15.
The program assumed that the date in question was
1915, because the century was not stored. When
assigning 7-year-olds to new primary
schools. Many very old people were assigned to
primary schools as well.
Bild 81
82
Why do we have Y2K-problem?
Old systems were not expected to be functioning
in the year of 2000. Required and still requires
extra storage space. To save key strokes. An
entrenched habit. Forced to adapt to the
environment. Different standards for
representing the date. Ignorance.
Bild 82
83
Problems when attending to the Y2K problem
Today many projects are late. The Y2K-project
must be finished on December 31st. It could
not be postponed.
Bild 83
84
Why is it difficult?
The date field could be anywhere. One must read
through each line of code. Correcting the date
is labour intensive. The difficulty arises
from - programs written in many different
programming languages Many systems written in
very old languages (Egyptian hieroglyphs) containi
ng information stored in many heterogenous
databases - dates embedded in software and
hardware - there were many different ways to
write dates - software engineers were needed to
attend to their ordinary tasks, such as
development and maintenance. - Lack of
pertinent labour Many original programmers have
either retired or were already in heaven. -
Source code was missing sometimes !!!!!!!!!!!
Bild 84
85
Why is it difficult? (cont.)
The data from a Y2K-compliant computer can get
infected by its co-operating non Y2K-compliant
computers. Just because it is so difficult it
is very costly.
Bild 85
86
The cost
The actual cost of conversion Find all hardware,
software and other equipment that might be
affected Decide whether to fix it or replace
it. Test The hidden cost if you are not fully
Y2K-compliant ripple effect of the
changes production delays loss of
profitability bad PR
Bild 86
87
Stages of a Year-2000 Project
Start-up Inventory Analysis Planning Coding and
Conversion Integration and Testing Quality
Assurance, Migration, and Feedback Reports
Bild 87
88
Staffing
Bild 88
89
Time required per phase of a Year-2000 project
Bild 89
90
Tools
In 1995 there were 10 Y2K tool vendors In 1998
there were over 200. Buyers had to choose
between relatively unknown vendors selling new
and unfamiliar tools. The cost of the conversion
could be reduced by 5 to 35 .
Bild 90
91
When is it too late to start working on
Y2K-problem?
It depends on the size of the organisation, its
software systems and its complexity. 1997 was
probably the last year when larger companies
could commence work on their Y2000 - compliance
projects. 30 of the companies will be close to
be fully compliant by the big day. It can take
as long as a year for a large company to
recognise the need for a conversion project.
Bild 91
92
Positive side of Y2K-problem?
It leads or may lead to - take a constructive
look at all aspects of business operations - to
implement up-to-date techniques. - to recognise
old unused and obsolete parts of the system. -
to shake up the hierarchy in some organisations,
to the benefit or detriment of some
individuals involved. - many indirect returns -
consciousness of what is happening within the
organisation. - introduction of new
methodologies and skills
Bild 92
93
Solutions
Decide on the approach - Data expanding any
date-related data field, then modifying all code,
screens, and reports that use the newly
enlarged field. - Logic (window approach)
define logical windows within which the
century must either be 19 or 20.
Bild 93
94
Windowing
Where CC is the century and YY is the year, the
code might look like CC 19 //default YY
input data If YY lt 50 then CC 20 If the code
returns a current age (based on current year
minus birth year) of 09, this could mean the
client is either 9 or 109 years old. If the
life-insurance premium the client has been paying
lately is relatively high, then one can logically
assume that the age is 109. The calculation of
the maturity century of a ten-year term
investment plan can be determined by looking at
the start date. If the start date is 94, the
04 maturation century date must actually be
2004. If the plan commenced in 85, the
maturation century data 95 must be 1995.
You leave the two-digit (stored) years alone and
add code that determines the century on the fly
(while the data is being processed). A base
year, for instance 50 for 1950, is selected.
Then every year between 50 and 99 is treated as
a 20th-century date and any year between 0 and 49
is treated as a 21st-century date.
Bild 94
95
File and db conversion

• Expand space reserved for storying date (in
  files and databases).
• Difficulties
• dates may be embedded in compound fields.
• both code and data will need thorough testing to
  ensure that all dates have been properly
  converted without reducing functionality.
• Storage limitations.
• Databases may have to be duplicated, at least
  temporarily, to facilitate access by both
  converted and unconverted programs.

Bild 95
96
Data vs logic approach
Data approach - It lasts forever (more robust
and durable). - Requires an immense amount of
resources. Logic approach - A very simple
approach - minimises the amount of conversion in
a system by only working with expanded dates
in localised sections of the system.
Bild 96