Assoc. Prof. Dr. Ayşe TOSUN Assoc. Prof. Dr. A.

Cüneyd TANTUĞ
Istanbul Technical University
Faculty of Computer and Informatics
2023
1. Course Introduction
2. Software History and Problems
3. Project Scope – How to begin a project?

 1.1 
 BLG411E – Software Engineering
o Credits: 3-0-0
o ECTS: 8
o Course Web Site : www.ninova.itu.edu.tr
• Lecture notes, announcements, report templates and examples, tools, etc.

2023-2024 Fall Semester

Instructor Assoc. Prof. Dr. A. Cüneyd TANTUĞ Assoc. Prof. Dr. Ayşe TOSUN
www.tantug.com https://web.itu.edu.tr/tosunay/
Lectures Tuesday, 13:30-16:30 Tuesday, 13:30-16:30
Office Hours With appointment via Zoom With appointment
Teaching Ayşe SAYIN
Assistants Esra ERGÜN
Kıymet KAYA
Serra UYSAL

1.3
Software Engineering: Object-Oriented and Object-Oriented Software
A Practitioner’s Approach Classical Software Engineering: Practical
Engineering Software Development Using
Roger S. Pressman,
Stephen R. Schach, UML and Java
Bruce R. Maxim T. Lethbridge, R. Laganiere,
8th ed. McGraw-Hill, 2010
9th ed. McGraw-Hill, 2019 2nd ed. McGraw-Hill, 2004

1.4
Other Books • Software Engineering
Ian Sommerville, 10th ed., Addison Wesley, 2017
• Yazılım Mühendisliği
Erhan Sarıdoğan, 1st ed., Papatya Yayıncılık, 2004
Journals • IEEE Transactions on Software Engineering
• IEEE Software
• ACM Transactions on Software Engineering and Methodology
Please click here for a larger list of journals.
Societies • The IEEE Computer Society
Other Links • The Software Engineering Institute

5
Week Date Topic Recitation Homeworks/Projects Invited Speaker Customer Meetings

1 3.10.2023 Introduction – Software Projects and Scope (Ch.1)

2 10.10.2023 Software Processes Models (Ch.2) Project Charter

3 17.10.2023 Agile Software Development Revised Project Charter TBA

4 24.10.2023 Software Project Planning and Estimation (Ch. 9)

5 31.10.2023 Software Project Management (Ch. 9) TBA

How to start a project, configurations, test, documentation, Meeting 1 on

6 7.11.2023 Project plan
CI (Lec. Turgut UYAR) Project Plan

Axure, Figma, Jira,

7 14.11.2023 Requirements Engineering (Ch.11)
ArgoUML

Meeting 2 on
8 21.11.2023 Requirements Analysis (Ch. 12- Ch.13) SRS TBA
Requirements

Meeting 3 on
9 28.11.2023 Software Architecture SRA TBA Requirement
Analysis
NodeJS, Hibernate,
10 5.12.2023 Software Design (Ch. 14-17)
Log4J
Meeting 4 on
11 12.12.2023 Software Design (Ch. 14-17) TBA
Design
Junit, Mockito,
12 19.12.2023 Implementation and Testing (Ch.14-15) SDD
Jmeter, Selenium
Meeting 5 on Test
13 26.12.2023 Implementation and Testing (Ch.14-15) TBA and Final
Deliverables

14 2.01.2024 DevOps Test Report TBA

6
Project Charter 1
Tentative (subject to change)
Project Plan 6
Software Requirements Specification (SRS) 7
Software Requirements Analysis (SRA) 9
Software Design 9
Test Report 8
Customer Collaboration 5
Use of CASE Tools 5
Project Demo and Final Deliverables 15
Final Exam 35

In-group Customer In-class

Evaluation Evaluation Exercises

1.7
• A mobile application will be built.
•A mobile application, a backend and a web-based management application should be built.
•You should focus on scalability and security as well as the functionality.
•Your app should have user management.
•Use of cloud technologies (API Gateway, FaaS etc.) is a must.
•Topic suggestions are allowed.
•Please keep the scope of your project appropriate for the time available.
•Submitted project charters can be rejected and should be revised within one week.
•Carried out in groups (5 students).
•Group members from different course sections (CRNs) are allowed.
•Has several phases that can be implemented in sequential or incremental fashion
•Requirements Specification, Design, Implementation, Test
•Has several deliverables
•SRS, SRA, SDS, Test Report, Source Code,Final Demo of the Product, Presentation
•All will be kept in Git
•Use of Git version control system to track commit activities and tasks is mandatory.
•Use of a unit testing tool (e.g. Junit, GoogleTest) is mandatory.
•Use of automated testing through unit testing tools is mandatory.
•Use of a collaboration tool (Jira, ClickUp, Wrike, etc.) is mandatory.

1.8
 https://conf.researchr.org/home/icse-2021/score-2021#Project-
Proposals
 https://conf.researchr.org/track/icse-2023/icse-2023-score-
2023?#Project-Proposals

 BLG 411E 2018-19 Fall Semester: İTÜ Team with the project
"Transient Shared Communication Channels" got the second
rank.

 Not all SCORE projects are allowed. Choose the one that fits to
the project requirements.

1.9
•RULE #1: PROJECT is a TEAM WORK!
•RULE #2: EVERYONE needs to contribute to all phases of the project.
•RULE #3: You need to report all your meetings with the customers (TAs)
and confirm the needs before moving forward. Remember that customers
change their minds too often!
•RULE #4: At the end of the project, everyone will evaluate his/her team
members’ performance and contribution to the project. This is going to be
privately shared with the instructors only.
•RULE #5: Inform us (me or TAs) early if you have any difficulties during
the project regarding the topic, technologies or with your group members!
•If a project member believes that some project members have not
contributed the phase
o Must submit a one-page summary for the phase, indicating how much he/she
thinks each project member has contributed to the phase

1.10
 Plagiarism, cheating or copying other people’s
work/documents/source code will be dealt with extreme
intolerance.
 Disciplinary actions will be applied immediately.

1.11
1. Course Mechanics
2. Software History and Problems
3. Project Scope – How to begin a project?

 1.2 
 Intangible
 Labor intensive
 Physically easy to change, but hard to modify - Complexity
 Mass production of duplicate items – Reuse
 Does not wear out, but its design deteriorates - Maintenance

13
 Engineering discipline since 1970-80s
 Hardware engineering  System engineering  Software
engineering

14
 Software engineering is like
Hardware engineering.
 Sequential waterfall-type models
have been in use for software
development for a long time.
 If you put coding at the bottom, it
becomes V-model.
 Newly established organizations:
o Association for Computing Machinery
o IEEE Computer Society

B. Boehm, A View of 20th and 21st Century Software Engineering, in Proc. ICSE 2005.
B. Boehm, Some Future Software Engineering Opportunities and Challenges, in Proc. of The Future of Software Engineering
Symposium, 2010.

1.15
 Crafting
 Differences from hardware
o Software was much easier to modify than hardware.
• “code and fix” as opposed to “Critical Design Reviews”
o Software reliability could only imperfectly be measured by hardware
models.
o It is invisible, weightless, but costs a lot.
• Hard to tell whether it was on schedule, if more people should be added.
o Many more states, modes, and paths to test, making its specifications
much more difficult.
 Establishment of computer science and informatics departments
of universities
 Software Engineering Conferences (NASA)
B. Boehm, A View of 20th and 21st Century Software Engineering, in Proc. ICSE 2005.
B. Boehm, Some Future Software Engineering Opportunities and Challenges, in Proc. of The Future of Software Engineering
Symposium, 2010.

1.16
 Formality and Waterfall Processes
 Reaction to “code and fix” approach
 Royce’s waterfall model
o Iterations
o Prototyping activity
 Quantitative approaches
o Coupling, cohesion, information hiding
o Complexity metrics
o Reliability estimation models
o Software quality
o Cost and effort estimation models
o Software engineering laboratories (NASA)

B. Boehm, A View of 20th and 21st Century Software Engineering, in Proc. ICSE 2005.
B. Boehm, Some Future Software Engineering Opportunities and Challenges, in Proc. of The Future of Software Engineering
Symposium, 2010.

1.17
 Productivity and Scalability
 CMM forced by U.S. DoD
 Reinforcement of waterfall-model
 Software tools
 Software processes
 Software reuse
 C++ and Java
 No silver bullet

B. Boehm, A View of 20th and 21st Century Software Engineering, in Proc. ICSE 2005.
B. Boehm, Some Future Software Engineering Opportunities and Challenges, in Proc. of The Future of Software Engineering
Symposium, 2010.

1.18
 Concurrent vs. Sequential Processes
 Emphasis on Time-to-Market
 Controlling Concurrency
 Open source development, General Public License, UML,
Expansion of WWW
 Usability and HCI

B. Boehm, A View of 20th and 21st Century Software Engineering, in Proc. ICSE 2005.
B. Boehm, Some Future Software Engineering Opportunities and Challenges, in Proc. of The
Future of Software Engineering Symposium, 2010.

1.19
 Agility and Value
 Agile Methods
 Value-based Software Engineering
 Software Criticality and
Dependability
 COTS, Open Source and Legacy
Software
 Model-Driven Development
 Interacting Software and System
Engineering
B. Boehm, A View of 20th and 21st Century Software Engineering, in Proc. ICSE 2005.
B. Boehm, Some Future Software Engineering Opportunities and Challenges, in Proc. of The Future of Software Engineering
Symposium, 2010.

1.20
 Globalization and Systems of Systems
 Software-intensive SoS
 User Patterns and End Value Focus
 Rapid, Accelerating Change

B. Boehm, A View of 20th and 21st Century Software Engineering, in Proc. ICSE 2005.
B. Boehm, Some Future Software Engineering Opportunities and Challenges, in Proc. of The Future of Software Engineering
Symposium, 2010.

1.21
 Mega sensor-intensive smart systems
 Search and mining of ultra-large data aggregations
 Software implications of multicore chips
 Software as a service
 Social networking technologies
 Empirically evolved process technology: Languages, methods,
metrics, models, tools
 Lean, value-based processes for balancing dependability and
agility
 Autonomy and Bio-Computing
 Software implications of deep learning models
 Generative models for software development (e.g. CoPilot)

1.22
 Formal Definition
o The application of a systematic, disciplined, quantifiable approach to the
development, operation, and maintenance of software"
[IEEE Standard, 610.12, 1990].

1.23
 The study of systematic and effective processes and technologies
for supporting software development and maintenance activities
o Improve quality
o Reduce costs
o Deliver on-time

1.24
 Software Market Revenue

https://www.statista.com/forecasts/963597/software-revenue-in-the-world

1.25
 Software cannot be built fast enough to keep up with technology
 Increasing need for high reliability software
 Software is difficult to maintain
 Difficult to estimate software costs and schedules
 Too many projects fail

1.26
Therac-25 (1985)
 Cost: Three people dead, three people critically injured
 Disaster: Canada’s Therac-25 radiation therapy machine
malfunctioned and delivered lethal radiation doses to patients.
 Cause: Because of a subtle bug called a race condition, a
technician could accidentally configure Therac-25 so the electron
beam would fire in high-power mode without the proper patient
shielding.

1.27
Patriot Missile (1991)
 Cost: 28 soldiers dead, 100 injured
 Disaster: During the first Gulf War, an
American Patriot Missile system in
Saudi Arabia failed to intercept an
incoming Iraqi Scud missile. The
missile destroyed an American Army
barracks.
 Cause: A software rounding error
incorrectly calculated the time,
causing the Patriot system to ignore
the incoming Scud missile.

1.28
Ariane 5 Rocket (1996)
 Cost: $500 million
 Disaster: Ariane 5, Europe’s newest unmanned
rocket, was intentionally destroyed seconds after
launch on its first flight. Also destroyed was its
cargo of four scientific satellites to study how the
Earth’s magnetic field interacts with solar winds.
 Cause: Shutdown occurred when the guidance
computer tried to convert the sideways rocket
velocity from 64-bits to a 16-bit format. The
number was too big, and an overflow error
resulted. When the guidance system shut down,
control passed to an identical redundant unit,
which also failed because it was running the same
algorithm.

1.29
 London Stock Exchange’s Transfer & Automated Registration of
Uncertificated Stock (TAURUS) System
 CONFIRM travel reservation system
to combine airline, car-rental & hotel information
 RACV Insurance’s Workflow Management System (litigation)
 FoxMeyer’s Delta III Information System
 British Sky Broadcasting’s Call Center & Customer Relationship
Management (CRM)(litigation)
 O2
 TSB Bank
 Security attacks: Spectre, WannaCry
 Cloudfare
 Nest

1.30
Year Successful (%) Challenged (%) Failed (%)

https://www.standishgroup.com/sample_research_files/CHAOSReport2015-Final.pdf
1994 16 53 31

1996 27 33 40

1998 26 46 28

2000 28 49 23

2004 29 53 18

2006 35 46 19

2009 32 44 24

2011 29 49 22

2012 27 56 17

2013 31 50 19

2014 28 55 17

2015 29 52 19

2020 31 50 19

J. DeFranco and J. Voas, "Revisiting Software Metrology" in Computer, vol. 55, no. 06, pp. 12-14, 2022.
1.31
 Cost Overrun Data Time Overrun Data # of Feature Dropped

https://www.projectsmart.co.uk/white-papers/chaos-report.pdf

Factors Making SD Difficult Factors Making SD Fail

Source : Standish Group

1.32
 Communication
o Between customer and developer
o Within development team
 Project characteristics
o Advancing technology
o Changing requirements
 Personnel characteristics
o Personnel variability
o High turnover
 Facilities
and resources
 Management issues

1.33
 Lack of high-level management support
 Lack of trust between customers and project team
 Too little involvement with the user community
 Poorly described requirements: Inadequate gathering, lack of user
input, misunderstandings
 Estimation errors
 Poorly implemented development methodology
 Lack of risk management
 Planning, monitoring, control
 Staff turnover

F.P. Brooks Jr., The Mythical Man-Month, Essays on Software Engineering, Addison-Wesley, Reading, MA, 1975.
McCain, K. W., & Salvucci, L. J. (2006). How influential is Brooks’ law? A longitudinal citation context analysis of Frederick Brooks’ The
Mythical Man-Month. Journal of Information Science, 32(3), 277-295.
Verner, J. M., Overmyer, S. P., & McCain, K. W. (1999). In the 25years since The Mythical Man-Month what have we learned about project
management?. Information & Software Technology, 41(14), 1021-1026
Cerpa N., and Verner J., [2009], “Why did your project fail?” Communications of the ACM, December Vol 52. No 12, pp.130-134.

1.34
 Today’s software development activities heavily rely on a project
based approach.

 A project can be seen as a series of planned activities packed

within a scope. The scope of a software project consists of
o Time: How much time do we need to complete the project.
o Cost: How much effort needed to complete the project on time.
o Quality: What primary and secondary features and functionalities should
be present regarding the time and budget.

 Software projects are generally carried out in phases (or stages)

containing activities with the intent of better planning and
management.

1.35
 A very classical model called “waterfall” contains the following
stages:
1. Requirements Specification Phase
2. Requirements Analysis phase
3. Design phase
4. Implementation phase
5. Post-delivery maintenance
6. Retirement

 Let’s work on a very basic example. Here are the questions you
should ask for each stage of the software development for a
mobile “alarm clock app”.

1.36
 For the requirements phase, almost no technical detail should be
considered in detail.
o Explore the concept
o Elicit the client’s requirements

 Software is treated as a black box, we enlist the features that we

wish to see
o Do we have snooze operation?
o Should we be able to give alias to alarms?
o Is there going to be a soft alarm?
o Should we be able to save multiple alarms?
o Do we support periodic alarms?
o Should we be able to assign custom alarm sounds?
o … and many more

1.37
 In the analysis phase, primary requirements on the technical
issues are analyzed in a broad perspective.
o Analyze the client’s requirements
o Draw up the specification document
o Draw up the software project management plan
o “What the product is supposed to do”
 In this phase for the alarm clock app we ask questions like
o What is the maximum snooze repetition, how much should we wait in
between?
o Should the user be able to edit snooze time?
o How should we increase the sound in soft alarm, should we use a different
melody?
o How should we list multiple alarms?
o Should we disable the periodic alarm in holidays? How should we get the
holiday information?
o … and many more

1.38
 In the design phase, most of the necessary decisions on the
technical issues are made.
o Architectural design, followed by
o GUI design
o Data and Functional design
 In this phase for the alarm clock app we discuss questions like
o Where should we save the alarm parameters (local db, file, cloud)?
o How should the alarm list look like?
o How should the single alarm edit screen look like?
o What kind of mechanism should we use to trigger alarm? Thread- daemon
process?
o Should we use a list or an array for the alarm list?
o How should we cache the holiday dates?

1.39
 Implementation and Testing
o Coding
o Unit testing
o Integration
o Acceptance testing

 Post-delivery maintenance
o Corrective maintenance
o Perfective maintenance
o Adaptive maintenance

 Retirement

1.40
 Surprisingly, the costs of the classical phases have hardly
changed

1.41
 The cost of detecting and correcting a fault at each phase

1.42
 When carrying out a software project, social aspects are
generally more important than technical aspects.

 Stakeholder: According to the Project Management Institute

(PMI), “the term project stakeholder refers to, ‘an individual,
group, or organization, who may affect, be affected by, or
perceive itself to be affected by a decision, activity, or outcome of
a project”

1.43
 The most common software project stakeholders are listed
below.
o User
o Customer
o Project Manager
o Team Leader
o Analyst – Requirements Eng.
o Configuration Manager
o Designer – Architect
o UI-Web designer
o Programmer
o Tester
o QA people
o IT people
o DevOps – Maintenance People

1.44
1.45
1. Course Mechanics
2. Software History and Problems
3. Project Scope – How to begin a project?

 1.3 
How to begin a project?
 The very first thing that’s done on a new project is the
development of the project charter. That’s the document that
authorizes you to do your work.

 Project Charter tells everyone in the company why the project is

needed, and gives you the authority you need to make it happen.

 Then you identify stakeholders to figure out who is affected by

the project and how to communicate with them

1.47
 Even though this may change from case to case, a project charter
(sometimes called as a “one-pager”) typically includes the
following items in a single page:
o Project Description
o Project Objectives and Outcomes
o Assigned Project Manager and Staff
o Summary Milestone Schedule
o Preliminary Cost Estimation
o Preliminary Risks

1.48
 Once you have a good idea of what needs to be done, you need
to track your scope as the project work is happening. Determining
the project scope is setting goals for the project team and keep
everybody on track.
o Product scope means the features and functions of the product or service
that you and your team are building.
o Project scope is all of the work that needs to be done to make the product.
o Scope creep means uncontrolled changes that cause the team to do extra
work.

1.51
 The five Scope Management processes that can be used in
scope management are
o Collecting the requirements to form a requirements document
o Defining the Scope to form a Project Scope document
o Creating a work breakdown structure
o Consider change requests to modify project scope
o Verify the scope iteratively by accepted deliverables

1.52
 The Project Scope document is created by considering the
following documents:
o Project Charter
o Requirements Document
o Organizational Templates/Forms
 When creating the project scope statement, you can perform the
following actions
o Stakeholder meetings  Output: Quantifiable goals
o Product analysis
o Alternatives Identification
o Expert Judgement

1.53
 All the project
objectives need to
be measureable

Even though you

probably can’t fit
ALL of the
requirements
here, there should This means
be enough detail looking for all the
to let you keep on work the project
planning and refer DOESN’T include.
back to it late
The deliverables
listed here are
EVERYTHING the
project creates,
including project
management
stuff.

Constraints are
known limitations.
Assumptions are
things you think
are true.

1.54
 Building good quality software requires the coordination of
various planning, engineering and management activities

 While beginning a software project, it is a common procedure to

use project charters (or project offer or one-pager).

 Analyzing and keeping up with scope is also very important which

is carried out during the whole project.

1.55
 We will discuss software development lifecycle in detail and
begin considering various classical lifecycle models!

1.56