bcspgdse2.blogspot.com Open in urlscan Pro
2a00:1450:4001:80b::2001  Public Scan

Form analysis
0 forms found in the DOM

Text Content

SOFTWARE ENGINEERING (BCS PGD) GUIDANCE FROM MS.DILSHARA WEERASINGHE

This is a Personal Education Blog Maintained by Dilshara Weerasinghe - a Senior
Lecturer in ICT and Business Management . Feel free to use these material and
excel in your studies :) Good Luck !





FRIDAY, MARCH 16, 2018


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)

at March 16, 2018 No comments:
Email ThisBlogThis!Share to TwitterShare to FacebookShare to Pinterest





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?

at March 16, 2018 1 comment:
Email ThisBlogThis!Share to TwitterShare to FacebookShare to Pinterest




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)

at March 16, 2018 1 comment:
Email ThisBlogThis!Share to TwitterShare to FacebookShare to Pinterest




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.






at March 16, 2018 1 comment:
Email ThisBlogThis!Share to TwitterShare to FacebookShare to Pinterest





MONDAY, MARCH 12, 2018


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
)

at March 12, 2018 No comments:
Email ThisBlogThis!Share to TwitterShare to FacebookShare to Pinterest




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



at March 12, 2018 No comments:
Email ThisBlogThis!Share to TwitterShare to FacebookShare to Pinterest




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.

at March 12, 2018 No comments:
Email ThisBlogThis!Share to TwitterShare to FacebookShare to Pinterest



Older Posts Home

Subscribe to: Posts (Atom)



MS.DILSHARA WEERASINGHE (AKA JEEVITHE MAL)

ජීවිතේ මල් ලෝකයත් එක්ක සුහදව ඉන්න කැමති, ජීවිතේට ලොකු ලොකු නිර්ණායක නැති , මම
.... View my complete profile



REPORT ABUSE




MATERIAL LIST

 * ►  2017 (13)
   * ►  November 2017 (8)
   * ►  December 2017 (5)

 * ▼  2018 (16)
   * ►  January 2018 (3)
   * ►  February 2018 (2)
   * ▼  March 2018 (11)
     * 19. How I did BCS exams :)
     * 20. Software Reuse vs Reusability
     * 21. Component Based Software Development
     * 22. People CMM
     * 23. Lets Discuss some past paper questions online–1
     * 25. lets discuss a Quality Management Question Onl...
     * 26. Lets Discuss a General Question on Process Imp...
     * 27. Software Metrics Lesson to be done on 18th March
     * 28. Lehman’s Laws of Software Evolution
     * 29. Function POints vs Object Points
     * 30. Legacy system management





Simple theme. Powered by Blogger.



Diese Website verwendet Cookies von Google, um Dienste anzubieten und Zugriffe
zu analysieren. Deine IP-Adresse und dein User-Agent werden zusammen mit
Messwerten zur Leistung und Sicherheit für Google freigegeben. So können
Nutzungsstatistiken generiert, Missbrauchsfälle erkannt und behoben und die
Qualität des Dienstes gewährleistet werden.Weitere InformationenOk