CS251

(Undergraduate - Level 2)

Software Engineering 1
an Introduction to Software Engineering

Lecture 0
Module Outline
.. & .. An Introduction to Software Engineering

1
 Module Information ..
❑ Instructor: Dr. Amr S. Ghoneim

Short Bio: Amr S. Ghoneim, received the B.Sc., pre-M.Sc., and M.Sc.
(by research) degrees in computer science and information systems
from Helwan University, Cairo - Egypt, in 2002, 2003, and 2007,
respectively. He completed his Ph.D. in 2012 from the School of
Engineering and Information Technology (SEIT), University of New
South Wales at the Australian Defence Force Academy (UNSW@ADFA),
Canberra - Australia, where he was a member of the Artificial Life and
Adaptive Robotics Laboratory (ALAR). Since 2002, he is with the
Department of Computer Science at Helwan University, Cairo - Egypt,
where he is currently an Assistant Professor. His research interests
include the areas of artificial / computational intelligence, machine
learning, ensemble learning, image processing, pattern recognition,
statistical analysis, and evolutionary computation. He is currently an
also an Adjunct Assistant Professor at the School of Informatics and
Computer Science, the British University in Egypt.
2
 Module Information .. (Continued)
❑ Indicative Reading List (textbooks):
Textbook:
• Ian Sommerville, "Software Engineering (9th Edition)", Addison Wesley,
ISBN: 978-0137035151, 2010.
For OO Design Principles, Analysis & Design, UML Modelling:
• Bernd Bruegge, Allen H. Dutoit , Object-Oriented Software Engineering:
Using UML, Patterns and Java, 3rd Edition, Prentice Hall 2009.
For the Design Patterns:
• Vlissides, J., Helm, R., Johnson, R. and Gamma, E., 1995. Design patterns:
Elements of reusable object-oriented software. Reading: Addison-Wesley.
And / Or
• Freeman E, Freeman E, Robson E, Bates B, Sierra K. Head first design
patterns. O'Reilly Media Inc., 2004.

3
 Course Logistics
o Course Materials & Announcements

o Assessment Summary (Grading Policy)

o Academic Integrity & Plagiarism

4
 Course Materials & Announcements
All course material (lecture notes “slides", announcements,

assignments, any supplemental notes or documentation), will be

made available (posted) online on weekly basis, on the webpage:

https://www.facebook.com/amr.s.ghoneim/

and .. the Google Drive Folder:

https://drive.google.com/drive/folders/1JUYkrThuNraxMuIl6ffgJG_5

nmfpxXxR?usp=sharing 5
 Course Materials & Announcements
Lecture Recordings will be made available on weekly basis, on the

YouTube Channel:

https://www.youtube.com/AmrSGhoneim

6
 Assessment Scheme
[ General Programme]
❑ Group Practical Project (2 phases): 25%
• The grades include an Individual Assessment.
• The final submission includes 10,000 words (approx.) report +
the detailed diagrams for software modelling + code
(implementation)

❑ Midterm Written Test: 15%

❑ Final Written Exam: 60%

7
 Assessment Scheme
[ Medical Informatics Programme]
❑ Group Practical Project (2 phases): 30%
• The grades include an Individual Assessment.
• The final submission includes 10,000 words (approx.) report +
the detailed diagrams for software modelling + code
(implementation)

❑ Midterm Written Test: 20%

❑ Final Written Exam: 50%

8
 Academic Integrity&Plagiarism
o You can discuss ideas and methodology for the homework
(assignments / sheets) with other students in the course, but
you must write your solutions completely
independently.

o We will be code-checking to assess similar submissions or

submissions that use code from other sources.

9
 Group Project
Register with the TA(s); Your group members, & the project idea, by
the end of week 3.

To apply the concepts discussed in lectures the student will get engaged in a
practical project.

Project Ideas: The students will have the choose from a list of ideas that will be
announced soon, but they have the freedom to present and adjust the
requirements of their selected project.

The students will be required to perform a 10-15 min demo of their project
during the final discussion.

10
 Group Project
Tentative/Indicative Project deliverables:

Week 4: (Part of registering the project – ungraded)

A report of 200 -500 word indicating the following:
• Project idea
• Main functionalities
• Similar applications in the market
• Development platform

11
 Group Project
Tentative/Indicative Project deliverables:

Week 8: (Phase I Submission)

UML design document indicating the following:
• Functional Requirements
• Non-Functional Requirements
• System Architecture
• Activity Diagram(s)
• Use-Case Diagram(s) – including general use-cases for the system, and
the detailed use-cases description
• Database Specification
• Class Diagram (Interfaces, Classes, Relations)
• Snap shots of User Interface 12
 Group Project
Week 12: (Phase II Submission)
UML Final design document/report indicating the following:
• Sequence Diagram(s) including System Sequence Diagrams (SSDs)
• Collaboration/Communication Diagram(s)
• Class Diagram (3 versions)
1) An initial version based on the requirements and Use-Case/Activity
diagrams. 2) An intermediate version based on the interaction
diagrams. 3) A final version, after applying the design pattern(s) and
any other modifications.
• Package Diagram(s)
• Test plan and Test cases performed
• 1 Mandatory Design Pattern Applied (Including a typed description)
• Bonus: Additional Design Patterns (Including a typed description)
13
• .. + (continued in the following slide)
 Group Project
Week 12: (Phase II Submission) – Continued
Implementation (code) based on the submitted Requirements & Design.
Should include at least 4 of the following modules (in addition of course to
modules specific to your individual projects):
1) User Role Management Module.
2) User manipulation Module (Login, Add / Delete / Update / Search, List).
3) Controlling Resources Module (Rooms, Orders, Products, ... etc.).
4) Reservation and Rescheduling Module.
5) Generating Reports Module (PDFs, … etc.).
6) Sending Emails or Notifications Module.
N.B. You must update and resubmit the initial part of the documentation
submitted in phase 1 (including the Functional / Non-Functional
requirements, Use-case Diagrams & Descriptions, Activity Diagrams, ..
etc.). 14
 What is expected from you?
• Attend the class regularly.

• Study and learn the material presented in the class

(and refer to your reading list).

• Do the group project.

• Perform well in the exams & quizzes.

• Don’t cheat (Plagiarism).

15
 Tentative Weekly Plan
Week 1: Lecture 0: Module Outline, Introduction to Software Engineering
Week 2: Lecture 1: Software Processes & Development Life-Cycles
Week 3: Lecture 2: Requirements Engineering
Week 4: Lecture 3: From Domain to Requirements; Use-Case & Activity
Diagrams
Week 5: Lecture 4: Introduction to UML, OO Modelling, & Class Diagrams
Week 6: Lecture 5: OO Modelling, UML Static Diagrams (Class, Object, &
Package Diagrams)
Week 7: Midterm Written Exams
Week 8: Lecture 6: OO Modelling, UML Interaction Diagrams (Sequence,
Collaboration, & System Sequence Diagrams)
Week 9: Lecture 7: Reuse in SWE - An Introduction to Design Patterns
Week 10: Lecture 8: Reuse in SWE - An Introduction to Architectural Patterns
Week 11: Lecture 9: A Brief Introduction to Testing
Week 12: Lecture 10: Additional Selected Topics in SE and/or Revision 16
 Why .. Software Engineering?
• The economies of ALL developed nations are
dependent on software.
• More and more systems are software controlled.
• Software engineering is concerned with theories,
methods and tools for professional software
development.
• Expenditure on software represents a
significant fraction of GNP (Gross National Product)
in all developed countries.

17
 Why .. Software Engineering?
• The Standish Group has been publishing reports on the
success of software projects since 1994. In its latest report
(2012) it identified that:
– Only 39% of all projects were being delivered on time, on
budget, with the required features and functions.
– .. 43% were late, or over budget, or not delivering all the
required features.
– .. 18% were either cancelled before delivery or delivered but
never used.
• In those reports, the major problems have been identified.
Among these problems were the following:
– Poor, or lack of, user involvement.
– Lack of clear business objectives.
– Under and over building – building features that are never used
and not building all the required features.
18
 Frequently asked questions about SE
Question
• Answer
What is software?
• Computer programs and associated documentation. Software products
may be developed for a particular customer or may be developed for a
general market.
What are the attributes of good software?
• Good software should deliver the required functionality and performance
to the user (useful) and should be flexible, usable, reliable, available,
affordable, and maintainable (greatly influenced by how it is designed and
written).
What is software engineering?
• Software engineering is an engineering discipline that is concerned with
all aspects of software production.
What are the fundamental software engineering activities?
• Software specification, software development, software validation and
software evolution. 19
 Frequently asked questions about SE
What is the difference between software engineering and computer science?
• Computer science focuses on theory and fundamentals; software engineering
is concerned with the practicalities of developing and delivering useful
software.
What is the difference between software engineering and system engineering?
• System engineering is concerned with all aspects of computer-based systems
development including hardware, software and process engineering. Software
engineering is part of this more general process.
What is a System boundary?
• a conceptual line that divides the system that we wish to study from
‘everything else’, (scope of a system).
What is a System’s environment?
• It is made up of those things which are not part of the system, but which can
either affect the system or be affected by it.
What is a domain?
20
• It is a particular area of interest.
 The Important Characteristics of
Software that affect its Development
• Malleability: Software is easy to change. This malleability
creates a constant pressure for software to be changed rather
than replaced.
• Complexity: Software is often complex. Complexity can
usually be recognized, but it is less easy to define. One item of
software can be considered more complex than another if the
description of the first requires more explanation than that of
the second. If complexity is increased, errors will be
increased.
• Size: It is likely that there will be more errors in a large piece
of software than there will be in a small one..

21
Thanks! .. Questions?

22