software development is like running a restaurant
+
+
come up with recipes,
+
cook the food,
+
ingredient logistics and preparation,
+
food serving,
+
marketing,
+
cleaning
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
software development often compared to house building
+
+
+
+
because it is an engineering discipline
+
but software does not have to obey the laws of physics
+
software design should focus only on the data structures and the
+connection between the modules
+
+
not the implementation details (e.g., hardware)
+
+
+
+
+
+
+
+
+
+
+
+
software development is more like gardening
+
+
+
+
a garden might be planned
+
external factors influence the result
+
+
weather, pests
+
+
garden needs constant care to bloom
+
sometimes also experimentation
+
+
methods, tools
+
+
garden is like an art (with function)
+
+
+
+
+
+
+
+
+
+
+
software growth
+
+
+
+
number of lines of code is increasing
+
+
which increases complexity
+
+
“every line of code written comes at a price: maintenance” [1]
+
+
larger garden, more gardening
+
+
software development processes to handle the complexity
+
+
+
+
+
+
+
+
+
+
+
+
evolution of software life cycle models (incomplete)
+
+
+
+
software life cycle models
+
+
waterfall
+
+
improved waterfall
+
+
V model
+
iterative
+
agile
+
+
regarding to change management
+
+
+
+
+
+
+
+
+
+
waterfall model
+
+
+
+
sequential, rigid model
+
+
(originally) not possible to step back to a previous phase
+
+
testing is after the implementation, errors are found late in the
+process
+
not possible to make changes during the development
+
could take years
+
+
+
+
+
+
+
+
+
+
+
V model
+
+
+
+
still rigid
+
each phase has output and a review process
+
+
errors are found at early stage
+
decreases the risk of failure
+
+
large to small: testing is done in a hierarchical perspective
+
+
+
+
+
+
+
+
+
+
iterative model
+
+
+
+
software is built incrementally,
+
+
with each iteration adding new features or refining existing
+ones
+
+
possible to get feedback after each iteration
+
can be rigid within an iteration
+
+
+
+
+
+
+
+
+
+
agile model
+
+
+
+
continuous collaboration and fast response to change, while the
+iterative model takes a more gradual approach, building up the final
+product over multiple iterations
+
scrum is an agile methodology
+
+
+
+
+
+
+
+
+
+
+
scrum team
+
+
optimally 3 to 9 people
+
cross-functional
+
self-organizing
+
+
+
+
roles
+
+
scrum master
+
+
responsible establishing scrum as defined in the Scrum Guide
+
+
by helping everyone understand the theory and practice, both within
+the scrum team and the organization
+
+
responsible for the scrum team’s effectiveness
+
+
product owner
+
+
responsible for maximizing the value of the product resulting from
+the work of the scrum team
+
also responsible for effective product backlog management
+
+
developers
+
+
+
+
sprint planning
+
+
initiates the sprint
+
maximum of eight hours for a one-month sprint
+
define a sprint goal
+
+
definition of done
+
+
it is up to the developers how to turn product backlog items into
+increments
+
+
+
+
+
+
sprint
+
+
1-4 week long
+
considered a short project
+
turns backlog items into increments
+
includes daily scrum
+
+
+
+
+
+
sprint review
+
+
scrum team presents the their work to the stakeholders
+
+
increment is evaluated
+
+
the attendees collaborate on what to do next
+
maximum of four hours for a one-month sprint
+
+
+
+
+
+
sprint retrospective
+
+
concludes the sprint
+
maximum of three hours for a one-month sprint
+
the scrum team discusses what went well/bad, what problems
+encountered
+
+
+
+
+
+
kanban
+
+
+
+
uses a visual workflow
+
pull-based system
+
+
no task in the workflow without request
+
+
uses columns for states of the product
+
defines conditions when to move a task between columns
+
conditions flow
+
+
no iterations (sprints)
+
no roles
+
+
encourages to improve the workflow
+
+
+
+
+
+
+
+
+
+
steps of requirement analysis
+
+
+
+based on [2]
+
+
+
+
+
functional and non-functional requirements
+
+
+
+
functional requirements define what a system is
+supposed to do
+
non-functional requirements define how a system
+is supposed to operate
+
a popular tool in requirements analysis, particularly in agile
+software development methodologies
+
simple description of a software feature
+
+
from the perspective of the end user or customer
+
+
and are often accompanied by acceptance criteria (BDD),
+
+
which define the conditions that must be met to be considered
+complete
+
+
+
+
+
as a [type of user], I want to
+[action/function] in order to
+[benefit/value]
+
+
+
+
+
behaviour-driven development
+
+
+
+
BDD starts from a user story and focuses on adding acceptance
+criteria
+
extends user stories how the software should react in some with
+scenarios (conditions)
+
+
+
Title (one line describing the story)
+
+Narrative:
+As a [role]
+I want [feature]
+So that [benefit]
+
+Acceptance Criteria:
+(presented as Scenarios)
+
+Scenario 1: Title
+Given [context]
+ And [some more context]...
+When [event]
+Then [outcome]
+ And [another outcome]...
+
+Scenario 2: ...
+
+
+
+
+
+
+
user story mapping
+
+
+
+
performed in workshops including
+
+
users,
+
(UI) designers,
+
developers,
+
testers,
+
and stakeholders
+
+
build a shared understanding of the product and a common
+language
SOLID is a mnemonic acronym for five
+design principles intended to make object-oriented designs more
+understandable, flexible, and maintainable [9]
+
+
single responsibility principle
+
+a class should do one thing and therefore it
+should have only a single reason to change
+
+
open-closed principle
+
+classes should be open for extension and
+closed to modification
+
+
Liskov substitution principle
+
+if class A is a subtype of class B, B should
+be able to replaced with A without disrupting the behavior of the
+program
+
+
interface segregation principle
+
+many client-specific interfaces are better
+than one general-purpose interface. Clients should not be forced to
+implement a function they do no need.
+
+
dependency inversion principle
+
+modules should depend upon interfaces or
+abstract classes, not concrete classes. It’s an inversion because
+implementations depend upon abstractions and not the other way
+round
+
+
+
+
based on [10], [11]
+
+
+
+
+
coupling
+
+
+
+
the degree of interdependence between software modules
+
coupling is usually contrasted with cohesion
+
+
low coupling often correlates with high cohesion, and vice
+versa
multiple countries in the case of an international team
+
+
things won’t go as planned, so
+
+
add safety margin (wiggle room)
+
e.g., an extra week before deadline for fixing bugs
+
+
+
+
+
+Gantt chart from Wikipedia
+ public domain
+
+
+
+
+
+
+
+
assign responsibilities and tasks
+
+
+
+
every task you want to make done should have exactly one person
+responsible
+
+
no assignee – no one will do it
+
more than one – “I though the other one was doing it”
+
+
define area of responsibility
+
+
a task (as in scrum) should have definition of done, which specifies
+it
+
+
everyone needs to know what other people are responsible for
+
+
scrum/kanban board can visualize it
+
issue/ticket trackers can also work
+
+
+
+
+
at the end of a sprint planning, every task in the sprint backlog
+should have an assignee
+
+
+
+
source: [14]
+
+
+
+
dependencies
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
allocate resources
+
+
+
+
scrum (and agile in general) does not say anything about
+how to estimate (time)
+
story points are often used instead
+
+
(relative) unit of effort required to fully implement a product
+backlog item
+
e.g., 1–5,
+
Fibonacci: 1, 2, 3, 5, 8, 13…
+
powers of 2: 1, 2, 4, 8, 16, 32…
+
+
+
+
+
+planning poker by Hkniberg
+ public domain
+
+
+
+
+
“Story points reward team members for solving problems based on
+difficulty, not time spent. This keeps team members focused on shipping
+value, not spending time [15].”
+
+
+
+
estimation is guessing
+
+
+
+
many developers do not like to estimate
+
seemingly simple task can turn out to be difficult
+
+
some difficulties are hard to foresee
+
bad architectural decision
+
+
“Adding manpower to a late software
+project makes it later.” – Fred Brooks
+
+
+
make educated guesses instead
+
+
measure
+
+
burn down charts, cumulative flow
+diagram
+
+
infer from previous tasks
+
+
+
+
+
+
+
+
+
code quality
+
+
+
agile
+
+working software over comprehensive documentation
+
+
+
+
+
+
software craftmanship
+
+not only working software, but also well-crafted software
+
+
+
+
+
+
+
well-crafted
+
+
+
high quality
+
+
+
+
+
well-designed
+
+
+
+
+
validated and verified
+
+
+
+
+
tested
+
+
+
+
+
code is clean, easy to understand and maintain
+
+
+
+
+
+
+
+
+
+
code smell
+
+
a code smell is a surface indication that usually corresponds to a
+deeper problem
+
– Martin Flower [16]
+
+
+
+
software rot is the degradation, deterioration, or loss of the use or
+performance of software over time [17]
+
+
requirement smell: signs in the requirements that
+are not necessarily wrong but could be problematic [18]
+
+
+
+
+
clean clode violations as code smells
+
+
+
+
long method
+
long parameter list
+
naming
+
+
notation in names
+
inconsistent names
+
uncommunicative names
+
+
comments
+
large class
+
+
possibly do more than one thing
+
+
a function / class does more than one thing
+
+
+
+
magic number
+
duplicated code
+
speculative generality
+
dead code
+
too complexity comditions
+
feature envy
+
bad comment
+
+
obsolete, redundant (noise), commented-out code
+
+
+
+
+
+
source: [19], [20]
+
+
+
+
+
how to measure code quality?
+
it is hard to objectively measure the quality of code
+
+
+
+
number of source lines of code
+(SLOC)
+
style guide compliance – is the code clean?
+
Halstead metrics
+
cyclomatic complexity – is the code simple?
+
maintainability index
+
test coverage – is the code tested?
+
+
+
+
+
+
+
+
cyclomatic comlexity
+
+
developed by Thomas J. McCabe in 1976
+
quantitative measure of the number of linearly independent paths
+through the source code
+
computed using the control-flow graph of the program
the percentage of the code lines ‘protected’ or covered by
+tests
+
+
+
+
code/fizzbuzz.py
+
+
+
def fizzbuzz(i: int) ->str:
+ result =""
+if i %15==0:
+ result +="FizzBuzz"
+elif i %3==0:
+ result +="Fizz"
+elif i %5==0:
+ result +="Buzz"
+else:
+ result =str(i)
+return result
+
+
+
def fizzbuzz(i: int) ->str:
+ result =""
+if i %15==0:
+ result +="FizzBuzz"
+elif i %3==0:
+ result +="Fizz"
+elif i %5==0:
+ result +="Buzz"
+else:
+ result =str(i)
+return result
+
+
+
def fizzbuzz(i: int) ->str:
+ result =""
+if i %15==0:
+ result +="FizzBuzz"
+elif i %3==0:
+ result +="Fizz"
+elif i %5==0:
+ result +="Buzz"
+else:
+ result =str(i)
+return result
H.
+Femmer, D. M. Fernández, S. Wagner, and S. Eder, “Rapid quality
+assurance with requirements smells,”Journal of Systems and
+Software, vol. 123, pp. 190–213, 2017.
![based on [2]](figures/requirement_analysis_steps.drawio.svg)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
