OMSE 551 Week 8: The Business Context

1
OMSE 551 Week 8 The Business Context

• FWSOS Architecture
• Domain Specific Modeling
• Organizational Issues
• Technology Transition

2
Domain-Specific Modeling

• Compiler Approach

3
Sequential Development Inefficiencies

• One issue temporal distance between desire and
  gratification
• Second issue Difference in abstractions
  (translation)
• How much of SE seeks to address this problem?

Requirements Analysis
Software Design
Coding
Needs
System Integration and Testing
Validation
Delivery
Customer
Product
4
Sequential Development Inefficiencies

• One issue temporal distance between desire and
  gratification
• Second issue Difference in abstractions
  (translation)
• How much of SE seeks to address this problem?
• What are the inefficiencies?

Problem Description (informal model Domain dep.)
Abstract Solution (semi-formal Domain indep.)
Concrete Soln. (formal, domain indep.)
Needs
System Integration and Testing
Validation
Delivery
Customer
Product
5
Composer Approach

• Positives
• Largely addresses problem
• Interaction with customer is primarily in domain
  terms (application modeling language)
• Many products can be generated
• Always feasible
• But..
• Mapping to solution domain typically not
  completely automated
• Some hand coding (10-20)
• Requires hand translation, maintenance
• Set of variations is bounded

6
Solution Approach

• Problem solution space (language) and problem
  space in different domains
• Requires translation that is error-prone, labor
  intensive, difficult
• Requires expertise in two domains
• Solution write solutions in language of the
  solution space
• Use domain specific abstractions
• Automate translation to target language
• Solving problem requires only domain expertise

7
AE with DSM

• Application Engineering writing in terms of the
  problem space (domain) requires
• A domain-specific modeling language (DSL)
• A tool for building models in the language
• A compiler/generator translating models to target
  code

8
Ex. 1 Smartphone Aps.

• Symbian Series 60
• Modeling language defines application layout,
  logic
• Complete code generation to phone

9
Phone App. Model
From Johu-Pekka Tolvanen, DSM for Full Code
Generation, 2005
10
Running on Phone (sim.)
From Johu-Pekka Tolvanen, DSM for Full Code
Generation, 2005
11
Business Process Modeling

• Supports definition of business processes for
  execution in workflow engine
• Modeling language for business processes
• Contractors, organizational units, messages,
  files
• Generator produces XPDL (XMP Process Def.
  Language)
• XPDL executed in workflow engine

12
AE Environment
From Johu-Pekka Tolvanen, DSM for Full Code
Generation, 2005
13
Generated XPDL
From Johu-Pekka Tolvanen, DSM for Full Code
Generation, 2005
14
Domain Engineering for DSLs

• Ideally done with tool building tools
• Application generator-generator
• Metamodeling IDE
• Supports defining DSLs
• Supports defining mappings to assets
• May be language compilation
• Also can be adaptable modules, assets, platforms,
  etc.
• Expert (Domain Engineer) defines modeling
  language environment

15
Metamodeling

• Modeling languages for building modeling
  languages
• Define domain concepts
• E.g. types with values, ranges, operations
• Relations
• Define modeling rules and constraints
• What is a legal model
• Create representation of concepts and rules
• Define translation to target language
• Mapping to code
• Mappings to templates, interfaces, etc.

16
P-L Engineering with DSM
From Johu-Pekka Tolvanen, DSM for Full Code
Generation, 2005
17
Comparison to Composer Approach

• Application Engineering
• Ideally done by domain expert (e.g. customer)
• Requires learning DSL modeling
• Ideally does not require specialized application
  engineer
• No hand-coding or maintenance
• Domain Engineering
• Requires metamodeling expertise
• Requires metamodeling tool
• Domain must fit the metamodeling language

18
Discussion Relations to SSE

• How does thinking about developemt have to
  change?
• What kinds of skills are needed?
• Which principles must be applied

19
Organizational Issues
20
Form Follows Function

• The structure of the organization tends to the
  structure of the product it produces
• Product-line development differs from tradition
  in
• Work products produced
• Focus on application family assets as primary
  product
• Someone must own managerial responsibility for
  this product
• Process
• Distinct domain engineering and application
  engineering activities
• Different skills, methods, success criteria
• Integration of functional areas of an
  organization
• Requires direct interactions and feedback between
  the software engineering side of the company and
  the business side
• Must understand business implications of
  technical decisions and visa versa
• Both organizational structure and relationships
  must change to address product line development

21
Form Follows Function
22
Other Views

• From van der Linden text
• Also gives process oriented and matrix
  organizations
• Different allocations of functions and relations

23
Expected Changes

• Successful organizational transition requires
  managing changes
• Organizational
• Requires interdisciplinary collaboration
• Must overcome organizational barriers
• Development
• Requires management, planning, ownership of
  assets (processes, plans, products)
• Must reorganize to reflect new product and
  process structures

24
Expected Changes (2)

• Customer
• Must understand tradeoffs of product line
  (benefits vs. costs from customer viewpoint)
• Successful when customers participate in defining
  strategic view, know what to expect
• Marketing and Sales
• Must interact with development to make strategic
  decisions
• Must interact with customers to guide buying
  decisions toward PL

25
Transitioning to Product Lines
26
Adoption Barriers

• Ignorance
• Inadequate understanding of the nature of the
  problem
• Inadequate understanding PL approach
• Lack of software engineering knowledge
• Chaotic development process
• Poor process control
• Adoption overhead (training, time, cost,
  disruption)
• Natural resistance to change

27
Adoption Risks

• Lack of training/education/understanding
• Lack of a champion
• Poor choice of product
• Insufficient management commitment
• Lack of staff commitment
• Poor transition planning
• Inadequate investment

28
Transition Strategies

• Incremental Adoption
• Expand organizational scope
• Expand Investment
• Biggest Problem First
• Attack problem areas in conventional development
  due to needing strategic approach (e.g.,
  architecture, CM)
• Target highest ROI issues first
• Pilot Project
• Small scale project
• Think ahead how to scale up
• Big Bang
• E.g., Celsius Tech

29
Nominal Transition Process

• Requires a plan
• Need to understand stakeholders problems and
  goals
• Apply process-as-product view
• Idealized process
• Identify stakeholders
• Identify goals (requirements for PL process)
• Create business case
• Create adoption plan
• Launch and institutionalize
• Monitor results

30
Business Case

• Transition founded on building business case for
  product lines
• Expected costs includes re-organization,
  training in addition to asset development
• Anticipated risks necessary managerial and
  technical leadership, expected resistance
• Likely returns reduced cost, time, personnel,
  increased sales?
• Business case becomes core asset
• Reusable
• Can it be a family?

31
Principle-Based Adoption
32
Role in Process Adoption

• Implications PL adoption
• Process change requires substantial resources
• Cannot afford large up-front investment or long
  delay in return on investment in process change
• A practical approach must address both risks of
  adopting and risks of applying product line
  technology
• Provide incremental benefit at each adoption step
• Provide near term recovery of investment defined
  as within the time frame of current product
  development
• Address barriers incrementally
• View as a process adoption spiral

33
SSE Process Family

• Commonalities
• All processes use a common set of software
  engineering principles (e.g., Information hiding
  and abstraction)
• All processes take a strategic view of
  development (address issues outside scope of a
  single development)
• Variabilities
• Family members vary in the degree to which each
  process focuses on and invests in work products
  that address strategic goals (I.e., are
  unnecessary to the product at hand)
• Such a family can be organized such that
  processes in the family
• Are on a migration path to a mature PL process
• Meet our goals for incremental benefit and near
  term ROI

34
A Family of SSE Processes
35
Questions?

• No class next week
• Work on projects
• Any constraints on presentations?