Your SlideShare is downloading. ×
Intro to Business Modeling
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Intro to Business Modeling

309
views

Published on


0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
309
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
6
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Business Modeling - Domain Analysis Most materials taken from the RUP textbook Chapter 8 and OOSE, pp. 101-106
  • 2. Purpose of Business Modeling
    • To understand the structure and dynamics of the organization in which a system is to be deployed
    • To understand current problems in the target organization and identify areas for potential improvement
    • To ensure customers, end users, and developers have a common understanding of the target organization
    • To derive the system requirements to support the target organization.
    •  Note: all about the organization and not the application (directly).
  • 3. Business Modeling (Domain Analysis)
    •  We look at WHY we look at business modeling before application development.
    • We will create a model of the ‘vision’ of the target organization –with its
      • Processes
      • Roles
      • Responsibilities
    • Three primary components: (Much more ahead)
      • Business Use Case Model, and
      • Business Object Model
      • Domain Model ( some: ‘exploratory domain model’)
      • We will discuss each in turn several slides ahead…
  • 4. Why Undertake Business Modeling (Why do we care? – Slide 1)
    • The new standard for software development is to try to understand the business domain before or in parallel with development of an application.
      • Applications must ‘fit’ within the organization!
    • Business modeling is now a recognized, central part of development, and, in particular, facilitates the development of Requirements.
    • Business modeling now involves higher level people; those who can make decisions involving change ( not just those who ‘know’ the business well - SMEs).
    • According to the RUP, it is the first discipline that should be addressed and is key to acquiring key artifacts that will underpin much future work.
    • It is also a fundamental discipline in Inception phase.
  • 5. Why Undertake Business Modeling (Why do we care?)
    • Very important to learn background knowledge so developers can communicate with users and make more intelligent decisions.
      • Essential for understanding customer’s problems and setting the scope for a development project that might follow.
    • Business Modeling (Domain Analysis) is a process by which a software engineer learns background information sufficient to be able to understand a problem at hand and to make good decisions during requirements analysis and other stages of the software engineering process.
    • The ‘Domain’ – a general field of business or technology.
  • 6. Why Undertake Business Modeling (Why do we care?)
    • To perform business modeling (domain analysis), we need to gather information from a number of sources of information.
    • Seek experts in domain knowledge
    • Sources of Domain (Class) Knowledge:
      • high-level problem statements;
      • requirements;
      • expert knowledge of the problem space;
      • anything that describes the problem space and the desires and needs of the stakeholders.
        • Quarterly reports
        • Interviews
        • Questionnaires
  • 7. Business Modeling - more
    • We need to often create a domain analysis document that contains the domain
      • Name
      • Glossary – terms used in the domain that are not a part of everyday language
      • General knowledge about the domain
      • Who are the customers, users, stakeholders…
      • Environment – system, equipment used
      • Tasks currently performed
      • Competing software….
    • Don’t develop too much information.
    • Brief summaries of what you have found plus references
  • 8. Business Modeling - more
    • “ No serious software project should be undertaken without a sound domain analysis; a good knowledge of the domain of application considerably increases your chances of success.” p. 103, OOSE textbook.
    • Understand the domain? Easier to press on with requirements analysis to solve the problem – vision of a new/enhanced application.
    • Recognize that domain analysis never ends, as developers continue to supplement their domain knowledge as time continues.
  • 9. Categories of Business Tools: e-business:
    • E-business reflects the nature of the business – represents what the business is all about.
    • Customer to business (C2B) – applications that allow you to order goods over the Internet, such as books
    • Business to business (B2B) automation of a supply chain across two companies
    • Business to customer (B2C): provision of information to (otherwise passive) customers, such as by distributing newsletters.
    • Customer to customer (C2C): applications that allow customers to share and exchange information with little input from the service provider, such as for auctions.
  • 10. Terms
    • Business user – customers, vendors, partners – represented by business actors
    • Business processes – represented by business use cases; business use case realizations
    • Roles people play – represented by business workers
    • ‘Things’ organizations manage/produce represented by business entities / events organized into business systems.
  • 11. Business Modeling Scenarios
    • Scenario 1 – Organization Chart
      • Build a simple org chart of business and its processes to get a good understanding of the application you are building.
      • Where does the application fit? To which organizations might it impact? …
        • Emphasis is on ‘the organization.’
      • Part of the software engineering process and part of the inception phase
  • 12. Business Modeling Scenarios
    • Scenario 2 – Domain Modeling
      • Build a model of that information (banking, order management) that will be present at the business level.
      • Domain Modeling is typically part of the software engineering project and is performed during inception and elaboration phases – but is definitely started in inception and refined in elaboration.
      • We will develop a domain model – among other things in the next slide lecture plus assigned readings.
      • Recognize that the Domain Model is part of Domain Analysis (that is, Business Modeling)
  • 13. Business Modeling Scenarios
    • Scenario 3 – One Business; Many systems.
      •  One business-modeling effort that is input to several other development projects.
      • The business models will as serve as inputs to building the architecture of the application family .
      • Individual applications may then use this model for individual projects, and will use this system as a baseline or domain, which may be then tailored or used in a dependency role.
      • This business modeling effort is a project by itself!
  • 14. Business Modeling Scenarios
    • Scenario 4 – Generic Business Model (for different organizations)
      • Important if you are building a single , general model to be used to align several organizations in the business
        • used to reduce overall complexity - or at least understand how the different organizations might use the application.
    • Scenario 5 – New Business
      • Necessary business modeling for a new line of businesses
    • Scenario 6 – Revamp: Business Process Reengineering (BPR)
      • A complete redo of the way of doing business. Done in several discrete stages – envision new business, reverse engineer existing business, forward-engineer new business, and install new business…
      • A revolutionary approach to reorganization….
  • 15. Primary Artifacts
    • Business Vision Document
      • Defines objectives and goals of the business modeling effort
    • Business Use Case Model
      • A model of the business’s intended functions.
      • Used as an essential input to identify roles and deliverables in the organization. (Use Rational Rose)
      • Will be very useful in your development use case modeling
    • Business Object Model (Business Analysis Model)
      • A model that realizes the business use cases . (Use Rational Rose) A lot of work…
  • 16. Primary Artifacts (2)
    • Business Rules – policies/conditions that must be satisfied; heuristics during operations;
    • Business Glossary – definitions of important terms that are important to the business (acronyms, as ELOC, … commonly used terms.)
    • Others – selected…(several omitted are important, but we are concentrating on these  )
  • 17. Business Models
    •  1. Business Use Case Model:
      • Contains business actors (roles external to the business such as customers) and business use cases (business processes)
    •  2. Business Object Model
      • Includes the business use case realizations
        • Includes interacting roles and entities involved.
    •  3. Domain Model - ahead
    • These are at higher levels of abstraction than the system use cases will be.
      • e.g. A class at business level represents a responsibility in an organization .
  • 18. 1. Business Use Case Model
    • Simple in structure . See pp 151-152 in the RUP.
      • Shows relationship between business use cases – in general and business users (business actors).
      • Business Use Case Model is very similar to (System) Use Case Model but with different icons (semantics)
      • Each use case is identified and actors who interact with this and each business use case.
  • 19. 2. Business Object Model
    • Much more detailed (pg 151-152)
      • Each business use case is realized with business actors and business entities.
      • Note icons used. (All documented in Visual Modeling with RR 2002 and UML )
      • You will not need the dashed lines, as these figures (pp. 151 and 152) are showing the relationship between the business modeling and the system models. (underlining implies objects)
      • Notice the syntactical difference between the icons in the System Use Case Model (bottom of pp 151-152) and the Business Use Case Models (middle of pp. 151-152).
  • 20. More details on Business Object Model
    • Business Models and Entity Classes
      • A business entity that is to be managed by an information system will correspond to an entity in the domain model.
      • More ahead on domain modeling
      • Example entities might include:
        • Menu;
        • Work Schedule;
        • Food Order; …
  • 21. The Domain Model
    • Part of Domain Analysis is developing models – Visual Models!
    • We develop a
      • Business Use Case Model
      • Business Object Model, and a
      • Domain Model.
    • All three of these will greatly assist in effective requirements analysis (gathering, capturing, and modeling user requirements).
    • Let’s look at the Domain Model.

×