oasis | advancing open standards for the information society€¦  · web viewany inadequacies...

74
Web Service Implementation Methodology Working Draft 01, 20 September 2004 Document identifier: document.doc Location: http://www.oasis-open.org/committees/documents.php? wg_abbrev=fwsi Editors: Lai Peng CHAN, Singapore Institute of Manufacturing Technology <[email protected]> Chai Hong ANG, Singapore Institute of Manufacturing Technology <[email protected]> Contributors: Eng Wah LEE, Singapore Institute of Manufacturing Technology <[email protected]> Puay Siew TAN, Singapore Institute of Manufacturing Technology <[email protected]> Yushi CHENG, Singapore Institute of Manufacturing Technology <[email protected]> Xingjian XU, Singapore Institute of Manufacturing Technology <[email protected]> Zun Liang YIN, Singapore Institute of Manufacturing Technology <[email protected]> Andy TAN, individual, <[email protected]> Roberto PASCUAL, The Infocomm Development Authority of Singapore <[email protected]> JAGDIP Talla, CrimsonLogic Pte Ltd <[email protected]> RAVI SHANKAR Narayanan Nair, CrimsonLogic Pte Ltd <[email protected]> Marc HAINES, individual <[email protected]> Abstract: This document specifies Web service specific activities in a Web service implementation methodology and illustrates the approach to incorporate these activities into an existing agile software development methodology. document.doc 20 September 2004 Copyright © OASIS Open 2004. All Rights Reserved. Page 1 of 74 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 1 2 3

Upload: others

Post on 08-Jul-2020

2 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: OASIS | Advancing open standards for the information society€¦  · Web viewAny inadequacies that may lead to possible security breaches should be reported and resolved by the

Web Service Implementation MethodologyWorking Draft 01, 30 September 2004Document identifier:

document.doc

Location:http://www.oasis-open.org/committees/documents.php?wg_abbrev=fwsi

Editors:Lai Peng CHAN, Singapore Institute of Manufacturing Technology <[email protected]>Chai Hong ANG, Singapore Institute of Manufacturing Technology <[email protected]>

Contributors:Eng Wah LEE, Singapore Institute of Manufacturing Technology<[email protected]>Puay Siew TAN, Singapore Institute of Manufacturing Technology<[email protected]>Yushi CHENG, Singapore Institute of Manufacturing Technology <[email protected]>Xingjian XU, Singapore Institute of Manufacturing Technology <[email protected]>Zun Liang YIN, Singapore Institute of Manufacturing Technology <[email protected]>Andy TAN, individual, <[email protected]>Roberto PASCUAL, The Infocomm Development Authority of Singapore <[email protected]>JAGDIP Talla, CrimsonLogic Pte Ltd <[email protected]>RAVI SHANKAR Narayanan Nair, CrimsonLogic Pte Ltd <[email protected]>Marc HAINES, individual <[email protected]>

Abstract:This document specifies Web service specific activities in a Web service implementation methodology and illustrates the approach to incorporate these activities into an existing agile software development methodology.

Status:This document is updated periodically on no particular schedule. Send comments to the editor.Committee members should send comments on this specification to the [email protected] list. Others should subscribe to and send comments to the [email protected] list. To subscribe, send an email message to [email protected] with the word "subscribe" as the body of the message.

document.doc 20 September 2004Copyright © OASIS Open 2004. All Rights Reserved. Page 1 of 59

1

2

3

4

56

78

910111213141516171819202122232425262728293031323334353637

3839404142434445

12

Page 2: OASIS | Advancing open standards for the information society€¦  · Web viewAny inadequacies that may lead to possible security breaches should be reported and resolved by the

For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the FWSI TC web page (http://www.oasis-open.org/committees/fwsi/).

document.doc 20 September 2004Copyright © OASIS Open 2004. All Rights Reserved. Page 2 of 59

46474849

34

Page 3: OASIS | Advancing open standards for the information society€¦  · Web viewAny inadequacies that may lead to possible security breaches should be reported and resolved by the

Table of Contents1 Introduction..................................................................................................................... 12

1.1 Purpose........................................................................................................................ 121.2 Target Audience...........................................................................................................121.3 Scope........................................................................................................................... 12

1.3.1 Not in Scope..........................................................................................................122 Implementation Methodology Overview.........................................................................13

2.1 Terminology.................................................................................................................. 132.2 Concepts...................................................................................................................... 13

2.2.1 Web Service..........................................................................................................132.2.2 Web Service Implementation Lifecycle..................................................................132.2.3 Phase.................................................................................................................... 13

2.2.3.1 Requirements Phase.....................................................................................................132.2.3.2 Analysis Phase..............................................................................................................142.2.3.3 Design Phase.................................................................................................................142.2.3.4 Coding Phase................................................................................................................142.2.3.5 Test Phase.....................................................................................................................142.2.3.6 Deployment Phase.........................................................................................................14

2.2.4 Activity................................................................................................................... 152.2.5 Role....................................................................................................................... 152.2.6 Artifact................................................................................................................... 15

3 Detailed Implementation Methodology...........................................................................163.1 Web Service Implementation Lifecycle.........................................................................18

3.1.1 Overview...............................................................................................................183.1.2 Requirements Phase.............................................................................................18

3.1.2.1 Activity: Determine the need for Web service................................................................183.1.2.1.1 Tasks......................................................................................................................183.1.2.1.2 Roles......................................................................................................................183.1.2.1.3 Artifacts..................................................................................................................18

3.1.2.2 Activity: Elicit Web service requirements.......................................................................183.1.2.2.1 Tasks......................................................................................................................183.1.2.2.2 Roles......................................................................................................................193.1.2.2.3 Artifacts..................................................................................................................19

3.1.2.3 Activity: Manage the Web service requirements............................................................193.1.2.3.1 Tasks......................................................................................................................193.1.2.3.2 Roles......................................................................................................................193.1.2.3.3 Artifacts..................................................................................................................19

3.1.2.4 Activity: Model the usage scenarios...............................................................................193.1.2.4.1 Tasks......................................................................................................................193.1.2.4.2 Roles......................................................................................................................193.1.2.4.3 Artifacts..................................................................................................................19

3.1.2.5 Activity: Prepare Test Cases for User Acceptance Test (UAT) and System Test.........203.1.2.5.1 Tasks......................................................................................................................203.1.2.5.2 Roles......................................................................................................................203.1.2.5.3 Artifacts..................................................................................................................20

3.1.3 Analysis Phase......................................................................................................203.1.3.1 Activity: Select a technology platform as implementation framework............................20

document.doc 20 September 2004Copyright © OASIS Open 2004. All Rights Reserved. Page 3 of 59

50

5152535455565758596061626364656667

686970717273747576777879808182838485868788899091929394

9596

56

Page 4: OASIS | Advancing open standards for the information society€¦  · Web viewAny inadequacies that may lead to possible security breaches should be reported and resolved by the

3.1.3.1.1 Tasks......................................................................................................................203.1.3.1.2 Roles......................................................................................................................203.1.3.1.3 Artifacts..................................................................................................................20

3.1.3.2 Activity: Define a candidate architecture for the Web service........................................213.1.3.2.1 Tasks......................................................................................................................213.1.3.2.2 Roles......................................................................................................................213.1.3.2.3 Artifacts..................................................................................................................21

3.1.3.3 Activity: Decide on the granularity of the Web service...................................................213.1.3.3.1 Tasks......................................................................................................................213.1.3.3.2 Roles......................................................................................................................213.1.3.3.3 Artifacts..................................................................................................................21

3.1.3.4 Activity: Identify reusable Web services.........................................................................213.1.3.4.1 Tasks......................................................................................................................213.1.3.4.2 Roles......................................................................................................................223.1.3.4.3 Artifacts..................................................................................................................22

3.1.3.5 Activity: Identify service interface contract for new Web services..................................223.1.3.5.1 Tasks......................................................................................................................223.1.3.5.2 Roles......................................................................................................................223.1.3.5.3 Artifacts..................................................................................................................22

3.1.3.6 Activity: Prepare Test Cases for Performance Test.......................................................223.1.3.6.1 Task.......................................................................................................................223.1.3.6.2 Roles......................................................................................................................223.1.3.6.3 Artifacts..................................................................................................................22

3.1.3.7 Activity: Prepare Test Cases for Integration / Interoperability Test................................223.1.3.7.1 Task.......................................................................................................................223.1.3.7.2 Roles......................................................................................................................233.1.3.7.3 Artifacts..................................................................................................................23

3.1.3.8 Activity: Prepare Test Cases for Functional Test...........................................................233.1.3.8.1 Task.......................................................................................................................233.1.3.8.2 Roles......................................................................................................................233.1.3.8.3 Artifacts..................................................................................................................23

3.1.3.9 Activity: Testbed preparation.........................................................................................233.1.3.9.1 Task.......................................................................................................................233.1.3.9.2 Roles......................................................................................................................233.1.3.9.3 Artifacts..................................................................................................................23

3.1.4 Design Phase........................................................................................................233.1.4.1 Activity: Transform signatures of reusable Web services..............................................23

3.1.4.1.1 Tasks......................................................................................................................233.1.4.1.2 Roles......................................................................................................................243.1.4.1.3 Artifacts..................................................................................................................24

3.1.4.2 Activity: Refine service interface of the new Web service..............................................243.1.4.2.1 Tasks......................................................................................................................243.1.4.2.2 Roles......................................................................................................................243.1.4.2.3 Artifacts..................................................................................................................24

3.1.4.3 Activity: Design Web service..........................................................................................243.1.4.3.1 Tasks......................................................................................................................243.1.4.3.2 Roles......................................................................................................................243.1.4.3.3 Artifacts..................................................................................................................24

3.1.4.4 Activity: Refine Test Cases for Functional Test.............................................................243.1.4.4.1 Task.......................................................................................................................243.1.4.4.2 Roles......................................................................................................................253.1.4.4.3 Artifacts..................................................................................................................25

document.doc 20 September 2004Copyright © OASIS Open 2004. All Rights Reserved. Page 4 of 59

979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131

132133134135136137138139140141142143144145146147148

78

Page 5: OASIS | Advancing open standards for the information society€¦  · Web viewAny inadequacies that may lead to possible security breaches should be reported and resolved by the

3.1.5 Coding Phase........................................................................................................253.1.5.1 Activity: Code internal workings of Web service............................................................25

3.1.5.1.1 Tasks......................................................................................................................253.1.5.1.2 Roles......................................................................................................................253.1.5.1.3 Artifacts..................................................................................................................25

3.1.5.2 Activity: Write the Web service consumer code.............................................................253.1.5.2.1 Tasks......................................................................................................................253.1.5.2.2 Roles......................................................................................................................263.1.5.2.3 Artifacts..................................................................................................................26

3.1.5.3 Activity: Unit Test Web service......................................................................................263.1.5.3.1 Tasks......................................................................................................................263.1.5.3.2 Roles......................................................................................................................263.1.5.3.3 Artifacts..................................................................................................................26

3.1.6 Test Phase............................................................................................................263.1.6.1 Activity: Test functionality of Web Services...................................................................27

3.1.6.1.1 Tasks......................................................................................................................273.1.6.1.2 Roles......................................................................................................................273.1.6.1.3 Artifacts..................................................................................................................27

3.1.6.2 Activity: Integration Test on the Web Services..............................................................273.1.6.2.1 Tasks......................................................................................................................273.1.6.2.2 Roles......................................................................................................................283.1.6.2.3 Artifacts..................................................................................................................28

3.1.6.3 Activity: System Test on the Web services....................................................................283.1.6.3.1 Tasks......................................................................................................................283.1.6.3.2 Roles......................................................................................................................283.1.6.3.3 Artifacts..................................................................................................................28

3.1.6.4 Activity: User Acceptance Test on the Web Services....................................................283.1.6.4.1 Tasks......................................................................................................................283.1.6.4.2 Roles......................................................................................................................283.1.6.4.3 Artifacts..................................................................................................................28

3.1.7 Deployment Phase................................................................................................293.1.7.1 Activity: Prepare deployment environment....................................................................29

3.1.7.1.1 Tasks......................................................................................................................293.1.7.1.2 Roles......................................................................................................................293.1.7.1.3 Artifacts..................................................................................................................29

3.1.7.2 Activity: Deploy Web service..........................................................................................293.1.7.2.1 Tasks......................................................................................................................293.1.7.2.2 Roles......................................................................................................................293.1.7.2.3 Artifacts..................................................................................................................29

3.1.7.3 Activity: Test deployment...............................................................................................293.1.7.3.1 Tasks......................................................................................................................293.1.7.3.2 Roles......................................................................................................................303.1.7.3.3 Artifacts..................................................................................................................30

3.1.7.4 Activity: Create end user support material.....................................................................303.1.7.4.1 Tasks......................................................................................................................303.1.7.4.2 Roles......................................................................................................................303.1.7.4.3 Artifacts..................................................................................................................30

3.1.7.5 Activity: Publish Web service.........................................................................................303.1.7.5.1 Tasks......................................................................................................................303.1.7.5.2 Roles......................................................................................................................303.1.7.5.3 Artifacts..................................................................................................................30

4 Case Example(s) of Applying the Implementation Methodology....................................31

document.doc 20 September 2004Copyright © OASIS Open 2004. All Rights Reserved. Page 5 of 59

149150151152153154155156157158159160161

162163164165166167168169170171172173174175176177178

179180181182183184185186187188189190191192193194195196197198199

200

910

Page 6: OASIS | Advancing open standards for the information society€¦  · Web viewAny inadequacies that may lead to possible security breaches should be reported and resolved by the

4.1 Rational Unified Process (Example).............................................................................314.1.1 Overview...............................................................................................................314.1.2 Approach...............................................................................................................33

4.1.2.1 Discipline: Requirements...............................................................................................344.1.2.1.1 Workflow Detail: Analyze the Problem...................................................................34

4.1.2.1.1.1 Activity: Capture a Common Vocabulary....................................................344.1.2.1.1.1.1 Role....................................................................................................34

4.1.2.1.1.1.2 Artifact.................................................................................................35

4.1.2.1.1.2 Activity: Develop Vision (across all Web services).....................................354.1.2.1.1.2.1 Role....................................................................................................35

4.1.2.1.1.2.2 Artifact.................................................................................................35

4.1.2.1.2 Workflow Detail: Understand Stakeholder Needs..................................................354.1.2.1.2.1 Activity: Elicit Needs...................................................................................35

4.1.2.1.2.1.1 Role....................................................................................................35

4.1.2.1.2.1.2 Artifact.................................................................................................35

4.1.2.1.2.2 Activity: Develop Vision..............................................................................354.1.2.1.2.2.1 Role....................................................................................................35

4.1.2.1.2.2.2 Artifact.................................................................................................35

4.1.2.1.2.3 Activity: Manage Dependencies.................................................................354.1.2.1.2.3.1 Role....................................................................................................36

4.1.2.1.2.3.2 Artifact.................................................................................................36

4.1.2.1.2.4 Activity: Find Actors and Use Cases (per Web service).............................364.1.2.1.2.4.1 Role....................................................................................................36

4.1.2.1.2.4.2 Artifact.................................................................................................36

4.1.2.1.3 Workflow Detail: Define the System.......................................................................364.1.2.1.3.1 Activity: Find Actors and Use Cases (per Web service).............................36

4.1.2.1.3.1.1 Role....................................................................................................36

4.1.2.1.3.1.2 Artifact.................................................................................................36

4.1.2.1.4 Workflow Detail: Manage the Scope of the System...............................................364.1.2.1.4.1 Activity: Prioritise the Use Cases (per Web service)..................................36

4.1.2.1.4.1.1 Role....................................................................................................36

4.1.2.1.4.1.2 Artifact.................................................................................................36

4.1.2.1.5 Workflow Detail: Refine the System Definition.......................................................374.1.2.1.5.1 Activity: Detail a Use Case.........................................................................37

4.1.2.1.5.1.1 Role....................................................................................................37

4.1.2.1.5.1.2 Artifact.................................................................................................37

4.1.2.1.5.2 Activity: Detail the Software Requirements................................................374.1.2.1.5.2.1 Role....................................................................................................37

4.1.2.1.5.2.2 Artifact.................................................................................................37

4.1.2.2 Discipline: Analysis and Design.....................................................................................384.1.2.2.1 Workflow Detail: Define a Candidate Architecture (for each Web service)............38

4.1.2.2.1.1 Activity: Architectural Analysis....................................................................384.1.2.2.1.1.1 Role....................................................................................................38

4.1.2.2.1.1.2 Artifact.................................................................................................38

4.1.2.2.2 Workflow Detail: Analyse Behaviour (for each use case)......................................38

document.doc 20 September 2004Copyright © OASIS Open 2004. All Rights Reserved. Page 6 of 59

201202203204205

206

207

208

209

210

211

212

213

214

215

216

217

218

219

220

221

222

223

224

225

226

227

228

229

230

231

232

233

234

235

236

237

238

239

240241

242

243

244

245

1112

Page 7: OASIS | Advancing open standards for the information society€¦  · Web viewAny inadequacies that may lead to possible security breaches should be reported and resolved by the

4.1.2.2.2.1 Activity: Use Case Analysis........................................................................384.1.2.2.2.1.1 Role....................................................................................................39

4.1.2.2.2.1.2 Artifact.................................................................................................39

4.1.2.2.3 Workflow Detail: Refine the Architecture (for each Web service)..........................394.1.2.2.3.1 Activity: Identify Design Elements..............................................................39

4.1.2.2.3.1.1 Role....................................................................................................39

4.1.2.2.3.1.2 Artifact.................................................................................................39

4.1.2.2.3.2 Activity: Identify Design Mechanisms.........................................................394.1.2.2.3.2.1 Role....................................................................................................39

4.1.2.2.3.2.2 Artifact.................................................................................................39

4.1.2.2.4 Workflow Detail: Design Components....................................................................394.1.2.2.4.1 Activity: Use Case Design..........................................................................39

4.1.2.2.4.1.1 Role....................................................................................................40

4.1.2.2.4.1.2 Artifact.................................................................................................40

4.1.2.2.4.2 Activity: Subsystem Design........................................................................404.1.2.2.4.2.1 Role....................................................................................................40

4.1.2.2.4.2.2 Artifact.................................................................................................40

4.1.2.2.4.3 Activity: Class Design.................................................................................404.1.2.2.4.3.1 Role....................................................................................................40

4.1.2.2.4.3.2 Artifact.................................................................................................40

4.1.2.3 Discipline: Implementation.............................................................................................414.1.2.3.1 Workflow Detail: Structure the Implementation Model...........................................41

4.1.2.3.1.1 Activity: Structure the Implementation Model.............................................414.1.2.3.1.1.1 Role....................................................................................................41

4.1.2.3.1.1.2 Artifact.................................................................................................41

4.1.2.3.2 Workflow Detail: Implement Components..............................................................414.1.2.3.2.1 Activity: Implement Design Elements.........................................................41

4.1.2.3.2.1.1 Role....................................................................................................42

4.1.2.3.2.1.2 Artifact.................................................................................................42

4.1.2.3.3 Workflow Detail: Integrate Each Web Service.......................................................424.1.2.3.3.1 Activity: Integrate Subsystem.....................................................................42

4.1.2.3.3.1.1 Role....................................................................................................42

4.1.2.3.3.1.2 Artifact.................................................................................................42

4.1.2.3.4 Workflow Detail: Manage the Scope of the System...............................................424.1.2.3.4.1 Activity: Prioritise the Use Cases (per Web service)..................................42

4.1.2.3.4.1.1 Role....................................................................................................42

4.1.2.3.4.1.2 Artifact.................................................................................................42

4.1.2.3.5 Workflow Detail: Refine the System Definition.......................................................424.1.2.3.5.1 Activity: Detail a Use Case.........................................................................42

4.1.2.3.5.1.1 Role....................................................................................................42

4.1.2.3.5.1.2 Artifact.................................................................................................42

4.1.2.3.5.2 Activity: Detail the Software Requirements................................................434.1.2.3.5.2.1 Role....................................................................................................43

4.1.2.3.5.2.2 Artifact.................................................................................................43

4.1.2.4 Discipline: Testing..........................................................................................................44

document.doc 20 September 2004Copyright © OASIS Open 2004. All Rights Reserved. Page 7 of 59

246

247

248

249

250

251

252

253

254

255

256

257

258

259

260

261

262

263

264

265

266267

268

269

270

271

272

273

274

275

276

277

278

279

280

281

282

283

284

285

286

287

288

289

290

1314

Page 8: OASIS | Advancing open standards for the information society€¦  · Web viewAny inadequacies that may lead to possible security breaches should be reported and resolved by the

4.1.2.4.1 Workflow Detail: Define Mission.............................................................................444.1.2.4.1.1 Activity: Identify Test Motivators.................................................................44

4.1.2.4.1.1.1 Role....................................................................................................45

4.1.2.4.1.1.2 Artifact.................................................................................................45

4.1.2.4.1.2 Activity: Agree on the Mission....................................................................454.1.2.4.1.2.1 Role....................................................................................................46

4.1.2.4.1.2.2 Artifact.................................................................................................46

4.1.2.4.1.3 Activity: Define Assessment and Traceability Needs.................................464.1.2.4.1.3.1 Role....................................................................................................46

4.1.2.4.1.3.2 Artifact.................................................................................................46

4.1.2.4.1.4 Activity: Define Test Approach...................................................................474.1.2.4.1.4.1 Role....................................................................................................47

4.1.2.4.1.4.2 Artifact.................................................................................................47

4.1.2.4.1.5 Activity: Identify Test Ideas.........................................................................474.1.2.4.1.5.1 Role....................................................................................................48

4.1.2.4.1.5.2 Artifact.................................................................................................48

4.1.2.4.2 Workflow Detail: Define Test Bed..........................................................................484.1.2.4.2.1 Activity: Identify Test Environment.............................................................48

4.1.2.4.2.1.1 Role....................................................................................................48

4.1.2.4.2.1.2 Artifact.................................................................................................48

4.1.2.4.2.2 Activity: Prepare H/W & S/W Infrastructure................................................484.1.2.4.2.2.1 Role....................................................................................................49

4.1.2.4.2.2.2 Artifact.................................................................................................49

4.1.2.4.2.3 Activity: Prepare Test Data Sets.................................................................494.1.2.4.2.3.1 Role....................................................................................................49

4.1.2.4.2.3.2 Artifact.................................................................................................49

4.1.2.4.3 Workflow Detail: Develop, Test and Evaluate........................................................494.1.2.4.3.1 Activity: Define Test Details........................................................................49

4.1.2.4.3.1.1 Role....................................................................................................49

4.1.2.4.3.1.2 Artifact.................................................................................................49

4.1.2.4.3.2 Activity: Implement Test.............................................................................504.1.2.4.3.2.1 Role....................................................................................................50

4.1.2.4.3.2.2 Artifact.................................................................................................50

4.1.2.4.3.3 Activity: Implement Test Suite....................................................................504.1.2.4.3.3.1 Role....................................................................................................50

4.1.2.4.3.3.2 Artifact.................................................................................................50

4.1.2.4.3.4 Activity: Execute Test Suite........................................................................504.1.2.4.3.4.1 Role....................................................................................................51

4.1.2.4.3.4.2 Artifact.................................................................................................51

4.1.2.4.3.5 Activity: Analyse Test Failures....................................................................514.1.2.4.3.5.1 Role....................................................................................................51

4.1.2.4.3.5.2 Artifact.................................................................................................51

4.1.2.4.3.6 Activity: Determine Test Results.................................................................514.1.2.4.3.6.1 Role....................................................................................................51

4.1.2.4.3.6.2 Artifact.................................................................................................51

document.doc 20 September 2004Copyright © OASIS Open 2004. All Rights Reserved. Page 8 of 59

291

292

293

294

295

296

297

298

299

300

301

302

303

304

305

306

307

308

309

310

311

312

313

314

315

316

317

318

319

320

321

322

323

324

325

326

327

328

329

330

331

332

333

334

335

1516

Page 9: OASIS | Advancing open standards for the information society€¦  · Web viewAny inadequacies that may lead to possible security breaches should be reported and resolved by the

4.1.2.4.4 Workflow Detail: Improve Test Assets...................................................................514.1.2.4.4.1 Activity: Define Test Approach (Refinement)..............................................51

4.1.2.4.4.1.1 Role....................................................................................................52

4.1.2.4.4.1.2 Artifact.................................................................................................52

4.1.2.4.4.2 Activity: Identify Test Ideas (Refinement)...................................................524.1.2.4.4.2.1 Role....................................................................................................52

4.1.2.4.4.2.2 Artifact.................................................................................................52

4.1.2.4.4.3 Activity: Prepare Guidelines for the Project................................................524.1.2.4.4.3.1 Role....................................................................................................52

4.1.2.4.4.3.2 Artifact.................................................................................................52

4.1.2.5 Discipline: Deployment..................................................................................................534.1.2.5.1 Workflow Detail: Plan Deployment.........................................................................53

4.1.2.5.1.1 Activity: Develop Deployment Plan.............................................................534.1.2.5.1.1.1 Role....................................................................................................53

4.1.2.5.1.1.2 Artifact.................................................................................................53

4.1.2.5.2 Workflow Detail: Develop Support Material............................................................544.1.2.5.2.1 Activity: Develop Training Material.............................................................54

4.1.2.5.2.1.1 Role....................................................................................................54

4.1.2.5.2.1.2 Artifact.................................................................................................54

4.1.2.5.2.2 Activity: Develop Support Material..............................................................544.1.2.5.2.2.1 Role....................................................................................................54

4.1.2.5.2.2.2 Artifact.................................................................................................54

4.1.2.5.3 Workflow Detail: Produce Deployment Unit (Web service)....................................544.1.2.5.3.1 Activity: Write Release Notes.....................................................................54

4.1.2.5.3.1.1 Role....................................................................................................54

4.1.2.5.3.1.2 Artifact.................................................................................................54

4.1.2.5.3.2 Activity: Develop Installation Artifacts.........................................................544.1.2.5.3.2.1 Role....................................................................................................54

4.1.2.5.3.2.2 Artifact.................................................................................................54

4.1.2.5.3.3 Activity: Create Deployment Unit (Web service).........................................554.1.2.5.3.3.1 Role....................................................................................................55

4.1.2.5.3.3.2 Artifact.................................................................................................55

4.1.2.5.3.4 Activity: Deploy Web Service to identified app servers..............................554.1.2.5.3.4.1 Role....................................................................................................55

4.1.2.5.3.4.2 Artifact.................................................................................................55

4.1.2.5.3.5 Activity: Publish Web service [optional]......................................................554.1.2.5.3.5.1 Role....................................................................................................55

4.1.2.5.3.5.2 Artifact.................................................................................................55

5 References..................................................................................................................... 565.1 Normative..................................................................................................................... 565.2 Non-Normative.............................................................................................................56

Appendix A. Acknowledgments...............................................................................................57Appendix B. Revision History..................................................................................................58Appendix C. Notices...............................................................................................................59

document.doc 20 September 2004Copyright © OASIS Open 2004. All Rights Reserved. Page 9 of 59

336

337

338

339

340

341

342

343

344

345

346347

348

349

350

351

352

353

354

355

356

357

358

359

360

361

362

363

364

365

366

367

368

369

370

371

372

373

374375376377378379

1718

Page 10: OASIS | Advancing open standards for the information society€¦  · Web viewAny inadequacies that may lead to possible security breaches should be reported and resolved by the

document.doc 20 September 2004Copyright © OASIS Open 2004. All Rights Reserved. Page 10 of 59

380

1920

Page 11: OASIS | Advancing open standards for the information society€¦  · Web viewAny inadequacies that may lead to possible security breaches should be reported and resolved by the

List of FiguresFigure 1: Web Service Implementation Methodology..............................................................17Figure 2: The "V" Model..........................................................................................................17Figure 3: The Rational Unified Process..................................................................................32Figure 4: The RUP development disciplines...........................................................................34Figure 5: Requirements Workflow...........................................................................................34Figure 6: Analysis and Design Workflow.................................................................................38Figure 7: Implementation Workflow.........................................................................................41Figure 8: Testing Workflow.....................................................................................................44Figure 9: Deployment Workflow..............................................................................................53

document.doc 20 September 2004Copyright © OASIS Open 2004. All Rights Reserved. Page 11 of 59

381

382383384385386387388389390

391

2122

Page 12: OASIS | Advancing open standards for the information society€¦  · Web viewAny inadequacies that may lead to possible security breaches should be reported and resolved by the

1 Introduction1.1 PurposeThe purpose of this document is to define a practical and extensible Web Service Implementation Methodology that can be used as a reference for Web service development and deployment. This document is a consolidation of the best practices by Web service practitioners and aims to improve the Web service implementation process through the formalization of a Web service implementation lifecycle and defining the Web service specific activities and artifacts.

This document should be used in conjunction with the Functional Elements1 specifications to govern the approach by which the Functional Elements are implemented, in a satisfactory manner.

1.2 Target AudienceThe target audiences are likely to be: Project Managers so as to have a formal methodology for Web service implementation,

which they can use for management and control. Software Architects/Designers/Developers/Testers to have identifiable activities which are

repeatable and which can be abide by, so as to ensure the quality of the software produced.

1.3 ScopeThis document details only the Web service specific activities, artifacts, roles and responsibilities that can be incorporated into an agile software development methodology (e.g. RUP, Extreme Programming, Feature Driven Development etc). A section is also included to illustrate how an agile software development methodology can be tailored to incorporate these Web service specific activities as part of the process.

1.3.1 Not in ScopeThis document does not define yet another software development methodology. Instead, the Web service implementation methodology leverages on an existing agile software methodology and extend it by incorporating the Web service specific activities.

Also, it is not in the scope of this document to specifically address how each of these software development methodology should be tailored to incorporate these Web service specific parts. An example is provided to only illustrate just one way of tailoring a specific agile development methodology for Web service implementation.

This document does not cover the detailed description or explanation of the existing agile software development methodologies as mentioned above nor does it recommend one particular agile software development methodology over another.

1 The Functional Elements are to be specified as components, which are to be exposed as web services where appropriate.

document.doc 20 September 2004Copyright © OASIS Open 2004. All Rights Reserved. Page 12 of 59

392

393394395396397398399400401402403

406407408409411412413414

416417418419420421422

423424425426427428429430431432433434435

2324

2526

Page 13: OASIS | Advancing open standards for the information society€¦  · Web viewAny inadequacies that may lead to possible security breaches should be reported and resolved by the

2 Implementation Methodology Overview2.1 TerminologyThe Web service implementation methodology defines a systematic approach to Web service development by leveraging on an agile software development methodology and extending that methodology by specifying the Web service specific activities and the corresponding roles and work-products that are produced in the process.

This methodology will define a set of common practices that create a method-independent framework, which can be applied by most software teams for developing Web Services applications.

2.2 Concepts

2.2.1 Web ServiceA Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP-messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards.

- W3C Definition

2.2.2 Web Service Implementation LifecycleA Web Service Implementation Lifecycle refers to the phases a Web service goes through between when it is conceived and when it is available for use.

The Web service implementation lifecycle typically includes the following phases: 1. Requirements Phase [see 2.2.3.1]2. Analysis Phase [see 2.2.3.2]3. Design Phase [see 2.2.3.3]4. Coding Phase [see 2.2.3.4]5. Test Phase [see 2.2.3.5]6. Deployment Phase [see 2.2.3.6]

The transitions through these phases need not be a single-pass, sequential process. On the contrary, the process tends to be iterative and incremental in nature and should be agile enough to accommodate revisions to the Web service in situations where the scope cannot be completely defined up front.

2.2.3 PhaseA Phase when used in the context of a Web service implementation lifecycle refers to the period of time a set of related software implementation activities are carried out.

In general, the phases detailed in the sub-sections are identified to be pertinent in a Web service implementation lifecycle. These phases may overlap with each other in the course of the implementation process.

2.2.3.1 Requirements PhaseThe objective in the requirements phase is to understand the business requirements and translating them to Web service requirements in terms of the features, the functional and non-functional requirements, and the constraints within which the Web service has to abide.

document.doc 20 September 2004Copyright © OASIS Open 2004. All Rights Reserved. Page 13 of 59

436

437438439440441442443444445

446

447448449450451452453

454455456457458459460461462463464465466467468469470

471472473474475476477

478479480481

2728

Page 14: OASIS | Advancing open standards for the information society€¦  · Web viewAny inadequacies that may lead to possible security breaches should be reported and resolved by the

Requirements elicitation should be done by the requirements analyst and should involve the project stakeholders such as the project champion, customers, end users, etc. Following which, the analyst should interpret, consolidate and communicate these requirements to the development team.

If possible, Requirements should be aggregated in a centralized repository where they can be viewed prioritized, and “mined” for iteration features. In all cases, enabling the team to easily capture requirements, search them, prioritize them and elaborate as necessary is the primary function of the repository.

2.2.3.2 Analysis PhaseIn the analysis phase, the requirements of the Web service are further refined and translated into conceptual models by which the technical development team can assimilate. It is also in this phase that an architecture analysis is done to define the high-level structure and identify the Web service interface contracts. This process should be performed by both the requirements analyst and the architect and communicated to the designers.

2.2.3.3 Design PhaseThe detailed design of the Web service is done in this phase. In this phase, the designers should define the Web service interface contract that has been identified in the analysis phase. The defined Web service interface contract should identify the elements and the corresponding data types (possibly using a XML schema) as well as mode of interaction between the Web service and the client, for example, whether it should be synchronous/asynchronous or RPC/Document style etc. Also the need to decide on the client programming model either Static Stub, Dynamic Proxy or DII (Dynamic Invocation Interface) should be done in this phase.

2.2.3.4 Coding PhaseThe coding and debugging phase for Web service implementation is essentially quite similar to other software component-based coding and debugging phase. The key differences lie in the creation of additional Web service interface wrappers (to expose the components’ public APIs), generation of WSDLs and client stubs. Web services in addition have to be deployed to a Web server/Application Server before the test clients can consume them.

The component developer and/or the tester should perform these activities.

2.2.3.5 Test PhaseFor testing of Web services, besides testing for functional correctness and completeness, testers should also perform interoperability testing between different Web/App servers and clients. Furthermore, performance testing has to be conducted to ensure that the Web services are able to withstand the maximum load and stress as specified in the non-functional requirements specification. Other tasks like profiling of the Web service application and inspection of SOAP messages should be done in this phase.

2.2.3.6 Deployment PhaseOnce the Web service has passed all the tests, it is now ready to be deployed by the deployer to be made available for consumption. The service end points of the Web service specifies where it is going to be deployed and needs to be identified and configured accordingly. The deployer primary tasks are to ensure that the Web service has been properly configuration managed (e.g. version controlled, presetting of configuration files, packaged and loaded in the

document.doc 20 September 2004Copyright © OASIS Open 2004. All Rights Reserved. Page 14 of 59

482483484485486487488489490491492

493494495496497498499

500501502503504505506507508509

510511512513514515516517518

519520521522523524525526

527528529530531532

2930

Page 15: OASIS | Advancing open standards for the information society€¦  · Web viewAny inadequacies that may lead to possible security breaches should be reported and resolved by the

correct location etc.) and running post-deployment tests to ensure that the Web service is indeed ready for use. Other optional tasks like specifying and registering the Web service with an UDDI registry may also be performed in this phase.

2.2.4 ActivityAn Activity refers to a unit of work a role may be assigned to perform. Activities are performed within each of the phases in the Web service implementation lifecycle. These activities will be described and elaborated in the next section.

2.2.5 RoleA Role refers to the responsibilities that a person or a team has been assigned with.Commonly defined roles include: Requirements Analyst - responsible for eliciting and interpreting the stakeholder needs,

and communicating those needs to the entire team. Architect - responsible for the software architecture, which includes the key technical

decisions that constrain the overall design and implementation for the project. Designer - responsible for designing a part of the system, within the constraints of the

requirements, architecture, and development process for the project. Developer - responsible for developing and testing components, in accordance with the

project's adopted standards. Deployer - responsible for planning the product's transition to the user community,

ensuring those plans are enacted appropriately, managing issues and monitoring progress.

Stakeholder – responsible for providing the domain expertise and specifying the system requirements. Stakeholder usually includes the project champion and the end users.

Project Manager – responsible for the deciding on the scope, schedule and staffing of the project team.

Test Manager - tasked with the overall responsibility for the test effort’s success. The role involves quality and test advocacy, resource planning and management, and resolution of issues that impede the test effort.

Test Designer - responsible for defining the test approach and ensuring its successful implementation. The role involves identifying the appropriate techniques, tools and guidelines to implement the required tests, and to give guidance on the corresponding resources requirements for the test effort. The role also involves monitoring detailed testing progress and results in each test cycle and evaluating the overall quality as a result of testing activities.

Tester - responsible for the core activities of the test effort, which involves conducting the necessary tests and logging the outcomes of that testing.

System Administrator – responsible for planning, installing and maintaining the hardware and software of the different environments e.g. development, test, live environment.

2.2.6 ArtifactAn Artifact refers to the work-product that is used or produced as a result of performing an activity. Examples of Artifacts include models, source files, scripts, and binary executable files.

document.doc 20 September 2004Copyright © OASIS Open 2004. All Rights Reserved. Page 15 of 59

533534535536

537538539540541

542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573

574575576577578

3132

Page 16: OASIS | Advancing open standards for the information society€¦  · Web viewAny inadequacies that may lead to possible security breaches should be reported and resolved by the

3 Detailed Implementation Methodology The term Web service describes a specialized type of software, which is designed to support a standardized way for provision and consumption of services over the Web, through the compliance with open standards such as eXtensible Markup Language (XML), SOAP, Web Services Description Language (WSDL) and Universal Description, Discovery and Integration (UDDI).

Web service, unlike traditional client/server systems, such as browser/Web server systems, is not meant for direct end-user consumption. Rather, Web services are pieces of business logic, which have programmatic interfaces and it is through these interfaces that developers can create new application systems.

The motivation behind Web services is to facilitate businesses to interact and integrate with other businesses and clients, without having to go through lengthy integration design and/or to expose its confidential internal application details unnecessarily. This is made possible by leveraging on the non-platform dependent, non-programming language dependent, XML, to describe the data to be exchanged between businesses or between the business and its clients; using a WSDL to specify what the service is providing; using a UDDI to publish and locate who is providing the service; and using SOAP over HTTP to transfer the message across the internet.

Web service, naturally, is a software element, but because of its specialized interface and mechanism to interoperate with others, all the prevalent generic software development methodology would need to be tailored to handle the unique features of Web service. This could translate to identification of Web service specific requirements (e.g. conformance to Web services standards), analysis of the specific implications of Web service on the overall system, design of the Web service interface and XML message structure, coding, testing, deployment and execution of the Web service.

The Web service implementation methodology that we define is to promote a systematic approach to Web service development. Rather than defining a new software development methodology and forcing software practitioners to forget their own familiar and established methodology to re-learn another, the better alternative is to leverage on what is already available and customize that methodology to incorporate the specifics of Web services.

The candidate software development methodology should, ideally, be agile and able to accommodate refinement throughout the development cycle in an iterative and incremental approach. The methodology should consists of phases that cover from the conception of the need of the Web service, to the construction of the Web service and finally to be deployed for use by the eventual client application. In this document, these phases are identified as requirements, analysis, design, code and debug, test and deployment.

The Web service implementation methodology would leverage on any of the candidate agile software development methodology and extend the said methodology by specifying additional and/or customized Web service specific activities and its corresponding roles and work-products. Figure 1 illustrates the proposed Web service implementation methodology.

document.doc 20 September 2004Copyright © OASIS Open 2004. All Rights Reserved. Page 16 of 59

579580581582583584585586587588589590591592593594595596597598599600601602603604605606607608609610611612613614615616617618619620621622623624625626

3334

Page 17: OASIS | Advancing open standards for the information society€¦  · Web viewAny inadequacies that may lead to possible security breaches should be reported and resolved by the

Web ServicesRequirements

Web ServicesAnalysis

Web ServicesDesign

Web ServicesCoding

Web ServicesTesting

Web ServicesDeployment

Leverage on Existing

Agile Software

Development MethodologyIteration 1 .. n

Web ServicesRequirements

Web ServicesAnalysis

Web ServicesDesign

Web ServicesCoding

Web ServicesTesting

Web ServicesDeployment

Leverage on Existing

Agile Software

Development MethodologyIteration 1 .. n

Figure 1: Web Service Implementation Methodology

The Web service implementation methodology is iterative and incremental. In each iteration, the Web service would goes through all the phases (i.e. requirements, analysis, design, code and debug, testing and finally deployment), thereby developing and refining the Web services throughout the project lifecycle.

In addition, for Web service testing, a multitude of tests have to be conducted to ensure that the Web service is developed according to its functional as well as non-functional requirements. Figure 2 illustrates using the “V” Model to perform these tests.

Legend Development PhaseDevelopment Phase Test Phase

ArchitecturalDesign Spec

ImplementationImplementation Source Codes

RequirementsRequirements RequirementsSpec

DesignDesign Design Spec

Unit Test

User AcceptanceTest Cases / Scripts

AnalysisAnalysis

System / Performance Test

Functional Test

Integration / Interoperability Test

System / PerformanceTest Cases / Scripts

User Acceptance Test

Integration / InteroperabilityTest Cases / Scripts

Functional TestCases / Scripts

Unit TestCases / Scripts

DeploymentDeployment

TestTest

Legend Development PhaseDevelopment Phase Test PhaseLegend Development PhaseDevelopment Phase Test Phase

ArchitecturalDesign Spec

ImplementationImplementation Source Codes

RequirementsRequirements RequirementsSpec

DesignDesign Design Spec

Unit Test

User AcceptanceTest Cases / Scripts

AnalysisAnalysis

System / Performance Test

Functional Test

Integration / Interoperability Test

System / PerformanceTest Cases / Scripts

User Acceptance Test

Integration / InteroperabilityTest Cases / Scripts

Functional TestCases / Scripts

Unit TestCases / Scripts

DeploymentDeployment

TestTest

ArchitecturalDesign Spec

ImplementationImplementation Source Codes

RequirementsRequirements RequirementsSpec

DesignDesign Design Spec

Unit Test

User AcceptanceTest Cases / Scripts

AnalysisAnalysis

System / Performance Test

Functional Test

Integration / Interoperability Test

System / PerformanceTest Cases / Scripts

User Acceptance Test

Integration / InteroperabilityTest Cases / Scripts

Functional TestCases / Scripts

Unit TestCases / Scripts

DeploymentDeployment

TestTest

Figure 2: The "V" Model

document.doc 20 September 2004Copyright © OASIS Open 2004. All Rights Reserved. Page 17 of 59

627628

629630631632633634635636637638

639640

3536

Page 18: OASIS | Advancing open standards for the information society€¦  · Web viewAny inadequacies that may lead to possible security breaches should be reported and resolved by the

The specifications produced in each of the phases are sources of input to derive the test scenarios and test cases. From these test cases, test scripts and test data are compiled, which will be used in unit testing, functional testing, integration/interoperability test, system/performance test and the final user acceptance test.

3.1 Web Service Implementation Lifecycle

3.1.1 Overview The Web Service Implementation Lifecycle describes the phases a typical Web service would undergo, from the identification of the need of the Web service to the final deployment and usage by the end-users. The phases identified to be relevant in the Web service implementation lifecycle are: requirements, analysis, design, code and debug, test and deployment. In each of these phases, Web service specific activities are carried out. These activities, as well as the roles and responsibilities, and the artifacts will be elaborated in the subsequent sub-sections.

3.1.2 Requirements Phase

3.1.2.1 Activity: Determine the need for Web service

3.1.2.1.1 Tasks Identify the stakeholders

Stakeholders would usually include the end users, project champion, project manager, etc.

Understand the inadequacies/problems to addressUnderstand the stakeholders’ need for Web services.

Identify the need for Web service technologyBased on the current technology available, identify needs specially for Web services.

Determine the positioning of the Web service within the boundaries of the problem identified

Define the features of the Web service based on the needs list

Identify the limitations to be imposed on the Web service

3.1.2.1.2 RolesArchitect, Requirements Analyst, Stakeholders, Project Manager

3.1.2.1.3 ArtifactsThe results should be recorded in Business Requirement Specifications.

3.1.2.2 Activity: Elicit Web service requirements

3.1.2.2.1 Tasks Identify the sources for requirements gathering based on the features list

Identify the departments, end users, domain experts, etc. who would be impacted by the introduction of Web services.

document.doc 20 September 2004Copyright © OASIS Open 2004. All Rights Reserved. Page 18 of 59

641642643644645

646

647648649650651652653654655

656

657

658659660661662663664665666667668669670671672673674

675676

677678679

680

681682683684685

3738

Page 19: OASIS | Advancing open standards for the information society€¦  · Web viewAny inadequacies that may lead to possible security breaches should be reported and resolved by the

Gather information from these sources and elicit the requirements for the Web service

Identify functional requirements for the Web service and categorise them

Identify non-functional requirements for the Web serviceNon-functional requirements are requirements pertaining to Usability, Reliability, Performance, Scalability, Supportability and other design considerations.

3.1.2.2.2 RolesRequirements Analyst, Architect, Test Manager

3.1.2.2.3 ArtifactsThe results should be recorded in Requirement Specifications.

3.1.2.3 Activity: Manage the Web service requirements

3.1.2.3.1 Tasks Based on the functional requirements categories, identify the Web services and

establish the dependencies and priorities

Create traceability matrices from the requirements to the identified Web servicesTraceability matrices help to track the requirements that have been taken care of by the Web services identified.

Manage changes to the requirements

3.1.2.3.2 RolesRequirements Analyst, Architect, Test Manager

3.1.2.3.3 ArtifactsThe results should be recorded in Requirement Specifications.

3.1.2.4 Activity: Model the usage scenarios

3.1.2.4.1 Tasks Translate the functional requirements into conceptual usage models using some form

of analysis modeling techniques

Specify the major interaction scenarios with the Web service clientsThis is to highlight the usage of Web services involved. Especially, the message exchange scenarios should be captured.

3.1.2.4.2 RolesRequirements Analyst, Architect, Test Manager

3.1.2.4.3 ArtifactsThe results should be recorded in Requirement Specifications.

document.doc 20 September 2004Copyright © OASIS Open 2004. All Rights Reserved. Page 19 of 59

686687688689690691692693

694695

696697698

699

700701702703704705706707708

709710

711712713

714

715716717718719720721

722723

724725726

3940

Page 20: OASIS | Advancing open standards for the information society€¦  · Web viewAny inadequacies that may lead to possible security breaches should be reported and resolved by the

3.1.2.5 Activity: Prepare Test Cases for User Acceptance Test (UAT) and System Test

3.1.2.5.1 Tasks Write business scenario test case(s) based on the requirements gathered to be used

for UAT and System TestTest case(s) can be derived from requirements. This is also a way to verify the requirements when they are implemented.

Build requirement validation matrixThe requirement validation matrix will include the requirements and a reference to the test case(s) that will validate the requirement.

Manage changes to the test cases when requirements changed

3.1.2.5.2 RolesRequirements Analyst, Test Manager, Test Designer

3.1.2.5.3 ArtifactsThe results should be recorded in Test Plan – UAT and System Test.

3.1.3 Analysis Phase

3.1.3.1 Activity: Select a technology platform as implementation framework

3.1.3.1.1 Tasks Specify the Web services standards that the implementation must adhere

Identify the Web service standards based on the requirements and implementation constraints. Consider issues like the standards compatibility, version of standards, standards adoption in industry sector, and the organization approving the standards.

Decide the technology platform for implementing Web servicesChoose technology platform that suitable for implementation. E.g. dotNet or Java platform.

Decide the technology platform for hosting Web servicesBased on implementation constrains and considerations for standards support and interoperability requirements, choose the appropriate hosting platform for Web services.

Decide the IDE tools used to develop Web servicesAvailable options include commercial vendor’s IDE tools, open source IDE tools. Normally, the selection of IDE is tied together with the implementation platforms.

3.1.3.1.2 RolesArchitect

3.1.3.1.3 ArtifactsThe results should be recorded in Software Architecture Specifications.

document.doc 20 September 2004Copyright © OASIS Open 2004. All Rights Reserved. Page 20 of 59

727728

729730731732733734735736737738739

740741

742743744745

746

747748

749750751752753754755756757758759760761762763764765766

767768

769770771

4142

Page 21: OASIS | Advancing open standards for the information society€¦  · Web viewAny inadequacies that may lead to possible security breaches should be reported and resolved by the

3.1.3.2 Activity: Define a candidate architecture for the Web service

3.1.3.2.1 Tasks Define a high-level architecture

Identify the architectural component that expose functionality as Web servicesIt is necessary to identify the architectural components that implement the wrapping of functionality as Web services and implement the message exchanges in the high level architecture.

Specify the major information exchange with Web service clientsIdentify and specify the first cut definition of message that is exchanged with Web services clients. The definition includes the element of data, data type and format.

3.1.3.2.2 RolesArchitect

3.1.3.2.3 ArtifactsThe results should be recorded in Software Architecture Specifications.

3.1.3.3 Activity: Decide on the granularity of the Web service

3.1.3.3.1 Tasks Decide on the coarseness of the Web service operations to be exposed

Set up criteria on the coarseness of Web services operations. Its definition depends the usage scenarios and requirements.

Identify and group functionality into the Web service.Based on the requirements and criteria mentioned above, identify the functions that are needed to group into the Web services.

Decide on the mechanisms to compose or aggregate functionalityIn case there is a need to compose individual Web services, choose and decide the mechanism to implement the compositions.

3.1.3.3.2 RolesArchitect

3.1.3.3.3 ArtifactsThe results should be recorded in Software Architecture Specifications.

3.1.3.4 Activity: Identify reusable Web services

3.1.3.4.1 Tasks Identify the architectural components that can be realized by existing Web services

If the functionality of architecture component can be fulfilled with existing Web services (internal or third party Web services), the architectural components should be identified to make use of these existing Web services.

Identify the Web service providers for the reusable Web servicesIdentify and gather the information about provider of existing Web services.

document.doc 20 September 2004Copyright © OASIS Open 2004. All Rights Reserved. Page 21 of 59

772

773774775776777778779780781782783

784785

786787788

789

790791792793794795796797798799800801

802803

804805806

807

808809810811812813814815816

4344

Page 22: OASIS | Advancing open standards for the information society€¦  · Web viewAny inadequacies that may lead to possible security breaches should be reported and resolved by the

Define the major invocation scenarios of re-useIdentify the functions that are going to be used. Define the interface of invocation.

3.1.3.4.2 RolesArchitect

3.1.3.4.3 ArtifactsThe results should be recorded in Software Architecture Specifications.

3.1.3.5 Activity: Identify service interface contract for new Web services

3.1.3.5.1 Tasks Define the new Web service operation signatures

Based on the usage models and analysis models, identify the operations and its signatures.

Define XML schema for the message exchangeIf message exchanges are involved, XML schema that guides the structure of message should be defined.

3.1.3.5.2 RolesArchitect, Designer

3.1.3.5.3 ArtifactsWeb Service Signature Specifications, XML schema.

3.1.3.6 Activity: Prepare Test Cases for Performance Test

3.1.3.6.1 Task Write performance test case(s) to be used for Performance Test

Test case(s) can be derived from Architectural Design Specifications.

These test cases should cover load testing scenarios to see how the system will perform under various loads (in terms of concurrent users/requests and/or transactions).

3.1.3.6.2 RolesTest System Administrator, Test Designer

3.1.3.6.3 ArtifactsThe results should be recorded in Test Plan – Performance Test.

3.1.3.7 Activity: Prepare Test Cases for Integration / Interoperability Test

3.1.3.7.1 Task Write integration / interoperability test case(s) to be used for Integration /

Interoperability TestTest case(s) can be derived from Architectural Design Specifications.

document.doc 20 September 2004Copyright © OASIS Open 2004. All Rights Reserved. Page 22 of 59

817818

819820

821822823

824

825826827828829830831832

833834

835836837

838

839840841842843844845

846847

848849850

851

852853854855

4546

Page 23: OASIS | Advancing open standards for the information society€¦  · Web viewAny inadequacies that may lead to possible security breaches should be reported and resolved by the

3.1.3.7.2 RolesTest Designer, Tester

3.1.3.7.3 ArtifactsThe results should be recorded in Test Plan – Integration / Interoperability Test.

3.1.3.8 Activity: Prepare Test Cases for Functional Test

3.1.3.8.1 Task Write functional test case(s) to be used for Functional Test

Test case(s) can be derived from Architectural Design Specifications.

3.1.3.8.2 RolesTest Designer, Tester

3.1.3.8.3 ArtifactsThe results should be recorded in Test Plan - Functional Test.

3.1.3.9 Activity: Testbed preparation

3.1.3.9.1 Task Set up testing environment that include hardware and software

This environment may be similar to the production/live environment in terms of hardware, OS, Web Server/Application Server, etc.

3.1.3.9.2 RolesTest System Administrator, Test Designer

3.1.3.9.3 ArtifactsThe results should be recorded in Test Plan - Testbed.

3.1.4 Design Phase

3.1.4.1 Activity: Transform signatures of reusable Web services

3.1.4.1.1 Tasks Identified the data type mapping if required

If the type of a parameter of the reusable service is not directly supported by the identified platform, data type mapping should be performed.

Identify the design patterns for mapping the re-used Web service interface to the identified (desired) oneCertain design patterns could be used to reuse existing Web service(s), such as adapter pattern, façade pattern etc. Adapter pattern could be used to expose a new interface of an existing Web service. The façade pattern could be used to encapsulate the complexity of existing Web services and provide a coarse-grained Web service.

document.doc 20 September 2004Copyright © OASIS Open 2004. All Rights Reserved. Page 23 of 59

856857

858859860

861

862863864

865866

867868869

870

871872873874875

876877

878879880881

882

883

884885886887888889890891892893894895

4748

Page 24: OASIS | Advancing open standards for the information society€¦  · Web viewAny inadequacies that may lead to possible security breaches should be reported and resolved by the

3.1.4.1.2 RolesDesigner

3.1.4.1.3 ArtifactsThe results should be recorded in the Design Specifications.

3.1.4.2 Activity: Refine service interface of the new Web service

3.1.4.2.1 Tasks Refine Web service interfaces signature

In the detailed design stage, the signature may be refined further. Care must be taken to ensure that the design decision should not affect the interoperability of the service.

Refine XML schema for message exchangeThe XML schema may be refined to further expand on the data structure, data types, namespaces etc.

3.1.4.2.2 RolesDesigner

3.1.4.2.3 ArtifactsThe results should be recorded in the Design Specifications.

3.1.4.3 Activity: Design Web service

3.1.4.3.1 Tasks Use some form of modeling techniques to describe the internal structure of the Web

serviceThe design of the internal structure needs to consider the receiving and pre-processing of request, delegating of the request, processing of the request and sending of the response. Existing modeling techniques such as UML, design patterns could be applied to the design.

Consider non-functional requirements (e.g. usability, reliability, performance, scalability etc) and design constraints (e.g. interoperability etc.)

3.1.4.3.2 RolesDesigner

3.1.4.3.3 ArtifactsThe results should be recorded in the Design Specifications.

3.1.4.4 Activity: Refine Test Cases for Functional Test

3.1.4.4.1 Task Refine functional test case(s) to be used for functional Test

Test case(s) can be refined by Design Specifications.

document.doc 20 September 2004Copyright © OASIS Open 2004. All Rights Reserved. Page 24 of 59

896897

898899900

901

902903904905906907908909

910911

912913914

915

916917918919920921922923924925

926927

928929930

931

932933934

4950

Page 25: OASIS | Advancing open standards for the information society€¦  · Web viewAny inadequacies that may lead to possible security breaches should be reported and resolved by the

3.1.4.4.2 RolesTest Designer, Tester

3.1.4.4.3 ArtifactsThe results should be recorded in Test Plan – Functional Test.

3.1.5 Coding Phase

3.1.5.1 Activity: Code internal workings of Web service

3.1.5.1.1 Tasks Based on the implementation language choice, code the Web service according

to the designConsider other constraints that are imposed by the specific implementation language itself. For example, consider the language dependent data types and the need to map these data types to the ones specified by the Web service interface.

Expose public APIs as Web service interfaceFor example, in Java, to create the interface class to expose the class method as a Web service operation or in dotNet, to annotate the class API as a [WebMethod].

Generate WSDL for client to consumeMost IDEs can auto-generate the WSDL from the interface code.

3.1.5.1.2 RolesDeveloper

3.1.5.1.3 ArtifactsWeb Service Implementation Codes.

3.1.5.2 Activity: Write the Web service consumer code

3.1.5.2.1 Tasks Decide on the Web Service Client programming modelAmong the three available:a) Static StubThe client invokes the Web service operation through a stub. Any IDE can generate this stub at compile time.

b) Dynamic ProxyAs the name implies, dynamic proxy is dynamically generated when the client application is executed. Because dynamic proxy is generated during runtime, Web Service invocation using this method takes the longest time amongst the three approaches.

c) DII (Dynamic Invocation Interface)Is the most flexible approach among the three programming models; the client does not even need to know the signature of the Web service operation until runtime. The Web service invocation can be dynamically constructed.

document.doc 20 September 2004Copyright © OASIS Open 2004. All Rights Reserved. Page 25 of 59

935936

937938939940

941

942

943944945946947948949950951952953954955956957

958959

960961962

963

964965966967968969970971972973974975976977978979980981

5152

Page 26: OASIS | Advancing open standards for the information society€¦  · Web viewAny inadequacies that may lead to possible security breaches should be reported and resolved by the

Hence, identify and decide on a suitable client programming model based on the weightage of flexibility against performance requirements.

Write client code to consume the Web serviceUse the WSDL to generate client stubs, which can be used in the client code to invoke the methods provided by the Web service.

3.1.5.2.2 RolesDeveloper

3.1.5.2.3 ArtifactsWeb Service Client Codes.

3.1.5.3 Activity: Unit Test Web service

3.1.5.3.1 Tasks Deploy Web service in local test environment and perform functional unit testing

The emphasis is on the correctness of the functionality and the exceptions handling.

3.1.5.3.2 RolesDeveloper

3.1.5.3.3 ArtifactsUnit Test Scripts.

3.1.6 Test PhaseFor Web services, additional tests may be conducted to ensure that the Web services are interoperable, secured and scalable.

Interoperability is an issue in Web services because the standards governing Web services are still evolving. Furthermore, different vendors that implement these specifications may interpret and comply with these specifications differently. Currently there is an effort by Web Services Interoperability Organization (WS-I) to recommend basic profiles to minimise these incompatibilities. The aim of conducting interoperability tests is to ensure that these reccomendations are followed and the Web service developed will interoperate with other Web services and products without problems.

Network congestion created by Web services is the major contributor to Web services’ slow performance. Not only is the messaging between requesters and Web services impacted by network latency, but also the service discovery and description protocols that precede those message exchanges. The cumulative effect of these delays can seriously degrade the performance of Web services. Therefore it is necessary to do a performance test on the Web services before they are deployed for operation, and then to monitor the Web services to determine if they can meet the service level agreements.

Web Services introduce special security issues e.g. in privacy, message integrity, authentication and authorization. Tests have to be conducted to ensure that these security requirements have been fulfilled. However, security schemes could complicate the process of testing and debugging Web service basic functionality. For example, nonintrusive monitors

document.doc 20 September 2004Copyright © OASIS Open 2004. All Rights Reserved. Page 26 of 59

982983984985986987988

989990

991992993

994

995996997998

9991000

1001100210031004

100510061007100810091010101110121013101410151016101710181019102010211022102310241025102610271028

5354

Page 27: OASIS | Advancing open standards for the information society€¦  · Web viewAny inadequacies that may lead to possible security breaches should be reported and resolved by the

are often used in functional testing but encrypted traffic presents an obvious complication to this approach to testing.

3.1.6.1 Activity: Test functionality of Web Services

3.1.6.1.1 Tasks Testing basic Web service functionality

The Web service should respond correctly to requests from their clients. The format of the SOAP message should be in compliance with the specifications. WSDL files, which contain metadata about Web services’ interfaces, should be in compliance with the WSDL specifications published by W3C. Perform fault checking to see how it handles unexpected input. The test scripts and data prepared in the earlier phases are executed in this activity. The test results should be recorded, and bugs found should be reported to the code owners and fixed by them.

Test for securityIf a service requires a certain level of privacy, or if it requires that messages be authenticated in a certain way, then specific tests are needed to ensure that these security requirements are met. The test scripts and test data prepared in the earlier phases should be executed in this activity. Any inadequacies that may lead to possible security breaches should be reported and resolved by the code owner, designer or architect.

Test the UDDI functionalityIf a service is registered to a registry server, perform registering of Web service, then write test clients to perform finding and binding of Web service on the registry, and then use the registry data to actually invoke the service. Test results from the test scripts and data should be recorded and bugs should be fixed by the code owners.

Test for SOAP intermediary capabilityIf particular SOAP message has one or more intermediaries along the message route that take actions based upon the instructions provided to them in the header of the SOAP message. Web service SOAP intermediary testing must verify the proper functionality of these intermediaries. Test results from the test scripts and data should be recorded and bugs should be fixed by the code owners.

3.1.6.1.2 RolesTester, Test Designer

3.1.6.1.3 ArtifactsThe results should be recorded in Client Test Code, Test Scripts and Test Results.

3.1.6.2 Activity: Integration Test on the Web Services

3.1.6.2.1 Tasks Test for conformance to Web Services Interoperability Organization (WS-I)

recommendations. Execute test scripts and data according to the test cases based on the WS-I recommendations.

Perform interoperability testing base on various scenariosThis is to highlight the interoperability issues of Web services implementation. Refer to Interoperability Guideline for the interoperability testing scenarios.

document.doc 20 September 2004Copyright © OASIS Open 2004. All Rights Reserved. Page 27 of 59

102910301031

1032

103310341035103610371038103910401041

10421043104410451046104710481049

105010511052105310541055

1056105710581059106010611062

10631064

106510661067

1068

10691070107110721073107410751076

5556

Page 28: OASIS | Advancing open standards for the information society€¦  · Web viewAny inadequacies that may lead to possible security breaches should be reported and resolved by the

Perform integration testing base on various scenariosBased on the test cases prepared in the Analysis Phase, test scripts and test data, which are prepared are executed and analysed in this activity.

3.1.6.2.2 RolesTester, Test Designer, Test System Administrator

3.1.6.2.3 ArtifactsThe results should be recorded in Client Test Code, Test Scripts and Test Results.

3.1.6.3 Activity: System Test on the Web services

3.1.6.3.1 Tasks Check system functionality and response time under different degrees of load

increasesThe test cases that are prepared in the earlier phases are executed in this activity. The load increases can be sudden surges or gradual ramp-ups.The test results should be analysed to determine potential bottlenecks and if the system is scalable.

Check functionality and response time under different combinations of valid and invalid requests.The results from the test execution should be analysed to determine if the system can still render the expected quality of service as specified in the non-functional requirement specifications.

3.1.6.3.2 RolesTester, Test Designer, Test System Administrator

3.1.6.3.3 ArtifactsThe results should be recorded in Client Test Code, Test Scripts and Test Results.

3.1.6.4 Activity: User Acceptance Test on the Web Services

3.1.6.4.1 Tasks Run the user acceptance test cases(s) for the Web services system.

The test cases prepared in the Requirement Phase are used in this activity to validate the correctness and completeness of the Web service system. Any bugs found should be reported and fixed by the code owners.

3.1.6.4.2 RolesUser, Test Manager, Test System Administrator

3.1.6.4.3 ArtifactsThe results should be recorded in Client Test Code, Test Scripts and Test Results.

document.doc 20 September 2004Copyright © OASIS Open 2004. All Rights Reserved. Page 28 of 59

1077107810791080

10811082

108310841085

1086

108710881089109010911092109310941095109610971098

10991100

110111021103

1104

11051106110711081109

11101111

111211131114

5758

Page 29: OASIS | Advancing open standards for the information society€¦  · Web viewAny inadequacies that may lead to possible security breaches should be reported and resolved by the

3.1.7 Deployment Phase

3.1.7.1 Activity: Prepare deployment environment

3.1.7.1.1 Tasks Set up and configure the hardware for Web service deployment

Set up and configure the software for Web service deploymentThe software may include application server, database, etc. The application server should have a SOAP listener to support Web services. Some Web services may need the SOAP handler to be configured.

3.1.7.1.2 RolesSystem Engineer

3.1.7.1.3 ArtifactsRelease Notes.

3.1.7.2 Activity: Deploy Web service

3.1.7.2.1 Tasks Determine service URL

Web service URL is unique and used to identify the Web service and where it is located.

Prepare the deployment scriptDeployment script is used to determine the steps of deployment. Although it different for different application server, most of them will include creation of directory, copying files, shutting down and restarting the server.

Deploy the Web serviceExecute the prepared deployment script.

Generate WSDL file

After successfully deploying the Web service, a WSDL file is needed to describe the functions provided by the Web service. WSDL can be created manually or by most application servers, which will automatically generate the WSDL file after deployment.

3.1.7.2.2 RolesDeveloper

3.1.7.2.3 ArtifactsWSDL File, Deployment Script.

3.1.7.3 Activity: Test deployment

3.1.7.3.1 Tasks Create (reuse) Web service client code

The Web service client code should be created by the developer during code and debug phase.

Consume Web service with the client code

document.doc 20 September 2004Copyright © OASIS Open 2004. All Rights Reserved. Page 29 of 59

1115

1116

1117111811191120112111221123

11241125

112611271128

1129

11301131113211331134113511361137113811391140114111421143114411451146

11471148

114911501151

1152

115311541155115611571158

5960

Page 30: OASIS | Advancing open standards for the information society€¦  · Web viewAny inadequacies that may lead to possible security breaches should be reported and resolved by the

Because the functionality of the Web Service is properly tested, there is no need to test all of the operations. To make sure the Web service is properly deployed and configured, the best candidates of operations for invocation are the ones needed for database connection, configuration of SOAP handler or any other special features of application server.

3.1.7.3.2 RolesTester

3.1.7.3.3 ArtifactsWeb Service Client Codes.

3.1.7.4 Activity: Create end user support material

3.1.7.4.1 Tasks Create end user support material.

The support material is needed to help the users to understand and use the Web service. For example, an interoperability guide of the Web service.

3.1.7.4.2 RolesDeveloper

3.1.7.4.3 ArtifactsInteroperability Guide, User Guide, On-line Help, Tutorials and Training Material.

3.1.7.5 Activity: Publish Web service

3.1.7.5.1 Tasks Identify the UDDI registry for publishing the Web service

Based on the requirements, decide whether a private or public UDDI registry is needed and the version of the UDDI Business Registry specifications to follow.

Prepare the information needed for publishing.The information may include key words for searching, description of Web service, URL of WSDL file, etc.

Publish the Web service in the UDDI registryNormally, the UDDI registry will support the publishing via browser.

Search the Web service by key words after publishing Search the Web service through browser provided by UDDI registry or tools provided by other vendors.

3.1.7.5.2 RolesDeveloper

3.1.7.5.3 ArtifactsNone.

document.doc 20 September 2004Copyright © OASIS Open 2004. All Rights Reserved. Page 30 of 59

11591160116111621163

11641165

116611671168

1169

1170117111721173

11741175

117611771178

1179

118011811182118311841185118611871188118911901191119211931194

11951196

119711981199

6162

Page 31: OASIS | Advancing open standards for the information society€¦  · Web viewAny inadequacies that may lead to possible security breaches should be reported and resolved by the

4 Case Example(s) of Applying the Implementation Methodology

The case example(s) aims to illustrate how an agile software methodology could be adapted to incorporate the Web services-specific activities described in the previous chapters.

It is not the intention of this Technical Committee to recommend any of the following case example(s) as the recommended agile software methodology to be used for Web services implementation. The Web service implementation methodology is intended to be generic and should be able to incorporate to any agile software methodology.

4.1 Rational Unified Process (Example)In this section, the Rational Unified Process (RUP) is illustrated as an example of how the Web service implementation methodology can be incorporated into RUP. Although the example tries to be as complete as possible, it is foreseeable that different projects set-up may be different in nature and would need to further customise this case example according to their needs.

4.1.1 Overview

The Rational Unified Process® is a software engineering process. It provides a disciplined approach to assigning tasks and responsibilities within a development organization. Its goal is to ensure the production of high quality software that meets the needs of its end users within a predictable schedule and budget.

As illustrated in Source: IBM-Rational Software, the overall architecture of RUP has two dimensions: the horizontal axis represents time and shows the lifecycle aspects of the process as it unfolds. This dimension is expressed in terms of phases, iterations and milestones. The vertical axis represents disciplines that logically group activities by nature. This second dimension portrays the static aspect of the process and is described in terms of process components, disciplines, activities, workflows, artifacts, and roles.

The “humps” in the graph illustrate the relative emphases of the disciplines change over the life of the project. For example, in early iterations more time is spent on Requirements, and in later iterations more time is spent on implementation.

document.doc 20 September 2004Copyright © OASIS Open 2004. All Rights Reserved. Page 31 of 59

1200

1201

120212031204120512061207120812091210

1211121212131214121512161217

1218

121912201221122212231224122512261227122812291230123112321233123412351236

6364

Page 32: OASIS | Advancing open standards for the information society€¦  · Web viewAny inadequacies that may lead to possible security breaches should be reported and resolved by the

Source: IBM-Rational Software

Figure 3: The Rational Unified Process

As the terms used in RUP are different from the terms used in Web Service Implementation Methodology, Table 1 maps the terms used between the two software methodologies.

RUP Web Service Implementation MethodologyPhases LifecycleDisciplines PhasesRoles Roles

Analyst System AnalystsRequirements Specifier

Analyst ArchitectRequirements Analyst

Developer Software ArchitectDesignerImplementerIntegrator

Developer DesignerDeveloperDeployer

Tester Test ManagerTest AnalystTest DesignerTesterTest System Administrator

Tester Test ManagerTest DesignerTesterTest System Administrator

Production & Support

Deployment ManagerDBAProcess Engineer

Others UserSystem EngineerProject ManagerStakeholder

Artifacts ArtifactsGlossaryVision

Business Requirement Specifications

Stakeholder RequestsRequirements AttributesRequirements Management PlanSoftware RequirementSoftware Requirements SpecificationsUse Case Model

Requirement Specifications

document.doc 20 September 2004Copyright © OASIS Open 2004. All Rights Reserved. Page 32 of 59

12371238

1239

124012411242124312441245

6566

Page 33: OASIS | Advancing open standards for the information society€¦  · Web viewAny inadequacies that may lead to possible security breaches should be reported and resolved by the

Supplementary SpecificationsSoftware Architecture Document Software Architecture SpecificationsDesign ModelAnalysis ModelUse Case Realization

Web Service Signature SpecificationsXML SchemaDesign Specifications

Test PlanTest Environment ConfigurationTest Strategy

Test Plan – UAT and System TestTest Plan – Performance TestTest Plan – Integration / Interoperability TestTest Plan – Functional Test

Test-Ideas ListTest CaseTest DataTest Suite

Test Plan – Testbed

Test Script Test ScriptsUnit Test ScriptsClient Test Code

Test LogTest Results

Test Results

Implementation ModelImplementation ElementBuild

Implementation CodesWeb Service Client Codes

Deployment Unit Release NotesDeployment ScriptsWSDL File

End-User Support Material Interoperability GuideUser GuideOn-line HelpTutorials

Training Materials Training MaterialsChange Request Not ApplicableDeployment Plan Not ApplicableInstallation Artifacts Not ApplicableProject Specific Guidelines Not ApplicableRelease Notes Not ApplicableTest Environment Summary Not Applicable

Table 1: Mapping of the terms used by both the RUP and the Web Service Implementation Methodology

4.1.2 Approach

In RUP, there are 9 disciplines altogether namely, Business Modeling, Requirements, Analysis & Design, Implementation, Test, Deployment, Configuration & Change Management, Project Management and Environment. However, as the focus of this Web service implementation methodology is on the implementation aspects only, the discplines Business Modeling, Configuration & Change Management, Project Management and Environment are beyond the scope of this document and will not be discussed here. The following disciplines as shown in Figure 4, are of interest and will be illustrated in detail in the subsequent sections.

document.doc 20 September 2004Copyright © OASIS Open 2004. All Rights Reserved. Page 33 of 59

1246

1247

1248

1249125012511252125312541255125612571258

6768

Page 34: OASIS | Advancing open standards for the information society€¦  · Web viewAny inadequacies that may lead to possible security breaches should be reported and resolved by the

Requirements Analysis and Design Implementation Testing DeploymentRequirements Analysis and Design Implementation Testing Deployment

Figure 4: The RUP development disciplines

For each of these disciplines, the relevant workflow details will be described and are extracted directly from RUP. Most of the activities in these workflow do not need special customisation. However, in areas where the activities are specific to Web services, these will be highlighted in bold2.

4.1.2.1 Discipline: Requirements

Requirements

•Analyze Problem•Capture a Common Vocabulary•Develop Vision (across all WS)

•Understand Stakeholder Needs•Elicit Needs

•Categorise needs into respective WSs•Identify potential WS

•Develop Vision•Refine the Categorisation Based on Features

•Manage Dependencies•Prioritise the WS

•Find Actors & UCs (per WS)•Define System

•Find Actors & UCs (per WS)•Manage Scope Of System

•Prioritise the UCs (per WS)•Refine System Definition

•Detail a UC•Detail the Software Requirements

Requirements

•Analyze Problem•Capture a Common Vocabulary•Develop Vision (across all WS)

•Understand Stakeholder Needs•Elicit Needs

•Categorise needs into respective WSs•Identify potential WS

•Develop Vision•Refine the Categorisation Based on Features

•Manage Dependencies•Prioritise the WS

•Find Actors & UCs (per WS)•Define System

•Find Actors & UCs (per WS)•Manage Scope Of System

•Prioritise the UCs (per WS)•Refine System Definition

•Detail a UC•Detail the Software Requirements

Source: IBM-Rational Software

Figure 5: Requirements Workflow

4.1.2.1.1 Workflow Detail: Analyze the Problem

4.1.2.1.1.1 Activity: Capture a Common Vocabulary- Find Common Terms

4.1.2.1.1.1.1 RoleSystem Analyst

2 The activities in italics represent refinement of an activity previously defined.

document.doc 20 September 2004Copyright © OASIS Open 2004. All Rights Reserved. Page 34 of 59

1259

12601261

126212631264126512661267

1268

12691270

1271

1272

1273

1274

12751276

12771278

69

7071

Page 35: OASIS | Advancing open standards for the information society€¦  · Web viewAny inadequacies that may lead to possible security breaches should be reported and resolved by the

4.1.2.1.1.1.2 ArtifactThe results should be recorded in Glossary.

4.1.2.1.1.2 Activity: Develop Vision (across all Web services)- Gain agreement on the some problems faced- Identify stakeholders of the Web services- Define boundaries of Web services- Identify (initial) constraints to be imposed on the Web services- Formulate Problem Statement (positioning why the need to develop Web services)

4.1.2.1.1.2.1 RoleSystem Analyst

4.1.2.1.1.2.2 ArtifactThe results should be recorded in Requirements Attributes and Vision.

4.1.2.1.2 Workflow Detail: Understand Stakeholder Needs

4.1.2.1.2.1 Activity: Elicit Needs- Determine sources for requirements (who and where can you gather the

requirements of Web services)- Gather information (based on stakeholders identified)- Conduct brainstorming session- Categorise the needs into respective Web services- Identify the Web services

4.1.2.1.2.1.1 RoleSystem Analyst

4.1.2.1.2.1.2 ArtifactThe results should be recorded in Stakeholder Requests.

4.1.2.1.2.2 Activity: Develop Vision- Gain agreement on the some problems faced- Identify stakeholders of the Web services- Refine boundaries of Web services- Identify the new constraints (or refine on existing constraints)- Formulate Problem Statement (positioning why the need to develop Web services)- Define features of the Web services based on the needs list- Refine the categorisation of the Web services based on the features

4.1.2.1.2.2.1 RoleSystem Analyst

4.1.2.1.2.2.2 ArtifactThe results should be recorded in Requirements Attributes and Vision.

4.1.2.1.2.3 Activity: Manage Dependencies- Assign attributes to the features of the Web services

document.doc 20 September 2004Copyright © OASIS Open 2004. All Rights Reserved. Page 35 of 59

127912801281

128212831284128512861287

12881289

129012911292

1293

1294129512961297129812991300

13011302

130313041305

13061307130813091310131113121313

13141315

131613171318

13191320

7273

Page 36: OASIS | Advancing open standards for the information society€¦  · Web viewAny inadequacies that may lead to possible security breaches should be reported and resolved by the

- Prioritise the Web services- Establish and verify traceability (what requirement types to be traced)- Manage changing requirements

4.1.2.1.2.3.1 RoleSystem Analyst

4.1.2.1.2.3.2 ArtifactThe results should be recorded in Requirements Attributes, Requirements Management Plan and Vision.

4.1.2.1.2.4 Activity: Find Actors and Use Cases (per Web service)- Find Actors- Find Use Cases- Create use case model

4.1.2.1.2.4.1 RoleSystem Analyst

4.1.2.1.2.4.2 ArtifactThe results should be recorded in Use Case Model and Supplementary Specifications.

4.1.2.1.3 Workflow Detail: Define the System

4.1.2.1.3.1 Activity: Find Actors and Use Cases (per Web service)- Find Actors- Find Use Cases- Refine use case model to include outlined use cases

4.1.2.1.3.1.1 RoleSystem Analyst

4.1.2.1.3.1.2 ArtifactThe results should be recorded in Use Case Model and Supplementary Specifications.

4.1.2.1.4 Workflow Detail: Manage the Scope of the System

4.1.2.1.4.1 Activity: Prioritise the Use Cases (per Web service)- Prioritise Use Cases and Scenarios

4.1.2.1.4.1.1 RoleSoftware Architect

4.1.2.1.4.1.2 ArtifactThe results should be recorded in Software Architecture Document and Software Requirement.

document.doc 20 September 2004Copyright © OASIS Open 2004. All Rights Reserved. Page 36 of 59

132113221323

13241325

1326132713281329

1330133113321333

13341335

133613371338

1339

1340134113421343

13441345

134613471348

1349

13501351

13521353

1354135513561357

7475

Page 37: OASIS | Advancing open standards for the information society€¦  · Web viewAny inadequacies that may lead to possible security breaches should be reported and resolved by the

4.1.2.1.5 Workflow Detail: Refine the System Definition

4.1.2.1.5.1 Activity: Detail a Use Case- Review and Refine the Scenarios- Detail the Flow of Events- Structure the Flow of Events- Describe any Special Requirements

4.1.2.1.5.1.1 RoleRequirements Specifier

4.1.2.1.5.1.2 ArtifactThe results should be recorded in Use Case Model, Supplementary Specifications.

4.1.2.1.5.2 Activity: Detail the Software Requirements- Detail the Software Requirements- Generate Supporting Reports (Use Case Model and Supplementary Specs)

4.1.2.1.5.2.1 RoleRequirements Specifier

4.1.2.1.5.2.2 ArtifactThe results should be recorded in Software Requirement and Software Requirements Specifications.

document.doc 20 September 2004Copyright © OASIS Open 2004. All Rights Reserved. Page 37 of 59

1358

13591360136113621363

13641365

136613671368

136913701371

13721373

1374137513761377

7677

Page 38: OASIS | Advancing open standards for the information society€¦  · Web viewAny inadequacies that may lead to possible security breaches should be reported and resolved by the

4.1.2.2 Discipline: Analysis and Design

Analysis and Design

•Define a Candidate Architecture (for each WS)

•Architectural Analysis•Identify WS Signatures•Identify possible 3rd party WS

•Analyse Behaviour (for each UC)•UC Analysis

•Refine the Architecture (for each WS)•Identify Design Elements

•Signature Mapping Translation•Confirm reuse of 3rd party WS•Identify WS to be built

•Identify Design Mechanisms•Design Components

•UC Design•Subsystem Design

•WS Signature Design•Class Design

Analysis and Design

•Define a Candidate Architecture (for each WS)

•Architectural Analysis•Identify WS Signatures•Identify possible 3rd party WS

•Analyse Behaviour (for each UC)•UC Analysis

•Refine the Architecture (for each WS)•Identify Design Elements

•Signature Mapping Translation•Confirm reuse of 3rd party WS•Identify WS to be built

•Identify Design Mechanisms•Design Components

•UC Design•Subsystem Design

•WS Signature Design•Class Design

Source: IBM-Rational Software

Figure 6: Analysis and Design Workflow

4.1.2.2.1 Workflow Detail: Define a Candidate Architecture (for each Web service)

4.1.2.2.1.1 Activity: Architectural Analysis- Define the high-level organization- Identify key abstractions- Identify analysis mechanisms- Identify the use case realization for the current iteration- Identify the Web Service signatures- Identify the possible 3rd party Web Service reuse

4.1.2.2.1.1.1 RoleSoftware Architect

4.1.2.2.1.1.2 ArtifactThe results should be recorded in Software Architecture Document and Design Model.

4.1.2.2.2 Workflow Detail: Analyse Behaviour (for each use case)

4.1.2.2.2.1 Activity: Use Case Analysis- Find analysis classes from Use Case Behaviour

document.doc 20 September 2004Copyright © OASIS Open 2004. All Rights Reserved. Page 38 of 59

1378

1379

13801381

1382

1383

13841385

1386138713881389139013911392

13931394

139513961397

1398

13991400

7879

Page 39: OASIS | Advancing open standards for the information society€¦  · Web viewAny inadequacies that may lead to possible security breaches should be reported and resolved by the

- Distribute behaviour to analysis classes- Describe responsibilities- Reconcile the use case realization- Qualify analysis mechanisms

4.1.2.2.2.1.1 RoleDesigner

4.1.2.2.2.1.2 ArtifactThe results should be recorded in Analysis Model and Use Case Realization.

4.1.2.2.3 Workflow Detail: Refine the Architecture (for each Web service)

4.1.2.2.3.1 Activity: Identify Design Elements- Signature mapping translation- Confirm reuse of 3rd party Web Services- Identify Web Services to be built- Identify classes and subsystems based on the activity Use Case Analysis- Identify subsystem interfaces

o Identify candidate interfaces (from internal or external source)o Look for similarities between interfaces

- Identify reuse opportunitieso Look for existing subsystems with similar interfaceso Modify the newly identified interfaces to improve the fit

- Update the organization of the design model

4.1.2.2.3.1.1 RoleSoftware Architect

4.1.2.2.3.1.2 ArtifactThe results should be recorded in Design Model.

4.1.2.2.3.2 Activity: Identify Design Mechanisms- Inventory the implementation mechanisms- Map design mechanisms to implementation mechanisms- Document architectural mechanisms (in terms of patterns)

4.1.2.2.3.2.1 RoleSoftware Architect

4.1.2.2.3.2.2 ArtifactThe results should be recorded in Software Architecture Document and Design Model.

4.1.2.2.4 Workflow Detail: Design Components

4.1.2.2.4.1 Activity: Use Case Design- Describe Interactions between design objects (refine interaction diagrams)- Simplify sequence diagrams with interfaces of subsystems (if any subsystems found)- Unify design classes and subsystems

document.doc 20 September 2004Copyright © OASIS Open 2004. All Rights Reserved. Page 39 of 59

1401140214031404

14051406

140714081409

1410

141114121413141414151416141714181419142014211422

14231424

142514261427

1428142914301431

14321433

143414351436

1437

1438143914401441

8081

Page 40: OASIS | Advancing open standards for the information society€¦  · Web viewAny inadequacies that may lead to possible security breaches should be reported and resolved by the

4.1.2.2.4.1.1 RoleDesigner

4.1.2.2.4.1.2 ArtifactThe results should be recorded in Design Model and Use Case Realization.

4.1.2.2.4.2 Activity: Subsystem Design- Interface realization (Web service signature design)- Distribute subsystem behaviour to subsystem elements (design the Web service)- Document subsystem elements (internal structure of the Web service)- Describe subsystem dependencies

4.1.2.2.4.2.1 RoleDesigner

4.1.2.2.4.2.2 ArtifactThe results should be recorded in Design Model.

4.1.2.2.4.3 Activity: Class Design- Create initial design classes- Define class visibility- Define operations- Define attributes- Define dependencies- Define associations- Define generalizations- Handle non-function requirements

4.1.2.2.4.3.1 RoleDesigner

4.1.2.2.4.3.2 ArtifactThe results should be recorded in Design Model.

document.doc 20 September 2004Copyright © OASIS Open 2004. All Rights Reserved. Page 40 of 59

14421443

144414451446

14471448144914501451

14521453

145414551456

145714581459146014611462146314641465

14661467

146814691470

8283

Page 41: OASIS | Advancing open standards for the information society€¦  · Web viewAny inadequacies that may lead to possible security breaches should be reported and resolved by the

4.1.2.3 Discipline: Implementation

Implementation

•Structure the Implementation Model

•Structure the Implementation Model

•Implement Components•Implement Design Elements

•Wrapping into WS•Integrate Each WS

•Integrate Subsystem•Aggregate WS for Application Development

•Manage Scope Of System•Prioritise the UCs (per WS)

•Refine System Definition•Detail a UC•Detail the Software Requirements

Implementation

•Structure the Implementation Model

•Structure the Implementation Model

•Implement Components•Implement Design Elements

•Wrapping into WS•Integrate Each WS

•Integrate Subsystem•Aggregate WS for Application Development

•Manage Scope Of System•Prioritise the UCs (per WS)

•Refine System Definition•Detail a UC•Detail the Software Requirements

Source: IBM-Rational Software

Figure 7: Implementation Workflow

4.1.2.3.1 Workflow Detail: Structure the Implementation Model

4.1.2.3.1.1 Activity: Structure the Implementation Model- Establish the implementation model structure- Define imports for each implementation components- Decide how to treat executables (and other derived objects)

4.1.2.3.1.1.1 RoleSoftware Architect

4.1.2.3.1.1.2 ArtifactThe results should be recorded in Software Architecture Document and Implementation Model.

4.1.2.3.2 Workflow Detail: Implement Components

4.1.2.3.2.1 Activity: Implement Design Elements- Implement operations- Implement associations- Implement attributes- Provide feedback to design

document.doc 20 September 2004Copyright © OASIS Open 2004. All Rights Reserved. Page 41 of 59

1471

1472

14731474

1475

1476

1477

1478147914801481

14821483

1484148514861487

1488

14891490149114921493

8485

Page 42: OASIS | Advancing open standards for the information society€¦  · Web viewAny inadequacies that may lead to possible security breaches should be reported and resolved by the

- Wrapping into Web Service

4.1.2.3.2.1.1 RoleImplementer

4.1.2.3.2.1.2 ArtifactThe results should be recorded in Implementation Element.

4.1.2.3.3 Workflow Detail: Integrate Each Web Service

4.1.2.3.3.1 Activity: Integrate Subsystem- Integrate implementation elements- Aggregate Web Service for application development

4.1.2.3.3.1.1 RoleIntegrator

4.1.2.3.3.1.2 ArtifactThe results should be recorded in Build and Implementation Model.

4.1.2.3.4 Workflow Detail: Manage the Scope of the System

4.1.2.3.4.1 Activity: Prioritise the Use Cases (per Web service)- Prioritise Use Cases and Scenarios

4.1.2.3.4.1.1 RoleSoftware Architect

4.1.2.3.4.1.2 ArtifactThe results should be recorded in Software Architecture Document and Software Requirement.

4.1.2.3.5 Workflow Detail: Refine the System Definition

4.1.2.3.5.1 Activity: Detail a Use Case- Review and Refine the Scenarios- Detail the Flow of Events- Structure the Flow of Events- Describe any Special Requirements

4.1.2.3.5.1.1 RoleRequirement Specifier

4.1.2.3.5.1.2 ArtifactThe results should be recorded in Use Case Model and Supplementary Specifications.

document.doc 20 September 2004Copyright © OASIS Open 2004. All Rights Reserved. Page 42 of 59

1494

14951496

149714981499

1500

150115021503

15041505

150615071508

1509

15101511

15121513

1514151515161517

1518

15191520152115221523

15241525

152615271528

8687

Page 43: OASIS | Advancing open standards for the information society€¦  · Web viewAny inadequacies that may lead to possible security breaches should be reported and resolved by the

4.1.2.3.5.2 Activity: Detail the Software Requirements- Detail the Software Requirements- Generate Supporting Reports (Use Case Model and Supplementary Specs)

4.1.2.3.5.2.1 RoleRequirement Specifier

4.1.2.3.5.2.2 ArtifactThe results should be recorded in Software Requirement and Software Requirements Specifications.

document.doc 20 September 2004Copyright © OASIS Open 2004. All Rights Reserved. Page 43 of 59

152915301531

15321533

1534153515361537

8889

Page 44: OASIS | Advancing open standards for the information society€¦  · Web viewAny inadequacies that may lead to possible security breaches should be reported and resolved by the

4.1.2.4 Discipline: Testing

Source: IBM-Rational Software

Figure 8: Testing Workflow

4.1.2.4.1 Workflow Detail: Define Mission

4.1.2.4.1.1 Activity: Identify Test Motivators- Identify iteration target items

o Web serviceso configuration (deployment platform)

- Gather and examine related informationo dependencies of services to be tested

other services configuration (deployment platform)

- Identify candidate motivatorso Web services

functionality usability

document.doc 20 September 2004Copyright © OASIS Open 2004. All Rights Reserved. Page 44 of 59

Testing

•Define Mission• Identify Test Motivators

•Functionality•Reliability•Performance•interoperability

• Agree on Mission• Define Assessment &

Traceability Needs• Define Test Approach

•API Level•SOAP Level

• Identify Test ideas•Define Test Bed

• Identify Test Environment• Prepare H/W & S/W Infrastructure• Prepare Test Data Sets

•Develop, Test & Evaluate• Define Test Details• Implement Test

•Generate WS Client• Implement Test Suite• Execute Test Suite• Analyse Test Failures• Determine Test Results

•Improve Test Assets• Define Test Approach• Identify Test Ideas• Prepare Guidelines for Project

Testing

•Define Mission• Identify Test Motivators

•Functionality•Reliability•Performance•interoperability

• Agree on Mission• Define Assessment &

Traceability Needs• Define Test Approach

•API Level•SOAP Level

• Identify Test ideas•Define Test Bed

• Identify Test Environment• Prepare H/W & S/W Infrastructure• Prepare Test Data Sets

•Develop, Test & Evaluate• Define Test Details• Implement Test

•Generate WS Client• Implement Test Suite• Execute Test Suite• Analyse Test Failures• Determine Test Results

•Improve Test Assets• Define Test Approach• Identify Test Ideas• Prepare Guidelines for Project

1538

1539

1541

1542

1543

1544

154515461547154815491550155115521553155415551556

9091

Page 45: OASIS | Advancing open standards for the information society€¦  · Web viewAny inadequacies that may lead to possible security breaches should be reported and resolved by the

reliability performance supportability

- Determine quality riskso prioritise the tests requirements

architecture significant value of service stability

o define the acceptable quality level- Define motivator list

o define the specific Web services ready to be tested- Maintain traceability relationships

o manage the test requirements to the other requirements impact analysis

- Evaluate and verify your resultso verify with team members on the objectives of this activity

4.1.2.4.1.1.1 RoleTest Manager

4.1.2.4.1.1.2 ArtifactThe results should be recorded in Test Plan.

4.1.2.4.1.2 Activity: Agree on the Mission- Investigate options for the scope of the assessment effort

o determine the resources needed to achieve the testingo scope the test based on existing resources

- Formulate mission statemento determine a balance between the need for:

Test for correctness Test for completeness

o determine Test Coverage Code Test requirements Defect Test Result

o determine the necessary stages of testing Unit (Formal/Informal) Integration (Formal/Informal) System (Formal) UAT (Formal)

- Identify test deliverableso Test Plan (based on type of tests)

Test Cases (high-level) Test Scenarios (test case)

o Explanationo Deriving Test Cases from Use Caseso Deriving Test Cases from Supplementary

Specifications Deriving Test Cases for Performance Tests Deriving Test Cases for Security / Access

Tests Deriving Test Cases for Configuration Tests Deriving Test Cases for Installation Tests Deriving Test Cases for other Non

Functional Tests

document.doc 20 September 2004Copyright © OASIS Open 2004. All Rights Reserved. Page 45 of 59

1557155815591560156115621563156415651566156715681569157015711572

15731574

157515761577

157815791580158115821583158415851586158715881589159015911592159315941595159615971598159916001601160216031604160516061607160816091610

9293

Page 46: OASIS | Advancing open standards for the information society€¦  · Web viewAny inadequacies that may lead to possible security breaches should be reported and resolved by the

o Deriving Test Cases for Product Acceptance Testso Build Verification Test Cases for Regression Testso Defining Test Data for Test Caseso use the existing test ideas as a mean to identify

possible scenarioso verify all extension points where not explicitly defined

Test Procedures/Steps Test Scripts

Test Result- Evaluate and verify your results

o verify with team members and stakeholder on the objectives of this activity

4.1.2.4.1.2.1 RoleTest Manager

4.1.2.4.1.2.2 ArtifactThe results should be recorded in Test Plan.

4.1.2.4.1.3 Activity: Define Assessment and Traceability Needs- Identify assessment and traceability requirements

o how to assess formal and informal testing- Consider constraints

o limitation that prohibits the testing effort existing skills set availability of resources

tools information process skills set

- Consider possible strategieso acquire required skills

vendor training

o outsource- Define and agree on the assessment strategy

o define checkpoint to assess the strategy (verify test approach)- Define tool requirements

o Use existing tool Good match Workaround solution Acquire new technology

o Increase productivity Regression testing

- Evaluate and verify your resultso verify with team members and stakeholder on the objectives of this activity

4.1.2.4.1.3.1 RoleTest Analyst

4.1.2.4.1.3.2 ArtifactThe results should be recorded in Test Plan.

document.doc 20 September 2004Copyright © OASIS Open 2004. All Rights Reserved. Page 46 of 59

16111612161316141615161616171618161916201621

16221623

162416251626

162716281629163016311632163316341635163616371638163916401641164216431644164516461647164816491650165116521653

16541655

165616571658

9495

Page 47: OASIS | Advancing open standards for the information society€¦  · Web viewAny inadequacies that may lead to possible security breaches should be reported and resolved by the

4.1.2.4.1.4 Activity: Define Test Approach- Examine test motivators and target test items

o test requirements - FURPS- Examine the software architecture

o understand how the target is deployed select the appropriate test point

- Consider the appropriate breadth and depth of the test approacho determine strategy for the test points

API level SOAP Client level

Atomic / Collaboration- Identify existing test techniques for reuse

o gather experience from team members identify the possible technique for use

select appropriate technique the rest as contingency

- Define techniqueso Outline each technique for each type of test

Automated/Manual/semi-automated Require tool

Framework Test Design

o maintenanceo effectivenesso reusableo longevity

Implementation tips and tricks Test bed pre-condition/post-condition

Test data management Test Result logging/reporting

- Define the test asset configuration management strategyo Identify possible test assets management

version control backup

- Survey availability of reusable assetso Identify existing test asset which could be reused

Based on test design- Evaluate and verify your results

o verify with team members and stakeholder on the objectives of this activity

4.1.2.4.1.4.1 RoleTest Designer

4.1.2.4.1.4.2 ArtifactThe results should be recorded in Test Environment Configuration, Test Plan and Test Strategy.

4.1.2.4.1.5 Activity: Identify Test Ideas- Identify relevant Test Motivators and Target Test Items

o Determine level of testing required for specific/partial targets Correctness (must) Completeness (vary)

The test ideas will help you to identify the possible test scenarios you would need to address based on the signature of each method call found in the specific Web service

document.doc 20 September 2004Copyright © OASIS Open 2004. All Rights Reserved. Page 47 of 59

165916601661166216631664166516661667166816691670167116721673167416751676167716781679168016811682168316841685168616871688168916901691169216931694169516961697

16981699

1700170117021703

17041705170617071708170917101711

9697

Page 48: OASIS | Advancing open standards for the information society€¦  · Web viewAny inadequacies that may lead to possible security breaches should be reported and resolved by the

- Examine relevant available Test-Idea Catalogso Check existing best practices to test specific

- Brainstorm additional Test Ideaso Enhance Test Idea catalogo Examine Web service and analyse every method signature

Valid value Boundary value

o Identify possible values for each parameter. Valid and invalid

Special value Invalid value

Must conform to the syntax of the parameter data structure Guidelines: Test Ideas for Booleans and Boundaries Guidelines: Test Ideas for Method Calls

- Refine the Test-Ideas Listo update existing list

- Evaluate and verify your resultso verify with team members and stakeholder on the objectives of this activity

4.1.2.4.1.5.1 RoleTest Analyst

4.1.2.4.1.5.2 ArtifactThe results should be recorded in Test-Ideas List.

4.1.2.4.2 Workflow Detail: Define Test Bed

4.1.2.4.2.1 Activity: Identify Test Environment- Identify the application architecture and deployment

o Hardware and Software (20% effort) Configurations

o Test Data (80% effort) Explanation Depth Breadth Scope Architecture

- Identify the test facilitieso Tools

Hardware and Software requirementso Roles

Sys Admin, DBA, etco Security

4.1.2.4.2.1.1 RoleTest Designer

4.1.2.4.2.1.2 ArtifactThe results should be recorded in Test Environment Configuration.

4.1.2.4.2.2 Activity: Prepare H/W & S/W Infrastructure- Select the appropriate technique to control environment- Set up test environment

document.doc 20 September 2004Copyright © OASIS Open 2004. All Rights Reserved. Page 48 of 59

171217131714171517161717171817191720172117221723172417251726172717281729

17301731

173217331734

1735

1736173717381739174017411742174317441745174617471748174917501751

17521753

175417551756

175717581759

9899

Page 49: OASIS | Advancing open standards for the information society€¦  · Web viewAny inadequacies that may lead to possible security breaches should be reported and resolved by the

o settings and configuration- Restore test environment

o Logso Temp fileso Software and Hardware settings

4.1.2.4.2.2.1 RoleTest System Administrator, DBA

4.1.2.4.2.2.2 ArtifactThe results should be recorded in Test Environment Configuration.

4.1.2.4.2.3 Activity: Prepare Test Data Sets- Identify the test data to be used

o Deptho Breadtho Scope

- Identify the strategy to restore test datao data refresho data re-initializeo data reseto data roll forward

4.1.2.4.2.3.1 RoleTest Analyst

4.1.2.4.2.3.2 ArtifactThe results should be recorded in Test Data.

4.1.2.4.3 Workflow Detail: Develop, Test and Evaluate

4.1.2.4.3.1 Activity: Define Test Details- Examine the Target Test Item and related Test-Ideas List- Select a subset of the test ideas to detail- For each test idea, design the Test;

o identify input, output and execution conditionso identify candidate points of observationo identify candidate points of controlo Identify appropriate oracles

- Define required data sources, values and ranges- Source sufficient consumable Test Data- Maintain traceability relationships- Evaluate and verify your results

4.1.2.4.3.1.1 RoleTest Analyst

4.1.2.4.3.1.2 ArtifactThe results should be recorded in Test Case, Test Data and Test Script.

document.doc 20 September 2004Copyright © OASIS Open 2004. All Rights Reserved. Page 49 of 59

17601761176217631764

17651766

176717681769

1770177117721773177417751776177717781779

17801781

178217831784

1785

178617871788178917901791179217931794179517961797

17981799

180018011802

100101

Page 50: OASIS | Advancing open standards for the information society€¦  · Web viewAny inadequacies that may lead to possible security breaches should be reported and resolved by the

4.1.2.4.3.2 Activity: Implement Test- Test Design

o Macro-Level Collaboration of high-level test case

o Micro-Level Test script implementation level

Affected by the test data managemento Data partitioning strategyo Data “life-cycle” strategy

- Select appropriate implementation technique- Set up test environment preconditions- Generate Web service client- Implement the test- Establish external data sets- Verify the test implementation- Restore test environment to known state- Maintain traceability relationships- Evaluate and verify your results

4.1.2.4.3.2.1 RoleTester

4.1.2.4.3.2.2 ArtifactThe results should be recorded in Test Script.

4.1.2.4.3.3 Activity: Implement Test Suite- Examine candidate Test Suites- Examine related Tests and Target Test Items- Identify Test dependencies- Identify opportunities for reuse- Apply necessary infrastructure utilities- Determine recovery requirements- Implement recovery requirements- Stabilize the Test Suite- Maintain traceability relationships- Evaluate and verify your results

4.1.2.4.3.3.1 RoleTester

4.1.2.4.3.3.2 ArtifactThe results should be recorded in Test Suite.

4.1.2.4.3.4 Activity: Execute Test Suite- Setup test environment to known state- Set execution tool options- Schedule Test Suite execution- Execute Test Suite- Evaluate execution of Test Suite- Recover from halted tests- Inspect the Test Logs for completeness and accuracy- Restore test environment to known state- Maintain traceability relationships

document.doc 20 September 2004Copyright © OASIS Open 2004. All Rights Reserved. Page 50 of 59

180318041805180618071808180918101811181218131814181518161817181818191820

18211822

182318241825

18261827182818291830183118321833183418351836

18371838

183918401841

1842184318441845184618471848184918501851

102103

Page 51: OASIS | Advancing open standards for the information society€¦  · Web viewAny inadequacies that may lead to possible security breaches should be reported and resolved by the

- Evaluate and verify your results

4.1.2.4.3.4.1 RoleTester

4.1.2.4.3.4.2 ArtifactThe results should be recorded in Test Log.

4.1.2.4.3.5 Activity: Analyse Test Failures- Examine the Test Logs- Capture nontrivial incident data- Identify procedural errors in the test- Locate and isolate failures- Diagnose failure symptoms and characteristics- Identify candidate solutions- Document you findings appropriately- Evaluate and verify your results

4.1.2.4.3.5.1 RoleTester

4.1.2.4.3.5.2 ArtifactThe results should be recorded in Change Request.

4.1.2.4.3.6 Activity: Determine Test Results- Examine all test incidents and failures- Create and maintain Change Requests- Analyze and evaluate status- Make an assessment of the current quality experience- Make an assessment of outstanding quality risks- Make an assessment of test coverage- Draft the Test Evaluation Summary- Advise stakeholders of key findings- Evaluate and verify your results

4.1.2.4.3.6.1 RoleTest Analyst

4.1.2.4.3.6.2 ArtifactThe results should be recorded in Test Evaluation Summary and Test Results.

4.1.2.4.4 Workflow Detail: Improve Test Assets

4.1.2.4.4.1 Activity: Define Test Approach (Refinement)- As in “Define Test Approach” activity found in “Define Mission” Workflow

4.1.2.4.4.1.1 RoleTest Designer

document.doc 20 September 2004Copyright © OASIS Open 2004. All Rights Reserved. Page 51 of 59

1852

18531854

185518561857

185818591860186118621863186418651866

18671868

186918701871

1872187318741875187618771878187918801881

18821883

188418851886

1887

18881889

18901891

104105

Page 52: OASIS | Advancing open standards for the information society€¦  · Web viewAny inadequacies that may lead to possible security breaches should be reported and resolved by the

4.1.2.4.4.1.2 ArtifactThe results should be recorded in Test Environment Configuration, Test Plan and Test Strategy.

4.1.2.4.4.2 Activity: Identify Test Ideas (Refinement)- As in “Identify Test Ideas” activity found in “Define Mission” Workflow

4.1.2.4.4.2.1 RoleTest Analyst

4.1.2.4.4.2.2 ArtifactThe results should be recorded in Test-Ideas List.

4.1.2.4.4.3 Activity: Prepare Guidelines for the Project- Identify the Project's Needs for Guidelines- Prepare Guidelines for Project Use- Maintain Guidelines

4.1.2.4.4.3.1 RoleProcess Engineer

4.1.2.4.4.3.2 ArtifactThe results should be recorded in Project Specific Guidelines.

document.doc 20 September 2004Copyright © OASIS Open 2004. All Rights Reserved. Page 52 of 59

1892189318941895

18961897

18981899

190019011902

1903190419051906

19071908

190919101911

106107

Page 53: OASIS | Advancing open standards for the information society€¦  · Web viewAny inadequacies that may lead to possible security breaches should be reported and resolved by the

4.1.2.5 Discipline: Deployment

Deployment

•Plan Deployment•Develop Deployment Plan

•Develop Support Material•Develop Training Material•Develop Support Material

•Produce Deployment Unit (WS)•Write Release Notes•Develop Installation Artifacts•Create Deployment Unit (WS)•Deploy WS to identified app servers •Publish WS (optional)

Deployment

•Plan Deployment•Develop Deployment Plan

•Develop Support Material•Develop Training Material•Develop Support Material

•Produce Deployment Unit (WS)•Write Release Notes•Develop Installation Artifacts•Create Deployment Unit (WS)•Deploy WS to identified app servers •Publish WS (optional)

Source: IBM-Rational Software

Figure 9: Deployment Workflow

4.1.2.5.1 Workflow Detail: Plan Deployment

4.1.2.5.1.1 Activity: Develop Deployment Plan- Plan how to produce the software- Plan how to package the software- Plan how to distribute the software- Plan how to install the software- Migration- Providing help and assistance to the users

4.1.2.5.1.1.1 RoleDeployment Manager

4.1.2.5.1.1.2 ArtifactThe results should be recorded in Deployment Plan.

document.doc 20 September 2004Copyright © OASIS Open 2004. All Rights Reserved. Page 53 of 59

1912

19131914

1915

1916

1917191819191920192119221923

19241925

192619271928

108109

Page 54: OASIS | Advancing open standards for the information society€¦  · Web viewAny inadequacies that may lead to possible security breaches should be reported and resolved by the

4.1.2.5.2 Workflow Detail: Develop Support Material

4.1.2.5.2.1 Activity: Develop Training Material- Develop an outline for the training materials- Write the training materials

4.1.2.5.2.1.1 RoleCourse Developer

4.1.2.5.2.1.2 ArtifactThe results should be recorded in Training Materials.

4.1.2.5.2.2 Activity: Develop Support Material- Develop end-user support material

4.1.2.5.2.2.1 RoleTechnical Writer

4.1.2.5.2.2.2 ArtifactThe results should be recorded in End-User Support Material.

4.1.2.5.3 Workflow Detail: Produce Deployment Unit (Web service)

4.1.2.5.3.1 Activity: Write Release Notes- Describe the major new features and changes in the release- Describe any known bugs and limitations or workarounds to using the product

4.1.2.5.3.1.1 RoleDeployment Manager

4.1.2.5.3.1.2 ArtifactThe results should be recorded in Release Notes.

4.1.2.5.3.2 Activity: Develop Installation Artifacts- Produce all the software required to install and uninstall the product quickly, easily

and safely without affecting other applications or system characteristics

4.1.2.5.3.2.1 RoleImplementer

4.1.2.5.3.2.2 ArtifactThe results should be recorded in Installation Artifacts.

4.1.2.5.3.3 Activity: Create Deployment Unit (Web service)- Create a deployment unit that is sufficiently complete to be downloadable, installable

and run on a node as a group

document.doc 20 September 2004Copyright © OASIS Open 2004. All Rights Reserved. Page 54 of 59

1929

193019311932

19331934

193519361937

19381939

19401941

194219431944

1945

194619471948

19491950

195119521953

195419551956

19571958

195919601961

196219631964

110111

Page 55: OASIS | Advancing open standards for the information society€¦  · Web viewAny inadequacies that may lead to possible security breaches should be reported and resolved by the

- A deployment unit consists of a build (an executable collection of components), documents (end-user support material and release notes) and installation artifacts

4.1.2.5.3.3.1 RoleConfiguration Manager

4.1.2.5.3.3.2 ArtifactThe results should be recorded in Deployment Unit.

4.1.2.5.3.4 Activity: Deploy Web Service to identified app servers- Identify the service end-point- Create the deployment script and configure the deployment parameters- Deploy the Web service- Generate the WSDL

4.1.2.5.3.4.1 RoleImplementer

4.1.2.5.3.4.2 ArtifactThe results should be recorded in Installation Artifacts.

4.1.2.5.3.5 Activity: Publish Web service [optional]- Identify the UDDI registry- Prepare the information needed for publishing- Publish the Web service in the UDDI registry- Perform a find and bind to test

4.1.2.5.3.5.1 RoleImplementer

4.1.2.5.3.5.2 ArtifactThe results should be recorded in Installation Artifacts.

document.doc 20 September 2004Copyright © OASIS Open 2004. All Rights Reserved. Page 55 of 59

19651966

19671968

196919701971

19721973197419751976

19771978

197919801981

19821983198419851986

19871988

198919901991

112113

Page 56: OASIS | Advancing open standards for the information society€¦  · Web viewAny inadequacies that may lead to possible security breaches should be reported and resolved by the

5 References5.1 Normative

1.

5.2 Non-Normative1. “Rational Unified Process”, Version 2003.06.00.65, IBM-Rational Software.

2. “Rational Unified Process for Developing Web Services”, Version 1.0, Java Smart Services Laboratory and Rational Software Pte. Ltd., Aug 2003.

document.doc 20 September 2004Copyright © OASIS Open 2004. All Rights Reserved. Page 56 of 59

1992

19931994

19951996199719981999

114115

Page 57: OASIS | Advancing open standards for the information society€¦  · Web viewAny inadequacies that may lead to possible security breaches should be reported and resolved by the

Appendix A. AcknowledgmentsThe following individuals were members of the committee during the development of this documentation: Ravi Shankar, CrimsonLogic Pte. Ltd. Jagdip Talla, CrimsonLogic Pte. Ltd. Andy Tan, Individual Roberto Pascual, IDA

document.doc 20 September 2004Copyright © OASIS Open 2004. All Rights Reserved. Page 57 of 59

2000

200120022003200420052006

2007

116117

Page 58: OASIS | Advancing open standards for the information society€¦  · Web viewAny inadequacies that may lead to possible security breaches should be reported and resolved by the

Appendix B. Revision HistoryRev Date By Whom Whatwd-01 2004-09-30 Lai Peng CHAN

Chai Hong ANGInitial version

document.doc 20 September 2004Copyright © OASIS Open 2004. All Rights Reserved. Page 58 of 59

2008

2009

118119

Page 59: OASIS | Advancing open standards for the information society€¦  · Web viewAny inadequacies that may lead to possible security breaches should be reported and resolved by the

Appendix C. NoticesOASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS's procedures with respect to rights in OASIS specifications can be found at the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification, can be obtained from the OASIS Executive Director.

OASIS invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to implement this specification. Please address the information to the OASIS Executive Director.

Copyright © OASIS Open 2004. All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself does not be modified in any way, such as by removing the copyright notice or references to OASIS, except as needed for the purpose of developing OASIS specifications, in which case the procedures for copyrights defined in the OASIS Intellectual Property Rights document must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.

This document and the information contained herein is provided on an “AS IS” basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

document.doc 20 September 2004Copyright © OASIS Open 2004. All Rights Reserved. Page 59 of 59

2010

201120122013201420152016201720182019

202020212022

2023

202420252026202720282029203020312032

20332034

20352036203720382039

2040

120121