100% de satisfacción garantizada Inmediatamente disponible después del pago Tanto en línea como en PDF No estas atado a nada
logo-home
Buscado previamente por ti
Buscado previamente por ti
logo
Complete Summary of all DBA Lectures, Notes and Learning Objectives 5,49 €
Añadir al carrito
Navegar rápidamente a
Vista previa
  2.  
  3. Erasmus Universiteit Rotterdam (EUR)
  4.  
  5. Designing Business Applications

Resumen

Complete Summary of all DBA Lectures, Notes and Learning Objectives

1 revisar
 1 veces vendidas
  • Grado
  • Designing Business Applications
  • Institución
  • Erasmus Universiteit Rotterdam (EUR)

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...

[Mostrar más]

Vista previa 4 fuera de 95  páginas

Información del documento

  • 15 de enero de 2019
  • 95
  • 2018/2019
  • Resumen

Temas

  • applications
  • dba
  • software
  • software engineering
  • engineering
  • srs
  • management
  • business
  • information management
  • bim
  • business information
  • information
  • technology
  • rsm
  • master
  • designing business applications
  • eur

Escuela, estudio y materia

  • Erasmus Universiteit Rotterdam (EUR)
  • MSc Business Information Management
  • Designing Business Applications
Todos documentos para esta materia (5)

1  revisar

review-writer-avatar

Por: jeanneau • 5 año hace

Very useful!

Vendedor

avatar-seller
CWischhoff

Comentarios recibidos

Vista previa del contenido

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

Los beneficios de comprar resúmenes en Stuvia estan en línea:

Garantiza la calidad de los comentarios

Garantiza la calidad de los comentarios

Compradores de Stuvia evaluaron más de 700.000 resúmenes. Así estas seguro que compras los mejores documentos!

Compra fácil y rápido

Compra fácil y rápido

Puedes pagar rápidamente y en una vez con iDeal, tarjeta de crédito o con tu crédito de Stuvia. Sin tener que hacerte miembro.

Enfócate en lo más importante

Enfócate en lo más importante

Tus compañeros escriben los resúmenes. Por eso tienes la seguridad que tienes un resumen actual y confiable. Así llegas a la conclusión rapidamente!

Preguntas frecuentes

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.

100% de satisfacción garantizada: ¿Cómo funciona?

Nuestra garantía de satisfacción le asegura que siempre encontrará un documento de estudio a tu medida. Tu rellenas un formulario y nuestro equipo de atención al cliente se encarga del resto.

Who am I buying this summary 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 this summary for 5,49 €. You're not tied to anything after your purchase.

Can Stuvia be trusted?

4.6 stars on Google & Trustpilot (+1000 reviews)

45,681 summaries were sold in the last 30 days

Founded in 2010, the go-to place to buy summaries for 15 years now

Empieza a vender
5,49 €  1x  vendido
  • (1)
Añadir al carrito
Añadido