Maintenance 1
Maintenance 1
Maintenance 1
MAINTENANCE
Maintain Analyze requirements Integrate & test system Implement Test units
Design
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Development
De
Understand how
Maintenance
1. Introduction
2. Ensure that the request has been approved 3. Understand the problem thoroughly
reproduce the problem
otherwise get clarification
4. Classify the MR as repair or enhancement 5. Decide whether the implementation requires a redesign at a higher level
if so, consider batching with other MRs
Service a Maintenance Request 2 7. Plan transition from current design 8. Assess changes impact throughout the application
small changes can have major impact!
Management
Return on investment hard to define
Process
Extensive coordination required to handle stream of Maintenance Requests
Technical
Covering full impact of changes Testing very expensive compared with the utility of each change
focused tests ideal but expensive regression testing still required
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Activity
Estimate (person-days)
Activity
Estimate (persondays)
1-4
2-4
1-4
2-4
1-4
2-6
TOTAL
14 - 35
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
1b. Ensure supportability 1c. Plan for transition to maintenance 1d. Plan post-delivery logistics
3. Identify maintainers
in-house? contracted?
5. Estimate costs
-- table 10.1
6. Perform maintenance
-- section 3
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Corrective
Fixing
defect identification and removal
Adaptive
changes resulting from operating system, hardware or DBMS changes
Perfective
Enhancing
changes resulting from user requests
Preventative
changes made to the software to make it more maintainable
Maintenance Request 78
The computations that ensue when the player changes the value of a quality, are supposed to keep the total invariant, but they do not. For example, if the qualities are strength = 10, patience = 0.8 and endurance = 0.8 (sum = 11.6), and the player adjusts strength to 11, then the result is strength = 11, patience = 0 and endurance = 0, which do not sum to 11.6.
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Maintenance Request 162 Modify Encounter so that the game begins with areas and connections in a coordinated style. When the player achieves level 2 status, all areas and connections are displayed in an enhanced coordinated style, which is special to level 2 etc. The art department will provide the required images.
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
3. Maintenance techniques
Impact of MR #162
Requirements Architecture
Impact of MR #162
Requirements Add: change appearance when player achieves new levels
Architecture
Detailed design
Accommodate ability to change global appearance: use Abstract Factory design pattern Add interface methods for Layout package
Add classes and methods as per detailed design Modify gameplay control code
Interface specs
Function code Module (e.g., package) code
System code
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Added 7/98
Added 1/99
Added 1/98
Added 7/99
Added 7/98
Added 1/99
Added 1/98
Reengineered Expansion
Added 7/99
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Software reengineering
Evaluate results
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
OR
reverse engineer legacy system or develop new architecture possibly replace in phases
2. Incorporate as integral part of new application OR freeze maintenance 3. Encapsulate and use as server
consider using Adapter design pattern
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Legacy Architectures
Incorporation Encapsulation
Legacy Architectures
Incorporation Encapsulation
(fig ed) Legacy Application New system Extensions
uses...
New system
New application
Adapter 3 Adapter 2 Adapter 1
(fig ew)
wrapper
Legacy Application
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
1. Problem identification 1.1 Input 1.2 Process 1.3 Control 1.4 Output 1.5 Quality factors 1.6 Metrics 2. Analysis 2.1 Input 2.2 Process
2.2.1 Feasibility analysis 2.2.2 Detailed analysis 2.3-2.6 Control, Output, Quality factors, Metrics.
1. Problem identification 4. Implementation 1.1 Input 1.2 Process 4.1 Input 1.3 Control 1.4 Output 4.2 Process 1.5 Quality factors 4.2.1 Coding and & testing 4.2.3 Risk analysis & review 1.6 Metrics IEEE 840-1994 4.2.4 Test-readiness review Software 2. Analysis Maintenance 4.3-4.6 Control, Output, 2.1 Input Table of Contents Quality factors, Metrics. 2.2 Process 5. System test 2.2.1 Feasibility analysis 5.1-5.6 Input, Process, Control, 2.2.2 Detailed analysis Output, Quality factors, Metrics. 2.3-2.6 Control, Output, 6. Acceptance test Quality factors, Metrics. 6.1-6.6 Input, Process, Control, 3. Design 3.1-3.6 Input, Process, Control, Output, Quality factors, Metrics. Output, Quality factors, Metrics. 7. Delivery 7.1-7.6 Input, Process, Control,
Output, Quality factors, Metrics.
1. Problem identification
2. Analysis
3. Design
4. Implementation
5. System test
6. Acceptance test
7. Delivery
Five Attributes of Each Maintenance Step (IEEE) Step Attributes a. Input life cycle artifacts for this step b. Process required for this step c. How the process is controlled d. Output life cycle artifacts e. Process quality factors involved f. Metrics for this step
1. Problem identification
2. Analysis
3. Design
4. Implementation
5. System test
6. Acceptance test
7. Delivery
b. Process
c. Control
Validated MR Clarity of the MR Correctness of the MR (e.g., type) Number of omissions in the MR Number of MR submissions to date Number of duplicate MR's Time expected to confirm the problem
f. Selected metrics
b. Process
c. Control
d. Output
f. Selected metrics
b. Process
c. Control
d. Output
f. Selected metrics
Area EncounterEnvironment
EncounterAreaConnection
EncounterEnvironment
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Client 1..n
EncounterEnvironment Area EnvironmentFactory getArea() buildConnection()
Level3Area
Client 1..n
EncounterEnvironment Area EnvironmentFactory getArea() getConnection()
Level1AreaConnection
create
Level2AreaConnection
Level3AreaConnection
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Level1Factory getArea()
Level2Factory getArea()
Level3Factory getArea()
Level1Factory getArea()
Level2Factory getArea()
Level3Factory getArea()
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
a. Input
b. Process
c. Control
d. Output
f. Selected metrics
Customer
nominal path
Help Desk
Proposed M. R.s
Reviewed M. R.s
Maintenance Current Source Engineer & Documentation Maintenance Assistance
Marketing
Proposed M. R.s
Help desk
Approved M. R.s
Maintenance engineer
Rejected MRs
Help desk
Complaints
Marketing
Docu- Patch ment (optional) patch Execute with patch
Create patch
4. Change code and documentation Implement Test changes Remove patch Document patch removal
Release
Update documentation
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Maintenance Patches advantages Keeps customers satisfied in the short run Enables continued operation and testing without repeated prevalence of the defect Avoids masking other defects Enables test of fix disadvantages Duplicates work
patch and final fix both implemented
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Ranked Problems in Maintenance (Deklava) 1. Changing priorities 2. Testing methods 3. Performance measurement 3. Incomplete or nonexistent system documentation 5. Adapting to changing business requirements 6. Backlog size 7. Measurement of contributions 8. Low morale due to lack of recognition or respect 9. Lack of personnel, especially experienced 10. Lack of maintenance methodology, standards, procedures and tools . . . . .
Top priority . . . Examples of Changing Priorities . . . at release : Make this most bug-free game on the market
action: eliminate as many defects as possible
. . . two months after release: Add more features than our leading competitor
action: add enhancements rapidly
6. Qualities in maintenance
Maintenance Metrics
maintenance
Person-months to perform various maintenance tasks
Defect count
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Goal
(1) Fault density (30) Mean time to failure Break / fix ratio
[ Number of defects introduced by maintenance actions ] / [Number of defects repaired ] Average time required to correct a defect, from start of correction work.
Fault closure
Computer utilization
Average time / CPU time per defect.
Effort and time spent, per defect and per severity category o planning o reproducing customer finding o reporting error o repairing o enhancing (13) Number of entries and exits per module (16) Cyclotomic complexity
Accounts Received
Timesheet
Benefits reporter
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
SOURCE CODE
CONTROL STRUCTURE
INFORMATION STRUCTURE
CODE DETAIL
SYSTEM
COMPONENT
SYSTEM
COMPONENT
SYSTEM
COMPONENT
....
SYSTEM
COMPONENT
COMPONENT
SYSTEM
COMPONENT
The maintainability of a product is affected by this property. + means that more of this property usually makes an application more maintainable;
- means that more of the property usually makes an application less maintainable.
From Oman [Om1]
SOURCE CODE
INFORMATION STRUCTURE
SYSTEM
COMPONENT
SYSTEM
COMPONENT
SYSTEM
COMPONENT
+overall program formatting +overall program commenting +module separation naming symbol and case
+data initialized
+intramodule commenting
-I/O complexity
Examples: +modularity + means greater modularity usually makes an application more maintainable; -span of data means that the greater the scope of data structures, the less maintainable.
7. Summary
Software Maintenance = post delivery Impact analysis is key IEEE standard covers process
identification, input, process, control, output, process quality, process metrics order similar to development process