Seminar: Software Product Families, Variability Management
| Year | Semester | Date | Period | Language | In charge |
|---|---|---|---|---|---|
| 2015 | autumn | 07.09-07.12. | 1-2 | English | Juha Tiihonen |
Lectures
| Time | Room | Lecturer | Date |
|---|---|---|---|
| Mon 16-18 | C220 | Juha Tiihonen | 07.09.2015-12.10.2015 |
| Mon 15-19 | C222 | Juha Tiihonen | 30.11.2015-30.11.2015 |
General
Software Product Families a.k.a. Software Product Lines aim to provide individual products (product variants) quickly, at low-cost and in high quality. To achieve this, reusable assets such as requirements, architecture, source code, and tests are developed in a process called domain engineering. Another main process, application engineering or product derivation, develops or configures individual product variants based on the assets. Software product lines can support business based on mass customization strategy as well as adapting software to different use scenarios or equipment (embedded software, higher level control applications).
Variability represents the planned differences between the product variants. Variability Management is a foundational asset for Software Product Families: planning, representation and management of variability is vital in both efficiency in domain and application engineering processes. Commonality and variability must be efficiently and effectively handled. Significant research effort has been invested on software variability modelling. Major approaches include feature modelling, orthogonal variability modelling, and decision-oriented approaches. Some variability modelling approaches have well-defined conceptual models and corresponding representations that make it possible to provide intelligent support for Variability Management. For example, it is possible to support the specification of product variants or analyse properties of variability models that capture the variability of a product line.
The topic of a seminar work can be methods or tools that support or are needed for successful software product families or variability management. Topics can be in the context of domain or application engineering or their sub-processes (e.g. domain/application requirements/design/realization/testing, product management). Topics in the context of variability management methods and tools (including their comparison) are especially welcome.
The seminar work can be based on literature, but searching for possibilities of investigating and reporting experiences or practices from real software companies or other development organisations are highly encouraged.
Completing the course
The seminar will be organised close to the format of a scientific software engineering conference with peer-review practice. The course uses the conference acronym SoFVar 2015.
Each participant writes a scientific paper (at least in the form and style) and submits it to the "conference" of the course. The paper will be peer-reviews by course staff and other seminar participants. In addition, everyone presents the paper as in a conference, if the paper is accepted.
The course will use EasyChair conference management system (conference address: https://easychair.org/conferences/?conf=sofvar2015) in which paper, reviews and revised paper will be returned. Details on accessing and using the system will be given in the beginning of the course.
The paper will be formatted using IEEE conference template, which can be found from http://www.ieee.org/conferences_events/conferences/publishing/templates.html. A suitable length of a seminar paper in this format is 6-10 pages.
The schedule for course sessions is initially as follows (these will be discussed in the first session and may change). Participation to all sessions is compulsory.
September 7, Opening, introduction
September 14, Introduction to scientific writing in the seminar, conference submission and review process. Topic assignment.
October 12, Feedback session
November 30, Conference day I
December 7, Conference day II
Instructions for Presentations
Each presentation is exactly 20 minutes. Think carefully what to include and how much presentation material can be included.
Discussion
After each presentation there are (X, TBD) minutes for discussion in which all are expected to actively participate.
Course Schedule (Deadlines, subject to change)
The course has the following main phases and deadlines (to be confirmed). All deadlines are at 12 noon. The deadlines are strict!
September 28. Extended abstract deadline. Write an extended abstract of your topic and return it to EasyChair (fulfil the web form, as a pre-submission abstract). It is good idea also already to prepare the IEEE template (remove all comments and instructions from the template). The extended abstract must contain as structured elements objectives of the study, data sources, selection criteria for primary studies. In addition, main references must be included.
October 19. Bidding deadline. You should mark your interest to review other's papers, called bidding, based on the extended abstracts.
November 9. Full paper deadline. Return a complete version of your seminar work to EasyChair. In the IEEE template, 6-10 pages. Note that you should return your work as a "update" to your abstract, not as a new submission (if that for some reason were possible).
November 12. Allocation of reviews done by course staff based on your bidding. You will be invited to review the papers allocated to you through EasyChair.
November 23. Review deadline. Read the papers allocated to you and return your evaluation to EasyChair as instructed at the beginning of the course. By this deadline, the course staff will also decide if some papers are rejected.
November 30 and/or December 7. Conference. The presentation sessions of seminar papers.
December 21. Optional revision deadline. You have an opportunity to revise your seminar paper on the basis of the reviews from others and discussion at the presentation session. The final grading is done based on the versions that are in EasyChair at this deadline. (You may note that this deadline is different than in a typical conference, in which the camera-ready deadline is after the reviews but well before the conference so that the final, revised papers are already available at the conference)
Grading
The grade for the seminar is given based on the written paper (40%), reviews given to other students and activity in the course (30%) and presentation (30%).