UML Process Diagrams: Learn Enterprise UML Technical Systems

Build scope definition and solutions - Elicit, Capture, and Collect Requirements, Rules, Deliverables, Resources
1.0 (1 rating) Instead of using a simple lifetime average, Udemy calculates a
course's star rating by considering a number of different factors
such as the number of ratings, the age of ratings, and the
likelihood of fraudulent ratings.
17 students enrolled
$19
$75
75% off
Take This Course
  • Lectures 32
  • Length 2.5 hours
  • Skill Level Intermediate Level
  • Languages English
  • Includes Lifetime access
    30 day money back guarantee!
    Available on iOS and Android
    Certificate of Completion
Wishlisted Wishlist

How taking a course works

Discover

Find online courses made by experts from around the world.

Learn

Take your courses with you and learn anywhere, anytime.

Master

Learn and practice real-world skills and achieve your goals.

About This Course

Published 8/2016 English

Course Description

This course provides you with the skills and knowledge to effectively and efficiently discover, develop and deliver valuable models of solutions for business and IT.

The "UML Process Diagrams: Learn Enterprise UML Technical Systems" course was authored by Chuck Morrison, MBA, PMP with extensive Program Management and Business Architecture experience in Silicon Valley California.

This course is a series of courses and lectures Introducing key concepts and demonstrations to show you how and help you learn to design, develop, and deliver solutions for your own work projects.

Related topics learned in this course series are:

  • What is a Business or IT requirement?
  • What best practice tools are available for Modeling
  • What is Enterprise UML Technical Systems Modeling
  • Modeling Business Process Workflows demonstration
  • UML Modeling Relationships demonstration
  • Use Case Context Modeling demonstration
  • Other related courses are in-process for future availability.

Additional authored and published for Udemy professional training courses and related Amazon Kindle books include:

  • UML Use Cases: Transforming Requirements into Context Maps, 
  • Logical Troubleshooting & RCA: Learn What You Need to Know, 
  • Agile SCRUM: Learn Agile Development for Project Managers, 
  • Project Management Office: Learn How the PMO Functions, 
  • Safety and Security: Learn CISSP Domains for Project Managers
  • Workflow & WBS: Develop Requirements-based Deliverables …

This course is based on insights pioneer winners of the Turing Award to help you support effective solutions and decisions regardless of your role.

Critical processes emphasized during this course are collaboration, listening, analysis, and modeling techniques needed for effective and efficient system operations solutions. This course helps you develop the skills and knowledge needed to support effective solutions and decisions regardless of your role.

All affected stakeholders including sponsors, subject matter experts, and other resources must be involved in collaborative development of the functionality and constraints of workflow model needed to support business automation and related make-buy decisions. This requires the leadership, skills, and knowledge or experiences analyst and architects capable of supporting an effective business requirements model.

As stated previously, "UML Process Diagrams: Learn Enterprise UML Technical Systems" provides you with the needed skills and knowledge to effectively and efficiently design and develop requirements-based business workflows and deliverables needed to support your programs and projects for business and IT organizations. During each lecture you’ll be presented with information and material found useful to others while developing workflows and deliverables for their own organizations. Remember, however, lectures and demonstrations can only help you so far. It’s up to you to learn then take advantage of the methods and tools presented.

If during this course, or after you’ve completed this course, you have any questions related to any part of a section, lecture, quiz, exercise, or in general please don’t hesitate to ask using Udemy’s Instructor Messaging to contact me. You have my promise to work with you to find an answer, which may include course enhancements and/or adjustments. I look forward to hearing your comments and suggestions.

Again! Please! You be the judge! If during this course or after you’ve completed this course, you have any questions related to any part of a section, lecture, quiz, exercise, or in general please don’t hesitate to ask using Udemy’s Instructor Messaging to contact me. You have my promise to work with you to find an answer, which may include course enhancement and/or adjustments. I look forward to hearing your comments and suggestions.

I’m looking forward to sharing with you the skills and knowledge to effectively and efficiently develop and deliver requirements-based business workflows and deliverables solutions needed to support your programs and projects to make you and your organization more successful. And, I now encourage you to take full advantage of the learning opportunities this course offers.

And, please if you find my course useful, please consider leaving a review and rating. Your review is much appreciated. You can go directly to the review page for this course then click and enter your review and rating.

Please remember my promise to you, if your have any questions about any part of this training or any related questions about this course or Udemy please don’t hesitate to ask using Udemy’s Instructor Messaging service to contact me.

Are you ready to get started!

Thank You and Best Regards,

Chuck Morrison, MBA, PMP

© 2015 Chuck Morrison, All Rights Reserved

What are the requirements?

  • Some technical experience desired.
  • Ability to collaborate and listen for business wants and needs
  • Capability to capture and define business and technical requirements
  • Ability to collect and organize tasks, activities and resources into diagrams, flow charts, and graphical models
  • Interest in data capture, organization, documentation, experimentation, and testing
  • Interest and aptitude in the fields of business analysis and information architecture
  • Ability to collect and organize tasks, activities and resources into diagrams and graphical models

What am I going to get from this course?

  • Decompose stories into requirement statements to identify Use Cases representing Functional and Non-Functional Requirements supported in a Work Breakdown Structure
  • Give those responsible for designing, building, and/or buying the solution the kind of information they need to make the decisions right for the business.
  • Identify system behaviors actors, pre-conditions, post-conditions, relationships and constrains from base on well-defined use cases and user stories use to define functional and non-functional requirements.
  • Document and manage Business system, Stakeholder, Functional, Non-Functional, and data requirements.
  • Capture and clarify Business Rules and External Constraints that mandate limits to the delivered solution.
  • Develop measurable Solution Requirements that facilitate End-User Acceptance Testing and delivery.

What is the target audience?

  • Subject Matter Experts (SMEs)
  • Product Owners and Sponsors
  • Business Process Managers
  • Business Process Users
  • Product, Project, Portfolio, and Program Managers
  • Quality Assurance
  • Business Analysts & Architects
  • System & Software Developers

What you get with this course?

Not for you? No problem.
30 day money back guarantee.

Forever yours.
Lifetime access.

Learn on the go.
Desktop, iOS and Android.

Get rewarded.
Certificate of completion.

Curriculum

Section 1: Introduction to Enterprise UML Technical Systems Modeling …
04:51

Section 1 - Introduction to Enterprise UML Technical Systems Modeling

Goals – 

  • Decompose stories into requirement statements to identify Use Cases representing Functional and Non-Functional Requirements supported in a Work Breakdown Structure.
  • Give those responsible for designing, building, and/or buying the solution the kind of information they need to make the decisions right for the business.
  • Identify system behaviors actors, pre-conditions, post-conditions, relationships and constrains from base on well-defined use cases and user stories use to define functional and non-functional requirements.
  • Document and manage Business system, Stakeholder, Functional, Non-Functional, and Data requirements.
  • Capture and clarify Business Rules and External Constraints that mandate limits to delivered solutions.
  • Develop measurable Solution Requirements that facilitate End-User Acceptance Testing and Delivery.

Lecture 1 – Course Introduction – UML Process Diagrams: Learn Enterprise UML Technical Systems

What comes to mind when you think of automating a business process? Does it seem overly complicated or even overwhelming? Do you wonder if there’s a better way to solve your riddle? 

I’m sure most of you, at some point, have been assigned work for which you knew there just had to be a better, more simple way to get it done. There are many tools to help you if you only knew the approach needed to help you with your tasks.  Many of these tools are inexpensive and have been around for many years if only you knew what they are and how to use them. 

For many years now, I’ve used these tools and concepts to develop solutions not just for myself, but for small to major businesses as well as government projects.

This course is a series of lectures introducing key concepts and demonstrations showing you how and helping you learn to design, develop, and deliver solutions for your own work projects. 

Related topics you will learn from this course series are:

  • What is a Requirement, why Requirements are used, and how to create and manage Requirements
  • What is Enterprise UML Technical Systems Modeling:
  • Requirements Class Model – Requirements analysis encompasses tasks determining needs and conditions for new or altered products or projects with possible conflicting requirements from stakeholders including analyzing, documenting, validating and managing stakeholder system requirements, expectations, and delivery. Requirements analysis is critical to the success or failure of business system applications projects. Requirements Class Models must be defined and documented as actionable, measurable, testable, and traceable to business needs and opportunities to sufficient detail level needed for successful system design, execution, and delivery. 

Requirements Class Models include …

  • Architecture Framework Model
  • Requirements Inventory
  • Requirements Knowledge Mode
  • Work Scope Inventory

What best practice tools are available to support Enterprise UML Modeling – 

  • MindManager
  • Visio (Windows)
  • Runway (Apple)
  • MS Project

Demonstrations and exercises for this course include – 

  • Modeling Business Process Workflows
  • UML Modeling Relationships
  • Use Case Context Modeling. 

Lectures, demonstrations and self-exercises in this course show you how to create your own products and projects. Successful completion of this training course based on UML modeling techniques enables you to construct your own business projects and Udemy courses.

So, if these course topics presented are what you want to learn and use, I’m excited to help you get started on your journey. 

Let’s get started!

© 2015 Chuck Morrison, All Rights Reserved

04:33

Lecture 2 – Enterprise UML Technical Systems Modeling

Welcome   

… to our exciting Udemy training course   

Hello, I’m Chuck Morrison, an MBA and PMP certified Senior Program/Projects Manager and Business Architecture Professional. 

My specialties are: Business Process Engineering, Software Systems Development, Cross-Functional Program and Change Management, as well as Online Course Author, Publisher, and Trainer.

My significant skills and accomplishments include:

  • Over 20 years of expansive and diverse experience as a Program, Project and Portfolio Manager, Consultant and Business Architect/Analyst working for companies such as VMware, Caltrain, PG&E, HP Enterprise Services, Hawaiian Airlines and DIRECTV. 
  • Proven success leading multiple, complex projects, process improvements and system migrations throughout the entire project lifecycle generating cost savings of over $50M for DirecTV.
  • Managed over 27 concurrent, high-visibility CPUC Rule 20 projects according to scheduled timeline across multi-locations and sites with a total budget of $40M for Pacific Gas and Electric Company (PG&E).
  • Extensive business applications technology background with recognized business acumen used to define and deliver small to large-scale, complex business process and systems infrastructure projects.

Courses & Books: Authored and Published Udemy professional online training courses and Amazon Kindle books: 

This is my seventh course and book combination. This course series about “Enterprise UML Technical Systems Modeling” introduces you to a series courses enabling you to learn key concepts with demonstrations empowering you to design, develop, and deliver solutions for your own and your organization’s business and IT projects. Currently, I’m in the process of authoring Udemy courses and Kindle books on topics concerning ITIL, Cloud Computing, and Business Architecture intended for release and availability later this year.

As stated previously, "UML Process Diagrams: Learn Enterprise UML Technical Systems" provides you with needed skills and knowledge to effectively and efficiently design and develop requirements-based business workflows and deliverables. During each lecture you are presented information and material found useful to others while developing workflows and deliverables for their own organizations. Remember, however, lectures and demonstrations can only help you so far. It’s up to you to learn then take advantage of methods and tools presented in related course lectures and demonstrations.

Again! Please! You be the judge! If during this course or after you’ve completed this course, you have any questions related to any part of a section, lecture, quiz, exercise, or in general please don’t hesitate to ask using Udemy’s Instructor Messaging to contact me. You have my promise to work with you to find an answer, which may include course enhancement and/or adjustments. I look forward to hearing your comments and suggestions.

I’m looking forward to sharing skills and knowledge you need to effectively and efficiently develop and deliver requirements-based business workflows and deliverables solutions. So, I now encourage you to take full advantage of all learning opportunities this course offers.

And, please if you find my course useful, I invite you to consider leaving a review and rating. Your review is much appreciated. You can go directly to the review page for this course then click and enter your review and rating.

Criteria for Writing a Review and Rating

Please remember my promise to you, if you have any questions about any part of this training or any related questions about this course, Udemy please don’t hesitate to ask using Udemy’s Instructor Messaging service to contact me.

Are you ready to get started?

Thank You and Best Regards, Chuck Morrison, MBA, PMP

© 2003-2016 Chuck Morrison, Hollister, CA, All Rights Reserved

 

02:52

Lecture 3 – Student Introductions - Course Discussion - Course Signup

Discussion – 

Welcome our next lecture and thank you for joining our course. Please take a moment to introduce yourself to me and the other students in our class using our Udemy Course profile page Q&A tab then click the green “Ask a new question” button to post your introduction.

Just include a little information about yourself including your name and location. You don't have to be specific about location if you prefer … just include your state or city or country. 

Also, please let us know where you’re coming from. Are you working full-time? Is this your first time taking or creating an online course? Are you working full or part? Is this your first time creating your own online business or making money online. 

Do you have a website? If so, please include your website address so we can find out a little more information about you and start following you on your own channel. If you’re on Facebook, Twitter, LinkedIn, or other social media, please let us know your contact information if you want to share.

Contact Me: Please contact me with any questions or suggestions you may have about our course using my Udemy Profile page https://www.udemy.com/user/chuckmorrison/.

Comments & Suggestions: If during this or any other of my courses, or after you’ve completed any of my courses, you have any questions or related suggestions for improvement; please don’t hesitate to contact me using Udemy’s  Course Q&A tab then click the green “Ask a new question” button to post your questions, comments, or suggestions.

Remember, you have my promise to work with you to find an answer for your questions and suggestions which may include course enhancements and/or adjustments or reviews and ratings. I look forward to hearing your comments, reviews and suggestions which are used for course improvements or as initiative to create a new course or amendment lecture.

Review & Rating: And, please after completing any of my courses or if you find this course or any of my courses useful, please consider leaving a review and rating. Your review is much appreciated. You can go directly to Udemy’s Course Q&A tab for any course then click the green “Ask a new question” button to post your questions, comments, suggestions, reviews and ratings.

I'm excited to meet you. So, just as I did in my “Welcome” video giving you information about myself, I really am excited to hear about you, and get to know you better. Please take just a moment to introduce yourself to the course; I will highly appreciate it. See you in the next course video lecture.

Thank You and Best Regards, Chuck

Quiz 1 – What are Use Cases?
2 questions
Section 2: 02 - UML Requirements Support Tools – Modeling ... What Is It?
09:18

Section 2: UML Requirements Support Tools – Modeling ... What Is It? 

Discussion - 

What are to Goals for our course and how do you achieve them?

Goals …

  • Provide functional requirements capturing tool. To answer this question, we’ll first discuss “What’s a Requirement”? …
  • Decompose stories into requirement statements to identify Use Cases representing Functional and Non-Functional Requirements supported in a Work Breakdown Structure.
  • Give those responsible for designing, building, and/or buying solutions the kind of information they need to make the right decisions for the business.
  • Identify system behaviors, actors, pre-conditions, post-conditions, relationships and constraints based on well-defined use cases and user stories used to define functional and non-functional requirements.
  • Document and manage Business system, Stakeholder, Functional, Non-Functional, and data requirements.
  • Capture and clarify Business Rules and External Constraints that mandate limits to delivered solutions.
  • Develop measurable Solution Requirements facilitating End-User Acceptance Testing and delivery.

To achieve our course goals, this course is delivered using sections, lectures, quizzes, out-of-class exercises, and downloads. Also included with your course is a “glossary” and “For further reading …” references. As each section is presented, each section’s goals are related key concepts are introduced, discussed and demonstrated as appropriate.

Students are encouraged to use skills and knowledge discussed and demonstrated as out-of-class exercises in their own work as much as possible thus enhancing learning success. During course lectures or out-of-class exercises, students are further encouraged to ask questions or make comments and suggestions using Udemy’s Instructor Messaging service to contact me so I can do related research then get back to the student promptly with results.

UML Requirements Support Tools

Lecture 4 UML Requirements Support Tools

Discussion –  

As we begin our journey into Business and IT UML modeling and Support Tools, we must first understand “what are requirements?” And, why we need UML tools to capture and support them. First, UML helps us to visualize our Business and IT problems both comprehensibly and understandably. This helps to avoid and minimize application, process, and system solutions not required to meet business needs and expectations.

Further, business and IT process modeling is used to visually capture and document business system workflows by first modeling system context. This provides visual models supporting and displaying goals the business wants, needs and must achieve, as a first step in requirements capture and definition process. 

UML Models are typically used by business analysts and architects because its rich language is useful for modeling application structures and behaviors needed to support business process requirements and solutions. 

Although UML 2.0 provides 14 UML diagram types, only the most useful for business modeling are discussed during this course. The balance are found in references provided in concluding course lectures and documents. As students, you are encouraged to explore our course glossary and references as desired and needed.

The following discussions explain use of UML tools for modeling business product functions in preparing business and IT product use cases and related models used to capture business and IT management requirements.

Management is all about balance, communication, collaboration, adjustment, and consensus as requirements are discovered, captured, executed, tested, and delivered. To prevent one class of requirements from over-riding another, constant communication and collaboration among members of the project, development, test, and delivery teams is crucial. For example, in software development for internal applications, the business has such strong user requirements needs that may be ignored, or believe while creating use cases, the user requirements are being taken care of when these are not expressed, captured , defined, and documented. This can lead to missed requirements, expectations or project failure.

The purpose of Requirements management is to ensure project requirements meet business needs and expectations as inconsistencies are identified among those requirements supported by project plans ensuring work products delivery. Further, requirements management practices must include change management and traceability. 

What is a Requirement? A requirement is a measurable action or set of actions a system must do (behaviors and functions). It may also be a measurable quality or property a system must have (attributes and persistence). Requirements must capture what is needed to satisfy client business processing needs and expectations in delivered systems. Requirements are categorized as three types: Functional, Non-functional (Performance), and Constraints. Issues are used to define risks involved in meeting requirements. Work Inventory is a collection of all completed and non-completed work and issues.

Requirement Types

  • Functional
  • Non-Functional
  • Constraints
  • Issues
  • Work Inventory

Functional – A functional requirement is a service (behavior, task, function) or set of services providing value to a system’s users and other stakeholders.  

Functional requirements: 

  • Define actions a system must do to provide value for clients 
  • Are event-driven (Business Events, Business Rules) 
  • Are role-based system behaviors (Use Cases, Actors (roles)) 
  • Define the essence of a delivered system i.e., the system’s reason for existence. 
  • Functional requirements set the scope and context (bounds-of-automation) for a given system, process, application or component. 

Example: The system must be capable of generating a return material authorization (RMA) and replacement gateway release for shipment to the customer using a single transaction. 

Non-Functional – Non-functional requirements are characteristics (features) or qualities a system must have and are often critical to system success.  

Non-functional requirements are often “attached” to system functional requirements and are often called “ilities”: 

  • Usability,  
  • Robustness, 
  • Maintainability,  
  • Portability,  
  • Scalability,  
  • Configurability,  
  • Extensibility,  
  • Security,  
  • Capacity,  
  • Measurability,  
  • Consistency,  
  • Resilience.  

Collectively, non-functional requirements provide features needed to support system infrastructure. 

Example: The system must provide defect-free (less than 1% defective serial-number captures), gateway serial-number recording for RMA replacement gateway shipment. 

Constraints – Constraints are global requirements.  

Constraints are externally imposed limitations on system requirements: 

  • Maintenance of access and connectivity with a legacy system 
  • Use of a specific platform such as MS NT, UNIX, OS X, VMS 
  • Use of a specific language such as JAVA, C++, MS Visual Basic, Fortran, Python 
  • Use of a specific persistence mechanism such as MS SQL Server, Oracle, Informix, DB2 
  • Use of a specific transport protocol/format such as HTTP(S)/XML(DTD), CORBA, Vitria, STC SeeBeyond 
  • Use of a specific framework such as Seibel CRM or SAP ERP.  
  • Constraints both aid and limit technical decision-making and problem-solving capabilities. 

Example: Address Information must be scrubbed using Code 1 before each RMA replacement gateway submission to 3rd party database. 

Issues – Issues are potential constraints on the success of a project. 

Issues may include Associated:  

  • Benefits,  
  • Risks,  
  • Costs,  
  • Delays,  
  • Resources.  

Issues define constraints related to user documentation, testing, training, deployment, and related system releases. 

Example: Code 1 must be available prior to RMA replacement gateway shipment transaction verification. 

So far, we’ve narratively covered what a requirement is. To further understand what requirements are and why we use visual models to capture, clarify, define and document requirements, we’ll quickly walk through a few related visual model context map views as follows: 

Requirement Support Modeling Tools Stories – 

  • Requirements Problem Definition Class View 
  • Architecture Framework View 
  • Requirements Inventory View 
  • Business and Technical Requirements Knowledge View 
  • Work Scope Inventory View. 

As a student, you are encouraged to explore the Internet using various search engines such a Google and/or Wikipedia to discover more related Business and Technical Requirements modeling views. 

©2003-2012 Chuck Morrison, Hollister, CA, All rights reserved

03:20

Lecture 4b – What is Model Driven Architecture?

Discussion –

Enterprise Architecture

Enterprise architecture (EA) defines structure and operation of an organization as a conceptual blueprint for achievement of vision. Enterprise architecture determines how an organization will effectively achieve current and future objectives. Enterprise architecture (EA) enables enterprise analysis, design, planning, and implementation for successful development and execution of strategy. Enterprise architecture brings architecture principles and practices to guide organizational business, information, process, and technology changes necessary to execute mission, strategies and objectives.

Enterprise Architecture consists of (refer to drawing) –

  • Itérative – Inception, Elaboration, Construction, Transition ...
  • Business Modeling Increments
  • Environment & Project Management
  • Requirements Analysis
  • System Analysis & Design
  • Software Analysis & Design
  • Development
  • Test Management
  • Training/Support – Configuration & Change Management

 

Model-Driven/Model-Based Architecture

Model-driven architecture (MDA) is a software design approach for development of business and IT software systems. MDA provides guidelines for structuring specifications expressed as documented visual models and narrative demonstration of systems projects and programs. The MDA model consists to multiple standards, including Unified Modeling Language (UML), Meta-Object Facility (MOF), XML Metadata Interchange (XMI), Enterprise Distributed Object Computing (EDOC), Software Process Engineering Metamodel (SPEM), and Common Warehouse Metamodel (CWM). Model-driven architecture does not architect a system being modeled, but architecture of various standards and models serving as a technology basis for MDA.

In information technology (IT), architecture is a term applied to both process and outcome of analyzing, designing, and specifying overall structure, logical components, and logical interrelationships of computers, operating systems, networks, or related objects and infrastructure. Architecture is a reference model or framework, such as Open Systems Interconnection (OSI) reference model, intended to model specific product architectures or specific product architecture from microprocessors to operating systems and networks.

Computer architecture is divided into five fundamental components:

  • Input,
  • Output,
  • Storage,
  • Communication,
  • Control, and
  • Processing.

Each component (sometimes called subsystem) has an architecture when modeled in context.

As you can see from the drawing, MDA covers a lot of territory and complete coverage is beyond the scope and context of our current course. However, over the next several months, it is my intention to build a follow-on course to cover the topics listed in the architecture drawings you see here. Meanwhile, as interested students, you are encouraged to research each of the concepts listed as a guideline for your further learning using online search and discovery tools such as Google and Wikipedia.

(OMG) Model-Driven Architecture

  • Pervasive Services
  • Security
  • Events
  • Transactions
  • Space
  • Manufacturing

Web Services

  • CORBA
  • XMI/XML
  • NET
  • JAVA

Architecture Framework

  • RUP/UML
  • ITIL/MOF
  • CWM

Model-Based Architecture

•Enterprise Architecture –Model-Based Architecture (MBA), Enterprise Architecture Framework)

  • Principals (Best Practices)
  • Patterns
  • Glossary – Metamodel, Applications Models, Interaction Models, Technology Models
  • •Component Model

•Context Models – Use Case Index/Glossary, Business Events, Roles & Responsibilities

  • Use Case Scenarios – Function Point, Estimation, Test Cases, Training, Maintenance

•Rule Models

  • Business Rules – Business Policy, Business Application Logic, Process Decisions
  • Transaction Rules
  • Migration Models

•Concept Models

  • Logical Models
  • Physical Models – Special Operation Team (SOT
  • Integrity Rules
  • Data Dictionary

•Usability Models

  • Context Storyboards
  • Prototypes
  • Demonstrations

•Technology Models

  • Capacity
  • Performance
  • Schedulability
  • Time
  • Utilization
  • Availability – Service Level Agreement (SLA)

•Quantitative/Qualitative Models

  • Metrics
  • Statistical Methods
  • Monitor Model
  • Questionnaires

•Infrastructure Model – Integration, Source of Truth, Network

•Environment – Development, Staging, Production, System Views, Server Views, Project Views, Program Views

•Pervasive Services – Directory, Transactions, Persistence, Events & Signals, Security, Fault-Tolerance, QoS (Quality of Service)

•Experiments – Procedural test of hypothesis of known facts to determine factual findings or results

GAP Analysis (Application) – Artifact Deliverable, Template, Principals/Guidelines, Analysis, Synthesis, Findings, Recommendations

05:05

Lecture 5 – UML Requirements Models Support Hierarchy …

Discussion – 

UML Requirements Models Support Hierarchy:

UML Models fall into two main categories: structured and behavioral diagrams. UML diagram types are listed below. Discussion with a brief introduction to business related diagrams explaining how they are used when modeling applications are also presented in course lectures to follow.

You can draw UML diagrams using MS Windows Visio, Apple Runway or application software of your choice as further discussed in course lectures to follow. Also, check out UML diagram examples online using Google examples from the online diagramming community.

UML Diagram Types are listed below beginning with structured diagrams then followed by behavioral diagrams starting with Use Case Diagrams at position 8 in the diagram.

UML Diagram Types

  • Class Diagram
  • Component Diagram
  • Deployment Diagram
  • Object Diagram
  • Package Diagram
  • Profile Diagram
  • Composite Structure Diagram
  • Use Case Diagram
  • Activity Diagram
  • State Machine Diagram
  • Sequence Diagram
  • Communication Diagram
  • Interaction Overview Diagram
  • Timing Diagram

UML Diagram Types

Structured Diagrams

  • Class Diagram – Class Diagrams are the main building block of object oriented solutions. A class has three parts: class name, attributes and operations (methods). Large systems group classes to create class diagrams. Relationships among classes are shown by various line and arrow types (presented in a later lecture).
  • Component Diagram – Component Diagrams display structural relationships among components of a system. Used when working with complex systems having many components. Components communicate through interfaces linked using connectors.
  • Deployment Diagram – Deployment diagrams show system hardware and software used by the hardware. Deployment diagrams are useful when software solutions are deployed across multiple machines having unique configurations. 
  • Object Diagram – Object Diagrams are instantiated class diagrams showing relationships among class/objects using real world examples. Objects show how a system looks for a specific time. Where data is available object diagrams explain complex relationships among objects.
  • Package Diagram – Package diagrams show dependencies among various packages in a system. 
  • Profile Diagram – Rarely used, profile diagrams are structured diagrams describing lightweight UML extension mechanisms by defining custom stereotypes, tagged values, and constraints. 
  • Composite Structure Diagram – Composite structure diagrams show internal structure (relationships) among classes.

Behavior Diagrams 

  • Use Case Diagram – As most known of UML behavioral diagrams, Use Case diagrams provide graphic overview of system actors (roles), behaviors (functions) used by actors and behavior interactions (relationships, events). Great starting point for project discussion, because main actors involved are easily identified with key system interactions.
  • Activity Diagram – Activity diagrams represent workflows used to describe business operational workflow of various system components. Activity diagrams are often used as a State Machine (Chart) diagram alternative.
  • State Machine (Chart) Diagram – State machine diagrams are similar to activity diagrams with slight change to notation and usage. Also known as state diagrams or state chart diagrams. State machines are useful for describing object behavior differently according to state at a given moment as trigged by events. 
  • Sequence Diagram – UML Sequence diagrams show object interactions with ordered interaction occurrences among class/objects. UML Sequence diagrams show interactions for each specific scenario. Processes (Tasks) are represented vertically with process interactions shown as labeled arrows.
  • Communication Diagram – Communication diagrams model interactions among objects or components using sequenced event messages. Communication diagrams represent a combination of Class, Sequence, and Use Case Diagrams information describing both static structure and dynamic behavior of a system.
  • Collaboration Diagram – Collaboration (also communication interaction) diagrams illustrate relationships and interactions among UML objects.
  • Interaction Overview Diagram – Interaction Overview Diagrams are Unified Modeling Language (UML) diagrams controlling flow among nodes contained within interaction diagrams. Interaction Overview Diagrams are similar to activity diagrams. Both model visualization of activity sequences.
  • Timing Diagram – UML timing diagrams are interaction diagrams with focus on timing constraints. Timing diagrams explore object behaviors for a given time period. Timing diagrams are a special form of a sequence diagram. The axes in timing and sequence diagrams are reversed so time is increased from left to right with lifelines shown as separate compartments arranged vertically.
10:12

Lecture 6 – Requirements Problem Definition Class View

Discussion – 

Requirements Problem Definition Class View

  • Proposal
  • Problem Definition
  • Solution(n)
  • Project
  • Project Assignment(Role[])
  • People[]
  • Process(Type)
  • Work Plan(Type)

Requirements Problem Definition Class View

The Requirements Problem Definition Class View enables you to visualize relationships among functions, relationships and attributes you encounter during business and IT problem definition phases of programs and projects.

Class diagrams are one of the most used UML diagram types. It’s a key building block of any object oriented solution. Shown in the diagram are classes in a business proposal system. The classes present the name, attributes, and methods/operations of key system classes and relationship among each class.

In detailed process modeling, a class has three parts, name at the top, attributes in the middle and operations or methods at the bottom. In large systems with many related classes, classes are grouped together to create class diagrams. Different relationships among classes are shown by different types of arrows and line segments. Note that annotations are used with certain classes to show further detail such as Solution, Process, Roles, ...

As you can see in the model, projects begin from a business case proposal. This is followed by a problem definition phase to determine possible solutions to the related business problem in terms of complexity, risk, effort, priority and other related factors. 

Requirements Problem Definition Class View (with Class Relationships):

  • Proposal – Documented plan or statement presented to stakeholders for collaboration and consideration. 
  • Problem Definition – A problem definition is a collection of issues and/or requirements requiring clarification and solution.
  • Solution (n) – Individual or collaborative enterprise carefully planned and designed to achieve a particular set of goals, objectives and strategy.
    • Complexity – As systems and applications become more complex, underlying systems development process becomes concurrently more complex. Thus it is reasonable to presume specific development methods must parallel our seemingly unstoppable march toward greater complexity. UML 2.0 addresses semantics, ambiguity and extension issues at the expense of additional and continued complexity. Agile development is suitable for small projects producing solutions using less complex methodology with increased risk of not delivering requirement-based solutions as expected. Solutions must meet expected business requirements versus quick latest technology-driven solutions.
    • Risk – Risk is exposure arising for an organization when undertaking a specific task. Business project risk involves internal or external events stemming from circumstances impacting overall success or loss results from a specified undertaking.
    • Effort – Effort defines assignment or removal of resources from tasks. Project duration is lengthened or shortened depending on the amount of resources assigned to tasks, however, the total amount of work to complete a given task is not changed.
    • Priority – Priority aligns most important issues and/or tasks requiring resource attention as the first receiving attention.
    • Project – Individual or collaborative enterprise carefully planned and designed to achieve and deliver a particular set of goals, objectives and strategy meeting requirements and expectations.

Process (Type) – 

  • Waterfall (SDLC) – Developed by IBM, Waterfall is a version of Systems Development Lifecycle (SDLC) software engineering model. Also known as the classic approach to SDLC, Waterfall describes a linear, sequential development methodology. SDLC is an application development lifecycle used for systems, information and software engineering to describe a linear process of planning, creating, testing, and deploying information systems.
  • RUP – RUP is an IBM development model created by Rational which divides the systems development process into four distinct iterative, incremental phases each involving business modeling, analysis and design, implementation, testing, and deployment. The four phases are: Inception, Elaboration, Construction, and Transition.
  • Agile – Agile is a project management methodology used especially for software development characterized by division of tasks into short iterative, incremental phases using frequent reassessment and adaptation of plans as contrasted with waterfall development used for larger projects. Agile has many similarities with RUP.
  • DMAIC – DMAIC (Define, Measure, Analyze, Improve and Control) is a data-driven improvement cycle used to improve, optimize and stabilize business processes and designs. DMAIC is a core tool used in Six Sigma projects developed by General Electric (GE) similar to IBM Waterfall development.

Project Role Assignment – Project role assignment definitions align users and groups with scope. Role definition is the list of permissions and responsibilities associated with a role.

  • People - Sponsor, Project Manager, Business Analyst, Architect, QA, ...
  • Work Plan (Type) – Work Plan is a workplace strategy used to solve problems while enhancing employee drive and focus. A work plan is commonly implemented for from six to twelve months in business. However, generally there is no time limit on a work plan timeline. A Work Plan is a written agreement used for product development setting work goals, allocating responsibilities with stakeholders for performing and delivering work, timelines, and terms and conditions agreed to by stakeholders. 

Once proposal solutions are deemed feasible to continue through requirements consensus, a project is created to further clarify and refine requirements including:

  • Objectives - Objectives state business benefits an organization expects to achieve through expenditure of resources, budget, time and effort to complete and deliver a project.
  • Current Status – Current Status provides states of resources, budget, and time relative to project scope, objectives and strategy. Status indicates and is used to manage expectations of project sponsors and stakeholders. Status reporting supports and emphasizes minimization of surprises.
  • Type – Type categorization is a process for recognition, differentiation, definition, and understanding of ideas, objects, and symbols. Categories show relationships among knowledge subjects and objects. Categorization is fundamental in language, prediction, inference, decisions, and in all environmental interactions.
  • Strategic Alignment – Strategic Alignment brings business actions of divisions and staff into alignment with planned objectives and strategies. Achievement of strategic goals benefits organizations by performing collaborative alignment ensuring stakeholders jointly work toward stated goals.
  • Size – Relative object or process overall dimensional or magnitude extents.
  • Risk – Risk is exposure arising for an organization when undertaking specific tasks. Project risk to a business, can involve internal or external events stemming from circumstances impacting overall success or loss impact resulting from an undertaking.
  • Effort – Effort defines assignment or removal of resources from a task. Project duration is lengthened or shortened depending on the amount of resources assigned to tasks, however, the total amount of work to complete a task is not changed.
  • Resources Estimates – Resource Estimates of resource groups activity duration against amount of work effort required by resources needed for work completion. Activity duration is work effort divided by resource units. Typical activity duration is measured in days, work effort in hours and amount of resources required as a decimal fraction.

Next, project stakeholder roles are determined then responsibilities are assigned for sponsor, Project Manager, Business Analyst, Product Manager, Architect, Quality Assurance. Stakeholders then analyze assignments and determine communication strategies. 

Based on project requirements, process requirements are determined including –

  • Deliverables – Deliverables by project management described tangible or intangible objects produced as project results intended for customer delivery. A deliverable is a product, report, document, or system delivered as an overall project result.
  • Methodology – (IBM) Rational Unified Process (RUP), Waterfall (SDLC), Agile, DMAIC or combination. Methodology is systematic, theoretical analysis of methods used in a field of study, business, or engineering. Methodology encompasses concepts such as paradigm or theoretical modeling phases using quantitative or qualitative techniques and standards. Because a methodology does provide solutions, a methodology is not a method. Methodology offers theoretical support for understanding methods or method sets as “best practices” applicable case by case.
  • Standards – Standards are measures, norms, or models used for comparative evaluation of a level of quality or achievement.
  • Techniques – Techniques are prescriptions for completing specific tasks, especially execution or performance of a specific project, objective, or requirement.

Each is used to complete projects or meet program requirements. This is followed by determining Work Plan (Type) requirements for programs or projects. The Work Plan includes all project task estimates within an associated Work Breakdown Structure (WBS).

02:33

Lecture 7 – Architecture Framework Model

Discussion – 

Architecture Framework Model  

  • Resources
  • Communication
  • Requirements
  • Security
  • Process Workflow
  • Architecture/ Infrastructure Framework (Reuse)
  • Methodology
  • Output and Delivery

Architecture Framework Model

As you can see from the Architecture Framework Model, Visual Modeling concisely clarifies, illustrates, and defines a feasible, technology agnostic, measurable business problem aligned to business’ mission, goals, and strategies. In the diagram you see the system interactions involved – 

  • Resources – People, Equipment, Facilities, Tools, Effort, Technology, Data, Persistence, Documentation
  • Communication – Use Cases (Stories, Scenarios), Schedule, Monitors and Metrics, Status, Action Items, Test Cases, Lessons Learned, Lead Times, Return on Investment (ROI)/Net Present Value (NPV).
  • Requirements – Scope, Decomposition, Work breakdown structure (WBS), Complexity, Risk, Priority, Tasks, Yield and Waste, Costs, Cycle Times, Constraints, Business Rules
  • Security – InfoSec, SysSec, NetSec, PII, …
  • Process Workflow – Iterative, Incremental process step sequences 
  • Architecture/Infrastructure Framework (Reuse) – Manufacturing, Assembly, Logistics, Distribution, Construction, Development, Testing, Release, Training, ...
  • Methodology – Waterfall, RUP/UML, Agile/SCRUM, PMBOK, BA Planning Framework, QA/TQM, Documentation
  • Output and Delivery – Scope (Opportunity, SWOT), Demand Forecast (IRR, NPV), Decomposition, Goals/Objectives, Strategies, Programs, Projects & Portfolios, Products (Bills of Materials (BOM) – Parts Flow), Business & Functional Requirements, Use Cases (Functions & Features) Backlog, Estimation, Deliverables.

As a student, you are encouraged to do an internet search on each term listed above to more fully understand relationships and dynamics related to Business and IT requirements

04:12

Lecture 8 – Requirements Inventory

Discussion –  

Requirements Inventory

  • Business Event Sources
  • Business Event List
  • Use Case – Scenario (Story) … Investigate
  • Product Scope
  • Use Case Elements … Story, Actors, Relationships
  • Requirement Descriptions

Requirements Inventory

Business Event Sources – Business Events normally execute recurring business operations and processes. Business triggered events are defined processes for automating business protocols and practices required to prepare notifications, reports, alerts, and related business process automation features for stakeholders and/or sources from which materials, information and other sources are derived.

• Business Event List – Business Events Lists are a number of connected items or names written or printed consecutively from which materials, information and other sources are obtained to support events and event triggers.

• Use Case – Scenario (Story) – A use case scenario lists a sequence of actions or triggered event steps defining the interactions among actor roles and system events and behaviors needed to achieve a goal or handle exceptions and errors occurring during triggered event process sequences.

• Product Scope – Product scope is functions and features offered by a specific product offering. Business goals determine the scope of product offerings.

Use Case Elements … 

Story or Scenario – A User Story describes behavior exhibited by a system when an actor interacts with a website or system application interface and related events are triggered. User Stories focus on value or result gained during system interactions. User Stories are written from a user’s point of view while using a website or application and are written in the expected user language.

Actors – Primary use case actors are stakeholders, processes, or time interacting with a system for delivery of a product or service. Actors implement goal interactions with a system satisfied to receive or deliver results derived from system operations. A primary actor triggers events instantiating a use case scenario. Supporting Actors are external system results or services. 

Relationships – Relationships are interactions among multiple concept, object, or actor connections or event connection states. 

Requirement Descriptions – Business requirements describe documented deliverables needed to provide value. Products, systems, software, and processes define how to deliver, satisfy, or meet business requirements. Business requirements provide context for developing or procuring resources, materials and systems.

Requirements Inventory

Requirements Inventory supports requirements management including user stories, use cases, scenarios, (System Meta Language) SysML requirement diagrams and textual analysis. The Systems Modeling Language (SysML) is a general-purpose modeling language used to support systems engineering applications. SysML supports specification, analysis, design, verification and validation of systems. SysML is defined as an extension or subset of the Unified Modeling Language (UML) using UML's profile mechanism.

Textual or Content analysis is a set of manual or computer-assisted techniques for contextual interpretations of documents produced by communication processes.  It is any kind of text, written, iconic, multimedia or signification processes and includes traces and artifacts. The goal of textual or content analysis is production of valid and trustworthy information decision-making inferences.

5 types of texts are involved with content analysis –

  • Written text – such as books and papers
  • Oral text – such as speech and theatrical performance
  • Iconic text – such as drawings, paintings, and icons
  • Audio-visual text – such as TV programs, movies, and videos
  • Hypertexts – which are connection texts found on the Internet
06:42

Lecture 9 – Work scope inventory

Discussion – 

Work Scope Inventory

  • Core Team Members
  • Intended Product
  • Operational Work Area
  • Business Environment
  • Broader Environment
  • Interfacing Technology

Work Scope Inventory

Work scope inventory or Statement of Work (SOW) is a document routinely employed in portfolio, program and project management. It defines project-specific activities, deliverables and timelines for providing materials and services to a client. A SOW typically includes detailed requirements and pricing, with standard regulatory and governance terms and conditions. It is an important accompaniment to a Master Services Agreement (MSA) or Request for Proposal (RFP) based on related business case(s).

Work scope inventory typically addresses these subjects …

  • Purpose: Why are we doing this project? A purpose statement attempts to answer this.
  • Scope of Work: This describes the work to be done and specifies the hardware and software involved.
  • Location of Work: This describes where the work is to be performed, including location of hardware and software and where people will meet to do the work.
  • Period of Performance: This specifies the allowable time for projects, such as start and finish time, number of billable hours per week or month, where work is to be performed and anything else related to scheduling.
  • Deliverables Schedule: Deliverables schedules list and describe what is due and when.
  • Applicable Standards: This describes any industry specific standards requiring adherence in fulfilling a ctract.
  • Acceptance Criteria: Specify how buyers or receivers of goods determine if products or services are acceptable, usually with objective criteria. See Acceptance testing.
  • Special Requirements: Specify special hardware or software, specialized workforce requirements, such as degrees or certifications for personnel, travel requirements, and anything else not covered in contract specifics.
  • Type of Contract/Payment Schedule: Project acceptance depends on budget available sufficient to cover work required. Therefore a breakdown of payments by whether they are up-front or phased is usually negotiated in an early stage.
  • Miscellaneous: Many items not part of the main negotiations are listed due to importance to the project; overlooking or forgetting listed items may pose problems for the project.

As shown in the diagram, Work Scope Inventory environment includes:

  • Core Team Members – Core Team Members are essential stakeholders considered as important members within an organization or in different projects. Key project team members who discuss project work on routine basis are Core Team.
  • Intended Product (Technical) – An intended product is a product or service offered to satisfy specific wants or needs. Technical definitions introduce vocabulary making communication in a particular field succinct and unambiguous for project stakeholders.
  • Operational Work Area (Sociotechnical) – Operational work achieves business goals, while projects execute business objectives. Projects are often executed to provide inputs to operations for implementation improvement. Operations and projects often intersect during the product life cycle. Project management manages projects while business process or operations management executes operations. Projects are a means of executing activities not addressable within an organization’s normal operations domain.
  • Maintenance Operator – Maintenance Operators perform actions with an objective of retaining or restoring items to a required functional state. Actions include combination of technical and corresponding administrative, managerial, and supervision actions.
  • Normal – Normal is conforming to a standards or common methods.
  • Operational Support – Operations support systems (OSS) are computer systems used by telecommunications service providers to manage networks. Management functions supported are network inventory, service provisioning, and network configuration and fault management.
  • Business Environment (Sociotechnical) – Business Environments are collections of internal and external factors influencing an operating situation. Business environments include clients and suppliers, competition and owners, technology improvements, laws and government activities, and market, social and economic forces and trends.
  • Owner – An owner is a stakeholder or organization responsible for development, procurement, integration, modification, operation and maintenance, and/or final disposition of a system.
  • Functional Beneficiary – Functional Beneficiary is a person or organization receiving benefits, profits, or advantage from special activities, purpose, or tasks relating to an operation.
  • Sponsor – Sponsors are persons or organizations provide funding for projects or activities carried out by other persons or organizations.
  • Internal Consultant – Internal Consultants are employees using knowledge and expertise for business solutions and providing advice to organizations or business units within an organization.

Broader Environment (Sociotechnical)

  • Political Beneficiary – Political Beneficiary is a person or organization receiving benefits, profits, or advantage from special activity, purpose, or task related to an operation.
  • Financial Beneficiary – Financial Beneficiary is a person or organization receiving benefits, profits, or advantage from special activities, purpose, or tasks relating to an operation.
  • Regulator – Regulators are organizations or persons controlling or maintaining proper system or process operation.
  • Negative Stakeholder – Negative stakeholders are negatively affected by project success, while positive stakeholder are positively affected by project success.
  • External Consultants – External consultant are employed externally to an organization for expertise provided on a temporary, for fee basis. Consultants engage with multiple and changing clients, typically companies, non-profit organizations, or governments.
  • Customer – Customers (client, buyer, purchaser) receive products, services, and/or ideas from sellers, vendors, suppliers, and consultants through financial transactions or exchange for money or other valuable consideration. 
  • Interfacing Technology – Interfacing Technology interconnects with independent systems interacting and communicating across system boundaries. Interfaces are often user interfaces consisting of keyboard, mouse, monitor, system application menus as when a user interface enables users to communicate with a system operating system.
05:48

Lecture 10 – Requirements Knowledge Model

Discussion – 

Requirements Knowledge Model

This model provides a protocol for communicating knowledge discovered during requirements capture activities. The model is a guide to information needed for consideration in deriving requirements. It serves as a tool for communication between the various stakeholders on your project. The model also serves as specification landscape roadmap for requirements knowledge you plan to discover and trace. Your own process specifies who gathers specific types of information, as well as how it is packaged and reviewed by stakeholders.

Knowledge models identify requirements knowledge classes and relationships among them. The model depicted uses UML class notation. A rectangle represents a knowledge class, lines among knowledge classes indicate relationships. Cardinality is represented as 1 (one) and * (many) and is readable in both directions. 

The following defines classes and relationships for the knowledge model presented.

Requirements Knowledge Model

  • Work Scope
  • Project Goal
  • Stakeholder
  • Business Event
  • Business Use Case
  • Product Scope
  • Product Use Case
  • System Architecture Component
  • Implementation Unit
  • Atomic Requirement
  • Test
  • Constraint
  • Issue
  • Functional Requirement
  • Non-Functional Requirement
  • Technological Requirement
  • Data Dictionary
  • Fact/Assumption

Data Dictionary for Requirements Knowledge Models

  • Work Scope – Defines the boundary of investigation needed to discover, invent, understand and identify product requirements.
  • Project Goal – Supports understanding for why the company is making an investment to perform a given project.
  • Stakeholder – Identification of people, roles, and organizations with vested interest in a given project. Clarifies the project team, product direct users, indirect product beneficiaries, technical specialists with skills needed to complete products, external organizations rules or laws related to products, external organizations having specialist knowledge about product domains, and product producers and competitors.
  • Business Event – Business Events occurring outside work scope impact demand for services provided by related work. For example, a motorist passes an electronic tollbooth, a customer orders a book, a customer withdraws cash from an ATM, a doctor asks for a patient scan, an airport worker collects a baggage fee for passenger luggage.
  • Business Use Case – Business Use Cases (BUC) identify system behavior performed in response to a business event. For example, a policyholder who decides to make a claim. Business Use Cases transform information, work, and material into processing performed for approval or denial of claims.
  • Product Scope – Product scope sets boundaries for products to be built. Scope summarizes boundaries of all product use cases.
  • Product Use Case – Product Use Case (PUC) is functional requirements grouping of functions and features implemented by a product. PUC is the part of business use cases included as product.
  • System Architecture Component – Technology, software, hardware, or abstract container influencing, facilitating and/or constraining design and delivery.
  • Implementation Unit – Unit for packaging an implementation collection. 
  • Atomic Requirement – Minimal requirements specifying business needs or wants. Requirements have attributes and methods providing features and functions. 
  • Test – Tests are designed to ensure results from test review meet a requirement's fit criterion (precise measure). Tests are designed to cost effectively prove if a solution meets fit criterion of a requirement.
  • Constraint – Constraints are a type of requirement constraining design of a product, or limitations on a project such as restrictions of scope, budget, time, and/or quality.
  • Issue – Important topic, opportunity, or problem for debate or discussion.
  • Functional Requirement – Functional requirements are provided by a product and/or service. For example: calculate a fare, analyze chemical composition, record a name change, and/or find a new route. Functional requirements are product behaviors and attributes concerned with creating, updating, referencing, and deleting essential data within context of a product or service.
  • Non-Functional Requirement – Non-functional requirements are qualities a product or service must have or provide. For example: attractiveness, security, customizable, maintainability, portability. Non-functional requirements provide Look and Feel, Usability, Performance and Safety, Operability, Maintainability, Portability, Security, Cultural, Political, and Legal Compliance.
  • Technological Requirement – Technological requirements exists due to technology chosen for an implementation. These requirements serve the purpose of technology and are not originated by business stakeholders.
  • Data Dictionary – Dictionary defining meaning of terms used for requirements. Throughout a project terms related to implementation are added the data dictionary. Data Dictionary is a global class having a relationship with other classes in a knowledge model. Consistent use of terminology defined in the dictionary minimizes misunderstandings among stakeholders.
  • Naming Conventions - In system engineering, naming conventions are rules used for choosing character sequence used as identifiers denoting variables, types, functions, and other entities in source code and requirements documentation.
  • Fact/Assumption – A fact is a provable, indisputable truth, reality, certainty, or actuality. An assumption is a guess, hypothesis, postulate, or theory accepted as true or as certain to happen, without proof, facts or evidence
UML Requirements Support Tools
3 questions
Section 3: 03 - UML Modeling and Support Tools Stories & Requirements Management
01:54

Lecture 11 – UML Modeling and Support Tools Stories & Requirements Management

Discussion – 

What is UML modeling? Application Software IS Magic

Goals for UML modeling training and Introduction to:

  • MindManager      
  • Visio      
  • Runway      
  • Project      

These applications enable mastery of the art and science framework of needed to support – 

  • Business Information Systems Analysis
  • Design/Architecture
  • Development
  • Testing
  • Delivery 

…as components of valuable project generation of products and services for Stakeholders, Customers, Clients, Users, and Partners.      

Students of this course work with and master the UML Business Information Systems Conceptual Framework applications learned, in application to their own valuable system solutions as lessons learned by expanding their own ideas into concepts (vision and scope), requirements, issues/options, goals, and strategies. 

In the lectures 11-16 students learn Tools ….

Used to support and produce UML diagramming models/maps –     

Tools       

  • Mindjet MindManager (Mac/Windows)       
  • XMind (Mac/Windows)       
  • Freemind (Mac/Windows)       
  • MindNode (Mac)       
  • SimplMind (Mac)       

Diagramming Tools 

  • ARIS Express (Mac/Windows)       
  • ConceptDraw Pro (Mac/Windows)       
  • Lucidchart (Cloud)       
  • Microsoft Visio ((Windows)       
  • OmniGrapple (Mac)       
  • Enterprise Architect (Mac/Windows)       
  • Rational System Architect (Windows)       
  • Visual Paradigm (Cross-Platform)       
  • ClickCharts (Mac/Windows)      
03:14

Lecture 12 – Project Support Tools – MindManager

Discussion – 

Key MindManager Functions & Features 

  • Organize Ideas for Future Use
  • Mapping Template
  • Sort Topics Alphabetically     
  • Simplify Coherent Access 
  • Interactive Dashboard
  • Engage Stakeholders
  • Competitive Advantage
  • Creative Collaboration
  • Visually Convey Ideas    

Note: This lecture overviews the current version of MindJet MindManager as presented in the diagram. A comprehensive MindMapping course by this author is planned for release later this year. 

Project Support Tools – MindManager

Mindmaps are diagrams used to visually organize and model stories and related information. Mindmaps encapsulate concepts based on centrally associated representations of related ideas as images and word phrases. Key ideas connect directly to a central concept as image related ideas then branch out from core concepts or images and descriptors to other related concepts and images forming a montage of relational ideas.

Mindmaps are used to align organizational vision, objectives, and strategy by visually conveying portfolio, program, and project information with a single, centralized and coherent view or theme. Mind-mapping empowers people to enhance strategic thinking while enabling accelerated business processes thus facilitating rapid project planning with increased team productivity and collaboration. 

Use mind-map modeling to engage and excite employees by engaging stakeholders in stimulating real-time interactions during the process planning. Enforcing best practices using visual project plans, processes and ideas, enables bringing better products and services to market faster while staying ahead of competition. Mindmap models foster innovation through increased team collaborative interactions and consensus in early stages of strategic project planning.

Key MindManager Functions & Features –

  • Set up a specific view or template for any map or set of maps then save for future project use
  • Create, format then save custom topic templates enabling maps to be more compelling and far reaching
  • Enables ability to easily drag a map around context with more control
  • Sort topics alphabetically based on task completion percentage or task priority
  • Display and synchronize Images, Videos, eMail, Contacts, Calendar, Tasks, Notes, Folders
  • Quickly and visually convey volumes of information in an organized framework or montage
  • Consolidate simplified access to volumes of information in a coherent single view.
  • Provide an interactive dashboard for assessing, tracking and observing deliverables status.
  • Engage stakeholders in meaningful interactions and consensus with customers and partners through development, capture and sharing of collaborative vision and ideas.
  • Gain competitive advantage through more effective delivery of solutions, proposals and projects by thinking and working creatively
  • Creativity and innovation collaboration at all organization levels, transforming work methods and interactions on a daily basis. 
07:38

Lecture 13 – Project Support Tools – Visio

Discussion – 

Project Support Tools – Visio

  • Vision & Scope Tools 
  • Diagramming Tools

Project Support Tools – Visio

Microsoft Visio is a vector graphics diagramming application and is part of the Microsoft Office family used in the Microsoft Windows operating system platform. MS Visio is widely used application for diagramming UML and use with other modeling tools in MS Windows. Most diagrams presented in our course were constructed using MS Visio.

Project Support Tools – Visio    

  • Vision & Scope Tools – Vision defines organizational mission and purpose focusing on goal, aspirations and expectations designed to be uplifting, inspiring, and timeless. Vision is constant even with organizational strategic changes. 
  • Mission – A mission is a concise, clear, and powerful definition of an organization's purpose and primary objectives and explaining why a business exists to organization stakeholders and to outside organizations and people. 
  • Scope – Defines organization program and project boundaries. Scope determines resources used work to be completed and during project lifecycle including identification of work both included and not included in a current project.
  • Diagramming Tools – Refer to list below.

As previously noted in this course section, other tools and diagramming aids are widely used to support and produce UML diagramming mapping models (with supporting operating system platforms) are –     

Vision & Scoping Tools       

  • Mindjet MindManager (Mac/Windows) – MindManager is a mindmapping application developed by Mindjet Corporation. MindManager prior to MindManager 8 supported Mac OS X. Files created in recent versions are compatible with both Microsoft Windows and Mac OS X platforms.
  • XMind (Mac/Windows) – XMind is a mindmapping and brainstorming application from XMind Ltd. In addition to management elements, the application captures ideas, clarifies thinking, manages complex information, and promotes team collaboration.
  • FreeMind (Mac/Windows) – FreeMind is a free mindmapping application written in Java. FreeMind is licensed under the GNU General Public License. It provides extensive export capabilities. It runs on Microsoft Windows, Linux and Mac OS X via the Java Runtime Environment.
  • MindNode (Mac) – MindNode is a mindmapping application built for both iPhone and iPad. The MindNode application enables expression of thoughts and ideas through brainstorming. Although constrained by the iPhone 3.5 inch screen (not so with iPad), MindNode makes use of all available space.
  • SimplMind (Mac) – SimpleMind Mindmapping supports organization and generation of thoughts and new ideas using an intuitive application interface.

Diagramming Tools       

  • ARIS Express (Mac/Windows) – ARIS Express is a business process analysis and management modeling tool supporting multiple modeling notations such as BPMN 2, Event-driven Process Chains (EPC), organization charts, process landscapes, and whiteboards.
  • ConceptDraw Pro (Mac/Windows) – ConceptDraw PRO is proprietary diagramming software used to create business graphics, including: diagrams, flowcharts, Infographics, data visualization for business process models, data presentation and project management documentation.      
  • Lucidchart (Cloud) – Lucidchart is a web-based diagramming software enabling users to collaborate and work together in real time creating flowcharts, organization charts, website wireframes, UML design models, mind maps, and software prototypes.
  • Microsoft Project (Windows) – Microsoft Project is a project management application designed to assist project managers in development of a project plan, task resources assignment, progress monitoring and tracking, budget management, and workloads analysis.    
  • OmniGrapple (Mac) – OmniGraffle is a diagramming and digital illustration application for Mac, iPhone, iPad and iPod touch created by The Omni Group enabling users to convey ideas, organize thoughts visually, and collaborate thoughts and ideas through User Experience design. 
  • Enterprise Architect (Mac/Windows) – Enterprise Architect is a comprehensive development tool for designing applications and XML web services, as well as delivering architectural guidance for development teams. Enterprise architect uses strategic management discipline for working with stakeholders, leadership and subject matter experts (SME), to design, build, encapsulate and deliver holistic views of organization strategy, processes, information, and information technology assets. 

Enterprise architect deploys architectural knowledge to ensure business and IT alignment. Enterprise architects encapsulate business mission, strategy, and processes of an organization with IT strategy by documenting use of multiple architectural models or views illustrating how current and future needs of an organization are met through an efficient, sustainable, agile, and adaptable architecture. 

Enterprise architect operates across organizational "silos" driving common approaches and exposing information assets and processes across the enterprise. The goal is delivery of architectures supporting effective, efficient and secure IT analysis, design, development, and delivery environments needed to meet business solution needs.

Rational System Architect (Windows) – IBM® Rational® System Architect is an enterprise architecture application for visualizing, analyzing, and communicating enterprise architecture and business process analysis. 

Visual Paradigm (Cross-Platform) – Visual Paradigm supports UML 2, SysML, Business Process Modeling Notation (BPMN) and provides reporting capabilities and code generation. Visual Paradigm generates reverse engineered diagrams from code and provides round-trip engineering using various programming languages.

ClickCharts (Mac/Windows) – ClickCharts for Mac enables creating visual representation of processes, organizations, mindmaps, and other diagrams enabling stakeholders to: 

  • Visualize complex processes and organizations
  • Create value stream and data flow diagrams
  • Identify bottlenecks and process optimization opportunities

Visual Studio (Microsoft) – Is an integrated development environment (IDE) used to develop Microsoft Windows applications, web sites, web applications and web services. Visual Studio uses development platforms such as Windows API, Windows Forms, Windows Presentation Foundation, and Microsoft Silverlight. Visual Studio produces native and managed code.

Note: Flowcharts and UML diagrams organize display of data so detailed and complex processes are easier to understand. Flowcharts are an effective method used to troubleshoot and share information

02:59

Lecture 14 Project Support Tools – Runway

Discussion – 

Runway Provides 

  • Connected Lines 
  • Smart Paths 
  • Bézier Path tool 
  • Mac-native UI
  • Mac OS X features 
  • Common Formats

Runway Provides 

  • Connected Lines – Runway supports "connected" lines. When resizing, lines magnetically snap to follow other shapes. As you drag connected shapes around the canvas, connected lines adjust.
  • Smart Paths – Runway provides "smart" paths used to connect boxes and shapes with smooth, curvy lines.
  • Bézier Path tool – Bezier Path Tool is used to model smooth curves indefinitely scaled enabling natural and intricate shapes. 
  • Mac-native UI – Mac-native UI is designed for interacting with Apple Mac OS X efficiently. User interfaces (UI) determine how easily an application does what a user wants to do. Graphical user interfaces (GUIs) using windows, icons, and pop-up menus are standard on personal computers.
  • Mac OS X features – Mac OS X GUI is named Aqua providing look and feel, behavior, and integration of GUI elements. Aqua provides distinctive features including Mac OS X high-quality photorealistic icons rendered at various sizes enabling features such as in-place document preview and in-icon status indication.
  • Common Formats – Common Formats are downloadable as PNG, JPEG, TIFF or multiple-page PDF.

Project Support Tools – Runway

Apple Runway is an elegant Mac OS X UML Design application. Runway provides most important features needed in a vector diagramming and design tool with easy-to-use Use Case, Activity, and Class Diagram tool. Runway is great for Project Managers, Programmers and Web Designers who need a simple tool for rapidly designing flowcharts, laying out wireframes, or visualizing model relationships without getting lost in a sea of confusing extraneous and confusing features.

Runway is used during our later Use Case demonstration so you can see many of Runways features in action.

Runway Provides – 

  • Support for "connected" lines. When resizing, lines magnetically snap to other shapes. When, connected shapes are dragged around the canvas, connected lines adjust as well
  • Enables "smart" paths used to connect boxes and shapes with smooth, curvy lines
  • Includes a powerful Bézier Path tool for creating vector graphics of most any shape or description. Runway is a vector graphics tool used to design icons and other graphics with bézier paths
  • Provides just important tools needed to work quickly in a single-window Mac-native UI
  • Fully supports modern Mac OS X features such as Quick Look, Full-Screen Mode, Autosave, and Version Browsing
  • Enables export of common image formats such as SVG, PNG, JPEG, TIFF or multiple-page PDF
03:23

Lecture 15 – Project Support Tools – Visio

Discussion

Refer to the diagram showing Project Support for Product Context interrelationships of key Vision and Scope components.

Project Support Product – Context Components …

  • Portfolio Management
  • Program Management
  • Project Management
  • Performance Management
  • Service Management
  • Estimation

Project Support Product – Context Key Components Include …

  • Portfolio Management – Portfolio Management (PPM) centralizes management of processes, methods, and technologies used by project managers and project management offices (PMOs) to analyze and collectively manage current or proposed projects.
  • Program Management – Program Management is a process for managing multiple related projects. Program management involves managing multiple related projects working toward a common goal or result.
  • Project Management – Project management is a methodical approach used to plan and guide project processes from start to finish. Processes are guided through initiation, planning, executing, controlling, and closing. Project management applicable to any project is used to control complex processes of application and product development projects.
  • Project portfolio management - Project Portfolio Management (PPM) is centralized management of processes, methods, and technologies used by project managers and project management offices (PMOs) to analyze and collectively manage current or proposed projects based on numerous key characteristics.
  • Performance Management – Performance management includes activities ensuring goals are consistently, effectively and efficiently achieved. Performance management focuses on organizational and stakeholder performance of processes used to build products, processes or services.
  • Service Management – IT service management (ITSM) refers to the entirety of processes and activities performed by an organization used to plan, deliver, operate and control IT service offerings to stakeholders. ITSM is defined by protocols, organized and structured in processes and supporting policies and procedures.
  • Estimation – Estimation is judgement of the size, amount, cost, and impact of a specific attribute, item or method.

Project Support Product – Context

Vision and scope are constituent components of any project’s business requirements. Product vision is a strategic concept defining the ultimate purpose and form of a new process or system. Product vision also describes a product’s positioning among competing products and services and within a common market or operating environment. Project scope is the portion of product vision a current project or iteration addresses. Scope draws a boundary between what’s in and what’s out of a project. Scope identifies what a product is and is not, what it will and won’t do, and functions and features it will and won’t contain.

Well-defined scope sets project expectations among stakeholders by identifying external interfaces among a system and surrounding environment. Scope definition aids project managers in assessing resources needed for projects while making achievable commitments. Further, a scope statement defines boundaries of a project manager’s role and responsibilities. A scope definition must list specific project or product limitations or exclusions. Not everything out of scope is listed. Limitations must identify capabilities expected to be included in the project but not all capabilities not included. Stakeholders involved with a project expect specific capabilities to be included. Supporting management and stakeholder expectations is critical to project success.

04:55

Lecture 16 – Project Support Product – Context

Discussion

Refer to the Project Schedule presented.

MS Project Fields 

  • Task
  • Resource
  • Duration
  • Start
  • Finish
  • Predecessor
  • Milestone
  • Date
  • Report
  • Work Breakdown Structure (WBS)

MS Project Key Fields – 

  • Task – Tasks are activities to be accomplished within a defined period of time or deadline to achieve specified project work task-related goals. Tasks are divided into role assignments with specified start and end dates or deadline completion dates. Completion of all assignments for a specific task renders the task complete. Tasks are linked together creating dependencies.
  • Resource – Resources are scheduled and assigned budget, materials, staff, and other assets and are used by a person or organization function to complete work tasks effectively and efficiently.
  • Duration – Duration is the length of time an entity or activity exists or lasts.
  • Start – Start is a point in time or space for origin or beginning of a task or resource allocation.
  • Finish – Finish is a point in time or space for the cessation or completion of a task or resource allocation.
  • Predecessor – A predecessor activity is a scheduled work activity in a project determining or establishing when the logical successor activity begins or an activity ends.
  • Milestone – Milestones mark specific check points along a project timeline. Milestones signal check points such as project start and end date, external budget review, and work task resource allocation stakeholder reviews. Milestones are instances in time not impacting project duration when completed.
  • Date – Key project characteristic are start, current and end dates. Setting these dates seems simple enough to determine until attempting to define these dates exactly. There are no universal standards for setting these dates. Choosing these dates is contingent on organization and stakeholder choice. 
  • Report – Progress Reports are assessments of project or process progress conveying details such as sub-goals and milestones accomplished, resources expended, problems and issues encountered, and project or process expected completion on time and budget. Progress reports are used by management and stakeholders to determine necessary changes to project effort, budget, resources and requirements.
  • Work Breakdown Structure (WBS) – Work breakdown structure (WBS) is used in project management and systems engineering as a deliverable-oriented decomposition of a project into interacting components and tasks. Work breakdown structure is a key project deliverable organizing project team work into manageable sections.

Project Support Tools – MS Project

Microsoft Project is a project management software application designed to assist project managers develop and schedule a project plan, assign resources to scheduled tasks, monitor and track delivery progress, manage project budget, and analyze project workloads. 

MS Project enables project budget creation based on work assignments and resource time and budget rates. As work is estimated and resources are assigned to tasks, Project calculates cost equal to work times rate, rolled up to task level then summarizes tasks to project level. Resource definitions (people, equipment and materials) are shared among projects using a shared resource pool. 

Each resource can be setup with a calendar defining days shifting a resource is available based on resource calendars. Resource rates are used to calculate resource assignment costs rolled up then summarized at resource level. 

Resources are assigned multiple tasks in multiple plans. Each task is assigned multiple resources. The application schedules task work based on the resource availability as defined in resource calendars. The number finished products producible with a given amount of raw materials cannot be determined rendering MS Project unsuitable for solving available material constrained production problems. Additional software is needed to manage complex facilities producing physical goods.

MS Project enables creation of critical path scheduling and Gantt charts. Schedules are resource leveled with chains visualized in a Gantt chart. Different user classes have different project access levels, views, and related data. Custom objects such as calendars, views, tables, filters, and fields are stored in an enterprise global database shared by all users.

Section 4: 04 - UML Diagrams Relationships
09:45

Lecture 17 – UML Diagrams Relationships - Demonstration 

06-UML Diagrams Relationships Demonstration

Discussion – 

Object Oriented Systems Context Workflow Architectural Framework

In this lecture Object Oriented (OO) Uniform Modeling Language (UML) modeling Workflow Architectural Framework context views and tools are discussed. UML Diagram Relationships contained within each context view of the UML Rational Unified Process (RUP) architectural framework is presented. These views and tools are then later demonstrated in course lectures to follow. 

Each context view and each UML model diagramming tool within a named view is overviewed during this lecture. After introduction of each model context and tool within our framework, we discuss and demonstrate how most commonly used tools are used for actual project and system analysis, design, development, test, and delivery. 

As you can see the OO RUP/UML architectural framework contains five context views, starting with the User View. 

Context Views Include –  

  • User View
  • Structural View
  • Behavioral View
  • Implementation View
  • Environmental View

Context Views –  

  • User View – Our first context view shown in orange at the top of the context bundle is the User View containing your use case diagrams. Use Cases are the first collection we capture and decompose in discovery of requirements. Use Case Diagrams are used to define your system’s scope, context, scenarios, roles, and requirements. Each of these is more fully discussed in a later lecture.
    • Use Case Diagrams – As most well-known of UML behavioral diagrams, Use Case diagrams provide graphic overview of system actors, behaviors (functions, scenarios, stories) used by actors and behavior interactions (relationships, events, triggers). Use Cases are a great starting point for project discussion and collaboration, because main actors involved are easily identified with key system interactions (behaviors and relationships).

____________________________________________

  • Structural View – Next in our overview is the Structural View. This section shown in green contains your composite structural diagram, your package diagrams, object diagrams, and your class diagrams. These diagrams represent containers and packages you’ll use for analysis, design, programming and development. The most often used Structural View diagram is are the Class Object Diagrams which are discussed further in a future lecture within this course. Other diagrams discussed in future amendments to this course are – 
  • Composite Structure Diagrams – Composite structure diagrams show internal structure (relationships) among classes. UML Composite Structure Diagrams are static structure diagrams displaying internal class structure and collaborations made possible by this UML structure.
  • Package Diagrams – Package diagrams are UML structured diagrams showing work packages and dependencies among work packages. A package diagram depicts dependencies among packages contained in package models. A package is a general purpose mechanism for collecting and organizing model elements & diagrams into groups providing encapsulated, unique namespaces.
  • Profile Diagrams – Rarely used, profile diagrams are structured diagrams describing lightweight UML extension mechanisms by defining custom stereotypes, tagged values, and constraints. Profiles allow adaptation of UML metamodels for various platforms such as J2EE or .NET and/or real-time or business modeling domains.
  • Object Diagrams – Object Diagrams are instantiated class diagrams showing relationships among class objects using real world examples. Objects show how a system looks for a specific time as objects are instantiated. Object Diagrams illustrate complex relationships among objects. This is demonstrated in our later class diagrams demonstration lecture. 
  • Class Diagrams – Class diagrams are key building blocks of object oriented data solutions. A class has three parts: class name, attributes and operations (methods). Large systems group classes to create class diagrams. Relationships among classes are shown by different line, arrow types (relationships) as demonstrated in our later Class Objects Diagrams demonstration lecture.

____________________________________________

  • Behavioral View – In the bottom left quadrant shown in yellow we discover the Behavioral View containing –
  • Activity Diagrams – Activity diagrams represent workflows used to describe business operational workflow of various system classes, components, and packages. Activity diagrams are often used as a State Machine (Chart) diagram alternative as discussed in a later course lecture.
  • Sequence Diagrams – UML Sequence diagrams show object interactions with order interaction occurrences among actors and class objects. UML Sequence diagrams show interactions for specific scenarios. Processes (Tasks) are represented vertically with process interaction event messages shown as labeled lines and arrows horizontally as demonstrated in our Sequence Diagram lecture later in our course.
  • Communication (Collaboration) Diagrams – Are similar to sequence diagrams with focus on messages passed among objects. Communications event messages can also be represented using sequence diagrams.
  • State Machine Diagrams – State machine diagrams are similar to activity diagrams with slight change to notation and usage. Also known as state diagrams or state chart diagrams. State machines are useful for describing object behavior differently according to state at a given moment following triggered events as demonstrated in a later State Machine course lecture.
  • Interaction Overview Diagrams – Interaction overview diagrams are similar to activity diagrams. While activity diagrams show process sequence interactions, overview diagrams show a collection of interactions among sequence diagrams. There are seven types of interaction diagrams which can each be a node within an interaction overview diagram. Interaction Overview Diagrams are discussed in a future course now a work-in-process.

These and other objects seen in the previous User View and Structural View quadrants, you normally think of as components of our object-oriented architectural framework, however, there are two additional views we must consider – Implementation View and Environmental View – presented our next two discussions.

____________________________________________

  • Implementation View – Component Diagrams, Package Diagrams

Next we present the Implementation View shown in the blue context of the Workflow Architectural Framework model. As you can see the Implementation view contains Component Diagrams. Component diagrams are used to encapsulate services, components and related software needed to support packaging business and IT Use Case Requirements for delivery. 

The Implementation View contains these diagrams –  

  • Component Diagrams – Component diagrams display structural relationships among components of a system. Used when working with complex systems having many components. Components communicate through interfaces using linked connectors and triggered events.
  • Package Diagrams – Package diagrams are UML structure diagrams showing work packages and dependencies among work packages and are also considered Structured View Diagrams. A package diagram in UML depicts dependencies among packages contained in package models. A package is a general purpose mechanism for organizing model elements & diagrams into groups providing encapsulated, unique namespaces.

____________________________________________

  • Environment View – In the lower right pink quadrant, is contained the Environmental View. This is where our deployment support diagrams are contained. Environment View diagrams are – 
  • Deployment Diagrams – Deployment diagrams show system hardware and system software used by related hardware. Deployment diagrams are useful when software solutions are deployed across multiple systems having unique configurations.
  • Entity Relationship Diagrams (ERD) – Entity Relationship Models or Entity-Relationship Diagrams (ERD) are graphical representations of entities and relationships used for data organization within information database systems. ERDs are not UML diagrams, but are used to support Data Requirement design and development support for Business and IT Projects.

____________________________________________

In summary, in this lecture, we’ve overviewed our OO RUP/UML Workflow Architectural Framework Model Context Venn Diagram. The model presented, is available for your download and review. Please provide any comments, suggestions, or further questions you may have in the green “Ask a new question” textbox (“Search for a question”) under the Q&A tab for this course.

07:30

Lecture 18 – UML Diagram Relationships - UML Diagrams Framework Discussion

UML Framework – 

  • Problem Statement
  • Data Dictionary
  • Requestor Phase
  • Analysis & Design Phase
  • Implementation Phase

UML Stories (Scenarios) – User stories are based on user-centric goals and behaviors of one or more entities achieved using a specific product. User stories apply when a person, place, or thing interacts with an interface of a product, process, or system to achieve a goal.  Product, process, or system are not necessarily automated and are often person-to-person manual interactions or operations.

A user story is written in the format - As a [person in a role] I want to [perform some activity] so that [some goal is achieved] … atomic, very concise and unambiguous. 

UML Framework Elements –  

•       Problem Statement – Problem statements describe issues needing to be addressed by a problem solving team and presented prior to problem solving.

•       Data Dictionary – Data Dictionaries are collections of information describing content, format, and structure of a database and relationships among its elements, used to control access to and manipulate a database and contents.

•       Requestor Phase – Requestor Phase is the event or action of asking for response to request for resolution of an issue, opportunity or problem.

•       Analysis & Design Phase – Analysis & design phase is a technical approach for analyzing and designing applications, systems, or businesses by using visual modeling throughout development lifecycles to manage stakeholder collaboration and communication ensuring product quality.

•       Implementation Phase – Implementation phase engages team component builds from scratch or by composition. Using requirement and architecture documentation from analysis and design phases, teams build products and processes requested as specified using innovation and flexibility as needed to enable progress. Components are narrowly designed for a particular system, or components are built more generally to satisfy reusability guidelines based on requirements and architecture documentation.

UML Framework– 

Requestor Phase

•       User View

•       Problem Statement – Problem statements describe issues needing to be addressed by a problem solving team and presented prior to problem solving.

•       Behavioral View

•       Use Case Model Diagram – As most known UML behavioral diagram, Use Case diagrams provide graphic overview of system actors, behaviors (functions, scenarios, stories) used by actors and behavior interactions (events, relationships). Great starting point for project discussion, because main actors involved are easily identified with key system interactions.

•       Use Case Description

A use case description contains descriptions of:

•       Context Scope (System Boundary) defining system of interest as related to environment

•       Actors (System Roles) are entities (Actors) interacting with a system defined according to roles.

•       Use Cases (Stories, Scenarios) specify roles played by actor triggered event relationships interacting with a system.

•       Relationships (triggered events, interactions) among actors and use cases within the related system environment.

•       Collaboration(Communication) Model

Related to Collaboration diagrams, Communication diagrams model event-driven interactions among objects and sequenced messages. Communication diagrams combination information from Class, Sequence, and Use Case Diagrams describing both static structures and dynamic behaviors of a system.

Collaboration (interaction) diagrams model triggered event interaction relationships among objects. Collaboration (interaction) requires use cases, system operation contracts, and domain models for existence. Collaboration diagrams depict messages among class object instances.

Analysis & Design Phase

•       Data View

•       Data Dictionary – Data Dictionaries are collections of information describing contents, format, and structure of databases and relationships among related elements, used to control access to and manipulation of a database.

•       Class/Object Diagram – Class/Object Diagrams are instantiated class diagrams showing relationships among class/objects using real world examples. Objects show how a system looks for a specific time. Where data is available, diagrams illustrate and explain complex relationships among objects. Class Object interact with Databases to collect and interact with attributes through Object methods to get, modify, or delete attribute contents when triggered by event methods interactions.

•       State Diagram – State diagrams are similar to activity diagrams with slight change to notation and usage. Also known as state machine diagrams or state chart diagrams. State machines are useful for describing object behavior differently according to state at given moments of time.

•       Sequence Diagram – UML Sequence diagrams show object interactions with order of interaction occurrence among class objects. UML Sequence diagrams show interactions for each specific scenario. Processes (Tasks) are represented vertically with process interactions shown as labeled arrows.

•       Design Case Diagram – Design Case Diagrams describe proposed system functionality representing discrete units of interaction among users and a system. Interaction is a single unit of meaningful work such as Create Account or View Account Details.

•       Activity Diagram/Interaction Overview Diagrams (Design Patterns)

Activity diagrams represent workflows used to describe business operational workflow of various system components. Activity diagrams are often used as a State Machine (Chart) diagram alternative. Interaction Overview Diagrams are Unified Modeling Language (UML) controlling flow among nodes contained within interaction diagrams. Interaction overview diagrams are similar to activity diagrams. Both provide visualization of activity sequences.

Implementation Phase/Structural View/Environmental View

•       Package Diagram – Package diagrams show dependencies among various packages in a system.

•       Database Schema – Database schemas are structures described in formal language supported by database management systems (DBMS/RDBMS/ODBMS). Schemas are data organization blueprints used to present database construction and organization.

•       Component Diagram/Profile View – Displays structural relationships among system components. Used when working with complex systems having many components. Components communicate through interfaces linked using connectors.

•       Deployment Diagram – Deployment diagrams show system hardware and software used by related hardware. Deployment diagrams are useful when software solutions are deployed across multiple machines having unique configurations.

05:40

Lecture 19 – UML Business Processes Relationships – Business Workflow

Discussion – 

Business Workflow –  

  • Functionality
  • Inputs – Boundary, Controller, Entity
  • Transformations
  • Outcomes
  • Use Cases
  • Classes

Stories (Topics) –   

Unified Modeling Language (UML) defines a notation standard for object-oriented (OO) systems. UML models enhance communication and collaboration among domain experts, workflow specialists, software designers and related stakeholders with various backgrounds. UML used at common level provides intuitive context visualizations for workflow system users. UML symbols provide structured semantics meaning visual workflow descriptions are used to specify projects, processes, systems and related deliverables. 

A key challenge is modeling business processes and systems in a precise, user-friendly manner. Symbols used to describe business processes must be intuitive using defined semantics, so descriptions used by developers have a general but precise system application specification. UML provides rich extensive notation for system description. Notation can be too rich to provide intuitive, user-friendly system models. However, UML is generally accepted notational standard within the system development community. UML is also useful at a common or general level with implementation details suppressed but with semantics defined precisely. Diagrams can be adorned with implementation details needed for system or application design purposes as necessary.

Business system models describe process behaviors, static structures, and input transformation to output results. An intuitive process model is a sequence flow model of activities (tasks), performed in ordered (sequenced step-by-step) transformations needed to achieve a specific goal or result. UML sequence and activity diagrams provide user-friendly, precise specification of business processes. Static structures such as organization charts are represented as static structure diagrams having no implementation details. Graphical representation of implementation details such as navigation arrows can be mistaken for flows. Thus, compositions are shown by drawing elements inside each other as opposed to using associations with filled diamonds. Various properties are represented using text notation.

Business Workflow –  

  • Functionality – Ability to perform a task or activity closely related to another task or activity and dependent on related entities for existence, value, or significance.
  • Inputs (MVP) – Data entered into a computer or data processing system using peripheral devices to provide data and control signals to an information processing system.

Entity Control Boundary Patterns – Model-View-Controller (MVP) patterns based on use cases iteration requirements supporting identification of roles during use case steps for either input to or output from a transformation.

  • Boundary (View) – Object interface with system actors for external services such as display screens and menus, UserInterface, DataBaseGateway, ServerProxy, Agreements, Proposals, Contracts ....
  • Controls (Controller) – Objects mediate among boundaries and entities serving as glue among boundary elements and entity elements and implementing management of iteration logic among various elements of Use Cases and systems. Controls orchestrate commands (triggered event messages) execution coming from a boundary by interacting with entity and boundary objects. Controls often correspond to use cases and map to use case controllers in the design model.

Note: Many controllers are simple enough for implementation as entity or boundary class methods not requiring obect mediation.

  • Entity (Model) – Entities are class objects representing system data: Customer, Product, Transaction, Cart, Documentation, Requirements, Specifications, Statement of Work ....
  • Internal Dynamics – Are associated with each analysis model control as a statechart diagram representing a control's internal logic.

Communication Rules – 

  • Actors only talk with boundary objects.
  • Boundary objects only talk with controllers and actors.
  • Entity objects only talk with controllers.
  • Controllers talk with boundary objects and entity objects, and with other controllers, but not with actors
  • Transformations (MVP) – Action(s) of changing action sequences required to meet specific business goal(s). Transformations convert value sets from source data, tasks, processes, or systems into value sets of destination data, task, process, or system.
  • Outcomes (MVP) – During planning and evaluation, projects determine objectives defining entities and fctions needed to produce, implement, provide, and develop processes and systems. Objectives are monitored using centric measures as outputs defining amount, quality, or usage volume of project product and service deliverables.
  • Use Cases – Collection of actions, event or steps defining interactions among actor role(s) within use case system context needed to achieve goal(s) and results. Actors are human, external system(s), or time.
  • Classes – Collection or category of common properties (attributes) and methods (operations) differentiated from class objects by kind, type, or quality.
06:47

Lecture 20 – Rational Unified Process (RUP)/Modeling Language (UML) versus Data Modeling

Discussion – 

Stories (Topics) –  

  • Use Case Analysis
  • Activity Diagrams
  • Sequence Diagrams
  • State Diagrams
  • Class Diagrams
  • User Requirements
  • Prototype Models
  • Technical Requirements
  • Construction Models
  • Test & Integration Plans
  • Deployment Models
  • Releases
  • Training

Rational Unified Process (RUP)/Modeling Language (UML) versus Data Modeling

Rational Unified Process (RUP) is a collection of recognized methods for reliable development of large and complex business information systems. Business information systems are normally modeled using Unified Modeling Language (UML) from inception to delivery. UML RUP Processes and models ensure requirements are documented, communicated, modified and implemented in a structured manner enabling full control during the project lifecycle using iterative, incrementally (wash, rinse, dry, repeat) design, construction and delivery. Each system element is completed within a single step, with each subsequent step beginning in parallel with refinement of previous steps as needed.

RUP has four phases – Inception, Elaboration, Construction and Transition. Inception establishes main goals and a framework for a project. Elaboration restructures functional requirements into UML use case and related models. Architecture, risk analysis and time planning (project management) are each considered during this step. Refinement and development are accomplished during construction phase. Transition is delivery of training and support of completed systems.

Data modeling is a cost effective alternative for less complex data systems with well-defined requirements. Data modeling with entity-relationship method (ERD) models data versus functionality methods of UML. Data models (Conceptual, Logical, and Physical) are easily understood mapping of business data and relationships among the data items used to support business systems. 

Stories (Topics) –   

  • Use Case Analysis – Technique for identifying and clarifying system requirements and information used to define behaviors (processes) and structures (classes) used in use case diagrams within development or redesign context of programs, processes, and systems.
  • Activity Diagrams – Represents workflows used to describe business operational workflow of various system components. Activity diagrams are often used as State Machine (Chart) diagram alternatives.
  • Sequence Diagrams – Interaction diagrams presenting how processes interact with one another and in what order. Sequence diagrams show object interactions arranged in time ordered step sequence.
  • State Diagrams – Diagrams used to describe behavior of a system considering all possible object states as each given event occurs. Each diagram represents a collection of objects tracking various states of each class object within a given system.
  • Class Diagrams – Are main building blocks of object oriented solutions. Classes contain three parts – class name, attributes (data) and operations (methods). Large systems group classes to create class diagrams. Relationships among classes are shown by different line, arrow types.
  • User Requirements – Are needed for any project to be successful. Poor requirement documentation is why many projects fail when system functions, features, performance, and delivery are not correctly specified. Many systems are simply given a delivery deadline, a spending budget, and vague notion of what a system should do. The root of this problem is generally systems developers rarely understand how a business operates or should operate as compared to business users, while business users have little or no idea of what functions a computer system can achieve. As a result business management time is concentrated on meeting timescales and budgets rather than specifying system delivery requirements and expectations.
  • Prototype Models – Systems Development Method (SDM) used to approximate how a system or product is built and tested, then reworked as necessary as a baseline model until an acceptance is achieved before a complete system or product is developed. Prototypes work best when not all project or product detail requirements are known in advance. Prototyping is an iterative, incremental process used during collaboration among developers, users, and other stakeholders.
  • Technical Requirements – Define and clarify technical aspects a system must achieve, such as performance, reliability, and availability issues. Technical requirements are referred to as Quality of Service (QoS), Service-Level Agreement (SLA) or non-functional requirements.  
  • Construction (Metadata Models) – Use meta-modeling in software and systems engineering for analysis and construction of models useful and applicable for a predefined class of problems. Important notions are concept, generalization, association, multiplicity and aggregation.
  • Test & Integration (I&T) Plans – Integration and Testing (I&T) is a software testing phase in which individual modules are combined and tested as a group. I&T occurs after unit testing and before validation testing. Integration testing aggregates into larger testing collections, defined within an integration test plan aggregate, then delivers an integrated system ready for system testing as output.
  • Deployment Models – Deployment (Process) Models are collections of interrelated activities and transition interactions. Every system is unique making precise processes or procedures used for deployment activity difficult to define. Thus deployment is a general process customized according to specific requirements or characteristics.
  • Releases – Release management is a process for managing, planning, scheduling and controlling software builds through different stages and environments including test and deploy of each software release.
  • Training – Is teaching or skills and knowledge development related to specific sets of useful competencies. Training specifies goals for improvement of individual capability, capacity, productivity and performance. 
  • Workflow – Is a repeatable operations sequence (pattern) of industrial, administrative, or other processes in which a piece of work must transit from initiation to completion within and organization or system.
UML Business Processes Relationships
3 questions
Section 5: 05: UML Diagrams Relationships
05:34

Lecture 21 – UML Business Processes Relationships – System Context 

Discussion –  

System Context Diagram

System Context

  • Context (Scope)
  • Process (Workflow)
  • System

UML Use Case (Story)

  • Context (Scope)
  • Use Case
  • Actor (Role) 
  • Relationship

System Context Diagram

System context diagrams present systems with inputs and outputs to and from external entities and environments. System Context Diagrams represent all external entities interacting with a system at the center and details of interior structure, bounded by interacting systems, environments and activities. The system context diagram objective is focus of attention on external factors and events requiring consideration during development and documentation of complete requirements and constraints.

System context diagrams are used to collaborate and get project consensus on scope and are included in a project requirements specification. Specifications and diagrams must be written in plain stakeholder language then read and accepted by project stakeholders, so stakeholders can understand and accept items within the document.

Refer to the System Context Diagram. Diagrams document and include – 

System Context – Represents all external entities interacting with a system.

  • Context (Scope) – Context defines external entities interacting with project scope and why. External entities are external to project solution scope. Scope defines extent of the boundary project solution scope describes.
  • Process (Workflow) – Process is a collection of related, structured activities or tasks used to produce and deliver a specific service or product for a customer. A process or workflow is visualized as a flowchart of activity sequences with interleaving decision points. Workflow is a collection of repeatable business activity patterns enabled by systematic organization of resources transforming information, materials, and services in into delivered products and services as output.
  • System – Systems are contained within a boundary between external environments and internal system entities. Simplified systems models are used to define and envision internal system structure and behavior and impact or reaction with external and internal events.

UML Use Cases (Stories) are –

User stories describe what users do when using web applications focused on value or result from use of an application. Stories are written from the users point in the language of users. User stories are written using the format "As an [actor] I want [action] so that [achievement]." 

Use cases describe collections of interactions among systems and one or more actors including –  

  • Use case title – Clearly indicates user goals represented in the use case.
  • Use case goal – Result expected as a result of use case scenario execution 
  • Use case description – Describes actions or event steps defining interactions among an actor and a system to achieve a goal.
  • Actor/user (Role) – Actor(s) use a system to achieve goals. Use Cases document interactions among systems and actors to achieve a goal of a primary actor (person, place, or time).
  • Preconditions – Preconditions are contracts or guarantees established prior to use case initiation. Triggers initiate use case events when preconditions are met.
  • Main success scenario – Main success scenarios of use cases provide actors with contract or agreement of what a system does and will not do. Main success scenarios provide context for each specific user story line item execution requirement.
  • Alternate paths or extensions – Use case alternative paths or extension scenarios provide execution details for exception solutions. 
  • Post-conditions – Post-conditions are system conditions which are true just after execution of a use case or functional operation.

UML Use Case (Story/Scenario)

  • Context (Scope) – Context defines external entity scope interactions with and why within scope boundaries. External entities are external to scope of a project solution. Scope is the extent of project solution boundary described by scope.
  • Use Case – A use case is a collection defining behavior (actions or event steps interactions) with an actor role and system to achieve a goal. Actors are human, external systems, or time.
  • Actor (Role) – Actors represent roles of human users, external systems, or time interacting with a system (exchange of data or messages). Roles are collections of interdependent behaviors (actions or event steps) within a system environment. 
  • Relationship – Relationships are specific types of logical connections in UML diagrams such as – message, interaction, generalization, multiplicity, inheritance, realization/implementation, dependency, association, aggregation, composition.
07:31

Lecture 22 – Activity Diagram/Use Case Scenario – Diagram, Narrative …

11-Use Case Diagram Elements - Activity Diagram Use Case Scenario

Discussion –

Use Case Scenario – Diagram, Narrative …

•Use Case (UC) – Visual and narrative description of an action sequence (story – scenario) providing measurable value to an actor – “What NOT How” – drawn as horizontal ellipse in “Verb-Object” form.

•Actor – Person, place, thing, time, or external system playing a role in one or more interactions (associations) with a system – drawn as stick figure.

•Relationships – Relationship, association, message (event) existing whenever an actors interact with use cases. Indicated in use case diagrams by solid lines.  Associations are modeled as lines connecting use cases and actors one to another, with an optional arrowhead on one end of a connecting line. Arrowheads indicate directionality of initial relationship invocation or indicates use case primary actors. Arrowheads are often confused with data flow, but indicate only relationship or association.

•Include – One use case includes another – “… a Directed Relationship between two use cases, implying behavior of included use case is inserted into behavior of including use case. Useful for containing common behaviors from multiple use cases into a single description. The notation is a dashed arrow from including to the included use case, labeled "«include»“.

•Extend – One use case (extension) extends another. Behavior of extension use case is inserted into extended use case under some conditions. The notation is a dashed arrow from extension to extended use case, labeled "«extend»". Notes or constraints are associated with this relationship to illustrate conditions when behavior is executed. Modelers use «extend» relationships to indicate use cases are "optional" to base use case.

•Generalization – Given use case has common behaviors, requirements, constraints, and assumptions with more general use case.

•System Bounds (Domain, Context, Scope) – Dashed rectangle surrounding use cases. Called system bounds box. The box represents functionality within scope or context. Anything outside the box is out of scope (context).  System bounds boxes identify which use cases are delivered as component packaged services in each major release of a system. 

•Packages (optional) – UML constructs (containers) enabling modeling of elements (such as use cases) into deliverable groups. Packages are depicted as file folders used in UML diagrams, including use case, activity, sequence, class, or other diagrams. Use packages to organize large diagrams into smaller ones.Entity Control 

Boundary Patterns – Model-View-Controller (MVP) patterns based on use cases iteration requirements supporting identification of roles during use case steps for either input to or output from a transformation.

•Boundary (View) – Object interface with system actors for external services such as display screens and menus, UserInterface, DataBaseGateway, ServerProxy, Agreements, Proposals, Contracts ....

•Controls (Controller) – Objects mediate among boundaries and entities serving as glue among boundary elements and entity elements and implementing management of iteration logic among various elements of Use Cases and systems. Controls orchestrate commands (triggered event messages) execution coming from a boundary by interacting with entity and boundary objects. Controls often correspond to use cases and map to use case controllers in the design model.

Note: Many controllers are simple enough for implemention as entity or boundary class methods not requiring obect mediation.

•Entity (Model) – Entities are class objects representing system data: Customer, Product, Transaction, Cart, Documentation, Requirements, Specifications, Statement of Work ....

•Internal Dynamics – Are associated with each analysis model control as a statechart diagram representing a control's internal logic.

Communication Rules –

•Actors only talk with boundary objects.

•Boundary objects only talk with controllers and actors.

•Entity objects only talk with controllers.

•Controllers talk with boundary objects and entity objects, and with other controllers, but not with actors

What Does a Use Case Narrative (Story) Look Like? - Each Use Case Narrative consists of the following fields:

•Use Case Name – Unique Use Case identifier – Action Verb/Object pair – Use Cases are triggered by events that occur NOW!!! ... not the past nor future tense.

•Author – Who wrote the Use Case

•Last Update – Date use case was last updated

•Use Case Description – Describing a use case requires framing use case context and describing dialog between an actor or another use case and general scenario step sequence within scope of a given Use Case.

•Assumptions (Constraints) – Conditions must evaluate as true to use a specific use case action flow. Validating these conditions (business rules) is outside scope of a use case (contrast with preconditions, postconditions or guard conditions). For example, consider authentication or authorization – these functions are typically handled by standard security features such as when user provides valid card and password.

•Preconditions – Preconditions must evaluate as true to initialize a use case. Unlike assumptions, these conditions are validated by a use case before entry into an action sequence. If conditions are not true, actors or other use case are refused entry.

•Postconditions – Postconditions must evaluate as true when a use case ends. You may never know what comes after a use case ends, so you must guarantee the system is in a stable state when a use case ends. For example upon successful completion of ATM withdrawal.

•Use Case Dialog – Step-by-step description of dialog between a use case (system) and user (actor or other use case). Very often it is helpful to model this sequence of events using a flowchart, activity diagram, or sequence diagram just as you might model a communication protocol between two business units. For example when the system asks for a withdrawal amount.

•Use Case Termination – Occurs when the Use Case ends successfully.

Main Dialog:

•User selects an amount for withdrawal.

•ATM verifies amount entered is within predefined policy limits and is an amount divisible by defined denomination, for example, multiples of $20.00.

•If funds are available, the ATM gives the user requested money and prints a receipt.

Alternative Dialogs:

•If the amount fails at main step 2, an error message is displayed

•If funds not available, user gets an error message.

•System displays “cannot connect” to bank message.

•User cancels transaction.

Termination:

•System dispenses specified cash and prints a receipt.

•System displays a message amount entered is invalid.

•System displays a message could not connect with bank.

•User cancels transaction.

Postconditions:

•System prints final outcome on a receipt.

•User account updated.

•Transaction logged

•Upon error condition, ATM returns to initial state.

•Upon receiving Cancel, ATM returns to initial state

06:00

Lecture 23 – UML Business Processes Relationships – Activity Diagrams

Discussion – 

Use Case Activity Scenario – Diagram, Narrative …

  • Initial node – Solid circle indicates starting point of diagram. 
  • Activity – Represented by rounded rectangle. Activities are physical, such as “Audit Record”, or electronic, such as “Display Policy Coverage”. 
  • Flow/edge – Arrows on diagram. 
    • Fork – Black bar with one flow going into it and several leaving it. Denotes beginning of parallel (concurrent) activity.
    • Join – Black bar with several flows entering it and one leaving it. All flows going into join must reach join before processing continues. Denotes end of parallel processing (concurrency).
    • Condition – Text such as [Invalid Record] on a flow, defining guard (pre-condition) which must evaluate to true to traverse a node.
    • Decision (Business Rule) – Diamond with one flow entering and several leaving. Exiting flows include post-conditions although not indicated if obvious.
    • Merge (Business Rule) – Diamond with several flows entering and one leaving. Implication is one or more incoming flows must reach point until processing continues, based on guards (postconditions) on outgoing flow.
    • Swimlane (Domain, Context) – Optional vertical or horizontal partitions, also called swimlanes, indicating who/what (Actor–Role) is performing activities and decisions (either Actor or System) in a Use Case scenario. 
    • Flow Final – Solid circle within a circle indicates scenario stops at this point. 
    • Business Rule – Statement defining or constraining some aspect of business. Intended to assert business structure or to control or influence behavior of business. Business rules describe operations, definitions, persistence (data, structures), and constraints associated with Actors in achieving goals.


Activity Diagram

  • Initial Node(s)
  • Activities (Tasks)
  • Decisions/Merge (Loopbacks) – Forks/Joins
  • Swimlanes (Domain/Context/Scope)
  • Flow Final

Activity Diagram

Initial Node(s) – Solid circle indicates starting point of diagram. An initial node (control node) initiates flow in invoked activity having no incoming flows and one or more outgoing flows. There are zero or more initial nodes for an activity. 

Activities (Tasks) – Is behavior or action done to perform work needed to achieve goal or purpose. Tasks are activities required within defined time period or work deadline for achieving work-related goals. Tasks are collections of assignments with defined start and end dates or completion deadline. Task assignments begin task execution. Completion of all specific task assignments renders tasks complete. Tasks linked together create dependencies.

Decisions/Merge (Loopbacks) – Forks/Joins – 

Decision-making results in selection of vision, goal or course of action from among several possible alternatives. Decisions produce choices prompting action. 

  • Merge combines or causes combination of entities or processes forming single entities or processes. 
  • Loopbacks route signals, data streams, or flows back to source with no intentional processing or modification. 
  • Forks divide process flow into two or more separate paths.
  • Joins connect two or more process paths together into a single path

Swimlanes (Domain/Context/Scope) – Swimlanes visually show process or workflow sharing and responsibilities among multiple processes within activity diagrams or flowcharts visually distinguishing tasks, decision sharing, and responsibilities among sub-processes within a business process.

  • Domains have a common name for containing network collections and processes accessed and administered using common set of policies and rules.
  • Context is a collection of interrelated conditions in which events or statements occur within a specified environment. Context is a task and data collection within a process or thread allowing tasks given time interruption with task continuation from interruption point at an arbitrary future time. 
  • Project Scope is work accomplished or product, service, or result delivered having a specified collection of features and functions. Product Scope is features and functions characterizing a products, services, or results

Flow Final – Flow Final is system exit point, as opposed to Activity Final, which is completion of an Activity. 

What Do Activity Diagrams Look Like?

Activity diagrams graphically represent workflows of step-by-step activities (actions) supporting choice, iteration, and concurrency. UML Activity diagrams show control flow. Actions achieve goals by producing and delivering actual work. Decisions capture and clarify Business Rules and External Constraints mandating limits to delivered solutions

As you can see in the activity diagram, each set of activities is contained in a swimlane such as configure schedule, spider crawl or indexer, protected logon, user search, and other activity swimlanes as needed.

Each swimlane initiates with an initial node and may contain several connected activities or tasks. Each swimlane may also require decisions and/or loopbacks, merges, forks and/or joins to connect activities to other activities within each swimlane scenario. Upon completion of a swimlane activities set, sequence is terminal as a flow final. Business rules within each decision determine direction of flow from decisions and activities in the activity diagram. 

02:05

Lecture 24 – RUP UML Modeling Relationships – Sequence Demonstration 

Discussion – 

Sequence Diagrams

  • Use Case (Scope)
  • Class(es)
  • Role(s)
  • Action/Task
  • Message(s)
  • Swimlane(s)

Sequence Diagrams

Sequence diagrams are interaction diagrams illustrating how actor/roles, class/objects, messages, events, and process tasks interact during interaction sequence order.

  • Use Case (Scope) – Use cases define and list actions of event steps and depict interactions among actor/roles and a system to achieve goals. Actors are human, other external systems, or time. Use cases represent organization missions or stakeholder goals. Detailed requirements are captured and encapsulated as contractual statements. Use Case Scope is the extent of design used to control project requirements discussions
  • Class (es) – UML Class Diagrams describe system structure by depicting system classes, attributes, methods/operations and class/object relationships.
  • Role (s) – Roles are division of interaction responsibility among actors, processes and systems activated through event relationships.
  • Action-Task – An action is accomplishment of work in stages and steps through repetition over time. A task is assignment of work requiring completion within a set period of time.
  • Message(s) – Messages are synchronous or asynchronous event calls to instances from entities or actors. Synchronous message wait for message completion such as invoking a subroutine. Asynchronous messages continue processing an event call without awaiting response. Asynchronous calls are used in multithreaded applications and message-oriented middleware (MOM). 
  • Swimlane(s) – Swimlanes are visual elements used in process flow diagrams or flowcharts to visually define sub-process job sharing and responsibilities within a business process.
01:07

Lecture 25 – RUP UML Modeling Relationships – Class Demonstration 

Discussion – 

Class Diagrams

  • Class Name
  • Property(ies)
  • Method(s)/Task
  • Relationship(s)
  • Abbreviation(s)

Class Diagrams

  • Class Name – Class Name represents an extensible default class constructor for object creation and as an object type generated by class instantiation.
  • Property (ies) – (Ins, Snd, Udt, Del, Get, Set, Val, Ret) Properties (Attributes) special class members drawn intermediately between a data member field and a method. Properties are read and written as fields translated from get and set method calls.
  • Method(s)/Task – Class methods (tasks) operate as triggered event message calls on class objects. 
  • Relationship(s) – Relationships are associations among classifiers showing classifier instances as either linked or combined through aggregation. 
  • Abbreviation(s) – Abbreviation(s) are shortened or contracted word or from phrases used to represent a whole
00:45

Lecture 26 RUP UML Modeling Relationships – State Diagram Demonstration 

Discussion – 

State Diagrams

  • Initial State
  • State Name
  • Method/Event
  • Transition
  • Final State

State Diagrams

  • Initial State – Initial State condition upon entry to a state machine.
  • State Name – Name used as State condition label.
  • Method/Event – Class methods operate as triggered event message calls on class objects. State Events change from one state to another initiated by a triggering condition transition. 
  • Transition – Switching from one state to another is called state transition. An event causing a transition is the triggering event or trigger. 
  • Final State – Final State condition upon entry into state machine.
06:25

Lecture 27 RUP UML Modeling Relationships – Entity Relationship Demonstration 

Discussion – 

Entity Relationship Diagram (ERD) Data Models

Entity Relationship Diagram (ERD) are data models used to graphically illustrate entities and the relationships among data elements of an information system. An ERD models data used to show infrastructure frameworks of data entities. Entity Relationship Models (ER models) define and illustrate inter-related elements (types) of a specific knowledge domain. ER models are composed of entities of interest specifying relationships existing among instances of entity types. ER models are commonly designed to represent entities (class objects) a business must remember transact do business processes. Consequently, ER model are abstract data models defining data or information structure implemented as typically relational database.

Entity Relationship (ERD) Model Types

  • Conceptual Data Model – Conceptual schemas or conceptual data models map database concepts and relationships. Maps describe organization semantics representing assertions as related to database structure, contents and relationships.
  • Logical Data Model – Logical Data Model (LDM) define and illustrates data architecture data model type showing detailed representation of technology agnostic organizational data described in business language.
  • Physical Data Model – Physical Data Models represent data design accounting facilities and constraints of database management systems.

ERD Structure – Entity Relationship Diagrams (ERD) graphical represent information system relationships among people, objects, places, concepts or events used within a system. ERDs define and model business processes used as a relational database template.

  • Fields – Fields represent attributes of entities in an ERD Data Schema.
  • Key Fields – Key Fields are Primary or Foreign key fields. Primary keys are an attribute or attributes uniquely identifying one and only one entity instance. Primary key are foreign keys in entity types related as a one-to-one or one-to-many relationship.
  • Types – Types may show type of data associated with a corresponding table field. Types also show entity types describing entity structure.
  • Tables – Tables represent entities in an ERD Data Schema
  • Entity Type – Entity type is a baseline building block describing data structure within an Entity Data Model (EDM). In conceptual models, entity type provide the structure of concepts such as customers and orders. Entity types are templates for entity type instances or class objects.
  • Entity – Entities are independent, separate, or self-contained uniquely identifiable class objects. Entities are tables in relational databases in which each row of the table represents an entity instance.
  • Relationship Type – Relationships show association between two tables. Relationship types are association, linkage, or connection among entities of a business.  Relationship types are are-directional, significant associations among entities. Each relationship is named, optionality (optional or mandatory), and degree (how many or count), and degree of relationship confirming relationship validity. 
  • Attributes – Attributes are properties or descriptors of entities such as Customer Name, Address, or City. Collectively, attributes define entities. Data attributes are defined as a result from customer requirements. 
  • Attribute Type – Attribute types specify attribute syntax and how attributes types are compared and sorted. Attribute types form a class hierarchy. Attributes are characteristics of entities, many-to-many relationships, or a one-to-one relationships. Multivalued attributes can have more than one value. Derived attributes are calculated from related attribute values.
  • Attribute for Entity – Attributes of entities are properties describes an entity. Relationship are associations describing interactions among entities. ERD cardinality is the instance count an entity must be associated with each instance of other entities. There is one-to-one, one-to-many, or many-to-many cardinal relationships.
  • Attribute for Relationship – Attributes are fundamental building block of dimensions. Dimension contains an attributes set organized as attribute relationships. Each dimension table contains attribute relationships for a table's key attribute to other attributes within a table. 

  • Association – Shows aggregation relationship between two entities. Encompasses any logical connection or relationship among classes.
  • Dependency – Dependency is an instance of one entity cannot exist without existence of a related entity. 
  • Aggregation – Aggregation cardinality counts unique field values, enabling search for unique class objects. Aggregation is formation of a class resulting from one class aggregated or built as a collection. This is accomplished by creating unique buckets for each specified field value as generated by a script. 
  • Composition – Composition is similar to aggregation relationships with the contained class purpose of dependence on the life cycle of the container class that is the contained class is destroyed when the container class is destroyed. 
  • Generalization – Generalization are entities as subtypes of general entities as represented by an "is a" relationship.
  • Multiplicity – Multiplicity is an active logical cardinality association of a class relationship depicted. 
  • Realization – Realization denotes implementation of functionality defined in one class by another class.

Cardinality ERD

  • One
  • One & Only One
  • Many
  • Zero or One
  • One or Many
  • Zero or Many
  • Key (Primary or Foreign)


07:15

Lecture 28 RUP UML Modeling Relationships – Sequence Timing Demonstration 

Discussion – 

Sequence Timing Diagram

Timing diagrams sequence diagrams with the axis reversed in timing diagrams from and sequence diagrams indicating lifeline time in timing diagrams show compartments arranged vertically. Timing Diagrams are used to show interactions during sequences when the primary diagram purpose is to illustrate relationships and impact of time. Timing diagrams show changing conditions along linear time axis timelines. Timing diagrams illustrate behavior of individual class object interactions focused event occurrence times causing changes in conditions relative to timelines.

Sequence Diagrams 

Sequence Diagrams are the most common Interaction Diagrams illustrating realization of a use case scenario when actors and objects exchange messages with objects among multiple Lifelines (refer to Sequence Timing Diagram on this page and Lecture 24 - RUP UML Modeling Relationships – Sequence Demonstration). 

Sequence Timing Diagram Attributes

  • Participants – Actors (Roles), Class Objects, Database Boundaries, Entities, Controls. Objects. The horizontal axis displays objects involved interactions. Conventionally, objects involved are noted from left to right according to involvement in the messaging sequence. Horizontal axis objects appear no particular order. Object can be denoted by associated MVP Entity Control Boundary Icon (refer to description for each icon).
  • Constraints – Constraints are restricted conditions expressed in natural or machine readable language declaring related semantics for an element such as Name, Expression (Condition must be true for a constraint satisfaction.), Document (Description).
  • Messages – Messages are synchronous or asynchronous event calls to instances from entities or actors. Synchronous message wait for message completion such as invoking a subroutine. Asynchronous messages continue processing an event call without awaiting response. Asynchronous calls are used in multithreaded applications and message-oriented middleware (MOM). Messages (also signals or event triggers) are shown in sequence diagrams arrows from one participants (message call) passing a message to another participant (message receipt). A Message (event stimulus trigger) is also shown an arrow leaving a sender (object or focus) entering the top of a focus of control (execution occurrence) of a message on a receiving object lifeline.
  • Focus of Control (Interaction Occurrences) – Focus of control is an execution (interaction) occurrence, shown as rectangles along Lifelines, represents time period when an object performs an operation. The tops and bottoms of rectangles are aligned with initiation and completion time of an operation respectively.
  • Note – A note or comment enables attachment of remarks to sequence elements (comments, time constraints, duration constraints). Comments provide no mandated action, but provide useful information to stakeholders.
  • States – States are pre and post conditions noted on sequence Lifelines.
  • Events – Events are any interaction point along a sequence when action occurs.
  • Durations – Activation durations of time among messages shown with Proofreading Marks.
  • Timing Framework – An interaction unit of behavior focusing on observable exchange of information among connectable elements of the timing sequence. The vertical axis represents time progressing vertically in ordered sequence down the page with messages and durations noted as appropriate. Vertical interaction space is not related to duration time for interactions.
  • Lifelines – Sequence diagrams organize participants with a corresponding lifeline. Each vertical dotted line within a timing sequence is a Lifeline representing time of object existence. Lifelines extend vertically downward participants in the sequence.
  • Action-Tasks – An action is accomplishment of work in stages and steps through repetition over time. A task is assignment of work requiring completion within a set period of time.
  • Swimlane(s) – Swimlanes are horizontal visual elements used in process flow diagrams or flowcharts to visually define sub-process job sharing and responsibilities within a business process.

Message Type Notations

  • Synchronous – Messages among active objects indicating wait semantics in which a sending participant waits for message handling before continuing typically as a method call.
  • Asynchronous – Asynchronous flow of control provides no explicit return message sent to a calling participant. Asynchronous messages among objects require no-wait so the sending participant does not wait for a reply message before continuing enabling concurrent object execution.
  • Reply – Return message from another message.
  • Create – Message results in creation of a new object. 
  • Lost – Lost messages occur when sender of a message is known with no message reception. 
  • Found – Found messages indicate a message receiver is known, but message sender is not.

Entity Control Boundary Patterns – Model-View-Controller (MVP) patterns based on use cases iteration requirements supporting identification of roles during use case steps for either input to or output from a transformation.

  • Boundary (View) – Object interface with system actors for external services such as display screens and menus, UserInterface, DataBaseGateway, ServerProxy, Agreements, Proposals, Contracts ....
  • Controls (Controller) – Objects mediate among boundaries and entities serving as glue among boundary elements and entity elements and implementing management of iteration logic among various elements of Use Cases and systems. Controls orchestrate commands (triggered event messages) execution coming from a boundary by interacting with entity and boundary objects. Controls often correspond to use cases and map to use case controllers in the design model.

Note: Many controllers are simple enough for implemention as entity or boundary class methods not requiring obect mediation.

  • Entity (Model) – Entities are class objects representing system data: Customer, Product, Transaction, Cart, Documentation, Requirements, Specifications, Statement of Work ....
  • Internal Dynamics – Are associated with each analysis model control as a statechart diagram representing a control's internal logic.

Communication Rules – 

  • Actors only talk with boundary objects.
  • Boundary objects only talk with controllers and actors.
  • Entity objects only talk with controllers.
  • Controllers talk with boundary objects and entity objects, and with other controllers, but not with actor
UML Modeling and Support Tools Stories & Requirements Management
3 questions
Section 6: 06 - Course Recap – Conclusion … What We Accomplished in this Course?
03:03

Section 6: Course Recap – Conclusion … What We Accomplished in this Course?

Discussion – 

In this Course We Learned –  

  • Decompose Stories
  • Decision Information
  • Identify System Behaviiors, Actors, ...
  • Document Requirements ...
  • Capture & ID Business Rules ...
  • Develop Measurable Requirements ...

Course Goals

  • Provide functional requirements capturing tool. To answer this question, we’ll first discuss “What’s a Requirement”? …
  • Decompose stories into requirement statements to identify Use Cases representing Functional and Non-Functional Requirements supported in a Work Breakdown Structure.
  • Give those responsible for designing, building, and/or buying solutions the kind of information they need to make the right decisions for the business.
  • Identify system behaviors, actors, pre-conditions, post-conditions, relationships and constraints based on well-defined use cases and user stories used to define functional and non-functional requirements.
  • Document and manage Business system, Stakeholder, Functional, Non-Functional, and data requirements.
  • Capture and clarify Business Rules and External Constraints that mandate limits to delivered solutions.
  • Develop measurable Solution Requirements facilitating End-User Acceptance Testing and delivery.

Course Recap - Conclusion

Lecture 29 – Lessons Learned - Conclusion…

Congratulations! You’ve made it! … You’ve completed all Course Goals …

What we learned – 

  • Decompose Stories
  • Decision Information
  • Identify System Behaviiors, Actors, ...
  • Document Requirements ...
  • Capture & ID Business Rules ...
  • Develop Measurable Requirements ...

Why are workflow models needed? …

Software is Magic from the Mind …

Software is Magic from the Mind … it’s the Opposable Thumb for technical entrepreneurship, innovation & architecture. A working model using mission-driven measures in a team approach enables focus on effective solutions … the result? Workflow mapping is the 1st step toward enhanced Software as Magic using the Opposable Thumb of your Mind. 

Thank you and congratulations for taking this opportunity for yourself to expand your skills and knowledge. Thank you for your decision to complete this course successfully.

And, please, if you have any questions about any part of this training or any related questions to this course or Udemy please ask. You have my promise to find you an answer. 

If you found my course useful, please consider leaving a review and rating. Your review is much appreciated. You can go directly to the review page for this course then click and enter your review and rating.

Criteria for Writing a Review and Rating

Please remember my promise to you, if you have any questions about any part of this training or any related questions about this course or Udemy please don’t hesitate to ask using Udemy’s Instructor Messaging service to contact me.

Have a Great day and thank you so much for being a student in my online classroom. If you would like to receive inspirations, useful articles, free tutorials, observations and more, please – 

Thank You and Best Regards,
Chuck Morrison, MBA, PMP

© 2015 Chuck Morrison, All Rights Reserved

Article

Lecture 30 – Glossary …

Definitions of terms used in this course …

Term

Definition

Activity

Condition in which things are happening or being done.

Activity Diagram

Graphical representation of workflows step-by-step activities and actions with support for choice, iteration and concurrency. In the Unified Modeling Language, activity diagrams are intended to model both computational and organizational processes (i.e. workflows).

Analysis

Detailed examination (decomposition) of structural elements (components) typically as a basis for discussion or interpretation

Architecture

Art or practice of designing and implementing business and information systems

Cause

Person or thing giving rise to action, phenomenon, or condition.

Cause and Effect

Relationship between actions or events in which one or more are the result of another or others.

Chaotic

State of complete confusion and disorder

Class Diagram

Illustration of the relationships and source code dependencies among classes in the Unified Modeling Language (UML)

Collaborate

Work jointly on an activity, especially to produce or create something

Condition

State of something, especially with regard to appearance, quality, or working order

Context

Circumstances forming event settings, statements, or ideas in terms which it can be fully understood and assessed.

Context Diagram

Context diagrams depict the environment in which a system or product exists.  A context diagram provides the name of the system or product of interest within a system boundary. The context diagram includes external entities such as user classes, actors (roles), organizations, other software systems or hardware devices interfacing with the system.

Continuous Improvement

Ongoing effort to improve products, services or processes. These Efforts seek “incremental” improvement over time or “breakthrough” improvement all at once

Control Chart

A control chart is a graph used to study how a process changes over time. Data is plotted in time order with a center line for average, upper line for the upper control limit and a lower line for the lower control limit

Corrective Action 

Corrective and preventive action (CAPA, also called corrective action / preventive action, or simply corrective action) is improvements to an organization's processes taken to eliminate causes of non-conformities or other undesirable situations.

Correlation

Quantity measuring the extent of interdependence of variable quantities

Decision

Conclusion or resolution reached after consideration of problems or issues

Decision Diagram (Tree)

A decision diagram is a decision support tool which uses a tree-like graph or model of decisions and their possible consequences, including chance event outcomes, resource costs, and utility. It is a way to display a decision-making algorithm.

Decomposition

Separate into constituent functions or components such as in a work-breakdown-structure. Used simplify functionality of systems

Diagram

Simplified drawing showing the appearance, structure, or activities of a system ... schematic representation.

Effect

Change result or consequence of an action or other cause

Event

Occurrence, especially one of some importance. Outcome, issue, or result of anything:

Experiment

Scientific procedure undertaken to make a discovery, test a hypothesis, or demonstrate a known fact

Exploratory

Relating to or involving exploration or investigation

Failure

Omission of expected or required action

Failure Analysis

Process of collecting and analyzing data to determine the cause of a failure. Important discipline in various branches of business and technology in which a vital tool used in the development and improvement of systems and products.

Findings

Conclusion(s) reached after examination or investigation resulting in statement or document containing an authoritative decision or conclusion

Flowchart

Diagram representing an algorithm, workflow or process, showing the steps as boxes of various kinds, and their sequence by connecting them with arrows.

Framework

Basic structure underlying a system, concept, or text.

Function

Relationship or expression involving one or more variables based on system or product requirements

Guideline

General rule, principle, or advice.

Histogram

Diagram consisting of rectangles whose area is proportional to the frequency of a variable and whose width is equal to the class interval.

Holistic

Comprehension of parts of a whole as intimately interconnected and explicable only by reference to the whole

Hypothesis

Supposition or proposed explanation provided on the basis of limited evidence as a starting point for further investigation.

Incident

Event or occurrence

Interpretive

Pertaining to, or serving to explain.

Isolated / Specific

Separated from other persons or things; individual; alone; solitary

Issue

Action of supplying or distributing an item for use, sale, or official purpose

Kepner-Tregoe

Refers to a process of weighing alternatives in which a person lists and assigns a numerical weight to a series of values (noting that some may be absolute requirements), gives each alternative a numerical rating according to each value, and computes a numerical score for the alternative (as the dot product). The technique allows that an absurd result may indicate an error in the weight and the rating, to be solved by adjusting and iterating

Limited

Restricted in size, amount, or extent, few, small, or short.

Listen

Share one's attention

Logical Troubleshooting

 Form of problem solving, often applied to repair failed products or processes; logical, systematic search for the source of a problem so that it can be solved, and so the product or process can be made operational again

Measure

Ascertain the size, amount, or degree of (something) by using an instrument or device marked in standard units or by comparing it with an object of known size.

Method

Procedure or guideline for accomplishing or approaching something, especially a systematic or established one

Methodology

System of methods used in a particular area of study or activity.

Metric

Standard of measurement 

Milestone

Action or event marking a significant change or stage (increment/phase) in development

Model

System or thing used as an example or framework to follow or imitate

Non-Structured

Not manifesting a clearly defined structure or organization.

Numeric

Denoting a number or a system of numbers

Objective

Judgment not influenced by personal feelings or opinions in considering and representing facts.

Operations

Active process; discharge of a function.

Opportunity

Set of circumstances making something possible to do

Perception

Manner of regarding, understanding, or interpreting something; mental impression

Policy

Course or principle of action adopted or proposed by a government, party, business, or individual organization.

Preventive Action

Preventive action is a change implemented addressing weakness in a system not yet responsible for causing nonconforming product or service.

Preventive Maintenance

Care and servicing for the purpose of maintaining systems and facilities in satisfactory operating condition. Provides systematic (scheduled) inspection, detection, and correction of failures either before they occur develop into major defects.

Problem

Matter or situation regarded as unwelcome or harmful and needing to be dealt with and overcome

Procedure

Series of actions conducted in a specified order or manner

Process

Sequence of actions or steps taken in order to achieve a specified requirement (expectation).

Program

Planned series of events, items, or performances.

Project

 Individual or collaborative enterprise carefully planned and designed to achieve a particular set of objectives within a specified timeframe and budget

Qualitative

Measuring, or measured by the quality of something other than quantity

Quantitative

Measuring, or measured by the quantity of something rather than its quality

Requirement

Compulsory; a necessary condition or result

Resource

Supply of money, materials, staff, and other assets that can be drawn on by a person or organization in order to function effectively

Risk

Exposure or vulnerability to chance of injury or loss; a hazard or dangerous chance

Root Cause 

Used to describe the depth in the causal chain where an intervention could reasonably be implemented to improve performance or prevent an undesirable outcome

Root Cause Analysis (RCA)

Method of problem solving used for identifying the root causes of faults or problems.

Run Chart

Also known, as a run-sequence plot is a graph that displays observed data in a time sequence. Often, the data displayed represent some aspect of the output or performance of a manufacturing or other business process.

Scattergram

Graph in which the values of two variables are plotted along two axes, the pattern of the resulting points revealing any correlation present

Schematic

Visual representation of the main parts of something usually in the form of a simple drawing or diagram

Scope

Extent of an area or subject matter something deals with or to which it is relevant

Sequence Diagram

Interaction diagram visualizing how processes operate with one another and in what order? 

Situation

Set of circumstances and relationships

Solution

Means of solving a problem or dealing with a difficult situation or failure.

Stakeholder

Person with an interest or concern in something, especially a business

Statistics

Practice or science of collecting and analyzing numerical data in large quantities, especially for the purpose of inferring proportions in a whole from those in a representative sample.

Structured

Arrange according to a plan; pattern or organization

Subject Matter Expert (SME)

A subject-matter expert (SME) or domain expert is a person who is an authority in a particular area or topic.

Symptom

Feature regarded as indicating a condition of failure particularly such a feature that is apparent to a stakeholder

Task

Work to be done or undertaken

Template

Pattern used for products, processes and systems

Test

Procedure intended to establish the quality, performance, or reliability of something, especially before it is taken into widespread use

Testing

Testing is discovery of how well something works

Text / Verbal

Written or printed work, regarded in terms of its content rather than its physical form also spoken words

Theory

Supposition or system of ideas intended to explain something, especially one based on general principles independent of the thing to be explained

Troubleshooting Aid

Documentation or artifact used to support problem solving, often applied to repair failed products or processes

Unique (Important)

Only one of its kind; unlike anything else and of great significance or value

Unique (Outliers)

Only one of its kind; unlike anything else person or thing situated away or detached from the main body or system … beyond the 6 sigma range of probability

Use Case

Related interactions between a user (or more generally, an “actor”) and a system enabling the user to achieve a goal. Use cases describe system behavior as it responds to a series of related requests from an actor.

Article

Lecture 31 – For Further Reading …

OO UML developed by “The 3 Amigos” Grady Booch, Ivar Jacobson and James Rumbaugh at Rational Software during 1994–95 with further development led by them through 1996. … Rational Software transferred to IBM … OO UML accepted by OMG & ISO

References:

Students Who Viewed This Course Also Viewed

  • Loading
  • Loading
  • Loading

Instructor Biography

Chuck Morrison, Program/Project Manager & Business/IT Architect (MBA, PMP)

“A working model using mission-driven measures in a team approach enables focus on profitable customer-driven solutions."

With extensive Program Management and Business Architecture experience in Silicon Valley California it's been my good fortune and opportunity to experience working with many Fortune 500 companies. Workflow modeling is my expertise, joy and passion. As a seasoned professional my enjoyment is using and sharing the skills and knowledge with others through teaching and writing. Chuck has also authored and published other Udemy courses, Amazon eBooks, Linked SlideShare, and YouTube videos.

PMI PMP certified: Principal Strategist, Architect, and Leader with MBA and extensive experience in business and technology consulting, planning, designing, mentoring, negotiating, and delivering project, product, program, and process solutions. Successful track record planning, managing, and leading small to multi-site, concurrent, complex cross-functional projects and portfolios requiring business process engineering, Internet and information technology, quality management, instrumentation, and training.

Specialties: -Programs/Projects Management (PMI PMP): Program, Product, Project, and Process (SDLC, Agile, PMBOK, DMAIC, RUP, ITIL, InfoSec, NetSec, CISSP)-Business/Technical Process/Systems Modeling, Analysis, and Design (UML, OOA/D, BRD, MRD, FRD, HLD, ERD)-Web Portal Planning, Design, Documentation, and QA (Web 2.0, HTML, TCP/IP, HTTP, B2B, B2C)-Client/Team-Focused Consultant, Mentor, and Communicator-Inventory/Supply Chain Modeling/Management (APICS CPIM)

Thank You and Best Regards,
Chuck Morrison, MBA, PMP, CPIM, WWISA

Ready to start learning?
Take This Course