THE UNIVERSITY OF SUSSEX
BSc SECOND YEAR RESIT EXAMINATION August/September 2017 (A3)
SOFTWARE ENGINEERING
ANSWERS: DO NOT DISTRIBUTE
Copyright By PowCoder代写 加微信 powcoder
Assessment Period:
DO NOT TURN OVER UNTIL INSTRUCTED TO BY THE LEAD INVIGILATOR
Candidates should answer TWO questions out of THREE.
If all three questions are attempted only the first two answers will be marked.
The time allowed is TWO hours. Each question is worth 50 marks.
At the end of the examination the question paper and any answer books/answer sheets, used or unused, will be collected from you before you leave the examination room.
Candidate Number
G6046 Software Engineering
1. CodexInnovationsCorphasprovidedyouwithatextstatementofasetof user requirements for an innovative project they are bidding on. The text statement reads as follows:
“Codex produce one-off highly innovative solutions for complex end user needs. We are producing a software system to manage the day to day operations of a nuclear fusion reactor for our customer British Fusion Ltd.
The job of this software includes the ignition system that starts the reactor by bringing the fuel up to the required temperature and pressure. The operational temperature of the reactor core can reach 100 million °C so any faults in the reactor core can cause extensive damage to auxiliary equipment. Fortunately, the nature of fusion reactors means that they fail safely if the fuel supply is disconnected. The software receives signals from the control room to set the operational temperature and pressure, and this determines the power output. The power output can be adjusted from 0 to 2GWatts. If the required power output is set to 0 for more than 2 minutes, the software needs to initiate the shutdown procedure. If the reactor output exceeds 2GWatts, an emergency procedure needs to activate in the software to alert a human operator to determine whether there is a fault. Ideally the software will give us warning if the power output gets within 5% of the maximum output power over any continuous 5-minute period.
The software needs to have a user interface that can be easily understood by the staff who are well qualified but not necessarily in nuclear physics. The software system also needs to monitor the fuel supply and tell the control room when the fuel supply falls below 30% of the full maximum value. The performance of the reactor can be affected by the purity of the fuel and the condition of the pumping units that supply it to the reactor core. The software will need to advise us of the performance of the reactor in this respect. The customer has expressed an interest in being able to receive reports on a daily basis on the performance so the software is likely to need to assemble that data for us in the form of a spreadsheet.
The software system needs to be written in a language suited to low level interfaces and needs to have a small footprint to enable it to be exhaustively tested for legal compliance and reliability. We think C would be a good choice in this respect. The software system can never be connected to the Internet. Ideally any updates would be carried out using a trusted desktop on the customer’s site. The customer requires a Mean Time Between Failures (MTBF) of no less than 1 month of operation and ideally better than 2 months. The software is intended to run continuously 24 hours a day, seven days a week.
We have a good development team in place with over 150 years of experience in development of innovative software systems. alone has 40 years of experience and is our most senior engineer. is our senior planner and she has 20 years of senior level experience and leads a senior team of 3 people.
John oversees a team of graduate software engineers and developers who have a minimum of 3 years commercial experience each. The work cannot be sub- contracted due to legal constraints placed upon Codex by our customer. The software system will need to have an operational life of 20 years.”
Working from this statement of user requirements:
a) State clearly two mandatory functional requirements and two desirable functional requirements.
2 marks for each requirement. Mandatory requirements should use “shall” and desirable requirements should use “should”.
Example answers include:
• The minimum power output shall be 0 GW.
• The maximum power output shall not exceed 2 GW.
• If the power output is set to 0 for more than 2 minutes, the reactor shall
shut down.
• It should be possible to update the software from a trusted desktop PC.
• The software should produce summary outputs that may be directly
read in Excel.
b) Stateclearlytwomandatorynon-functionalrequirementsandtwodesirable non-functional requirements.
2 marks for each requirement. Mandatory requirements should use “shall” and desirable requirements should use “should”.
Example answers include:
• The MTBF shall be no less than 1 month.
• The MTBF should be no less than 2 months.
• The software shall have no capability for Internet connectivity.
• The software should be written in C (debatable whether this is
mandatory or not, but it is not stated definitively in the user requirements).
c) Giveanexampleofadomainrequirementandexplainwhyneedstobedone with the domain requirement so that it can be acted upon.
A domain requirement is one that cannot be directly translated into functional and non-functional requirements within expert analysis of the problem. There are two obvious domain requirements:
“The software needs to have a user interface that can be easily understood by the staff who are well qualified but not necessarily in nuclear physics.”
“The performance of the reactor can be affected by the purity of the fuel and the condition of the pumping units that supply it to the reactor core. The software will need to advise us of the performance of the reactor in this respect.”
In both cases, the domain requirement needs to be developed to ensure that the requirement is expressed in terms of SMART functional and non- functional requirements.
As part of the planning and management process, a risk analysis is to be conducted. Risks are to be analysed using a standard risk analysis methodology considering the nature of the risk, how likely it is, what can be done about it and how we monitor the on-going level of risk.
d) Presentananalysisoftwotechnologicalrisksinherentinthisproject.
Two possible examples:
Description:
Software reliability. Software needs a MTBF or no less than 1 months and ideally no less than 2 months.
To prove this level of reliability could take more than 12 months. Delaying deployment may have an adverse consequence for the usefulness of the project. Premature deployment may be unsafe.
Extensive unit testing and site acceptance testing required. Emphasis on structure software development methods. Create shadow system that can be used to model faults should they arise.
Monitoring:
Weekly reports of possible faults from both site operators and shadow system operators.
Risk #2 Description:
Software fails to shut down reactor when power output exceeds 2GW causing substantial risk to plant,
Plant could be damaged by over overheating but risk to public small due to fail safe nature of the reactor.
Need multiple redundant components capable of shutting down reactor. Multiple components to be develop by separate teams.
Monitoring:
Weekly safety systems check.
[8 marks] e) Present an analysis of two organisational/people risks inherent in this project.
Description:
Integrity of senior team. This is a long-term project that we are required to support over an extended period.
The most senior engineer may be close to retirement.
Ensure another senior engineer is shadowing . Establish whether could be retained on an on-going consultancy basis. Ensure design work is comprehensively documented.
Monitoring:
Career end planning through line management chain.
Description:
Continuity of development team.
Core development work done by graduates who may only stay with the company for 2-3 years. Getting a new development team member fully integrated into this project could take many months.
Identify high performing team members and offer them enhanced terms of employment / promotion
Monitoring:
Project manager to monitor staffing levels on a weekly basis and identify staffing shortages at the earliest opportunity.
and career development opportunities.
Recruit larger pool of developer staff to cater for unexpected losses.
A detailed analysis of risk forms one part of the quality manual that specifies what types of planning documentation we should prepare when considering a project. Describe four other types of documentation that a typical quality manual specifies we should prepare.
Examples include:
• Organisational information,
• A breakdown of the phases and tasks,
• A list of milestones for each phase, and
• A PERT chart.
• Conflict resolution protocol.
• Peer assessment plan.
Examples should be supported by an appropriate text description.
[12 marks]
Marks (out of 50) 8
% Bookwork 0%
0% 100% 100%
Total % bookwork
Contribution bookwork 0%
0% 12% 24% 44%
/Turn over
G6046 Software Engineering
a) HardRock Software Corp have two projects. One project requires their
development team to produce an innovative new smartphone app game intended to take the world by storm and become a huge hit with people in the age range 18-25. Details are sketchy at the moment but it is said that the game is to allow you to become a virtual international rock star by forming a band, learning to play your instruments and touring the world. Sounds quite glamorous (health warning – it isn’t). The smartphone app is needed on Android first and it may get ported to other platforms later.
The other project is to develop a new sales, accounting and project planning system for a company that makes fluid pumps used in gear boxes for the automotive and aerospace industry. The system is needed to provide an effective means for multiple project managers to monitor income and expenditure and provide high quality reports to customers on the progress of their projects. These are high value projects and are often subject to complex technical requirements.
You are asked to advise HardRock on what would be the most appropriate software development process for each of these projects. Your answer should state the key elements of the development process and must state clearly why you think that process model is suited to each of the two projects.
Key points to make in the answer: Smartphone app:
• Requirements may not be firm. Customer may have requirements that are hard to quantify and attach meaningful metrics to. Customer may shift and evolve requirements as development proceeds and market conditions evolve. Computer gaming is a fast-paced business driven by fashion and trends.
• High degree of creativity and innovation may be required.
• Short development times may be required to deal with hardware
evolution outside of the control of the customer and the development
• However, the customer likely has a fixed budget and a target time to
market, so some effective controls must be in place.
• Suggest Agile, or more likely hybrid plan and Agile based approach, with
frequent short term goals and early code development to get feedback from customer and possible sample end user groups.
Sales, accounting and planning system:
• Requirements are likely well understood and unlikely to evolve over the medium term. Customer likely has a very firm understanding of requirements and can develop meaningful and firm metrics to quantify performance.
• Creativity is not at a premium. Company has likely developed similar products before.
• Customer has fixed budget and a need to develop on time and on budget to meet needs of customer further down the business process chain.
• Likely plan based approach is appropriate.
[15 marks]
b) Using the information in the table below, assuming that the project team will work a standard working week (5 working days in 1 week) and that all tasks will start as soon as possible:
A B C D E F G H I J
Duration Predecessor(s) (Working days)
Description
Requirements analysis 5
Review with customer Initial software design Hardware procurement T est hardware
Final software design Core software coding User interface coding Software integration System integration
15 D 10 C 20 F
10 G,H 10 E,I
Produce a PERT analysis of this project and determine the critical path of the project.
Earliest finish
Critical path?
Earliest start
Latest start
Latest finish
A 5 B 5 C 20 D 30 E 15 F 10 G 20 H 15 I 10 J 10
0 5 0 5 Yes 5 10 5 10 Yes 10 30 10 30 Yes 10 40 25 55 No 40 55 55 70 No 30 40 30 40 Yes 40 60 40 60 Yes 40 55 45 60 No 60 70 60 70 Yes 70 80 70 80 Yes
Critical path is: A, B, C, F, G, I, J
[10 marks]
ii. Calculate the planned duration of the project in weeks.
80 days, 5 days/week gives 16 weeks.
iii. Identify any non-critical tasks and the float (free slack) on each.
Task D: 15 days Task E: 15 days Task H: 5 days
c) WhataretheadvantagesofbuildingapieceofsoftwareusingtheModelView Controller architectural design pattern? Your answer should include a description of what the MVC pattern is, and a practical example of your choosing to illustrate it being used to solve a practical problem.
The answer should address the following points:
Widely adopted architectural design pattern when there a software system has a non-trivial user interface element.
Seeks to partition the software system into:
• Model: the underlying application or business logic
• View: the part that renders the visual appearance of a model
• Controllers: the part that accepts user input and translates into actions for the model
Model: e.g. for a computer game – character models, world model, locations, health points, physics engines. I.e. everything to do with how the game “works”, but nothing about how it is to appear
View: steerable cameras, mobile or tablet? frame rate? Controller: touch? Joystick? Gesture?
Suitable examples include computer gaming and multi-platform development.
• Which parts do we need to redevelop if we decide to port to a new platform?
• Can also customise view and controllers on the fly without affecting the core model
• Each component has a clear and dedicated purpose
Part Marks (out of 50) % Bookwork A 15 50%
Total % bookwork
Contribution bookwork 15%
[15 marks]
/Turn over
G6046 Software Engineering
3. Youhavebeengivenanoutlinespecificationforacomputersystemforusebya company selling “cheap car insurance”. No meerkats are involved …
“A company sells car insurance. Customers can visit the site and enter details so that they can receive a quotation. They can opt to accept the quotation and purchase the insurance if they choose. To get a quotation, customers have to enter some basic personal information including their age, occupation and address (including postcode). Customers can have any number of motor cars and purchase insurance to drive all of them under one simple policy. The cost of insuring any individual motor car is determined by the make of the car, its age, engine capacity in cc (cubic centimetres) and whether it is kept in a garage overnight or on the street. Insurance for any individual car can be “fully comprehensive”, “third party, fire and theft” or “third party only” depending on the level of cover required. The system has information that enables it to combine information about the car and the customer and calculate the total for the customer to insure that particular car. You should not be concerned with how that calculation is performed. The total for any quotation is the sum total of all of the cars that the customer would like insured. A customer can add another driver to any part of the policy. This increases the cost of insuring any individual car by a further 20%, providing the additional driver is over 25 years of age. If a customer wants to insure more than two vehicles, they receive a 10% discount on their quotation and policy if they decide to go ahead and make a purchase. Once a quotation is accepted it is converted into a purchased policy that needs to be stored on the system with all of the relevant details and a date that the purchase was made. If a customer calls the company to follow up on a quotation, the insurance company should be able to recover the quotation details by the customer’s name.”
a) Identify the main object classes involved in the system, and for each class briefly describe the primary attributes and operations associated with it.
• Motorcar represents a single car.
• CarQuote combines data about a car with the cover level required and whether there is a second driver. Different quotes may have the same car with differing levels of cover and differing options on a second driver,
• Customer provides the necessary basic details to identify a customer.
• Quotation links customers to Quotations and allows for an arbitrary number of CarQuotes for one Customer.
• InsuranceSystem represents the system as a whole and allows quotes to be searched by customer name.
• Policy represents quotations that have been sold.
Marking scheme generally 5 marks per class. Students do not need to provide general accessor, mutator or constructor methods.
Class Attributes
Policy Quotation details; Date dateAccepted;
String make;
int capacity; boolean garage;
String occupation; String address; String postcode;
Customer; ArrayList
boolean discount;
void addVehicleToQuote(CarQuote carQuote)
void calculateTotalCost()
Motorcar vehicle; double cost;
Customer secondDriver; char coverLevel
void calculateCost()
InsuranceSystem
HashMap
Quotation findQuoteByCustomerName(String name)
void createNewQuote()
b) Produce a use case to describe the system in use.
Many possible variations. Need to identify some of the core functions and the actor.
c) Explainthedifferencebetweenunittesting,componenttestingandsystem level testing.
System level testing: testing the system as a whole, looking at system level inputs and outputs and testing whether the software as a whole is meeting the requirements set out for it. May involve the customer or end users.
Unit testing involves testing individual elements of the software. Typically organized using unit testing software tools such as Unit. Intended for use by software developers as testing is concerned with inner workings of software components not necessarily visible to the end user.
Component testing involves testing sets of unit classes operating together to evaluate one aspect of the functionality of the whole system.
[10 marks]
d) Define an appropriate system of documentation for recording system-level testing. Define 3 tests that might be performed on this system.
[25 marks]
Appropriate system level documentation example might look like this:
Test Description Reference
Example Test input A
1 Add customer with no age
Expected output
Actual output
If fail, action required
Fix method1()
All data except age
% Bookwork 0%
Invalid Invalid
Valid Fail
Try to recover customer policy
2 valid policies and customer name
2 records recovered
3 Check discount
Part Marks (out of 50)
程序代写 CS代考 加微信: powcoder QQ: 1823890830 Email: powcoder@163.com