100% satisfaction guarantee Immediately available after payment Both online and in PDF No strings attached
logo-home
Complete Summary of all DBA Lectures, Notes and Learning Objectives $5.89
Add to cart

Summary

Complete Summary of all DBA Lectures, Notes and Learning Objectives

1 review
 169 views  1 purchase
  • Course
  • Institution

A comprehensive summary of the lectures and lecture notes that were covered in the course Designing Business Applications (DBA) at RSM. The summary includes screenshots/pictures of all key concepts (i.e. learning objectives) of the DBA course. Topics discussed in the lectures include Software Engin...

[Show more]

Preview 4 out of 95  pages

  • January 15, 2019
  • 95
  • 2018/2019
  • Summary

1  review

review-writer-avatar

By: jeanneau • 5 year ago

Very useful!

avatar-seller
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

The benefits of buying summaries with Stuvia:

Guaranteed quality through customer reviews

Guaranteed quality through customer reviews

Stuvia customers have reviewed more than 700,000 summaries. This how you know that you are buying the best documents.

Quick and easy check-out

Quick and easy check-out

You can quickly pay through credit card or Stuvia-credit for the summaries. There is no membership needed.

Focus on what matters

Focus on what matters

Your fellow students write the study notes themselves, which is why the documents are always reliable and up-to-date. This ensures you quickly get to the core!

Frequently asked questions

What do I get when I buy this document?

You get a PDF, available immediately after your purchase. The purchased document is accessible anytime, anywhere and indefinitely through your profile.

Satisfaction guarantee: how does it work?

Our satisfaction guarantee ensures that you always find a study document that suits you well. You fill out a form, and our customer service team takes care of the rest.

Who am I buying these notes from?

Stuvia is a marketplace, so you are not buying this document from us, but from seller CWischhoff. Stuvia facilitates payment to the seller.

Will I be stuck with a subscription?

No, you only buy these notes for $5.89. You're not tied to anything after your purchase.

Can Stuvia be trusted?

4.6 stars on Google & Trustpilot (+1000 reviews)

52510 documents were sold in the last 30 days

Founded in 2010, the go-to place to buy study notes for 14 years now

Start selling
$5.89  1x  sold
  • (1)
Add to cart
Added