30. Legacy system management

there are still many legacy systems that are critical business systems. These have to be extended and adapted to changing e-business practices.

legacy systems that they use, with a limited budget for maintaining and upgrading these systems

They have to decide how to get the best return on their investment

There are four strategic options

1. Scrap the system completely 

This option should be chosen when the system is not making an effective contribution to business processes. This commonly occurs when business processes have changed since the system was installed and are no longer reliant on the legacy system.

2. Leave the system unchanged and continue with regular maintenance 

This option should be chosen when the system is still required but is fairly stable and the system users make relatively few change requests.

3. Reengineer the system to improve its maintainability 

This option should be chosen when the system quality has been degraded by change and where a new
change to the system is still being proposed. This process may include developing new interface components so that the original system can work with other, newer systems.

4. Replace all or part of the system with a new system

This option should be chosen when factors, such as new hardware, mean that the old system cannot continue in operation or where off-the-shelf systems would allow the new system to be developed at a reasonable cost. In many cases, an evolutionary replacement strategy can be adopted in which major system components are replaced by offthe-shelf systems with other components reused wherever possible.

1. Low quality, low business value  - Scrap
Keeping these systems in operation will be expensive and the rate of the return to the business will be fairly small. These systems should be scrapped.
2. Low quality, high business value - replace
These systems are making an important business contribution so they cannot be scrapped. However, their low quality means that it is expensive to maintain them. These systems should be reengineered to improve their quality. They may be replaced, if a suitable off-the-shelf system is available.
3. High quality, low business value - Continue or Scrap
These are systems that don’t contribute much to the business but which may not be very expensive to maintain. It is not worth replacing these systems so normal system maintenance may be continued if
expensive changes are not required and the system hardware remains in use. If expensive changes become necessary, the software should be scrapped.
4. High quality, high business value - Continue 
These systems have to be kept in operation. However, their high quality means that you don’t have to invest in transformation or system replacement. Normal system maintenance should be continued.


What about this paper question ?
March 2016 A2.
a) Explain what is meant by a legacy system and why such systems may be critical to the operation of an organization. Discuss ways in which organizations can lessen their reliance on legacy systems. (10 marks)

Sep 2016 - A2 
b) When you are assessing a legacy system, you have to look at it from a business perspective and a technical perspective. From a business perspective, you have to decide whether the business really needs the system. From a technical perspective, you have to assess the quality of the system and its related support software and hardware. You then use a combination of the business value and the system quality to take one of the following informed decisions: scrap the system, re-engineer the system, replace the system, continue the system’s maintenance.
Your task is to assess legacy systems in your organization and decide what would be the most appropriate strategy for maintaining these systems.

ii. Assume that you assessed four systems and the results of the assessment are as follows:
System A: high quality, low business value
System B: high quality, high business value
System C: low quality, low business value
System D: low quality, high business value

What would be your recommendations for each of these systems? Justify your decisions. (10 marks)

29. Function POints vs Object Points

hello all, 
remember we learnt the software estimation techniques . COCOMO and FP ? in another way COCOMO and FP can be taken as software measurements (metrics ) , here I am listing another metric ; object points below .

Function points

FP are a language independent way of expressing the functionality in a program. Productivity is expressed as the number of function points that are implemented per person-month. A function point is computed by combining several different measurements or estimates (see below)



You can then compute the so-called unadjusted function-point count (UFC) by multiplying each initial count by the estimated weight and summing all values. The unadjusted function-point count is then readjusted and yield final function-point count for the overall system.

problems
unction-point count in a program depends on the estimator. Different people have different notions of complexity.

Object Points (Application Points )

Application points are an alternative to function points. Object points are only concerned with screens, reports and modules in conventional programming languages. The advantage of application points over function points is that they are easier to estimate
The number of application points in a program is a computed using ,

• The number of separate screens that are displayed
• The number of reports that are produced.
• The number of modules in codes to be developed to supplement the database programming code

Problems
They are not concerned with implementation details and the complexity factor estimation is much simpler

When you have free time (perhaps after exams ) read this for more information : http://fattocs.com/en/resources/faq
Source : https://ifs.host.cs.st-andrews.ac.uk/Books/SE9/Web/Planning/FPs.html

Try this question : 
2016 Sep A1 -
b) Object Points and Function Points are general, high level system size metrics. Which aspects of the software system are taken into account in the Object Point metric, and which in the Function Point metric?

28. Lehman’s Laws of Software Evolution

Remember we did a lesson on configuration management and change management ?
here is an additional element to the same lesson :
Law 1
first law states that system maintenance is an inevitable process. As the system’s environment changes, new requirements emerge and the system must be modified.
Law 2
The second law states that, as a system is changed, its structure is degraded
Law 3
large systems have a dynamic of their own that is established at an early stage in the development process. which suggests that program evolution is largely independent of management decisions
Law 4
Lehman’s fourth law suggests that most large programming projects work in a ‘saturated’ state. That is, a change to resources or staffing has imperceptible effects on the long-term evolution of the system
Law 5
Lehman’s fifth law is concerned with the change increments in each system release. Adding new functionality to a system inevitably introduces new system faults.
Law 6 and 7
When the time passes , new functions need to be added based on operational and environmental demands. ( users of software will become increasingly unhappy with it unless it is maintained and new functionality is added to it)
Law 8
in order to see products improvement, you need to collect feedback and improve accordingly. (it is not yet clear how this can be applied in practical software development)
Summary of Lehman’s 8 Laws


Try this question : 
2016 Sep A2 
a) With respect to Lehman's laws of software evolution, state the two most fundamental laws and explain their implication for software lifecycle management.
(5 marks)

27. Software Metrics Lesson to be done on 18th March

A high quality process (input) that can result in a high quality product (output)
Software Metric produces a numeric value or profile for an
attribute of a software component, system, or process
examples :

•   Size of a product in lines of code
• the Fog index (Gunning, 1962), which is a measure of the readability of a passage of written text
• the number of reported faults in a delivered software product
• number of person-days required to develop a system component

Purpose of having a Metric
Metrics facilitate prediction, costing, and management decision-making on the process, and expected products.
By comparing the values produced in measurement they can compare  to the standards that apply across an organization, you may be able to draw conclusions about the quality of software, or assess the effectiveness of software processes, tools, and methods
produce an example of using a metric in a project:
example, say an organization intends to introduce a new software-testing tool. Before introducing the tool, you record the number of software defects discovered in a given time. This is a baseline for assessing the effectiveness of the tool. After using the tool for some time, you repeat this process. If more defects have been found in
the same amount of time, after the tool has been introduced, then you may decide that it provides useful support for the software validation process
Software Metrics – 2 Types

1. control metrics (aka Process Metrics) - support process management 
   eg : average effort and the time required to repair reported defects
2. predictor metrics ( aka Product Metrics)- help you predict characteristics of the software 
   eg : cyclomatic complexity of a module ,
   average length of identifiers in a program,
   number of attributes and operations associated with object classes in a design

How Metrics are use din each SDLC stage

• requirements analysis and specification

metrics can help to highlight critical aspects of the expected product, its quality and subsequent maintenance, based on available process and resource inputs. For example, a simple function point analysis may highlight the scale of the development and likelihood of delivery within timescale such that the stakeholders are asked to revisit the requirements, re scope and cost the system;

• design phase

process metrics can highlight complexity, productivity, and engineering build quality. For example, the McCabe complexity metric as an indicator of complexity can result in design decisions about the process of decomposition, and subsequent testing and maintenance processes.

• implementation and testing phase

metrics can verify and predict operational performance, configuration and maintenance requirements. For example, a metric for testing in terms of defects identified per 100 modules inspected, may cause
stakeholders to release the product early, in the sure knowledge of the number and timing of patches that would follow in terms of maintenance.

• maintenance phase

process metrics are concerned with change, their frequency, the sub-systems affected, and the predicted cost and expected system lifetime. Process metrics such as these can lead to decisions to delay certain requests, or system decommissioning.
Directly Measurable Quality attributes
Depth of Inheritance Tree
Cyclomatic Complexity
No of Errors/ error messages 
Program size in No of Lines of Code
Length of user manual
Indirectly Measurable Quality attributes
Maintainability , Reliability ,Reusability , Usability
but  there many be relationships between external and internal attributes, so we can indirectly measure them

Now lets talk about few product metrics
Product metrics have 2 classes
1. Dynamic metrics, which are collected by measurements made of a program in execution. Dynamic metrics help to assess the efficiency and reliability of a program
eg : number of bug reports or the time taken to complete a computation
2. Static metrics, which are collected by measurements made of representations of the system, such as the design, program, or documentation.  Static metrics help assess the complexity, understandability, and maintainability of a software system
eg : code size and the average length of identifiers used
Some descriptions of Static Metrics

*** Cyclomatic complexity is a software metric, used to indicate the complexity of a program. It is a quantitative measure of the number of linearly independent paths through a program's source code.Lower the Program's cyclomatic complexity, lower the risk to modify and easier to understand
lets do a simple calculation of Cyclomatic Complexity

Cyclomatic complexity = E - N + 2*P 
where,
  E = number of edges in the flow graph.
  N = number of nodes in the flow graph.
  P = number of nodes that have exit points

The Cyclomatic complexity is calculated using the above control flow diagram that shows 

seven nodes(shapes) and 

eight edges (lines),

One exit point 

 hence the cyclomatic complexity is 8 - 7 + 2 = 3

questions to try : 

March 2017 A1 

a) Write a brief overview of the various forms of software process metrics 

available today, and discuss how they might be usefully employed from the 

initial project stages, through to the commissioning of a new system. 

Illustrate your answers with examples.

c) Consider the following software attributes: Maintainability, Cyclomatic complexity, 

Lines of Code count (LOC), Reliability, Number of errors.
Which of these attributes can be measured directly and which indirectly? 

Justify your answers.

26. Lets Discuss a General Question on Process Improvement - 3

Look at Sep 2017 Question 4 part a

Define the term software process improvement, and explain how the process triangle of product, people and technology can impact quality and performance

how are you going to answer this kind of a generic question ?
1. first explain what process improvement means (refer to my note )
2.  then explain the process triangle : people, process , technology ( use this link for a very related explanation : https://justindavies.com.au/2007/02/09/people-process-technology-still-the-3-keys-to-successful-application-development-projects/)

3. Explain how each element above can impact quality and performance of an organization / project (here is a very related article : https://www.linkedin.com/pulse/understanding-people-process-technology-equation-kevin-decker )

25. lets discuss a Quality Management Question Online - 2

Hello all , trust we did a quality assurance and quality management lecture few weeks ago. Gess I have forgotten to upload the note.

here it is….

please have a strong look at the ISO 9126 , ISO 9001:2008 guidelines  . these are  useful for the answers
https://www.dropbox.com/s/ps162jyzzivlq4l/PROJECT%20QUALITY%20MANAGEMENT.pdf?dl=0

consider Sep 2017 – Question 4 – part 3
A small to medium sized software house is considering the use of a reference framework such as CMMI, and ISO/IEC 12207 for improving its own processes.
Write a report that presents a brief outline of ONE of these reference frameworks highlighting the degree of coverage of the software process, independence of specific methodologies, and acceptance amongst software professionals and communities.
(12 marks)

You can freely choose CMMI and explain how an organization is supposed to improve their processes , using CMMI as a guideline .
here is a structure for your answer

• what is CMMI
• what's the importance of CMMI for an organization
• provide the diagram for CMMI
• explain each stage and how each stage relate to software processes ( eg : requirements gathering in random data gathering methods like informal discussions could be done in “initial stage” of CMMI )
• explain how far CMMI is relevant to a software company
• explain how MCMI is providing guidelines generic to any company

what if you choose ISO / IEC 12207

whats ISO 12207 ?
This International Standard establishes a common framework for software life cycle processes, with well-defined terminology, that can be referenced by the software industry. It aims to be the standard that defines all the tasks required for developing and maintaining software. It applies to the acquisition of systems and software products and services, to the supply, development, operation, maintenance, and disposal of software products and the software portion of a system, whether performed internally or externally to an organization. Those aspects of system definition needed to provide the context for software products and services are included. Software includes the software portion of firmware (read more : https://www.iso.org/obp/ui/#iso:std:iso-iec:12207:ed-2:v1:en )
This standard contains Primary processes and each process contain activities .

There  are  six different main processes:

• Acquisition
• Supply
• Development
• Operation
• Maintenance
• Destruction

each process has a set of activities . for each activity , deliverables are defined.
read more on : https://en.wikipedia.org/wiki/ISO/IEC_12207

23. Lets Discuss some past paper questions online–1

Look at Sep 2017 Q4 – part 2

Give a brief explanation of what improvements can be made to the construction and infrastructure management processes of a traditional development process cycle.
(8 marks)

what are the exactly looking for in this answer ?

all you need to elaborate here are ,

*** what are the issues that exist in a traditional SDLC processes . How can they be improved by incorporating good practices of other SDLC models such a Agile , INcremental , RAD etc …

here is a suggested structure for your answer

• What are the main steps of traditional SDLC ?
• Provide a diagram ( waterfall)
• what are the key unique features / limitations  of traditional SDLC ?
• sequential, linear models are not too practical  ,
• less involvement of end users in requirement gathering ,
• too many processes , procedures ,
• belief in delivering documentations
• testing takes too long in planning and design
• change management process is slow and formal
• less team work seen
• modular programming may not be practical
• how could the SDLC stages be improved by incorporating good practices of any other SDLC you know
• Requirements Engineering stage ( by involving end users , prototyping )
• Design Stage ( reduce design and development time by using CBSD , reusing components
• Development (use of CASE tools , development frameworks etc , component based delivery like incremental )
• Testing ( involvement of end users , using 3rd parties / outsourcing for testing smoke testing )
• Implementation ( pilot delivery , component based implementation )
• Maintenance (version management , change management )

you need to elaborate the above points I have given .

BCS Examiner report says ,

The “traditional” software development process is often represented by a sequence of phases from development into maintenance. Within each phase, there exist many activities that can be implemented to varying degrees. These improvements relate not just to the sequencing of the steps or to the inclusion (or exclusion) of certain steps but also to the specific implementation of the individual steps.
Improvements to the general area of requirements management, including capture, sign-off and change management by adopting prototyping methods or tools to a lesser or greater degree. In addition improvements in the testing process can also yield positive benefits.