UML Application Guideline for Offshore Development

Ver. 3.0

August 2010

NPO UMTP
Offshore Software Development Working Group

Copyright ©

NPO UMTP 2007-2010 All rights reserved

Contents
1．

2．

3．

Purpose……………………………………………………………………………………

(1) How this guideline is positioned in the entire offshore development guideline …

1(2) What this guideline covers ………………………………………………………………

2……………………………………………….

7………………………………………………………..

7… ……………………………………………

8…………………………………………………………………

11………………………………………………………………………………….

12……………………………………………………………………………

12…………………………………………………..

15……………….

17

…………

29

..………………………………….

32[Point 03: It does not have to be UML at all times] ……………………………………

33……………………

35[Point 05: Non-Functional Requirement Definition] ………………………………………

36[Point 06: Understanding Business Process by Analysis Models] .…………………..

37…………………………………………………………

40[Point 08: Creating Naming Rules]…….……………………………………………….

41[Point 09: Creating Modeling Rules]….……………………………………………..

42[Point10: Explicit Common Function]…...…..………..…..………………………….

43..…………………………………………………………..

44………………………………..

45……………………………………………………………….

46

……………

47

………………………………………….

49[Point 16: Clarifying Areas of Which Specifications Are Not Determined]……………

50

Offshore Development Issues and Solutions(1)

Overview of the questionnaire(2)Extract of the questionnaire response(3)

Voices and Comments

UML Modeling

3.1 UML Features

3.2 Required UML Modeling skill level
4．

1

UML Application Scope and Development Know-how （Hints & Tips）[Point 01: Define Specific Scope of Work, Roles and Responsibilities][Point 02: Determining UML Diagram to be Used][Point 04: Participate Early Development Process (optional) ][Point 07: Creating Glossaries][Point 11: Architecture Model][Point 12: Create Output of Architecture Description][Point 13: Using Patterns][Point 14: Level of Description of Specification, Format Specification][Point 15: Creating Detail Design Guideline]………………...……….

51………………………………...

52……………………………………………………

53………..………………………..

55……………………………………….

56[Point 22: Using “Code Generation Feature” in the Tool for Production (optional)] ..

61[Supplement: Unique Nature of Systems Development in Japan] …………………….

62

Appendix A Explanation of the examples used in the Points ………………………

64……………..…………………………………………

71[Point 17: Reviewing Output by the Offshore Partner][Point 18: Repeating Check by the Owner (Japan)][Point 19: Validation and Verification][Point 20: Reviewing Detail Design by the Model][Point 21: Consistency between UML Diagrams]

Appendix B Sample outcomes1. Purpose(1) How this guideline is positioned in the entire offshoredevelopment guideline
The offshore system development uses normal development cycles including requirement analysis, design, implementation, test and development methodology with each technical process, project management, budget planning and quality management technique the same as non-offshore local development. This guideline focuses on“offshore software development using UML” and demonstrates hints and tips based on practice and experience on
offshore development and UML development.

The following explains how this guideline is positioned in the entire offshore systems development.
Offshore systems development requires the following factors.
(1) Systems Development Methodology (Development processes, development procedures anddevelopment techniques)(2) Project Management (Management by such documents as project management documents)(3) Quality Management (Management by such documents as quality management documents)(4) Text books of offshore systems development business (Case study books of offshore systems
development available in book stores, mail magazines of offshore systems development,
unique expertise and know-how of the companies involved, and so on)(5) Agreements with the offshore partners (Statement of works of each party, project schedules ,deliverable and prices)

Systems develop ment projects typically require (1) through (3) above. Offshore system sdevelopments further require (4) and (5). Participating companies need to prepare (1) through (5)prior to the project start. This guideline i s to describe some common development options ,development procedures and relevant artifacts by primarily addressing to the modeling technology
and is to supplement (1) through (5) as proven know-how. This document is written based on
the assumption that participating companies has prepared all (1) through (5) , and is intended to
improve performance of offshore systems development by using it as supplemental information.
Accordingly, this guideline does not address such company specific issues as scope of work,
work procedures and so forth.

This guideline(4) Text books of offshore systems development/ (5) Agreement with offshore partners(2) Project Management / (3) Quality Management(1) Development Methodologies

1(2) What this guideline covers
This guideline covers the following areas.

“Systems Development”, in broad sense, can be categorized to software engineering using “UML2” and tosystem engineering using “SysML”. This guideline describes output of consideration focused on software engineering.

Software Engineering

System Engineering

UML 2

SysML

 Class diagram Package diagram

State machine diagram Communication diagram
 Object diagramSequence diagram
Use case diagram Component diagram

Activity diagram Composite structure diagram Deployment diagram
 Interaction overview diagram Timing diagram

2

Requirement diagram
Block definition diagram
Internal block diagram
Package diagram
Parametric diagram

Here are some details of Software Engineering.

Software engineering includes;
・

Development technique elements on each process development cycle such as requirement – design – test maintenance・

Product supporting elements such as tools, development methods, and configuring procedures・Project maintenance elements such as development processes and budget planning・

Quality maintenance elements such as specification guide and program manuals

Software for engineering includes 1) embedded system software and 2) business application software. The business application has 2a) limited customized design/implementation case within the product specification by usinga software package and 2b) large custom development case with new design/implementation although it is difficult
to have application package.

This guideline gives hints and tips about each of the process development cycle elements, especially custom business application software development.

Tool
Technology

Requirements

DesignImplementation

Test

MaintenanceConfiguring
Management

Embedded
SystemPackage
Software

Customization

Business
Application System

3

Process

Management

QualityFurther, here are some details of each systems development cycle.

Development cycle goes through requirement definition from final requirements, design, implementation, and test.
UML is used from IT system requirement definition stage for business process until the implementation stage
starting programming. In other words, the requirement definition and design specification are described in UML.
The specification in UML is delivered to offshore members who implement the software based on the UML.

This guideline describes the specification in UML for requirement definition and external/internal design. Fromthe modeling point of view, specification modeling and implementation modeling are covered by this guideline
also.
Conceptual ModelingSpecification Modeling

Implementation Modeling3 types ofmodeling
Requirements

Requirement Definition

Business
Process

DesignImplementation

Test

Outline Design

Detail design

Implementation

Join Test

External design

Internal design

Unit Test

System Test

IT System

 Use case diagram Activity diagram Sequence diagram
 Interaction overview diagram  Component diagram Class diagram Object diagram State machine diagram

Composite diagram Communication structure diagram Package diagram Deployment diagramTiming diagram

This guideline has used requirement definition, external design, internal design, and implementation. However,please refer to the following concepts being described in the next parts.

・Business analysis

・Requirement analysis

・System analysis

・Architecture design・

Detailed design

・

Implementation and Unit Test

・Join Test

4

The offshore development is described as follows in the UML process mentioned above.
In this guideline, offshore means from internal design (detailed design) to implementation after completing
external design (architecture design).
In the point of the developers, the issues are;
“What specification, and how, are drawn up in UML for offshore members?”“What are the main features for offshore development?”

Also, the offshore development results are investigated in the following points.
“What factors are necessary to check after offshore development?”“Which aspects should be satisfied with the offshore development?”
In particular, this guideline gives the answers to the questions above.

Requirement definition

Basic design

Detailed design
Internal design

Implementation
Unit Test

Join Test
System Test

External design
Requirement definition
OutputBasic design
OutputDetailed design
OutputImplementation
OutputView ofDevelopment

View of Quality
Investigation이떻게 이용/작성하면되는가
Requirement
definition
要件定義→Basic Design→
開発者
日本側JapanViewofの視으시점点
Developers
Offshore

How to use/make?

品質 of
日本側JapanView
Quality
点検の視点
Investigation
Offshore

What elements to check?

－－

Detailed Design
Implementation →
詳細設計
実装 →
→ Implementation Join Test/System Test→

Basic Design
基本設計→ Detailed Design→
What is to be given?

－

What is to be received?

－

Level of contents/level to be achieved What elements
to check?
－
What is o be received

What elements to check?
－

The subject of each process has been explained. This guideline will demonstrate mainly two subjects. Firstly,it will assume the „Offshore internal design ~ implementation‟ which is the typical pattern of offshoredevelopment and show the requirement definition and the design summary produced by the Japanese
project team and how to present them to the offshore team members.
Secondly, it will describe the development output verification of both the Japanese project team and theoffshore team.

The subject scope is described in other ways as follows.
The development process is to analyze requirements, design appropriate systems, send the specification to offshore, develop program based on the specification, and test the quality.

5The relevant points from the above development process are;・

Offshore development has some similarities and some differences with local development. Therefore, thefollowing peculiar cases should be considered.

・Techniques and know-how in case of using UML as a language・Techniques and know-how in case of modeling・Techniques and know-how of development methods as an intellectual property based on experience

This guideline is limited to describing “Requirements, specification, and test issues in offshore development using
UML”. Therefore, it does not explain how to use UML, modeling guide, or detailed development methods.

The readers of this guideline are supposed to already understand UML, modeling, development method, and software development elements. Please apply your knowledge to this guideline.
（This guideline does not aim 「to explain UML, modeling, development method, quality management, or
project management or to explain know-how of offshore software development unless they are part of the offshoredevelopment scope.）

Requirement

DesignDefinition

Using UML
as Language

CommonAspectOffshore
Development aspect

Common aspect

Modeling
Skill

Offshore
Development aspect

Common aspect

Development
Methodology

Offshore
Development aspect

6

Specification

Quality Check2. Offshore Development Issues and Solutions
We had a survey targeting the offshore development clients. The survey covered offshore development issues,
outlook and opinions about UML, and the benefits from offshore development using UML. The result of the survey is as shown below. Most of the developers have high expectations of UML and believe that it will ameliorate
many issues.

Expectations and opinions on UML

Offshore Development Issues
Misinterpretation of intention/understanding
through reading/writing unfamiliar language.

Difficulty to describe specification in Japanese
Guideline readers are over expected by writers to

Applying UML

 Create consistent diagram/forms

understand even delicate nuances including readingfor offshoredevelopment

 Minimize ambiguous specification

between the lines Outlook and promising future

Share common understanding between Japan/Offshore
Discovery of misunderstanding in specificationin latter part of development effort.

UML+Offshore Development Benefits
 Visual document expression being
independent from the language
 Consistent communication methods infinal process/early process East of use to identify changes and to makedocuments and codes consistent Global standard description/development
methodologies.

(1) Overview of Questionnaire<Questionnaire to Owners (Japan)>Target: UMTP member companies and their group companies
Date of Survey: November 2006
Qualified Response: 70(Primarily from PM/PL. Ave. years of experience: 16.2 Offshore years of experience: 2.2)

<Questionnaire to Contractor (offshore party)>
Target: Companies in China of which UMTP member companies and their group companies contract with.
Date of Survey: March 2007
Qualified Response: 91 (Primarily from PM/PL. Ave. years of experience: 4.4)
* China was a chosen targeted country for this particular survey because it is assumed that most of theoffshore partnering country is China for Japanese companies.

7

(2) Extract of the questionnaire response
We introduce the outcome of questionnaire by extracting specific questions regarding issues in offshoredevelopment, expectation and comments to UML, and advantages using UML for offshore development.
・Offshore development issues
Table 2.1.1 Offshore development issues and how serious these issues are – Owner (Japan)
Extremely
serious1 Different language/culture causes misunderstanding.
It takes a long time to communicate exactly with offshore
2
partners.
Ambiguous specification description causes
3
misunderstanding.
Discrepancy between the original specification and the4source code provided by the offshore could happen
5 Some specification can be missing.
Too much time can be spent fielding questions from the6
offshore company.
7 Serious quality issues can appear during the test phase.
8 It is difficult to describe specification in details.
9 Test from offshore partner can be unreliable.
10 Offshore partner's resignation can cause unreliable project.
Debugging lead time can be long if offshore partners do
11maintenance.
12 Efficient information sharing is difficult with offshore partners.

Veryserious

Serious

A little
serious

Not serious

More than"serious"
(%)

4

19

14

13

10

38

1

15

16

18

10

27

1

11

14

22

13

20

4

17

21

14

4

35

2

13

19

16

10

25

6

19

19

13

2

42

3
3
5
12

14
14
13
22

11
22
14
13

26
14
22
9

6
8
6
3

28
28
30
58

11

23

16

7

2

58

7

27

17

6

2

58

Table 2.1.2 Offshore development issues and how serious these issues are – Offshore partner(Remarks: Numbers of questionnaires are not sequential because some questions are not identical to the questionnaires to Owner.)

1 Different language/culture causes misunderstanding
It takes too much time to communicate with the2
Owner (Japan)
3 Ambiguous specification causes misunderstanding
4 Discrepancy between the original specification andthe source code provided by the offshore could
5 There are missed description in specifications
Can not share information effectively with Owner
12based on the same understanding and interpretation
Communication between project members are not
13
satifactoryMore
A little
Notthan
se rious seri ous "ser ious"(% )Extre mely Se rious

Ve ry
S riousSe rious

6

7

11

31

38

2

6

14

32

37

9

9

28

24

28

2

41

13

12

10

27

28

28

12

23

33

19

4

38

7

27

17

6

2

58

4

15

16

23

32

21

14

It is now understood that both Owners and Offshore parties recognize #12, which is “cannot share
information effectively based on the same understanding”, a serious problem. Offshore parties believe it
is because specifications provided by Owners are ambiguous, which is shown in #3. Owners, however,
do not recognize it a problem. It is assumed that Owners have difficulties to communicate with offshore
parties fully by their system specifications and Owners end up spending too much time responding somany questions from offshore parties, which is shown in #6.

8

Solution to the offshore development issues
It is recognized that 74% of people, shown in table 2.2, are using not just UML but any diagrams andcharts to review status or write specifications to avoid such issues as that Owners and Offshore parties
could not communicate effectively based on the same understanding indicated in #12 in the table on theprevious page. It is interpreted that most of the developers using diagrams and charts actively.
Table 2.2 Percentage of using UML or other diagrams in review process, specifications – Owner (Japan)
Case
(a)
(b)
(c)
(d)
(e)
(f)
(g)

UML (at least a diagram) is used.
Same diagram format excluding UML is used in organization.
Identified diagram format is used personally - no (a) and (b) cases.
Random various diagram formats are used.
Only characters but not diagrams are used.
No written format is used.
Others.

Average(%)
19%38%
17% 74%
14%
5%
3%
4%

Further, another survey shown below explains how UML is recognized. It seems that UML is recognizedthat it is more specific and clear than other diagrams and charts.
Table 2.3.1 Expectations and Comments to UML – Owner (Japan)
Totally
RatherNeutralDisagree Diagree

Comments
UML should only be known by those who get involed in high levelsystem design
2 UML is not much help to reduce cost
3 UML expertise are not there around us
1

RatherAgree

TotallyAgree% of"Agree"

29

28

8

2

0

3

3
10

9
17

28
9

21
22

6
9

40
46

4 UML training is a tough part. It costs us a lot, as well

4

10

17

31

5

54

5 UML increases productivity

1

4

38

19

5

36

6 UML reduces reversal processes in programinning phase

2

5

30

24

6

45

7 UML brings more quality

2

4

27

29

5

51

8 UML is too professional and is difficult to use

9

22

24

10

2

18

9 UML makes difficult to quote volume of work and cost

5

20

32

8

2

15

10 UML makes project management difficult

6

20

37

4

0

6

11 UML makes specifications less ambiguous

1

2

18

37

9

69

2

6

17

32

10

63

2

4

15

35

11

69

12

29

20

6

0

9

5

15

36

9

2

16

2

3

30

23

9

48

1
3

13
15

36
26

12
18

5
5

25
34

3

6

42

12

3

23

4

6

29

24

3

41

UML makes easier to understand how changes impacts the otherareas
UML helps better and more effective communication in review
13
process
14 UML creats mess in development processes
There are more suitable tools in high-level design phase rather
15
than UML
UML accelerate communications between Owners and Offshore
16
partners
17 UML reduces cost in maintenance
18 UML is effective to automate development process
12

19 UML is more used in offshore development rather than in Japan
UML better matches with offshore development rather than20
development in Japan

9

Table 2.3.2 Expectations and Comments to UML – Offshore Partner(Remarks: Numbers of questionnaires are not sequential because some questions are not identical to the questionnaires to Owner.)

To tal ly
Ra the rRath er Tota lly% of
NeutralDisag ree Diagr ee
A gree A gree "A gree "Commen ts
1 UML should o nly b e kno wn by Owners (Japan )

51

22

4

4

1

6

2 UML is n ot mu ch he lp to re duce cost

7

23

35

15

2

21

3 UML expertise are not th ere arou nd us

27

19

23

9

4

16

4 It co sts a l ot to learn UML

4

18

26

27

6

41

5 UML increa se s pro ductivity

0

0

14

47

21

83

6 UML redu ce s retur n p rocesses from Owner s

1

6

21

33

18

65

7 UML brin gs mo re quality

0

1

26

36

19

67

8 UML is too p rofessio nal and is difficu lt to use

10

21

20

23

8

38
9

9 UML makes difficu lt to quote vo lume of wor k and cost

4

32

39

7

0

10 UML makes proje ct manag ement diffi cu lt

6

45

27

3

1

5

11 UML makes sp ecifica tio ns le ss ambi guous
UML makes easier to unde rstan d h ow chan ges impacts the12o th er areas
UML help s be tter and mo re effective co mmunication in13
r evi ew pro ce ss
14 UML creats me ss in develo pment processes
UML accelera te commu nications betwe en Owners and16
O ffshor e p artners

1

3

12

45

21

80

0

3

18

37

24

74

1

4

19

35

23

71

24

37

15

5

1

7

0

3

21

40

17

70

18 UML is e ffective to automa te de ve lopmen t pro ce ss
19 UML is m ore used in offsh ore develop ment r ather th an in
Jap anbetter match es with offsho re developme nt ra th er tha nUML20d evelopme nt in Japa n
21 The re are many UML textb ooks avail able

1

3

23

43

12

67

2

12

44

20

4

29

4

4

43

27

6

39

0

13

16

30

23

65

22 UML help s to develop care er and hel ps pr omotion

1

4

25

28

24

63

Both Owners and Offshore Partners recognize such advantages as “#11, makes less ambiguous”, “#12,easier to understand how changes impact”, or “#13, helps effective communications in review process”.
They both also believe that “#16 UML accelerate communications”, “#7 UML bring more quality”. It isalso recognized that level of expectations of Offshore Partners to UML is very high. On the other hand,
Owners recognize high training cost and UML is difficult to educate (#4) .
Benefits of UML being used for Offshore Development

Table 2.4.1 Benefits of UML being used for Offshore Development – Owner (Japan)
Not
Very
Weighted
Importantimportantimportant
Total
13
26
22
131

Benefits①

Global standard documentation②

Visual documentation

10

26

24

134

③

Client(User) friendly documentation

13

27

20

127

④

Easy maintenance by using specification without
program source code
Seamless development through the entire process

14

31

15

121

16

27

18

124

9

21

30

141

⑦

Same tool can be used by offshore and local
developments.
Identified communication tool is used from the
beginning and ending processes.

8

26

26

138

⑧

Global standard development methods can be used.

10

27

24

136

⑨

Developed process can be reused.

15

28

17

122

⑩

It does not have to rely on natural language.

13

30

17

124

⑪

Specification and source code should be matched.

8

31

21

133

⑫

Offshore developer's language(ex. Chinese) can beused.
Quality can be assured.

24

22

14

110

13

21

26

133

⑤
⑥

⑬

Table 2.4.2 Benefits of UML being used for Offshore Development – Owner (Japan)

10

Not
important

Benefits
①
②
③
④
⑤
⑥
⑦
⑧
⑨
⑩
⑪
⑫
⑬

Global standard documentation
Visual documentation
Client(User) friendly documentation
Easy maintenance by using specification without
program source code
Seamless development through the entire process
Same tool can be used by offshore and local
developments.
Identified communication tool is used from the
beginning and ending processes.
Global standard development methods can be used.
Developed process can be reused.
It does not have to rely on natural language.
Specification and source code should be matched.
Owner's language (Japanese) can be used
Quality can be assured.

7
5
3
5

Very
Weighted
important
Total
41
43
218
44
42
219
43
45
224
43
43
220

2
17

48
42

41
32

221
197

7

39

58

259

5
5
10
5
5
5

46
36
53
26
35
20

40
50
28
60
51
66

217
227
200
237
228
243

ImportantCommunication with Offshore Partners is very important in Offshore Development. Having said that,“#12, Other party‟s language can be used” would be extremely important. Between China and Japan
offshore relationship, Chinese offshore partners typically understand Japanese so that Owners do notrecognize significant advantages using UML. However, Offshore Partner does recognize significant
advantage using UML. It is assumed that most of high-level system design is done by Owners (Japan)
and development effort is done by the contractors (Offshore Partners). In that sense, both parties
recognize benefits of having common communication tool (#7).
Also, such unique benefits as “#2, Visual Documentation”, “#1, Global Standard Documentation”,“#8, Global Standard Development Methods” are all important in the offshore development.
Further, such recognition as “#11, consistency between source code and specification is successfully
maintained” is supported by many people involved in the offshore development.
(3) Voices and Comments
The following hearing process was implemented to support outcome of the questionnaire above. It isthen confirmed that this particular guideline is convincing enough from Offshore Partners point of view,and that it could possibly be used for other offshore development partners‟ country such as India.
<Hearing from PM/PL in China (partially done by written questionnaire format)>
Hearing Objective: To better understand the reality which many not be discovered by quantitative
questionnaire survey.
Date:
November 2007<.Hearing from Architects in India>
Hearing Objective: To understand how UML is being used in US/India offshore relationships which isahead of Japan/China offshore relationships
Date:
March 200811

3. UML Modeling
3.1 UML Features(1) What is UML?
UML (Unified Modeling Language) is a standard by the OMG (Object Management Group) to specify and makediagrams for software development.

(2) UML Features
UML has the following features.
・ Global standard.
Easy communication between countries and different projects.

・ Easy to display and understand.


UML provides various diagrams to analyze and display designs in intuitive and easy to understandways.

・ Identified method through the entire development process.
Each development is traceable and communication between developers in each process is easy.

(3) UML Diagrams
UML has various diagram types as shown below.

Diagrams

Composite structure
diagramClass diagram

Behavior diagram

Use case diagram

Composite structure
diagramState machine diagram

Object diagram

Activity diagram

Package diagram

Interaction diagram

Interaction overview
diagramComponent diagram

Sequence diagram

Deployment diagram

Communication diagram

Timing diagram

12

・Component structure diagrams● Class diagram● Composite structure diagram

Objects in analysis and design area are

Internal structure of class or compo-

analyzed conceptually and displayed bynent is displayed by class.

class and the relationships.
Department

1..*

1

ビル

：部屋

Department
minute book

1..*
1..*
1

1

Position

1..*
Employees：廊下

1
Employee list

：トイレ
Technical

Sales

Administration● Package diagram● Object diagram

Package relationships with UML ele-

A system state at a moment is dis-ments are displayed.

played in object or the relationships.
：従業員リスト

Employees

Control

Screen
田中：従業員

鈴木：従業員

技術職
営業職

佐藤：従業員

事務職● Component diagram● Deployment diagram

Software component (reusable) configu-

System running environment is dis-ration is displayed.

played.
<<device>>: ApplicationServer：Salary：Acount<<executionEnvironment>>：J2EEServer

13

・Behavior diagrams● Use case diagram● State machine diagram

Functions and the external relation-

An object state change by time isships provided by the system are dis-

displayed.
Regular Member

played.

[営業職]

試用期間

職種
変更

営業職

職
種
変
更

職
種
変
更

]

職

務

職種
変更

[事

Search employee
information

職種
変更

[技

職種
変更

術

職

]

技術職

正式採用

事務職

Employees

Register employee
information
退職

Modify employee
information

退職

Delete employee
information
Administrator● Activity diagram● Interaction overview diagram● Timing diagram

Business /event/algorithm flows

Various interactivity relationships

Lifeline changed by time and message

are displayed.

are displayed.

exchange are displayed.
sd タイミング１

sd 相互作用１Lifeline 1

Status1

Enter employee information

Event 1

Status2
Event 2

Status3
Choose position
sd 相互作用2

Event 3sd 相互作用3０ １ ２Enter Technicalposition info

Enter Sales
position info

Enter administration
position info
sd 相互作用4

Register in employee list

● Sequence diagram● Communication diagram

Interaction (object or person exchange in anal-

Interaction (object or person exchange inysis

analysis and design) is displayed by rela-anddesign)isdisplayed

by

time.

tionships

Sd Employee register：Register screen：Register
management：Employee listwith

objector２：従業員の登録
５：従業員リストへの登録：登録画面：Administrator

：登録管理

：管理者

Enter employee info
Employee register：従業員リスト３：生成

Generation：Employee
４：生成

Generation：Technicalposition

Register in employee list (Employees)

per-１：従業員情報の入力：Department

：従業員

son.

Register in department (Employees)

14

：技術職

3.2 Required UML Modeling Skill Level
Both Offshore Owners and Offshore Partners need to maintain qualified level of UML modelingskill for them to maintain successful and effective offshore development relationship using UML. If thisparticular skill set is not available yet, required training and education are highly recommended prior tothe offshore development project starts. It should also to be understood that required UML modeling skill
level would be varied from such positions as Analyst, Designer, Production Engineer, Architect, ProjectManager and Project Leader.
UML Modeling skill level defined here in this section is only for UML Modeling, and it presumes
that all such engineers as Analyst, Designer, Production Engineer, Architect, Project Manager and Project
Leader have had respective technical skill required for such respective positions. Therefore, this particularsection does not define any of these generic skill sets.
<Objective>
It is expected that both Owners and Offshore Partners exchange information of artifact created byUML. If both parties have qualified UML modeling skill, communications between them will be
successful by minimum effort of exchanging artifact. If, however, UML modeling skill developers are notenough, communication between Owners and Offshore Partners using artifact of specifications will not be
accurate. It will further cause problems such as that Owners development engineers will need to explain
what UML modeling is to Offshore Partners‟ engineers. This will be a waste of time and effort.
<Details/Supplements>

How to judge the skill level
UMTP defines modeling skill level from L1 through L4 as shown below.
Modeling Skill

Description

L4

Can train other engineers and help them to improvetheir modeling skill based on his/her own modelingexpertiseL3

Can implement UML models in the production
environment

L2

Can write/read UML models without difficulties(qualified level of modeling literacy)

L1

Can interpret simple UML models

Require L3 skill level. Also required qualified
number of years modeling experience or
number of projects experience in softwaredevelopment projects.
Can provide high-quality models withscalability and ease of changes capabilities.
Has professional knowledge (professional
fileds can be chosen) for businessmodedling, analysis, architectual design andembedded development.
Can be involved in the modeling project
being responsible for a part of the targeted
development area.
Can interpret the models created by otherengineers.
Has minimum level of knowledge of modelingto creat models by a technique such as UML
modeling.

UMTP offers qualified tests for L1 and L2 levels (L3 test is expected to be available from April 2008)
This test qualifies your skill level appropriately.
There are two levels of test for L1, L1-T1 and L1-T2.
Qualified levels are:
L1-T1: Understands how to write UML models.
L1-T2: Able to read UML models and successfully judge the quality of the model.
* L1-T2 and L2 tests are available in China.
A real development project requires the following skill level depending on the roles.
Production Engineers:
Create source code from UML models (level L1-T2).
Analysts:
Create UML analytic models by himself/herself directed by senior analysts(Level L2)
Designer:
Create UML design models by himself/herself by the architecture provided.
(Level L2)

15

Senior Analyst:
Architect:
Project Leader:
Project Manager:

Production Engineer
AnalystSenior Analyst
Designer
Architect
Project Leader
Project Manager

Create initial analytic model (Level L3)
Create architectural model (Level L3)
Review model analysis, design rules, and determine what to do (Level L3)
Highest level of project management (Level L1, L2)
L1-T1
Yes
Yes
Yes
Yes
Yes
Yes
Yes

L1-T2
Yes
Yes
Yes
Yes
Yes
Yes
Yes

L2
No
Yes
Yes
Nice to have
Yes
Yes
Nice to have

L3
No
No
Yes
No
Yes
Yes
No



Skills Development
Getting familiar with UML (L1-T1) and learning entry level of modeling (L1-T2) can be done
by a text book available in book stores. However, extra effort might be required for L2, whichis to develop UML model without help. It requires specific training or mentoring to get to thepoint for better model development, and further requires practical modeling development
experience for more comprehensive understanding.



Reference Information
UMTP Modeling Standard Based
Some text books available at book stores have levels as UMTP Modeling Standard Based.
This indicates that UMTP verifies that these books follow UML Modeling terminologies (Ver.2).
If successfully followed, UMTP authorizes them.
All UMTP Modeling Standard Based books can be found at the following URL.
http://www.umtp-japan.org/modules/data4/index.php?id=7-

Training Text Authorization
It is reviewed in detail during UMTP authorization process whether or not the training text
follows UMTP standard terminologies (Ver.2) and whether or not the training text addresses
knowledge required for UML modeling and is explained in detail. If successfully followed,
UMTP authorizes it.
UMTP authorized training courses can be found at the following URL.
http://www.umtp-japan.org/modules/data4/index.php?id=8< Relevant Information >Not available

16

4. UML Application Scope and Development Knowhow (Hints & Tips)
According to the survey in the chapter 2, it is understood that most people recognize the advantage ofusing UML for offshore development. It is,however,very important in which status UML is applied because
the effect is not immediate. This particular chapter explains know-how to succeed in offshore development
for each process. It will be focused on UML but not limited to it.
Development flow and each process purpose, task, staff and output are described in figures 4-1 and Table 4-1
respectively. Figure 4.1 only shows the important artifacts. Detail of that should be referred to Table 4.1.
Figure 4.1 also shows which tasks may require special attention in each step of development process(know-how) by point number.
The know-how will be described in the following formats.
・Point numbers and titles
・Contents
・Purpose・Detailed description
・Relevant information
Besides, there is another category, which is “optional”(can be chosen depending on the situation), forknow-hows that is not necessarily executed in the initial stage of offshore development although it istypically effective if all other conditions are satisfied.

17

Figure 4.1 Development workflow

Japan

Offshore Partner

Point 01
Point 02
Point 03
Define specific scope of work

Business use case diagram

Business analysis

Point 05
Requirement
Requirement analysis
Non-functional requirement analysis
Point 04

System use case diagram

Point 06
Glossary
Point 07
Class diagram
Sequence diagram

System analysis

Point 12
Naming rules
Point 08
Point 09

Point 10
Architecture description

Point 13

Detail design
Point 11

Architecture design

Architecture model(Class diagram, Sequence diagram, etc.)

Point 14

Point 18
Point 20

Detail design
guideline
Check list

Detail design
review[NG]

Point 15
Point 16

Point 17

Point 19
Point 21Class diagram
Sequence diagram

Detail design review[OK]

Review result

Point 22

Implementation
guideline
Implementation review/Unit test

Check list
Source code
Unit test result check[NG]

Unit test result

Review result[OK]

Joint test

System test18

Table 4.1 Process description

Process name：Business Analysis
Purpose(Japan）：

Purpose(Offshore Partner）：
Understand business flow of thesystem to be developed in detailand clarify it. This helps further
clarify to define which particularpart of the business process to betargeted for system development.

Task(Japan）：

Understand targeted business process to be
developed. This should support any successive
processes to be moved on smoothly.

Task(Offshore Partner）：
Understand business process indetail and clarify it. Organize
business flow once again to makesure if necessary.

Developer(Japan）：
PM
AnalystInput required：

Understand targeted systems development
scope and associated business processes. (incase participated in high-level system design).
Developer(Offshore Partner）：
PM
System analyst(if s/he participates in high-level systemdesign phase)
Input required：・Business flow

・Business Use Case Diagram
・Business Flow
・Business Use Case Description
・Conceptual Class Diagram

Output :Output :・Business Use Case Diagram
・Business Flow
・Business Use Case Description
・Conceptual Class Diagram

Reference Information
・Glossary・Naming Rules

Reference Information
・Glossary・Naming Rules

19

Process name：Requirement analysis
Purpose(Japan):Purpose(Offshore Partner):
Verify the functional requirements andthe non-functional requirements of thesystem.

Task(Japan):

The process assigned after detailed
design is not using this process output
directly. Understand system function as
this system development object in thisprocess output. Recognize the design
purpose for the better communication
after detailed design.
Task (Offshore Partner):

Verify the requirement of clients.

Developer(Japan):

Refer to the output and understand thesystem function. (If partiticpated in highlevel design process.)
Developer(Offshore Partner):
System analyst
Detail system analyst(if participated in high-level design
process.)

Requirement analyst

Input required：・Business use case diagram
・Business flow
・Business use case description
・Requirement Detail

Output :Input required：・System use case diagram
・System use case list
・Busines rule definition
・System sequence diagram
・System use case description
・Screen transition diagram
・Screen and design documentation
・Non-functional requirement
definition
Output :・System use case diagram
・System use case list
・Business rule definition
・System sequence diagram
・System use case description
・Screen transition diagram
・Screen and design documentation
・Non-functional requirement
definition
Reference Information

Reference Information

・Glossary・Naming Rules

・Glossary・Naming Rules

20

Process name：
System analysis
Purpose(Japan):Purpose(Offshore Partners):
Analyze system development
object domain in natural form andmake model not relying on
development and operation
system to reuse and maintain.

Task(Japan):

The process assigned after detailed
design is not using this process output
directly. Aim to acquire systemdevelopment object knowledge from thisprocess output and understand thedesign purpose for better
communication after detailed design.
Task (Offshore Partners):

Define system context displayed
Refer to the output and understand thebrief system structure andsystem development area. (Ifrelevance. Then, analyze system
participated in high-level system design
behavior with summary toprocess)
understand system geographic
dispersion or complex operation.
Developer(Japan):
Developer (Offshore Partner):
System analyst
Requirement analyst
Detail system designer(if participated in high-level systemdesign process).
Input required：

Input required：・System use case diagram
・System use case list
・Business rule definition
・System sequence diagram
・System use case description
・Screen transition diagram
・Screen and design documentation

Output :・Analysis class diagram
・Analysis sequence diagram
・Object diagram(・Communication diagram)(・State machine diagram)

Output :・Analysis class diagram
・Analysis sequence diagram
・Object diagram(・Communication diagram)(・State machine diagram)

Reference Information
・Glossary・Naming Rules

Reference Information
・Glossary・Naming Rules

21

Process name：Architecture design
Purpose(Japan):Purpose (Offshore Partner):
Verify the fundamental system
structure.

Task(Japan):

Use as input to the detail design.
Task (Offshore Partner):

Define a candidate architecture
Refer to the output to detail design
including reusable modeling(If participated in high-level systemelements based on analyzed result.
design process).
Achieve architecture analysis indetail and distinguish class,subsystem and subsysteminterfaces in component design andDeveloper(Japan): database design.
Developer (Offshore Partner):
Architect
Detail system designer(If participated in high-level system

Architect

design process.)
Input required：

Input required：・Analysis class diagram
・Architecture class diagram
・Analysis sequence diagram
・Architecture sequence diagram
・Object diagram
・Object diagram(・Communication diagram)・Package diagram(・State machine diagram)
・Component diagram
・Non-functional requirement definition
・Deployment diagram
・Architecture description
・Detailed architecture guideline
・Detailed architecture checklist
・Data model diagram (E-R diagram)・Analysys class diagram
・Analysys sequence diagram

Output :Output :・Architecture class diagram
・Architecture sequence diagram
・Object diagram
・Package diagram
・Component diagram
・Deployment diagram
・Architecture description
・Detailed architecture guideline
・Detailed architecture checklist
・Data model diagram (E-R diagram)

Reference Information
・Glossary・Naming Rules

Reference Information
・Glossary・Naming Rules

22

Process name：Detail Design
Purpose(Japan):Purpose (Offshore Partner):
Assign the large tasks to China.

Task(Japan):

Detail the model to implementation

Purpose (Offshore Partner):
Verify the task from China is within
the architecture scope.

Developer(Japan):

Input the architecture model and description
to control subsystems and detail theimplementation model.
Developer (Offshore Partner):

Reviewer

Input required：

Architect(if participated in high-level systemdesign process).
Input required：・Detailed architecture class diagram
・Detailed architecture sequence
diagram(・Object diagram)・Detailed architecture review result(Offshore Partner)

Output :・Architecture class diagram
・Architecture sequence diagram
・Object diagram
・Package diagram
・Component diagram
・Deployment diagram
・Architecture description
・Detailed architecture guideline
・Detailed architecture checklist
・Analysys case diagram
・Analysys sequence diagram
Output :・Detailed architecture review result(Japan)Reference Information
・Glossary・Naming Rules

・Architecture class diagram
・Architecture sequence diagram(・Object diagram)・Detailed architecture review result(Offshore Partner)
Reference Information
・Glossary・Naming Rules

23

Process name：Implementation/Review/Unit Test
Purpose(Japan):Purpose(Offshore Partner):
Assign the large tasks to Offshore Partner.

Task(Japan):

Build the source program which runs thesystem.
Task (Offshore Partner):

Review test status as required.

Developer(Japan):

Make implementation and individual test
based on the detail design output.
Developer (Offshore Partner):

Reviewer
Input required：

Person in charge of implementation
Input required：・Unit test result

・Detail design class diagram
・Detail design sequence diagram(・Object diagram)

Output :Output :・Unit test review result

・Source program
・Each test result

Reference Information

Reference Information

・Glossary・Glossary・Naming Rules

・Naming Rules

・Implementation Guideline

・Implementation Guideline

・Check List

・Check List

24

Process name： Unit Test Result Review

Purpose(Japan):Purpose (Offshore Partner):

Review quality.
Task(Japan):Final quality review.
Task (Offshore Partner):

Review unit test result.

Developer(Japan):

Revisit unit test result as required.

Developer (Offshore Partner):

Reviewer

Input required：

Person in charge of implementation

Input required：

・Review result

・Unit test result

Output :Output :・Review result

Reference Information

・Unit test result

Reference Information

・Glossary・Glossary・Naming Rules

・Naming Rules

・Implementation Guideline

・Implementation Guideline

・Check List

・Check List

25

Process name：Join Test
Purpose(Japan):Purpose (Offshore Partner):
Perform join test on the source
program through the Unit Tests.

Task(Japan):

Improve source program quality.

Task (Offshore Partner):
Perform Join Test.

Developer(Japan):Fix bugs in the detail design andimplementation.

Developer (Offshore Partner):
Tester

Person in charge of detail design
Person in charge of implementation

Input required：

Input required：・Source program・Detail Design class diagram

・Each test result

・Detail Design sequence diagram
・Source program
・Bug list

Output :Output :・Join test result

・Detail Design class diagram
・Detail Design sequence diagram
・Source program
・Bug list
・Checklist

Reference Information

Reference Information

・Glossary・Glossary・Naming Rules

・Naming Rules

26

Table 4.2 Example for each process output
Process

Business
Analysis

Output set

Output

UML diagram

Business

Business use case diagram

Use case diagram

process

Business flow

Activity diagram

model

Business use case description

Domainmodel

Concept class diagram
System use case diagram

Use
case
model
Requirements
Analysis

Class diagram
Object diagram
Use case diagram

System use case list
Business rule definition
System sequence diagram

Sequence diagram
Interaction overview diagram

System use case description

Activity diagram available

User interface

Screen transition diagram

State machine diagram

model

Screen, Design bookNon-functional

Non-functional requirements defini-requirements

tion

Glossary

Glossary
Robustness diagram
Analysis class diagram

System Analysis

Analysis model

Class diagram
Object diagram

Data model diagram（E-R diagram）
Interaction diagram
State diagram

Sequence diagram
Communication diagram
State machine diagram

Architecture description
Package diagram
Architecture

Software configuration

model

Architecture
Design/Detail Design

Component diagram
Composite structure diagram

Hardware configuration

Deployment diagram

Fundamental process method

Sequence diagram

Architecture class diagram/DetailClass diagram

design class diagram

Object diagram

Data model diagram（E-R diagram）
Design modelInteraction diagram

Sequence diagram
Communication diagram
State machine diagram

State diagram

Timing diagram

Class specification
Embedded

Embedded set

Unit test/

Test set

Join test Process

Output set

Implementation code
Test plan
Test specification
Output

UML diagram27

Table 4.3 Development Know-How (Hints and Tips)
Process

Point

Know-HowNo.
Define specific01

Define specific scope of work, roles and responsibilities

scope of work

02

Determining UML diagram to be used

03

It does not have to be UML at all times

Business

04

Participate early development process (optional)

Analysis /05

Non-functional requirement definition

Requirement

06

Understanding business process by analysis models

Analysis07

Creating glossaries

08

Create naming rules

09

Creating modeling rules

System10

Explicit common function

Analysis/

11

Architecture Model

Architecture

12

Create output of architecture description

Design13

Using patterns

14

Level of description of specification, format specification

15

Creating detail design guideline

16

Clarifying areas of which specifications are not determined

Detail Design /17

Reviewing output by the offshore partner

Implementation

18

Repeating check by the owner (Japan)

19

Validation and Verification

20

Reviewing detail design by the models

21

Consistency between UML diagrams

22

Using code generation feature in the tool for production(Optional)

Remarks

Unique nature of systems development in Japan(Optional): Expected to be very effective if it is executed under well-prepared appropriate
situation. However, it is not necessary required in the early stages of offshore development.

(*): Samples are available. See Appendix A for explanation of the samples.

28

(*)
(*)

(*)

(*)

(*)

【Point 01 Define specific scope of work, roles and responsibilities.】
Each process should be assigned clearly. Output (with UML or non-UML) for each process should be
decided in advance. Modeling and test scopes need to be distinguished precisely in offshore development.

【Purpose】
A system development project can be processing in several offices/branches (local or worldwide) together. Every project has different task and output in each process. Task for each process should becorrectly recognized to avoid any confusion when project starts. Client and offshore members verify
their outputs in each process to avoid issues after completion.

【Details ・ Supplementation】
Offshore task for each process should be correctly assigned for efficient processing. In many cases
offshore members are not available to deal with environmental aspect, operational requirements, troubleshooting requirements, and security issues. Therefore, it is helpful to divide the tasks for offshore teamand client (Japanese project company) in advance.

<General process>・ Describe outcome for each process.
・ Verify input/output for each process.
・ Produce the guideline for output forms and contents granularity.
・ Decide how to verify output to avoid inconsistency between related outputs.
<Architecture design ・ Detail design （modeling）>
・ Decide the fundamental development and other development scopes to be provided.
<Implementation ・ Unit test （preparation and production）>
・ Development environment requirements （including server, software, and version）
・ Scheduling to provide components （available date）
・ Components provided （summary, external requirements）
・ Development tools<Test>・ Consider development environmental condition
・ Choose if test and sample data will be provided （Sample data will be helpful for better understanding）
・ It is expected to provide test data as early as possible if test data is provided
Offshore development party should particularly consider the followings in the early stage of development.
・ Any constraints in the offshore development environment and test environment

29

For example, it is required to check in an early stage if documents in Japanese/Chinese will
be used, large server/computer can be prepared, or files can be shared.
・ Any constraints on non-functional requirements implemented by offshore architecture
For example, some tests need to have an embedded verification function and the other tests
rely on the performance during the test.
・ Limited test data in offshore environment
For example, secured client data or some test data in Japanese or Chinese is difficult toshare because of the language barrier.

It should be recognized that communication is extremely important in the offshoredevelopment project. Detail and specific communication planning will be required. Specifically, whoshould communicate with whom, either by weekly or any other cycle.
Not just scope of work and associate responsibility, It is necessary to clearly define thedevelopment organizations in the offshore team.

【Relevant information】
Figure 4.1 Development Process
Table 4.1 Description of Each Process

30

<Example of using activity diagram to clearly define works and responsibilities>
Swimlane in the activity diagram is used to identify the works of Japan and offshore partner.

31

【Point 02 Determining UML diagram to be used.】
Clarify which UML diagrams and supplementation will be used for each process.

【Purpose】
Use appropriate UML diagram in each process development. Decide which UML will be used byprocess when project starts.

【Details ・Supplementation】

Decide which UML diagrams will be used in each process to avoid missing any steps. Analyze UML
diagram link such as diagrams by random/compulsory classification to explain the basis of the model.
Consider using UML diagram as shown below for business analysis ~ detail design in each process.

<Task analysis>
・Use case diagram
・Activity diagram
・Class diagram
・Object diagram△ （depending on status）○△ （depending on status）△ （depending on status）<Requirement analaysis>
・Use case diagram
・Activity diagram
・Sequence diagram
・Interaction overview diagram
・State machine diagram○△ （depending on status）△ （depending on status）△ （depending on satus）△ （depending on status）<System analysis>
・Class diagram
・Object diagram
・Sequence diagram
・Component diagram
・State machine diagram○○○△ （depending on status）△ （depending on satus）<Architecture design、Detail design>（To reassure the diagrams drawn up in previous process and to add
more details)

・Component diagram
・Composite structure diagram
・Class diagram
・Communication diagram
・State machine diaram
・Sequence diagram
・Object diagram
・Package diagram
・Deployment diagram
・Timing diagram△ （depending on status）△ （depending on status）○△ （depending on status）△ （depending on status）○○○△ （depending on status）△ （depending on status）【Relevant information 】
Refer to Table 4.2 Example for each process output.

32

【Point 03 It does not have to be UML at all times.】
The entire output of system development does not have to be in UML only. Use non-UML diagram if itsuits your purpose.

【Purpose】
The purpose of architecture is to deliver development objects more precisely and efficiently. It is notnecessary to use only UML diagrams in system development to produce architecture documentation.

【Details ・ Supplementation】
Recognize UML diagram features and use appropriate diagram to demonstrate information. Use UML
or non-UML appropriately because not every UML supports every output. In this case, it is not necessary to use UML. For example, some tables demonstrate clearer information depending on context. All
the information does not have to be in UML model. The document should be in proper format whether it
is UML or not.

Consider the following for using non-UML diagrams.
・ Screen transition diagram
・ Screen design documentation
・ Data model diagram（E-R diagram）
・ Data flow diagram（DFD）
・ Robustness diagram (UML extension)
・ Network diagram【Relevant information 】
Table 4.2 Example for each process output.

33

【Example that the technology other than UML may be more appropriate】
When you design the member registration screen, how you could do it UML class diagram isshown in the sample 1. Sample 2 is the screen sample designed and developed by the otherscreen design tools and Excel. It is obvious that the sample 2 is much easier to understandrather than the sample 1 when you design screen layouts, when you make sure of the design
or review them. It is suggested not to use UML to design screens and reports, and use adiagram in the sample 2 alternatively.

<Sample 1><Sample 2>
Member Registration

E-mail address （log in ID)
Name

Address
Phone

Gender○ MalePayment method (default)-- Please selectPassword for log inOK○ Female

Cancel34

【Point 04 Participate early development process (optional) 】
It is desirable that offshore system engineer (SE), who‟s command of Japanese language are high,to participate high-level system design process which is conducted in Japan.

【Purpose】
Drive after detail design efficiently if offshore members develop process after detail design.

【Details ・Supplementation】

Offshore members have difficulty in understanding the entire system because The Japanese project
team performs the high-level system design process and offshore members perform the detail design.
Therefore, it is necessary that offshore members participates the high-level system design process
and understand the purpose of the development system and the contents to avoid any mistakes in thedetail design process and its successive processes. It would also be possible to request the
Offshore Partner to execute Join Test partially as some of the Offshore Partner members
understand the entire system design. In this scenario, it would be ideal that just some of offshore
members participates the high-level system design process would be depending on the system size.
Most importantly, Owner (Japan) should make a fair judgment whether or not the Offshore
Partner has qualified engineers who could possibly participate the high-level system design
process. Then, the Owner could consider expanding the areas that the Offshore Partner could
help.

【Relevant information 】
Point 01: Define specific scope of work, roles and responsibilities
Point 06: Understanding business process by analysis models
Point 11: Architecture model35

【Point 05 Non-functional requirement definition】
Define the non-functional requirements. Non-functional requirements are important f a c t o r t odetermine how to make required functions (system features) available.

【Purpose】
Non-functional requirements are important for architecture design and have to be defined clearly before the architecture design. Non-functional requirements are entered when the architecture is designed.

【Details ・Supplementation】

There are functional requirements and non-functional requirements in the system requirements. Indicate functional requirements clearly in usage case diagram and define non-functional requirements.
Non-functional requirements are described as shown below.

・ Development/system requirements (hardware/software)・ Performance requirements
・ Reliability requirements
・ Cost (short/long terms)
・ Security
・ Maintenance・ Operational requirements
This particular section covers non-functional requirements in the system, not just what to becovered by the Offshore Partners. How project members typically view things may not be equallyinterpreted by the Offshore Partners. Therefore, it is extremely important to define clearly what
the output goals should be including non-functional requirements.

【Relevant information 】
Point 11:

Architecture model36

【Point 06 Understanding business process by analysis models】
Create Analysis Model to help project members understand business process visually.

【Purpose】
Using Analysis Model helps engineers to understand business process visually at high-level.
So that, it is expected that Owner (Japan) should create the Analysis Model as the Owner is
supposed to be familiar with system requirements in detail. Model description can be written in
Japanese. However, it is expected to be brief, not using long sentence. Using models help
Offshore Partners‟ engineers who may not be fluent in Japanese, and it will help both Owner
and Offshore Partner to communicate accurately.

【Details ・Supplementation】

Analysis Model uses mainly class diagram and presents business processes. Analysis Model
does not explain how business processes can be systematically design. It does not necessarily haveto be in detail.

Models should be developed for common understanding among project members.

This also intends to avoid anything ambiguous. It will help any successive design processes
to avoid any step-backs. Offshore Partners should be advised to ask questions as early as
possible if models cannot be interpreted completely or they have any other questions.

【Relevant information 】
Appendix, Sample Output: (1) Output of each process37③Process: Systems Analysis

【Sample of analytic model to understand business operation】
Understanding business operation by use case diagram and class diagram at analytical level.

Example of use case diagramlevel of detail requiredby the end user

memberregistration

search goods
customersearch by goods'
categories
search by
keywords
search by ranking
purchase goods

registration of
goods

enter comments
and evaluation of
goods

change of goods'
information

checking goods
delivery status
administrator

memberdeletion of goods'
information

display detail listof goods
purchasedchange ofmember's
information

identification of actor
should by roles38

closing theaccount

Sample of class diagram

add relationship to theother classes while
creating sequence
diagramdisplay only major
attributes

multiplicity is notnecessarily described1
administator

1

1..*

goods' categories

catogories
1

membere-mail addressname(Kanji)
name(Furigana)
Address
phone number
gender
0..1

1..*
1
1

0..*

1

0..*

card
name of the card
issuerphone number

1..4

payment
methodregistered1..*

purchase

0..*default
payment
method

0..*

1

1

1

0..*

cash on delivery

comments/
evaluationcomments
evaluation

class should be
described only by thewords end users areusing

1
delivery statusdelivery method

payment methodbank transfer

name of goods
picture of goods
pricedelivery schedule
description of goods
at high level
authers or Artists

11name of the bankaccount number
account name

0..*

goods

取取
0..*

取取取

generalization
relationship is to bemarked only if further
understading of
domain region is
expected

all the relationships
are not necessarily
have to be defined

pay atconvenience
storeshome delivery

postal officedeliverypick up atconvenience
stores＜Notice＞-

Should be created from end user point of view (operational point of view), and should not be toomuch detail.

-Name of use case should be the name of operation in use, and name of class, name of attributes
should be the words used in the real operation.

39

【Point 07 Creating glossaries】
Create glossaries. It is efficient to classify common terminology and specified business terminology.
Generate it not only in Japanese but also in the offshore member‟s language (for example, Chinese or
English in the case of China). Include offshore member‟s language for specified business terminology todeliver the meaning more precisely.
It is strongly suggested to use English, and not to use Katakana.

【Purpose】
Improving offshore project members understanding of tasks and consistency. The offshore project
team will have clear naming rule to improve the followings.
・Understand design documentation from the Japanese project team・Prepare specification generation ability
・Use naming rule when the process is accepted and verified【Details ・Supplementation】

Terminology and contents are used to improve comprehension of tasks. Update version if glossary ischanged and notify all members of the update. If possible, the Japanese project team and the offshore
project team are informed that the glossary version is updated in real time.

【Relevant information 】
Point 08: Creating naming rules
UML Modeling Glossary
http://www.umtp-japan.org/modules/data4/index.php?id=240

【Point 08 Creating naming rules】
Create naming rules. Use naming rule standard needs to be created in the system analysis stage atleast.

【Purpose】
Produce the standard terminology in order to achieve the efficient requirement analysis and systemanalysis process output in development and improve the later process output. Offshore project members recognize naming rules and improve the following.
・Understand the design provided by the Japanese project team・Specification quality of offshore project team・Use naming rule when the process is accepted and verified

The Japanese project team also improves their review and design with misusing Japanese and lackof description.

【Details ・Supplementation】

It is convenient to generate rule to decide which language (Japanese or Chinese), digits/figures, androw classification will be used. It is also effective to describe them in both Japanese and English.
The following items decides the naming rule.
・ Subsystem/component name・ Package name・ Use case name・ Class name・ Attribute name and property name・ Operation name and method name・ Event name・ Message name・ Status name・ Screen ID、screen transition ID
and more.

【Relevant information 】
Point 07: Creating glossaries

41

【Point 09 Creating modeling rules.】Create modeling rules same as coding rules on implementation.

【Purpose】
Generate modeling rule for consistency of models made by the project members. It helps maintenance.

【Details ・Supplementation】

UML elements (class, package, and message etc.) are classified by explicit modeling rule and themeanings are more accurate. For example, class is divided into BCE (Boundary、Control、Entity) toperform system analysis, architecture design and detail design generally. Boundary indicates other system mediating class; control indicates flow control class; and entity indicates existing class in reality. In
addition, development project or exclusive rule in a business unit such as data delivery class, databaseexchange class, or time constraint message can be generated for better communication between
project members.
It is also advised to define level of authorization for changes in Models. For example, it could
be authorized for Offshore Partners to use “private” operation, subject to that Offshore Partners
needs approval from Owner (Japan) to use “public” operation.
UML extension function can be used when a modeling rule is generated if necessary. UML has UML
profile as a UML extension tool. UML extension by UML profile uses stereotype, limitation, and metaattribute specifically.

【Relevant information 】
Point 07 Creating glossaries.
Point 08 Creating naming rules.

42

【Point 10 Explicit common function】
Check for common functions in UML modeling process. The offshore project team can produce generalization based exclusively on the architecture by Japanese project team when Japanese project teamproduces the design/implementation.

【Purpose】
Improve quality and development efficiency. Solution is required for the intention such as the followings of offshore project members.
・ Offshore project members copy and modify samples provided, or from first development output repeatedly and consider the modification as another output.
・ Similar functions considered as common component/function/module can be generated from theresult of copied design or implementation.

【Details ・Supplementation】

Offshore project team generates common functions based on sample exclusively for efficient internal
development. It means they copy samples and produce again after generating the task sequence. The
Japanese team should provide architecture and guideline in advance and perform an analysis review inan early stage. Verify if common functions are generated concisely and the components are assigned
properly. For this, include the following.
・ Task item to verify common function in planning task process.
・ Task item to check common function included in reviewing.

【Relevant information 】
None

43

【Point 11 Architecture model】
Architecture Model means specific design of hardware and software basic structure. It isstrongly advised to create comprehensive architecture model and make sure that the models areequally understood among project members.

【Purpose】
Understand tasks to verify that the hardware and software architectures satisfy the client‟s business
request. That being a situation, it is advised that Owner (Japan) creates Architecture
Model. Architecture should be designed with future system extension in mind or change in a long term
because architecture change causes design/specification change as well.
There is a chance that any system enhancement or maintenance in the future may ends up
failing because of the insufficient understanding of system architecture of Owner (Japan) if
Offshore Partner is assigned to design system architecture.. In this situation, appropriate changes
and enhancement in the future may not be possible.

【Details ・Supplementation】

The Japanese project team prepares the system hardware/software/architecture for the development
project. In this case, consider the followings.

・Is the architecture reasonable for functional/non-functional aspect?
・How to implement the requested performance/capacity?
・How to solve the restraints from operational/test environment?
・How to perform operational requirements including trouble shooting?
・How to solve the security issues?
・How to manage development member‟s skills?

The Japanese project team designs the architecture model and forwards it to the offshore project
members as output. It will be helpful to prepare a guideline including „development sequence according
to hardware architecture and software architecture‟ in case of need.

【Relevant information 】
Point 12:Create output of architecture description

Appendix, Sample output: (1) Output of each process44③Process: Architecture design

【Point 12 Create output of architecture description】
Draw up output of system software architecture description.

【Purpose】
The Japanese and offshore project team members both equally understand the development system
software architecture when the process moves from requirement analysis ~ architecture design of theJapanese project team to detail design of offshore team in offshore development. The Japanese project
members should send information about the structures and/or ideas that the development system isbased upon.

【Details ・Supplementation】

Use supplementation as process input to verify the software architecture and draw up output from thearchitecture result. The architecture description output consists of class diagrams and other supplementary documents in system analysis ~ architecture design level.
Each diagram demonstrates ground generating design, decision points, or the intention/purpose of
the hardware/software architecture of development system in functional aspect. You can use component diagrams, package diagrams, and/or deployment diagrams if necessary. Description in Japanese
can be delivered concisely to offshore project members if you use diagrams of models.
The followings are as outputs on architecture modeling process.
・Input：non-functional requirement definition (Supplementary specification)・Output：architecture description, detail design guideline

It is not satisfactory if Architecture Model and Architecture Description have just been created. It
is even more important and required to make sure that these are in place and used.

【Relevant information 】
Point11 Architecture model
Appendix, Sample output: (1) Architecture description45

【Point 13 Using patterns】
It is recommended to use any Patterns, which are known well in architecture or design, either
in architecture design phase or detail design phase.

【Purpose】
Using Patterns commonly known among project members accelerates understanding of eachother, and helps providing more information for purpose and respons ibilities even without
sufficient explanation. This equally means there are more information for better communication.
This is extremely effective to communicate intention of architecture in thearchitecture designphase, or to communicate roles and intentions of Components and Classes in the detail designphase.

【Details ・Supplementation】

It is often happens that design patterns in the software development is explained in
combination with UML. Know-how in system design will be incorporated into design patterns
which are typically shared by engineers. Re-use or application of these design patterns contributes sustaining quality and brings common understanding successfully by design patterns in thecommunication in design phase or any review phases. Such architectural level patterns in thearchitecture design phase as MVC (Model, View and Control) helps project members
responsible for detail design to better communicate what the design intends. Such patterns usedin the detail design phase as GoF (Gang of Four) helps engineers to bette r assume roles andresponsibilities of each part of the process designed in any review processes. This also helps
checking actions as the points to be checked are effectively summarized. As such, suing
patterns are always helpful for all the project members to better understand each other ‟s workand outcome of it.
Mastering Patterns and usage of it is not mandatory in the Offshore Development. However, it
is truly believed that it helps communications among project members and fulfills skill level gap
among them. So, it is viewed that learning Patterns is certainly recommended.

【Relevant information 】
Point 06: Understanding business process by analysis models
Point 11: Architecture model
Point 12: Create output of architecture description46

【Point 14 Level of description of specification, format specification】
Specify level of description of UML and format specification for each respective specification
which is supposed to be the outcome of off-shore partner.

【Purpose】
Sample artifacts are often required in the off-shore development, not just in UML. Lack ofdetail direction from Japan to the off-shore partner‟s project members regarding how they should
describe specification will create inconsistent way of description and inconsist ent format among
the off-shore partner‟s project members. It is also recognized that there is not that much effort
by the off-shore partner‟s project members to try to make description level and format consistent.
It should be considered depending on the situation that the artifacts are to be presented withthe customers or to be reviewed by the Japanese project members.

【Details ・Supplementation】

Regarding UML contained in the artifact, Japan members create samples based applying thedetailed description and granularity of the models required by the Japanese members, andprovides them as part of the guideline. It is desirable to direct specific purposes of the modelsuch as what is expected to be done by the UML and what is to be shown by the UML. This
helps the team to be consistent in the level, accuracy, and granularity of UML.
Processes handling exceptions and errors need to be included in the sample appropriately.
(The off-shore partner expects that it is included in the sample at all times. So that it is not
likely included in the final artifact if not included in the sample.)
Such other points in descriptions for the artifacts to be cared should include 1) any
expressions should be specific, not vague, 2) words and terms used should be consistent, and3) words and terms in Katakana should be described in English.

【Relevant information 】
None

47

【Example of exception/error handling】
This system allocates the inventory when button of placing order is pressed, not when the
goods are put in the cart. If inventory are allocated to all the goods in the cart, it pr oceeds tothe order confirmation screen. If inventory is not allocated to even one item in the cart, all alloca
ted inventory should be released, return to the original screen and error message should beshown.

sd sample 14: user: cart screen: order process screen: order: cart: inventory

1: place an order()1.1: allocate inventory()
loop [for each goods]

1.1.1: put goods in the cart()

1.1.2: allocate inventory()

break[no inventory]alt
1.1.3: display()[available in inventory][no inventory]

1.1.4: release inventory allocated()

1.1.5: set error messages()

1.1.6: display()・Notice1)

It happens that the process satisfies specific condition is described (i.e., process inventory is
allocated in the case above) and that process not satisfying specific condition is not described (i.e.
process is not allocated in the case above). Accordingly, sample specification and diagram should
clearly state that both processes are required to be described.

2)

It needs to be recognized that error handling process (release of inventory allocated in theexample above) is not developed for production if it is not described in the specification.

3)

Error handling process requires detail and specific description what to do (setting error messages before returning to the cart screen, in the example above)

4)

Production environment and process depended on implementation should also be described
as required (such as stating error message id clearly, adding additional object where error messages
are sent)48

【Point 15 Creating detail design guideline】
Present undecided specification of output precisely to offshore members.

【Purpose】
The Japanese project team sends a development request with some undecided specifications for „requirement analysis ~ system analysis ~ architecture design process‟ to offshore project team due to thelack of time in some cases. The undecided specification can result in lots of questions from the offshore
project members because the output of the Japanese project team is inconsistent in many cases.

【Details ・Supplementation】

Define which specification has been undecided for the offshore project members to avoid any specification loss. It is often connected to specification change and specification missing.

Use notes or annotation including the following about undecided specification that is changeable orundefined in UML output.
・Which domain has undecided specification and which parts can be affected?
・What kind of change do you expect in the current specification? (Will it be more specific or changed todifferent contents?)

The Japanese project members should manage each item to avoid any loss or misleading change ofoffshore development parts when specification is decided or changed. In addition, check how offshore
members reflect the current change or later decided specification through the offshore company‟s
minute book and meeting minutes to confirm the development progress.

【Relevant information 】
Appendix, Sample output: (1) Detail design guideline49

【Point 16 Clarifying areas of which specifications are not determined】
Areas in the output of which specifications are not yet determined should be clearly presented to
the Offshore Partners. Offshore Partners should not proceed if specifications are not clearly com
municated and should confirm any undefined areas of specifications with the Owner (Japan).

【Purpose】
Verify output review. If you inform the offshore members that the Japanese project members aregoing to review the offshore output, sometimes the offshore members just send their output without reviewing it because they think „it is pointless to review it twice in both Japan and offshore sites‟.

【Details ・Supplementation】

Make agreement between the Japanese and offshore teams on output review including object to bereviewed, check point, and acceptance level performed by offshore project team. At the time, define thedifference of the review purposes between offshore company and The Japanese project team to improve the review of the offshore company explicitly.

Basic review points are;・ Check whether all the functions on development function plan are included.
・ Check whether all the specification in the entire design process is described.
・ Check whether the designated description level and notation are followed.
・ Check whether the consistent terminology is used precisely.
・ Check whether the expected static development structure is correctly delivered, designed, and described.
・ Check whether the expected dynamic development structure is correctly delivered, designed, anddescribed.
・ Check whether the expected physical alignment is correctly delivered, designed, and described.
・ Check whether the class responsibility is unclear.
・ Check whether the diagram consistency is ensured.
・ Check whether the specification change is reflected.

【Relevant information 】
None

50

【Point 17 Reviewing output by the offshore partner】
Start to check when the offshore project members kick off their development.

【Purpose】
The following can happen because communication is not normally in the offshore project member‟slanguage in offshore development.
・ The Japanese project team has difficulty ascertaining how much the offshore project members understand the project.
・ The offshore project team cannot recognize their misunderstanding.
Prepare against any misunderstanding between the Japanese and the offshore project members due
to miscomprehended and unconfirmed issues.

【Details ・Supplementation】

The Japanese project team checks the offshore team‟s status including the following often after theoffshore project members starts their development.
a) Check whether the output description is accurate.
b) Check whether the output notation standard is followed.
c) Check whether the design contents are understood correctly.
The Japanese project members should verify continuously the review results of the offshore project
members in the beginning of the process and during the process.
Furthermore, give advice to the offshore project members to verify development output andcomprehend each other during the development period. Offshore Partners should create Review
Reports at all times and the Owner (Japan) should review it as required.

【Relevant information 】
Point18 Repeating check by the owner (Japan)51

【Point 18 Repeating check by the owner (Japan)】
The Owner (Japan) should implement appropriate checking process immediately after theoffshore development effort has been started.
*It is to be noted that “check” hereby means, level of understanding and recognition, not justany sampling checks or as opposed to “review” which is typically conducted for more formal
authorization and confirmation..

【Purpose】
You can see inconsistent output often in offshore development even though it is not in UML. Offshore
project members frequently ask about inconsistent output from the Japanese project team. Sometimes
both teams cannot review their outputs due to the inconsistent output. It is required that all the necessar
y information should be contained in output without expecting readers to guess.
Offshore Development projects need to be closely reviewed as there might not be any output
in time or quality of outputs are not satisfactory. These effort needs to be closely monitored.
Checking process by the Owner (Japan) helps better quality and save workload. It is highly
recommended that the Owner should allocate appropriate number of days retain resources forthis particular checking effort.

【Details ・Supplementation】

In dynamic aspect
・Mutual class diagram/sequence diagram/communication diagram
・Mutual sequence diagram/state machine diagram/ activity diagram
In static/physical aspect
・Mutual class diagram/package diagram/object diagram/ component diagram/ deployment diagram
It is suggested that the Owner (Japan) executes review process of which done by Offshore
Partners in early stage of projects. The Owner (Japan) should check appropriate outputs at
appropriate timing of the project rather than checking all the detail outputs.
The Japanese project team should verify through detail design review the diagram consistency withcounterparts in several relevant diagrams as above. Also ensure if each diagram uses consistent terms
for the same subjects. Inconsistency, as shown below, causes implementation failures.

・ Some sequence operation causes unreadable recorded objects from class diagrams.
・ Some state transition trigger is unreadable from sequence diagram or activity diagram.
・ Component to be aligned in some node is unreadable from class diagram or component diagram.
【Relevant information 】
Point 17 Reviewing output by the offshore partner52

【Point 19 Validation and verification】
It is recommended to have two views. One is to validate the project for the Owner (Japan) toachieve its goal, and the other is to verify if things are successfully implemented by the Offshore
Partner.

【Purpose】
Roles and responsibilities are clearly defined in the Offshore Development project. Accordin gly,
it is expected that the Owner (Japan) tends to focus on customer ‟s business analysis throughsystem analysis, while Offshore Partners focus on detail design and unit test to satisfy needs
defined by the Owner. This different view occasionally creates misunderstanding in testing scope
and functional requirement. It is important to verify whether or not end customer‟s needs are allsatisfied. It is equally important to validate if implanted system satisfies end customer‟s needs.

【Details ・Supplementation】

The Offshore Partner tends to focus on verification to make sure that the system wasdeveloped to exactly meet with customer‟s needs, required specifications and functions are allsatisfied by cross checking programs and result of running those during unit test or join test
processes. On the other hand, the Owner (Japan) wants to validate many points whether or not
the production system satisfies end customer‟s business needs.
These different viewpoints between the Owner and Offshore Partner should be recognized andfollowing actions will be required in addition to the review done by the Offshore Partner which isprimarily “verification”.


The Owner should let the Offshore Partner know as early as possible during the
project what exact tests the Owner wants Offshore Partners execute, from validation
point of view

The Owner should prepare for validation viewpoint tests to execute which should
be conducted right after the Owner has received the outputs from the Offshore
Partner.

For example, Traceability Matrix, which is to verify how each required functions are implemented
and incorporated in the system by streamlining from needs analysis through implementation, isvery useful and it should be very effective once project members have been qualified from skill
point of view.

This guideline defines “review”, “check”, “validation” and “verification” as below.

53

Review process which targets to authorize the output can be interpreted either in “ it is ideal tobe reviewed by such two points of view as validation and verification, or “it is ideal to execute
variety of checking process to better monitor the progress of development project coordinated remotely, not just defined process of output review.”.

CheckReview

Validation

Verification【Relevant information 】
Point 01:

Define specific scope of work, roles and responsibilities

Point 17:

Reviewing output by the offshore partner

Point 18:

Repeating check by the owner (Japan)54

【Point 20 Reviewing detail design by the model】
Class Diagram, Sequence Diagram, Object Diagram, and Package Diagram are to be reviewed
for detail design.

【Purpose】
Directions such as system sequence and business flow need to be confirmed by the Model
before making it production. It is not necessary to follow source code. Review can be completed
by the Model (such as sequence diagram) because it is visual and is easy for every project
member.

Owner (Japan) can also review the detail design by the Model, which will improve

quality of the system in production.

【Details ・Supplementation】

Reviewing in offshore development is more important than any other usual development. However,the Japanese project members can have many numbers of review processes if you make too many detail items to check. Therefore, it is useful to use modeling.
The Owner‟s (Japan) project members create Architecture Description and Architecture
Guideline. The Offshore project members follow them and proceed to detail design. Then, theycreate such outputs as Sequence Diagram, Class Diagram, Object Diagram and Package
Diagram.
The Owner (Japan) needs to review such outputs as Sequence Diagram, Class Diagram,Object Diagram and Package Diagram created by the Offshore Partner.
Important point in this particular review process is to refer Architecture Description to makesure that Sequence Diagram, Class Diagram, Object Diagram and Package Diagram created by
the Offshore Partner are consistent with the architecture specified.

【Relevant information 】
Point 09:

Creating modeling rules

Point 12:Create output of architecture description

Point 15:

Creating detail design guideline

Point 21:

Consistency between UML diagrams55

【Point 21 Consistency between UML diagrams】
Consistency between UML diagrams created by the offsh ore partner need to be carefully
reviewed.

【Purpose】
It is common that there are inconsistency between outputs from the Owner and the Offshore
Partner. This could happen to any outputs, not just UML. Inconsistency in the output fromthe Owner (Japan) creates confusions and questions from the Offshore Partner. Inconsistency inthe output from the Offshore Partner creates difficulties for Japanese project members tounderstand the output correctly. Both organizations end up not being able to review their output
each other. So, it is extremely important to describe as much detail as possible in the output.
Creators should not ever expect Readers to understand the output in the way Creators expect
without complete description.

【Details ・ Supplementation】
In dynamic aspect
・Consistency between Class Diagram/Sequence Diagram/Communication Diagram
・Consistency between Sequence Diagram/State Machine Diagram/ Activity Diagram
In static/physical aspect
・Consistency between Class Diagram/Package Diagram/Object Diagram/ Component Diagram/
Deployment Diagram

The Japanese project team should verify through detail design review the diagram consistency withcounterparts in several relevant diagrams as above. Also ensure if each diagram uses consistent terms
for the same subjects. Inconsistency, as shown below, causes implementation failures.

・ Some sequence operation causes unreadable recorded objects from class diagrams.
・ Some state transition trigger is unreadable from sequence diagram or activity diagram.
・ Component to be aligned in some node is unreadable from class diagram or component diagram.

【Relevant information 】
None

56

【Example of integrity between UML diagrams】> Sequence diagram and class diagram
Special attention needs to be paid the following three integrities for sequence diagrams andclass diagrams.

Example: Search for goods by goods category・Lifeline and classClass in the class diagrams corresponding to the lifeline of sequence diagrams need to be
defined.

goods

goods category
search for goods(category)display of list of goods ( )goods selection ( )display of goods detail ( )

1

1..*

category

1

taking goods ( )getting detail information(goods)1..*

getting detail information(): goods category: category: goods

search for goods (category)taking goods ( )display list of goods ( )goods selection ( )getting detail information (goods ID)
getting detail information ( )display of goods detail ( )57

> Message and operation
In sequence diagrams, operation needs to be described in the class of the class diagram whichcorresponds to the lifeline where a message is called. Message call is possible by operation call.

goods

goods category
search for goods(category)display of list of goods ( )goods selection ( )display of goods detail ( )

1

1..*

category

1

1..*taking goods ( )getting detail information(goods)getting detail information(): goods category: category: goods

search for goods (category)taking goods ( )display list of goods ( )goods selection ( )getting detail information (goods ID)
getting detail information ( )display of goods detail ( )58

> Relationship with messages
In sequence diagrams, some relationships need to be described in between the class of theclass diagram which corresponds to the lifeline where a message is called.

goods

goods category
search for goods(category)display of list of goods ( )goods selection ( )display of goods detail ( )

1

1..*

category

1

1..*taking goods ( )getting detail information(goods)getting detail information(): goods category: category: goods

search for goods (category)taking goods ( )display list of goods ( )goods selection ( )getting detail information (goods ID)
getting detail information ( )display of goods detail ( )59In addition to the three examples introduced earlier, necessity of attribute in the class diagram
may be recognized occasionally.

: goods

goods category
search for goods(category)display of list of goods ( )goods selection ( )display of goods detail ( )

1

1..*

category

1

taking goods ( )getting detail information(goods)1..* name of goods
ID of goods
getting detail information ( ): goods category: category: goods

search for goods(category)taking goods ()
display list of goods ()

goods selection ()
getting detail information (goods
ID)getting detail information ()
display of goods detail ()

60

【Point 22 Using “code generation feature” in the tool for production (optional)】
It is suggested to create source code using the source code template created by the code
generation feature in the tool for production, if appropriate models are available. Tools do nothave to be used at all times. However, using tools brings higher productivity and more efficiency.
【Purpose】
In the process of detail design, the Owner (Japan) project team should review suchoutputs as Class Diagrams or Sequence Diagrams created by the Offshore Partner. This process
makes the model more reliable as it was already reviewed and confirmed that there is no error
in the model. Then, it is advised to use the code generation feature in the tool so that it makes
the source code even more reliable.
【Details ・Supplementation】

It would be possible to generate skeleton of source code by using code generation featurein the modeling tool for the Class. This makes possible to identify the context in the sourcecode by the model (Class Diagram) because such information as class name, attribute name,operation name will be available in the source code.
It requires checking the process flow (primarily Sequence Diagram) manually as genericmodels typically do not generate source code specifically for the sequence diagram (some of themodeling tools provide the feature to run the source code in production and reversely generate
the sequence diagram)【Relevant information 】
None

61

【Supplement: Unique nature of systems development in Japan】
This particular section is to make Owner‟s (Japan) unique nature clear in the systems
development environment and intends to get rid of the gap between the Owner and the Offshore
Partner.

【Purpose】
Systems development environment in Japan demonstrates the following unique nature of it.
・Project proceeds subject to repeated specification changes (people tend to believethat it would happen and unavoidable)
・Test coverage and management method must be complete and strict.
It is important to make the Owner‟s (Japan) unique nature of systems development environment
clear and reduce issues in the project by aligning the understanding of the Owner (Japan) andthe Offshore Partner.

【System Design】
It is important to create common understanding between the customer and developer (Owner andOffshore Partner) that changes in specification may impact significantly negatively to the project quality.

【Detail / Supplement】
The following might be considered reasons why changes in specification might happen.

① Common business practice or unique conditions in the customer industry (so to speak, common
understanding in the customer industry) are occasionally not described in the specification. These
typically become visible at delivery after all tests have been completed.

② Japanese customers tend to request in detail for screen layout and operation of the system.
③ Japanese customers typically request changes in specification even once it has been agreed.
④ The Owner (Japan) may occasionally ask the Offshore Partner to start their task (detail design)
even before the final specification gets completed.

62

【Development/Test】【Detail / Supplement】
The following request for the test should be satisfied.

① Test for all paths will be required
Variation or matrix of conditions, screen sequence and flow, complete code coverage(100% coverage expected).

② Evidence (test result) is fundamentally required.
・Evidence is required to clarify process pattern.
・Evidence is required if issues are recognized during development process.

③ Standard rates for tests items will be specified.
・Number of steps, number of screens, number of DB tables will be the base forstandard rates for the test items..
・Rate of each such case as Normal, Abnormal, Boundary will be specified.

④ Number of bugs during test process will be specified
・Test will be requested again if number of bugs in normal system, abnormal system arebelow each respective standard rate.
・It will be requested to review the entire system if numbers of bugs are many.

⑤ Many reports and documents during test process will be requested to present.
・List of bugs, list of issues and problems, bugs creation curve, quality management
report of test processes, and so forth.

63

Appendix A： Explanation of the examples used in the Points
Internet Shopping
A Company is considering starting selling a shopping system on the Internet.

> How to search for the goods
There are three ways to search for the goods.

1) Search by the goods category2) Search by the keywords
3) Search by the rank (by sales volume)1) Search by the goods category
There are several goods categories (such as books, magazines, CD, DVD), and each categorycontains the following items

Books
・Animation
・Medical・Entertainment
・Music Melody Books
・Science Technology
・Study Aid・Music・Education
・Living・Economy・Game・Engineering・Languages
・Children Books
・Computer・Qualification
・Dictionaries/
Encycropedias
・Performer's photos
・Geography
・Business
・History

Magazines
・Animation
・Music・Game・Marriage
・Health・Commic
・Computer
・Magazines
・Cars
・Bikes・Business
・Literature
・Life Style
・Cooking
・TravelCD
・J-POP・Animation
・Eas y Listening
・Enka
・Classic
・Jazz
・Pops
・Rock
・Game Music・Western Music

64

DVD・Foreign Movies
・Japanese Movies
・TV Drama・Music・Animation
・Comedy
・Variety・Hobbies
・Sports・idols・Adults

2) Search by the keywords
Select what to search, type in keyword, press search button, then goods hit the information will
be shown.
all categories ?

searchThe following all categories can be searched.
・All categories
・Books・Magazines
・CD・DVD
3) Search by the rank (by sales volume)
Choose what to search, press “rank” button, then goods will be shown by sales order sequence.
The following all categories can be searched.
・All categories
・Books・Magazines
・CD
・DVD>Display of goods
Choose goods, display goods information, and then the following goods information will be shown.
This is common for all the categories. Each category may have more information to be shown.
・goods name・picture of goods
・price・delivery schedule・description of goods at high level・description about the author or the artist
・customer comments and evaluation>Member registration
Member registration is required to purchase goods, send comments or evaluations. For member
registration, following information needs to be provided from the screen and register button needs
to be pressed. The system returns a confirmation e-mail to the e-mail address registered. Thisconfirmation e-mail has a URL which needs to be accessed to confirm the information registered,by pressing confirmation button.
・e-mail address (Log in ID)
・Name (Kanji, Furigana)65

・address
・phone number
・gender・default payment method (card, bank transfer, cash on delivery, convenience store)・log in password
When registration is completed, members can log in by log-in ID and log in password.
・purchasing goods
・input comments and evaluation for the goods
・confirmation of goods delivery schedule and status
・detail list of goods purchased
・change of members information
・closing account>Purchasing goods
Log-in is required prior to purchasing goods. You go to searching goods, list the goods to purchase,press “cart” button. You can put as many goods as you want in the cart. “What‟s in thecart” button can list all the goods in the cart. You can delete the goods that you really do notneed. “Order” button will lead you to the ordering process. You can choose delivery method (home delivery, post office delivery, and pick up at convenience store) and payment method (card,bank transfer, cash on delivery, or convenience sto re). Default payment method chosen atmember registration screen will be shown on this particular screen. Information typed in will besaved and can be used next time.
To complete ordering process, you should confirm list of goods purchased, total amount, thenpress “confirmation” button to confirm your order. Then, you will see purchase number on thescreen, and receive an e-mail which describes purchase number and list of goods purchased.
If you pick up your goods at the convenience store, you need to inform this purchase number
to the store clerk.

>Input comments and evaluations for the goods
Members can type in comments and evaluations for the goods by log-in. This input can be possible for any comments and evaluations for the goods which members do not buy. Comments canbe up to 300 characters. Evaluations should be 5 scale from 1 to 5, of which “5” is the best
evaluation.

>Checking goods delivery status
Members can confirm the delivery status of the goods purchased. After logged-in, member can
pop up the goods delivery status check screen, choose the purchase number of the goods thatmembers wants to check, and could see delivery status in more detaiｌ.

66

being prepared for shipping, on its way to the receiving store, delivered to the receiving
store
already delivered, being prepared for shipping, being shipped, already delivered>Display of list of goods purchased
You can display the list of goods purchased. You can even check the goods purchased and alre
ady delivered. After logged-in, you can display the list of goods purchased, and choose purchasenumber of the goods you want to check, then list of the goods selected will be shown.
>Change of member‟s information
You can change your member‟s information already registered. After logged-in, choose change ofmember‟s information and then screen of member‟s information is shown. Make any changes youneed to make and then update your member‟s information by pressing “update” button.
>Closing accountIf you choose closing account after logged-in, confirmation screen is shown. Then you choose closing the account, and then your account will be closed. Once account is closed, all member inf
ormation will be completely deleted. You will no longer be able to log in. All the features and fu
nctions available for you as a member will no longer be available.

>Registering administrator
An administrator can be registered by the screen not available for public. You need to type in administrator ID and associated password.
Administrator can benefit the same features as members can. Administrators can also use some
additional features as follows:・Registration of goods
・Change of goods‟ information
・Deleting goods information>Registration of goods
Administrator can register the goods by logging in through the screen not open to public.
Administrator chooses the category and input the following information. Some categories havemore information in addition to the following. These information needs to be registered as required.
・name of goods
・picture of goods
・price・delivery schedule・description of products at high level・description about the author or the artist
・customer comments and evaluation

67

>Change of goods information
Administrator can change the goods information by logging in through the screen not available tothe public. First you need to choose the goods to make any changes. There are a couple ofways to make these changes.
・ choose goods category and select targeted goods from the list of goods in the category.
・ search for the goods from search screen, and select targeted goods.
Goods already registered will be shown. Make necessary changes and apply these changes bypressing ”update” button.
>Deleting goods information
Administrator can delete goods information by logging in through the screen not available to the
public. Just like to change goods information, choose the goods and press “delete” button to delete goods information. Confirmation screen pops up and the goods information gets deleted.
<System use case diagram>memberregistration

search goods
customersearch by goods'
categories
search by
keywords
search by ranking
purchase goods

registration of
goods

enter comments
and evaluation of
goods

change of goods'
information

checking goods
delivery status
administrator

deletion of goods'
information

memberdisplay detail listof goods
purchasedchange ofmember's
information
closing theaccount

68

class diagramadministator

1

goods' categories

1

1..*

1

membere-mail addressname(Kanji)
name(Furigana)
Address
phone number
gender

0..1

default
payment
methodcatogories

1..*
1

past

0..*

1

0..*

1

activetransaction0..*purchase0..*

payment
method
1..4
registered1

1

name of the card issuer
ne numbername of the bankaccount number
account namename of goods

1..* picture of goods

1

0..*

price
delivery schedule
description of goods
at high level
authers or Artists

0..*comments
evaluation1

delivery statusdelivery method

payment methodbank transfer

0..*comments/
evaluation

1

1

card

goods

cash on delivery

pay atconvenience
storesstate machine diagram (screen transition)home delivery

postal officedeliverypick up atconvenience
stores※a part of screen for customers and members

stm state machine diagram
member registration screen
member registration
portallog in screen
log inlog off

display of results
log off
key word entry
result of key word search
log ingoods category

ranking

end

return69

list of goods

list of goods ranking

sequence diagram
sd sample 14: user: cart screen: order process screen: order: cart1: place an order()1.1: allocate inventory()
loop [for each goods]

1.1.1: put goods in the cart()

1.1.2: allocate inventory()

break[no inventory]alt
1.1.3: display()[available in inventory][no inventory]

1.1.4: release inventory allocated()

1.1.5: set error messages()

1.1.6: display()70: inventory

Appendix B. Sample outputs(1) Each process output (partial)① Requirement definition
Company A is verifying the employee information search system development. If a user enters keywords such as department, age, or address of employees, it displays the employee information. Every
employee can use this function.
The company employees are in technical/Technical/administration positions. The company has several
departments and the employees belong to departments. Some employees belong to several departments at a time. The administrator registers, modifies, or deletes employee information in the system
and registers, modifies, or deletes departments of employees also.

71

② Process： Requirement analysis (Japan ⇒ Offshore Partner)●Use case diagram
Search employee
information
Employees

Register employee
information

Modify employee
information

Delete employee
information
Administrator
Register
department

Modifydepartment

Deletedepartment72

● Activity diagram of use case (event flow)
Activity(event flow) of use case 「Register employee information」

Enter employee information

Choose position

Enter Technicalposition info

Enter Sales
position info

Enter administration
position info

Register in employee list

Activity diagram of use case 「Register department」 (event flow)

Enter department info

Register in department
minute book

※ Describe activity diagram(event flow) on the other use cases.

73

③ Process: System analysis (Japan ⇒ Offshore Partner)●Class diagram

Department

1..*

1

Department
minute book

1..*
1..*
1

1

1..*

Position

Technical

1

Employees

Sales

Employee list

Administration●「Register employee information」 sequence diagram

Sd Employee register：Register screen：Register
management：Employee list

：Administrator
Enter employee info
Employee register
Generation：Employee
Generation：Technicalposition

Register in employee list (Employees)

Register in department (Employees)

74：Department

●「Register department」 sequence diagram

Sd Register department
Department
register

Department
management

Department
minute book

Administrator
Enter department information
Department register
Generation
Department

Register in department template (Department)75

④ Process：Architecture design (Japan ⇒ Offshore Partner)●Class diagram

local

local
local

Register screen
RegisterManagement

parameter

Department DAO
Department

parameter

1..*

local

1..*
1
Position DAO

1Position

Employees

Employees DAO

Technical

Sales

Administration

parameter

local

76

●「Register employee information」 sequence diagram
Sd Employee register：Register screen：Register
management：Employees DAO：Technical DAO：Department DAO：Administrator
Enter employee information
DAO Abbreviationof making object

Employee register
Generation：Employees
Generation：Technical

Save Employee information (Employees)
Save Technical position information (Technical)

Department acquisition (Department information)
Generation (Department info
：Department
Register in department (Employees)

Department information maintenance (Department)77

⑤Process：Detail design (Offshore Partner ⇒ Japan)● Class diagram

local

local
local

Register screen
Registermanagement

parameter

Describe this partin details

Department DAO
Department

parameter

1..*

local

1..*
1
Position DAO

1Position

Employees

Employees DAO

Technical

Sales

Administration

parameter

local

local

Department
register

Department
management

Department

parameter
local
部署DAO

78

● Sequence diagram
Sd Register department
Department
register

Department
management

Administrator
Enter department info
Department register
Generation
Department

Generation
Department DAO

Save Department info (Department)79

(2) Architecture description
Version 0.1

Contents
Introduction
Architecture notation
Architecture purpose and limitation
Use case view
Logic view
Process view
Deployment view
Implement view
Size and performance
Quality
Introduction

80○Persistent use （use case view and part of logic view）

・Data Access Object (DAO) pattern use
Purpose：Understand the difference between persistent methods and database by classifying businesslogic and persistent implementation.
Role of DAO：DAO is in charge of CRUD of data.
DAO connects to database.

・Example: DAO pattern is introduced for system analysis model by using a simple example (Employee
register).
Class diagram of system analysis
RegisterscreenRegistermanagement

Employees

Sequence diagram of system analysis
Register screen

Registermanagement

Administrator
Enter employee info
Employee register
Generation
Employees

81Design model with DAO pattern
Class diagram
local
Register screen

Employees
Registermanagement

Employees DAO

local※ “Local” means to generate dependency class object among the dependency class operations in dependency relationships.

Sequence diagram
Register screen

Registermanagement

Employees DAO

Administrator
Enter employee info
Employee register
Generation
Employees

Save Employee info (Employees)「Employee DAO」class saves and loads 「Employee class」 database.

・
・
・

82

(3) Detail design guideline （partial）
Design class addition

・ Persistent Data Access Object (DAO) pattern
Each DAO class is drawn up for each entity class to be persisted.
DAO class name is entity class name + ”DAO”.

Employees

Employees DAO

・ Class diagram
Display the dependency relationships and enter the comment 「local」 because the control class draws
up new DAO class object locally and entity class. The DAO class receives the entity class as a parameter so that the dependency relationships need to be displayed with the comment „parameter‟.
local
Register screen
Employees
parameter

Registermanagement

Employees DAO

local

83

Sequence Diagram
Control class draws up and calls a DAO class object locally and calls it. Entity class is forwarded as aparameter in case of maintenance.

control Class

Register screen

Registermanagement

Administrator
entity ClassEnter employee info
Employee register
Generation
Employees

DAO Class

Genaration
Employees DAO

Save Employee info (Employees)

・
・
・
・

84

Forward employee
object withparameter

UML application guideline for offshore development
NPO UMTP
Offshore Software Development Working Group

Guideline preparation members
NameCompany

Masaru Adachi 足立 勝

Nikon Systems Inc.

Chunsheng Wang 王 春生

Oriental Standard Japan Co., Ltd.

Miho Oshita 大下 美穂

Bab-Hitachi Software K.K

Junichi Oka 岡純一

Japan Information Co., Ltd.

Hiroshi Ogura

小倉博

Open-Works Inc.

Naoki Kase 加瀬 直樹

Toshiba Corporation

Taro Kamioka 神岡 太郎

Graduate School of Commerce and Management, Hitotsubashi University

Akira Kamoshita 鴨下 明

Japan Systems Co. Ltd.

Yán Xu 許 炎

TONGHUA TECHNOLOGY (DALIAN) CO., LTD.

Ryuichi Konno 今野 隆一

Japan Systems Co.,Ltd

Hajime Saito 齋藤 肇

Hyron Software Co.,Ltd

Sutherland Maria サザーランド真理亜

Yokohama National University

Rui Shouda 正田 塁

Osaka Gas Information System Research Institute Co.,Ltd

Kazushi Takahashi 高橋 和司

Ad-Sol Nissin Corporation

Akitoshi Takemasa 竹政 昭利

Osaka Gas Information System Research Institute Co.,Ltd

Shigeru Tanaka 田中 繁

Open Works Inc.

Taku Nakajima 中嶋 拓

IT Engineering Ltd.

Tomohiro Nagase 永瀬 知洋

IT-Brain Corporation

Toshimasa Nakahara 中原 俊政

Bab-Hitachi Software K.K

Yohei Haba 幅 洋平

Bab-Hitachi Software K.K

Tsuyoshi Hamakawa 浜川 剛

Technologic Arts Incorporated

Tsunahiro Hidaka日高 綱弘

Nippon Information Co.,Ltd

Masahiko Hiroi 広井 政彦

Nikon Systems Inc.

Hiroyuki Fujino 藤野 博之

NEC Nexsolutions, Ltd

Shigetoshi Hosaka 保坂 成利

Chiyoda Corporation

Hiroshi Makino 牧野 宏

Open Resource Corporation

Toshitaka Mori 森 稔貴

Japan Information Co., Ltd.

Shoji Yamaguchi 山口 昭二

Sakura Information Systems Co., Ltd.

Ryo Yoshida 吉田 亮

IBM JapanXiãoｄōng Ｌｉａｎｇ 梁 暁冬

Meiji Yasuda System Technology Limited

Ryouji Wakabayashi 若林 良二

NEC Nexsolutions, Ltd

Copyright © NPO UMTP 2007-2010 All rights reserved85