Skip to navigation | Skip to main content | Skip to footer

COMP20340: Software Engineering (2009-2010)

This is an archived syllabus from 2009-2010

Software Engineering
Level: 2
Credit rating: 20
Pre-requisites: COMP10081 and COMP10092
Co-requisites: COMP20340-Supplementary
Lecturers: Chris Harrison, Kung-Kiu Lau, John Sargeant, Robert Stevens, Liping Zhao
Course lecturers: Chris Harrison

Kung-Kiu Lau

John Sargeant

Robert Stevens

Liping Zhao

Additional staff: view all staff
w0 WORKSHOP ROSCOE 1.007 Thu 09:00 - 15:00 -
w0 WORKSHOP ROSCOE 1.009 Thu 09:00 - 15:00 -
w0 WORKSHOP ROSCOE 1.010 Thu 09:00 - 15:00 -
w0 WORKSHOP ROSCOE 2.2 Thu 09:00 - 15:00 -
w0 Lecture ROSC B Wed 10:00 - 12:00 -
w0 WORKSHOP ROSCOE 1.009 Wed 12:00 - 16:00 -
w0 WORKSHOP ROSCOE 1.010 Wed 12:00 - 16:00 -
w0 WORKSHOP ROSCOE 2.2 Wed 12:00 - 16:00 -
w0 WORKSHOP ROSCOE 2.3 Wed 12:00 - 16:00 -
w0 Lecture ROSC B Thu 15:00 - 17:00 -
Sem 1 w1-5,7-12 Lecture 1.1 Mon 10:00 - 11:00 -
Sem 1 w1,3,5,8,10,12 WORKSHOP IT407 Wed 09:00 - 11:00 G
Sem 1 w1,3,5,8,10,12 WORKSHOP IT407 Fri 09:00 - 11:00 I
Sem 1 w1,3,5,8,10,12 WORKSHOP IT407 Fri 11:00 - 13:00 H
Sem 1 w1,3,5,8,10,12 WORKSHOP IT407 Mon 13:00 - 15:00 F
Sem 1 w2,4,7,9,11 Lab G23 Wed 09:00 - 11:00 G
Sem 1 w2,4,7,9,11 Lab UNIX Fri 09:00 - 11:00 I
Sem 1 w2,4,7,9,11 Lab UNIX Fri 11:00 - 13:00 H
Sem 1 w2,4,7,9,11 Lab UNIX Mon 13:00 - 15:00 F
Sem 1 w8,10 Lecture LF15 Wed 12:00 - 13:00 extra
Sem 2 w19-26,30-33 Lecture 1.1 Thu 14:00 - 15:00 -
Sem 2 w19,21,23,25,30,32 WORKSHOP Collab Fri 09:00 - 11:00 G
Sem 2 w19,21,23,25,30,32 WORKSHOP Collab Wed 10:00 - 12:00 H
Sem 2 w19,21,23,25,30,32 WORKSHOP Collab Mon 10:00 - 12:00 I
Sem 2 w19,21,23,25,30,32 WORKSHOP Collab Fri 11:00 - 13:00 F
Sem 2 w20,22,24,26,31,33 Lab G23 Fri 09:00 - 11:00 G
Sem 2 w20,22,24,26,31,33 Lab G23 Mon 10:00 - 12:00 I
Sem 2 w20,22,24,26,31,33 Lab G23 Wed 10:00 - 12:00 H
Sem 2 w20,22,24,26,31,33 Lab G23 Fri 11:00 - 13:00 F
Assessment Breakdown
Exam: 45%
Coursework: 25%
Lab: 30%
Degrees for which this unit is core
  • Artificial Intelligence BSc (Hons)


The development of software systems is a challenging process. Customers expect reliable and easy to use software to be developed within a set budget and to a tight deadline. As we come to depend upon software in so many aspects of our lives its increasing size and complexity, together with more demanding users, means the consequences of failure are increasingly severe. Experience from nearly 40 years of software engineering has shown that programming ('cutting code') is only one of a range of activities necessary for the creation of software systems that meet customer needs. In fact, many industry experts estimate that on a typical project only 20% of the total development time will be spent in coding. The rest of the time is spent on: planning and acquiring resources for the project; investigating the business and technical contexts for the system; eliciting and documenting user requirements; creating a design for the system; and integrating, verifying and deploying the completed components. This course unit builds on the programming skills you have gained in the first year, to provide you with an understanding of the major challenges inherent in real-scale software development, and with some of the tools and techniques that can be used in their attainment.

Since software engineering is a subject best learned hands-on, this is a project-based module that involves less traditional lecturing than usual. Instead, relevant skills will be acquired during fortnightly two-hour workshops, supported by a weekly one hour lecture. The understanding gained will be practiced through individual and group project assessments.

Assessment Breakdown

Exams: 45%; there is one exam at the end of each semester with both totaling 45% of the marks for the course.
Coursework: 25%; 20% of the total is made from four mid-semester tests, two in each semester. Five percent of the total marks come from the material in week nought and the second year tutorials that is associated with COMP20340.
Lab: 30%; the two semester's labs come to 30% of the total marks for the course.


This course unit aims to provide an introduction to the topic of software engineering, covering (almost) all the aspects of system development.
Students will be introduced to disciplines such as project planning, requirements specification and business modelling and will learn how to produce artefacts such as use cases models and domain models. The course will use the Unified Modelling Language (UML), a {de facto} industry standard notation, to document and facilitate the software engineering process.

In semester one workshops and lectures will give an overview of these techniques. The team-based laboratory exercises will take students through the basics of planning, requirements gathering, design and implementation. The second semester builds on the first, providing more depth in some topics and introducing others such as software validation and design patterns. The laboratory exercises in semester two will take the prototype software produced in semester one and iteratively extend its functionality, in order to give experience of changing software needs, and of testing, software quality issues and integration.

Learning Outcomes

On completion of this course unit a student should:

1) Be aware of some of the risks inherent in a software project and to be aware of some of the different process models that can be used to organise and control the construction of large software systems. (A, B)

2) Be able to plan resource requirements for simple software projects, and to generate from these plans expected development timings and completion dates. (A, B)

3) Be able to apply basic interview techniques for requirements elicitation for functional and non-functional requirements; to document the results as a specification using standard UML notations. (A, B)

4) Appreciate how different styles of user interaction support the cycle of execution and evaluation in using an application. The student will be able to combine an understanding of human factors issues with requirements to choose and justify an overall screen design. (A, B)

5) Have an understanding of good software design principles, and be able to apply current best practices to construct software designs that adhere to both functional and non-functional requirements. (A, B)

6) Students will learn that three basic modelling aspects: structural, dynamic and functional are involved in software engineering. this is known as \emph{multiperspective modelling}. The structural model represents the static relationship among classes and objects in a system; the dynamic model represents the behaviours of the objects; the functional model shows the computational flows among the objects.

7) Understand how the architecture of a system needs to reflect both the functional and non-functional needs of that system and generates the hardware requirements to support the software system. Students will learn how the architecture of a system needs to accommodate issues such as distribution, as well as issues such as licencing. (A,B)

8) Understand how software validation helps to make a software system meet user's expectations and how software verification ensures that it meets its specifications. (A, B, C)

9) Have an understanding of the means by which individual software components, produced by a team of developers, are integrated to form a larger whole, and be able to make use of tools that can support this process. (A, B, C)

10) Have experience of some of the challenges inherent in working as part of a software team, and of resolving the difficulties that arise. (D)


Software Methodologies and software project planning

Students will be exposed to the basics of project planning for software engineering. This will include an awareness that different methodologies exist that describe and organise the various parts of the process of developing software. The widely used Unified Process (UP) will be used as an example. Project planning approaches are used to tie the stages and phases of the development process to resources within the project.

Software Requirements elicitation

Requirements gathering forms the foundation for any software project. Students will learn about the basic techniques of interview used in requirements gathering. Students will learn the difference between functional and non-functional requirements and how this material is used and updated throughout the production of software. Students will learn the limitations and difficulties of this soft, but all too hard, technique.

Software Requirements specification: Use Cases and Activity Diagrams

Once gathered, requirements have to be organised and structured in an effort to build a model of the tasks to be performed by an application. Students will learn about UML Use Cases and Activity Diagrams as a means of documenting and specifying the requirements of the software. This is the start of the process of moving from a specification of what the users do to a specification
of what the system does.

Requirements specification: domain modelling

Requirements specify what either users do or software needs to do. It is also important to understand the domain in which the software must operate. Students will learn about domain modelling, which will stress that although the UML notation (class and interaction diagrams) is the
same as that used for software design, domain modelling is a distinct activity from software design.

Software Design class Modelling

The focus will move from modelling the domain to modelling the classes of the software itself. Students will learn about design classes, and the relationship between these and domain classes. Students will have seen the subset of UML class diagram notation that is commonly used in practice, and have seen how requirements specified, primarily in Use Cases, leads towards a system specification.

Dynamic modelling

With domain and design modelling students have encountered \emph{static modelling} of both the domain in which the software will operate and the software itself. Students will be introduced to \emph{dynamic modelling}, in particular sequence diagrams that represent realisations of the use cases in software. We will also briefly look at an alternative dynamic modelling technique, statechart modelling.

Software System Architecture

Students will learn how a system?s physical Architecture Layer design models the system?s hardware, software and network environments. Students will learn that in doing this, a system architecture:

1) Reflects the non-functional requirements, e.g. operational, security and human-oriented requirements, and
2) models the infrastructure, and specifies the hardware and software of that infrastructure.

Most modern software systems involve co-operating computers and possibly other kinds of server. An IT system operating entirely within a company?s network may have applications on a given computer that interact with other servers, such as a database server, within the same network; and hence, that

the design for a physical architecture layer must model:

1) How a system is distributed amongst computers;
2) The hardware of those computers and
3) The software on those computers.

Students should understand that a system architecture helps specify the hardware and supporting software (such as database management systems) needed by the system being designed. This section of the course will be rounded off by considerations of the elements of a Physical Architecture Layer, such as how clients and servers are arranged.

Introduction to User Interface Design

The interface between the user and the system is a vital part of any software system. Students will learn about the cycle of execution and evaluation by which a user operates an application. Each stage of the cycle
involves mappings from one language to another: The user's language; the interface language and the system language. Students will learn how different tasks require different styles of interaction from direct manipulation; query and answer; form fill in; etc. Students will learn to choose an appropriate interaction style for a particular application and take into account human factors that affect screen design such as ergonomic considerations.

Software integration

Integration of software components, created by different developers, is critical for building working software. Students will learn about the different techniques and strategies for planning, developing, and integrating software components.

Verification and validation of software systems

Studies of software development in action show that errors which are found later in the development process are more costly to correct than those which occur earlier. It is therefore in a development team's interests to be able to locate errors as soon as possible. Students will learn about strategies for verifying that software meets its specification, and for determining whether the final system will meet the needs of the users.

Software Design Patterns

Design patterns, as described in the popular Design Patterns book, are recurring solutions to Class-Based Object-Oriented design problems. A design pattern describes a reusable OO design through a standard format - known as a pattern form - which normally consists of a name, the context in which the pattern is motivated, the problem situation in which the pattern is developed, and a general design solution. The design pattern solution is usually, but not always, illustrated using UML models. There are many expected benefits from design patterns. The most important ones are that design patterns provide a standard vocabulary for software designers to communicate the design and a pedagogical tool to teach novice how to design object-oriented systems.

In this course we provide a brief introduction to design patterns. These, and other types of software pattern will be covered in much more depth in a third year course unit.

Team working

Most software projects are too large and complex to be completed by one person working alone, and instead require a team of people with complementary skills. Even in a small team, effort must be put into ensuring that all team members are aware of their role in the total development, and are communicating well with other relevant team members. Through the laboratory exercises, students will gain experience in in working in teams, coping with the dynamics of teams, planning a team's resources and using team meetings to make progress in a team project.

Reading List

Core Text
Title: Applying UML and patterns: an introduction to Object-Oriented analysis and design and iterative development (3rd edition)
Author: Larman, Craig
ISBN: 0131489062
Publisher: Prentice Hall
Edition: 3rd
Year: 2004

Core Text
Title: Software engineering (9th edition)
Author: Sommerville, Ian
ISBN: 9780137053469
Publisher: Addison-Wesley
Edition: 9th
Year: 2011

Core Text
Title: Systems analysis and design with UML (3rd edition)
Author: Dennis, Alan and Barbara Haley Wixom and David Tegarden
ISBN: 9780470400302
Publisher: Wiley
Edition: 3rd
Year: 2009

Core Text
Title: Human-computer interaction (3rd edition)
Author: Dix, Alan et al.
ISBN: 0130461091
Publisher: Prentice Hall
Edition: 3rd
Year: 2004