Curriculum specificationrti.etf.bg.ac.rs/rti/projekti/tempusmirror/results/...o principles for the development of modules. All mentioned items are described in this document. This

http://perun.im.ns.ac.yu/msc-se/ 1

Joint MSc curriculum in software engineering European Union TEMPUS Project CD_JEP-18035-2003

Curriculum specification

- 2nd release -

Version: May 25, 2006 Contents

1. Declaration of the project consortium 2. Goals of the Joint curriculum in software engineering 3. Structure of the curriculum 4. Module lists 5. Principles for implementing the curriculum 6. Quality assurance and control 7. Module templates - Glossary - Version history Consortium members of the European union (EU) Tempus project: Humboldt University, Berlin (Prof. Klaus Bothe, Grantholder) University of Novi Sad (Prof. Zoran Budimac, Co-ordinator) Deusto University, Bilbao (Prof. Rebeca Cortazar) De Montfort University, Leicester (Prof. Hussein Zedan) University of Belgrade (Prof. Dragan Bojić) University of Niš (Prof. Milena Stanković) University ‘Sts. Cyril and Methodius’, Skopje (Prof. Katerina Zdravkova) Individual Experts: Prof. Ioan Jurca (Timisoara, Romania) Prof. Stanimir Stoyanov (Plovdiv, Bulgaria)


1. Declaration The project consortium recognizes difficulties in developing a curriculum for the joint master studies in ‘Software Engineering’ for changing and different environments for four universities in two different countries in Serbia and Macedonia. Therefore we are not defining a fixed curriculum, but rather a curriculum template that can be implemented in several different ways by the participating institutions. All of the implemented curricula share:

• goals, structure, and the module list of the curriculum, • principles for implementing (adopting) the curriculum, • quality assurance and control mechanism, • pool of implemented modules (study packs) fully developed

according to: o module templates and o principles for the development of modules.

All mentioned items are described in this document.

This document will be accompanied by further curriculum documents: curriculum handbook, detailed module template handbook, staff handbook, and student’s handbook. The information that will be contained in these documents will not be the subject of this document (i.e., assessments, grading, detailed rules for the final project, etc…).


2. Goals of the Joint MSc curriculum in software engineering Mission The MSc curriculum in software engineering is committed to excellence in European-wide software education and training of engineers to deliver high quality and trustworthy software systems that meet the local industrial needs.

General competencies of a successful MSc graduate of the joint curriculum

• Ability to work in an interdisciplinary team • Capacity for analysis and synthesis • Capacity for applying knowledge in practice • Capacity for generating new ideas (creativity) • Capacity to learn • Critical and self-critical abilities • Decision-making • Knowledge of a second language • Research skills

Specific learning outcomes of a successful MSc graduate of the joint curriculum

• Show mastery and critical thinking of the software engineering (SE) knowledge and skills and professional issues necessary to begin practice/research as a software engineer.

• Work as individual or as part of a team to develop and deliver high quality software artefacts, being able to analyze its level of quality.

• Identify, analyse, and reconcile conflicting project objectives, finding acceptable compromises within limitations of cost, time, knowledge, existing systems and organizations.

• Analyze, design and document appropriate solutions in more than one application domains using SE approaches that integrate ethical, social, legal and economic concerns

• Demonstrate an understanding of and critically analyze and apply current theories, models and techniques that provide a basis for problem identification and analysis, software design, development, implementation, verification and documentation.

• Demonstrate an appreciation and understanding for the importance of negotiation, effective work habits, leadership and good communication with stakeholders in a typical software environment.

• Learn new theories, models, techniques and technologies as they emerge and appreciate the necessity of such continuing professional development.


3. Structure of the curriculum

• The value of master studies will be 90 European credit transfer system (ECTS) credits.

• The studies will be organized into three semesters. • One academic year consists of two semesters and is lasting for 30

weeks (1 semester = 15 weeks). • The first two semesters will consist of lectures, while the third one

will be devoted to the final project/thesis. • Induction layer: a couple of introductory modules will be offered

before the 1st semester for students without enough pre-knowledge • First semester: core modules (30 ECTS) • Second semester: optional modules (30 ECTS) • Third semester: final project (30 ECTS) • 1 ECTS credit is worth 20 hours of total student's workload. • There are 21 - 24 contact hours per week.


4. Module list List of induction layer modules

Introduction to software engineering (SE-IN-01) Principles of programming, coding and testing (SE-IN-02) Project management (SE-IN-03) System modelling and design (SE-IN-04)

Core modules 1. Research methods (part 1) (SE-C-01) 2. Requirements engineering (SE-C-02) 3. Architecture, design, and patterns (SE-C-03) 4. Software testing (SE-C-04) 5. System integration (SE-C-05) 6. Information system development process (SE-C-06) Optional modules

1. Software evolution (SE-O-01) 2. Component-based development (SE-O-02) 3. Formal methods engineering (SE-O-03) 4. Software engineering for critical systems (SE-O-04) 5. Privacy, ethics, and social responsibilities (SE-O-05) 6. Applied system thinking (SE-O-06) 7. Business modelling (SE-O-07) 8. E-business (SE-O-08) 9. Business process re-engineering (SE-O-09) 10. Service quality management (SE-O-10) 11. Software engineering for database systems (SE-O-11) 12. Advanced topics in software engineering (SE-O-12) Final project

Detailed project descriptions are made available to students at the beginning of the curriculum but they start working on it in 3rd semester.

At the beginning of semester a condensed module on selected topics in project management is delivered to students.

Some suggested projects are: Electronic patient records Electronic purse Flight control systems E-voting system


5. Principles for implementing the curriculum

1. Number of modules. All modules are one-semester long and equally weighted. The total number of modules will be eight. However, due to different traditions and backgrounds some universities may choose ten modules. In such a case we insist that at least eight of those ten modules must be chosen from the list given below.

2. Module weight. The weight of each module is 7.5 ECTS credits in case of four and six ECTS credits in case of five modules per semester. In the former case additional homeworks must be given to students in order to reach the value of 7.5 ECTS credits per every module.

3. Contact hours. The number of contact hours per module is four per week.

4. Induction layer. Modules in this layer can be chosen from those described below. However if an institution does have equivalent (with respect to learning outcomes) modules then it is free to use them.

5. Core modules. Every institution is obliged to choose four modules from the list of core modules. The institution can change its decision every year and have to direct students to the core modules of other institutions belonging to the joint MSc studies in software engineering. For those institutions that decided to choose five modules per semester, four of those five must be from the core.

6. Optional modules. 6.1 In the 2nd semester, students can choose four modules from

the rest of core modules and/or optional modules, provided to him or her by any institution belonging to the joint MSc studies in software engineering.

6.2 Institutions do not have to offer all available optional modules every year.

6.3 Institutions can include new module(s) into the set of optional modules, providing that they pass through the same quality procedures as the originally existing modules. The consortium of institutions implementing the joint studies should agree on the aims and learning outcomes of new modules.

7. The choice of tools. Each institution implementing the curriculum will select appropriate technologies and products to be used for implementation and exemplification purposes, according to suggestions given in module templates.

8. Changes. If some of the institutions wishes to suggest changes it should address the project consortium for a final decision during the duration of the project. Otherwise, the consortium will make the final decision.


6. Quality assurance and control

Quality assurance and control are extremely vital for the success of any educational and training curriculum. To this end we have established a series of protocols that ensure the attainment of the highest level of quality to the proposed MSc Curriculum. These protocols address five basic components: curriculum validation, module development, module assessment, students’ selection and quality team. 1. Curriculum Validation 1.1 Validation is the process by which an academic institution establishes

that a new curriculum is • academically viable, • that academic standards have been appropriately defined and • that the students have the best opportunity to learn.

1.2 A validation event should be organised in which a validation panel of academic peers scrutinise the proposed curriculum.

1.3 A panel must have external members (academics and/or industrialists).

1.4 The panel reads the curriculum documentation before the event. The documentation consists of Curriculum handbook (describing the whole curriculum dealing with rationale, curriculum, costing and resource issues, etc.), Detailed module templates handbook (requirements specification of all modules in the curriculum), Staff handbook (contains all CVs of teaching staff) and Student handbook (contains everything that students need to know, from the course regulation, modules, staff, libraries, etc.).

1.5 Holding a face-to-face validation puts the curriculum team to the test and ensures they can justify their proposal.

2. Module Development Every fully developed module is described by the study pack that contains the following:

• detailed module template that refines and details the module template and also contains a) requirements for the lecturer (job description) for every module and b) precise rules for examination and the course work;

• supporting literature for lecturers; • presentation material preferably slides in PPT format; • lecture notes, separate or attached to slides (preferably the latter),

explaining the way in which slide contents can be delivered to students;

• material for theoretical exercises (assignments, rules, solutions…);


• material for practical exercises (assignments, rules, solutions, tools…);

• supporting literature for students (the reference list and/or actual reading material).

2.1 The MSc curriculum will establish a number of technical editors

(TEs), who are expert in particular subject(s) in the field. Each TE is responsible for the technical direction and evolution of the module(s) in his/her subject area.

2.2 The requirement specification of a module is clearly documented in what is known as module template. The development of a module must follow and satisfy its template.

2.3 Any changes in the module must be approved by the TE in charge and be reflected in the template itself.

2.4 Modules go through minor and major revisions on an annual basis. 2.5 Prior to its first delivery, a module goes through two releases: draft-

and final- releases. In the former, a dry-run is given to a selected audience (members of the teaching staff) and their feedback is taken into account in the second release.

2.6 Modules have module feedback form where students are asked to fill at the end of each module delivery. These are collated, analysed and reported to the module TE.

2.7 Every module must be evaluated by the teaching team at the end of each delivery. The evaluation should take into consideration achievement rates, student views, external examiners comments and the observation of the teaching team. Module evaluation should lead to action for enhancement where problems are identified.

2.8 A module is retired if its objectives do not fit the purpose it was originally believed.

3. Module Assessment 3.1 Three modes of assessment exist: unseen paper, course-work, and

mixture of unseen paper and course-work. The choice depends on the nature of the module.

3.2 An internal process should exist to ensure the quality (with respect to learning outcomes) of the assessed work. Such process should have an internal moderator who checks (and sign-off) the unseen paper and/or the course-work.

3.3 An external examiner (EE) is appointed to ensure that the quality of the assessed work is of a national and Joint studies standards. The EE should be an experienced academic or industrialist.

4. Students’ Selection 4.1 Being an advanced master in software engineering, the recommended

target intake group is as follows:


• current practitioners with adequate relevant experience; • new graduates of computer science or software engineering; • Computer scientists or software engineers who require retraining or

undertake career development; • students wishing to embark on a research curriculum, at a PhD level,

in software engineering There are no restrictions regarding the average grade mark in previous education unless stated otherwise in national laws or university regulations.

4.2 We should note that new graduates of subjects such as mathematics,

engineering and physics may also be considered as we have an induction provision in the curriculum which intends to provide adequate background knowledge in software engineering to allow them to follow the rest of the curriculum.

4.3 As the general guidelines for those who wish to attend the Joint MSc

curriculum, we provide the following competencies that are expected from every student. These guidelines can be also used by the institution to decide whether or not an induction is necessary.

• fundamental knowledge in basic fields of mathematics; • ability of logical thinking, formulation of prerequisites, and deriving

conclusions in a formal or formalized way; • ability to understand and formulate problem, and its modelling to

enable its analysis and solving; • programming skills in at least procedural and object-oriented

programming paradigm; • understanding of all phases in the software development cycle:

requirements, analysis, design, implementation, testing, maintenance;

• practical skills in using of programming environments, database management systems (DBMS), and computer-aided software engineering (CASE) tools;

• understanding of current trends in the development of informatics • ability to adapt to new circumstances, i.e., ability to learn new

models, techniques and technologies as they emerge and appreciate the necessity of such continuing professional development;

• appreciation of basic ethical and social responsibilities of information technology (IT).

5. The quality team

We recognize the following roles and their duties in the process of the developing and delivering study packs.


Roles and duties in the quality assurance of study packs


7. Module Templates


INTRODUCTION TO SOFTWARE ENGINEERING (SE-IN-01) AIMS: This module gives the student foundational knowledge and concepts in software engineering. It aims to be both a light touch introduction (essential for those who have no knowledge of the subject) and a refresher for those who need to refresh their knowledge on the topics. LEARNING OUTCOMES: Upon successful completion of this module, the student will be able to: • to select an appropriate software development life cycle model; • understand the importance of and apply appropriate requirements, analysis, design, build and

testing methodologies; • discuss project-wide processes, including quality assurance, configuration management,

project planning and risk management; • identify essential deployment activities; • address maintenance issues during initial project development as well as during the

maintenance phase; • compare structured and object-oriented techniques; • discuss best software engineering practices and common pitfalls that cause many projects to

fail; • discuss techniques that will aid an organisation in achieving ISO (International Organisation for

Standardisation) or SEI CMM (Software Engineering Institute Capability Maturity Model) goals; • assess the value of various tools for CASE (Computer-Aided Software Engineering). SYLLABUS CONTENT: • Software: art or science? • Software life cycles • Capturing and managing requirements • Analysis, design and implementation • Testing, deployment and maintenance • Building in quality • Project planning and management • CASE tools • Making it happen


PRINCIPLES OF PROGRAMMING, CODING AND TESTING (SE-IN-02) AIMS: This module distinguishes between programming (as a principle activity, recursion, conditional, modularisation,) and coding (a practical activity realising the programming principles). This module introduces two complementary topics: (1) traditional, imperative programming; and (2) the implementation of standard linear data structures and the algorithms that manipulate them. Key aspects of an imperative programming language are covered, including major library functions and basic design and testing techniques. The module will be particularly suited to anyone who needs to understand how a computer can be controlled using software designed for a traditional Von-Neumann architecture. It is an introductory course in computer programming. LEARNING OUTCOMES: Upon successful completion of this module, the student will be able to: • develop, using a text editor, compiler and linker, small-scale imperative programs involving

the core language; select and use standard library functions; and modify pre-coded algorithms;

• design a suitable test strategy for a computer program and apply standard debugging techniques to identify and correct semantic errors;

• design and write software that creates and maintains linear data structures along with algorithms for searching and sorting data;

• describe the performance characteristics of standard searching and sorting techniques SYLLABUS CONTENT: • The core of procedural language: statements, types, operators, expressions, sequence,

selection, iteration, arrays and strings. • Small program construction: functions, records, pointers, variable scope and lifetime,

libraries, separate compilation and linking. • Linear data structures and algorithms: Linked and contiguous storage, linear structures,

ordered and unordered lists, searching and sorting. • Software testing: unit, integration, system, acceptance, regression…


PROJECT MANAGEMENT (SE-IN-03) AIMS: To provide basic project management skills with a strong emphasis on issues and problems associated with delivering successful IT projects. The module is designed to provide an understanding of the particular issues encountered in handling IT projects and to offer students methods, techniques and 'hands-on' experience in dealing with them. Upon completion of this module students will be able to undertake and be aware of aspects of project management. LEARNING OUTCOMES: Upon successful completion of this module, the student will be able to: • understand and practice the process of project management and its application in delivering

successful IT projects; • evaluate a project to develop the scope of work, provide accurate cost estimates and to plan

the various activities; • understand and use risk management analysis techniques that identify the factors that put a

project at risk and to quantify the likely effect of risk on project timescales; • identify the resources required for a project and to produce a work plan and resource

schedule; • monitor the progress of a project and to assess the risk of slippage, revising targets or

counteract drift; • distinguish between the different types of project and follow the stages needed to negotiate

an appropriate contract. SYLLABUS CONTENT: • Introduction to IT project management: distinguishing between software & other types of

development projects; defining the scope of software project management; structured approach to project planning.

• Carrying out a project evaluation against strategic, technical and economic criteria: using a variety of cost-benefit evaluation techniques; evaluating risks involved and selecting appropriate strategies for minimising potential costs; selecting an appropriate process model, reducing risks by implementing the projects incrementally.

• Estimating project costs by bottom up approach: understanding the range of estimating methods that can be used to understand the COCOMO (COnstructive COst MOdel) parametric model used to develop effort methods; producing an activity plan for a project using a tool (e.g. MS Project); creating a critical path and a precedence network for a project; identifying the factors that put a project at risk.

• Identify the resources required for a project and producing a plan and work schedule: monitoring the progress of a project and assessing the risk of slippage; revising targets to correct or counteract drift; controlling changes to projects requirements; understanding the advantages and disadvantages of using goods and services brought in from external organisations; distinguishing between the different types of contract: following the stages needed to negotiate an appropriate contract; evaluating proposal.

• Identifying some of the factors that influence people's behaviour in a project environment: increasing staff motivation and improving group working; an appreciation of the various team structures; understanding the importance of software quality standards to ensure meeting the project requirements.


SYSTEM MODELLING AND DESIGN (SE-IN-04) AIMS: This module provides the student with practical experience of the issues involved with software development. Specifically, the student will work as part of team developing software from a supplied specification and design document. The development will take place on an industrial-strength platform (e.g. .NET). The basic concepts of the object-oriented (OO) paradigm and the rapid application development (RAD) approach are introduced and an overview of the means by which systems requirements can be captured and modelled is given. The elaboration of analysis models into design models is covered, taking into consideration both object and systems design issues. The way in which test cases are used to ensure quality software production is also examined. Throughout, models are developed using the Unified modelling language (UML) which has become an industry standard for OO modelling. The use of design patterns is introduced; a range of which are applied to the specification of OO design models. An overview of the role of methodologies in specification is given, with an introduction to a contemporary systems development methodology (e.g. USDP - Unified Software Development Process) as a framework for undertaking analysis and design activities. The module will encourage the use of software tools whenever possible in areas such as: collaborative working, product testing, version and documentation control. The student will gain experience of software development, software testing and adaptive maintenance while gaining familiarity with a modern development framework. Throughout the module the student will be encouraged to reflect upon the experience gained and keep to maintain a personal set of notes LEARNING OUTCOMES: Upon successful completion of this module, the student will be able to: • map a specification and design into code; • explain the main issues involved with collaborative software development, testing and

maintenance; • explain the object-oriented paradigm and identify the significant issues that are addressed when

developing object-oriented systems specification models; • construct a set of system specification models using an appropriate range of object modelling

techniques that represent different perspectives of a particular systems development (e.g. build UML models and describe them by use cases, class diagrams, activity diagrams, interaction diagrams, state charts and package diagrams);

• use a CASE tool to build and document analysis and design models in a consistent manner; • describe how analysis and design activities are organized within a leading systems development

methodology (e.g. Unified Software Development Process) and discuss the contribution of the methodology in the production of quality software systems;

• describe the features of a modern software development framework that support access control; multi-language programming; version control and release.

SYLLABUS CONTENT: • The .NET environment: structure; facilities; navigation; services. • The basic concepts of the object-oriented (OO) paradigm and RAD approach to systems

development. • Recap traditional fact-finding approaches for systems requirements capture. • An overview of the use of RAD techniques such as JAD (Joint Application Development), use

case and task-scripting. • An overview of techniques used for the analysis and modelling of logical requirements,

expressed as UML models. • Systems analysis vs. systems design: moving from an analysis set of documents to a design

model. • Introduction to systems design issues: object design (assigning responsibilities, CRC (Class-

Responsibility-Collaboration) cards, visibility and designing associations, specifying constraints and integrity); facilitating reuse (coupling and cohesion); systems design concepts; identifying design goals; software architecture (layering and partitioning, packaging subsystems, deployment); interface design (persistent data management strategies, identifying concurrency and control).


RESEARCH METHODS (SE-C-01) AIMS: The module will introduce and develop the concepts, organisational structure and deliverables of a research project using qualitative and quantitative methods. To extend to a postgraduate level, the student's appreciation and understanding of how to organise, to plan and 'execute' a technical research project. LEARNING OUTCOMES: Upon successful completion of this module, the student will be able to: • prepare, plan and monitor a research project using tools and skills needed for critical evaluation

and analyses of project results; • formulate, plan and communicate a research project; • select and appreciate the appropriate search methods for collection of information; • demonstrate knowledge and experience on procedures and methods for structuring, gathering

and handling of information and data in a technological environment. SYLLABUS CONTENT: • Project approaches: project management, quality management. • Communication skills: presentation skills, literature search & patents, technical report writing. • Methods for research: problem analyses and problem solving techniques; methods for structuring

a problem; qualitative methods for system/process analyses and performance assessment; quantitative methods for data gathering and data analyses; experiment design and collection of data, performance analyses, variance analyses, statistical quality control, statistical process control; plagiarism and referencing; health and safety aspects of research

PREREQUISITES: None RECOMMENDED ASSESMENT: Coursework


REQUIREMENTS ENGINEERING (SE-C-02) AIMS: Software requirement engineering is the science and discipline concerned with establishing and documenting software requirements. It consists of software requirement elicitation, analysis, specification, verification and management. On the other hand, system requirements engineering is the science and discipline concerned with analysing and documenting system requirements. It involves transforming an operational need into a system description, system performance parameters and a system configuration. This is accomplished through an iterative process of analysis, design, trade-off studies and prototyping. This module is intended to provide the student with a comprehensive understanding, critical evaluation of requirement engineering both software and system. LEARNING OUTCOMES: Upon successful completion of this module, the student will be able to: • critically evaluate baseline management models; • critically evaluate fundamentals of requirements engineering; • appreciate the essential issues of requirement engineering and architecture design; • perform requirements engineering, including elicitation, analysis, documentation and validation; • practically implement traceability issues in system requirement engineering; • critically evaluate the role of tools and methods in requirement engineering. SYLLABUS CONTENT: • The requirement environment. • Requirements characteristics. • System and system engineering. • Requirement allocation and/or relationship assignment. • Requirement versus design implementation. • Requirement quality. • Relationships among stakeholders, i.e., users, analysts, non-user customers, sponsors,

managements… • The concept of operations: the bridging from operational requirement to technical specifications • Techniques for requirement elicitation. • Requirement engineering with a tool (e.g. ViewPoints) and use cases PREREQUISITES: None RECOMMENDED ASSESMENT: Coursework


ARCHITECTURE, DESIGN, AND PATTERNS (SE-C-03) AIMS: Software architecture is an active area with growing interest by researchers and practitioners from the disciplines of software engineering and software design. In the strict sense, software architecture is “a description of the subsystems and components of a software system and the relationships between them.” The increasing volatility of requirements and need to respond in timely fashion to changes taking place in the business or application domain, requires software design to produce systems that can be extended and modified relatively easily. There is an increasing need in industry for software to support evolution of requirements, the rapid addition of services, and a wide variety of customer needs. A number of architecture modelling notations and tools as well as architectural styles have been proposed to provide the foundation for developing robust, scalable, and reliable software. Explicit focus on architecture in conjunction with emerging best practices in analysis and design has shown great potential to improve the current state-of-the-art in software product development. The course addresses this issue as a central design goal, and introduces the student to a variety of modelling and design techniques that address this need in the context of object-oriented software development. The course covers all aspects of designing software: from architectural issues (styles, patterns, views) to design patterns that can be described as “a common solution to a common problem in a given context” on a lower lever of abstraction. LEARNING OUTCOMES: Upon successful completion of this module, the student will be able to: • clearly appreciate the impact of abstraction, modelling, architecture, and patterns in the

development of a software product; • critically discuss and explore key concepts in software architectures, designs, and patterns; • critically discuss and explore architectural and design alternatives and be able to generate

reasonable alternatives for a problem, and choose among them; • to recognize the appropriate pattern for a problem and to create an appropriate one; • apply practical skills to generate and deploy software architectures and designs based on

traceable requirements. SYLLABUS CONTENT: • Theory of software architecture. • Analogy with architecture in general. • Elements of software architecture: architectural styles (ABAS – Attribute Based Architectural

Style); architectural patterns (event-based, layered, pipes & filters …); architectural description languages.

• Interaction between various types of requirements and architecture. • Master plans vs. piecemeal growths. • Architecture analysis and evaluation: SAAM (Software Architecture Analysis Model), scenario-

based evaluation. • Architecture process and organization. • Model driven development. • From architecture to design. • Reusing architectures. • Design patterns. • Framework and tools. PREREQUISITES: None RECOMMENDED ASSESMENT: Coursework and unseen paper


SOFTWARE TESTING (SE-C-04) AIMS: With the growing significance of computer systems within industry and wider society, techniques that assist in the production of reliable software are becoming increasingly important. The complexity of many computer systems requires the application of a battery of such techniques. Two of the most promising approaches are formal methods and software testing. Traditionally formal methods and software testing have been seen as rivals. Thus, they largely failed to inform one another and there was very little interaction between the two communities. In recent years, however, a new consensus has developed. Under this consensus, these approaches are seen as complementary. This has lead to work that explores ways in which these approaches complement. The use of a formal specification or model eliminates ambiguity and thus reduces the chance of errors being introduced during software development. Where a formal specification exists, both the source code and the specification may be seen as formal objects that can be analysed and manipulated. The use of a formal specification introduces the possibility of the formal and, potentially, automatic analysis of the relationship between the specification and the source code. This is often assumed to take the form of a proof, but such a proof cannot guarantee operational correctness. For this reason, even where such a proof exists, it is important to apply dynamic testing. Software testing is an important and, traditionally, extremely expensive part of the software development process. Studies suggest that testing often forms in the order of fifty percent of the total development cost. Where formal specifications and models exist, these may be used as the basis for automating parts of the testing process. This may lead to more efficient and effective testing. It may thus transpire that the automation of parts of the software testing process is one of the most significant benefits of using a formal specification language. The links between testing and formal methods do, however, go well beyond generating tests from a formal specification. This module aims to introduce and critically analyse current techniques for software testing, in particular the importance of formal methods towards this goal. LEARNING OUTCOMES: Upon successful completion of this module, the student will be able to: • critically evaluate the importance of software testing; • appreciate the need and usefulness of formal methods for the testing process; • develop an integrated approach for software testing and formal theories; • critically evaluate testing tools. SYLLABUS CONTENT: • Introduction to testing fundamentals. • Structural testing. • Functional testing. • Foundation for combining formal methods and testing. • Assertion based testing. • Model based formal methods. • Finite state machine based testing. • Testing from a process algebra. • Testing with UML's dynamic models. • Temporal logic, model checking and their role in testing. • Tools for automatic testing and continuous integration. • The management process of software testing. PREREQUISITES: None RECOMMENDED ASSESMENT: Coursework and unseen paper


SYSTEM INTEGRATION (SE-C-05) AIMS: This module provides a comprehensive understanding of the technical issues involved in designing and implementing modern distributed systems through integration. It also introduces different concepts and approaches for system integration. LEARNING OUTCOMES: Upon successful completion of this module, the student will be able to: • critically evaluate the different integration possibilities; • appreciate the need and usefulness of different models and approaches for system

integration; • critically evaluate, design and use object-based distributed systems such are CORBA

(Common Object Request Broker Architecture), Web Services Model, EJB (Enterprise Java beans), .NET Remoting…;

• implement a simple distributed system that can communicate effectively with existing and new architecture.

SYLLABUS CONTENT:

• Integration: overview. • Middleware-oriented integration by (e.g.) CORBA: architecture, interfaces and IDL

(Interface Description Language), clients, servers, CORBA vs. RMI & RPC (Remote Method Invocation & Remote Procedure Call).

• Introduction to XML (eXtensible Markup Language). • Web-Services integration: model, architectures, XML-based protocols, UDDI (Universal

Description, Discovery and Integration), WSDL (Web Services Description Language), SOAP (Simple Object Access Protocol), SWS (Simple Web-Services), service publication, service retrieval, service activation.

• Component-oriented Integration: model and architecture, transaction components (Transaction EJB).

• Semantics-oriented integration: architectures, agent-oriented approach, intelligent services, agent-service communication.

• Using a platform (e.g., .NET) to develop and test the Web service servers and clients, transactional components, and multi-component projects.

PREREQUISITES: None RECOMMENDED ASSESMENT: Coursework and unseen paper


INFORMATION SYSTEM DEVELOPMENT PROCESS (SE-C-06) AIMS: This module covers two important aspects of information systems development (ISD): the selection and evaluation of methodologies and the management of the systems development process. A variety of ISD paradigms and methodologies will be considered, including ‘hard’ approaches, both object-oriented and structured, ‘soft’ and participative approaches, and ‘heavyweight’ and ‘agile’ methodologies. A framework will be developed to compare and evaluate methodologies to help determine their applicability to particular development projects and environments. The way in which methodologies are used in practice will be considered. To successfully deliver a computer-based information system to a customer, whether internal or external, requires proper planning: an analysis of the project, its potential as an investment, the benefits and risk. The manager should be convinced that the project will succeed, is controllable, that resources will be forthcoming and should carry out planning (as detailed as possible) before accepting the brief. The importance of being able to balance the key project requirements of timescale, budget, quality and delivered functionality makes the project manager’s role challenging and satisfying. The success of a project depends on more than just technical issues; commitment from the users, ‘ownership’ of the system, effective communications, clear identification of benefits and managing the delivery of these – these and other ‘softer’ issues are often the key factors in determining success. Various project management approaches will be examined and critically evaluated in the context of the methodological approach (e.g. SSADM - Structured Systems Analysis and Design Methodology, PRINCE - PRojects IN Controlled Environments, agile development). Staffing issues (e.g. recruitment, training, motivation, team-building, leadership style) have major implications for project success and will be placed in the context of ISD. LEARNING OUTCOMES: Upon successful completion of this module, the student will be able to: • discuss the merits and drawbacks of a variety of Information systems development

methodologies and the issues involved in their adoption; • justify the selection of a methodology appropriate for a given information systems

development project; • identify the major planning and staffing issues involved in information systems project

management and recommend appropriate techniques and methods for a given project; • discuss the need for awareness and sensitivity in managing organisational relationships and

the importance of effective reporting structures and communication; • recommend appropriate ways in which the benefits of a system can be evaluated. SYLLABUS CONTENT: • Information systems development (ISD): a review of major concepts, lifecycles, definition of a

‘methodology’, the factors influencing methodology use. • Frameworks for methodology evaluation. • Object-oriented methodologies, e.g. (Rational) Unified Process. • Structured methodologies, e.g. SSADM. • The development from ‘heavyweight’ to more ‘agile’ approaches, e.g. DSDM (Dynamic

Systems Development Method), XP (eXtreme Programming). • ‘Soft’ methodologies, e.g. soft systems methodology. • Participative approaches, e.g. DSDM, ETHICS (Effective Technical and Human

Implementation of Computer-based Systems). • Integrated approaches, e.g. Multiview. • Specialist applications and their methodology requirements, e.g. Web information systems. • Issues concerning the introduction of and use of methodologies. • Ethical aspects of ISD.


The emphasis throughout will be on the comparison and evaluation for specific contexts of the methodologies covered. • The nature of the project, its components, risks, success factors and associated politics. • Information Systems investment justifications: approaches to investment appraisal. • Identification and management of benefits; assessing the intangibles. • Organisation of systems development: reporting structures. • Project planning and control: work breakdown structures; estimation, budgeting, planning

methods (PRINCE 2). • Project administration: tracking and reviewing; configuration management and change

control. • Staff management, motivation, leadership. • Quality Management, standards and accreditation. • Managing software project risks. • Managing object-oriented projects (reuse): rapid application development (e.g., DSDM, XP) • Managing large-scale projects: implementation and post-implementation review. PREREQUISITES: None RECOMMENDED ASSESMENT: Coursework and unseen paper


SOFTWARE EVOLUTION (SE-O-01) AIMS: With the advent of new architectures, the need to introduce new functionalities, the improvement in design techniques and/or changing in business objectives and process, there is a strong need to evolve existing software systems maintaining their continuity of use. Such evolution requires various techniques for what is known as `re-engineer'. By re-engineering, we adopt the view of examining, understanding and altering a system with the intent of re-designing and implementing it in a new form. The process of re-engineering a system requires therefore • the construction of a higher level abstraction of the system, a process known as reverse

engineering; and • the development of a new system starting from its higher level of requirement specification

(i.e. forward engineering). Recognising the functionality of an existing code is often seen as being the most difficult aspect of the process of re-engineering. To successfully re-engineer a system, we need to identify design decisions, intended use and domain specific details. This module aims to introduce and critically analyze current techniques for software evolution and provides students with a practical experience using industry strength tool-set (such as FermaT). LEARNING OUTCOMES: Upon successful completion of this module, the student will be able to: • critically evaluate the current rationales for software evolution; • appreciate reengineering techniques for software migration and abstraction; • apply transformation rules to migrate time and business critical software; • develop an integrated approach for software evolution life cycles; • gain practical experiences on using industry-strength tools (such as FermaT). SYLLABUS CONTENT: • Rationales and taxonomies for software evolution. • Evolution within development life cycles. • Lehman's laws of evolution. • Managerial aspects of software evolution. • Program comprehension. • Refactoring. • Aspect oriented software evolution. • Wide spectrum language (WSL) and software transformation. • Transformation theory and their implementation. • Tools (e.g. FermaT) and software migration and abstraction. • Open source and their evolution. PREREQUISITES: None RECOMMENDED ASSESMENT: Coursework and unseen paper


COMPONENT BASED DEVELOPMENT (SE-O-02) AIMS: The development of modern, distributed enterprise-wide computing systems is a complex activity. Issues of scale and distribution have added to the general pressures of the 'software crisis' - the inability of the software industry to match expectations created by the rapid evolution of computing hardware. One approach targeted at these problems is component based development (CBD). CBD has been the 'holy grail' of software engineering since the famous NATO (North Atlantic Treaty Organization) conference on software engineering coined the term in 1968. Technological development over the last decade has at last resulted in the emergence of a component market - but CBD also changes the nature of the software development process. This module provides the historical background in order to understand the issues and difficulties inherent to CBD which have held back its growth, while providing insights into the current situation through exposure to an industrial strength CBD process. It provides a practical introduction to the key modelling techniques used at different stages in a CBD project in order to identify and specify business components as 'independent units of deployment and replacement'. It illustrates how object-oriented principles underlay these techniques, and shows how they can be fitted together in an overall end-to-end development process. The intention of the module is to provide students with a practical, integrated overview of CBD from requirements gathering through to the deployment of a component-based system. A large-scale case study, already part implemented, is used to take the student through all of the workflows of the CBD project life-cycle. The module introduces relevant theory including, non-exhaustively, the concept of CBD; the history of CBD; objects versus components; business components and software architectures; design-by-contract; UML as a visual language for CBD; problem-space and solution-space modelling; the object constraint language for specifying pre- and post-conditions on operations and comparing development processes that aim to support CBD. The module also lays a foundation in practical skills and understanding of CBD which will be of potentially immediate advantage to the student in her future profession. Use case driven techniques are explored in depth, specification modelling using a subset of UML together with relevant profiles are practiced, and implementation in the context of specific component execution environments are explored to give the student a balanced and in-depth base of theoretical and practical knowledge in this area. LEARNING OUTCOMES: Upon successful completion of this module, the student will be able to: • critically discuss and explore the key concepts in component based development, and its

impact on business computing and on the software engineering discipline; • understand the theoretical basics of CBD; • apply appropriate techniques to derive detailed and rigorous component specifications from a

set of user requirements; • apply practical component development skills to implement and deploy significant business

components in the context of a particular component execution environment. SYLLABUS CONTENT: • Background. • Component based software architecture. • UML for component based development. • CBD ’96: requirements, specification, and provisioning workflow. • Business objects. • Component technologies (e.g., EJB, Microsoft technologies, CORBA). • Combining components – case studies: accessing legacy code and wrappers; web services;

components of the shelf (COTS). • System integration issues. • Tools. PREREQUISITES: None RECOMMENDED ASSESMENT: Coursework and unseen paper


FORMAL METHODS ENGINEERING (SE-O-03) AIMS: Formal methods are those with a sound basis in mathematics. They are often used in the specification and design of critical systems where failure can cause catastrophic effects such as death, damage to the environment, lose of money, etc. However, the use of these methods in a large scale design and development still not wide spread as originally thought. What is needed is mechanisms to engineer these methods so that they can be used in industry and on large scale systems. This module is intended to provide the student with a comprehensive understanding, critical evaluation of formal methods and gives a detail account on a particular technique that is based on automata theory and their industry-strength tool support such is Statemate. LEARNING OUTCOMES: Upon successful completion of this module, the student will be able to: • critically evaluate the basis for the need of trustworthiness in large scale computer systems; • critically evaluate fundamentals of formal methods; • appreciate the essential issues of using formal techniques in the whole system life cycle in

particular requirement engineering and architecture design; • critically evaluate various types of large scale system from transformational to hybrid systems; • critically evaluate the role of tools and methods for the engineering formal methods. SYLLABUS CONTENT: • Large scale systems. • Taxonomy of formal methods. • Transformation vs. reactive vs. hybrid systems. • Automata theory. • State-based development methods. • State chart and activity chart. • (e.g.) Statemate semantics and development. • Real-time aspects in (e.g.) Statemate. • Case studies. PREREQUISITES: None RECOMMENDED ASSESMENT: Coursework and unseen paper


SOFTWARE ENGINEERING FOR CRITICAL SYSTEMS (SE-O-04) AIMS: Critical Systems (CSs) are those whose operation poses a risk to human life, health, economy or environment. Typically, CSs are large and complex industrial systems or products which have been constructed through the effort of multi-disciplinary teams. The engineering and assessment of modern CSs is thus complex, multi-disciplinary task, often involving mechanical, structural, and electronic and software engineers and psychologists. The skill of economists is needed; sociologists also have a role in addressing the interaction between complex systems and teams of operators. This module aims to introduce and critically analyse CSs. Requirements for the engineering of CSs will be introduced and the role of formal approaches in the life cycle of CSs will be explored. LEARNING OUTCOMES: Upon successful completion of this module, the student will be able to: • critically evaluate the current taxonomies of CSs including international standards; • critically evaluate the use of formal methods in the life cycle of CSs; • appreciate the essential issues of time-critical systems both at the specification and design

stages, including scheduling techniques; • critically evaluate the use of temporal logic for the engineering and re-engineering of CSs. SYLLABUS CONTENT: • Classification and analysis: examples, analysis, taxonomy, standardization efforts (UK,

Europe, USA). • Time-critical systems: what are they; technical issues (design and architecture, specification,

scheduling, reliability and dependability). • Role of formal approaches: software in CSs (and real-time); goals and objectives; assurance;

formal approaches in CSs life cycle; examples of formal approaches (model-based, logic-based, process algebras, refinement).

• Refinement, abstraction, and evolution: rationale and model (why, what is needed, computational model); interval temporal logic (syntax, semantics, tool (e.g. Tempura: executable subset); refinement calculus (the temporal agent model, algebraic laws, example); abstraction calculus (abstraction rules, example); evolution (guided evolution, example, tool (e.g. Ana Tempura)).



PRIVACY, ETHICS AND SOCIAL RESPONSIBILITIES (SE-O-05) AIMS: There continues to be a growth of databases holding personal and other sensitive information in multiple formats including text, pictures and sound. The scale of data collected, its type and the scale and speed of data exchange have all changed with the advent of information and communication technology (ICT). Whilst the potential to breach privacy continues to increase organisations are subjected to a considerable amount of legislation governing privacy and data protection. This module examines the balance between maintaining business effectiveness, legal compliance and professional practice in the field of IT (Information Technology) / IS (Information Systems). The module will address the legal, social and technological aspects of privacy and data protection, consider privacy enabling technologies and privacy invasive technologies identify and evaluate the role of the computer professional in providing privacy and data protection, and review privacy and data protection legislation from different countries. Care will be taken in ensuring perspectives from different cultures and countries are highlighted and considered in the light of global information systems. LEARNING OUTCOMES: Upon successful completion of this module, the student will be able to: • define the concepts of privacy and data protection within a multi-cultural and multi-

disciplinary context; • recognise and evaluate current and future threats to privacy; • outline and evaluate IS professional practice with regard to perceived professional and social

responsibilities to employers and data subjects; • research into an area of privacy and or data protection; integrate complex and sometimes

conflicting ideas into a coherent analysis that demonstrates integrative, synoptic and analytical skills.

SYLLABUS CONTENT: • Ethics: normative frameworks, values, analysis approaches. • Privacy: concepts of privacy, information privacy, information privacy legislative, privacy - the

global perspective / privacy enhancing technologies. • Trust: concepts and classification of trust; reliability. • Security: information security, surveillance. • Access: information access, software piracy. • Property: intellectual property, ICT espionage. • Social impact: social impact audit, cultural impact and ethnography, globalization. • Conduct: professional conduct, codes of conduct, information risk management. • Case studies. PREREQUISITES: None RECOMMENDED ASSESMENT: Coursework


APPLIED SYSTEM THINKING (SE-O-06) AIMS: The module presents a unifying philosophical approach to the post-graduate curriculum in Software Engineering. Applied systems thinking is used as a practical tool to view holistically organisations, information systems, and organisational change and integration. The aims of the module are: • To develop in students the knowledge of the use of systems models representing the

environment, in order to simplify problem solving in the real world and contemplate purposeful activity in business organisations.

• To develop in students an understanding of systems practice through practical application of tools, methods and techniques.

• To develop in students knowledge and skills relevant to the organisational intervention and management of change.

• To engender in students an understanding and appreciation of the uses of information technology to improve business performance at strategic and operational levels.

LEARNING OUTCOMES: Upon successful completion of this module, the student will be able to: • understand hard systems thinking concepts and their application to change situations in

business organisations; • apply soft systems methods and tools to provide a holistic approach to solving complex

socio-technical problems within organisations; • understand the key role of modern information systems in organisational integration within

the context of global marketplaces. SYLLABUS CONTENT: • Background: pace of change, integration and need for holistic approach for business. • Systems concepts and constructs: general systems theory; hard systems thinking for

organisational change; soft systems approach and its relevance to business organisations; viable systems model; systems thinking skills; creative thinking; visualising problems; power of team thinking.

• Organisation as an information system: data, information and knowledge; organisational decision-making; communication models; new economics of information;

• Organisational development and integration: nature of organisations and stages of organisational growth; process of organisational transformation and integration; impact of global markets and e-commerce and m-commerce on organisations.



BUSINESS MODELLING (SE-O-07) AIMS: This module is motivated by the belief that it better to develop the right product than developing the product right. Fundamental to achieving this is two-fold: • to be able to model and analyse business objectives and processes, and • to convert the business model to a requirement statement. For the former the module will utilise UML features and also introduces new features (such as contract diagram). The second item is dealt with by developing the Gap-Navigator which is a notion based on software refinement. In this module we will be addressing various business modelling including B2C (Business to Customer), B2B (Business to Business), … Throughout the module real-life case studies from real small and medium sized enterprises (SMEs) will be given. LEARNING OUTCOMES: Upon successful completion of this module, the student will be able to: • model businesses and business processes using UML; • assess current business practices and establish baselines for process improvement; • produce a model that accurately reflects the reality of business; • leverage established business patterns to solve commonly recurring problems; • develop effective and efficient communications strategies; • structure models to maximise organisational performance; • transfer a business model into a requirement model. SYLLABUS CONTENT: • Why model? • Assessment of business status. • Description of current business (various case studies and scenarios). • Identification of business processes. • Various business modelling including B2C, B2B, … • Business process realisation. • Interaction of use-case realisations. • Process automation. • Transition from business model to requirements model. PREREQUISITES: None RECOMMENDED ASSESMENT: Coursework and unseen paper


E-BUSINESS (SE-O-08)

AIMS: Current approaches to systems design and development such as the rational unified process, SSADM, Multiview or web-based approaches take a very centralised approach. There is a central database model defined early on, and an emphasis on centrally designed business processes. The emphasis is on fulfilling the processing demand of the business, not meeting the task-oriented needs of the client or user. Many e-commerce systems are targeted at external users. Hence there is a need for new approaches to system development which take a client oriented view, are much more bottom-up than top-down and seek to elicit client-views throughout the design process. This module explores the issues around such a transition from business focussed design to client focused design. The issues are developed through a study of usability engineering as a client-led development process. Usability engineering is gaining acceptance as a design approach which focuses on the customer needs and the customer view in preference to the business process demand. It is seen as a more fruitful approach to the design of ecommerce systems which are customer facing. Students explore the frameworks for alternative design approaches and critically evaluate the fit of usability engineering to the demands of design of e-commerce systems. The module further emphasises the importance of a research-based approach to systems design and explores current research in systems design, usability engineering and related cognitive sciences. LEARNING OUTCOMES: Upon successful completion of this module, the student will be able to: • critically appraise current approaches to systems design in comparison to the requirements of e-

commerce and distributed system design; • apply the techniques of usability engineering, within the process framework of ISO13407 to the

development of an e-commerce application; • critically evaluate approaches to measuring usability performance objectives and identify appropriate

approaches for given situations; • apply a range of supporting techniques derived from current literature to enhance the process of eliciting

usability requirements; • identify and describe technical and research trend which may influence approaches to client-led design. SYLLABUS CONTENT: • Characteristics of e-business systems and consequences for design: requirement for bottom-up

approach, focus on screens and tasks. • Critical analysis of top-down approaches to system design and development: properties of top-down

approaches such as Rational Unified Process (RUP). • Issues in distributed design. • Characteristics of an alternative design approach. • Alternative approaches which do not rely on top-down analysis and a pre-defined data structure:

exploration of other techniques for eliciting usability requirements and understanding tasks; joint application design; focus groups.

• Service-oriented human-computer interaction (HCI): applying service concepts to systems design. • Approaches to evaluating web usability: survey of the literature. • Nature of culture: effect of culture on usability. • Use of scenarios in usability engineering: construction of scenarios in e-business. • Continued evaluation of implemented e-business applications: approaches to getting feedback. • System integration and usability engineering: systems integration across e-commerce systems. • Future issues concerning web-based applications. • Dealing with change: autonomic systems and service-oriented computing; principles of self-evolving

systems; screen evolution and tailorability. • Comparing usability engineering and the RUP. • Alternative emergent environments: complexity; synchronicity and (e.g.) StarLogo. • Aspects of security in e-business applications. PREREQUISITES: None RECOMMENDED ASSESMENT: Coursework and unseen paper


BUSINESS PROCESS RE-ENGINEERING (SE-O-09) AIMS: To provide a greater understanding of effective solutions to change problems that need to combine technological, organisational and people-orientated strategies by adopting a process-based approach to change management. To introduce the contingencies that affect management and the most effective measures for dealing with them. To introduce strategic IS/IT planning and how it must relate to business strategy. To demonstrate the use and validity of organisational development models through current real-life case studies. LEARNING OUTCOMES: Upon successful completion of this module, the student will be able to: • understand the methods used to changing processes and the impact it has on company

culture, people and the integration with other information systems; • develop a strategic plan of IS/IT to support a business strategy aimed at providing an

organisation with competitive advantage; • manage information as a resource and have an understanding of systems development

lifecycle; • implement, evaluate and analyse strategic business change processes; • understand the benefits the learning organisations strategy can bring to knowledge based

organisations. SYLLABUS CONTENT: • Changing business processes: the importance of technology as a driver for organisational

change. • Change and the manager: change and the human resource: the cultural web and the past:

the cultural attributes of change. • The importance of communication and the resistance to change: building the culture for

successful strategy implementation; the influence IT will have on the internal appearance of organisations in the future.

• Business intelligence and the future of e-business. • The concept of the learning organisation and its influence on systems development:

examples of organisations that have been through minor change programs and the lessons that have been learnt.

PREREQUISITES: Business modelling RECOMMENDED ASSESMENT: Coursework and unseen paper


SERVICE QUALITY MANAGEMENT (SE-O-10) AIMS: The central role of software systems in an organisation is to provide applications, technology and services to support the business functions and contribute to the organisation’s strategic goal. This module takes a service view of software systems. The module explores the application of service management concepts to the delivery (of services) and to quality management. It examines operational issues surrounding the management of resources and computer capacity, the provision of help desk services and the management of IT assets. It considers the development of new services, the management of end-user computing and the development of IT service culture. An introduction to the disciplines required for BS15000 / ISO20000 IT service standards is provided. The subject area is considered in the context of a business environment where many IT services are provided by third parties and managed through contracts. The strategic role of systems and service in the organisation is developed by exploring the alignment of information systems and the organisational strategy. An understanding of the strategy of an organisation leads to the development of a portfolio of systems and services which matches the objectives of the organisation and delivers competitive advantage. Frameworks and approaches to developing such an understanding of the strategic role of information systems are considered. LEARNING OUTCOMES: Upon successful completion of this module, the student will be able to: • formulate an IS/IT strategy which aligns the provision and management of the IS portfolio with

organisational goals and strategies; • discuss the theory and practice of managing IT services within a defined framework of

disciplines and activities; • explain the effect of context, organisational relationships and organisational structure on the

delivery of IT services. SYLLABUS CONTENT: • IT service fundamentals: what is a service; nature of services; moments of truth; front office

and back office; service components; IT service quality; IT service marketing; IT service innovation.

• IT service strategy: IT/IS core competences and the resource-based view of the firm; developing a service-oriented IT strategy; IT strategy process; understanding business strategy; tools for relating business strategy to IT strategy; managing the application portfolio; auditing, classifying, identifying new systems; role of IT in competitive strategy; finding strategic information systems; IT procurement strategy; globalisation issue in strategy and outsourcing.

• IT service governance: organisational role of IT services; structuring the IT organisation (centralised, decentralised, federal); reporting structures and the balanced score card; justifying IT services in the organisation; CoBIT (Control Objectives for Information and Related Technology) and IT governance.

• IT service context: managing end-user computing; IT strategy and services in SMEs; organisational and service culture; effect of organisational power on strategy and services; globalisation; enterprise resource planning (ERP) systems; future trends; autonomic computing.

• IT service operations: managing the IT helpdesk; rationing IT services; incident management; problem management; release management; information requirements for IT service management; capacity management; managing and controlling IT assets; availability management; service level agreements – their creation and management; The IT service catalogue; IT service security issues; configuration management service issues; global IT service operations.

• IT service process: IT service frameworks (ITIL and BS15000); the BS15000 certification process; implementing IS/IT strategy and the role of IT strategy documents



SOFTWARE ENGINEERING FOR DATABASE SYSTEMS (SE-O-11) AIMS: The module provides theoretical basics for understanding of modern DBMS and their integration into information systems. It stimulates a systematic approach for practical implementation of database (DB) based applications by team work and by using of experience repository. LEARNING OUTCOMES: Upon successful completion of this module, the student will be able to: • critically evaluate the different DBMS and their features; • appreciate the need and different possibilities for DB integration; • complete implementation of selected case study from the Experience Repository. SYLLABUS CONTENT:

• DB Taxonomy: DBMS models and architectures; DB aspects (relational, procedural, object-

oriented, descriptive (XML), deductive); persistent objects; DB integrity. • DB integration: language-oriented (embedded SQL - Structured Query Language); driver-

oriented (ODBC - Open Database Connectivity, JDBC - Java Database Connectivity) (architectures, driver types, application scenarios); component-based; SOA (Simple Object Access) integration; agent-based.

PREREQUISITES: None RECOMMENDED ASSESMENT: Coursework


ADVANCED TOPICS IN SOFTWARE ENGINEERING (SE-O-12) AIMS: The aim of this module is to provide an insight into the freshest research directions and achievements in the field of software engineering that are not covered in the rest of the modules. LEARNING OUTCOMES: Upon successful completion of this module, the student will be able to: • appreciate the need to learn new theories, models, techniques and technologies as they

emerge; • appreciate the necessity of continuing professional development and application of newest

research achievements in the practice. SYLLABUS CONTENT: Various advanced research topics will be covered by internal or external experts including agent technology, bio-informatics, health informatics, pervasive computing… The content of the module will vary yearly depending on current trends and advances. PREREQUISITES: None RECOMMENDED ASSESMENT: Coursework


PROJECT AIMS: This module is intended to provide the student with the experience of developing a substantial piece of individual work, from concept to completion. For this, the student will have to identify the skills and knowledge necessary for a successful completion, acquire them by personal study and employ them appropriately. Time constraints will ensure that students will acquire skills in time management and in scheduling and managing inter-related tasks. Good presentational skills, written and oral, will be essential for the student's description of the work undertaken. Students are encouraged to undertake projects in association with industrial, commercial or public service sponsors. Part-time students are particularly encouraged to undertake, where possible, the project at their place of work. Learning approaches: supervisory teams will provide guidance as and when necessary. However, it is to be emphasised that the student is expected to drive the project, to take responsibility for the acquisition of necessary skills and knowledge and to ensure that tasks are completed within the agreed timescales. LEARNING OUTCOMES: Upon successful completion of this module, the student will be able to: • produce terms of reference for a project to be undertaken; • construct a project from unstructured ideas through critical analysis of the problem area • identify skills which are necessary for a successful completion of the project; • identify a reasonable course of action for making good any deficiency in expertise which is

identified as necessary for the project, and pursue it effectively; • employ good time-management practice in the pursuit of the project; • schedule tasks appropriately so that the available resources are fully utilised; • conceive, design, implement and deliver a software system in an organised, repeatable way; • present written reports in a manner appropriate to the demands of the project, in particular, a

formal presentation of material as demanded in an academic medium such as a journal or set of conference proceedings;

• make an oral presentation describing the project, using appropriate technology, and be able to answer questions on it from an informed audience.

SYLLABUS CONTENT: • Semester 1. Students consider the subject area in which they would like to undertake a

project. If students are arranging their own project, particularly with an external agency, such as a local company, they should start discussions about the scope and content.

• Semester 2. At the beginning of semester 2, internal projects are described; students investigate the possibilities in discussions with the project co-ordinator and the project proposer (who will often, subsequently, be the project supervisor).

• Semester 3. Students complete their terms of reference, in collaboration with their project supervisor and then complete all outstanding work on the project.

PREREQUISITES: Passed all exams

RECOMMENDED ASSESMENT: Coursework, written and approved thesis, and oral public presentation


Glossary Basic terms Assignment A task given to students to solve, usually during the delivery of a module. Assignments are usually to be solved over a fixed period of time, in students teams or alone. Assignments are usually a part of an assessment strategy for the module. Bologna Declaration The Bologna declaration is the main guiding document of the Bologna process. It was adopted by ministers of education of 29 European countries at their meeting in Bologna in 1999. The main goal of the Bologna process is to harmonize university education in Europe, with respect to various aspects (principles, degrees, credit system,…). Contact hours The number of hours where the instructor(s) and the students are present and interact face-to-face (as opposed to the distance learning, student’s self-study, etc.). Contact hours usually cover lectures, seminars, tutorials, consultations, etc. They are expressed on a ‘per week’ basis. Core module (In our curriculum) is a module that presents basic knowledge of the curriculum (i.e., to the field of study) and, thus, is obligatory for the students (as opposed to the optional module). Curriculum aka “programme of studies”. The set of modules and their contents offered by an institution such as a school or university. For further information, see Module, Module template, and Detailed module template. Detailed module template It refines and details the module template (see Module template) in which the requirements of a module are defined. Besides aims, learning outcomes, and contents which are already part of a module template, it also contains a precise assessment strategy, examination criteria, prerequisites, the way to deliver the contents (lectures, tutorials, practical work, …), reading material, supporting literature, etc. ECTS European Credit Transfer (and Accumulation) System is a method that is used to compare the marks given in higher education across Europe. ECTS-credit is a unit of measure of a student’s workload needed to complete the module. One academic year corresponds to 60 ECTS-credits in all countries irrespective of standard or qualification type and is used to facilitate transfer and progression throughout Europe. 1 ECTS-credit is equivalent to 20-30 hours of the total students workload (depending on the country). Induction layer A set of modules that the institution offers to students that do not have enough pre-knowledge to enrol the studies. It can be implemented as given (e.g., in this document) or by finding appropriate equivalents in existing modules within an institution. Lecture Notes Notes for the instructor (lecturer), i.e., to a person that delivers the module. It usually contains additional technical and methodological information on the subject, how to deliver the lecture, what are suitable topics for discussion with students, etc.


Module aka “course” or (in some parts of Europe) “subject”. A module specialises on a specific part of the curriculum, has a name, usually spans over a semester (or term) and ends with an assessment of students’ achievements. A module is usually described by its aims, learning outcomes, and contents (see Module template and Detailed module template). Module template A module template is a requirement that the development and delivery of a module must satisfy. It usually defines the aim, learning outcomes, and contents of the module. See also Detailed module template. Optional module As opposed to the Core module, an optional module can be freely chosen by the student during her studies. It usually implements non-core subjects of the field of study and allows students to specialise in some sub-field according to their needs. Study pack A set of teaching materials that fully support the delivery of the module. It contains presentation material (e.g. PPT slides), lecture notes, a set of assignments and solutions, a set of (practical and theoretical) exercises with solutions, set of possible questions for the final exam... Terms related to quality assurance and control Coursework Work carried out by students while they are studying a module. Coursework contributes towards students’ overall mark, but is assessed separately from their final exams. Coursework can, for example, take the form of solving the assignments, write book reports, write essays, etc. Curriculum handbook Document that describes the whole curriculum in general, i.e., its rationale, set of modules with module templates, costing and resource issues, etc. (Detailed) Module templates handbook Document that contains the set of all detailed module templates of the curriculum. Dry-run A delivery of the module to a selected audience, usually members of the teaching staff. The purpose of the dry-run is to collect ideas and suggestions for possible improvements of a module. External examiner Person outside of the home institution appointed to monitor the implementation of assessment strategy of a module and to ensure that the quality of the assessed work complies with certain standards. External examiner is an experienced academic or industrialist. To fulfil her task, external examiner must collaborate with technical editor of the module and possibly advise him on some aspects of the module. Instructor aka “Lecturer”. Person delivering the module to the audience. Module developer Person that develops the teaching material of the module (i.e., the study pack). It is not necessary that this person is also an instructor of the module. Module feedback form The form that students are asked to fill in at the end of each module delivery. These are


collated, analysed and reported to the module technical editor. Staff handbook Document that contains the CVs of all instructors of modules of the curriculum. Student handbook Document that contains everything that students need to know, from the course regulation, modules, staff, libraries, web sites, etc. Technical editor (of a module) Person that is responsible for the technical direction and evolution of the module(s) in his/her subject area. Technical editor is expert in the field to which the module belongs and is not the module developer of that module. Unseen paper Examination technique in which students answer questions or solve the problem without any supporting literature or external help. Validation panel A group of academic peers that scrutinise the proposed curriculum in the process of curriculum validation. Validation panel usually works during a specially organized validation event. A panel must have external members (academics and/or industrialists).


The list of abbreviations ABAS Attribute Based Architectural Style B2B Business to Business B2C Business to Customer CASE Computer Aided Software Engineering CBD Component Based Development CMM Capability Maturity Model CoBIT Control Objectives for Information and Related Technology COCOMO COnstructive COst Model CORBA Common Object Request Broker Architecture COTS Components Of The Shelf CRC Class-Responsibility-Collaboration CS Critical System CV Curriculum Vitae DB DataBase DBMS DataBase Management System DSDM Dynamic Systems Development Method ECTS European Credit Transfer System EE External Examiner EJB Enterprise Java Beans ERP Enterprise Resource Planning ETHICS Effective Technical and Human Implementation of Computer-based Systems EU European Union HCI Human-Computer Interaction ICT Information and Communication Technology IDL Interface Description Language IS Information System ISD Information Systems Development ISO International Organisation for Standardisation IT Information Technology JAD Joint Application Development JDBC Java DataBase Connectivity MSc Master of Science NATO North Atlantic Treaty Organization ODBC Open Database Connectivity OO Object-Oriented PhD Philosophiae Doctor (doctor of philosophy) PRINCE PRojects IN Controlled Environments RAD Rapid Application Development RUP Rational Unified Process RMI Remote Method Invocation RPC Remote Procedure Call SAAM Software Architecture Analysis Model SE Software Engineering SEI Software Engineering Institute (at Carnegy Mellon University) SME Small and Medium sized Enterprises SOA Simple Object Access SOAP Simple Object Access Protocol SQL Structured Query Language SSADM Structured Systems Analysis and Design Methodology TE Technical Editor UDDI Universal Description, Discovery and Integration UK United Kingdom UML Unified Modelling Language USA United States of America USDP Unified Software Development Process WSDL Web Services Description Language WSL Wide spectrum language XML eXtensible Markup Language XP eXtreme Programming


Version history Document name Date

This document (Curriculum specification, 2nd release)

May 25, 2006 Accepted during the 2nd project workshop in Skopje, April 3-6, 2006 and is based on the review done by European Software Institute.

Electronic version: http://perun.im.ns.ac.yu/msc-se/partners/work/02/MScSE-curriculum-rel2.doc Curriculum Nov. 17, 2005 Accepted during the 1. project workshop in Novi Sad, Oct 17-21, 2005. Electronic version: http://perun.im.ns.ac.yu/msc-se/partners/work/02/MScSE-curriculum.doc Draft curriculum Aug. 23, 2005 Working material for the 1. project workshop Electronic version: http://perun.im.ns.ac.yu/msc-se/partners/work/02/workshop/MScSE-draft-curriculum.zip

Documents

Curriculum specificationrti.etf.bg.ac.rs/rti/projekti/tempusmirror/results/...o principles for the development of modules. All mentioned items are described in this document. This