RSM, Erasmus University
Msc BIM 2021 - 2022
Kathleen Gaillot
BM02BIM • 5 EC
Designing Business Applications
Summary Notes/imagery based on lectures
Software Engineering 9th ed. by Ian Sommerville
ISBN: 978-0-13-703515-1
1 UML Distilled: A Brief Guide to the Standard Object Modeling Language
3rd ed. by Martin Fowler
ISBN: 978-0321193681
, Table of Contents
1: Software Engineering & Development Processes 1 4.1.1 Combined Fragmentation ..............................19
1.1 What is DBA? ........................................................... 1 4.2 Activity Diagram .....................................................20
1.1.1 What is Software? ........................................... 1 4.3 State Machine Diagram .........................................21
1.1.2 Software Crisis ................................................. 2 4.3.1 Concurrent State Diagram .............................21
1.2 What are Systems? .................................................. 2 4.4 Basic Software Design ............................................21
1.2.1 Socio-Technical Systems .................................. 2 4.4.1 Design Principles ............................................23
1.3 What is Software Engineering? ............................... 3 4.5 Value-Maximizing Design Decisions ......................24
1.3.1 Presctiptive Process Models ............................ 3 4.6 UML – Truth Tables & Impact Estimation ..............24
2: Introduction to Requirements 7 5: Value-Based Software Engineering 25
2.1 Requirements Engineering: How & Why? ............... 7 5.1 Sources of Software Value-Creation Problems......25
2.1.1 Non-Functional Requirements Quantification 8 5.2 Value-Based Software Engineering Key Elements .25
2.2 Requirements Engineering Activities ....................... 9 5.3 Estimation ..............................................................27
Types of Requirement Engineering Activities........... 9 5.4 Planning .................................................................28
2.3 Elicitation ............................................................... 10 5.5 The Cone of Uncertainty ........................................29
2.4 Specification........................................................... 10 5.6 UML Class Diagram Notes ......................................29
Specification: Natural Language Specification ....... 10 6: Agile Methods, XP, Scrum 32
2.5 Validation ............................................................... 12 6.1 Process Models Overview ......................................32
2.6 Purpose of SRS ....................................................... 12 6.2 Waterfall Model .....................................................33
3: Requirements in Business Analysis 12 6.3 Other Models .........................................................33
3.1 Requirement Management ................................... 12 6.3.1 Incremental Vs Iterative ................................34
3.1.1 Requirements Change Management............. 12 6.4 Agile Methods ........................................................34
3.2 History of UML Diagrams ....................................... 13 6.4.1 Common agile methodologies: ......................34
3.3 Use Case Diagram .................................................. 13 6.5 Scrum .....................................................................35
3.4 Class Diagram......................................................... 15 6.5.1 User Stories....................................................36
3.4.1 Identifying Classes ......................................... 16 6.5.2 Recap: Scrum in <100 words .........................37
3.5 UML - Tips for Drawing a Class Diagram ................ 17 6.6 Which Model? ........................................................37
4: Introduction to Design 17 Exam Information 38
4.1 Sequence Diagram ................................................. 18 Question Samples ........................................................38
Tips/Note: use CTRL + F for quick navigation / finding keywords.
Look for yellow stars in the left margin for topic that have been used in the exam in the past.
Double-check the learning objectives at the beginning of each chapter against your knowledge.
ii
, Learning Objectives
L1: recognize the important traditional as L2: compare different methods to develop L3: transfer stakeholders’ objectives into a
well as agile methods to develop software software packages and choose the best one for documented system requirement
projects. a given project. specification.
L4: analyze system requirements to ensure L5: assess the accuracy of a given system L6: develop a visual model (based on UML)
that they comply with the system and requirement specification document and of the system requirements that is
budget limitations. whether it needs any editing. understandable to the developers.
1: Software Engineering & Development Processes
Mandatory Literature:
Sommerville (2010, chapters 1, 2, 10.1, 10.2)
Frederick P. Brooks Jr. . (1995). No Silver Bullet - Essence and Accident in Software Engineering.
Learning Objectives:
L1.1 Understand what DBA is about
L1.2 Explain the inherent difficulties of software systems
L1.3 Define software, systems, socio-technical systems, emergent properties
L1.4 Explain software engineering, software processes, process flows
L1.5 Compare and contrast prescriptive process flows (Waterfall, V-model, Incremental, Prototyping, spiral)
RUP
1.1 What is DBA?
In short – DBA is about all processes you need to take to develop a software. It’s not about coding, it’s about what
needs to be clarified to turn an idea into something coders can use to turn it into code for a software project.
1.1.1 What is Software?
Application software is only one type of software. A software can be as
basic as returning “x+y” when given x + y. For such a simple software, DBA
isn’t needed, but a simple ios app is over40k lines of code… mozila, 10M,
boieng 14M. Programmers are expensive… a mobile app costs $20k-80k total.
Most of these can be avoided when following software engineering guidelines ,
Software is any set of machine-readable instructions that directs a
computer processor to perform specific operations.
Why is it difficult?
DBA is difficult because of the inherent difficulties of software.
Some characteristics of software (3 reasons to be difficult):
1. Complexity 2. Invisibility 3. Changeability
More complex than (perhaps) any other Geometric abstractions are Constantly subjects to requests
human construct powerful tools (floor plans, for changes
The number of states (more to less): Software stick-figure models for o Conversely, Manufactured
>> Digital computer >> Most human constructs molecules) goods are infrequently
Elements interactions increase super-linearly Software is invisible changed after manufactured
Difficult for the managers and customers to The reality of software cannot o All successful software gets
understand be embedded in space changes
1
, Other characteristics include:
No Wear-out: constant updates possible…
Conformity: Physicists hope that there are unifying
principles, but…
o Cannot be expected in software
o People with different styles create one software –
these styles do not conform to each other
o Results in very complex & non-uniform software
Sharp Requirements: Performance, Security, Continuous
deployment.
1.1.2 Software Crisis
o Software improvement is not slow, it is hardware
development that was fast (software crisis of 1968)
o No other tech has seen six orders of magnitude price
performance gain in 30 years, other than hardware.
Silver Bullet
“There is no single development in either technology or in
management technique that by itself promises even one order of magnitude improvement in productivity, reliability
and simplicity at the same time.”
So in the time that this quote was published, it was the time of the software crisis. Also known as a wicked problem:
So complex with no definitive problem specification. The true nature emerges as a solution is evolved.
1.2 What are Systems?
A purposeful collection of interrelated components that work together to achieve some objective. Example: A pen.
Software-included systems:
Technical computer-based systems include software and hardware but not procedures and processes (e.g.,
TV, mobile phone)
Socio-technical systems include technical parts but crucially also include knowledge of how the system should
be used to achieve some broader objective (e.g., social media)
1.2.1 Socio-Technical Systems
While a train itself is a technical system, the metro system is heavily dependent on its
users (the amount of train, scheduling, etc.) and is therefore a socio-technical system.
Properties of Socio-Technical Systems
1. They have emergent properties.
2. They are often non-deterministic.
3. The success-failure of the system also depends on
how objectives are interpreted.
o Different managers might interpret the objective of a system differently and
have different results
Emergent properties: they emerge only when the system components are integrated:
- Functional: appear when all the parts of a system together to achieve some object.
- Non functional: relate to the behaviour of the system in its operational environment
(volume, reliability, security, reparability, usability
2
