«Sharam Hekmat PragSoft Corporation Contents 1. INTRODUCTION 1.1 PURPOSE 1.2 SCOPE 1.3 SOFTWARE TOOL 1.4 GLOSSARY OF TERMS 2. ...»
1.3 SOFTWARE TOOL
1.4 GLOSSARY OF TERMS
2. REFERENCE MODELS
2.1 PROCESS REFERENCE MODELS
2.1.1 Process Domains Reference Model
2.1.2 Process Reference Model
2.1.3 Modelling Reference Model
2.2 LIFECYCLE REFERENCE MODELS
2.2.1 Gateways Reference Model
2.2.2 Linear Lifecycle Model
2.2.3 Proof-of-Concept Lifecycle Model
2.2.4 CBD Lifecycle Model
2.2.5 DSDM Lifecycle Model
2.2.6 Small Change Lifecycle Model
2.3 ARCHITECTURAL REFERENCE MODELS
2.3.1 Architectural Domains Reference Model
2.3.2 Layered Architecture Reference Model
3. BUSINESS MODELLING
3.1 INTRODUCTION TO BUSINESS PROCESSES
3.1.1 What Constitutes a Business Process?
3.1.2 Business Process Improvement
3.1.3 Business Process Re-engineering (BPR)
3.2 BUSINESS MODELLING CONCEPTS
3.2.1 Abstraction versus Instance
3.2.2 Business Process Definition
3.2.3 Activity Definition
3.2.4 Action Definition
4. Create New Tax Payer Record
3.3 USE-CASE MODELLING
4. APPLICATION MODELLING
4.1 BUSINESS OBJECTS
4.1.1 Class Diagrams
4.2.1 Collaboration Diagrams
4.2.2 Sequence Diagrams
4.2.3 Completed Business Model
www.pragsoft.com 2 UML Process
4.3 USER INTERFACE MODELS
5. SYSTEM MODELLING
5.1 MULTI-TIER ARCHITECTURES
5.2 FRONT-END MODELS
5.2.1 Screen Specifications
5.2.3 Boundary Objects
5.3 MIDDLE-TIER MODELS
5.3.1 Entity Objects
5.3.2 Control Objects
5.3.3 Boundary Objects
5.3.4 Long Transactions
5.4 BACK-END MODELS
5.4.1 Data Models
5.4.2 Data Access Objects
6.1.1 Testing Process
6.1.2 Testing Approaches
6.1.3 Testing Techniques
6.1.4 Testing Stages
6.1.5 Regression Testing
6.2 TEST PLANNING
6.2.1 Test Strategy
6.2.2 Test Plan
6.2.3 Test Environment
6.2.4 Automated Testing
6.3 SYSTEM TESTING
6.3.1 Function Testing
6.3.2 Exception Testing
6.3.3 Stress Testing
6.3.4 Volume Testing
6.3.5 Scalability Testing
6.3.6 Availability Testing
6.3.7 Usability Testing
6.3.8 Documentation Testing
6.3.9 Installation Testing
6.3.10 Migration Testing
6.3.11 Coexistence Testing
6.4 TEST CASE DESIGN
6.4.1 Presentation Oriented Test Case Design
6.4.2 Workflow Oriented Test Case Design
6.4.3 Business Object Oriented Test Case Design
6.4.4 Data Oriented Test Case Design
1.1 Purpose UMLProcess is a defined process for developing software systems using object technology. The purpose of this document is to define the UMLProcess at a level that is suitable for practitioners who have had no prior exposure to a similar process.
1.2 Scope This document is intended to be a concise guide to the processes it covers, rather than giving a detailed description of each process. By focusing on the key concepts (and deferring the practical details to workshops and mentoring sessions), we can maximise the usefulness of the handbook as a learning tool.
1.3 Software Tool If you plan to implement the UMLProcess in your organisation, we recommend that you use a UML modelling tool to formalise your modelling activities. PragSoft provides two very popular tools for
• UMLStudio allows you to create UML models, generate code from them, and reverse engineering UML models from code.
• UMLServer allows you to deploy UMLStudio in a collaborative environment.
Both tools can be downloaded from www.pragsoft.com.
UML Process 5 Copyright © 2005 PragSoft
2. Reference Models The processes that underpin the development of modern information systems are varied and complex. This section provides a number of reference models to help manage this complexity,
covering three broad areas of:
• Architecture The reference models provide a common understanding, so that when we later talk, for example, of production, business objects, or Gate 2, the intent is clear.
2.1 Process Reference Models A process is a well-defined collection of activities, each undertaken by possibly a different participant, which takes one or more inputs and produces one or more outputs. Every manufacturing or service industry uses a set of inter-related processes for its operation. The quality of the design of these processes and the quality of their implementation determines the overall quality of the organisation. In other words, to improve an organisation, one needs to improve its underlying processes.
2.1.1 Process Domains Reference Model At the highest level, the processes that underpin the development and operation of information solutions can be divided into 5 domains, as illustrated below.
The development domain is concerned with processes that directly contribute to the development
of the solution. These include:
• Business modelling
• Application modelling
• Architectural design www.pragsoft.com 6 UML Process
• Detailed design
• Coding and testing
• System testing
• Problem reporting and fixing The production domain is concerned with processes that directly affect the evolution of the system
after it is fully developed. These include:
• Detailed design
• Coding and testing
• System testing
• Acceptance testing
• Problem reporting and fixing The live domain is concerned with processes that directly affect the operation of the solution in a
live environment. These include:
• Release management
• Performance monitoring
• Help desk
• Problem reporting and fixing The coordination domain is concerned with processes that regulate and manage the successive
progression of the solution through its various stages. These include:
• Project management
• Quality management
• Change management The facilitation domain is concerned with processes that indirectly contribute to development, production, and live processes by way of providing guidance and/or administrative assistance. These
• Configuration management
• Training and mentoring
• Quality reviews
• Metrics collection and reporting 2.1.2 Process Reference Model Each process is described by a set of process elements, as illustrated below.
Checklists Templates Examples The guide describes the process, its inputs, constituent parts, outputs, and how each participant contributes to it. The checklists provide a means of verifying that the process parts have been completed to satisfaction and meet the necessary criteria. The templates provide a standard format and structure for the deliverables (outputs) produced by the process. The examples serve as a learning aid and illustrate to the process participants sample deliverables produced by the real-life application of the process.
2.1.3 Modelling Reference Model A different way of looking at development processes is to view them as an iteration of modelling exercises. Each modelling exercise takes one or more earlier models and produces a new, more enriched model by making additional design decisions. This results in a progression from abstract (requirements) to detailed (working solution). This approach, combined with object-oriented modelling, has the distinct advantage of producing representations that can be verified through logical reasoning, testing, or even simulation. For example, a business process map can be tested by mentally passing imaginary cases through it that exercise its different logical paths to see if it copes with the possibilities and produces the required output.
There are three broad types of modelling, as illustrated below.
Business modelling is concerned with what the business does. This is before using information systems to automate aspects of the business. This may appear as redundant if the business already has systems in place. But this is exactly the point. Technologists often forget that information systems are not an end to themselves, but a means for serving the business (i.e., to support the business processes they are aimed at). If it is not clear what the business does, then it will be equally unclear how systems may be able to support it.
The business model is described in purely business terms. One of its key objectives is to establish a common, unambiguous understanding between the business users and the technologists who will ultimately build appropriate system solutions for it. The importance of this baseline cannot be overstated. Its quality and completeness will, more than any other model, influence the success of the final solution.
Business modelling produces the following artefacts:
• End-to-end Business Processes
• Business Process Maps
• Activity Maps
• Action Narratives
• Use-cases Application modelling is concerned with how systems support the business. Having established a business model that describes what the business does, we are then in a position to come up with an application solution that addresses the business needs. This is essentially an external view of the solution and shows how the users interact with the application, its look and feel, and the business abstractions (objects) that are represented by the application. Application modelling is where functional requirements are addressed.
The application model does not assume any specific implementation technology and is primarily described in non-technological terms. It should, therefore, be reasonably understandable by the business users.
System modelling is concerned with how systems are realised using technology. System modelling is largely a technological activity that attempts to translate the application model into a concrete, executable system. System modelling has to deal with artificial details that are not an inherent part of the application model, but a by-product of using specific technologies. For example, it has to deal with specific programming constructs, middleware services, data models, and so on. In other words, it produces an internal view of the solution, showing how its different parts interact in order to support the external, application view. System modelling is where the non-functional requirements (e.g., platform, performance, throughput, scalability, maintainability) are addressed.
The system model is expressed in technical terms and is for the internal use of the technologists who work on it. It is inappropriate reading material for business users.
System modelling produces the following artefacts:
• User Interface Models:
• Screen Specifications
• Data Entry Validation Rules
• Front-end Components
• Application Server Components
• Business Object Server Components
• Data Access Components