0.

Introduction

Software Engineering is the technological and managerial discipline concerned with the
systematic development and maintenance of software and software-intensive systems satisfying
specified functional and quality attributes.

The software consists of programs, associated data, and documentation for performing
tasks with the aid of computers
Software is immaterial, difficult to measure, is not subject to physical laws and limits,
doesn't wear out, and has no spare parts, but it does age.

Waterfall model

1.0 Planning
In the Planning phase, the main output is the requirements document which describes the system
in the words of the user. The process of determining the requirements is called requirements
elicitation.
A Feasibility study - determines whether a software development organization is capable of
implementing the requirements.
Requirement - condition or capability that must be met or possessed by a system or a component to
satisfy an imposed document.
Scenario - Describes an event or a sequence of events, or a system used in text form, containing
images, sketches, restrictions, and so on. EXTRA: if scenarios are used in the design phase then it's
a scenario-based design.
UML Use Case Diagrams - employed during the planning phase to represent the user’s possible
interaction with the system.
● Actor - the role of use or an external system that interacts with the planned
system
● Use case - class of functions given by the system
● Use case mode - set of all use cases that represent the complete
functionality of the system.
● Seven parts of the textual description: unique names, participating actors,
entry conditions, the flow of events, exit conditions, exceptions, and special
requirements.
<<include>> Relation - identifies a use case that is used in more than one other case. (similar
“calls” relation) When the base use case is executed, the included use case is executed every
time.

<<extend>> Relation - When the base use case is executed, the extended use case is executed
only SOMETIMES. The extended use case will happen only when certain criteria are met

Types of Requirements:
● Functional - Describe the behavior or reaction of the system to data
entered or events received, or the interaction between the system
and environment
● Quality - describes the quality of how a function is performed
● Constrains - Restriction imposed by a client, law, or environment

Functional non - functional

Describe user tasks that the system must describe properties of the system
support or the domain
are formulated as constraints or
Assertions

Quality Constraints

Usability Implementation
Reliability Interfaces
Fault tolerance Operational environment
Security Scope of delivery
Performance Legal obligations
Response time
Throughput
Scalability
Availability
Maintainability
 Adaptability
Extendibility
Understandability
Portability

Correctness
The requirements reflect the wishes of the customers correctly.
Completeness
All situations, in which the system can be used, are described, including
errors and faulty operation.
Consistency
No requirements contradict each other.
Unambiguity
The requirements are formulated in unambiguous ways.
Understandability
The requirements can be understood by all concerned in the same way.
Feasibility
Requirements can be realized and delivered.
Traceability
It should be possible to associate every requirement with a set of functions

2.0 Specification
Specification phase gives us requirements specification, in its way defines the system to be
developed completely. The requirements specification defines what but not how. Requirements
document is for communication with the user, and requirements specifications are for
developers.

We use models to abstract details of reality, make predictions of the future and give insights
about the past or present.
Types of Models: 1) Functional model - scenarios, use case
2) Object model - class, object
3) Dynamic Model - state, sequence, activity

2.1 Object Orientation, and UML class diagrams

Object: An element out of the set G that is recognizable and clearly distinguishable from others
by at least one individuum.
Ω: The set of all objects. (Ω ⊂ G)
class: An arbitrary category over the set of all objects Ω.
exemplar/instance: A concrete element of a given class.
Attribute: a property that is defined and present in all exemplars of a class
Object identity: The existence of an object is independent of its attribute values. Two objects
are distinguishable even when they have the same attribute values.

Comparing objects
Equality of order n:
● Order 0: objects are identical
● Order 1: order 1 or objects are different but have pairwise identical values
for all attributes
● Order 2: order 1 or pairwise equality of order 1 in all attributes
● Order 3: order 2 or pairwise equality of order 2 in all attributes

State: As long as an object is in a certain state and in the same calling or use context, it will
always react in the same way.
Encapsulation: The state is visible from the outside, but is controlled inside the object

UML Object/instance Diagram

An association in UML defines the properties of relations between sets.

Transactionality, ACID-principle
● Atomicity – Indivisibility of changes, “all or nothing“
● Consistency – Changes result in a consistent state (target state or, in case of abortion,
in starting state)
● Isolation – Changes are not affected by concurrently running, other changes
● Durability – After completion, changes are permanent and visible for all other
threads—not guaranteed for main memory)

Multiplicities specify, how many tuples of a given class may appear.

An association connects classes and specifies potential relations between examplars.
A link connects examplars, and expresses an actual relation between exemplars.
Restriction
Example:

Navigation specifies in which direction the messages can traverse a link

Special Associations
Aggregation (specialization of association): Part-whole relationship (or contains, has)

Composition (specialization of aggregation): More constraint: Parts cannot exist witout the
whole. This is important when creating and deleting the parts.

Qualified Associations
Qualifier: An attribute (or combination of attributes) that partition the set of associated
exemplars
Qualified association: An association where the set of associated elements is partitioned by a
qualifier.
Example:

Constructors - marked with <<create>>, the return type is not indicated

Enumerators - defined in a special form of a class, mark class with <<enumeration>>, linked to
an object with an association

Inheritance
Inheritance: Let O and U be classes, and ΩO und ΩU the sets of exemplars that make up these
classes. Then U is a subclass or specialization of O (and O superclass or generalization of U) iff
ΩU ⊆ ΩO
Advantage of inheritance is to avoid redundancy.

Liskov substitution principle

In a program with U being a subclass of O, every exemplar of O can be replaced with an
exemplar of subclass U and the program will continue to work correctly.
● All properties of the superclass must be available to the subclass
● Subclass has the same or weaker preconditions
● Subclass has the same or stronger postconditions as the superclass
Subclass may define additional properties, but may not delete properties of the superclass. Covariance -
of return, contravariance of parameters.

Def. Variance: Changing the types of parameters

and return types of an overriding method.
Def. Covariance: Specializing the parameter or
return types of an overriding method
Def. Contravariance: Generalizing the parameter or
return types of an overriding method
Def. Invariance: no modification of types

2.2 Additional UML diagrams

Use case diagram
Used for requirements elication - what does the user want?
Use case diagrams are an aid for requirements elicitation and documentation. They show
relationships and not behavior or process.

Activity diagram
Describes a process
Elements that activity diagram has: activities (round square), Nodes: (1. start node, 2. end node
3. control flow end), Decision, Join, parallel lunch, Synchronization. (note: if many arrows are
pointed to one action, all arrows should have their own token to satisfy the requirement)
Partitions are used to give us information about who is responsible for an action.

Sequence diagram
Depiction of the sequence of method calls of a use case.
Elements of a sequence diagram: activation(bar overlaid on lifeline), declaration of local
attributes (ex, i: integer), alt (if/else statement), reference, recursive call, object
creation/deletion, Message types:
● synchronous message (with filled arrow)
● Reply/return(optional)
● Asynchronous message (returns immediately, call runs in parallel.
State diagram
Describes possible states of an object plus allowed state changes.
The translation is triggered by an event. Guarded transition- when at the moment when the
event happens the condition is true. ε-transition- may happen anytime. We have two special
events at and after.
Actions
● Entry action - executed when a transition enters the state.
● Exit action - executed when a translation leaves the state.
● Continuous action - executes as long as the machine remains in the state.

Basic example:
The hierarchy of a state machine
Reduces the number of edges.

History
Remembers the last state and when going back it returns to the saved state.
You can still make a machine without a history feature. Just write down all possible returns.
Concurrency
Runs in parallel with each other, and you write products of them. As previously with history you
can remove it and just write down all possible concatinations.

Implicit/ explicit
implicit storage saves storage space, explicit computing time.the implicit is potentially
complicated, the explicit more extensive. the implicit is not always possible, the explicit is.

Package diagram
Packages are sets of UML model elements of arbitrary types. Helps with structuring the large
models. Every model has a name that is unique and may have visibility. Dependencies amazon
packages are indicated with a dashed arrow.

2.3 Object Modeling

Object model is a static model.
Abbot method

Noun class Car, dog, lift

Name instance Peter, Mark

Intransitive verb method To do, to run

Transitive verb association/method Love someone /eats sth

Verb “is a” inheritance Is a, are, includes

Verb “have s.t” aggregation/attribute Has, consists, made up of

Modal verb assertion Must, should

Adjective attribute 3 years old, green, 20 seats

When is a class probably redundant?

● the class has no attributes, no methods, and no associations.
● the class has the same attributes, methods, and association/aggregations as another
class.
● the class contains only methods that could be placed in another class
● the class models implementation details
● the class has only one or two attributes. Could they be added to another class?

3.0 The Design Phase

Software design phase
Transforming requirements specifications into a software design or software
Architecture.
There are two major design methods:
1. Modular design
2. Object-oriented design

Modular Design
A modular design consists of the following:
1) Module Guide: functions of each module and subsystem, structure of the system
consisting of modules and subsystems.
2) Interfaces: exact description of the interface elements.
3) Uses relation: describes for every module which other modules or subsystems it uses.
4) Detailed Design (optional): specification of internal algorithms and data structures.
It should be possible to implement and test modules independent of their later use.
It should be possible to implement a module without knowing anything about the internal details
of other modules or to influence the behavior of other modules.
It should be possible to use a module without knowing anything about its internal details.

What is a Module?

A typical module consists of functions or subprograms that modify one or more data structures;
other modules cannot directly access these data structures, except by using subprograms
provided by the interface of the module.

Candidates for hiding:

● Implementation of data structures and the operations on them
● Low-level hardware details
● Operating system details
● Basic libraries such as databases, graphics packages, and operating
system-specific libraries
● I/O formats
● Size of data structures
● Order of processing
● Text of dialogues and error messages

Object Oriented Design

Object-oriented design uses the concepts of classes, methods, objects, inheritance,
associations, etc. from object-oriented languages or UML to express software designs. The
information-hiding and change-invariant interfaces apply the same.

3.1 Architectural Styles

Def: Architectural Styles or patterns structure a software system as a whole. We will cover nine
styles.

Layered Software Architecture

A layered architecture consists of a hierarchically ordered set of layers. Each layer consists of a
set of software components for use by higher layers and may use lower layers to implement
these components. In Opaque layers, can only use the layer directly below it. In Transparent
Layers, each layer can use all the layers below it. 3-tier architecture 3-layer architecture with
layers being on other machines.
Advantages:
● Clear structuring in levels of abstraction or virtual machines
● No Restriction on the structure within the layers
● Independent development, testing, and can replace each layer
● Step-by-step development and testing
● Reuse lower layers in other configurations
● To provide a simplified interface for a complex layer(s) we can use facade.
Disadvantages:
● opaque layers may lead to performance issues when calls need to be passed down
through intervening layers to the target layer. This causes extra calls, parameters, and
return value passing.
● the same is true for passing error codes back, but not a problem when using exceptions
with catch/throw.
● Avoid chaos within a layer!

Sometimes to avoid chaos we use a facade to provide a simplified interface for a given layer, to
be used by higher layers. The facade may provide new methods that combine calls that is used
together, plus convenience methods.

Abstract or Virtual Machine

An abstract machine or virtual machine is a set of software commands and objects that are
implemented on top of a real (or other abstract) machine and hides the underlying machine
partially or completely. (Example: java VM, programming language, op sys.) An abstract
machine is implemented by several modules or packages. The underlying machine must be
entirely or at least partially hidden to prevent inconsistency. Virtual machines are special kinds
of layers. Virtual machines can also provide complete instructions sets of computers.
Client/Server

One or more servers offer services for other systems or applications, called clients. They both
are located on different computers and communication is via a network. The client must “know”
the interface of the server, but not vice versa. It is often used for database applications. The
client may request inputs and display output. Server-side functions consist of data management,
security, and parallel transactions.

Peer-to-Peer Networks
Generalization of the client/server architecture. Participants are called “peers” and they are
co-equal. Properties: Symmetry of roles, Decentralization, self Organization, autonomy,
Unreliability, also all data must be stored redundantly because of the unreliability of some peers.

Repository
Repositories are classes or components that encapsulate the logic required to access data
sources. They centralize common data access functionality, providing better maintainability and
decoupling the infrastructure or technology used to access databases from the domain model
layer. Subsystems read and modify data in a central repository and are loosely coupled and
interact only through the repository. Access can be local or remote.

Model-View-Controller (MVC)
is commonly used for developing user interfaces. It divides the program logic into three
interconnected elements. MVC parts:
● Model: The central component of the pattern. It contains the application's
dynamic data structure, independent of the user interface. It directly manages the
data, logic, and rules of the application.
 ● View: Displays the data structure to the user. It is updated when the model
changes.
● Controller: Responsible for user interaction; accepts input and converts it to
commands for the model or view.

Pipeline
Each filter is an independently running process or thread with its own program, instruction
pointer, and memory. Data flows through the pipeline. On parallel computers, the filters can be
run in parallel, which improves throughput compared to a sequential pipeline.

Applicability of pipeline:
● Good for data streams
● Performance is limited by the slowest filter. For good performance on parallel
machines, the filters should be the same speed
● Pipelines do not speed up the response time for individual data packets or tasks,
but they can increase throughput.

Framework
is a complete program that can be extended by the user with plugins. Plugins are added at
pre-planned extension points called hooks. It contains complete application logic and main
program. For some of the classes, users can supply subclasses that overwrite existing methods
or implement abstract methods.
Usual (non-framework) architecture:
Framework architecture: follows the “Hollywood Principle” (“Don't call us - we call you”)

Service Oriented Architecture (SOA)

SOA is an architectural style, in which applications are composed of independent services. SOA
is an abstract concept of software architecture. The service model is the core of an SOA.
Required functionality can be added as a service at runtime. Characteristics:
● Loose coupling: services can be added and replaced runtime.
● Support business processes.
● Using open standards.
● Services can be written in any language on any platform.

DESIGN PATTERNS

A Software Design Pattern describes a family of solutions to a software design problem.

1. Decoupling
Decoupling Patterns divide a software system into several independent parts in such a way that
they can be built, changed, and replaced independently as well as reused and recombined in
unforeseen combinations.
Observer
is a behavioral design pattern that lets you define a subscription mechanism to notify multiple
objects about any events that happen to the object they’re observing. Use the Observer pattern
when changes to the state of one object may require changing other objects, and the actual set
of objects is unknown beforehand or changes dynamically. Use the pattern when some objects
in your app must observe others, but only for a limited time or in specific cases.

Repository
Intent; A set of independent clients communicate with a central data structure, into which they
put, or from which they get elements, or ask queries.

Iterator
Intent: provide a way to access the elements of an aggregate object sequentially without
exposing its underlying representation.
Use the pattern to reduce duplication of the traversal code across your app. Also when you want
your code to be able to traverse different data structures or when types of these structures are
unknown beforehand.
Mediator
behavioral design pattern that lets you reduce chaotic dependencies between objects. The
pattern restricts direct communications between the objects and forces them to collaborate only
via a mediator object. Encapsulate how a set of objects interact.
Use the Mediator pattern when it’s hard to change some of the classes because they are tightly
coupled to a bunch of other classes. when you can’t reuse a component in a different program
because it’s too dependent on other components.

Bridge
structural design pattern that lets you split a large class or a set of closely related classes into
two separate hierarchies—abstraction and implementation—which can be developed
independently of each other.
Use the pattern when you need to extend a class in several orthogonal (independent)
dimensions. Use the Bridge if you need to be able to switch implementations at runtime.

Adapter
Adapter is a structural design pattern that allows objects with incompatible interfaces to
collaborate. Use the Adapter class when you want to use some existing class, but its interface
isn’t compatible with the rest of your code. Use the pattern when you want to reuse several
existing subclasses that lack some common functionality that can’t be added to the superclass.

Object adapter
 class adapter

Proxy
Proxy is a structural design pattern that lets you provide a substitute or placeholder for another
object. A proxy controls access to the original object, allowing you to perform something either
before or after the request gets through to the original object.
There are many types of proxy:
● virtual proxy. This is when you have a heavyweight service object that wastes system
resources by being always up, even though you only need it from time to time.
● A remote access proxy provides a local representative for an object in a different
address space.
● protection proxy. This is when you want only specific clients to be able to use the service
object; for instance, when your objects are crucial parts of an operating system and
clients are various launched applications (including malicious ones).
● Local execution of a remote service (remote proxy). This is when the service object is
located on a remote server.
● Logging requests (logging proxy). This is when you want to keep a history of requests to
the service object.
● Caching request results (caching proxy). This is when you need to cache the results of
client requests and manage the life cycle of this cache, especially if the results are quite
large.
● Smart reference. This is when you need to be able to dismiss a heavyweight object once
there are no clients that use it.
● A firewall (protection proxy) controls the access to the original object. Firewalls are
useful when objects should have different access rights.
● A decorator adds additional responsibilities to an object dynamically (maybe in
cascades).
● A buffer proxy (cache proxy) loads a persistent object in memory when it was first
dereferenced. It can hold a buffer with several objects, which can be moved between
background and main memory on demand.
Event Channel
Decouple participants of a system completely so that they can work independently, and do not
know anything about the existence or number of other participants. Interactions are transmitted
as events.

2. Variant Management

Variant management patterns treat different but related objects uniformly by factoring out their
commonality. All of the variant patterns rely on features found in object-oriented programming
languages.

Superclass
Uniform treatment of objects that belong to different classes but share common attributes or
methods. Use When objects of several different classes share attributes or methods or interface
elements When objects of different classes need to be manipulated uniformly in one program.

Composite
is a structural design pattern that lets you compose objects into tree structures and then work
with these structures as if they were individual objects. Use the Composite pattern when you
have to implement a tree-like object structure. Use the pattern when you want the client code to
treat both simple and complex elements uniformly.
Visitor
behavioral design pattern that lets you separate algorithms from the objects on which they
operate. Represent an operation to be performed on the elements of an object structure. Use
the Visitor when you need to perform an operation on all elements of a complex object structure
(for example, an object tree). Use the Visitor to clean up the business logic of auxiliary
behaviors. Use the pattern when a behavior makes sense only in some classes of a class
hierarchy, but not in others.

Template Method
Template Method is a behavioral design pattern that defines the skeleton of an algorithm in the
superclass but lets subclasses override specific steps of the algorithm without changing its
structure. Use the Template Method pattern when you want to let clients extend only particular
steps of an algorithm, but not the whole algorithm or its structure. Use when you have several
classes that contain almost identical algorithms with some minor differences. As a result, you
might need to modify all classes when the algorithm changes.
Factory Method
Creational design pattern that provides an interface for creating objects in a superclass, but
allows subclasses to alter the type of objects that will be created.
Use the Factory Method when you don’t know beforehand the exact types and dependencies of
the objects your code should work with. Use the Factory Method when you want to provide
users of your library or framework with a way to extend its internal components. Use the
Factory Method when you want to save system resources by reusing existing objects instead of
rebuilding them each time.
.

Abstract Factory Method

Abstract Factory is a creational design pattern that lets you produce families of related objects
without specifying their concrete classes. Use the Abstract Factory when your code needs to
work with various families of related products, but you don’t want it to depend on the concrete
classes of those products—they might be unknown beforehand or you simply want to allow for
future extensibility.

Builder
Separate the construction of a complex object from its representation so that the same
construction process can create different representations.
 3. State Handling
State Handling patterns manipulate the state of objects generically. This means that these
patterns work on the state of any object or class, independent of the actual purpose of these
objects/classes.

Memento
Behavioral design pattern that lets you save and restore the previous state of an object without
revealing the details of its implementation. Use the pattern when direct access to the object’s
fields/getters/setters violates its encapsulation. Use the Memento pattern when you want to
produce snapshots of the object’s state to be able to restore a previous state of the object.

Implementation based on nested classes

Prototype
creational design pattern that lets you copy existing objects without making your code
dependent on their classes. Use the Prototype pattern when your code shouldn’t depend on the
concrete classes of objects that you need to copy. Use the pattern when you want to reduce the
number of subclasses that only differ in the way they initialize their respective objects.
Flyweight
structural design pattern that lets you fit more objects into the available amount of RAM by
sharing common parts of the state between multiple objects instead of keeping all of the data in
each object. Use the Flyweight pattern only when your program must support a huge number of
objects which barely fit into available RAM.

Singleton
creational design pattern that lets you ensure that a class has only one instance while providing
a global access point to this instance. Use the Singleton pattern when a class in your program
should have just a single instance available to all clients; for example, a single database object
shared by different parts of the program. Use the Singleton pattern when you need stricter
control over global variables.

4. Control
Blackboard
The Blackboard architectural pattern is useful for problems for which no deterministic solution
strategies are known. In Blackboard several specialized subsystems assemble their knowledge
to build a possibly partial or approximate solution.

Command
Encapsulate a request as an object, thereby letting you parameterize clients with different
requests, queue or log requests, and support undoable operations.
Chain of Responsibility
Avoids coupling the sender of a request to its receiver by giving more than one object a chance
to handle the request. Chain the receiving objects and pass the request along the chain until an
object handles it.

Master/Slave
The Master/Worker design pattern supports fault tolerance, parallel computation, and
computational accuracy. A master component distributes work to identical worker components
and computes a final result from the results these workers return.

Process Control
Regulates a physical (continuous) process.
• Open-Loop System
• Closed-Loop System
– Feedback Control System
– Feedforward Control System
Terminology
Process Variables: Properties of the process that can be measured; several specific kinds are
often distiguished.
Controlled variable: Process variable whose value the system is intended to control
Input variables: Process variable that measures an input to the process
Manipulated variable: Process variable whose value can be changed by the controller
Set point: The desired value for a controlled variable

Closed-Loop System
System in which information about process variables is used
to manipulate a process variable to compensate for variations
in process variables and operating conditions.
– Feedback Control System
– Feedforward Control System

5. Virtual Machines
Interpreter
Given a language, define a representation for its grammar along with an interpreter that uses
the representation to interpret sentences in the language. A context provides values for
variables or other information needed for interpretation.
Rule-Based Interpreter
Solve a Problem using a set of rules. A rule consists of a condition part and an action part. If the
condition evaluated on a set of data elements in the working space returns true, then the action
part can be executed. The action part replaces or removes data elements which have been
selected in the condition part, or adds new data elements.

6. Convenience Patterns

Convenience Method
Simplify method invocation by supplying often-used parameter combinations through additional
methods (overloading).
Convenience Class
Simplifies method invocation by maintaining parameter values in a special class.

Facade
Facade is a structural design pattern that provides a simplified interface to a library, a
framework, or any other complex set of classes.
Null Object
Provide a surrogate for another object that shares the same interface but does nothing. The Null
Object encapsulates the implementation decisions of how to “do nothing” and hides those
details from its collaborators.

Pattern-Based Development
• Model-based development that focuses on extensive use and reuse of
patterns during analysis, design, and testing
• Goal: Manage Complexity, reduce cost and time-to-market
• Desirable: Applying patterns throughout the software lifecycle

Pattern Coverage
• Ideally, every element in the UML model and every element in the source
code should be covered by a pattern
• Desirable: 100% Coverage

4.0 Implementation

4.2 Coding Conventions

A consistent style improves readability, speeds up familiarization if personnel changes, or when
re-acquainting with old software, safes time when searching for bugs, extending and
maintaining software. Examples: K&R, Allman style, GNU, Whitesmiths. There are conventions
for class, method, attributes, variables, enumerations, types sometimes with a capital T at the
end, and Compound identifiers.
 5.0 Verification

5.1 Verification
Motivation
Artifacts always contain defects. The later a defect is found, the more expensive it is to fix it.

● Testing Procedures -> Detect defects

● Verifying Procedures -> Prove Correctness
● Analyzing Methods -> Determine properties of a system component

3 types of errors:
● failure/fault - wrong output or crash
● defect/bug - deficiency in software that can lead to failure
● mistake/manufacturing err. - human action that causes a defect

Types of test helpers:

● Stub- rudimentarily implemented part that does nothing (placeholder).
● Dummy - simulates the implementation for test purposes. Return the same values or
performs the same actions.
● Mock object - dummy + additional functionality. Used to test the behavior of the client.

Defect classes
● Requirement defect - defect in the specification.
● Design defect - defect in the design document.
● Implementation defect - in the program.
A software test, or test, executes a single software component or a configuration of CUT under
known conditions and checks its behavior.

There are four test phases:

● Component test (component design) - checks the function of a module or class by
observing the processing.
● Integration test (system design document) - checks step-by-step interaction of system
components that have already been tested in a unit test.
● System test (specification) - tests the entire system by the developer in a real
environment without customers.
● Acceptance (customer expectations) - final test of the system in real environments under
observation and participation of the customer.

Classification of testing methods:

● Dynamic methods: structural (white box), functional, performance (black box both).
Code executed in real environment, the correctness of the program is not proven!
● Static methods: manual (inspection, review, walkthrough), program analysis tools.
White box: determines values with knowledge of control and/or data flow.
Black box: determines values without knowledge of control and/or data flow. Only from the
specification.

Control flow oriented (CFO) test procedures

● Statement coverage
● Branch coverage
● Boundary-interior test
● Path coverage

Completeness criteria for test procedures are defined via "control flow graphs".
Intermediate language:
Consists of statements except for ones that affect execution order, conditional and unconditional
branches to arbitrary but fixed positions of the statement sequence, any number, and type of
variables. Based on assembler code.
Structure-preserving transformation:
Transformation of the source language into intermediate language if statements affecting
execution order are replaced by intermediate language. All other statements are taken over
unchanged. Transformations that replicate statement sequences or conditional jumps are
avoided (no loop unrolling, no optimizations).

Basic block: a maximally long sequence of continuous statements of the intermediate Lan. into
which the control flow enters only at the beginning and which contains no branches except at
the end.

Statement Coverage:
C- coverage, C0 - number of unique blocks executed/number of all blocks
Task is to find a test case that covers all the blocks, and therefore C0 is 100%.
Branch Coverage:
C1- number of traversed, unique branches/number of all branches.
More thorough than statement coverage. Branches that cannot be executed can be detected
Boundary-interior test
works like branch coverage but treats loops more thoroughly.
● Construct a set of test cases that traverses the loop body once.
● Cover all branches within the loop body: Add test cases until achieving branch coverage
when traversing the loop body once.
● Construct test cases that traverse the loop body at least twice.
● Cover all branches in the last traversal when traversing at least twice: add test cases
until you achieve branch coverage on the last traversal.
Path Coverage
requires the execution of all complete paths in the program. Path count grows dramatically with
loops. Some paths may not be executable due to mutually exclusive conditions. Most thorough
CFG test strategy. Not practicable because of the enormous number of possible paths.
Subsumption
A test procedure for criterion x subsumes a test procedure for criterion y if every set of paths
that satisfies criterion x also satisfies criterion y.
Short Circuit Evaluation
evaluation of a compound condition is terminated as soon as the complete result is fixed.Short
circuit evaluation in Java, e.g. for "&&" and "| |" operators. In Java, the operators "&" and "|" do
not perform a short circuit evaluation

Functional Tests
Goal: Test the specified functionality
Derive test cases from the specification. Adv: test cases independent of the implementation,
avoids short-sightedness, diss: possible critical paths not known and potentially not tested.
Functional test case determination procedures:
Functional Equivalence Classes
Assumption: A program/module works the same when processing a value from a certain range
as when processing any other value from this range.
Approach: Decompose the value range of the input parameters and the range of the output
parameters into equivalence classes. Pick a value from each combination of equivalence
classes.
Partition ranges starting from a large equivalence class
Partitioning along domain boundaries, Partitioning along assumed(!) processing method
boundaries Selection of representatives:
Let m be the number of Equiv. casses of the input parameters and n be the number of Equiv.
classes of the output parameters.
Then ≤ m * n different Equiv. classes arise. An arbitrary representative is chosen for testing from
each class.
Boundary Value Analysis
Further development of functional equivalence classes. Test cases that cover the boundaries of
the equivalence classes and their immediate surroundings are particularly effective. choose a
test value that is in the interval and another outside the interval, close to the boundary.
For (a… choose a (not in the interval) and a+1 (int) or a+delta (float)
For [a… choose a (in the interval) and a-1 (int) or a-delta (float)
for [5-10) choose boundary values 4,5,9,10.

Random Testing
Testing the function with random test cases. Testers tend to create test cases that are
considered obvious during the implementation. a non-deterministic test method that treats all
test cases equally.

Test helpers
Objects do not live in isolation; objects work together in an application. If classes depend on
each other, classes not yet implemented can be replaced by test helpers. Stubs or dummies
represent the implementations that are still missing.
Test of state machines
If a component has an internal state, test cases can be derived from the state transitions
Goal: pass through all transitions at least once
Attention: Covering all transitions does not guarantee a complete test, Instrumentation of the
component may be necessary to monitor the test sequences

Performance Tests

Load tests
Load testing is the process of putting simulated demand on software, an application or website
in a way that tests or demonstrates it's behavior under various conditions.
Stress test
Tests the behavior of the system when exceeding the defined limits.

Manual Testing Methods

Only way to check the semantics.

Review
More or less (more than walkthrough, less than inspection) formalized process of examining of
written documents by an "outside" reviewer (without a checklist)

Walkthrough
The developer walks one or more colleagues through a piece of code or design that he or she
has written. Colleagues ask questions and make comments about style, defects, adherence to
development standards, and other problems. (according to ANSI/IEEE 729-1983)
Definition: Inspection
Inspection is a formal quality assurance technique in which requirements, design, or code are
examined in depth by a person or group of persons different from the author. The purpose is to
find errors, violations of development standards, and other problems.
Advantages
● Applicable to all software documents: requirements, specifications, drafts,
code, test cases, ...
● Can be carried out at any time and at an early stage
● Very effective in industrial practice
Disadvantages
● manual process
● Consumes time of several employees
● expensive
● "static"

Phases of an inspection
1. Preparation - Determine, prepare, and plan schedule
2. Individual inspections - checks document, uses technique
3. Group session - discussion, collects problems
4. Follow-up - author identifies actual defects, and repairs them
5. Process improvement

Roles
Inspection manager: manages all phases of the inspection
Facilitator: leads the group meeting (usually the head of an inspection).
Inspectors: check the document
Secretary: records defects in the group meeting.
Editor: classifies and fixes the defects (mostly the author)
Author: has written the document

Defect Classification
● major or minor
● Defect, suggestion, or question
● Defect type, e.g. according to NASA SEL (orthogonal defect classification).
○ A: ambiguous information
○ E: extraneous information
○ II: inconsistent information
○ IF: incorrect fact
○ MI: missing information
○ MD: miscellaneous defect

We have two reading techniques, checklist and perspective or scenarios.

Static Analysis Tools
Static analysis of a software component takes place during the translation of the source code or
by special tools. They display errors, check programming style, find errors using error patern
● Warnings and errors
● Are displayed by the development environment. These include, for example:
○ Possibly not initialized variables
○ Unreachable instructions
○ Unnecessary instructions
● Check programming style
○ Indentation inconsistent or forgotten or too deep/flat
○ JavaDoc comments forgotten
○ Parameters not declared as final
● Find errors using error patterns
○ With the help of a static analysis, errors can be found based on certain patterns

Integration testing
The entire system is viewed as a collection of subsystems determined during design
Goal: Test all interfaces between subsystems and the interaction of subsystems

Big bang approach

The Big Bang approach in software testing is a testing strategy that involves waiting until all of
the parts of a software system are completed before starting to test it. Defect search difficult,
Interfaces not tested separately, the worst possible strategy.

Bottom-up strategy
The subsystems in the lowest layer of the call hierarchy are tested individually. Then the
subsystems above this layer tested that call the previously tested subsystems.
Pros: no dummies needed, useful for integration testing of object-oriented systems, with strict
performance requirements
Cons: important last, driver is needed

Top-down Testing Strategy

Test the subsystems in the top layer first. Then combine all the subsystems that are called by
the tested subsystems and test the resulting collection of subsystems.
Pro: no driver needed, case defined by terms of functional requirements.
Cons: dummies needed, a helper is difficult,

Horizontal Integration Risks

1. The higher complexity, the more difficult is integration
2. Later integration, bigger the risk for failures

Vertical Integration
Building as soon as possible. Used in scenario-driven design, Scrum.
Adv: always executable, all the team members have a good overview.
System Test
Testing of the complete system against the product specification. System as BLACK BOX in real
envirionment without customer.
Functional system test: Verification of the functional quality characteristics correctness and
completeness.
Non-Functional system tests: Verification of non-functional quality characteristics, such as:
Security, Usability, Documentation, Fail-safety, and Interpolability.
Regression Test: A regression test is the repetition of a system test because of maintenance,
modification, or correction of the system under consideration. Purpose is to check if the system
has regressed.

Acceptance Test
System test in which the customer observes and directs the tests, the real operating
environment is used. Customer may adapt or change the tests. formal acceptance (for which
the acceptance test is the basis) is the binding declaration of acceptance (in the legal sense) of
a product by the client.

5.2 Testing Tools

Testing tools of the software amateur
● Testing with print statements
● Testing with an interactive debugger
● Testing with test scripts
Disadvantages of these methods are that you need to rerun the program every time you make
changes. Manual checks are often impractical. Results also should be checked manually. It is
impractical to combine test cases for many components and execute them collectively

Alternatives
● Use assertions
Pre- and post-conditions, invariants
Tasks of assertions
At the beginning of a method preconditions are checked regarding parameter
values, at the end results and invariants are checked. Assertions are checked for
all inputs.
● Write automatically running test cases that check themselves.
● Use testing programs that examine software for vulnerabilities.
Warnings and defects
• Are displayed by the development environment. example:
• Potentially uninitialized variables
• Unreachable instructions
• Unnecessary instructions
 • Check programming style
• Indentation
• JavaDoc comments
• Method parameters not declared as final
• Find defects based on error patterns
• With the help of static analysis, defects can be found based on
certain patterns.

6.0 Operation and Maintenance

6.1. Maintenance
The acceptance phase
The completed overall product is accepted and introduced to the user and put into
operation. From this point on, the product is subject to maintenance. Activities in this phase:
delivery of the product including all documentation, acceptance test is associated with the
delivery and useful to perform load and stress tests. For external clients:
• Acceptance test also depends on whether the client ...
• only uses, but does not maintain the product
• uses and maintains it
The introduction phase
Activities
• Setting up the product in its target environment for the purpose of operation
• Training of users and operating personnel
• Commissioning of the product
• Transition between installation and operation
• Introduction protocol
• All incidents that occur during the introduction phase are recorded
• Treat large-scale product launches like innovation launches
• When replacing an existing system: Changeover
Important task:
• Converting existing databases to new formats
• Manual card indexes and paper files must be compiled and
prepared before they can be captured for the new data management
system
• Time must be scheduled for scanning documents and manual
data entry
Commissioning possible in 3 ways:
• Direct transition
There is an immediate transition from the old to the new system. If problems
occur, be prepared to go back to the old system until the problems are solved.
• Parallel run
 Old and the new system runs in parallel. It is costly but the risk is reduced.
• Test run
First-works with old data, whole system
Second- introduction in individual systems
Pilot Instalation/beta run
If a software product is produced for the anonymous market, a series of pilot installations at pilot
customers (beta test) are carried out before a general sales release.
Acceptance & Introduction Phases produce the following results:
• Total product incl. total documentation
• Acceptance protocol
• Introduction protocol.

The maintenance phase

Starts with the successful acceptance and introduction of a product
4 categories of maintenance & care:
● Corrective activities - stabilization, optimization
● Progressive activities - adaptation to a changed environment, extension.

Corrective activities are hard to plan, and customizing, and perfective activities are planned.
Software aging- Software that is not constantly adjusted to both the changing environment and
new requirements will eventually age and become obsolete

Other classification:
• Corrective activities
• Include the identification and correction of:
• Software defects
• Performance deficiencies
• This includes "emergency repairs" that must be performed immediately to
maintain ongoing operations
• Corrective implementation is also part of these activities to bring it in line with
specified product requirements and deliverables.
• Customizing activities
• Adapt the software to changing product environments
• Perfecting activities
• Increase performance, improve cost-effectiveness, processing effectiveness and
maintainability
• This also includes enhancements due to new user requirements
• Most of the effort is spent on customizations and extensions
• 60% to 80%.
Viewing Maintenance as further Development
Adaptations, Enhancements
• Adaptations and enhancements of a product are characteristic for further developments or for
new versions of products
• It therefore makes sense - apart from minimal changes - to let all maintenance activities run
through the normal software development process
• In the evolutionary and incremental process model
• No longer a maintenance phase, maintenance activities are seen as creating a new
product Version.

Re-Engineering
Refurbishment or restoration (re-engineering) of legacy systems;
• There will always be old software
• Old software is the predominant part of the installed software
• During remediation, an understanding of the old software and its transformation into a more
maintainable form (newer language, clearer design, modularized structure) takes place before
the actual change is made
• The development of tools that facilitate software restoration is an important area of research

Maintenance Organization
Advantages of independent maintenance organization;
• Clear allocation of maintenance and development costs
• Relieve developers from maintenance tasks and especially from parallel execution of different
activities
• Qualitatively better acceptance test by the maintenance team
• Better customer service through focus on maintenance
• Hiring of specialized employees or targeted training of employees
• More efficient communication between maintenance employees
• Higher productivity through specialization and related product knowledge.

Disadvantages of independent maintenance organization:

• Maintenance work can get a "bad image", which decreases the motivation of employees
• Valuable knowledge about the product is lost during the transition from development to
maintenance
• Coordination problems between development and maintenance, especially when new products
replace old ones.
• The developers do not have to bear the consequences of their development
• The maintenance employees have to familiarize themselves with the systems in a
time-consuming manner
• It is difficult to achieve an even workload for employees.

7.0 Cost Estimation

Effort estimation
Effort estimation is one of the least popular activities in software engineering, yet it is critical to
the commercial success of a software house.
Profitability of a product:
Profit (loss) = margin * estimated quantity - one timedevelopment costs
Margin = price - variable costs

View of the software manufacturer or the contractor:

• Development costs of a software system:
• Main share of development costs: personnel costs
• Computer and software costs (licenses) for product development
• Costs for other services, training, office supplies, printing costs, documentation, travel
expenses, etc.
• variable costs: marketing, advertisement, maintenance, support, consultants, licenses

Person month = 4w*5d*8h = 160h

delivers about 350 tested source code lines per engineering monthit includes the contributing
costs of all phases: definition, specification, design, implementation, and test (but not
maintenance).

Important influencing factors

● Quantity
Scope - estimate kloc, value depending on programming language
Complexity - quality measure (ez, mid, severe), mapping (1-6)
● Quality
higher the quality requirements, the greater the effort required.
● Development time
Time shortened - more employees, more employees -more communication, more
communication - less productivity. Correlation between effort in PM and development
times is therefore liner
● Costs
● Productivity
Influenced by: ability to learn, motivation, work climate, language, familiarity

Analogy method
Compare the development to be estimated with already completed product developments based
on similarity criteria.
Advantages: Relatively simple and intuitive estimation method
Disadvantages: global estimate based on individual experience, not transferable, lack of a
general approach.

COCOMO II
Calculates the total duration of a SW project in person months from the estimated size and 22
influencing factors. the size is estimated in KLOC or alternatively in unadjusted function points.

• Product factors
• Required Software Reliability, Data Base Size, Product Complexity, Required Reusability,
Documentation match to life-cycle needs
• Platform factors
• Execution Time Constraint, Main Storage Constraint, Platform Volatility, Computer
Turnaround Time
• Personnel factors
• Analyst Capability, Programmer Capability, Applications Experience, Platform Experience,
Language and Tool Experience, Personnel Continuity
• Project factors
• Use of Modern Programming Practices, Use of Software Tools, Multisite Development,
Required Development Schedule, Classified Security Application

Consensus Estimation Methods

Delphi method
One uses a set of estimators (experts) who have experience with the planned SW.
● In one or more rounds, the following is done:
• Each estimator anonymously provides an estimate plus rationale on a card.
• The moderator summarizes the results, including the justifications
• If the values are far apart, a new round is conducted in which the estimators are
allowed to change their estimate. The hope is that the estimated values will converge towards
the "correct" value.
● If nothing changes, take the average value.
● Important: the first estimate is not influenced by other participants.

Planning Poker
● All participants are given a deck of cards with rapidly increasing values, e.g., 0, ½, 1, 2,
3, 5, 8, 13, 20, 40, 100, ∞, and ? ("impossible to guess")
● Each participant lays a card with an estimate on the table, with the
number facing down. (Unit of estimation can be hours, days, or months;
will be agreed beforehand).
● After that, everyone reveals their cards at the same time.
● The estimators with high and low values justify their estimates.
● Process is repeated until consensus is reached.
● An timer keeps the process short.

Depending on the time of the estimate and knowledge of effort-relevant data, one or the other
method should be used:
For early, rough estimates use the
• Analogy method
• Planning poker
When development has stared, size estimates are possible, and the influencing factors are
known, use
• COCOMO II

8.0 Process

8.1 Process Model

What is a process model?
A software process model is an abstraction of the software development process.
Programming by Trial and Error
Also known as “code and fix”. Procedure : create preliminary program, think about requirements,
design, testing, maintenance, improve program.
pros: fast kinda, code created without useless additional efforts
Cons:
● generates poorly structure code because of unsystematic imporvmenets and lack of a
design phase.
● Insufficient task fulfillment due to lack of requirements analysis
● Maintenance costly
● Documentation no no
● No teamwork

Waterfall model
“Phase model”
Procedure
● All activities
● are completed
● in the order given
At the end of each activity there is a finished set of documents → "document-driven" model.
User participation only foreseen in the planning and specification phases.
Waterfall model is useful if requirements will not change during development, for instance in
government projects.

Cons:
● No cross-pphase feedback provided
● Parallelization potential not properly exploited (market launch delayed)
● Forces precise specification of even poorly understood user interfaces and functions
● Not suitable for changing requirements

V-modell 97
Each activity has its own test step

Managers love waterfall models

• Nice milestones
• No need to look back (linear system)
• Always one activity at a time
• Easy to check progress during development: 90% coded, 20% tested
However, software development is non-linear
• While a design is being developed, problems with requirements are identified
• While a program is being coded, design and requirement problems are found
• While a program is tested, coding errors, design errors and requirement errors are found.

Prototype Model
Suitable for systems for which a complete specification cannot be produced without exploratory
development or experimentation. Strengthens morale and trust between supplier and customer.

Incremental Model
Also successive versions - extension ot the prototype idea.
Same pros and area of application as prototype. At least parts of the functionality can be clearly
defined and realized. Has different approaches:
 ● Evolutionary: plan and analyze only the part that will be added next (n-fold waterfall
model)
● Incremental: Plan and analyze everything, then iterate n times through incremental
design, implementation, and testing phases

Synchronize and stabilize

“Microsoft Model”
Approach: organize the 200 programmers of a project into small hacker teams (give freedom),
synch always, stabilize regularly.
Three phases:
● Planning
● Development in 3 sub-projects
● stabilization

Planning phase
● Vision statement: managers identify and prioritize product features based on customer
wishes.
● Specification: Managers and developers define functions, architecture, and component
dependencies based on the desired vision.
● Schedule and team structure: division of tasks into "product function groups" with each
○ 1 Manager
○ 3-8 developers
○ Exactly as many testers as developers (work 1:1 in parallel with developers)
● Duration: 3 -12 months (depending on complexity)

Development Phase
● Tasks
○ Managers coordinate further development of the specification
 ○ Developers design, code and remove bugs
○ Testers work in parallel with their developer
● Three subprojects → Three milestones
○ First third of the planned functionality, most important functions
○ Second third
○ Last third: least important functions

Stabilization Phase
● • Tasks
○ • Managers coordinate beta testers and collect feedback
○ • Developers stabilize code
○ • Testers isolate errors
● • Tests
○ • Internal testing (within Microsoft)
○ • External tests (tests at "beta testers")
● • Preparation for delivery
○ • Burn finished product onto the "master" disc
○ • Prepare documentation for printing
● • Duration: 3 - 8 months

Schedule
● Planning: 3 - 12 Mon.
● Each of the 3 subprojects: 2 - 4 mon., whereby
○ 6 - 10 weeks coding, optimizing, testing, debugging and stabilizing the
functionality
○ 2 - 5 weeks integration, testing and debugging
○ 2 - 5 weeks buffer time
● • Stabilization: 3 - 8 Mon.

Pro
• Effective through short product cycles
• Prioritization according to functions
• Natural modularization by functions
• Progress possible even without complete specification
• Many developers work in small teams and thus just as effectively as a few
• Feedback can be incorporated at an early stage
Contra
• Unsuitable for some types of software - architecture problems, poor fault tolerance,
possibly real-time problems
• Undefined team process: ad-hoc processes in each team, no learning across team
boundaries
• every 18 months 50% of the code has been revised (code instability)
 Sync-and-Stabilize Waterfall

Product development and testing done in Separate phases done in sequence

parallel

Vision statement and evolving Complete "frozen" specification and

specification detailed design before building the
product

Features prioritized and built in 3 or 4 Trying to build all pieces of a product

milestone subprojects simultaneously

Frequent synchronizations (daily builds) One late and large integration and system
and intermediate stabilizations test phase at project's end
(milestones)

"Fixed" release and ship dates and Aiming for feature and product
multiple release cycles "perfection" in each phase

Customer feedback continuous in the Feedback primarily after development as

development process inputs for future projects

Product and process design so large Working primarily as a large group of

teams work like small teams individuals in separate functional
departments

Incremental vs Iterative vs Adaptive

● Incremental means to “add onto something”
○ Incremental development improves your process
● Iterative means to “re-do something”
○ Iterative development improves your product
● Adaptive means “react to changing requirements”
○ Adaptive development improves the reaction to changing customer needs

8.2 Agile Processes

Agile manifesto
Counter reaction to plan driven processes
● Individuals and intereaction more important than processes and tools
● Running software > complete documentation
● Customer cooperation > contract negotiations
● Adapting changes > following a plan

Agaile Processes
● Min advance planning
 ● Planning is incremental
● Avoid supporting documents
● Fast to changes
● Involvement of the customer in the development
● Extreme programming, scrum, software expedition

XP Practices
● Pair programming
● Test-driven development
● Incremental design due to restructuring
● Iterative planning in short cycles (planning game)
● Active participation of the customer
● Continuous integration
● Programming guidelines
● Shared source code ownership
● Textual description of use cases on index cards
● 40-hour weeks

Pair Programming I
One keyboard, one mouse, one screen , driver and navigator
+ Higher quality of a code
+ In built inspections
Properties: Double costs, reliability, good for inexperienced developers. Not good for
experienced developers.

Efficient Testing
Testing should be as close as possible in time to programming. Test cases automated,often, and
repeatable. Fun. only to find defects.

Testing at XP
Programmers write automatic unit tests, customer specifies acceptance tests. Load and stress
acceptable

Component tests
Written by developer, concrete feedback, secure changes, must run at 100 with every code
integration, preservation of existing functionality.

Acceptance tests
Specified by the customer, written by developer, rare - written by customer, test frameworks
such as JUNIT, must be running on delivery at the latest, increases customers confidence.

Test-Driven Development
● Test/Implement/Restructure:
 ○ Motivate any behavioral change to the source code through one or more failing,
automated tests.
● Restructuring and simple design:
○ Always put the code in a simple form.
● Frequent integration:
○ Integrate the code as often as possible.
● Pair programming:
○ Helps comply with the rules of test-driven development.

State diagram of test-driven dev

● Write test code before application code
● small steps (no more than one method per cycle)
● Incremental design (only as much design as presently needed; no forward-looking
design).

• green → red:
Write a test that fails. If necessary, write just enough source code (stubs, dummies, mocks) to
compile and execute the test.
• red → green:
Write just enough source code to run all tests successfully.
• green → green:
Cleanup by restructuring: eliminate duplications and other impurities in the source code. All
tests must still run.

Role of the Component Tests

• Tests for quality assurance:
Test coverage criteria apply
• Test-first development leads to "Evolutionary Design": The design emerges incrementally.
• Tests for interface definition/specification:
Tests use classes and methods before they are programmed out (stubs required).
• Tests for modularization:
Testability requires decoupling of program parts.
• Tests as executable specification and documentation (compensate for missing design phase)

Refactoring
"A change made to the internal structure of software to make it easier to understand and
cheaper to modify without changing its observable behavior."

Prerequisites: automatic tests, collective code ownership.

Goal: Always produce a form that is as simple as possible and sufficient for the requirements
implemented to-date (no change-friendly, forwardlooking design necessary).
Performed on bad smells of the programm text: like duplicates, parallel inheritance trees,
shotgun surgery.

Incremental Design
Conventional approach:
"Implement for today, design for tomorrow"
XP approach:
"The system should be designed as simply as possible at any given moment. Extra complexity
is removed as soon as it is discovered."

Planning game
Goal: Planning of scope, time and costs
• the next iteration (weekly cycle)
• the next delivery (quarterly cycle)
Constant correction of the plan

Competencies in the planning game

• The customer makes the business-relevant decisions
• Scope of the system
• Functionality priorities
• Composition of a release
• Date of release
• The development team makes the technical decisions
• Estimation of costs and risk
• Technical consequences
• (Development) process
• Sequencing
• The customer can correct his decision at any time

Release Planning
Release planning replaces conventional requirements analysis. Planning for 1-4 months.
● Approximate project plan is created jointly by the customer and the development team
○ • Customer expresses his wishes (use case cards)
○ • Team estimates the costs and risks
○ • Customer prioritizes his wishes
○ • Entire team sets timeline for key customer requests

Iteration Planning
Takes place several times between planning and release. Planning horizon: 1 - 4 weeks.
● All tasks are written down on task cards:
○ Breakdown of use cases into smaller tasks
○ Merging to small tasks
○ Identification of additional tasks
■ Prototypes
■ Versioning
Team members commit to tasks and estimates effort for their tasks, Balance between team
members is established, Feedback to the customer.

Customer on Site
• Real customer is someone who will really use the product later
• Customer should be available all the time
• Originally: The customer should work in the same room as the developer team
• Is not easy to accomplish in practice, and customer is underutilized.
• In a time of remote work, a customer on site is overkill. Remote presence and a remote trial of
emerging product is enough.

XP Criticism
• Missing product documentation (although can be added if required)
• Non-reproducible, ad-hoc process in iterations
• Pair programming costly, unclear whether this is compensated by the increase in quality
• XP can react quickly to changing requirements—adaptation of the plan possible at the
beginning of every iteration.

Problems with the introduction of XP

● Customer must participate and want to do so
● Software engineers are trained to anticipate future changes, extensions. The
consequence can be:
○ design too complex
○ design too comprehensive, later discarded (wasted work)
● Test-driven development requires rethinking and relearning
● Same wavelength for pair programmers (must be able to work together)

XP rating
● XP = programming by trial and error?
● No,
○ Planning steps
○ Successful tests required
○ Test-driven development and restructuring compensate for missing design phase
○ Pair programming compensates for missing inspections
● Cowboy programmer disciplined
● Planning spectrum
○ XP: lightweight, changeable planning, small teams
 ○ Waterfall model: heavyweight, fixed planning

Summary
● XP is suitable
○ For vague and rapidly changing requirements
○ For small team of developers (6-10 developers)
○ Without time-consuming bureaucracy, documents
● Software development with light baggage
● Large projects require at least a requirements phase and a design phase that divides
the overall task so that XP teams can work independently.

SCRUM

Core Components in Scrum

● 3 Artifacts
○ Product Backlog: Vague requirements for the whole project
○ Sprint Backlog: Detailed requirements for one iteration (“sprint”)
○ Potentially Shippable Product Increment: The deliverable for each Sprint
● • 4 Meeting Activities
○ Kickoff Meeting: At the beginning of a project
○ Sprint Planning Meeting: List of prioritized features
○ Daily Scrum: Informal daily meeting, about 15 min
○ Sprint Review Meeting: Demonstration of features to management and customer
● • 3 Roles
○ Scrum Master: Responsible for the process
○ Product Owner: Responsible for the product
 ○ Developer: Responsible for the realization of the Potentially Shippable Product
formalIncrement

Scrum - Roles
● Product owner (responsible for the product)
○ Is responsible for adding value to the product and the requirements list
○ Defines the requirements for the product
○ Prioritizes requirements and adjusts requirements and their priority for each
sprint.
● Scrum Master (responsible for the process)
○ Ensures compliance with Scrum values and techniques.
○ Ensures that the development team is complete, functional, and productive and
protects the development team from outside interference.
○ Removes barriers and supports collaboration between all roles.
● • Developer Team (5-6 members)
○ Are responsible for implementing the tasks defined in the task list.
○ Consists of people with different areas of expertise (programmers, UI
designers,...) and organizes itself.
○ Composition of a team does not change during a sprint.

Project-Kickoff Meeting
● A collaborative meeting in the beginning of the project
○ Participants: Product Owner, Scrum Master
○ Takes 8 hours and consists of 2 parts (“before lunch and after lunch”)
● Goal: Create the Product Backlog

Sprint Planning Meeting

• The developers agree on a sprint target together with the product owner.
• They select those requirements from the product backlog that they can complete in this sprint
and form the sprint backlog
Daily Scrum Meeting
● A short (15 minutes long) meeting, which is held every day before the Team starts
working
● Participants:
○ Scrum Master (which is the chairman), Scrum Team
● Every Team member should answer 3 questions:
1. Status: What did I do since the last Scrum meeting?
2. Issues (Impediments): What is stopping me getting on with the work?
3. Action items: What am I doing until the next Scrum meeting?

Two Meetings at the end of a sprint

● Sprint Review
○ The Scrum Team presents the results of the Sprint, e.g. in the form of a
demonstration of the new features
○ Results are discussed and, if necessary, the list of requirements is adjusted and
○ what is to be done next is discussed.
○ Participants are the Scrum team as well as representatives of other stakeholders,
e.g., customers and users.
● Sprint Retrospective
○ The Scrum team analyzes the previous sprint
○ Focused on the process (What went well? What didn't?)
○ Derive consequences for next sprint
○ Goal: reflect and improve

0.1 The Tool Chain

Origin of the Configuration management
When? U.S. space industry in 1950s and 1960s
During the development of rockets and satellites, numerous changes were made that were not
documented. Prototypes were destroyed during tests or shot into space, or sunk in the ocean,
the original plans were obsolete, therefore reconstruction impossible.
→ Configuration management was to document all changes to spacecraft so that any
development status could be restored.

Software configuration management

is the discipline of tracking and
controlling the evolution of software.

Configuration Management (CM)

ISO 9001:
"Configuration management provides a mechanism for identifying, directing, and tracking the
versions of each software element."
(Software) Configuration
A (software) configuration is a uniquely named set of software elements, with their valid version
identification, which are coordinated with each other in their operation and their interfaces at a
specific point in time in the product life cycle, and which fulfill an intended task together.

Software Element (SE)

A software element is any identifiable component of a product or product line. A software
element can be a single file, or a configuration. (a product line is a set of related products that
have software elements in common).

● Has system-wide unique identifier

● Change of an element creates a new version with a new, unique identifier to avoid
misidentification
● Distinguish
○ Source element: created manually, e.g., with editor or drawing tool
■ needs to be stored in the repository indefinitely
○ Derived element: automatically generated, e.g., by translator, compiler
■ can be deleted, because it can be regenerated automatically

Versions
● A version is the expression of a software element at a certain point in time.
● Revisions are successive versions (development statess).
● Variants are alternative versions (customizations, or with alternative data
structures/algorithms, for different platform, different GUI, etc.).

Checkout/Modify/Checkin Cycle
Software elements are collected in repositories
Checkout
● Fetches copy from repository
● Reserves copy for the person checking out, which means that only this person may file
the next revision (strict checkout)
● Copy may be changed, tested and checked in again
Checkin
● checks reservation
● writes copy back to repository
● deletes reservation
● records meta data:
○ Author of the element/change
○ Checkin time
○ Logbook entry summarizing change
● checked-in element can no longer be modified
● only checking out again allows modifications (and produces a new version)
Users are allowed to check out as many elements as they want.
Read access for other team members is not prevented by change reservation (only
modification). So, others can compile the entire system, for instance, even if there are change
reservations.
Distinguish
● Strict checkout: with change reservation
● Optimistic or multiple checkout: Without change reservation; may require merge
operation later.

Strict Checkout
Only one checkout with change reservation per version of an SE is allowed. Person with
reservation has exclusive right to change (i.e., to deposit next revision)
Advantage:
● no merging effort when checking in, because only one developer at a time (the one who
currently owns the reservation) is allowed to modify the version.
Disadvantage:
● only one person at a time can change the checked-out version.
● This can lead to delays (in case of illness, absence, workload of person holding the
reservation).

Optimistic Checkout
No change reservation necessary. One can checkout and modify at any time.
Advantage:
● Multiple developers can work on the same element at the same time.
● A single individual cannot stop the work.
Disadvantage:
● There may be simultaneous changes to the same version
● This creates effort in merging the versions (the one that checks in first does not
need to merge; but all later ones do).
Merging the versions:
● Status of the checked-out version may have changed in the repository
● Merging of changes and resolution of conflicts may be necessary.

Components of a (software) configuration

● Source elements, e.g.
○ Program text
○ Libraries
○ Initialization data
○ Documentation
○ Configuration files for system to be built
● Derived elements (translated, formatted, linked,...)
● Tools used (translator, formatter, linker, loader,....)

Configuration for intermediate steps of the SW development process

 ● Configurations for all results of all development phases, e.g.
○ Requirements documents
○ Models
○ Specification
○ Design
● tracking these enables
○ Reviewing of changes
○ tracing software to requirements and specifications (important for changes)
○ Reset to a working configuration

How are versions Managed?

Complete saving of each version is space consuming. Alternative:
Forward deltas: save basic version and changes made to it
Backward deltas: save current version and the reverse changes for previous versions
A delta is the difference between two versions; a change script that transforms one version to
the other. In software, a delta is usually about 1-2% of the size of a (full) version.

Forward Deltas
Advantages
Quick access to old versions
Disadvantages
Slow access to more recent version
Current version is needed most often

Revision Control System (RCS, 1983)

Manages multiple versions of a file
● Automated
● Storage
● Recovery
● Logbook
● Automatic identification of the software elements
● Merging versions
Versioning of directories not supported. No remote access (repository is local).

Concurrent Versions System (CVS,

1990)
Versions entire directory trees
Internet enabled (checkout from,
checkin to, remote repositories)
Uses RCS internally

Subversion (SVN, 2000)

● Further development of CVS
 ● Internet-enabled, i.e., the repository is stored on a server, the workstation computer is
accessed via the Internet.
● SVN versions the entire project repository, including moving, renaming and copying
directories and files.
● Checkin is atomic, i.e., a change is transferred to the project repository completely or not
at all. There is no danger of an inconsistent state because of an aborted checkin.
● Optimistic checkout.

GIT
● abstraction of files; everything is an object: file contents, directories, configurations,
variants
● Dealing with variants is an integral part
● Cryptographic security of the history
● Entire repository is local for each user
● For this additional communication step: push/pull/fetch for transferring objects between
repositories
● "command hierarchies" and workflows (for release of configurations)

User Interface
● git <command> , e.g.
● help - list of commands
● init - Create repository, Create empty project in repository or "transport" an existing
project to repository
● clone - load repository of a project
● add - Add new file/change to be tracked by GIT; transfer file to the staging area.
● rm – remove a file from tracking by Git
● commit - Apply added changes to your own repository
● push - transfer commits to (remote) repository, now visible to all in project.
● fetch - get changes from (remote) repository to local repository
● merge - combine changes of one development branch with another (from local repo to
working directory)
● pull - fetch + merge

Creating a Git repository

● The repository is located on your computer.
● git init
○ Creates new, empty repository in the current directory named .git
○ Example: c:\Test\> git init
● You're already done - no need to checkout for a working copy!
● Start populating the directory with files and directories. These are initially untracked by
Git.

Checkin
● git add <file|directory>
 ○ Adds <file|directory> to the staging area. Now the files are tracked.
○ This is how you collect semantically related changes and prepare for the Commit.
● git commit –m ’initial project version’
○ Writes back the files in the staging area to your own, local repository.
○ No conflicts, since this is a local operation.

● git pull <repository>

(fetch) Fetches changes from the repository
A
/ – - b - - C - master on origin
D---E---F---G master
● (merge) Updates local files with new versions from the repository that have been
committed since last checkout.

Testing
Software amateur testing tools
● Testing with output statements in the program
● Testing with an interactive debugger
● Testing with test scripts
● Common to all, Manual check of the outputs
Cons: Test cases must be repeated when program changes are made, Tedious and impractical
and often impossible

Automatically running test cases

● Check result of their execution themself
● Return: boolean value (successful or failed)
● Optional: Raise an exception on failure
● Can be assembled into large test suits.
● Can be executed any number of times (daily, hourly, at each change).
 ● Can be used as a regression test.

JUnit 5: framework
Fast and hierarchical, returns failed test cases.
● Contains (related) test cases in the form of methods.
● Usually holds references to the test objects to be tested
● The comparisons of target and actual values take place using assertions from the
org.junit.jupiter.api.Assertions class.
● Labeling of the test methods is done with annotations.

Excursus: Annotations as of Java 5

● Annotations are meta-information that can be added to the source code.
● They remain in the byte code, but do not directly affect the execution of the program.
● They can be read and processed at translation time by tools and at runtime by reflection.
● Annotations may occur in any declaration: Package, Class, Interface, Instance/Class
Variable, Method, Parameter, Constructor, Local Variable.
● Example: mark method as deprecated : @Deprecated public void tuWas() { ... }

Some asserts
● assertEquals(Object shall, Object is)
○ Fails if the call to the equals method of shall with the parameter is returns the
value false.
● assertSame(Object shall, Object is)
○ Fails if the references point to different objects.
● assertEquals(float shall, float is, float delta)
○ Fails if shall and is differ by more than delta.
● assertTrue(boolean expression), assertFalse(boolean expression)
○ Fails if the expression is false/true.
● assertNull(Object reference), assertNotNull(Object reference)
○ Fails if the reference is not null/null.
● assertThrows(Class<T> exceptiontype, Executable subprogram)
○ Fails if the expected exception of type exceptiontype does not occur when
executing subprogramm.
● Example: assertThrows(SQLException.class, () -> {...});
○ To all these methods there is a variant with a string for a message in case of
error.

Annotations
@Test - Marks a test case
@Timeout(42) - Sets the maximum runtime in seconds
@Disabled - Marks a test case that should not be executed The reason is specified as a string:
@Disabled("Functionality is still missing.")
@Test public void borrowBook() { ... }
@BeforeEach - Marks a method that is executed before each test case.
@AfterEach - Marks a method that is executed after each test case.
@BeforeAll - Marks a class method that is executed before the test class is instantiated.
@AfterAll - Marks a class method that will be executed after all other methods mentioned so far.

AUTOMATION WITH MAVEN

Tool for (partial) automation of tasks during the development process "Standardized" file format
for specifying task steps, dependencies, and data in the artifact development process.
Automated execution of development process tasks

● Archetype
○ Programming project template, e.g. J2EE, sample project, Maven plugin
○ Create a new project: mvn archetype:generate
● Artifact ID
○ Artifact name
○ Multiple artifacts possible within one Maven project
● Group ID
○ Equivalent to the "package" line of the Java source files

● mvn < plugin>:< goal>

○ Plugin
■ Partial functionality of Maven for a specific task
■ Examples: Version control, compiling, testing, creating new (empty)
project according to a template, …
○ Goal
■ Specific subtask of the development process
■ Defined from convention or pom.xml
■ A plugin provides a set of Goals

Exam questions
2019
Aufwarmen
1) Optimization, stabilition
2) can be used to identify use cases, describe the use of a system from the point of view of
a uses
3) Analogie, relationsmethod, planungspoker
4) defines activities and products as well as responsibilities, is divided into submodels,
has the waterfall model
2018
1) Agile software development with Scrum allows new customer requirements at any time
in the current task list (engl. sprint backlog) be taken over. T
 2) Older software products tend to be easier to maintain because corrective actions have
already been taken. F
3) Formal acceptance is the (written) declaration of acceptance of a product by the
customer. T
4) With the analogy method, the effort of the development phases estimated based on
previous phases. T
5) The customer specifies his requirements for the product in the specification system to
be developed. T
6) The customer specifies his requirements for the product in the specification system to
be developed. T
7) The scope of a Maven integrated Library determines when to expose this on the
classpath will. F

2016
a) What is the difference between variant creation and revisions?
Revisions are successive versions (development stages) Variants are alternative versions
(adaptations, or with alternative data structures/algorithms, for other platforms, other GUIs, etc.)
b) What is the difference between strict and optimistic check-in/check-out? What are the pros
and cons of each?
strict: exclusive booking out, change reservation optimistic: multiple booking out, no change
reservation Advantage strict: no conflicts Advantage optimistic: simultaneous processing
possible
c) What are forward and backwards deltas? What are the pros and cons of each?
Forward deltas: Save basic version and the changes made to it Backward deltas: Save current
version and the changes for earlier versions Advantage of forward deltas: Quick access to basic
version Advantage of backward deltas: Quick access to current version
d) to what extent do SVN and GIT differ with regard to the depot organization?
SVN: Server-side, mostly, online, not distributed. GIT: local and possibly, remote depot,
distributed.
1. Java assertions are evaluated at compile time. F
2. With the help of unit tests, the correctness of a program can be guaranteed wil. F
3. Request errors always lead to a failure of the software. F
4. In a static test procedure, the source text is analyzed without run the program. T
5. During the software inspection, the inspectors meet after the individual Troubleshooting
to fix the identified errors.b
6. A system test also includes non-functional quality features checked, e.g. usability. T
7. A parallel run as an introductory phase reduces operating costs. F
8. Maintenance & care in software development include both corrective as well as
progressive activities. T
 9. If a company has its own maintenance organization development and maintenance
costs can be clearly separated will. T
10. In software re-engineering, software comes first brought into a more maintainable form
and then expanded. T
11.

Version control
1. Each Git post has exactly one or two parent posts. F
2. A Git repository is a directed, acyclic graph. T
3. SVN saves commits as filesystem snapshots. F
4. Each time Git logs in, the head pointer (HEAD) is automatically set to the newly created
booking is set. T
5. In order to create a new development branch (branch), a new Registration created with
the initial state of the new branch. F
6. Git globally uniquely identifies postings with a cryptographic hash value (hash). T
7. SVN uniquely identifies rebookings globally with a consecutive number. T
8. Unlike Git, in SVN all operations are performed on a (remote) Depot/Server performed. F