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.

22. People CMM

The P-CMM can be used as a framework for improving the way in which an organisation manages its human assets,  a five-level model from initial to optimizing. Its strategic objectives include: increasing the capability of an organisation involved in software development by increasing the capability of its workforce; aligning the organization and its employee’s motivation; and retention of critical human assets.

Please read this link : https://ifs.host.cs.st-andrews.ac.uk/Books/SE9/Web/Management/P-CMM.html
whats the similarity of P-CMM and Agile ?
Similar concept in Agile philosophy in the areas of:
Individuals and interactions over Processes and tools
Working software over Comprehensive documentation
Customer collaboration over Contract negotiation
The agile philosophy re “Individuals and interactions over Processes and tools” gives emphasis to such things as: building projects around motivated individuals; their working environment and support needs; trust, autonomy, and self-organizing teams to get the job done.
Now try to answer September 2017 Question 5 -  part b

21. Component Based Software Development

What is a Component ?
A component was seen as an element of a software system that could be accessed, using a remote procedure call mechanism, by other components running on separate computers. Components are higher-level abstractions than objects and are defined by their interfaces. They are usually larger than individual objects and all implementation details are hidden from other components

What is CBSE ?
CBSE is the process of defining, implementing, and integrating or composing loosely coupled, independent components into systems.

Benefit of CBSE
It has become as an important software development approach because software systems are becoming larger and more complex. Customers are demanding more dependable software that is delivered and deployed more quickly. The only way that we can cope with complexity and deliver better software more quickly is to reuse rather than reimplement software components

Design Principles of Components
1. Components are independent so they do not interfere with each other’s operation. Implementation details are hidden. The component’s implementation can be changed without affecting the rest of the system.
2. Components communicate through well-defined interfaces. If these interfaces are maintained, one component can be replaced by another, which provides additional or enhanced functionality.
3. Component infrastructures offer a range of standard services that can be used in application systems. This reduces the amount of new code that has to be developed

Essential Requirements for CBSE
1. Independent components that are completely specified by their interfaces. There should be a clear separation between the component interface and its implementation. This means that one implementation of a component can be replaced by another, without changing other parts of the system.
2. Component standards that facilitate the integration of components. These standards are embodied in a component model. They define, at the very minimum, how component interfaces should be specified and how components communicate. Some models go much further and define interfaces that should be implemented by all conformant components. If components conform to standards, then their operation is independent of their programming language. Components written in different languages can be integrated into the same system.
3. Middleware that provides software support for component integration. To make independent, distributed components work together, you need middleware support that handles component communications. Middleware for component support handles low-level issues efficiently and allows you to focus on application-related problems. In addition, middleware for component support may provide support for resource allocation, transaction management, security, and concurrency.
4. A development process that is geared to component-based software engineering.

Problems with CBSE
CBSE is now a mainstream approach to software engineering—it is a good way to build systems. However, when used as an approach to reuse, problems include component trustworthiness, component certification, requirements compromises, and predicting the properties of components, especially when they are integrated with other components.

Stages of CBSE

1. Component qualification – it is the process of finding suitable components  and evaluating/ conducting an assessment of potential benefits and costs of chosen components  . the most suitable qualified components are then selected for further adaptation
2. Component adaptation – the selected components are modified , improved , to prepare for the next step (ie integration)
3. Component composition (integrating) – it is the process of systematically integrating the selected components
4. Component engineering (design for reuse and implementation of ‘new’ components)

How does it differ from Traditional Software Engineering ?
The process of component-based system development differs from ‘traditional’ development processes.
The main difference is in the separation of the development process of components from the development process of systems.
For the system-level process, the emphasis is on finding the proper components and verifying/evaluating and integrating them. For the component-level process, design for reuse is the main concern.
Component assessment is a new (possibly separate) process for finding and evaluating components.

Try this 
March 2017 A3 
c) Component based systems development (CBSD) methods place a lot of emphasis on component reuse, hence they differ from ‘traditional’ systems development methods.
You are asked:
(i) to briefly explain the main differences between ‘traditional’ and CBSD process/life cycle models;
(4 marks)
(ii) to discuss the main stages of CBSD methods.(7 marks)

20. Software Reuse vs Reusability

REUSE 

use of some previously constructed software
Such as a source code , library , component , a requirement , a design

Benefits of Reuse

• it saves development effort in a new project
• reused modules could be well  tested and already executed
• it saves time allocations , resources , budget allocation , therefore it makes project management convenient
• standardization

** In order to reuse a component , the component should be reusable
there are many levels of software reuse

• a line of code
• a function
• a module
• a component
• a package
• a sub system
• an entire program

problems of reuse

• mismatch of requirements of originally build product and new product
• issues in components such as hidden errors , incompatibilities may be revealed at later adoptations
• cost of reuse could be high

Software Reusability

it is the ability that a software or a component is constructed in such a way , that it could be easily adopted , modified  or reused in other projects in future. not only codes , but also , documents , test plans , design diagrams , requirements could be developed in a reusable manner. reusability is a tactic management when building , packaging , distributing , installations , deployment , design or maintenance practiced by a project team.

the following are some the reusability principles
1. Develop components as simple as possible , in the smallest size of code
2. make the software adaptable that enables a component to adjust to different environments with minimal effort
3. modularity – it is the ability that a system has to decompose a system in to a module hierarchy (separabe modules ) each module can execute oin its own. the external data required are defined in it s interface
4. Correctness – it means the accuracy and well tested nature of a system
5. extensibility – it is the ability to grow in future . or its ability to extend its internal structure ,depth of processing , number of functionalities , volume of data etc.
6. Generic – a system component should be written in a more generic way that it could be specified in future when the compnent is reused
7. orthogonal – it refers to separation oif specific features from the rest of the system therefore such features can be combined in to many combinations of modules to generate different results .
in addition to the above features : Consistency , fast, less complex , stable, flexible , volatile ( changeable)

Try this past paper question 
March 2017 - Question 3
a) Explain the difference between software reusability and software reuse. (4 marks)
b) Discuss briefly benefits of and problems associated with software reuse. (10 marks)

19. How I did BCS exams :)

Hello Everyone ,
I know you all must be getting ready for the battle in few weeks.
Twelve years ago , in 2006 April , I too was just like you and making time tables, revision notes , past paper questions , no pay leaves (talk about it ! )
if you are able to read in sinhala, just spend a few minutes to read how I did my BCS exam in 2006
I am sure it will bring you energy to work hard and pass the exam.. (feel free to comment )

Here is the link to my blog post :

http://sansaare.blogspot.com/2018/03/bcs.html