BCS THE CHARTERED INSTITUTE FOR IT
BCS HIGHER EDUCATION QUALIFICATIONS
BCS Level 6 Professional Graduate Diploma in IT
MARCH 2014
EXAMINERS’ REPORT
Software Engineering 2
General Comments
The pass rate of was marginally lower than the summer examinations of the
previous year. The following issues (identified in previous examiner reports)
appear to be significant in some centres:
1. Coverage of the syllabus. Centres should: encourage candidates to
adopt a staged approached to their learning, by completing the
Software Engineering 1 module, before attempting Software
Engineering 2; and provide more consideration to less popular topics
such as software maintenance and software management;
2. Subject awareness. A successful learner should provide more breadth
in responses given to all parts of the question by reading more widely
publications within the profession as well as recommended text. Many
candidates attempted to take a common-sense approach to answering
questions without evidence of comprehending fundamental concepts;
3. Examination techniques.
Some candidates need better time
management to ensure that the majority of questions are given
sufficient time and attention. It is dangerous to assume that a pass is
possible with one very good answer and two very poor answers, for
example;
4. Answers should be legible, well structured and formatted.
It is important that candidate responses to questions are: comprehensible,
exhibit breadth and depth in knowledge; applied to the scenario presented;
and have relevance and appropriateness to the questions and rubric of the
paper itself.
Question 1
a) Explain the key features of and differences between a “Technical
computer-based system” and a “Socio-technical system”. Your
explanation should include examples of each.
(5 marks)
b) Define what is meant by an emergent property of a software system
and distinguish between non-functional emergent properties and
functional emergent properties.
(5 marks)
c) The following strategies which may be used in system design to
manage risks of an accident or incident occurring when a critical
system is in operation to ensure its dependability. Explain each strategy
with suitable examples and discuss any problems associated with each
strategy:
i) Damage Limitation,
ii) Risk Detection and Removal, and
iii) Risk Avoidance.
(15 Marks)
Answer Pointers
A good answer should cover the following points:
a) The key features of a technical computer-based system are as
follows: it includes hardware and components, but not knowledge
of how the system should be used to achieve some higher
objective. It can be thought of a tool to be used for many purposes.
A key feature is their deterministic behaviour.
An example of a technical computer-base system is digital
television or programmable microwave oven.
The key features a socio-technical system are the following: It can
include one or more technical computer-based systems and it also
includes knowledge of how it should be used to achieve some aim.
A key feature of socio-technical systems is that they have emergent
properties, exhibit non-deterministic behaviour and are associated
with society-based objectives which may change over time.
An example is a MOOC (Massive On-line Course) with its Virtual
Learning Environment and associated procedures and processes.
b) An emergent property of a system is one which is associated with
the system as a whole and one which can only be evaluated once
the whole system has been constructed. Such properties are said to
“emerge” once the system has been fully integrated into its
operational environment. Emergent properties can be either
functional or non-functional. Examples of functional emergent
properties are the MOOC being a means of providing education
once all its parts have been put together or a modern car being a
means of transportation with its hardware, software, satnav, etc all
assembled.
Examples of non-functional emergent properties reflect the
operational behaviour of a system and are reliability, performance,
and security.
c) Damage Limitation Strategy: The critical system is designed and
developed so when an accident or incident occurs, its effects are
contained or minimised. An example would be building a system
“safe-mode” i.e. a shut-down state where the system alerts
operators and ceases its activities.
Problems with DLS:
Once the incident or accident has occurred, it may not be possible
to bring the affected part of the system into a “safe-mode”. The
consequences of shutting down the whole or parts of the system
may be too risky.
Risk Detection and Removal Strategy: The critical system is
designed and developed so that any risks can be detected and
dealt with before they cause an incident or accident. An example
would be monitoring pressure in a chemical plant and opening a
release valve if the pressure became too high.
Problems with RDRS:
Obviously the means of removing the risk must be adequate and
not have an adverse impact on other parts of the system.
Risk Avoidance Strategy: The critical system is designed and
developed so that the identified risks cannot occur.
Problems with RAS:
It is almost impossible to design and develop a critical system that
is completely with any risks.
With all these strategies, there are problems of thorough risk
identification, analysis and classification. It may also be difficult to
decompose the risk into its root causes. It is usual to use a
combination of these strategies.
Examiner’s Guidance Notes:
This question assesses a candidate’s knowledge of socio-technical systems,
emergent properties of systems as well as risk management strategies. Most
students failed to demonstrate an understanding of the social aspects of
computer systems. While students could distinguish between functional and
non-functional properties, they were less able to define the meaning of an
emergent property. When explaining risk management strategies, most
students failed to address the critical system dependability aspect of the
question. This was the least popular of the Section A questions and the most
poorly answered.
Question 2
a) Explain what is meant by Component-Based Software Engineering
(CBSE) and discuss the impact of Open Source Software Engineering
projects, available from the internet, on the practice of CBSE.
(5 marks)
b) In the context of Software Engineering, explain what is meant by a
Software Product Line. Discuss how and why a software house may
wish to develop its own Software Product Line. Your answer should
include appropriate examples.
(15 marks)
c)
Outline the advantages and disadvantages of using externally acquired
Components-Off-The-Shelf and externally sourced web services in a
software development project.
(5 marks)
Answer Pointers
A good answer should cover the following points:
a) Component Based Software Engineering is the process of developing
software systems from components, by specifying the components
needed, developing or obtaining them externally, then integrating or
composing them into a system. Its key features are as follows:
middleware is used to support component integration, components are
independent modules specified and accessed solely by their interfaces,
standard component models and interface definitions are used, and a
development process involving component specification, search,
selection and validation is used.
Although much software id freely available from Open Source projects
through SourceForge, and some of it is re-used iin component form,
largely most Open Source projects have not adopted a ComponentBased Software Engineering approach and so their impact has been
limited.
b) A Software Product Line builds on the experience that an organisation
may have of building a series of similar systems in a specific domain
and establishes a framework for encapsulating the experience and
knowledge gained in a set of reusable re-usable architectures and
components which allows a number of related software products to be
assembled. For example, the on-board computer controlling a series of
car engines may itself be assembled from such a framework developed
as there are sufficient common elements to all the car engine
controllers in a specific car manufacturer’s range of cars.
The process of building a software product line involves recognising
that the software house has been developing a number of commonly
recurring systems in a specific application domain and studying these
systems to abstract their common reference frameworks, architectures
and common components. These are then specified and components
may be re-engineering for better re-usability. Steps to deriving specific
products are formalised with any options or variation noted.
The company will now have a valuable repository of both their
knowledge and expertise as well as a series of re-usable frameworks,
architectures and components to deploy when building future products
matching the product line. It save it time when developing future
products and lead to high quality, more maintainable products.
It is possible to undertake development of a product line from scratch
where the software house has observed an opportunity for distilling
knowledge of software systems in a particular domain; however, this
will involve significant investment and detailed domain analysis as well
as software development. The domain must also be established and
mature to enable a useful software product line to be developed.
c) Advantages: Potential low-cost overall as already developed, tested
and maintained by provider; quality of component may be readily
determined if it is already in widespread usage; no need to re-invent
the wheel if a suitable, existing component is available.
Disadvantages: May not be possible to adapt component to the specific
needs of the development project, so some compromise may be
needed; the component provider may cease support and the long term
evolution of the component may be out of the control of the
development project and the subsequent maintenance team.
Examiner’s Guidance Notes:
This question assesses a candidate’s knowledge of Component Based
Software Engineering, Software Product Lines and Software Reuse based on
COTS and web services. Most students were able to explain CBSE but their
answers lacked specifics and very few students demonstrated an
understanding of the concept of Software Product Lines. The closest some
students got was to mention software versioning; other described a software
production line. Answers to part c generally rehearsed pros and cons of
software reuse. This question was the second most popular question in
Section A.
Question 3
a) Discuss four key features or practices of Agile Development and
explain the rationale for each.
(8 marks)
b) Compare ordering of software processes in the V-model of the
Software Life Cycle with ordering of software processes in the Agile
approach to software development and testing.
(12 marks)
c) Discuss the differences between Model-Driven Development and TestDriven Development and indicate under which conditions it is
appropriate to use each.
(5 marks)
A good answer should cover the following points:
a) Four key practices of Agile Development are:
Pair Programming: This involves developers working in pairs as code
is written. The rationale being that two heads are better than one,
programmers working together can question each other’s code and
gain a better understanding of the code being developed in case one of
the pair moves on to other work.
Shared ownership of the code: This follows from pair programming, but
is a broader practice meaning that everyone on the team takes
responsibility for the system being produced.
Refactoring of code: This involves improving the design of code after
the code has been written, so that it becomes more understandable to
the whole team. Refactoring results in more maintainable in the future.
This especially important in agile development where the system is
incrementally developed and change is inevitable.
Customer Involvement: In Agile Development, the customer is
embedded within the team and engages activitely in the development
process. This allows immediate feedback from the customer and
ensures that the system being developed is what the customers
requires and wants. The rationale is that this practice increases
customer satisfaction.
Although much software is freely available from Open Source projects
through SourceForge, and some of it is re-used iin component form,
largely most Open Source projects have not adopted a ComponentBased Software Engineering approach and so their impact has been
limited.
b) Software processes in the V model follow the classic Waterfall model of
the software life cycle: Requirements Elicitation, Requirements
Specification, Architectural Design, Component/function Design,
Module Implementation and Unit Testing, then there is in ascending
order: Component/Functional Testing, Integration Testing, System
Testing and finally Acceptance Testing. In kind of testing there is a link
with earlier stages in the life cycle using test plans developed by the
requirements, the system specification, its architecture, and
component’s functional specifications.
Agile software processes are much less sequential and typically are
repeated several times and a key feature is that tests are developed
before code. Agile does involve working with stakeholder/customer to
develop an understanding of the required system through story boards
and user cases, but no formal specification of the system is developed
although some UML modelling of classes and behaviours may take
place; instead the system is decomposed into modular parts and tests
are developed for each module which is then implemented. The
modules are developed, tested and integrated in incremental versions
of the system; the customer working with the team can give their
feedback as soon as a working implementation of the system is
available. The tests developed over time are aggregated and used for
regression testing as the system is rebuilt regularly with changed
modules to meet the customer’s requirements which may emerge
during the development. In Agile development, the various
development phases and especially the testing phases are not so well
differentiated, nor are the deliverables from each phase employed as
planning documents for subsequent testing phases.
c) Model driven development is based on the use of UML in the top down
development of Object Oriented Systems. Working with stakeholders, a
system vision is developed and then through Use-Cases, UI modelling,
prototyping the requirements and high level architecture are developed,
These models are refined to obtain the Class diagrams and activity
diagrams, state charts, and other models which are further refined into
the implementation and running system. An example is the Rational
Unified Process.
Test Driven development involves rapid cycles of testing, coding/recoding and refactoring. Obviously the first testing cycle cannot succeed
until some code has been developed, but thereafter, the cycle can
proceed It focuses on developing tests before code and is a more
bottom up approach where the system is built incrementally with tests
to validate and verify the correct functioning of each increment being
developed prior to the coding. It also involves regular builds of the
system with re-testing sometimes on a daily basis. It is associated with
Extreme Programming methods and can be seen as a development of
test-first programming.
Model driven development is appropriate in a mature domain where a
product line is being developed; while test driven development is
appropriate when building more experimental systems in less well
understood domains.
d) Discuss four key features or practices of Agile Development and
explain the rationale for each.
(8 marks)
e) Compare ordering of software processes in the V-model of the
Software Life Cycle with ordering of software processes in the Agile
approach to software development and testing.
(12 marks)
f) Discuss the differences between Model-Driven Development and TestDriven Development and indicate under which conditions it is
appropriate to use each.
(5 marks)
Answer Pointers
A good answer should cover the following points:
a) Four key practices of Agile Development are:
Pair Programming: This involves developers working in pairs as code
is written. The rationale being that two heads are better than one,
programmers working together can question each other’s code and
gain a better understanding of the code being developed in case one of
the pair moves on to other work.
Shared ownership of the code: This follows from pair programming, but
is a broader practice meaning that everyone on the team takes
responsibility for the system being produced.
Refactoring of code: This involves improving the design of code after
the code has been written, so that it becomes more understandable to
the whole team. Refactoring results in more maintainable in the future.
This especially important in agile development where the system is
incrementally developed and change is inevitable.
Customer Involvement: In Agile Development, the customer is
embedded within the team and engages activitely in the development
process. This allows immediate feedback from the customer and
ensures that the system being developed is what the customers
requires and wants. The rationale is that this practice increases
customer satisfaction.
Although much software is freely available from Open Source projects
through SourceForge, and some of it is re-used iin component form,
largely most Open Source projects have not adopted a ComponentBased Software Engineering approach and so their impact has been
limited.
b) Software processes in the V model follow the classic Waterfall model of
the software life cycle: Requirements Elicitation, Requirements
Specification, Architectural Design, Component/function Design,
Module Implementation and Unit Testing, then there is in ascending
order: Component/Functional Testing, Integration Testing, System
Testing and finally Acceptance Testing. In kind of testing there is a link
with earlier stages in the life cycle using test plans developed by the
requirements, the system specification, its architecture, and
component’s functional specifications.
Agile software processes are much less sequential and typically are
repeated several times and a key feature is that tests are developed
before code. Agile does involve working with stakeholder/customer to
develop an understanding of the required system through story boards
and user cases, but no formal specification of the system is developed
although some UML modelling of classes and behaviours may take
place; instead the system is decomposed into modular parts and tests
are developed for each module which is then implemented. The
modules are developed, tested and integrated in incremental versions
of the system; the customer working with the team can give their
feedback as soon as a working implementation of the system is
available. The tests developed over time are aggregated and used for
regression testing as the system is rebuilt regularly with changed
modules to meet the customer’s requirements which may emerge
during the development. In Agile development, the various
development phases and especially the testing phases are not so well
differentiated, nor are the deliverables from each phase employed as
planning documents for subsequent testing phases.
c) Model driven development is based on the use of UML in the top down
development of Object Oriented Systems. Working with stakeholders, a
system vision is developed and then through Use-Cases, UI modelling,
prototyping the requirements and high level architecture are developed,
These models are refined to obtain the Class diagrams and activity
diagrams, state charts, and other models which are further refined into
the implementation and running system. An example is the Rational
Unified Process.
Test Driven development involves rapid cycles of testing, coding/recoding and refactoring. Obviously the first testing cycle cannot succeed
until some code has been developed, but thereafter, the cycle can
proceed It focuses on developing tests before code and is a more
bottom up approach where the system is built incrementally with tests
to validate and verify the correct functioning of each increment being
developed prior to the coding. It also involves regular builds of the
system with re-testing sometimes on a daily basis. It is associated with
Extreme Programming methods and can be seen as a development of
test-first programming.
Model driven development is appropriate in a mature domain where a
product line is being developed; while test driven development is
appropriate when building more experimental systems in less well
understood domains.
Examiner’s Guidance Notes:
This question assesses a candidate’s knowledge of approaches to software
development: agile, the V-model, model-driven and test-driven. Most students
demonstrated an understanding of agile development and the V-model. Few
students were able to demonstrate a good knowledge of either model-driven
or test-driven development, and when it would be appropriate to use each.
This was the most popular of the Section A questions and it was the best
answered of the questions in Section A.
Question 4
a) Define the term software maintenance and carefully distinguish
between corrective, adaptive, perfective, and preventive maintenance
activities.
Answer Pointers
A good answer should:
Firstly define software maintenance in terms of post-release activities that
attempt to prolong the longevity and usefulness of operational software by
creating new versions that exhibit higher quality and better maintainability.
That is, making changes to the system after it has been delivered to the
customer.
(2 marks)
Corrective maintenance is concerned with fixing known faults and represents
around 20% of all maintenance activities. These may include coding errors
(relatively cheap to correct), or design faults that may involve major rewrites.
(2 marks)
Adaptive maintenance attempt to respond to changes in the operating
environment, covering such things as the adoption of new hardware, network,
functionality, or operating system platform.
(2 marks)
Perfective and Preventive maintenance are more difficult to differentiate and
whilst the former can be seen as perfecting what the software was designed
to do and how it does it, the latter (often referred to as reengineering) is
primarily concerned with minimising future maintenance through rebuilding
software that is currently operational.
(3 marks)
Adaptive, Perfective, and Preventive maintenance accounts for around 80%
of all maintenance activities.
(1 mark)
(10 marks)
b) Discuss how the mechanisms available for evaluating, controlling, and
making changes to software have impacted on the percentage of time
spent fixing mistakes. Your answer should include appropriate
examples.
Answer Pointers
A good answer should recognise the process stages of maintenance and
discuss some of the mechanisms available. The following points should be
covered:
Evaluating change. These can vary from bug fixes to system upgrades.
Implementing such changes tend to have associated costs in time and the
degree to which existing system structures are degraded and future
maintainability reduced, which may be the consequence of complex internal
structures and/or relationships with the external environment.
(2 marks)
Metrics that helps in understanding the relationship between the system and
its environment are useful in the evaluation of change requests. Complexity
measurements such as McCabe Complexity are very useful in identifying
software components that are expensive in respect of change implementation.
Such knowledge allows the engineer to impact on the percentage of time
spent effecting the change by being able to more accurately identify the time
frame for completion, and size the problem and resource requirements.
(3 marks)
Controlling change. A prioritization system is one of the more effective forms
of control in respect of selecting the next change to be serviced. High priority
may be given to requirement changes reflecting new business processes, or
problems in code affecting the business and its customer. However, metrics
for monitoring the process of maintenance can also be used to assess
effectiveness. For example, an increase in the number of bug fix requests
over a given time period may be indicative of a decline in maintainability of the
software or the effectiveness of the maintenance team. This information
allows the engineer to impact on the percentage of time spent fixing mistakes
by being able to identify and anticipate problems, and initiate corrective
actions early.
(5 marks)
Effecting change. On the assumption that a change cost-benefit analysis and
approved, high priority bug fixes may require short-circuiting the formal
process of requirements analysis and software development to going directly
to the problem source code for analysis. Once modifications have been
made, the modified system (or patch to be downloaded) is delivered. The
problem with such fixes is that the original documentation and code become
inconsistent and difficult to maintain. That is, the impact of emergency bug
fixes to make future changes progressively more difficult. One of the ways
this could be avoided would be to leave the change request open rather than
closed out, until it has been properly engineered and associated
documentation completed.
(5 marks)
(15 marks)
Examiner’s Guidance Notes:
This question assesses a candidate’s knowledge and awareness of software
maintenance, its processes, metrics and techniques. The question was joint
second in popularity, but had the second lowest pass rate (28%). It is clear,
from many
of the answers given, that the subject was not as well understood or covered
as earlier lifecycle stages. Candidates and centres need to recognise the
importance of maintenance and ensure chapters in recommended text are
well covered and understood.
Question 5
a) You have been appointed as a project manager for a small company
trying to develop the next generation of web technologies for a very
competitive retail market.
Discuss your approach to team selection and structures, and the mechanisms
you would choose to control and deliver project success for this organisation.
Answer Pointers
A good answer should cover:
Overview: that project management is a people-intensive activity, and that the
project manager role is to primarily plan, monitor, and control the work of a
team in a manner that ensures the successful completion of the project; that
the market is competitive and volatile where environmental changes can
adversely impact the project if artefacts are not delivered quickly and of the
right quality.
(2 marks)
Selection: It is important that team membership, organisation, and operation
facilitates personal growth, individual and collective motivation, the utilisation
of talent and expertise to maximum effect, and commitment retention.
(2 marks)
In terms of selection, having the right mix of people as well as technical skills
is an important qualification for membership. Most significant is the project
manager’s ability to motivate others to produce their best, and to anticipate
and solve problems. In the latter case, this may involve such things as
organising (and creating) processes to facilitate good communication from
initial concept and prototype, to final product.
(2 marks)
The project manager should play an important role in team selection. This
may involve external recruitment or selecting from an existing pool of
employees. In the latter case, motivating team may be an even greater
challenge for the project manager. However, Meredith Belbin’s research and
subsequent Team Role theory demonstrates that there is no one type of
person representing an ideal team player.
The important issue for the project manager is that the team contains a mix of
various types such as innovators, implementers, finishers, monitor-evaluator
etc. As part of the selection process the analysis of completed psychometric
tests can be indicative of the role may naturally gravitate towards.
(3 marks)
Structure: Team structure may depend on the management style of the
organization and this may dictate team size and their skill levels. However,
large teams often experience difficulty in communication with and between
members. Organisational paradigms such as the traditional hierarchy of
authority work well when producing software products that are similar to past
efforts. Given the nature of the existing environment difficulty would be
experienced as innovation and technological breakthroughs are expected. In
recent years, agile teams consisting of small, highly motivated members have
been promoted as an ideal solution to the many structural deficiencies of
project teams. Assuming that the team members have a high level of
individual competency and can self-organise accordingly, it would be the
structure of choice for the web technologies projects.
(4 marks)
Mechanisms: the key problems to be solved are the coordination of project
activities to ensure efficiency in the use of resources, and speed of delivery.
This also depends on the means of communication. Small teams often allow
communication to be clear and instant. The quality of work must also be
monitored on a regular basis, and recognition given to teams and their
members for performance beyond the call of duty. Therefore, regular
meetings (sometimes informal)and reviews should be carried out.
(3 marks)
(16 marks)
b)
Discuss the view that managing the software projects of today is
no different from managing projects for products in other business
sectors.
Answer Pointers
A good answer should:
Highlight the fact that all projects do have a lot in common. The project, and
development life cycles are difficult to differentiate, where, in the case of
PRINCE2 for example, general project stages include definition, planning,
implementation, monitoring and delivery, and evaluation and closure. The
artefact, whether it be physical, virtual or conceptual can only be delivered
through the management of people and resources.
(3 marks)
Highlight that project artefacts today are complex and often multi-faceted,
requiring project teams with diverse skills, and using multi-disciplinary
approach in their creation.
Thus software, projects in the games industry often appear to have similar
crews and teams to that of the Film and Television industry. Likewise,
engineering projects are increasingly complex with ecological, sociological
and technical constraints.
(3 marks)
Suggest that the real issue is the degree to which one is able to accurately
measure and predict the quality and performance of the artefact. The once
unique features of computing projects are becoming evident in other sectors,
namely:
Constantly changing technological environment of the business;
Difficulty in recruiting and retaining experienced staff;
The need to manage extensive user involvement;
Producing solutions that have never been tried before;
Using technologies that are likely to change during the life of the project
The management of large increases in project scope
(3 marks)
(9 marks)
Examiner’s Guidance Notes:
This question proved to be the most popular amongst candidates and had the
third highest pass rate (48%). It was clear from the answers submitted, that
many candidates in their answer to part a) had little knowledge or awareness
of project management techniques and principles in respect of team building
and achieving project success. Rather than giving common sense and
opinionated answers, candidates need to give informed responses, and
centres need to ensure chapters in recommended texts are well covered and
understood, especially in the areas of the software project life and
management principles.