410 likes | 515 Views
ECE 453 – CS 447 – SE 465 Software Testing & Quality Assurance Lecture 28 Instructor Paulo Alencar. Overview. Software Maintenance Legacy Software Maintenance Metrics. Legacy Systems. Older software systems that remain vital to an organization
E N D
ECE 453 – CS 447 – SE 465 Software Testing & Quality AssuranceLecture 28InstructorPaulo Alencar
Overview • Software Maintenance • Legacy Software • Maintenance Metrics
Legacy Systems • Older software systems that remain vital to an organization • Software systems that are developed specially for an organization have a long lifetime • Many software systems that are still in use were developed many years ago using technologies that are now obsolete • These systems are still business critical that is, they are essential for the normal functioning of the business • They have been given the name legacy systems
Legacy Systems Replacement • There is a significant business risk in simply scrapping a legacy system and replacing it with a system that has been developed using modern technology • Legacy systems rarely have a complete specification. During their lifetime they have undergone major changes which may not have been documented • Business processes are reliant on the legacy system • The system may embed business rules that are not formally documented elsewhere • New software development is risky and may not be successful
Legacy Systems Change • Systems must change in order to remain useful • However, changing legacy systems is often expensive • Different parts implemented by different teams so no consistent programming style • The system may use an obsolete programming language • The system documentation is often out-of-date • The system structure may be corrupted by many years of maintenance • Techniques to save space or increase speed at the expense of understandability may have been used • File structures used may be incompatible
The Legacy Dilemma • It is expensive and risky to replace the legacy system • It is expensive to maintain the legacy system • Businesses must weigh up the costs and risks and may choose to extend the system lifetime using techniques such as re-engineering.
Legacy System Structures • Legacy systems can be considered to be socio-technical systems and not simply software systems (e.g., involves issues such as communication, user satisfaction, resistance, group interaction, knowledge) • System hardware - may be mainframe hardware • Support software - operating systems and utilities • Application software - several different programs • Application data - data used by these programs that is often critical business information • Business processes - the processes that support a business objective and which rely on the legacy software and hardware • Business policies and rules - constraints on business operations
System Change • In principle, it should be possible to replace a layer in the system leaving the other layers unchanged • In practice, this is usually not possible • Changing one layer introduces new facilities and higher level layers must then also change to make use of these • Changing the software may slow it down so hardware changes are then required • It is often not possible to maintain hardware interfaces because of the wide gap between mainframes and client-server systems
Legacy Data • The system may be file-based with incompatible files. The change required may be to move to a database-management system • In legacy systems that use a DBMS the database management system may be obsolete and incompatible with other DBMSs used by the business
Legacy System Design • Most legacy systems were designed before object-oriented development was used • Rather than being organised as a set of interacting objects, these systems have been designed using a function-oriented design strategy • Several methods and CASE tools are available to support function-oriented design and the approach is still used for many business applications
Evolving Systems • It is usually more expensive to add functionality after a system has been developed rather than design this into the system • Maintenance staff are often inexperienced and unfamiliar with the application domain • Programs may be poorly structured and hard to understand • Changes may introduce new faults as the complexity of the system makes impact assessment difficult • The structure may be degraded due to continual change • There may be no documentation available to describe the program
Maintenance Management • Maintenance has a poor image amongst development staff as it is not seen as challenging and creative • Maintenance costs increase as the software is maintained • The amount of software which has to be maintained increases with time • Inadequate configuration management often means that the different representations of a system are out of step
Change Processes Fault repair process Iterative development process
System Documentation • Requirements document • System architecture description • Program design documentation • Source code listings • Test plans and validation reports • System maintenance guide
Document Production • Structure documents with overviews leading the reader into more detailed technical descriptions • Produce good quality, readable manuals - they may have to last 20 years • Use tool-generated documentation whenever possible
Maintenance Cost Factors • Module independence • It should be possible to change one module without affecting others • Programming language • High-level language programs are easier to maintain • Programming style • Well-structured programs are easier to maintain • Program validation and testing • Well-validated programs tend to require fewer changes due to corrective maintenance
Maintenance Cost Factors • Documentation • Good documentation makes programs easier to understand • Configuration management • Good CM means that links between programs and their documentation are maintained • Application domain • Maintenance is easier in mature and well-understood application domains • Staff stability • Maintenance costs are reduced if the same staff are involved with them for some time
Maintenance Cost Factors • Program age • The older the program, the more expensive it is to maintain (usually) • External environment • If a program is dependent on its external environment, it may have to be changed to reflect environmental changes • Hardware stability • Programs designed for stable hardware will not require to change as the hardware changes
Maintenance Metrics • Measurements of program characteristics which would allow maintainability to be predicted • Essentially technical, how can technical factorsabove be quantified • Any software components whose measurements are out of line with other components may be excessively expensive to maintain. Perhaps perfective maintenance effort should be devoted to these components
Maintenance Metrics • Control complexity Can be measured by examining the conditional statements in the program • Data complexity Complexity of data structuresand component interfaces. • Length of identifier names Longer names imply readability • Program comments Perhaps more commentsmean easier maintenance
Maintenance Metrics • Coupling How much use is made of other components or data structures • Degree of user interaction The more user I/O, the more likely the component is to require change • Speed and space requirements Require tricky programming, harder to maintain
Maintenance Metrics: Coupling • d(i) – number of input parameters • d(o) – number of output parameters • c(i) – number of input control parameters • c(o) – number of output control parameters • g(d) – number of global variables used as data • g(c) – number of global variables used as control • w – number of modules called (fan-out) • r – number of modules calling this (fan-in) m(c) = k / M , where k = 1 (can be adjusted) and • M= d(i)+(k1 * c(i))+d(o)+(k2 * c(o))+g(d)+(k3 * g(c))+w+r • where k1, k2, k3 are constants and may be adjusted • The lower the value, the weaker the coupling
Maintenance Metrics: Maturity Software Maturity Index • M = number of modules in current release • F(c) = number of changed modules in current release • F(a) = number of added modules in current release • F(d) = number of modules removed from previous • SMI = [M-(F(a)+F(c)+F(d)]/M • As SMI approaches 1 product begins to stabilize
Maintenance Metrics: Software Purity Level This metric estimates the relative change in the failure rate from the beginning of a phase (e.g., maintenance) to the time of the fth failure detection: PL = purity level = (Z(t0) – Z(tf)) / Z(t0) where: • t0 = start of the specified phase • tf = length of time in current phase when fth failure detected • f = total number of failures in a given time interval • Z(t) = estimated failure rate at time t
Maintenance Metrics: Cost Basili, Vallet (NASA Goddard Space Flight Center) et al. (1995) developed a predictive cost model for maintenance. By estimating the size of a release, an effort estimate can be determined: Effort in hours = (0.36 * SLOC) + 1040
Maintenance Metrics: Fault Days This metric evaluates the number of days between the time an error is introduced into a system and when the fault is detected and removed: FD = fault days for total system = SUM (FDi) for i=1 to I where • FDi = fault days for ith fault = fout – fin • fin = date error was introduced into the system • fdet = date error was detected • fout = date fault was removed from the system • I = total number of faults found to date
Maintenance Metrics: Fault Days Other similar metrics can be calculated: FDfind = days to find an error = SUM (FDfindi) for i=1 to I where • FDfindi = days to find ith error = fdeti – fini FDfix = days to fix faults = SUM (FDfixi) for i=1 to I where • FDfixi = days to fix ith error = fouti – fdeti
Maintenance Metrics: Fault Days The following averages can be calculated: • average days to find an error = FDfindi / I • average days to fix an error = FDfixi / I • average error duration = (FDfindi + FDfixi) / I
Maintenance Metrics: Staff-Hours The staff-hours per major defect detected metric is defined as follows: SH = staff-hours per major defect detected = (SUM (T1 + T2)i (i= 1 to I)) / SUM(Si) (i=1 to I) where: • T1 = preparation time spent by the team for the i-th inspection • T2 = time spent by the team to conduct the ith inspection • Si = number of nontrivial defects detected during the ith inspection • I = total number of inspections conducted to date
Maintenance Metrics: Failure Density SSFD: Software System Failure Density: SSFD = NYF / KLMC WSSFD: Weighted Software System Failure Density WSSFD = WYF / KLMC where: NYF = number of software failures detected during a year of maintenance service WYF = weighted number of yearly software failures detected during a year of maintenance service KLMC = thousands of lines of maintained source code
Maintenance Metrics: Failure Density WSSFF: Weighted software system failures per function point WSSFF = WYF / NMFP where: WYF = weighted number of yearly software failures detected during a year of maintenance service NMFP = number of function points designated for the maintained software
Maintenance Metrics: Failure Severity ASSSF: Average severity of software system failures ASSSF = WYF / NYF MRepF: Maintenance repeated repair failure MRepF = RepYF / NYF where: RepYF = number of repeated software failure calls (service failures)
Maintenance Metrics: Availability FA: Full availability FA = (NYSerH – NYFH) / NYSerH VitA: Vital availability VitA = (NYSerH – NYVitFH) / NYSerH where NYSerH = number of hours software system is in service during one year NYFH = number of hours where at least one function is unavailable (failed) during one year, including total failure NYVitFH = number of hours when at least one vital function is unavailable (failed) during one year NYTFH = number of hours of total failure (all systems functions failed) during one year
Maintenance Metrics: Availability TUA: Total Unavailability TUA = NYTFH / NYSerH where: NYSerH = number of hours software system is in service during one year NYTFH = number of hours of total failure (all systems functions failed) during one year
Maintenance Metrics: Productivity and Effectiveness CMaiP: Corrective maintenance productivity CMaiP = CMaiYH / KLMC FCMP: Function point corrective maintenance productivity FCMP = CMaiYH /NMFP where CMaiYH = total yearly working hours invested in the corrective maintenance of the software system KLMC = thousands of lines of maintained software code NMFP = number of function points designated for the maintained software
Maintenance Metrics: Productivity and Effectiveness CMaiE: Corrective maintenance effectiveness CMaiE = CMaiYH / NYF where CMaiYH = total yearly working hours invested in the corrective maintenance of the software system NYF = number of software failures detected during a year of maintenance service
Maintenance Metrics • Log maintenance effort on a per component basis • Choose set of possible metrics which may be related to maintenance • Assess possible metrics for each maintained components • Look for correlation between maintenance effort and metric values