Curriculum

Comment

To create a joint joint curriculum of master studies in software engineering proved to be the challenging task because it should be developed for and accepted by:
a) four institutions with different expertise, tradition, and ‘nature' (technical vs. science institutions);
b) in two different countries;
c) under transitional legislations (‘old' vs./and ‘new' higher-education laws); and
d) concurrently with undergoing reforms of undergraduate studies in each institution.

Nevertheless, the project consortium successfully resolved all difficulties and adopted the curriculum that is at the same time firm and joint, while containing enough flexibility to be adjusted by each individual institution according to its needs, pre-knowledge of students, undergraduate reforms, and tradition.

- Full document describing all aspects of the curriculum, release 3 (pdf)

- Full document describing all aspects of the curriculum, release 2 (pdf)
- Full document describing all aspects of the curriculum, release 1 (pdf)

- Serbian translation of release 1 (pdf)
- Macedonian translation of release 2 (pdf)

The curriculum has been accepted by:

- University of Novi Sad, in May 2006. Studies started in October 2006 (the adopted curriculum).
- University Ss. Cyril and Methodius, Skopje in November 2006. Studies started in February 2007 (student enrollment for 2007 - see 2nd page)
- University of Belgrade, in September 2006. Studies started in October 2007 (the adopted curriculum)
- De Montfort University, Leicester in June 2007. Studies started in October 2007 (the adopted curriculum)

The rest of this page contains only highlights of the curriculum. For the full information, please see one of the above two documents.

---

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.

Learning outcomes of a successful MSc student of joint programme

• Show mastery and critical thinking of the SE knowledge and skills and professional issues necessary to begin practice/research as an SE.
• 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, analyses, 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.

Structure of the curriculum

• The value of master studies will be 90 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 1 st semester for students without enough pre-knowledge
• First semester: Core modules (30 ECTS)
• Second semester: Elective 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.

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 (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 3 rd Semester. At the beginning of semester a condensed module on selected topics in project management is delivered to students.

Principles for instantiation of curriculum by the institution

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.

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 . quality assurance of study packs.

1. Curriculum Validation

1. Validation is the process by which an academic institution establishes that a new curriculum is
2. academically viable ,
3. that academic standards have been appropriately defined and
4. that the students have the best opportunity to learn .
5. A validation event should be organised in which a validation panel of academic peers scrutinise the proposed curriculum.
6. A panel must have external members (academics and/or industrialists).
7. 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.) .
8. 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).

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. 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.
3. Any changes in the module must be approved by the TE in charge and be reflected in the template itself.
4. Modules go through minor and major revisions on an annual basis.
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.
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 .
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 .
8. A module is retired if its objectives do not fit the purpose it was originally believed.

3. Module Assessment

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.
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. 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

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.
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.
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.