SE 322: Software Intensive Systems Engineering הנדסת מערכות עתירות תוכנה
Course, Kinneret College on the Sea of Galilee, Software Engineering, 2026
Semester 2, 5786
Course Details
- Lecture: Thursdays 10:00–12:00 in Room 817
- Instructor: Michael J. May
- Email: mjmay (at) mx; kinneret, ac, il
The full detailed syllabus of the course is available here.
Topics:
This course leads students on the transition from the world of programming (writing computer programs) to the world of software engineering where we develop software intensive systems (SIS). We will focus on the development life cycle - requirements, analysis, design, implementation, integration, testing - while maintaining a systems approach. Students will also perform exercises in model based software development using the Unified Modeling Language (UML).
The course will be taught as a “seminar class” in which lecture and practice are interwoven. A typical session will consist of 2–3 hours of lecture and 1–2 hours of student active practice of the techniques presented. Some sessions will be entirely dedicated to practice.
Course Goals:
At the end of the course the student will be able to:
- Define life cycle options (Waterfall, V, Agile) for the development of software intensive systems.
- Build a requirements table categorized by requirement type (functional, non-functional) and class (e.g. hardware, implementation)
- Create Use Case Diagrams and Use Case details for software intensive systems
- Design a set of logical software components based on a user story and a set of use case details
- Allocate logical components to physical components as part of a software intensive system deployment
- Create and document the physical, logical, and composite architectures of software intensive systems.
- Create a plan for the development of object-oriented programs based on classes and object interaction.
- Create, understand, and update UML diagrams for all of the above tasks.
Reading
The following books are used in the class:
- Roger Pressman and Bruce Maxim. Software Engineering: A Practitioner’s Approach. McGraw-Hill Education, 9th edition, 2020.
- James Rumbaugh, Ivar Jacobson, and Grady Booch. Unified Modeling Language Reference Manual. Addison-Wesley, 2nd edition, 2005.
- Steven Schach. Object Oriented and Classical Software Engineering. McGraw-Hill Education, 8th edition, 2011.
- Martina Seidl, Marion Scholz, Christian Huemer, and Gerti Kappel. UML @ Classroom: An Introduction to Object-Oriented Modeling. Undergraduate Topics in Computer Science. Springer, 2015.
- Hassan Gomaa. Software Modeling and Design: UML, Use Cases, Patterns, and Software Architectures. Cambridge University Press, New York, N.Y, 1 edition, 2011.
The library has copies of the books listed, but students are encouraged to purchase the books as needed.
Semester Project
During the course of the semester, you will develop a project in stages. There are two submission milestones for the project that will be shown in class.
The project will involve the design and partial development of a software system. There will be two intermediate design reviews in class and a final submission. The grade will be a combination of grades from the in-person design reviews and the final project submission.
The project overview file here explains the background for the project and its various stages. The project submission stages are as follows:
Stage 0 (0%): Customer and Stakeholder Story. Due: 25 March 2026
Stage 1 (15%): Design iteration 1 and Design review 1. Due: 6 May 2026
Stage 2 (15%): Design iteration 2 and Design review 2. Due: 10 June 2026
Stage 3 (70%): Project Final Submission. Due: 26 June 2026
Each project can be done in groups of four or five students.
Project stage instructions, formats, and examples are on Moodle.
Grading Criteria
Final grades will be calculated by combining grades from the project stages. The grades are weighted as follows:
- 100% Semester Project
Lecture Slides and Notes
| # | Date | Topic | Subjects | Slides |
|---|---|---|---|---|
| 1 | 12 Mar | Introduction | What is Software Engineering? Software’s Special Issues | |
| 2 | 19 Mar | Developing SIS, Requirement elicitation in SIS | Software from a Systems Perspective, Development Life Cycles and Patterns, Modelling, Gathering & Categorizing requirements | |
| 3 | 26 Mar | Requirement elicitation and management in SIS, System process definition | Managing Requirements, Building a Requirements Table, Use Cases | |
| 4 | 16 Apr | System process definition | Use Case Identification, Use Case Diagrams and Specification | |
| 5 | 23 Apr | System process definition | Writing Use Case Specifications, Activity Diagrams, Activity Model and Business Logic | |
| 6 | 30 Apr | System physical architecture | Physical architecture | |
| 7 | 7 May | Design review 1 | ||
| 8 | 14 May | Functional analysis and software process definition | Functional Analysis, Decomposition to Components | |
| 9 | 28 May | Software architecture and overall system architecture | Sequence models, Component model | |
| 10 | 4 June | Overall system architecture, Object Oriented Software Design | Composite model, PDOM, Class Model | |
| 11 | 11 June | Design review 2 | ||
| 12 | 18 June | Testing | Class Model, OOP | |
| 13 | 25 June | Design Improvement Principles | Static Testing, Design Patterns, SOLID |
Academic Integrity
Cheating of any sort will not be tolerated. Student collaboration is encouraged, but within limits as set forth in the college’s rules on academic integrity. Any students caught cheating will be immediately referred to the department head and the Dean and may receive a failing grade for the course.
Cheating includes:
- Copying information, content, or verbatim text from other students, internet sites, books (other than the ones listed in the bibliography), other unaffiliated individuals to answer questions, solve problems, or aid in programming projects.
- Copying or submitting source code, documentation, or other programming aids without attribution from other students, web sites, online repositories, text books, open source programs, or other unaffiliated individuals.
- Project teams which submit work which is identical or substantially identical to work submitted by other project teams, whether current or from previous years.
- Other forms of academic misconduct as described at this link or as reasonably assessed by the instructor, program head, or dean.
If you have any questions about what constitutes cheating in the above rules, contact the instructor as early as possible.