BCS HIGHER EDUCATION QUALIFICATIONS Level 6 Professional Graduate Diploma in IT March 2013 EXAMINERS REPORT Software Engineering 2 General Comments The pass rate this year was significantly better than the summer examinations of the previous year. The following issues (identified in previous examiner reports) are once again repeated as areas that can affect the performance of candidates positively: 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 training in aspects of problem solving using UML, and software measurement; 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; 3. Examination techniques. Some candidates answered too many questions resulting in very shallow answers ; or too few, which resulted in too detailed an answer but insufficient to compensate for the marks lost by not completing a third question; 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 In your role as a software engineer, you have been given the task of introducing software reuse for existing and new software development. a) Write a report that gives an overview of software reuse and discusses how various approaches to reuse might handle legacy software and new application developments. A good answer should produce: A structured report with appropriate headings, including introduction and conclusion; Introduction that defines key concepts, gives an overview of software reuse, and highlight the progress made in its adoption. For example, the transition from original to reuse software development has only occurred within the last decade, to lower production and maintenance costs. Overview The software units that can be re-used include application: the entire application through reconfiguration for a target environment, or integration in an entirely new application; component: typically sub-systems with well-defined interfaces for easy assembly; Object or function: an entity conforming to the Single Responsibility Principle is common to standard libraries, characterised by their longevity. Body of report that discusses reuse approaches such as: Possible approaches that could be discussed include design patterns, componentbased development, application frameworks, and service-oriented systems. New applications can be developed through and for reuse. The latter can result in rapid development of applications with desired behaviour and robust structures making use of resilient design patterns and tried and tested components and frameworks. Design patterns are generic abstractions occurring across a wide set of applications which can provide a foundation for reliable design structures and interactions for new software developments. At a higher level, application frameworks (e.g MVC) are extendable generic structures for creating more specific applications. However, the prohibitive redevelopment cost of legacy systems means that such applications can only become reusable very quickly by means of wrapping. This involves defining a set of interfaces through which new software components can pass parameters to and obtain results from the existing legacy system. Conclusion that draws attention to the progress made to date though OO methods, tools, and languages. However, some issues regarding effective and productive reuse still remain: in particular, easy-to-use and integrated CASE toolsets; and the maintenance of a readily available and user-friendly reuse library. (17 marks)
b) Consider the problem of software quality and programmer productivity, and explain whether a software crisis exists today. How has reuse contributed to the problem or the solution? Justify your answer. A good answer needs to show some awareness of what is meant by a software crisis, identifying such things as programmer productivity, and software quality as key issues of the past and perhaps of the present. It can be argued that reuse has contributed to the solution through modern tools that have made developers more productive and the widespread adoption and promotion of good development practice (OO) and thus standards (like UML) have significantly improved quality and reduced the application backlog. However, it can also be said that the backlogs still persist, and reuse is part of the problem, especially as many of today s applications lack longevity because of poor engineering quality, and inability to adapt to rapidly changing requirements and technology. Thus, the proliferation of application and components created in such an environment without a universally accepted standard makes it difficult to identify the right components amongst many alternatives, resulting in the not-invented here syndrome. (8 marks) Examiner s Guidance Notes: This question assesses a candidate s knowledge and awareness of software reuse and its impact on software quality and programmer productivity. This was the most popular question and whilst many appear to understand the concept of reuse, a significant number were unable to recognise its potential effect on productivity and quality.
Question 2 The managing director of a small financial services company recently attended a UML development seminar and has asked you to: a) Define and explain the differences between the following UML terms: (i) Association, aggregation, and composition; (ii) Invariant and pre- and post- conditions A good answer should: (i) Define UML Association as the structural relationship that exists between two self-contained objects (classifiers). {The answer can be illustrated with a simple diagram with an association link having two ends that can be labelled with a name (a verb or phrase), a multiplicity (or repetition), and navigability (directional arrow}; Aggregation is a specialized form of Association that represents the whole-part dependency (e.g parent-child) relationship between the aggregate (whole) and a component part. However, the component part can remain should the aggregate be removed. {The answer can be illustrated with one end of the association link having a clear diamond}; Composition as a specialized form of Aggregation in which the component part cannot exist independently of the whole (e.g the deletion of the parent will also result in the deletion of the child object): {the answer can be illustrated with one end of the association link having a filled diamond}; (ii) Recognise that the named terms are assertions and therefore, represent statement that should never be false; Thus, an invariant is a statement about a class such that for all instances of that class, a said operation invoked on it will always be true; similarly, a pre-condition is a statement about the prevailing system state that needs to be true before the performance of a given operation; whilst post-condition is a true statement about the change in conditions resulting from the execution of the operation. (10 marks) b) Use UML notation to demonstrate the modelling of a customer account, and deposit and withdrawal services, paying particular attention to such things as integrity constraints, and the dependency relationship. A good answer would typically present an outline model of a financial services application using Use Case or Class diagrams. In the case of the class diagram: - the key classes would include: Account and Customer, where the specification of the former s attributes would include accountnumber, balance, and openaccount(), deposit() and withdrawal() methods. Similarly, the Customer class may include personaldetails attributes, and Deposit_toSavingsAccount() and withdraw_fromcurrentaccount() methods. - The dependency relationship could show sub-classes of accounts (e.g savings and current) derived from Account. But, more importantly, the association link between Account and Customer is labelled as follows:
Account has one Customer {Aggregate type association} Customer has at least one Account {simple type association} - An example of Integrity constraints such as Withdrawal constraints: Precondition: wamount <= cbalancet - The withdrawal amount <= the Current balance Postcondition: cbalancet+1 < cbalancet The current balance < the previous balance (9 marks) c) Briefly discuss whether the continuing development of UML as an open standard will result in the creation of tools to facilitate reverse engineering and, more significantly, able to automatically generate production quality code from such designs. Justify your answer. A good answer should highlight the proliferation of tools able to generate code from designs based on UML in addition to producing UML designs from object oriented programming language source code (e.g. the Eclipse development environment). However, it is a question of whether a design in UML represent the blueprint for production and therefore, cannot be changed; or the means by which one gains a better understanding of the requirements and explore potential solutions before committing designs to production style toolkits. It can be argued that the adoption of UML as a blueprint language is a deviation from its original purpose in design, and may result in production systems that are excessive consumers of resources, and to which insufficient time was given to the design phase. Examiner s Guidance Notes: (6 marks) This question proved to be the least popular amongst candidates and had the second lowest pass rate (35%). It was clear from the answers submitted, that many candidates in their answer to part a) had little knowledge or awareness of the conceptual definition and characteristics of the terms listed, and experience of open source development; and in part b) lacked experience of problem-solving with UML. Finally, many candidates did not appreciate the potential and current developments surrounding UML products for generating code and application software from design documents.
Question 3 a) Distinguish between software process metrics and software product metrics. A good answer should see software product metrics as measures of the software product; and software process metrics are measures of software development process. For quality purposes, product metrics might include such things as usability, efficiency, reliability, and portability. The size of the software can be considered as a measure of the software product itself. However, these become process metrics, when considered within the context of the development process as indicators of the effort required to build the system. (5 marks) b) 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. A good answer should: Highlight the importance of high quality process (input) that can result in a high quality product (output). Metrics facilitate prediction, costing, and management decision-making on the process, and expected products; In 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; In the 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. In the 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. In the 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. (10 marks)
c) Explain what is meant by software product complexity, and demonstrate how measures of module coupling, cohesion, and size can help the engineer monitor the build quality of software. A good answer should Recognize and explain complexity at different levels in terms of structure (e.g graphs, trees, lists), cognition (e.g abstraction, induction, recursive processes), and magnitude (scale and size beyond what is accepted as manageable). Coupling is concerned with the degree of connectivity between the modules of a system. Typically, with good engineering practice most modules are loosely coupled via their interfaces such that there are no side effects resulting from changes in implementation. Nevertheless, many modules are coupled via their parameter list, and the greater the number of parameters exchanged the more likely that errors will arise from missing or incorrect type parameters; Cohesion is concerned with the internal strength where each module exhibits the single responsibility principle. For example, using a given value parameter, each statement will act upon the intermediate result of the previous statement until the result is produced. Thus, increasing values for this metric would indicate that the module is in danger of violating the single responsibility principle, resulting in the likelihood of performance inefficiencies, and defects when change is affected. Module size is concerned with the lines of code, internal data structures, and components. For the engineer the optimal module size can get the best performance from the target platform. However, that same value for the maintenance team may be indicating poor comprehension or understandability. (10 marks) Examiner s Guidance Notes: This question proved to be the second most unpopular amongst candidates and had the lowest pass rate (34%). It was clear from the answers submitted, that many candidates in their answer to part a) and b) were lacking in knowledge of software metrics, both product and process. Even with the concept of cohesion and coupling (in part c), candidates gave chapter and verse responses on their different types, but were not able to see it within the context of a software complexity or quality metric. Question 4 a) Define what is meant by reverse engineering and re-engineering of a software system, distinguish between these two processes, and explain how these two processes are related. (5 marks) b) As a software engineer, you have been given the task of reverse engineering and reengineering a large legacy system written in languages which are no longer widely used in modern development with out-of-date and incomplete documentation. Give an assessment of the problems likely to be encountered in this task. Explain how you would go about the reverse engineering of this system. Outline the techniques and tools that you could use, and the results that you would expect to produce. (15 marks)
c) The practice of re-factoring in agile development can be considered as a form of continuous reverse and re-engineering. Discuss the validity of this claim. (5 marks) A good answer should cover the following: a) Reverse engineering of software is the analysis of existing legacy software artifacts to recreate or discover higher level abstractions of the software; it usually involves analyzing the source code of a system to extract information about its organization (e.g. architecture) and its functionality (high level design). Re-engineering of software is the process of taking a legacy system and producing a re-structured and modularised version of the system through a series of automated and manual transformations. It does not alter the functionality of the original software; it is concerned with improving its quality, its comprehensibility and future maintainability. These two processes are related as follows: it is not possible to re-engineering software without a good understanding of the software and its documentation, where the documentation is missing or out-of-date, such understanding must be recreated through reverse engineering and hence reverse engineering usually precedes re-engineering. In fact, reverse engineering is often seen as the first step in the re-engineering process. b) Problems likely to be encountered are as follows: 1. As the system is written in languages no longer widely used it may be necessary to convert it through automated and manual transformations to a more modern programming language so that in the future it will be easier to find knowledgeable software engineers to maintain the system; however, it be difficult to software engineering with adequate knowledge of the old programming languages to undertake the necessary manual transformation work.. 2. To aid the re-engineering process and assist future maintainers, redocumentation may be desirable; this is likely to prove difficult in view of the inaccurate and missing documentation and as this is an old system, the staff involved in its development may no longer be available. 3. Depending on the versions of the old programming languages in which the system was originally written, it may prove difficult to find any translators that will convert the old source code into more modern languages. 4. Data re-structuring may be needed if data structures are altered during the re-engineering of software. 5. If the re-engineering involves moving from a procedural programming language to an object oriented programming language, significant work may be involved and there may be little potential for automation. The process of re-engineering involves the following steps: 1. Source code analysis and conversion 2. Documentation Recovery and Re-documentation 3. Program re-structuring 4. Program modularization 5. Data re-structuring Techniques and tools and results produced: 1. Source code analysis and conversion: The old source code is analysed and and converted to the new language using source code analysers and old-code to new-code converters. This process is likely to be semiautomatic and results in program in a more modern version of the old language or a program in a completely new modern language.
2. Documentation recovery and re-documentation:: code analysis tools can assist with this as well as automated source code documentation tools; results in improved and more comprehensible documentation to assist reengineering and future maintenance. 3. Program re-structuring: automated re-structuring tools can be applied once the code has been converted to the new language. The result is more maintainable software with an improved structure and a more modern architecture may be introduced. 4. Program Modularisation: Re-factoring techniques and clone detection tools may be used. The individual modules/subsystems are grouped together and any redundancy is removed. 5. Data re-structuring: To transform data, it is likely that specific data transformation tools will have to be developed using lexical analysis techniques. c) Refactoring as practiced in agile development can be considered as a form of continuous reverse and re-engineering as it aims to improve the structure of the software and also to identify common replicated components and replace them with a single component and to eliminate complexity thus making the system easier to change. As agile developers embrace change, they risk weakening the software structure through continuous change and thus by Lehamn s law of increasing complexity must devote extra resources to preserving and simplifying the structure. However, agile practice does not necessary involve re-documentation, nor does it involve transformation of code from one language to another or to a modern language. It would be more accurate to say that refactoring is form of re-engineering. Examiner s Guidance Notes: This question focused on students understanding of reverse engineering and reengineering of software. Many students attempted this question successfully although only a very few students were able to achieve full marks for each part. The weakest answers were to the final part of the question where answers failed to demonstrate evidence of critical thinking. Question 4 a) Explain how as a software project manager, you would estimate and measure the software development productivity of your team. (5 marks) b) Outline five factors that as a software project manager you would need to consider when selecting and building a project team to undertake a new development project. In the case of each factor, discuss relevant issues that need to be taken into consideration to lower any risks. (15 marks) c) A software cost estimation model is an empirical model derived from data from many software projects. These have been widely used and evaluated. Discuss the relevance of software cost estimation models to an agile software project development team in terms of advantages and disadvantages. (5 marks)
A good answer should cover the following: a) The ability to accurately estimate the productivity of a software team relies of having some measurements of the team members past productivity in comparable projects although some estimates can be made of the basis of industry wide measurements of the average of software developers productivity. Productivity can be measured in lines of code produced over a fixed period of time. Other activities can also be measured, e.g. lines of documentation written, tests carried out, bugs resolved, etc. The complexity of work to be undertaken also needs to be considered as does the level of experience and skill set of the team. Where a team has worked together on a number of projects, it may be more helpful to consider them as a single unit. b) Factor Expertise and experience needed for project, especially specific domain expertise Compatibility of team members and their skills Staff Availability and Duration of the project Staff Personalities and attitude to team working Size of team Relevant Issues to lower risk Professional experience of team members, is external recruitment required? And how long will it take to recruit? Recruit new staff in good time Past experience of working together already, complementary skill sets, is training in specialist skills required Consider when staff will be needed and the potential to schedule work on project flexibly, Experience of team working and Team building exercises if new team, clear roles and responsibilities for each team member Good communication channels, use of sub-teams, open and transparent management, regular team meetings c) The COCOMO model may not appear to be directly relevant to a team practicing Agile development with the Agile approach s emphasis on people not process in contrast to the planned based approach which emphasizes the use of well defined, standardised and managed processes. Indeed the first version of COCOMO was based on data from industrial projects mainly in the defence and aerospace domains at a time when Agile development was not widely practised. The later COCOMO II developed in 2000 does address prototype development through its application-composition sub-model and could be applied in the case of Agile development. It estimates software size on the basis of application points which could be related to specific activities undertaken by the agile developers which result measurable outputs, e.g. lines of code, story boards, etc. Cost estimates would help define the project cost and schedule, inform investment decisions and assess any changes in technological solutions; however, the measures that needs to be collected may not be possible to obtain from the agile development practitioners in order to give credibility to their application.
Examiner s Guidance Notes: This question concerned software productivity and software project management. Many students attempted this question successfully although only a few achieved full marks. Many students attempting this question failed to address the estimation of productivity in part a) adequately. Most students were able to outline factors in part b), but many failed to discuss issues related to lowering risks. In answering part c), some students mentioned COCOMO as a cost model or were able to state what agile software development is, but they often failed to make any connection between these. Very few demonstrated knowledge of COCOMO developments.