Faculty of Engineering and Information Technology

Subject Outline Subject name: Subject Number: Credit Points: Subject Coordinator: Semester/Year: Prerequisites: Corequisites: Antirequisites:

Software Engineering
48440 6 Xiaoying Kong Spring 2009 48024 Object-oriented Design none none

Presentation:

Software Engineering combines coverage of new concepts and material, with a problem based learning approach. The new material is covered in a series of required readings and lectures that focus on general techniques and issues and matching workshops during which the students apply these techniques to a project. The lectures are provided to introduce the students to the various concepts and emphasise the most important elements. The students are expected to follow-up these class sessions with directed reading and study which extends this knowledge. This reading then forms the basis of discussions in the following week. In parallel with the formal content of the subject, the students work on a major project. The students are provided with the specification of a software system. During the semester there are deadlines to be met for each part of the problem (known as work products) that are specified by the client. There are also techniques to be used in the problem which the client has specified. The client is, of course, open to reasonable negotiation. The students undertake the projects in groups. The organisation of the groups will be a matter for each group to decide. The assignments will be carried out as a form of group work. It is a form of group work because each member will, in general, be personally responsible for a component of each work product. Subject activity time distribution: Lecture: 19.5 Hours Tutorial: 19.5 Hours It is assumed that students are familiar with:

Assumed Knowledge:

Subject Outline

48440 Software Engineering

Page 1 of 17

-Concepts of software life-cycles and software processes -Object-oriented analysis and design principles and UML notation -Software programming
Handbook Entry:

The aim of this subject is to develop students' understanding and skills related to how an engineering software project should be managed and the various pool of techniques which are available to a software engineer or software project manager. The objectives are to bring students to the point where they are competent to engineer moderately complex engineering software systems as members of a software development team. On completion of this subject, students should [Obj-01] be familiar with the issues and principles of software engineering [Obj-02] have an appreciation of the different phases in the software life cycle [Obj-03] be competent in applying techniques of [a]software analysis, [b]design, [c]coding and [d]testing. This subject contributes to the following course objectives: -Orient and support students as learners in the University including -Developing academic literacy skills -Gaining an overview of professional engineering and how it is informed by academic experiences and workplace experiences -Developing information literacy skills -Beginning to develop a personal Portfolio -Starting to build the academic foundations of professional engineering education -Starting to acquire equipment mastery, and computer and programming skills required for the academic & workplace experiences The following material will be covered during this subject: -software development processes and process models, agile methodologies: including waterfall model, spiral model, prototype, extreme programming -software project planning, software estimation and costing, metrics , scoping and estimation techniques -software specification: problem statements, requirements elicitation and analysis, requirements specification, UML applications -software design: design approaches, OVID design methodology -software implementation: languages, language selection, implementation, HTML -verification, validation and testing: test plans, requirements traceability, audits, reviews and walkthroughs Software configuration management; software maintenance; Development environment and CASE tools, software standards.

Objectives:

Contribution:

Topics:

Subject Outline

48440 Software Engineering

Page 2 of 17

Assessment:

IMPORTANT NOTE: This should be read in conjunction with the information on assessment in both the student guide and in the UTS Coursework Assessment procedures and policy manual. The details of all aspects of assessment (including, but limited to, submission processes, late penalties, referencing, attendance, etc.) are governed by the details in these associated documents except where explicitly over-ridden by the following information.

Assessment tasks
The assessment for the subject revolves around the major project and an oral exam at the end of semester. The project will be carried out in groups, and have various deliverables during the semester. The deliverables for the subject add up to 100 marks, but this mark is scaled by a factor derived from the oral exam (see the description of the oral exam). Finally the mark is rounded to the nearest 5 marks (this rounding acknowledges that accuracy of marking beyond 5% is not practical in a subject such as this). The deliverables are as follows: Software Requirements Specification: System Design Specification: Acceptance Testing Report: Reflections and project log 35 marks 35 marks 25 marks 5 marks

Total

100 marks

Final Mark total x oral exam scaling factor NOTE: Full details of each component will be discussed during the class sessions.

Assessment task 1 Assessment Title: Software Requirements Specification

Percentage of Final Grade Minimum mark required Date Provided: Date Due: Typical Duration for Feedback Assessed by Submission: Objective References:

35 marks 30%
31 July 2009 3 Sept Thursday 2009 2 weeks

Subject tutors
UTSonline / digital drop box

[Obj-01], [Obj-02], [Obj03-a]

Subject Outline

48440 Software Engineering

Page 3 of 17

Description:

Students will be provided with a document that defines the User Requirements for a Tutor Web System (TutorMe). This document is to be used as the basis for developing a more technically precise System Requirements Specification that can later be used for detailed design / implementation of the TutorMe. The requirements defined in the User Requirements Document are admittedly not perfect. Students will be required to undertake an initial analysis of the user requirements to uncover ambiguities or inconsistencies. Students will then undertake the necessary requirements elicitation activities to ensure that the issues / problems identified are resolved. Students will then document the requirements, analysis models and other artifacts into a System Requirements Specification.

Assessment task 2 Assessment Title: System Design Specification and User Interface Development
Percentage of Final Grade Minimum mark required Date Provided: Date Due: Typical Duration for Feedback Assessed by Submission: Objective References:

35 marks 30%
31 July 2009 8 Oct, Thursday 2 weeks

Subject tutors
UTSonline / digital drop box [Obj-01], [Obj-02], [Obj03-b,c]

Description: Using the System Requirements Specification for TutorMe that was derived in Assignment 1, students will be required to design and develop the user interface (UI) for TutorMe. The design will be documented in a System Design Specification. The user interface will be developed using HTML. Students are to ensure that the design and UI that they produce are correct, consistent and complete.

Assessment task 3 Assessment Title: Acceptance Testing Report

Percentage of Final Grade Minimum mark required Date Provided:

25 marks 30%
31 July 2009

Subject Outline

48440 Software Engineering

Page 4 of 17

Date Due: Typical Duration for Feedback Assessed by Submission: Objective References:

29 Oct Thursday 2009 2 weeks

Subject tutors
UTSonline / digital drop box [Obj-01], [Obj-02], [Obj03-c,d

Description: You must undertake full acceptance testing of the provided system to determine whether it meets the users requirements. The results of this testing should be documented as a testing report.

Assessment task 4 Assessment Title: Reflection and project log

5 marks 30%
31 July 2009 29 Oct Thursday 2009 2 weeks Percentage of Final Grade Minimum mark required Date Provided: Date Due: Typical Duration for Feedback Assessed by Submission: Objective References

Subject tutors
UTSonline / digital drop box or Blackbox, Level 24 Building 1

[Obj-01], [Obj-02]

Description: (1 set per student) These reflections should consider the approach which you adopted, the mistakes which you made, the successes and problems with your group work, what things you would do differently next time and (most especially) what you have feel you have learnt from the subject. You must also keep a project log book throughout the semester. This log book should detail all work carried out, meetings, reflections, draft designs, rejected possibilities, etc. It should provide a detailed record of the work that you have carried out for the subject.

Assessment task 5 Assessment Title:

Date Percentage of the subject Approximate time to complete: Minimum mark required Assessed by

Oral exam
Scheduled during exam period Scaling factor 20 minutes (not applicable) Subject staff

Subject Outline

48440 Software Engineering

Page 5 of 17

Objective Reference:

[Obj-01], [Obj-02], [Obj-03a,b,c,d]

Description: The oral exam will be carried out during the examination period at the end of the semester. It will be of approximately 20 minutes duration and will contain both general software engineering questions (such as "describe (and explain) the stages of the spiral model of the software development process") and questions specific to your project. Based on this exam a scaling factor will be applied to your overall project mark. An initial scaling factor of 1.0 will be assigned. If, however, you demonstrate an understanding which is not consistent with your project mark, then the scaling factor may possibly be increased (if your understanding exceeds that demonstrated in your project) or decreased (if you demonstrate a poorer understanding). Note that this means that two very different students may have the same scaling factor - because their result in the oral exam was consistent with the level of understanding indicated by their project mark. In other words, the oral exam is used to adjust your project mark so that your subject mark accurately reflects your individual understanding rather than that of the group overall. Full details are given in an Appendix.

Minimum essential requirements for students

In order to pass the subject, you must > complete and submit each of the Assessment tasks 1, 2, 3 and 4; and > receive 30% or more of the marks for each of Assessment tasks 1, 2, 3 and 4; and > attend oral exam during scheduled exam period > earn an overall total of 50 marks or more for the subject.

There is NO supplementary exam for this subject.

Assessment procedures and advice

Information on general Faculty policy about assessment procedures etc. is provided in the Faculty Student Guide. The following information is provided in addition to this, and

Subject Outline

48440 Software Engineering

Page 6 of 17

covers any variations to the defaults in the course guide.

Assessment Modification
If you feel that the assessment schedule outlined is unlikely to give you the opportunity to demonstrate your knowledge (for example, if you have particular difficulty with oral examinations or group work) then you should contact the lecturer or subject coordinator before the end of week 2. If appropriate, an alternative assessment schedule will be organised which is better suited to your needs. For example, there may be a specific reason why you are particularly uncomfortable with oral examinations. In such a case, you may wish to negotiate an alternative method of assessment (such as an assignment) that satisfies the same objectives as the oral exam. Requests for a change in assessment later in the semester (such as informing your tutor, at the end of the semester, that you are not comfortable with an oral exam) will not be considered. The only exception will be where the request is strongly supported by evidence of a change in circumstances that could not have been foreseen at the beginning of the semester.

Assignment Extensions and Late Submissions

Where you feel that an extension is warranted, you should see your tutor or lecturer a minimum of three days prior to the normal due date. Any request must be appropriately supported by appropriate document such as a medical certificate or a letter from your employer. Any requests for extensions after this time will be refused except in exceptional circumstances. Excuses (documented or otherwise) will not be accepted after the event. In particular, the following excuses will not be considered as adequate: We have had assignment in other subjects to complete The due dates for all assignment should be known well in advance. You should be able to plan your time appropriately to avoid this problem. My group members have not been pulling their weight Part of the subject is about being able to manage group work suitably, including planning ahead for possible group difficulties. You should have discussed difficulties with your tutor well before the assignment was due. Further, you should still be able to submit evidence of your own work. This evidence will need to include your project log-book If this is missing then your claims of group problems will not be considered. My work has been really busy; I was sent overseas/interstate/etc. You are expected to be able to make a suitable commitment to the subject, including planning ahead to avoid possible work conflicts. If work becomes a particular problem, and this could not have been foreseen, then you should talk to the subject

Subject Outline

48440 Software Engineering

Page 7 of 17

coordinator who will discuss the possibility of a late withdrawal from the subject (only if warranted).

Groupwork and Assignment Submission

The major projects in this subject are carried out in groups. The primary reason for this is that development of software systems is inherently a team activity, and as such the students are required to develop and demonstrate not only technical skills, but also group skills. We recognise that group work can potentially provide difficulties for some students. Because of this we place certain requirements on the ways in which you work as groups as well as providing mechanisms for alleviating potential problems. 1. The front page of EVERY project component submission MUST be the standard Faculty Assignment submission cover page. It should also clearly identify the name, student number, and email address of each member of the group. 2. The second page of every submission MUST indicate the contributions of each member of the group and the number of hours spent on the project. A statement such as "all members contributed equally to all areas" is not acceptable. Rather you MUST state the specific work completed by each member. Where the above information is missing from the submission, you will be penalised 1% of the subject mark the first time, another 2% the second time, another 3% the third time, etc. 3. Every student is required to maintain an individual work log. This work log should be in the form shown in the appendices. 4. All assignments should be submitted directly to your tutor. All assignments will be retained by the tutor for collection.

Late Submission
Any assignments submitted after the due date and time will be considered to be late and will be penalised at 10 % of the allocated marks per day (i.e. an assignment which received a mark of 75%, would be changed to 60% if 2 days late). It will not be accepted for assessment if more than 10 days late. The only possible exception to this will be in the case of illness or misadventure that must be documented. If this occurs you must see your tutor or lecturer immediately. Excuses (documented or otherwise) will not be accepted after the event.
Online Support: The subject makes heavy use of UTSonline resources. In order

Subject Outline

48440 Software Engineering

Page 8 of 17

to gain access to these resources you should go to the following URL: http://online.uts.edu.au/. It is expected that every student will check UTSonline every week. IMPORTANT administrative details will be posted when appropriate. Not checking UTSonline for appropriate messages will not be considered an acceptable excuse for lack of knowledge of assessment information, timetabling changes etc.

References:

Text Books
- Pressman, Roger. S (2005), Software Engineering - A practitioner's approach, McGraw Hill, 6th Edition. - Sommerville. J (2007) Software Engineering, Addison Wesley, 8th Edition. - Pressman, Roger. S, Lowe, David (2008) "Web Engineering A Practioner's Approach" McGraw-Hill, c2008 ISBN 0073523291 / 9780073523293

References
- David Gustafson, Shaum's outline of theory and problems of software engineering, McGraw-Hill, c2002. ISBN 0071377948 - Behforooz & Hudson (1996), Software Engineering Fundamentals, Oxford Uni Press, ISBN: 0195105397 - Dave Roberts, Dick Berry, Scott Isensee, John Mullaly, Designing for the User with OVID: Bridging User Interface Design and Software Engineering, Macmillan Technical Publishing 1998, ISBN 1578701015

UTS-Online
UTSonline contains copies of the subject notes and lectures, discussion lists, subject announcements, and other resources.

IEEE Software Standards

Copies of these are available in the UTS library (refer to http://standards.ieee.org/catalog/software.html) 610.12-1990 IEEE Standard Glossary of Software Engineering Terminology (Revision and redesignation of IEEE Std 7291983) 730-1998 IEEE Standard for Software Quality Assurance Plans 730.1-1995 IEEE Guide for Software Quality Assurance Plannning (Revision and redesignation of IEEE Std 983-1986) 828-1990 IEEE Standard for Software Configuration Management Plans

Subject Outline

48440 Software Engineering

Page 9 of 17

829-1983 (R1991) IEEE Standard for Software Test Documentation 830-1998 IEEE Recommended Practice for Software Requirements Specifications 982.1-1988 IEEE Standard Dictionary of Measures to Produce Reliable Software 982.2-1988 IEEE Guide for the Use of IEEE Standard Dictionary of Measures to Produce Reliable Software 990-1987 (R1992) IEEE Recommended Practice for Ada As a Program Design Language (This standard has been withdrawn) 1002-1987 (R1992) IEEE Standard Taxonomy for Software Engineering Standards 1008-1987 (R1993) IEEE Standard for Software Unit Testing 1012-1998 IEEE Standard for Software Verification and Validation 1016-1987 (R1993) IEEE Recommended Practice for Software Design Descriptions 1016.1-1993 IEEE Guide to Software Design Descriptions 1028-1997 IEEE Standard for Software Reviews 1042-1987 (R1993) IEEE Guide to Software Configuration Management 1044-1993 IEEE Standard Classification for Software Anomalies 1044.1-1995 IEEE Guide to Classification for Software Anomalies 1045-1992 IEEE Standard for Software Productivity Metrics 1058.1-1987 (R1993) IEEE Standard for Software Project Management Plans 1059-1993 IEEE Guide for Software Verification and Validation Plans 1061-1992 IEEE Standard for a Software Quality Metrics Methodology 1062-1993 IEEE Recommended Practice for Software Acquisition 1063-1987 (R1993) IEEE Standard for Software User Documentation 1074-1997 (Approved Draft) IEEE Standard for Developing Software Life Cycle Processes 1074.1-1995 IEEE Standard for Developing Software Life Cycle Processes 1175-1991 IEEE Standard Reference Model for Computing System Tool Interconnections Includes STL Language

Subject Outline

48440 Software Engineering

Page 10 of 17

Interconnection Profile Form in ASCII format. 1209-1992 IEEE Recommended Practice for the Evaluation and Selection of CASE Tools 1219-1998 IEEE Standard for Software Maintenance 1220-1994 IEEE Trial-Use Standard for Application and Management of the Systems Engineering Process 1228-1994 IEEE Standard for Software Safety Plans 1233-1996 IEEE Guide for Developing System Requirements Specifications 1295-1993 IEEE Standard for Information Technology-X Windows System-Modular Toolkit Environment (MTE) 1298-1992 (AS 3563.1-1991) Software Quality Management System, Part 1: Requirements 1320.1-1998 IEEE Standard for Functional Modeling Language-Syntax and Semantics for IDEF0 1320.2-1998 (Approved Draft) IEEE Standard Conceptual Modeling Language--Syntax and Semantics for IDEF1F1X97 (IDEFobject) 1348-1995 IEEE Recommended Practice for the Adoption of Computer-Aided Software Engineering (CASE) Tools 1362-1998 (Approved Draft)) IEEE Guide for Information Technology--System Definition--Concept of Operations Document 1420.1-1995 IEEE Standard for Information Technology-Software Reuse--Data Model for Reuse Library Interoperability: Basic Interoperability Data Model (BIDM) 1420.1a-1996 IEEE Guide for Information Technology-Software Reuse-Data Model for Reuse Library Interoperability: Asset Certification Framework 1430-1996 IEEE Guide for Information Technology--Software Reuse-Concept of Operations for Interoperating Reuse Libraries 12207:2008(E) ISO/IEC Systems and Software Engineering Software Life Cycle Processes J-STD-016-1995 EIA/IEEE Interim Standard for Information Technology Software Life Cycle Processes Software Development Acquirer-Supplier Agreement (Issued for Trial Use)
Subject Staff:

Subject coordinator and lecturer: Dr. Xiaoying Kong Phone: 95142445 Email : xiaoying.kong@uts.edu.au Office / consultation: 1/2226,see UTSonline for consultation times Tutor: Tran, Tich Phuoc Email: tiptran@it.uts.edu.au

Subject Outline

48440 Software Engineering

Page 11 of 17

Contacting staff Please see the lecturer in lectures or consultation time. Please see your tutor in tutorial sessions. If you are unable to come, then please email to staff. Any email correspondence with staff should include [48440SE] in the subject line. This enable staff to deal with all SE (Software engineering) related correspondence in an efficient manner. Failure to include [48440SE] could result in your email being ignored. Staff will aim to respond within two working days. The response to your email can take various forms as follows: - A personal response for administrative issues of a personal nature - A posting on UTS Online if the staff member feels that the answer to your query could be of value to the whole class

Assessor:

Dr Tom McBride Students are reminded of the principles laid down in the Facultys Statement of Academic Integrity - Good Practice and Ethics in Informal Assessment found at; <wiki.it.uts.edu.au/start/Academic_Integrity>. The Universitys rules regarding academic misconduct can be found at; <www.gsu.uts.edu.au/rules/16-2.html> Assignments in this Subject should be your own original work. The inclusion in assessable work of any material such as code, graphics or essay text obtained from other persons or sources without citation of the source is plagiarism and is a breach of University Rule 16.2.2. Any collaboration with another person should be limited to those described in the Acceptable Behaviour section of the Statement of Academic Integrity. Similarly, any group work should be the result of collaboration only within the group. Any infringement by a student will be considered a breach of discipline and will be dealt with in accordance with the Rules and By-Laws of the University. Students are not to give to or receive from any other persons copies of their assessable work in any form (hard copy or an electronic file). To do so is 'academic misconduct' and is a breach of University Rule 16.2.2. That is, assisting other students to cheat or to act dishonestly in a submitted assignment. Accidental submission of another students work as your own is considered to be a breach of University Rule 16.2.2 in that

Academic Standards:

Subject Outline

48440 Software Engineering

Page 12 of 17

you are acting dishonestly since you should not have a copy of another student's work. The Faculty penalty for proven and serial misconduct of this nature is zero marks for the Subject. For more information go to; <wiki.it.uts.edu.au/start/Academic_Integrity >.
ELSSA:

If you think you need help with your English, or feel unable to express yourself correctly in assignments, contact the English Language Study Skills Assistance (ELSSA) Centre, Level 18 Tower Building, Broadway, phone 9514-2327. Academic Liaison Officers (ALO) are academics who help students with special needs (students with temporary or permanent disabilities, students with language problems who are from non-English speaking backgrounds, or students who are primary carers). If you require assistance with assessment tasks and exams, the Faculty ALO will help you negotiate special conditions with your Lecturers. For example; the use of a dictionary and extra time in exams if your first language is not English (only available for your first two years at UTS) tests and exams printed in larger type if you have a vision impairment use of a lap-top if you cannot write because of an injury extra time to complete assignments if your studies have been disrupted by illness or disability. If you require it, the ALO will talk to all your Lecturers so that you don't have to explain your circumstances to each of them individually. Privacy is important and personal information is only passed on to university staff on a "need to know" basis. Students with disabilities are encouraged to contact the Special Needs Service for advice before contacting the ALO. The contact details for the Faculty ALOs can be found at <www.ssu.uts.edu.au/sneeds/services/assessment/alo.html>

ALO:

Student support:

Information regarding support available to students undertaking this Subject is available at; <wiki.it.uts.edu.au/start/Student_Support> Support for learning and teamwork skills is available at; <www.bell.uts.edu.au> and <www.star.uts.edu.au> If you are experiencing problems while undertaking this Subject then help and assistance are available both within the

Having problems?

Subject Outline

48440 Software Engineering

Page 13 of 17

Faculty and also within the wider University. More information is at; <wiki.it.uts.edu.au/start/Student_Support >. You should attempt to resolve the problem through the following chain: 1. Tutor, 2. Lecturer, 3. Subject Coordinator, 4. Head of Department, and finally 5. the Responsible Academic Officer, (Associate Dean Teaching and Learning)

Student Attendance
The Faculty of Engineering and Information Technology expects that students will attend all scheduled sessions for a subject in which they are enrolled.

Subject Schedule
Week Commencing Week Number

Lecture 10am-11:20am Friday

Tutorial 11:30am13:00pm Friday

Deadlines

27 July 3 Aug 10 Aug 17 Aug 24 Aug 31 Aug

1 2 3 4 5 6

A: Intro, Admin, Subject Overview, SW engineering concepts B: Development processes; Software analysis-1 C: Software analysis-2 D: Software design -1 E: Software design -2 F: Implementation, languages, environments, etc.

Req. Spec Req. Spec Req. Spec Req. Spec Design

Software Req. Spec Due 5pm, 3 Sept Thursday

7 Sept 14 Sept 21 Sept 28 Sept 5 Oct

7 8 9

G: V&V, traceability, audits, reviews, walk-throughs H: Maintenance, SW configuration management Tutorial Break Vice Chancellors Week I: Development models. Agile methodologies

Design Design

10

Testing

System Design Due 5pm, 8 Oct Thursday

12 Oct 19 Oct 26 Oct

11 12 13

J: Software planning , software scoping and estimation, metrics K: Development environment and CASE tools L: Risk management, software standards

Testing Testing Acceptance Testing Report; Reflection/

Subject Outline

48440 Software Engineering

Page 14 of 17

log Due 5pm, 29 Oct Thursday 2 Nov 9 Nov 14 M: Review Oral exam

Appendix
App A: Example Student Work Log Entry
The following is an example extract from a student work logbook. Note that EVERY student must maintain his or her own logbook. This book will be inspected at regular intervals during the semester and will be used to assist in the marking of the final report and during the oral exam. Project Log & Reflections Joshua Weir 14/3/02 11:30-12:30 We conducted a project planning workshop in which the topics given to us in the tutorial were discussed. I had already found an IEEE standard for project planning but much of the information included in this standard was not needed for our project. I wonder if the SRS and testing will be an adaptation of the IEEE standard also? We designated Tamati to be the team leader because he shows good leadership skills through communication and organization. Rob was assigned the role of scribe during meetings. There was indecision between Iain and Rob about what software process we should use for this project. Rob thought the spiral method would be most efficient and Iain wanted to use his own adaptation that he developed. After much indecision a hybrid adaptation of the two methods was developed. The work breakdown was discussed, it was decided that each of the major components will be worked on by the team as a whole during the group meetings/workshops then the major sections of each of the tasks/activities will be divided up and completed individually. Prior to the group meeting I was unaware that the code will be developed be a contracting agency as I was under the conclusion that we would develop and code the entire system, this was confirmed during the meeting.

App B: Oral Examination Information

App B.1 Logistics When The oral exams are scheduled in 20 minute increments, though the actual time may be more or less than this depending upon your particular answers. The specific dates and times will be announced during the final few weeks of the semester. How You should arrive at least 10 minutes prior to your appointed date and time, and wait outside the glass doors on Level 22, Building 1. If you have not arrived for your exam

Subject Outline

48440 Software Engineering

Page 15 of 17

within 5 minutes after the scheduled time, then you will be recorded as a no-show. The same conditions will be applied as for missing formal examinations. The purpose of the examination is to assess your level of understanding of the software engineering process as covered by this subject. You will be allowed considerable leeway in achieving this. The examiner will select at least three of four questions which ensure coverage of an understanding of the need for process in software engineering, the role of different tools and/or methodologies, how the process affects the quality of the end result, and the pragmatics of actual development. These questions will be used to trigger a discussion. This discussion should elicit both your understanding of the underlying concepts and also how these are applied in the context of the specific project you carried out. You are expected to understand both your own work as well as that of the other members of your group i.e. an answer of but I didnt do that part of the project is not an acceptable answer. The following might be a typical discussion (which shows a rather poor understanding): Tutor: Can you tell me a little about formal methods, and how they might be used in the development of software Student: Well, Z is a formal method and so is VDM. You use them to define sets and relationships Tutor: Rather than specific examples, can you tell me what defines a formal method Student: It is a method or process that you formalise, so you have rules about what you do. It makes sure you do it properly and dont get confused. Tutor: So would OO class diagrams be considered a formal method? Student: Uh I think so. It is important to keep in mind that the examiner is trying to evaluate your level of understanding, not your communication skills, personality, or general knowledge. App B.2 Outcome The outcome of the oral exam is a final mark for the subject. This final mark will be the project mark after adjustment based on the oral exam. Essentially, we begin by assuming that the project mark is an accurate reflection of your level of understanding in the subject. If, however, you are able to demonstrate that you understand the material much better that your mark indicates (for example, because you were working with a poor group) then we will scale your mark upwards. To illustrate, you might have got a project mark of 60, but demonstrate an excellent understanding of the subject, and therefore have your mark scaled up to 75. On the other hand, if you demonstrate an understanding that is poorer than indicated by your project (for example, because you relied too heavily on your other group members) then your mark will be scaled down. Where you mark is scaled to less than a pass mark, you will be given the opportunity to discuss this with the subject coordinator. Note: You may demonstrate an understanding which is normally sufficient to pass the subject, but have a project mark which is extremely low (i.e. indicates very little work, or very poor understanding during the semester). In this case the project mark will remain, but you will be referred to the subject co-ordinator, who will negotiate with you the possible opportunity to complete the project to a sufficient level to obtain a pass.

Subject Outline

48440 Software Engineering

Page 16 of 17

(Typically this will need to be completed within several weeks from the date of the exam).

Subject Outline

48440 Software Engineering

Page 17 of 17