Learning Objectives DBA
Objective 1: Software Development Processes
• Remember what a system, a socio-technical system, and emergent system properties are
• Explain the principal activities involved in systems engineering: requirements engineering,
(problem) analysis, modeling, (solution) design, implementation, quality assurance,
operation, maintenance, and related management activities
• Explain the special nature of software-based systems in contrast to other technical systems
• Produce a software business case for a self-selected software development effort
• Understand the purpose of software development processes
• Able to clarify under which circumstances the Waterfall model, the V model, the Spiral
model, the (Rational) Unified Process, the Incremental Model, or Prototyping, is most
appropriate
Objective 2: Software Requirements
• Explain the importance of requirements engineering within software engineering
• Explain key challenges in and techniques for requirements discovery, development, analysis,
communication, and validation
• Apply the following techniques for requirements discovery: interviewing, scenario analysis,
and use cases
• Produce specifications of stakeholder requirements and system requirements, functional
requirements, non-functional / performance requirements, and constraints using the most
appropriate of the following representations: natural language, structured language,
graphical specifications, mathematical specifications.
Objective 3: Software Design
• Describe the purpose of requirements traceability and the tools used for establishing it
• Describe the role of modeling in software engineering
• Explain the notions of (object) classes, attributes, operations, cardinality / multiplicity,
association, composition, and generalization and use them correctly in modeling stylized
scenarios
• Draw and critique structural models of a simple problem domain using Unified Modeling
Language (UML) class diagrams
• Draw and critique behavioral models of a simple problem domain using UML activity, state,
use case and sequence diagrams
• Analyze the unstructured description of a software development effort to distinguish between
requirements and design ideas
• Explain key concepts in good software design: abstraction, architecture, separation of
concerns, modularity, refinement, refactoring, and low coupling / high cohesion
• Explain the connection between design, requirements, and business value
• Use Impact Estimation to calculate value-maximizing design decisions in a principled fashion
• Check the unstructured description of a design idea for violations of the design principles
above, and for value-creation issues
Objective 4: Value Based Software Engineering and Project Management
• Describe common problems in value creation through software projects, and the sources of
these problems
• Identify such problems in an unstructured description of a stylized development effort
• Explain the roles of iterative approaches, of continuous learning and refinement, and of
quantified performance requirements in value creation
• Explain the characteristics of a good plan for a software development effort: putting planning
before the plan, planning iteratively, continuous refinement, embracing change, and
maintaining the connection with the business case
• Apply fundamental estimation techniques for size and effort to the unstructured description of
a software development effort: counting, calibration, and historical data, expert judgements
• Explain the role of uncertainty in estimates for size and effort: the cone of uncertainty
Carli Wischhoff DBA 2018-2019 1
,Week 1 – Software Engineering & Software Development Processes
–
(DBA.L1.1) What is DBA about?
It is about all the processes you need to take to develop a software (e.g. software development).
Software is hard to define, but could be defines as ‘any set of machine-readable instructions that
directs a computer processor to perform specific operations)’ thus, Application software is only one
type of software.
DBA is about all the processes you need to take to develop a software. Example: Develop a software
that takes two numbers x and y and return the sum (x+y)
–
(DBA.L1.2) The inherent difficulties of software systems
Challenged and failed projects account for a great deal (+/- 60% of the total delivered project in 2009)
- High challenged & failure rates
- Costly
- Inherent difficulties of software; complexity (interactions increase super-linearly, no
definitive problem specification), Invisibility (software cannot be embedded in space),
Changeability (constant requests for changes), Conformity (non-uniform – i.e. due to
different styles)
–
(DBA.L1.3) The definition of systems, socio-technical systems, emergent properties
System: A purposeful collection of interrelated components that work together to achieve some
objective (e.g. a pen)
Software included systems:
Technical computer-based systems: include software and hardware but not procedures and processes
(e.g. TV, Phone)
Socio-technical systems: include technical parts but, crucially, also include knowledge of how the
system should be used to achieve some broader objectives (e.g. social media). Have emergent
properties, often non-deterministic, success/failure depends also on interpretation
Emergent properties: Emerge as the system components are integrated with one another.
Functional: Appear when all the parts of a system work together to achieve some
objective (i.e. bike is a transportation device)
Non-functional: Relate to the behavior of the system in its operational environment
(reliability, performance, security, etc.
–
(DBA.L1.4) Software engineering, software processes, process flows (linear, iterative,
evolutionary, parallel)
DBA is about software engineering. This term was first used in 1968 at a conference for ‘software
crisis’. Software engineering is critical for the successful development of complex, computer-based
socio-technical systems.
Software engineering is not computer science (practice vs theory) & software engineering is not
systems engineering
Software engineering = requirements engineering, analysis, modeling and design (in generic
problem terms: understand the problem and plan a solution)
Sommerville describes it as software specification and software development. Pressman describes it
as the process of communication, planning and modeling.
Carli Wischhoff DBA 2018-2019 2
,Software processes: Consists of the framework activities (communication, planning, modelling,
construction, deployment) the (umbrella) actions and tasks sets
Process flow: Different ways to sequence framework activities; linear, iterative (and evolutionary)
and parallel
Linear process flow:
i.e. Waterfall Model & V-model
Pros: Works well when all the requirements are known in advance, it is well
documented and predictable
Cons: Real project rarely follow a linear flow, problem of the blocking state,
infeasible to acquire upfront requirement statements, little feedback and
learning opportunities, inflexible
Iterative process flow:
i.e. Evolutionary model: Spiral and prototyping
Prototyping: Serves as a first system, stand alone or as part of other process
flows, emphasis on quick delivery, feedback, learning about
customer requirements (i.e. Itunes)
Pros: Stakeholders like it (feeling actual system), developers
like it (quick build), best serves as a mechanism for
identifying software requirements
Cons: Does not consider the overall software quality or long-
term maintainability, compromising to get work quickly, The
habits of less-than-ideal choice
Spiral model: A rapid development of increasingly more complete versions
of the software, Difficult to convince customers it is controllable. If major
risks are uncovered problems occur
Cons: Unclear # of cycles, and difficult to estimate the time
needed for each cycle (i.e. too slow = productivity failure
and too fast = chaos
Carli Wischhoff DBA 2018-2019 3
, Evolutionary process flow:
Software evolves over a period of time → requirements change
Tight market deadlines prohibit a one-shot comprehensive software product
A limited version satisfies the business pressure and competitiveness
Parallel process flow:
Perspective process models:
Also called traditional process models: strive for structure and order in software
development
Incremental process models → Linear + parallel
Requirements are relatively well defined
Particularly useful when staffing is unavailable for a complete implementation. Additional
functionality in each iteration (i.e. 1st iteration is the core product) Word Processor iterations
Rational Unified Process (RUP) → Iterative + parallel
Carli Wischhoff DBA 2018-2019 4
