COMP20341: Software Engineering 1 (2007-2008)
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. Software systems are growing in size and complexity, users are becoming more demanding and the consequences of failure can be increasingly severe as we come to depend upon software in so many aspects of our lives. 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 to tame them.
Since software engineering is a subject best learned hands-on, this is a project-based module that involves very little traditional lecturing. Instead, relevant skills will be acquired during weekly two-hour workshops, and practiced through individual and group project assessments.
This course unit aims to provide an introduction to the topic of software engineering, covering (almost) the entire software life cycle from early project planning through to verification of the finished product.
On completion of this course unit a student should:
Be aware of some of the different process models that can be used to organise and control the construction of large software systems, and be able to select appropriate models for given circumstances. (A, B)
Be able to plan resource requirements for simple software projects, and to generate from these plans expected development timings and completion dates. (A, B)
Be able to select and apply standard techniques for requirements elicitation, and to document the results as a specification using industry standard notations. (A, B)
Appreciate how different interaction styles 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 a screen design from overall style to each widget used. (A, B)
Have an understanding of good software design principles, and be able to apply current best practices to construct straightforward software designs that adhere to both functional and non-functional requirements. (A, B)
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)
Be aware of the capabilities and limitations of testing as a means of verifying system correctness, and be able to apply common approaches to test suite design within the context of modern software testing tools. (A, B, C)
Have experience of some of the challenges inherent in working as part of a software team, and of resolving the difficulties that arise. (D)
Assessment of Learning outcomesLearning outcomes 1 to 6 are assessed by examination, the mid-semester tests and the laboratory group project. Learning outcome 7 is assessed by examination and the laboratory group project. Learning outcome 8 is assessed by the laboratory group project.
Contribution to Programme Learning OutcomesA2, A4, A5, B1, B2, B3, C2, C4, C5, C6, D2, D3, D4, D5
Software processes and software project planning (SH)
Students will be exposed to the basics of project planning the software engineering task. This will include an awareness of the different models of the development life-cycle (along with their strengths and weaknesses), the use of project planning approaches to tie these techniques to resources, and a brief overview of each stage of the most common aspects of each model.
Requirements elicitation (RDS)
Requirements gathering forms the foundation for any software project. This workshop will introduce students to the basic techniques of interview and questionnaire used in requirements gathering. Students will learn the limitations and difficulties of these soft, but all too hard, techniques.
Requirements specification: use cases and activity diagrams (RDS)
Once gathered, requirements have to be organised and structured in an effort build a model of the tasks to be performed by an application. This workshop will introduce students to Use Cases and Activity Diagrams as the start of the process of moving from a specification of what the users do to a specification of what the system does. At the end of this workshop the students will be given a standard set of Use Cases which will be used in the next three workshops.
Requirements specification: domain modelling (JS)
Students will be given a brief introduction to 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. They will then produce domain models for the case study, based on the standard use cases provided. At the end of the workshop there will be a review period, where students will be encouraged to criticise each others' models.
Design class diagrams (JS)
This workshop will focus on design classes, and the relationship between these and the domain classes produced in the previous workshop. By the end of this workshop the students will have seen the subset of UML class diagram notation which is commonly used in practice, and produced design class diagrams based on the outputs of the previous workshops (primarily use cases and domain classes).
Dynamic modelling (JS)
The previous two workshops investigated static modellng of the domain in which the software will operate, and the software itself, respectively. In this workshop we will introduce dynamic modelling, in particular sequence diagrams which represent realisations of the use cases in software. We will also briefly look at an alterative dynamic modelling technique, statechart modelling.
HCI design principles (RDS
From this self study pack, 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 (SH)
Integration of software components, created by different developers, is critical for building working software. In this workshop we will investigate the different techniques and strategies for planning, developing, and integrating software components.
Software tools for collaboration and control (SME)
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. A number of software tools have been developed over recent decades to help in coordinating team software development and promoting accurate and timely communication within the team. Through this self-study pack, and the laboratory exercises, you will gain experience in using industry-strength examples of such tools.
Verification and validation of software systems (SME)
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. In this workshop, we will look at strategies for verifying that software meets its specification, and for determining whether the final system will meet the needs of the users.
See the course unit web pages or the Moodle forum for details of background reading for the individual workshops for this course unit.