Good Practice Guidelines for Software Engineering in New Zealand

Transcription

1 ID= 116 IACUTE /> ID= 293 UDBLACUTE /> AFII10084 /> ID= 443 NCEDILLA /> ID= 452 RCEDILLA /> ID= 117 IGRAVE /> ID= 294 UDBLACUTE /> AFII10085 /> ID= 444 ID= 453 NCEDILLA /> SCIRCUMFLEX /> ID= 118 ICIRCUMFLEX /> ID= 295 ZACUTE /> AFII10086 /> ID= 445 ID= 454 ENG /> SCIRCUMFLEX /> ID= 119 IDIERESIS /> ID= 296 ZACUTE /> AFII10087 /> ID= 446 ID= 455 ENG /> TBAR /> ID= 120 NTILDE /> ID= 297 ZDOT /> AFII10088 /> ID= 447 ID= 456 OMACRON /> TBAR /> ID= 121 OACUTE /> ID= 298 ZDOT /> AFII10089 /> ID= 448 ID= 457 OMACRON /> UTILDE /> ID= 122 OGRAVE /> ID= 299 GAMMA /> AFII10090 /> ID= 449 ID= 458 OBREVE /> UTILDE /> ID= 123 OCIRCUMFLEX /> ID= 300 THETA /> AFII10091 /> ID= 450 ID= 459 OBREVE /> UMACRON /> ID= 124 ODIERESIS /> ID= 301 PHI /> AFII10092 /> ID= 451 ID= 460 RCEDILLA /> UMACRON /> ID= 125 OTILDE /> ID= 302 ALPHA /> AFII10093 /> ID= 452 ID= 461 RCEDILLA /> UBREVE /> ID= 126 UACUTE /> ID= 303 DELTA /> AFII10094 /> ID= 453 ID= 462 SCIRCUMFLEX /> UBREVE /> ID= 127 UGRAVE /> ID= 304 EPSILON /> AFII10095 /> ID= 454 ID= 463 SCIRCUMFLEX /> UOGONEK /> ID= 128 UCIRCUMFLEX /> ID= 305 SIGMA /> AFII10096 /> ID= 455 ID= 464 TBAR /> UOGONEK /> ID= 129 UDIERESIS /> ID= 306 TAU /> AFII10097 /> ID= 456 ID= 465 TBAR /> WCIRCUMFLEX /> ID= 130 DAGGER /> ID= 307 PHI /> AFII10071 /> ID= 457 ID= 466 UTILDE /> WCIRCUMFLEX /> ID= 131 DEGREE /> ID= 308 UNDERSCOREDBL /> AFII10099 /> ID= 458 ID= 467 UTILDE /> YCIRCUMFLEX /> ID= 132 CENT /> ID= 309 EXCLAMDBL /> AFII10100 /> ID= 459 ID= 468 UMACRON /> YCIRCUMFLEX /> ID= 133 STERLING /> ID= 310 NSUPERIOR /> AFII10101 /> ID= 460 ID= 469 UMACRON /> LONGS /> ID= 134 SECTION /> ID= 311 PESETA /> AFII10102 /> ID= 461 ID= 470 UBREVE /> ARINGACUTE /> ID= 135 BULLET /> ID= 312 ARROWLEFT /> AFII10103 /> ID= 462 ID= 471 UBREVE /> ARINGACUTE /> ID= 136 PARAGRAPH /> ID= 313 ARROWUP /> AFII10104 /> ID= 463 ID= 472 UOGONEK /> AEACUTE /> ID= 137 GERMANDBLS /> ID= 314 ARROWRIGHT /> AFII10105 /> ID= 464 ID= 473 UOGONEK /> AEACUTE /> ID= 138 REGISTERED /> ID= 315 ARROWDOWN /> AFII10106 /> ID= 465 ID= 474 WCIRCUMFLEX /> OSLASHACUTE /> ID= 139 COPYRIGHT /> ID= 316 ARROWBOTH /> AFII10107 /> ID= 466 ID= 475 WCIRCUMFLEX /> OSLASHACUTE /> ID= 140 TRADEMARK /> ID= 317 ARROWUPDN /> AFII10108 /> ID= 467 ID= 476 YCIRCUMFLEX /> ANOTELEIA /> ID= 141 ACUTE /> ID= 318 ARROWUPDNBSE /> AFII10109 /> ID= 468 ID= 477 YCIRCUMFLEX /> WGRAVE /> ID= 142 DIERESIS /> ID= 319 ORTHOGONAL /> AFII10110 /> ID= 469 ID= 478 LONGS /> WGRAVE /> ID= 143 NOTEQUAL /> ID= 320 INTERSECTION /> AFII10193 /> ID= 470 ID= 479 ARINGACUTE /> WACUTE /> ID= 144 AE /> ID= 321 EQUIVALENCE /> AFII10050 /> ID= 471 ID= 480 ARINGACUTE /> WACUTE /> ID= 145 OSLASH /> ID= 322 HOUSE /> AFII10098 /> ID= 472 ID= 481 AEACUTE /> WDIERESIS /> ID= 146 INFINITY /> ID= 323 REVLOGICALNOT /> AFII00208 /> ID= 473 ID= 482 AEACUTE /> WDIERESIS /> ID= 147 PLUSMINUS /> ID= 324 INTEGRALTP /> AFII61352 /> ID= 474 ID= 483 OSLASHACUTE /> YGRAVE /> ID= 148 LESSEQUAL /> ID= 325 INTEGRALBT /> PI /> ID= 475 ID= 484 OSLASHACUTE /> YGRAVE /> ID= 149 GREATEREQUAL /> ID= 326 SF /> SHEVA /> ID= 476 ID= 485 ANOTELEIA /> QUOTEREVERSED /> ID= 150 YEN /> ID= 327 SF /> HATAFSEGOL /> ID= 477 ID= 486 WGRAVE /> RADICALEX /> ID= 151 MU1 /> ID= 328 SF /> HATAFPATAH /> ID= 478 ID= 487 WGRAVE /> AFII08941 /> ID= 152 PARTIALDIFF /> ID= 329 SF /> HATAFQAMATS /> ID= 479 ID= 488 WACUTE /> ESTIMATED /> ID= 153 SUMMATION /> ID= 330 SF /> HIRIQ /> ID= 480 ID= 489 WACUTE /> ONEEIGHTH /> ID= 154 PRODUCT /> ID= 331 SF /> TSERE /> ID= 481 ID= 490 WDIERESIS /> THREEEIGHTHS /> ID= 155 PI1 /> ID= 332 SF /> SEGOL /> ID= 482 ID= 491 WDIERESIS /> FIVEEIGHTHS /> ID= 156 INTEGRAL /> ID= 333 SF /> PATAH /> ID= 483 ID= 492 YGRAVE /> SEVENEIGHTHS /> ID= 157 ORDFEMININE /> ID= 334 SF /> QAMATS /> ID= 484 ID= 493 YGRAVE /> COMMAACCENT /> ID= 158 ORDMASCULINE /> ID= 335 SF /> HOLAM /> ID= 485 ID= 494 QUOTEREVERSED /> UNDERCOMMAACCENT /> ID= 159 OHM /> ID= 336 SF /> QUBUTS /> ID= 486 ID= 495 RADICALEX /> TONOS /> ID= 160 AE /> ID= 337 SF /> DAGESH /> ID= 487 ID= 496 AFII08941 /> DIERESISTONOS /> ID= 161 OSLASH /> ID= 338 SF /> METEG /> ID= 488 ID= 497 ESTIMATED /> ALPHATONOS /> ID= 162 QUESTIONDOWN /> ID= 339 SF /> MAQAF /> ID= 489 ID= 498 ONEEIGHTH /> EPSILONTONOS /> ID= 163 EXCLAMDOWN /> ID= 340 SF /> RAFE /> ID= 490 ID= 499 THREEEIGHTHS /> ETATONOS /> ID= 164 LOGICALNOT /> ID= 341 SF /> PASEQ /> ID= 491 ID= 500 FIVEEIGHTHS /> IOTATONOS /> ID= 165 RADICAL /> ID= 342 SF /> SHINDOT /> ID= 492 ID= 501 SEVENEIGHTHS /> OMICRONTONOS /> ID= 166 FLORIN /> ID= 343 SF /> SINDOT /> ID= 493 ID= 502 COMMAACCENT /> UPSILONTONOS /> ID= 167 APPROXEQUAL /> ID= 344 SF /> SOFPASUQ /> ID= 494 ID= 503 UNDERCOMMAACCENT /> OMEGATONOS /> ID= 168 DELTA /> ID= 345 SF /> ALEF /> ID= 495 ID= 504 TONOS /> IOTADIERESISTONOS /> ID= 169 GUILLEMOTLEFT /> ID= 346 SF /> BET /> ID= 496 ID= 505 DIERESISTONOS /> ALPHA /> ID= 170 GUILLEMOTRIGHT /> ID= 347 SF /> GIMEL /> ID= 497 ID= 506 ALPHATONOS /> BETA /> ID= 171 ELLIPSIS /> ID= 348 SF /> DALET /> ID= 498 ID= 507 EPSILONTONOS /> DELTA#1 /> ID= 172 AGRAVE /> ID= 349 SF /> HE /> ID= 499 ID= 508 ETATONOS /> EPSILON /> ID= 173 ATILDE /> ID= 350 SF /> VAV /> ID= 500 ID= 509 IOTATONOS /> ZETA /> ID= 174 OTILDE /> ID= 351 SF /> ZAYIN /> ID= 501 ID= 510 OMICRONTONOS /> ETA /> ID= 175 OE /> ID= 352 SF /> HET /> ID= 502 ID= 511 UPSILONTONOS /> IOTA /> ID= 176 OE /> ID= 353 SF /> TET /> ID= 503 ID= 512 OMEGATONOS /> KAPPA /> ID= 177 ENDASH /> ID= 354 SF /> YOD /> ID= 504 ID= 513 IOTADIERESISTONOS /> LAMBDA /> ID= 178 EMDASH /> ID= 355 SF /> FINALKAF /> ID= 505 ID= 514 ALPHA /> MU /> ID= 179 QUOTEDBLLEFT /> ID= 356 SF /> KAF /> ID= 506 ID= 515 BETA /> NU /> ID= 180 QUOTEDBLRIGHT /> ID= 357 SF /> LAMED /> ID= 507 ID= 516 DELTA#1 /> XI /> ID= 181 QUOTELEFT /> ID= 358 SF /> FINALMEM /> ID= 508 ID= 517 EPSILON /> OMICRON /> ID= 182 QUOTERIGHT /> ID= 359 SF /> MEM /> TION! --> ID= 509 ID= 518 ZETA /> PI /> ID= 183 DIVIDE /> ID= 360 SF /> FINALNUN /> ID= 510 ID= 519 ETA /> RHO /> ID= 184 LOZENGE /> ID= 361 SF /> NUN /> ID= 511 ID= 520 IOTA /> SIGMA /> ID= 185 YDIERESIS /> ID= 362 SF /> SAMEKH /> ID= 512 ID= 521 KAPPA /> TAU /> ID= 186 YDIERESIS /> ID= 363 SF /> AYIN /> ID= 513 ID= 522 LAMBDA /> UPSILON /> ID= 187 FRACTION /> ID= 364 SF /> FINALPE /> ID= 514 ID= 523 MU /> CHI /> ID= 188 ID= 524 EURO /> ID= 365 PSI /> SF /> PE /> ID= 515 NU /> ID= 189 ID= 525 GUILSINGLLEFT /> ID= 366 OMEGA /> UPBLOCK /> FINALTSADI /> ID= 516 XI /> ID= 190 ID= 526 GUILSINGLRIGHT /> ID= 367 IOTADIERESIS /> DNBLOCK /> TSADI /> ID= 517 OMICRON /> ID= 191 ID= 527 FI /> ID= 368 UPSILONDIERESIS /> BLOCK /> QOF /> ID= 518 PI /> ID= 192 ID= 528 FL /> ID= 369 ALPHATONOS /> LFBLOCK /> RESH /> ID= 519 RHO /> ID= 193 ID= 529 DAGGERDBL /> ID= 370 EPSILONTONOS /> RTBLOCK /> SHIN /> ID= 520 SIGMA /> ID= 194 ID= 530 PERIODCENTERED /> ID= 371 ETATONOS /> LTSHADE /> TAV /> ID= 521 TAU /> ID= 195 ID= 531 QUOTESINGLBASE /> ID= 372 IOTATONOS /> SHADE /> DOUBLEVAV /> ID= 522 UPSILON /> ID= 196 ID= 532 QUOTEDBLBASE /> ID= 373 UPSILONDIERESISTON DKSHADE /> VAVYOD /> ID= 523 CHI /> OS /> ID= 197 PERTHOUSAND /> ID= 374 FILLEDBOX /> DOUBLEYOD /> ID= 524 PSI /> ID= 198 ID= 533 ACIRCUMFLEX /> ID= 375 BETA /> FILLEDRECT /> GERESH /> ID= 525 OMEGA /> ID= 199 ID= 534 ECIRCUMFLEX /> ID= 376 GAMMA /> TRIAGUP /> GERSHAYIM /> ID= 526 IOTADIERESIS /> ID= 200 ID= 535 AACUTE /> ID= 377 ZETA /> TRIAGRT /> NEWSHEQELSIGN /> ID= 527 UPSILONDIERESIS /> ID= 201 ID= 536 EDIERESIS /> ID= 378 ETA /> TRIAGDN /> VAVSHINDOT /> ID= 528 ALPHATONOS /> ID= 202 ID= 537 EGRAVE /> ID= 379 THETA /> TRIAGLF /> FINALKAFSHEVA /> ID= 529 EPSILONTONOS /> ID= 203 ID= 538 IACUTE /> ID= 380 IOTA /> CIRCLE /> FINALKAFQAMATS /> ID= 530 ETATONOS /> ID= 204 ID= 539 ICIRCUMFLEX /> ID= 381 KAPPA /> INVBULLET /> LAMEDHOLAM /> ID= 531 IOTATONOS /> ID= 205 ID= 540 IDIERESIS /> ID= 382 LAMBDA /> INVCIRCLE /> LAMEDHOLAMDAGESH /> ID= 532 UPSILONDIERESISTONOS /> ID= 206 ID= 541 IGRAVE /> ID= 383 MU /> SMILEFACE /> ALTAYIN /> ID= 533 BETA /> ID= 207 ID= 542 OACUTE /> ID= 384 NU /> INVSMILEFACE /> SHINSHINDOT /> ID= 534 GAMMA /> ID= 208 ID= 543 OCIRCUMFLEX /> ID= 385 XI /> SUN /> SHINSINDOT /> ID= 535 ZETA /> ID= 209 ID= 544 OGRAVE /> ID= 386 OMICRON /> FEMALE /> SHINDAGESHSHINDOT /> ID= 536 ETA /> ID= 210 ID= 545 UACUTE /> ID= 387 RHO /> MALE /> SHINDAGESHSINDOT /> ID= 537 THETA /> ID= 211 ID= 546 UCIRCUMFLEX /> ID= 388 SIGMA1 /> SPADE /> ALEFPATAH /> ID= 538 IOTA /> ID= 212 ID= 547 UGRAVE /> ID= 389 UPSILON /> CLUB /> ALEFQAMATS /> ID= 539 KAPPA /> ID= 213 ID= 548 DOTLESSI /> ID= 390 CHI /> HEART /> ALEFMAPIQ /> ID= 540 LAMBDA /> ID= 214 ID= 549 CIRCUMFLEX /> ID= 391 PSI /> DIAMOND /> BETDAGESH /> ID= 541 MU /> ID= 215 ID= 550 TILDE /> ID= 392 OMEGA /> MUSICALNOTE /> GIMELDAGESH /> ID= 542 NU /> ID= 216 ID= 551 MACRON /> ID= 393 IOTADIERESIS /> MUSICALNOTEDBL /> DALETDAGESH /> ID= 543 XI /> ID= 217 ID= 552 BREVE /> ID= 394 UPSILONDIERESIS /> IJ /> HEDAGESH /> ID= 544 OMICRON /> ID= 218 ID= 553 DOTACCENT /> ID= 395 OMICRONTONOS /> IJ /> VAVDAGESH /> ID= 545 RHO /> ID= 219 ID= 554 RING /> ID= 396 UPSILONTONOS /> NAPOSTROPHE /> ZAYINDAGESH /> ID= 546 SIGMA1 /> ID= 220 ID= 555 CEDILLA /> ID= 397 OMEGATONOS /> MINUTE /> TETDAGESH /> ID= 547 UPSILON /> ID= 221 ID= 556 HUNGARUMLAUT /> ID= 398 AFII10023 /> SECOND /> YODDAGESH /> ID= 548 CHI /> ID= 222 ID= 549 ID= 557 OGONEK /> PSI /> ID= 399 AFII10051 /> AFII61248 /> FINALKAFDAGESH /> ID= 223 ID= 550 ID= 558 CARON /> OMEGA /> ID= 400 AFII10052 /> AFII61289 /> KAFDAGESH /> ID= 224 ID= 551 ID= 559 LSLASH /> IOTADIERESIS /> ID= 401 AFII10053 /> H22073 /> LAMEDDAGESH /> ID= 225 ID= 552 ID= 560 LSLASH /> UPSILONDIERESIS /> ID= 402 AFII10054 /> H18543 /> MEMDAGESH /> ID= 226 ID= 553 ID= 561 SCARON /> OMICRONTONOS /> ID= 403 AFII10055 /> H18551 /> NUNDAGESH /> ID= 227 ID= 554 ID= 562 SCARON /> UPSILONTONOS /> ID= 404 AFII10056 /> H18533 /> SAMEKHDAGESH /> ID= 228 ID= 555 ID= 563 ZCARON /> OMEGATONOS /> ID= 405 AFII10057 /> OPENBULLET /> FINALPEDAGESH /> ID= 229 ID= 556 ID= 564 ZCARON /> AFII10023 /> ID= 406 AFII10058 /> AMACRON /> PEDAGESH /> ID= 230 ID= 557 ID= 565 BROKENBAR /> AFII10051 /> ID= 407 AFII10059 /> AMACRON /> TSADIDAGESH /> ID= 231 ID= 558 ETH /> AFII10052 /> ID= 408 CCIRCUMFLEX /> QOFDAGESH /> ID= 232 ID= 559 ETH /> AFII10053 /> ID= 409 CCIRCUMFLEX /> RESHDAGESH /> ID= 233 ID= 560 YACUTE /> AFII10054 /> ID= 410 CDOT /> SHINDAGESH /> ID= 234 ID= 561 YACUTE /> AFII10055 /> ID= 411 CDOT /> TAVDAGES /> ID= 562 AFII10056 /> ID= 412 EMACRON /> VAVHOLAM /> ID= 563 AFII10057 /> ID= 413 EMACRON /> BETRAFE /> KAFRAFE /> ID= 564 AFII10058 /> PERAFE /> ID= 565 AFII10059 /> ID= 566 AFII10060 /> Good Practice Guidelines for Software Engineering in New Zealand March 2007 The New Zealand Computer Society Inc.

2 2

3 CONTENTS Minister s Foreword Foreword Introduction What Is Different About Software? Why Worry About Software Engineering Process Standards? How Can Engineering Standards Help Software Development? How Can Standards Help Software-intensive System Operations? Conclusion Acknowledgements References Appendix 1: Examples of Key Software Development and Operations Engineering Process Standards

4 MINISTER S FOREWORD New Zealand s future economic development and international competitiveness is reliant upon improving our digital capability, infrastructures and skills across government, the business sector and communities. These aims are brought together in the Labour-led Government s Digital Strategy. Underpinning many of these areas is reliance upon international good practice and conformance with internationallyrecognised standards. In the area of software engineering standards IPENZ has taken a leadership role and developed Good Practice Guidelines for Software Engineering in New Zealand. Increasingly, New Zealand software development companies will need to conform to accepted international benchmarks in order to remain internationally competitive. These guidelines mean that New Zealand companies will have a point of reference for the standards required by the global software market when developing new products. The Government recognises that these guidelines are important. Industry-led initiatives, such as the development of these guidelines, assist in New Zealand s transformation into an innovative, knowledge-based, internationallycompetitive economy. Therefore, I commend the Institution and its collaborators for undertaking this valuable work. Hon David Cunliffe 2

5 FOREWORD New Zealand s economic development relies on good practices for developing and operating software-intensive systems. Moreover, to strengthen New Zealand s export competitiveness both in terms of cost structures and delivered product quality software development organisations must adopt the good practices already being used elsewhere around the world. The fi nancial transaction component of our economy has been largely digital for many years now. We are also rapidly implementing digital government through initiatives fl owing from the Government s Digital Strategy. But these critical infrastructures for our 21st century economy fundamentally rely on trustworthy softwareintensive systems. Already our society is highly dependent on software intensive systems, and in turn their defi nition, development, implementation and operations. Obvious everyday examples include: electronic cash registers used for virtually all purchasing whatever the fi nal payment mechanism might be stock control systems monitoring and control systems for public utilities, transportation systems and health care rapid and easy web-based access to government-held information industrial control systems Building and operating these kinds of critical systems are dependent on good practices across the whole softwareintensive system lifecycle, such as those codifi ed by international software engineering standards and maturity frameworks. While slavishly following good practices won t guarantee reliable or cost-effective development and operations, poor or mediocre practices make reliability and effectiveness a matter of chance rather than good management. There are many other reasons for referring to documented good practices. They: foster traceability of features delivered to meet customers requirements describe ways of avoiding risks caused by the failure of software-intensive systems provide checklists of procedures and practices that improve the overall effi ciency of software development processes encompass considerations for building in and maintaining security, privacy and resilience to malicious attacks In short, good practices as embodied in international software standards and frameworks are the roadmaps towards a disciplined approach to software systems development and operations. 3

6 INTRODUCTION 4 Engineers like solving problems especially diffi cult problems. Although it has become relatively easy to commission hardware for information technology, many non-trivial problems continue to plague software development and operational processes. Software engineering problems have remained hard. Many of the good practices in other engineering disciplines have been codifi ed and are enforced in nationally and internationally accepted standards. However, this doesn t generally apply to software development and operations in New Zealand. There is plenty of room for improvement in referencing to and conforming (J Moore, personal communication) 1 with software engineering process standards in New Zealand (Sung and Paynter, 2006). While not a silver bullet solution (Brooks, 2003) to all software problems, software engineering standards can support improvement in software development and operations. Software engineering standards can also help reduce costs and complexity when specifying and evaluating components incorporating software in larger systems. International standards in software and system engineering are also excellent references for good practice in software development and operations. Along with international economic, legal and cultural requirements, internationally accepted software engineering process standards are becoming increasingly important. Software intensive systems development and operations can be undertaken anywhere in the world for clients anywhere in the world. So, at whatever scale they operate, New Zealand software developers will increasingly be at a competitive disadvantage if they cannot demonstrate knowledge of and adherence to software engineering standards. Successful export of valueadded products that rely on software-controlled processes for manufacture, quality assurance and inventory control will also increasingly depend on demonstrable conformance and possibly obligatory compliance to software engineering process standards. The following are some international and New Zealand examples of guidelines or requirements to comply with software engineering standards or quasi-standards: The Payment Card Industry (PCI) Security Standards Council s Data Security Standards (DSS) (2006) which include requirements to develop software applications based on industry best practices and incorporate information security throughout the software development lifecycle and to develop all web applications based on secure coding guidelines such as the Open Web Application Security Project guidelines. The Association for Computing Machinery s studies of implementing voter registration databases (2006) (equivalent to New Zealand s electoral roll system) concludes that e-voting systems technology, if engineered and tested carefully, and if deployed with safeguards against failure, can strengthen [the USA s] voting system, but we still have work to do in meeting these goals (Spafford, 2006). In New Zealand, issues with Student Management Systems (SMS) for use in primary and secondary schools led to the Ministry of Education initiating an SMS accreditation process so schools would have reliable and consistent data about the various SMS packages available in the New Zealand market (2005). In addition to reviewing the functionality of the SMS applications, The Ministry also reviewed suppliers business organisation, supply of application support services, software development management and quality assurance, and technology roadmaps. The New Zealand Government s Communications Security Bureau s Security of Information Technology publication NZSIT 400 (2005) which provides guidance to government agencies for managing the risks of sharing information and includes reference to various international IT security standards. Software engineering process standards can be used in essentially two ways (Christensen and Thayer, 2001): to defi ne the right things to do as normative reference model codifi cations of good practices to guide software engineering processes the implicit assumption being that the quality of a software-intensive system is directly infl uenced by the quality of the development and operational processes to measure whether the right things are being done that is, the degree of conformance to codifi cations 2 of good practices often expressed as a score derived from a process maturity level framework This document identifi es some sources of software engineeringspecifi c process standards to which practising professional engineers in New Zealand might want to refer, and it identifi es situations when standards might be useful (J Dietrich, personal communication). 3 1 Moore notes that the preferred nomenclature is to conform, which connotes voluntary agreement to standards, as opposed to to comply, which carries a meaning of enforced obligation. 2 A normative document prescribes what an engineer should do in a specifi ed situation rather than providing information that might be helpful. The normative literature is validated by consensus formed among practitioners and is concentrated in standards and related documents. (ISO/IEC 19759) 3 In addition to the standards mentioned in [this document] there are several de-facto standards. These standards are not (yet) maintained by an international standard body but are either promoted by vendors and consultancy fi rms (example: IBM s Rational Unifi ed Process RUP) or by communities like the Agile Alliance, Examples include: Extreme Programming XP, Scrum, FDD. The existence of these de-facto standards refl ects the very nature of the software industry where technology and methodologies used change frequently and [international] standard bodies are not agile enough to refl ect this.

7 WHAT IS DIFFERENT ABOUT SOFTWARE? In essence, software is a set of instructions to carry out a sequence of actions resulting in a set of observable states, each state being dependent on some or all previous inputs and intermediate states. A useful metaphor for both software and its development is solving a scrambled Rubik s cube. The initial state and goal state can be well defi ned but a variety of action sequences ( algorithms or procedures ) can be taken to achieve the desired result. In practice, not all new individuals entering the domain of software development and operations have trained in computer science or software engineering. Even if they have computing degrees, they may never have learnt about what has been done by people before them. Many [of these] people purposely ignore the lessons of the past. It may take a major project failure before these people realise that the problems they encountered were neither new nor unique. (Endres and Rombach, 2003) Other engineering disciplines are generally well supported by science-based knowledge. However, the industrial practices of software engineering are not generally well supported by the theories of computer science. For example, there is little support from robust, well-accepted theories and abstractions about quantifying the complexities of real-world problem spaces. WHY WORRY ABOUT SOFTWARE ENGINEERING PROCESS STANDARDS? Professional engineers involved in specifying, developing, evaluating or managing software or specifying and evaluating systems incorporating software-intensive components should ask the following questions: To what extent should, and does, the development process comply with recognised standards? Are the standards complied with appropriate for the development being undertaken? What are the potential problems that could arise if the software fails to perform as required? As articulated in IEC and the accompanying paper (Durdle, 2006), this should be assessed and expressed in similar terms to the outcomes of a hardware engineering risk analysis. If there is some degree of non-compliance, what is the impact on the process, the software or system being delivered and the resulting risks? If the client is not aware of or concerned about compliance to appropriate standards, how should the impacts of the above be communicated? In general, we can t accurately estimate how much effort should be required to solve a given software development problem unless we have solved a very similar problem before (Brooks, 2003). Empirical information about the effort and cost involved in successful software development is generally only anecdotal or proprietary in nature. The tie back to universal physical laws and constraints and the experiences of having solved numerous tangible engineering problems have very limited applicability in software development. Furthermore, unlike a physical structure, it can be very diffi cult to discern the overall software architecture and quality attributes of a software system by examining the code implementing the system s algorithms (Baragry and Reed, 2001). This accounts for the signifi cant effort required to reconstruct the software architecture of an operating system once the original creators have moved on and knowledge of the decision-making considerations that resulted in the design is lost (O Brien et al, 2002; P Kruchten, personal communication; Kruchten, 2004). It s about as easy as reconstructing a pig from a sausage (Eastwood, 1993). 5

8 HOW CAN ENGINEERING STANDARDS HELP SOFTWARE DEVELOPMENT? 6 Software engineering is the part of systems engineering (Doran, 2006) 4 that deals with the systematic development, evaluation and maintenance of software. Software engineering standards can provide the equivalent of instructions to cheat by disassembling the Rubik s cube and piecing it back to achieve a desired result. While standards can provide guidance as to how to decompose the total problem space into coordinated component problems, they won t tell the developer how to create new algorithmic procedures. So in that sense, standards are only part of an engineering approach to software system development. But they can form the basis of a robust, auditable and repeatable quality management approach to tackling the hard problems of software-intensive large-system development. Some of the advantages of conforming with software engineering standards include (E Tempero, personal communication): risk management process standards have often been formulated purposefully to identify, address, reduce and avoid risk, as discussed in Best Practice Guidelines for Risk Management of Software-based Systems (IPENZ, 2006) predictability by following consistent processes the resource requirements for similar kinds of activity will become easier to identify and estimate audit to satisfy customers expectations that appropriate processes have been followed to produce the end product, much as Producer Statements do to comply with the Building Act 1991 health and safety requirements particularly in order to demonstrate that appropriate design consideration has been taken for life-critical and safety-critical software systems service differentiation as a marketing feature, demonstrable adherence to standards might well be perceived as added value by customers who can choose between alternative suppliers of software engineering services However, some factors to consider before mandating heavyweight software engineering process standards are (Glass, 2003; Garcia, 2005): size matters small development projects that involve a handful of developers are vastly easier than larger projects application domain matters for example the mathematical formalism often needed for scientifi c applications is typically unnecessary for business oriented software intensive systems criticality matters if lives or vast sums of money are impacted by the results of a project it should be treated carefully, especially in respect to reliability requirements innovativeness matters if the problem being addressed is quite unlike one previously solved, an exploratory and less process-driven approach to its solution may be appropriate what the competition is doing matters complying with software engineering process standards might well become a requirement for entry into some markets, or remaining in existing markets poor performance matters adopting software engineering process standards might help solve diffi culties in getting the right quality level of software delivered to customers on time and within budget required investment matters adopting software engineering process standards incurs costs in terms of process development, deployment, maintenance and appraisal organisational culture matters key considerations include business strategy and goals, embedded work practices, potential for transformation and the appetite for change Nevertheless, software engineering process standards are important to software quality assurance as they codify good practices and they go a long way to address the distinctive problems of non-trivial software development noted above. The assumption that software engineering process standards are too expensive and diffi cult for implementation by small-sized software development organisations is challenged by reported successes from using tailored approaches for example in Australia (Cater-Steel, 2004), Brazil (von Wangenheim et al, 2006) and various countries in Europe (Lawthers, 1999). An historical issue was the proliferation of software engineering standards and standards setting bodies, resulting in the quip the nice thing about standards is that there are so many to choose from. 5 At one time, 55 producers of software engineering standards were active publishing more than 300 standards (Magee and Thiele, 2004). However, this quagmire (Sheard, 2000) has now solidifi ed to a smaller set of key producers and standards (Moore, 1998; Brotbeck et al, 1999). From a New Zealand perspective, the key internationally accepted software engineering development process standards (and quasi standards) producers are: IEC the International Electrotechnical Commission ISO the International Organization for Standardization JTC1 the ISO/IEC Joint Technical Committee and its subcommittees working on IT standards IEEE the Institute of Electrical and Electronics Engineers, Software and Systems Engineering Standards Committee SEI the Software Engineering Institute OMG the Object Management Group 4 Standards for the wider area of systems engineering are being harmonised and include ISO/IEC Systems Engineering System Lifecycle Processes; IEEE 1220 IEEE Standard for Application and Management of the Systems Engineering Process. 5 Attributed to A Tannenbaum.

9 While the standards produced by these bodies aren t always consistent and at the same level of detail, they do defi ne a common set of processes that are generally adequate for current use. In practice, the processes can be tailored to meet development requirements and capabilities but caution should be exercised should contractual or regulatory requirements dictate compliance. As of 2006 some New Zealand-specifi c IT standards have been mandated or are under development for government agencies: e-government Interoperability Framework Standards relating to Network; Data Integration; Business Services; Access and Presentation; Web Services; Security; Best Practices in Digital Rights Management, Trusted Computing, Business Process Execution Language, Business Data Transformation, Data Modelling, Processing Structured Data, Document File Formats; Meta Data relating to government agencies; Authentication; Security and Intranet usage guidelines for the management and design of public sector websites the New Zealand Government Locator Service (NZGLS) Metadata Element Set, providing a set of metadata elements designed to improve the discovery, visibility, accessibility and interoperability of online information and services process guidelines for managing and monitoring major IT projects published in August 2001 by the State Services Commission In general, these government-adopted standards and guidelines are representative of industry-acknowledged international good practices. Internationally, the following standards and framework are accepted as normative prescriptions and measures of good practice for software engineering development processes: Industries Alliance (EIA) added to ISO/IEC by publishing three additional standards forming part of the IEEE Software and Systems Engineering Standards collection: IEEE/EIA Standard for Information Technology Software lifecycle processes. This contains ISO/IEC in its entirety and includes six additional annexes which address: basic concepts such as categorising lifecycle processes into primary, supporting, organisational and tailoring compliance situations, levels and criteria lifecycle process objectives acquisition, audit, confi guration management, development, documentation, improvement, infrastructure, joint review, maintenance, management, operation, problem resolution, quality assurance, supply, training, validation, verifi cation lifecycle data objectives relationships between standards errata Standard for Information Technology Software lifecycle processes. Lifecycle data, which provides additional guidance on recording lifecycle data Standard for Information Technology Software lifecycle processes. Implementation considerations, which provides additions, alternatives and clarifi cations to ISO/ IEC based on US industrial experience. ISO/IEC is intended to be independent of development technologies and methodologies and useful for any form of lifecycle model, for example, waterfall, incremental, spiral, etc.. In fact, one of the specifi ed responsibilities of the supplier s role is to select a lifecycle model and map the requirements of the standard to that model. (Moore, 2006) 7 ISO/IEC Information Technology Software Lifecycle Processes ISO/IEC TR Software Engineering Guide to the Software Engineering Body of Knowledge ISO/IEC Information Technology Software Process Assessment SEI s Capability Maturity Model Integration ISO/IEC ISO/IEC establishes a common framework for software lifecycle processes, with well-defi ned terminology, that can be referenced by the software industry. It provides a process that can be employed for defi ning, controlling, and improving software lifecycle processes. 6 The IEEE and Electronics ISO/IEC TR ISO/IEC TR (International Organization for Standardization, 2005) is a republication of a document sponsored by the IEEE Computer Society commonly referred to as the guide to the SWEBOK (Software Engineering Body of Knowledge) (IEEE Computer Society Software Engineering Coordinating Committee, 2004). Offi cially it is a Technical Report of type 3: when the joint technical committee has collected data of a different kind from that normally published as an International Standard ( state of the art, for example). ISO/IEC TR represents a broad consensus within the professional software engineering community of the processes of and good practices in software engineering for both development and operations through identifying and describing the body 6 From ISO/IEC 12207, Section 1.1: Purpose. 7 This is an excellent guide to the use of the IEEE Software and Systems Engineering Standards (and those IEEE standards shared with ISO/IEC) as a codifi ed set of knowledge and good practices in accordance with ISO/IEC TR

10 8 of knowledge that is generally accepted as being software engineering. From the beginning, the SWEBOK project was conceived as having a strong relationship to the normative literature of software engineering. The two major standards bodies for software engineering (IEEE Computer Society Software and Systems Engineering Standards Committee and ISO/IEC JTC1/ SC7) are represented in the project. Ultimately, it is hoped that software engineering practice standards will contain principles directly traceable to the Guide. ISO/IEC TR is subdivided into ten software engineering knowledge areas plus an additional section providing an overview of the knowledge areas strongly related to software engineering process disciplines: software requirements software design software construction software testing software maintenance software confi guration management software engineering management software engineering process software engineering tools and methods software quality disciplines related to software engineering: computer engineering, computer science, management, mathematics, project management, quality management, software ergonomics, systems engineering Appendix C of ISO/IEC TR maps various IEEE Computer Society Software and Systems Engineering standards and ISO/IEC software engineering standards to the ten software knowledge areas. The material covered by ISO/IEC TR will be extended as its users needs evolve. For example, consideration of security aspects in software development activities and software itself has become a topic of increasing concern for high integrity systems in both commercial and governmental domains. To address these new needs, as of late 2006 the United States Departments of Homeland Security and Defense are developing two related documents: A Guide to the Common Body of Knowledge to Produce, Acquire, and Sustain Secure Software (Redwine, 2006) Security in the Software Lifecycle (Goertzel, 2006) a source of information and guidance for good software development practices focused on security Content from these documents might well be incorporated in future versions of ISO/IEC TR ISO/IEC ISO/IEC provides a framework for the assessment of software processes to help: understand the state of an organisation s softwareintensive systems development processes and process improvement opportunities determine the suitability of an organisation s softwareintensive systems development processes for a particular requirement or class of requirements ISO/IEC provides a common approach to describing the results of process assessment while allowing for some degree of comparison of assessments based upon different but compatible models and methods. The sophistication and complexity required of a process is dependent upon its context. For instance, the planning required for a fi ve-person project team is much less than for a fi fty-person team. The ISO/IEC and CMMI frameworks have been mapped to each other by the Software Quality Institute at Griffi th University in Brisbane (Rout et al, 2000). The major benefi ts of the ISO/IEC approach to process assessment are that it: reduces uncertainties in selecting suppliers of softwareintensive systems by enabling the risks associated with the supplier s capabilities to be identifi ed enables appropriate controls to be put in place to manage the risks of software-intensive systems acquisition or development provides a quantifi ed basis for choice in balancing business needs, requirements and estimated project cost against the capabilities of competing sources of software-intensive systems and components of such systems provides a public, shared approach for process assessment provides a common understanding of the use of process assessment for process improvement and capability evaluation facilitates capability evaluation in procurement can be controlled and regularly reviewed in the light of experience of use can be changed only by international consensus The ISO/IEC reference model architecture has two dimensions: a process dimension for software-intensive systems development, largely aligned to ISO/IEC for which example base practices for each process are listed below a process capability dimension

11 ISO/IEC defi nes two primary lifecycle process categories: customer-supplier processes that directly impact the customer, support development and transition of software to the customer and provide for the correct operation and use of the software engineering processes that directly specify, implement, or maintain the software product, its relation to the system and its documentation The customer-supplier category is broken down into the following processes: acquisition: preparation, supplier selection, supplier monitoring, customer acceptance supply requirements elicitation operation: operational use, customer support The engineering category is broken down into the following TABLE 1: ISO/IEC REFERENCE MODEL CAPABILITY LEVELS Capability Level Description Level 0: Incomplete Level 1: Performed Level 2: Managed Level 3: Established Level 4: Predictable Level 5: Optimising There is general failure to attain the purpose of the process. There are few or no easily identifi able work products or outputs of the process. The purpose of the process is generally achieved. The achievement may not be rigorously planned and tracked. Individuals within the organisation recognize that an action should be performed and there is general agreement that this action is performed as and when required. There are identifi able work products for the process and these testify to the achievement of the purpose. The process delivers work products according to specifi ed procedures and is planned and tracked. Work products conform to specifi ed standards and requirements. The primary distinction from the Performed Level is that the performance of the process now delivers work products that fulfi l expressed quality requirements within defi ned timescales and resource needs. The process is performed and managed using a defi ned process based upon good software engineering principles. Individual implementations of the process use approved, tailored versions of standard and documented processes to achieve the process outcomes. The resources necessary to establish the process defi nition are also in place. The primary distinction from the Managed Level is that the process of the Established Level is using a defi ned process that is capable of achieving its process outcomes. The defi ned process is performed consistently in practice within defi ned control limits, to achieve its defi ned process goals. Detailed measures of performance are collected and analysed, leading to a quantitative understanding of process capability and an improved ability to predict and manage performance. Performance is quantitatively managed. The quality of work products is quantitatively known. The primary distinction from the Established Level is that the defi ned process is now performed consistently within defi ned limits to achieve its process outcomes. Performance of the process is optimised to meet current and future business needs and the process achieves repeatability in meeting its defi ned business goals. Quantitative process effectiveness and effi ciency goals (targets) for performance are established based on the business goals of the organisation. Continuous process monitoring against these goals is enabled by obtaining quantitative feedback and improvement is achieved by analysis of the results. Optimising a process involves piloting innovative ideas and technologies and changing non-effective processes to meet defi ned goals or objectives. The primary distinction from the Predictable Level is that the defi ned and standard processes now dynamically change and adapt to effectively meet current and future business goals. 9

12 10 development processes: system requirements analysis and design software requirements analysis software design software construction software integration software testing system integration and testing An additional engineering process is also defi ned at a basic level system and software maintenance. ISO/IEC supporting lifecycle processes are those that may be employed by any of the other processes at various points in the software lifecycle. They include: documentation confi guration management quality assurance verifi cation validation joint review audit problem resolution ISO/IEC organisational lifecycle processes establish the business goals of the organisation and develop processes, products, and resource assets which, when help the organisation achieve its business goals. They include: management processes: project management, quality management, risk management organisational processes: organisational alignment, improvement processes process establishment, process assessment, process improvement human resource management infrastructure measurement reuse The six capability levels in the ISO/IEC reference model are described in Table 1 (see page 9). CMMI CMMI was developed by the SEI and is more widely used in the USA than ISO/IEC for which it is essentially an alternative assessment framework. CMMI provides a measurement framework to assess process maturity for systems engineering, software engineering, integrated product and process development and supplier sourcing. CMMI is also a process measurement and improvement approach that defi nes the elements of effective processes for software development and operations. It can be used to guide process improvement across a project, a division, or an entire organisation. CMMI helps integrate organisational functions, set process improvement goals and priorities, provide guidance for quality processes, and provide a point of reference for appraising current processes (Carnegie Mellon University Software Engineering Institute, 2007). A CMMI staged representation metric commonly quoted is the maturity level which describes the organisation s overall maturity in software engineering processes from 1 (initial, low maturity) to 5 (optimised, high maturity). The CMMI is a descriptive framework it doesn t specify how organisations should satisfy the specifi c practices identifi ed at each maturity level. Rather it focuses on what should be demonstrated. The IEEE Software and Systems Engineering Standards (for example) defi ne how to implement specifi c practices to fulfi l the CMMI requirements (for example, Land, 2005). They defi ne processes along with the work products (also known as artefacts ) that provide support to and result from the development processes. Other Sources of Software Engineering Development Process and Related Standards Another potential source of good practice guidance for New Zealand software-intensive systems engineering is the British Standards Institute-initiated TickIT website (2005). TickIT is essentially a UK-focused accreditation scheme for certifi cation organisations that conduct ISO 9000 audit/registration for software development companies. A TickIT accredited ISO 9001 certifi cate is roughly equivalent to between CMMI Maturity Levels 2 and 3. The TickIT Web site offers: Getting The Measure Of TickIT Guidance and Information about the emerging ISO measurement standards for improving software processes and how they relate to ISO 9001, published in February 2002 TickIT Reference List An extension of the standards list in appendix 5 of Issue 5 TickIT Guide including details of standards databases, an extensive reading list and procurement information, published with revisions in July 2001 Software Architecture Standards One of the major challenges to large software-intensive systems development is establishing the software architecture at the early stages of development. An April 2004 report jointly released by the Royal Academy of Engineering and the British Computer Society noted:

13 In general, the signifi cance of architecture for complex IT projects also tends to be poorly appreciated. The SEI has developed elements of a Software Architecture Lifecycle Integration process approach to defi ning and analysing software architectures for large software-intensive systems development (2007): The Quality Attribute Workshop (QAW) offers a method for eliciting quality attribute requirements. The Attribute-Driven Design (ADD) method provides an approach to defi ne software architectures by basing the design process on the system s quality attribute requirements. The Active Reviews for Intermediate Designs (ARID) concentrate on whether the software architecture design being proposed is suitable from the point of view of other parts of the architecture that must use it. The Architecture Trade-off Analysis Method (ATAM) helps a system s stakeholders understand the consequences of software architectural decisions with respect to the TABLE 2: CMMI CMMI Maturity Level Process Area Number of Specific Practices that Must Be Demonstrated Above Lower Maturity Level 1: Initial Ad hoc occasionally chaotic processes that rely on individual heroes and heroics to deliver death march (Yourdon, 2004) projects. 2: Managed Basic project management disciplines are in place to allow repeatable success for similar projects Requirements Management Project Planning Project Monitoring and Control Process and Product Quality Assurance Confi guration Management Supplier Agreement Management Measurement and Analysis : Defi ned A wider range of software engineering processes for development and operations are documented and complied possibly with some tailoring. 4: Quantitatively Managed Detailed metrics are collected and used to manage the quality of both the software engineering processes and end deliverables. 5: Optimised Continuous software engineering process improvement based on quantitative analyses. Requirements Development Technical Solution Product Integration Verifi cation Validation Organisational Process Focus Organisational Process Defi nition Organisational Training Integrated Project Management Risk Management Organisational Process Performance Quantitative Project Management Organisational Innovation and Deployment Causal Analysis and Resolution

14 system s quality attribute requirements and business goals. The Cost Benefi t Analysis Method (CBAM) and Software Architecture Comparison Analysis Method (SACAM) are methods for architecture-based economic and businessgoal analyses of software-intensive systems to help the system s stakeholders choose between software architectural alternatives. In addition, various volumes in the SEI Series in Software Engineering defi ne good practices and for software architecture development Bass et al, 2003). The book Documenting Software Architectures: Views and Beyond (Clements et al, 2002) represents a de facto application guide to the rather abstract IEEE Standard 1471 Recommended Practice for Architectural Description of Software-Intensive Systems. As of 2006, IEEE 1471 is in the process of being adopted as an ISO/ IEC standard (J Moore, personal communication). Other open standards for enterprise information systems architecture from the defi nition of business architecture requirements and processes, through to information architecture, technology and software implementation, documentation and change management include: the Open Group Architecture Framework ( TOGAF ) Version 8.1 Enterprise Edition (2006) the National Association of Chief Information Offi cers Enterprise Architecture Toolkit version 3.0 (2006) the US Federal Enterprise Architecture Reference Models (2006) Software-intensive Systems Modelling Notation Standards Graphical and mathematical representations of real objects are important for engineering analysis and design in the physical world. The equivalent representations for software-intensive systems make use of various modelling notations, one of which has been published as ISO/IEC Information technology Open Distributed Processing Unifi ed Modelling Language (UML) Version (UML release 2.0 is also available from the Object Management Group, 2007). Another modelling notation the Business Process Modelling Notation (BPMN) is emerging as a de facto standard for describing the business processes and software-intensive system interactions. design to intermediate-level descriptions of implementation. From ISO/IEC 19501: Developing a model for an industrial-strength software system prior to its construction or renovation is as essential as having a blueprint for large building. Good models are essential for communication among project teams and to assure architectural soundness. We build models of complex systems because we cannot comprehend any such system in its entirety. As the complexity of systems increase, so does the importance of good modelling techniques. There are many additional factors of a project s success, but having a rigorous modelling language standard is one essential factor. UML defi nes the following graphical diagrams for softwareintensive systems: use case diagrams class diagrams behaviour diagrams statecharts, activity diagrams, sequence and collaboration interaction diagrams, and component and deployment implementation diagrams UML has some shortcomings in relation to systems modelling, which have led to the development of extensions to its language by the SysML language being developed by the SysML Partners forum (Open Source Specifi cation Project, 2006). BPMN (Object Management Group, 2007) 9 is a graphical notation for business process modelling aimed at business users. It is gaining widespread industry acceptance as a process-centric (as opposed to UML s object-centric) approach that is more intuitive for business analysts. BPMN focuses on modelling control and message fl ows. BPMN also offers the option of explicitly modelling business objects that may be exposed through business services. BPMN and UML complement each other. Business analysts will likely use BPMN as a front-end modelling language and software developers will use UML for subsequent technically-oriented systems development. 12 UML is a graphical notation for visualising, specifying, constructing and documenting the artefacts of a softwareintensive system. UML offers a standard way to write a system s planning documents, including conceptual things such as business processes and system functions, as well as concrete things such as programming language statements, database schemas, and reusable software components. It provides a commonly understood notation set for use by developers of object-oriented software-intensive systems from architecture 8 Unifi ed Modelling Language (UML) is undergoing enhancement with the latest specifi cation (version 2.0) being available for free download from The UML specifi cation version adopted by ISO/IEC is available for free download from 9 Business Process Modelling Notation (BPMN) Version 1.0 Specifi cation was adopted by the Object Management Group on 6 February 2006.

15 HOW CAN STANDARDS HELP SOFTWARE-INTENSIVE SYSTEM OPERATIONS? Software-intensive systems operations is an area of increasing focus as typically some 80 per cent of total cost of ownership relates to ongoing service management costs. Standards for software systems operations are important because: they embody good practices for service management of software-intensive systems management of software-intensive systems is often critical to the success of business and government organisations they can help defi ne and manage the organisation s policies, internal controls and business practices in respect to software intensive systems in cost-effective ways because they represent codifi ed good practices available for reuse they can provide effi ciency gains; reduce reliance on experts; reduce errors; and they can provide documentation for auditable procedures Internationally, two sets of standards and one framework have become increasingly accepted as normative prescriptions and measures of good practices for software engineering operations processes: the ISO/IEC standards ISO/IEC Code of Practice for Information Security Management and ISO/IEC (an update to ISO/IEC ) Control Objectives for Information and related Technology (COBIT) framework ISO/IEC In 2005, the ISO/IEC released: ISO/IEC : Information technology Service management Specifi cation ISO/IEC : Information technology Service management Code of practice The ISO/IEC standards cover good practices for service delivery and service support. They address the following aspects: service delivery processes service level management service reporting service continuity and availability management sudgeting and accounting for IT services capacity management information security management relationship processes business relationship management supplier management 10 Refer to Offi ce of Government Commerce Web site at resolution processes incident management problem management control processes confi guration management change management release process release process management The UK Offi ce of Government Commerce s IT Infrastructure Library (ITIL) publications 10 are becoming generally accepted as a standard source of good practices in process management for software assets, service support, service delivery, IT infrastructure management and security management in support of the ISO/IEC standards. ISO/IEC and ISO/IEC ISO/IEC provides a framework for information security management and management practices to improve the reliability of information security in inter-organisational relationships. ISO/IEC documents good practice in information security management systems as a Code of Practice. ISO/IEC is a specifi cation for information security management systems. Areas addressed include: organisational security asset classifi cation and control personnel security physical and environmental security communications and operations management access control systems development and maintenance business continuity management compliance A related security standard ISO/IEC Security Techniques Evaluation Criteria for IT Security (also known as the Common Criteria for IT Security Evaluation 11 ) defi nes criteria for a common and comparable evaluation of IT security, focusing on the security of systems and products. Another source of information about good information security practices is the Standard of Good Practice (SoGP) (2005) published biannually by the Information Security Forum (ISF). It is available free of charge from the ISF. The SoGP is developed based on the practices of and incidents experienced by large organisations around the world. The SoGP can be used as a governing document for information security by itself or in conjunction with other standards such as ISO/IEC , ISO/IEC and COBIT Unoffi cial versions of the Common Criteria and Common Evaluation Methodology released for public consultation can be downloaded from

16 COBIT COBIT (Information Systems Audit and Control Association, 2005) is a comprehensive framework for software-intensive systems governance, providing management tools such as metrics and maturity models to complement a governance control framework. COBIT defi nes 34 software-intensive systems operations processes grouped along the lines of the classic four-phase plan-do-check-act quality management cycle. Each process is described in terms of: process description, metrics, practices and mapping of the process to process domains, information criteria, required resources and governance areas detailed control objectives for the process management guidelines including process inputs and outputs, a RACI (Responsible, Accountable, Consulted Informed) chart a maturity model for the process The processes defi ned in COBIT 4.0 are outlined in Table 3. The COBIT framework addresses governance of software service management processes within organisations by linking together: business requirements a generally accepted service delivery process model the major resources involved in service delivery management control objectives To establish the control objectives for software-intensive systems operations and monitor performance levels COBIT defi nes specifi c: benchmarking of process capabilities expressed as maturity models, derived from the SEI s Capability Maturity Models balanced scorecard goals and metrics for process performance and outcome measurement goals for getting software-intensive systems processes under control 14 TABLE 3: COBIT 4.0 PROCESSES Plan and Organize: Defi ne a strategic IT plan Defi ne the information architecture Determine technological direction Defi ne the IT processes, organisation and relationships Manage the IT investment Communicate management aims and direction Manage IT human resources Manage quality Assess and manage IT risks Manage projects Monitor and Evaluate: Monitor and evaluate IT performance Monitor and evaluate internal control Ensure regulatory compliance Provide IT governance Acquire and Implement: Identify automated solutions Acquire and maintain application software Acquire and maintain technology infrastructure Enable operation and use Procure IT resources Manage changes Install and accredit solutions and changes Deliver and Support: Defi ne and manage service levels Manage third-party services Manage performance and capacity Ensure continuous service Ensure systems security Identify and allocate costs Educate and train users Manage service desk and incidents Manage the confi guration Manage problems Manage data Manage the physical environment Manage operations

17 CONCLUSION In early 2007 it is planned that a fi ne-tuned COBIT 4.1 will be released along with several other revised publications to create an aligned COBIT 4 series of publications (Information Systems Audit and Control Association, 2006). An alternative top-down approach to defi ning governance for software-intensive systems operations is Australian Standard AS 8015 Corporate governance of information and communications technology. This standard provides guiding principles for owners, board members, directors, partners, senior executives, or similar on the effective, effi cient, and acceptable use of information and communication technology. AS 8015 is quite brief the substantive content is less than fi ve pages. It defi nes six high-level principles with application guidance expected to be released in subsequent handbooks to accompany the standard. The AS 8015 governance principles are: establish clearly understood responsibilities for information and communications technology plan information and communications technology to best support the organisation acquire information and communications technology validly ensure information and communications technology performs well whenever required ensure information and communications technology conforms with formal rules ensure information and communications technology use respects human factors Software engineering is still a rapidly developing discipline. There remain many challenges in addressing the persistent software crisis. Yet there are also many proven software engineering-specifi c techniques and approaches derived from traditional professional engineering disciplines that have been codifi ed as good practices in internationally generally accepted software engineering standards. These standards are being harmonised into a corpus of consistent standards that the international professional software engineering community can refer to as generally accepted knowledge, good practices and measures to guide responsible professional conduct in software engineering. Ethically, it behoves practicing professional software engineers in New Zealand to be aware of the good professional practices described in the standards outlined in this paper. Consistent with the practices of other professional engineering disciplines, New Zealand professional software engineers should endeavour to apply these good practices to solving their client s problems using processes that demonstrably address: client needs timeliness cost-effectiveness ethical requirements including sustainability risk awareness and management ACKNOWLEDGEMENTS These guidelines were developed by Duncan Hall. Many individuals provided support and review during the preparation of this document. They include: A Holt B Durdle C Skinner D Montgomery E Tempero J Moore J Dietrich M Milner N Procter New Zealand Computer Society anonymous reviewer(s) P Croll 15

18 REFERENCES 16 Association for Computer Machinery Committee on Guidelines for Implementation of Voter Registration Databases 2006, Study of Accuracy, Privacy, Usability, Security, and Reliability Issues. Retrieved 8 December 2006 from VRD_report.pdf Baragry, J & Reed, K 2001, Why We Need A Different View of Software Architecture, Proceedings of the Working IEEE/IFIP Conference on Software Architecture, pp Bass, L, Clements, P & Kazman, R 2003, Software Architecture in Practice, (Second Edition), Addison-Wesley & Pearson Education. Brooks, F 2003, A Handbook of Software and Systems Engineering Empirical Observations, Laws and Theories, Fraunhofer Institut Experimentelles Software Engineering, Pearson. Brooks, F 2003, Three Great Challenges for Half-Century-Old Computer Science, Journal of the ACM, 50(1), pp Brotbeck, G, Miller, T & Statz, J 1999, A Survey Of Current Best Practices And Utilization Of Standards In The Public And Private Sectors, State of Texas Department of Information Resources. Carnegie Mellon University Software Engineering Institute 2007, Capability Maturity Model Integration. Retrieved 11 February 2006 from Carnegie Mellon University Software Engineering Institute 2007, Software Architecture Life-Cycle Integration. Retrieved 26 August 2006 from arch_lci.html Cater-Steel, A 2004, Low-rigour, Rapid Software Process Assessments for Small Software Development Firms, Australian Software Engineering Conference Proceedings, pp Clements, P et al 2002, Documenting Software Architectures: Views and Beyond, Addison-Wesley & Pearson Education. Common Criteria 2007, The Common Criteria Project. Retrieved 4 March 2006 from Doran, T 2006, IEEE 1220: For Practical Systems Engineering. IEEE Computer, May 2006, pp Durdle, B 2006, Best Practice Guidelines for Risk Management of Software-based Systems, IPENZ. Eastwood, A 1993, It s a Hard Sell and Hard Work Too, Computing Canada, 18(22), p35. Endres, A & Rombach, D 2003, A Handbook of Software and Systems Engineering Empirical Observations, Laws and Theories, Fraunhofer Institut Experimentelles Software Engineering. Pearson. Federal Enterprise Architecture 2006, Reference Models. Retrieved 1 September 2006 from gov/omb/egov/a-2-eamodelsnew2.html Garcia, S 2005, How Standards Enable Adoption of Project Management Practice, IEEE Software, September October 2005, pp Glass, R 2003, Facts and Fallacies of Software Engineering, Addison-Wesley & Pearson Education. Goertzel, K M et al 2006, Security in the Software Lifecycle: Making Software Development Processes - and the Software Produced by Them - More Secure, Draft Version 1.2 (August 2006), US Department of Homeland Security. Retrieved 20 February 2007 from bsi/resources/dhs/87.html Hunter, R 2001, Software Process Improvement, in The Project Manager s Guide to Software Engineering s Best Practices, Christensen, M & Thayer, R eds, IEEE Computer Society Press. IEEE Computer Society Software Engineering Coordinating Committee 2004, A Guide to the Software Engineering Body of Knowledge. Retrieved 11 February 2006 from swebok.org Information Security Forum 2005, Standard of Good Practice for Information Security, January Retrieved 20 March 2006 from Information Systems Audit and Control Association 2005, COBIT 4.0 Control Objectives, Management Guidelines, Maturity Models. Retrieved 11 February 2006 from org/ Information Systems Audit and Control Association 2006, COBIT Focus Newsletter, vol.2. Retrieved 15 December 2006 from International Organization for Standardization 2005, ISO/IEC 19759:2005. Retrieved 5 March 2006 from asp?dept_id=3107&pagenum=74 IPENZ 2004, Practice Note 04 Safety and Engineers. Retrieved from pdf Kruchten, P 2004, An Ontology of Architectural Design Decisions in Software-Intensive Systems, in Second Groningen Workshop on Software Variability, pp Land, S 2005, IEEE Software Engineering Standards Support for the CMMI Project Planning Process Area, IEEE Computer Society ReadyNote. Lawthers, I 1999, Software Process Improvement in Regions of Europe, European Analysis Report. Retrieved 5 March 2006 from

19 Magee, S & Thiele, D 2004, Engineering Process Standards: State of the Art and Challenges, IEEE IT Professional, September October 2004, pp Ministry of Education 2005, E-Admin Programme Accredited Student Management System. Retrieved 8 December 2006 from documentid=10428&indexid=11255&indexparentid=5646&got o=00#topofpage Moore, J 1998, Software Engineering Standards A User s Road Map, IEEE Computer Society Press. Moore, J 2006, The Road Map to Software Engineering: A Standards-based Guide, IEEE Computer Society Press, p205. National Association of Chief Information Offi cers 2006, Enterprise Architecture Toolkit, Retrieved 1 September 2006 from New Zealand Government 2007, E-Government Standards. Retrieved 11 February 2006 from standards New Zealand Government Communications Security Bureau 2005, NZ Government Information Technology Security Manual: NZSIT 400. Retrieved December 2006 from govt.nz/publications/nzsit/index.html Object Management Group 2007, Business Process Modelling Notation. Retrieved 20 March 2006 from Object Management Group 2007, Unifi ed Modelling Language. Retrieved 14 December 2006 from technology/documents/modeling_spec_catalog.htm#uml O Brien, L, Stoermer, C & Verhoef, C 2002, Software Architecture Reconstruction: Practice Needs and Current Approaches: Technical Report CMU/SEI-2002-TR-024, Carnegie Mellon Software Engineering Institute, Pittsburgh. Open Source Specifi cation Project 2006, Systems Modelling Language. Retrieved 20 March 2006 from Payment Card Industry Security Standard Council 2006, Data Security Standard, Version 1.1. Retrieved 8 December 2006 from pci_dss.htm Redwine, S T et al 2006, Software Assurance, A Guide to the Common Body of Knowledge to Produce, Acquire, and Sustain Secure Software, Draft Version 1.1 (September 2006) US Department of Homeland Security. Retrieved 20 February 2007 from dhs/95.html Rout, T, Tuffl ey, A & Cahill, B 2000, CMMI Evaluation Capability Maturity Model Integration Mapping to ISO/IEC , Defence Materiel Organisation (Australia). Retrieved 5 March 2006 from Sheard, S 2000, Software Productivity Consortium, The Frameworks Quagmire, A Brief Look. Retrieved 11 February 2006 from Spafford, E 2006 (8 November), ACM experts say more required to improve e-voting, [Press Release], Washington: The Association for Computing Machinery. Retrieved 8 December 2006 from releases/11_2006/election.cfm State Services Commission and the Treasury 2001, Guidelines for Managing and Monitoring Major IT Projects. Retrieved 11 February 2006 from asp?docid=2726 Sung, P & Paynter, J 2006, Software Testing Practices in New Zealand, in 19th Annual Conference of the National Advisory Committee on Computing Qualifi cations. The Open Group 2006, The Open Group Architecture Framework Version 8.1. Retrieved 1 September 2006 from opengroup.org/togaf The Royal Academy of Engineering 2004, The Challenges of Complex IT Projects. Retrieved 4 March 2006 from raeng.org.uk/news/publications/list/reports/complex_it_ Projects.pdf TickIT 2005, TickIT Guide. Retrieved 4 March 2006 from von Wangenheim, C, Anacleto, A & Alviano, C 2006, Helping Small Companies Assess Software Processes, IEEE Software, January-February 2006, pp Yourdon, E 2004, Death March, (Second Edition), Yourdon Press/Prentice Hall Professional Technical Reference. 17

20 APPENDIX 1: EXAMPLES OF KEY SOFTWARE DEVELOPMENT AND OPERATIONS ENGINEERING PROCESS STANDARDS Source ISO/IEC Title 9126, Product Quality 12207, Software Lifecycle Processes; 15271, Guide to use of ISO/IEC , Functional Size Measurement 14598, Product Evaluation 14764, Software Maintenance 15026, Software Integrity Levels 15288, System Lifecycle Processes 15408, Security Techniques Evaluation Criteria for IT Security 15504, Software Process Assessment 15939, Software Measurement Process 16085, Risk Management , Code of Practice for Information Security Management 19501, Unifi ed Modelling Language (UML) Version , Guide to the Software Engineering Body of Knowledge (SWEBOK) (Technical Report) 20926, IFPUG 4.1 Unadjusted Functional Size Measurement Method 27001, Specifi cation for Information Security Management Systems IEC IEEEE 61508, Functional Safety Of Electrical/Electronic/Programmable Electronic Safety-Related Systems Standard Glossary of Software Engineering Terminology 730 Standard for Software Quality Assurance Plans 828 Standard for Software Confi guration Management Plans 829 Standard for Software Test Documentation 830 Recommended Practice for Software Requirements Specifi cations Standard Dictionary of Measures to Produce Reliable Software 1008 Standard for Software Unit Testing 18

21 Source IEEE cont. SEI Title 1012 and 1012 Standard for Software Verifi cation and Validation 1016 Recommended Practice for Software Design Descriptions 1028 Standard for Software Reviews 1042 Standard for Software Confi guration Management 1044 Standard Classifi cation for Software Anomalies 1045 Standard for Software Productivity Metrics 1058 Standard for Software Project Management Plans Standard for a Software Quality Metrics Methodology 1062 Recommended Practice for Software Acquisition 1063 Standard for Software User Documentation 1074 Standard for Developing Software Lifecycle Processes 1220 Application and Management of the Systems Engineering Process Standard for Software Safety Plans 1233 Guide for Developing System Requirements Specifi cations 1362 Guide for Information Technology-System Defi nition Concept of Operations 1471 Recommended Practice for Architectural Description of Software-Intensive Systems 1490 A Guide to the Project Management Body of Knowledge 1517 Software Lifecycle Processes Reuse Processes 2001 Recommended Practice for Internet Practices Web Page Engineering 14 Capability Maturity Models for example CMM Integrated: CMMI Standards New Zealand NZMP 6653 APEC-TEL Information Systems Security Standards Handbook (contains references to a wide range of IT security standards) Standards Australia HB 90.9 Software Development Guide to ISO 9001 HB 231 Information Security Risk Management Guidelines AS 8015 Corporate Governance of Information and Communications Technology 12 IEEE Std 1058 is being merged with ISO/IEC TR on the same subject. The result will be published by both IEEE and ISO/IEC with the number (J Moore, personal communication) IEEE Std 1220 has been fast-tracked into JTC 1. The ISO/IEC number is not yet known (J Moore, personal communication). 14 IEEE Std 2001 has been fast-tracked into JTC 1 as ISO/IEC/IEEE (J Moore, personal communication).

22 20

23 21

24 22 For more information, contact: ID= 573 <CLASSDEF AFII10020 /> GLYPH= GLYPH1061 <CLASSDEF ID= 620 YPH GLYPH= AFII62841 ID= 856 AFII63896 /> ID= 574 <CLASSDEF AFII10021 /> GLYPH= GLYPH1062 ID= 743 <CLASSDEF ALEFLAMED /> GLYPH= AFII62843 ID= 857 AFII63897 /> ID= 575 ID= 621 AFII10022 /> ID= 1257 UHOOKABOVE /> ID= 744 <CLASSDEF ZEROWIDTHNONJOINER /> GLYPH= AFII62844 ID= 858 AFII63898 /> ID= 576 ID= 622 AFII10024 /> ID= 1258 UHORNACUTE /> ID= 745 <CLASSDEF ZEROWIDTHJOINER /> GLYPH= AFII62845 ID= 859 AFII63899 /> ID= 577 ID= 623 AFII10025 /> ID= 1259 UHORNACUTE /> ID= 746 <CLASSDEF LEFTTORIGHTMARK /> GLYPH= AFII62881 ID= 860 AFII63900 /> ID= 578 ID= 624 AFII10026 /> ID= 1260 UHORNGRAVE /> ID= 747 <CLASSDEF RIGHTTOLEFTMARK /> GLYPH= AFII ID= 861 AFII63901 /> ID= 579 ID= 625 AFII10027 /> ID= 1261 <EBLC> <EBDT> UHORNGRAVE /> ID= 748 <CLASSDEF AFII57388 /> GLYPH= AFII ID= 862 AFII63902 /> ID= 580 ID= 626 AFII10028 /> ID= <HEXDATA> E <HEXDATA> 303C0603 UHORNHOOKABOVE /> ID= 749 <CLASSDEF 55040B13 AFII57403 /> GLYPH= AFII ID= 863 AFII63903 /> ID= 581 ID= 627 AFII10029 /> ID= C UHORNHOOKABOVE /> ID= 750 <CLASSDEF C AFII57407 /> GLYPH= AFII A ID= 864 AFII63904 /> ID= 582 ID= 628 AFII10030 /> ID= D204D F73 UHORNTILDE /> ID= 751 <CLASSDEF F AFII57409 /> GLYPH= AFII A ID= 865 AFII63905 /> ID= 583 ID= 629 AFII10031 /> ID= F FF C UHORNTILDE /> ID= 752 <CLASSDEF AFII57440 /> GLYPH= AFII D75C ID= 866 AFII63906 /> ID= 584 ID= 630 AFII10032 /> ID= F6E B UHORNDOTBELOW /> ID= 753 <CLASSDEF 0480C AFII57451 /> GLYPH= AFII C ID= 867 AFII63908 /> ID= 585 ID= 631 AFII10033 /> ID= UHORNDOTBELOW /> ID= 754 <CLASSDEF 045A5A5A A AFII57452 /> GLYPH= AFII C3 0C ID= 868 AFII63910 /> ID= 586 ID= 632 AFII10034 /> ID= E 04FE F6E E YDOTBELOW /> ID= 755 <CLASSDEF 06045A5A A5A0804 AFII57453 /> GLYPH= AFII F 5F5F5F89 ID= 869 AFII63912 /> ID= 587 ID= 633 AFII10035 /> ID= D6F E64311E YDOTBELOW /> ID= 756 <CLASSDEF C0603 AAAAAAAA AFII57454 /> GLYPH= AFII AA2FCBF2 FCBF8922 ID= 870 AFII62927 /> ID= 588 ID= 634 AFII10036 /> ID= D F736F YHOOKABOVE /> ID= 757 <CLASSDEF AAAA AFII57455 /> GLYPH= AFII AAAAAAAA AAA057D5 ID= 871 AFII63941 /> ID= 589 ID= 635 AFII10037 /> ID= F72706F 05FE F6E311E F57D5F D5F00B YHOOKABOVE /> ID= 872 AFII62939 /> ID= 414 ID= 758 AFII57456 /> ID= EBREVE /> <CLASSDEF 301C0603 GLYPH= AFII62884 ID= 590 AFII10038 /> ID= B14 154D F736F 900C B A A56A56A 56A56A0C YTILDE /> ID= 873 AFII63943 /> ID= 415 ID= 759 AFII57457 /> ID= EBREVE /> <CLASSDEF GLYPH= AFII ID= 591 AFII10039 /> ID= F72706F F6E F57F F57F57F5 7F5402A8 YTILDE /> ID= 874 AFII62943 /> ID= 416 ID= 760 AFII57458 /> ID= FE0000 EDOT /> <CLASSDEF 9D300D06 GLYPH= AFII ID= 592 AFII10040 /> ID= A F70D A A UNI01CD /> ID= 875 AFII62946 /> ID= 417 ID= 761 AFII57392 /> ID= EDOT /> <CLASSDEF 03818B00 GLYPH= AFII ID= 593 AFII10041 /> ID= D E9FFBE C C FD57F55F D57F55FD UNI01CE /> ID= 876 AFII63946 /> ID= 418 ID= 762 AFII57393 /> ID= GCIRCUMFLEX /> <CLASSDEF GLYPH= AFII62885 ID= 594 AFII10042 /> ID= ACAB BBC A21AA1 57F55FC D07000B UNI01CF /> ID= 877 AFII62951 /> ID= 419 ID= 763 AFII57394 /> ID= FE0000 GCIRCUMFLEX /> <CLASSDEF FDAB4446 GLYPH= AFII ID= 595 AFII10043 /> ID= 1277 E312DC33 9B61D1B BC67400C F B0754AA AAAAAAAA UNI01D0 /> ID= 878 AFII63948 /> <CLASSDEF ID= 420 ID= 764 AFII57395 /> ID= GLYPH= AFII GDOT /> <CLASSDEF 3C5077B8 GLYPH= AFII AAAAAAAA E4 AAAAAA80 ID= 596 AFII10044 /> ID= 1278 B30EEEB9 A70F B5EEC C 0F07000B 072A57F9 UNI01D1 /> ID= 879 AFII62953 /> <CLASSDEF ID= 421 ID= 765 AFII57396 /> ID= GLYPH= AFII GDOT /> <CLASSDEF 24F8B39D GLYPH= AFII FE57F FE57F95F ID= 597 AFII10045 /> ID= E4F F ECE E57F C08 UNI01D2 /> ID= 880 AFII63950 /> <CLASSDEF ID= 422 ID= 766 AFII57397 /> ID= FD0000 GLYPH= AFII GCEDILLA /> <CLASSDEF 32F37380 GLYPH= AFII C C423 ID= 598 AFII10046 /> ID= BDFBB FA14C027 74C31F8F C C41008 UNI01D3 /> ID= 881 AFII63951 /> <CLASSDEF ID= 423 ID= 767 AFII57398 /> ID= GLYPH= AFII57494 GCEDILLA /> <CLASSDEF 11D1A8C4 GLYPH= AFII C AA55AA55 ID= 599 AFII10047 /> ID= C482D5D B2393E AD8C AA55AA55 AA55AA55 UNI01D4 /> ID= 882 AFII63952 /> <CLASSDEF ID= 424 ID= 768 AFII57399 /> ID= GLYPH= AFII HCIRCUMFLEX /> <CLASSDEF DCD05951 GLYPH= AFII AA55AA C08 ID= 600 AFII10048 /> ID= 1282 A96DC B6E A95D106E FF55FF 55FF55FF UNI01D5 /> ID= 883 AFII63953 /> <CLASSDEF ID= 425 ID= 769 AFII57400 /> ID= 601 AFII10049 /> ID= FD0000 GLYPH= AFII HCIRCUMFLEX /> <CLASSDEF FC3A09A8 GLYPH= AFII FF55FF FF55FF ID= 1283 EB3B8351 5D4EAB A D C UNI01D6 /> ID= 884 AFII63956 /> <CLASSDEF ID= 426 ID= 770 AFII57401 /> ID= 602 AFII10065 /> ID= GLYPH= AFII HBAR /> <CLASSDEF 075A3082 GLYPH= AFII A0A C C42 ID= D C 3108C D UNI01D7 /> ID= 885 AFII63958 /> <CLASSDEF ID= 427 ID= 771 AFII57381 /> ID= 603 AFII10066 /> ID= GLYPH= AFII57504 HBAR /> <CLASSDEF 00300B06 GLYPH= AFII AA55 0B AA55AA55 ID= D0F A AA55AA55 AA55AA55 UNI01D8 /> ID= 886 AFII63959 /> <CLASSDEF ID= 428 ID= 772 AFII57461 /> ID= 604 AFII10067 /> ID= 650 0BFD0000 GLYPH= AFII ITILDE /> <CLASSDEF GLYPH= AFII B AA D0855 ID= D C B FF55FF 55FF55FF UNI01D9 /> ID= 887 AFII63960 /> <CLASSDEF ID= 429 ID= 773 AFII63167 /> ID= 605 AFII10068 /> ID= GLYPH= AFII ITILDE /> <CLASSDEF E4D143FD GLYPH= AFII B0B FF55FF FF55FF ID= F338 CC6E3BF2 0B82A UNI01DA /> ID= 888 AFII63961 /> <CLASSDEF ID= 430 ID= 774 AFII57459 /> ID= GLYPH= AFII IMACRON /> <CLASSDEF GLYPH= AFII B ID= F E UNI01DB /> ID= 889 AFII64046 /> <CLASSDEF ID= 431 ID= 775 AFII57543 /> ID= 653 0BFC0000 GLYPH= AFII57505 IMACRON /> <CLASSDEF 65726E65 GLYPH= AFII B ID= A130E UNI01DC /> ID= 890 AFII64058 /> <CLASSDEF ID= 432 ID= 776 AFII57534 /> ID= GLYPH= AFII57506 IBREVE /> <CLASSDEF GLYPH= AFII C0C0101 2A957FE C 5FF957FE ID= E 2C20496E 632E FF957F E55FF957.NOTDEF#8 /> ID= 891 AFII64059 /> <CLASSDEF ID= 433 ID= 777 AFII57494 /> ID= GLYPH= AFII57507 IBREVE /> <CLASSDEF GLYPH= AFII FE55FF80 0C D ID= B13 2A A NOTDEF#9 /> ID= 892 AFII64060 /> <CLASSDEF ID= 434 ID= 778 AFII62843 /> ID= 656 0CFC0000 GLYPH= AFII57508 IOGONEK /> <CLASSDEF 6E20436F GLYPH= AFII C ID= D6D C 20536F A.NOTDEF#10 /> ID= 893 AFII64061 /> <CLASSDEF ID= 435 ID= 779 AFII62844 /> ID= GLYPH= AFII57509 IOGONEK /> <CLASSDEF GLYPH= AFII D0D D0AAA AA955 ID= C AA955AA9 55AA955A.NOTDEF#11 /> ID= 894 AFII62945 /> <CLASSDEF ID= 436 ID= 780 AFII62845 /> ID= GLYPH= AFII57534 JCIRCUMFLEX /> <CLASSDEF GLYPH= AFII A955AA95 0D AA955AA ID= C78F 37DB9228 DF3CBB1A A 000D0A55 UNI0492 /> ID= 895 AFII64184 /> <CLASSDEF ID= 437 ID= 781 AFII64240 /> ID= 659 0DFC0000 GLYPH= AFII57543 JCIRCUMFLEX /> <CLASSDEF AD82FA67 GLYPH= AFII D FF557FF FF557 ID= D FF FF557FF5 57FF557F UNI0493 /> ID= 896 AFII52399 /> <CLASSDEF ID= 438 ID= 782 AFII64241 /> ID= GLYPH= AFII KCEDILLA /> <CLASSDEF GLYPH= AFII E0E0101 F557FF C 7FF01409 ID= E300C06 0A2B C 010F0A UNI0496 /> ID= 897 AFII52400 /> <CLASSDEF ID= 439 ID= 783 AFII63954 /> ID= GLYPH= AFII KCEDILLA /> <CLASSDEF GLYPH= AFII C ID= D D0A UNI0497 /> ID= 898 AFII62753 /> <CLASSDEF ID= 440 ID= 784 AFII57382 /> ID= 662 0CFB0000 GLYPH= AFII KGREENLANDIC /> <CLASSDEF GLYPH= AFII C A F0A55 ID= A2B AA556AA 556AA556 UNI049A /> ID= 899 AFII57411 /> <CLASSDEF ID= 441 ID= 785 AFII64242 /> ID= GLYPH= AFII57555 LCEDILLA /> <CLASSDEF GLYPH= AFII F0F0101 AA556AA AA556A ID= A01 01FF A556AA55 6AA556AA UNI049B /> ID= 900 AFII62754 /> <CLASSDEF ID= 442 ID= 786 AFII62881 /> ID= GLYPH= AFII57567 LCEDILLA /> <CLASSDEF 041FA029 GLYPH= AFII A000F 0D050A00 0A557FF5 ID= A 2F2F FF557F F557FF55 UNI049C /> ID= 901 AFII57412 /> <CLASSDEF ID= 787 AFII57504 /> ID= 665 0DFB0000 GLYPH= AFII62753 <CLASSDEF 772E7665 GLYPH= AFII D FF557FF FF557 ID= E2E63 6F6D2F FF557FF5 57FF8884 UNI049D /> ID= 902 AFII62755 /> <CLASSDEF ID= 788 AFII57369 /> ID= GLYPH= AFII62754 <CLASSDEF 65706F73 GLYPH= AFII B ID= F72 792F A UNI04A2 /> ID= 903 AFII57413 /> <CLASSDEF ID= 789 AFII57370 /> ID= GLYPH= AFII62755 <CLASSDEF B GLYPH= AFII F050A ID= 1303 B UNI04A3 /> ID= 904 AFII62756 /> <CLASSDEF ID= 790 AFII57371 /> ID= 668 0FFB0000 GLYPH= AFII62756 <CLASSDEF GLYPH= AFII F ID= E 636F7270 6F UNI04AE /> ID= 905 AFII57414 /> <CLASSDEF ID= 791 AFII57372 /> ID= GLYPH= AFII62757 <CLASSDEF GLYPH= AFII C ABF ID= E63652C C FCAAFFF2 ABFFCAAF UNI04AF /> ID= 906 AFII62759 /> <CLASSDEF ID= 792 AFII57373 /> ID= GLYPH= AFII62758 <CLASSDEF 20616E64 GLYPH= AFII FF2ABFFC 0F050B00 AAFFF2AB ID= FFCAAFFF 2ABFFCAA UNI04B0 /> ID= 907 AFII62757 /> <CLASSDEF ID= 793 AFII57374 /> ID= 671 0FFB0000 GLYPH= AFII62759 <CLASSDEF GLYPH= AFII F FFF ID= C79 0A A UNI04B1 /> ID= 908 AFII62758 /> <CLASSDEF ID= 794 AFII57375 /> ID= GLYPH= AFII62760 <CLASSDEF 20746F2C GLYPH= AFII E ID= C UNI04B2 /> ID= 909 AFII57415 /> 54696D65 <CLASSDEF ID= 795 AFII57391 /> ID= GLYPH= AFII D70696E <CLASSDEF 6E E060B GLYPH= AFII ID= F6E UNI04B3 /> ID= 910 AFII62760 /> <CLASSDEF ID= 796 AFII57471 /> ID= 674 0EFA F GLYPH= AFII E F <CLASSDEF GLYPH= AFII ID= D ABF FCAAFFF2 UNI04B8 /> ID= 911 AFII57416 /> 55040B13 <CLASSDEF ID= 797 AFII57460 /> ID= B4E4F20 GLYPH= AFII C <CLASSDEF 6E ABFFCAAF C4954 GLYPH= AFII63759 FF2ABFFC ID= A F6E AAFFF2AB FFCAAFFF UNI04B9 /> ID= 912 AFII62763 /> <CLASSDEF ID= 798 AFII52258 /> ID= GLYPH= AFII C20 <CLASSDEF 20312E30 2ABFFCAA 10060C GLYPH= AFII63761 FFF0150A ID= C C61 626C C UNI04BA /> ID= 913 AFII62761 /> <CLASSDEF ID= 799 AFII57506 /> ID= FA GLYPH= AFII E2C20 <CLASSDEF 696E E632E GLYPH= AFII ID= E UNI04BB /> ID= 914 AFII62762 /> 301E170D <CLASSDEF ID= 800 AFII62958 /> ID= GLYPH= AFII <CLASSDEF F GLYPH= AFII C 00100C55 ID= F A0A C 5AAA555A UNI018F /> ID= 915 AFII57417 /> 5A170D30 <CLASSDEF ID= 801 AFII62956 /> ID= GLYPH= AFII <CLASSDEF AA555AAA 11060D A GLYPH= AFII AAA55 5AAA555A ID= A2F2F E AA555AAA UNI0259 /> ID= 916 AFII62764 /> 3081B231 <CLASSDEF ID= 802 AFII52957 /> ID= FA GLYPH= AFII A <CLASSDEF 69676E2E 555AAA E5665 GLYPH= AFII AAA555A AA555AAA ID= F6D3B D6D C0010 UNI04E8 /> ID= 917 AFII57418 /> <CLASSDEF ID= 803 AFII57505 /> ID= E2C20 GLYPH= AFII E632E <CLASSDEF 696C2061 0C555FFF F301D GLYPH= AFII FFF55 5FFF555F ID= D FF555FFF UNI04E9 /> ID= 918 AFII62767 /> <CLASSDEF ID= 804 AFII62889 /> ID= B GLYPH= AFII <CLASSDEF FFF E20 GLYPH= AFII FFF555F </GLYPHORDER> E2E 636F6D3B 000C0012 FF555FFF 555FFF55 ID= 919 AFII62765 /> <CLASSDEF ID= 805 AFII62887 /> ID= E65 GLYPH= AFII F72 <CLASSDEF 206F720A 5FFF B GLYPH= AFII D 61696C ID= 920 AFII62766 /> <CLASSDEF ID= 806 AFII62888 /> ID= B133D GLYPH= AFII E E <CLASSDEF GLYPH= AFII <DSIG> 69676E2C 20496E63 2E2C ID= 921 AFII57419 /> E <CLASSDEF ID= 807 AFII57507 /> ID= E636F6D GLYPH= AFII C 2F <CLASSDEF F GLYPH= AFII <!-- NOTE THAT 436F E2C THE DIGITAL SIGNATURE ID= 922 WILL BE AFII62770 /> ID= 808 AFII62961 /> INVALID AFTER ID= 686 RECOMPILA 6F72792F <CLASSDEF GLYPH= AFII E636F <CLASSDEF 4D6F756E E20 GLYPH= AFII <HEXDATA> E C ID= 923 AFII62768 /> <CLASSDEF ID= 809 AFII62959 /> ID= E2C GLYPH= AFII A 4C <CLASSDEF E4C5444 GLYPH= AFII A F AA ID= 924 AFII62769 /> <CLASSDEF ID= 810 AFII62960 /> ID= E30 GLYPH= AFII F 2C <CLASSDEF FFE GLYPH= AFII FFF FFE555FF F9557FFE B ID= 925 AFII57420 /> <CLASSDEF ID= 811 AFII57508 /> ID= FEFC E GLYPH= AFII D <CLASSDEF FFF GLYPH= AFII FFE A86 FFF9557F 4886F70D 676E2C20 496E632E C FE555FFF A ID= 926 AFII62773 /> 616D7069 <CLASSDEF ID= 812 AFII62962 /> ID= E 6E GLYPH= AFII <CLASSDEF 6C FFE0 0C GLYPH= AFII FEFA E C0608 2A ID= 927 AFII62771 /> <CLASSDEF ID= 813 AFII57567 /> ID= GLYPH= AFII D06 <CLASSDEF 642E2043 </HEXDATA> A8648 GLYPH= AFII F70D E0A A2B ID= 928 AFII62772 /> 86F70D01 <CLASSDEF ID= 814 AFII62964 /> ID= B GLYPH= AFII F <CLASSDEF 4E </EBDT> GLYPH= AFII A C41 494D C060A 2B ID= 929 AFII57421 /> 0A <CLASSDEF ID= 815 AFII52305 /> ID= D498 GLYPH= AFII AD E86792C1 <CLASSDEF 20414E D 6D11B3AA GLYPH= AFII E07000B CA21E 204C C C 801C003C 003C003C ID= 930 AFII62776 /> F8A7CFC8 <CLASSDEF ID= 816 AFII52306 /> ID= FDF900 2A32C6EA GLYPH= AFII F2CC2CA6 <CLASSDEF 494D D2059F1A GLYPH= AFII F F 45442E0A 0A E494E47 006C ID= 931 AFII62774 /> 7FA0E7BE <CLASSDEF ID= 817 AFII57509 /> ID= D4 2F4F5FE0 GLYPH= AFII62783 GLYPH= AFII D01BB872 <CLASSDEF 3A CFA945 GLYPH= AFII E003E 003E F C0608 2A ID= 932 AFII62775 /> 1341EC19 <CLASSDEF ID= 818 AFII62967 /> ID= FC340CB GLYPH= AFII62784 GLYPH= AFII E6112D <CLASSDEF B 8F964D62 GLYPH= AFII F70D DAE11E8F FB7550D3 ID= 933 AFII57422 /> 97A5AF1C <CLASSDEF ID= 819 AFII62965 /> ID= D 062F3305 GLYPH= AFII62785 GLYPH= AFII D440A5DD <CLASSDEF D1AD5B0 GLYPH= AFII A F C A4543 A08210CF ID= 934 AFII62779 /> F4B8036D <CLASSDEF ID= 820 AFII62966 /> ID= D586FB4F GLYPH= AFII62786 GLYPH= AFII D65F1049 <CLASSDEF F 002A0040 DEB7E40A GLYPH= AFII A C A F37DB92 28DF3CBB ID= 935 AFII62777 /> 164E650C <CLASSDEF ID= 821 AFII57555 /> ID= AC7 GLYPH= AFII62787 GLYPH= AFII FF9F9229 <CLASSDEF 4E B8137 GLYPH= AFII AAD82FA D F4E A F70D ID= 936 AFII62778 /> 9246D0B4 <CLASSDEF ID= 822 AFII52364 /> ID= C 9B GLYPH= AFII62788 GLYPH= AFII FCF700 52CDF7B3 <CLASSDEF FB2CF76 GLYPH= AFII D F ID= 937 AFII57423 /> 0A <CLASSDEF ID= 823 AFII63753 /> ID= B987CD GLYPH= AFII62789 GLYPH= AFII C4 C2DCB2CE <CLASSDEF 4E542E A 70B106E3 GLYPH= AFII E E E ID= 938 AFII62780 /> 62B2F511 <CLASSDEF ID= 824 AFII63754 /> ID= AE84872 GLYPH= AFII62790 GLYPH= AFII C987B237 <CLASSDEF C6532C GLYPH= AFII A13 0E F A C E2C2049 ID= 939 AFII57424 /> B <CLASSDEF ID= 825 AFII63759 /> ID= C BF8C4818 GLYPH= AFII62791 GLYPH= AFII A <CLASSDEF 41494D AFAC2C34 GLYPH= AFII E632E E 20494D B 132A5665 ID= 940 AFII62781 /> 83504E4A <CLASSDEF ID= 826 AFII63763 /> ID= A308F62 GLYPH= AFII62792 GLYPH= AFII E A59E0215 <CLASSDEF 4C C 851EEA2B GLYPH= AFII B000F E E F6D6D ID= 941 AFII57425 /> EE <CLASSDEF ID= 827 AFII63795 /> ID= 705 0BFBF ADE0D GLYPH= AFII62793 GLYPH= AFII CDF4 <CLASSDEF A5EFE6 GLYPH= AFII C20536F E C 20494E C69 ID= 942 AFII62782 /> 9EFCF1CB <CLASSDEF ID= 828 AFII62891 /> ID= C2 F8D93293 GLYPH= AFII62794 GLYPH= AFII C 9F77F630 <CLASSDEF 4C B000E F2B98592 GLYPH= AFII BFBF E E E170D <CLASSDEF ID= 943 GLYPH= AFII57407 AFII57426 /> ID= 829 AFII63808 /> ID= D7A049 <CLASSDEF EAE7B4 GLYPH= AFII62795 GLYPH= AFII EC28F <CLASSDEF 530A4F E6898D GLYPH= AFII D E A170D30 <CLASSDEF ID= 944 GLYPH= AFII57409 AFII62783 /> ID= 830 AFII62938 /> ID= <CLASSDEF A GLYPH= AFII62796 GLYPH= AFII C 42F825EC <CLASSDEF 4C E71198FE GLYPH= AFII A 204F E <CLASSDEF 300F0603 ID= 945 GLYPH= AFII57410 AFII57427 /> ID= 831 AFII63810 /> ID= F9888 <CLASSDEF B GLYPH= AFII62797 GLYPH= AFII A3 <CLASSDEF 464F GLYPH= AFII D E C E65 <CLASSDEF ID= 946 GLYPH= AFII57411 AFII62786 /> ID= 832 AFII62942 /> ID= <CLASSDEF 0DFAF D25 GLYPH= AFII62798 GLYPH= AFII C300A <CLASSDEF B06 GLYPH= AFII A130E 504F5345 2C20414E <CLASSDEF E ID= 947 GLYPH= AFII57412 AFII62784 /> ID= 833 AFII62947 /> ID= <CLASSDEF </HEXDATA> F GLYPH= AFII62799 GLYPH= AFII D <CLASSDEF 4C4C204E GLYPH= AFII C20496E 632E3133 4F540A C C <CLASSDEF 55040B13 ID= 948 GLYPH= AFII57413 AFII62785 /> ID= 834 AFII63813 /> ID= </EBLC> <CLASSDEF 0B GLYPH= AFII62800 GLYPH= AFII F845 <CLASSDEF 20464F GLYPH= AFII A F4E E5449 6E20436F <CLASSDEF 6D6D6572 ID= 949 GLYPH= AFII57414 AFII57428 /> ID= 835 AFII63823 /> ID= <CLASSDEF 06082B06 GLYPH= AFII62801 GLYPH= AFII <CLASSDEF 414C2C GLYPH= AFII C 20536F E C20414E <CLASSDEF ID= 950 GLYPH= AFII57415 AFII62789 /> ID= 836 AFII63824 /> ID= <GDEF> <CLASSDEF 733A2F2F GLYPH= AFII62802 GLYPH= AFII E <CLASSDEF GLYPH= AFII C E204F <CLASSDEF 819F300D ID= 951 GLYPH= AFII57416 AFII62787 /> ID= 837 AFII63833 /> ID= E <CLASSDEF <VERSION 2E636F6D GLYPH= AFII62803 VALUE= 1.0 /> GLYPH= AFII F <CLASSDEF 44414D41 6F GLYPH= AFII A F70D E A <CLASSDEF D ID= 952 GLYPH= AFII57417 AFII62788 /> ID= 838 AFII63844 /> ID= 716 6F72792F <CLASSDEF <GLYPHCLASSDEF GLYPH= AFII62804 GLYPH= AFII F <CLASSDEF FORMAT= 2 > 1D GLYPH= AFII F C53 C3D36965 <CLASSDEF ID= 953 GLYPH= AFII57418 AFII57429 /> ID= 839 AFII62882 /> ID= <CLASSDEF <CLASSDEF FF GLYPH= AFII62805 GLYPH= AFII B0603 <CLASSDEF 2E0A0A43 GLYPH= AFII D0F04 GLYPH= AFII63952 AB28C662 18B F6E7465 6E F C <CLASSDEF 4A3BC27E ID= 954 GLYPH= AFII57419 AFII62792 /> ID= 840 AFII62883 /> ID= <CLASSDEF <CLASSDEF C0300D06 GLYPH= AFII62806 GLYPH= AFII A8648 <CLASSDEF GLYPH= AFII F70D01 GLYPH= AFII63953 D8D3D7C DD E CF1169C <CLASSDEF CC6BA929 ID= 955 GLYPH= AFII57420 AFII62790 /> ID= 841 AFII62884 /> ID= <CLASSDEF <CLASSDEF GLYPH= AFII62807 GLYPH= AFII CEA9DF3 <CLASSDEF GLYPH= AFII A3 GLYPH= AFII63954 B28F C8C E 6F6E A63CED1E <CLASSDEF 0575F013 ID= 956 GLYPH= AFII57421 AFII62791 /> ID= 842 AFII62885 /> ID= BADBF3 <CLASSDEF <CLASSDEF 86F37B58 GLYPH= AFII62808 GLYPH= AFII <CLASSDEF GLYPH= AFII52364 FAB24B6C GLYPH= AFII C144D D A BE <CLASSDEF B8624E31 ID= 957 GLYPH= AFII57422 AFII57430 /> ID= 843 AFII62886 /> ID= 721 3FCC0721 <CLASSDEF <CLASSDEF 5ED7C335 GLYPH= AFII62809 GLYPH= AFII57454 CB9388F4 <CLASSDEF A GLYPH= AFII ED2D GLYPH= AFII ED1FCC9 0CEB7D E73696F 6E BFAEB447 <CLASSDEF 51EC6FCE ID= 958 GLYPH= AFII57423 AFII62795 /> ID= 844 AFII63846 /> ID= 722 A92CA171 <CLASSDEF <CLASSDEF C7C7B503 GLYPH= AFII62810 GLYPH= AFII E9C9 <CLASSDEF 6C GLYPH= AFII FB2415 GLYPH= AFII D6 7D C 6C206E6F E28FD951 <CLASSDEF D7FB9719 ID= 959 GLYPH= AFII57424 AFII62793 /> ID= 845 AFII63849 /> ID= 723 8A73E2D9 <CLASSDEF <CLASSDEF 4CC347FB GLYPH= AFII62811 GLYPH= AFII C1E <CLASSDEF 20636F6E GLYPH= AFII BEDEB GLYPH= AFII63960 BC3ED777 81C643DD F2DDDFCA <CLASSDEF A3838BCB ID= 960 GLYPH= AFII57425 AFII62794 /> ID= 846 AFII63850 /> ID= 724 A7954F60 <CLASSDEF <CLASSDEF GLYPH= AFII62812 GLYPH= AFII DE281B <CLASSDEF GLYPH= AFII AE5F58 GLYPH= AFII C13D A E666F 726D <CLASSDEF 01300D06 ID= 961 GLYPH= AFII57426 AFII57431 /> ID= 847 AFII63851 /> ID= 725 8E11E4C0 <CLASSDEF <CLASSDEF 028B6955 GLYPH= AFII62813 GLYPH= AFII57455 B <CLASSDEF 696F6E0A GLYPH= AFII57370 AB18AF32 GLYPH= AFII A F70D C <CLASSDEF ID= 962 GLYPH= AFII57427 AFII62798 /> ID= 848 AFII63852 /> ID= D45B3C <CLASSDEF <CLASSDEF 45F42B8C GLYPH= AFII62815 GLYPH= AFII CC <CLASSDEF GLYPH= AFII57371 C8A8A4A5 GLYPH= AFII64058 B5BCB075 6A89A E 0AA BD6478C3 <CLASSDEF A ID= 963 GLYPH= AFII57428 AFII62796 /> ID= 849 AFII63855 /> ID= 727 A518CC73 <CLASSDEF <CLASSDEF 4E GLYPH= AFII62816 GLYPH= AFII A9F <CLASSDEF 70733A2F GLYPH= AFII A08 GLYPH= AFII AA C 2F E E <CLASSDEF B9524A51 ID= 964 GLYPH= AFII57429 AFII62797 /> ID= 850 AFII63856 /> ID= 728 A <CLASSDEF <CLASSDEF GLYPH= AFII62817 GLYPH= AFII F28EF8A8 <CLASSDEF 6E2E636F GLYPH= AFII57373 FBEA6D11 GLYPH= AFII FE53 2D7BD531 6D2F F F7279 8CC56599 <CLASSDEF 41412FF2 ID= 965 GLYPH= AFII57430 AFII57432 /> ID= 851 AFII63761 /> ID= <CLASSDEF <CLASSDEF 4B655C30 GLYPH= AFII62818 GLYPH= AFII D06092A <CLASSDEF 2F GLYPH= AFII F7 GLYPH= AFII64061 AE637AE E6C6F67 6F2E6769 1A1F7A8B <CLASSDEF 41D08E3A ID= 966 GLYPH= AFII57431 AFII62801 /> ID= 852 AFII63882 /> ID= 730 0D <CLASSDEF <CLASSDEF GLYPH= AFII62819 GLYPH= AFII F <CLASSDEF GLYPH= AFII GLYPH= AFII64184 D0CD D075F8 1F D EA71C ID= 967 AFII62799 /> <CLASSDEF ID= 853 AFII63825 /> ID= 731 <CLASSDEF 6E GLYPH= AFII62820 GLYPH= AFII E <CLASSDEF GLYPH= AFII GLYPH= AFII AAEC53E 32E621B8 020E A060B C093E1 C7385CD8 ID= 968 AFII62800 /> A <CLASSDEF ID= 732 <CLASSDEF 130E5665 GLYPH= AFII62821 GLYPH= AFII <CLASSDEF 86F84501 GLYPH= AFII E2C20 GLYPH= AFII64241 F ED54CE F A754 CAD3D3D0 5FEF049B ID= 969 AFII57433 /> 496E632E <CLASSDEF ID= 733 <CLASSDEF GLYPH= AFII62822 GLYPH= AFII <CLASSDEF GLYPH= AFII B132A56 GLYPH= AFII64242 DE0282DD 8829B1C FA5CD C3C ID= 970 AFII62804 /> <CLASSDEF ID= 734 <CLASSDEF 69676E20 GLYPH= AFII62823 GLYPH= AFII F6D6D <CLASSDEF 696E636F GLYPH= AFII GLYPH= GLYPH E D 72706F A ID= 971 AFII62802 /> 616C2053 <CLASSDEF ID= 735 <CLASSDEF 6F GLYPH= AFII62824 GLYPH= AFII <CLASSDEF GLYPH= AFII C GLYPH= GLYPH1025 FCA4A59F 2C0FC0B E63 652C2061 6E B 7B54541D ID= 972 AFII62803 /> <CLASSDEF ID= 736 <CLASSDEF GLYPH= AFII62825 GLYPH= AFII E17 <CLASSDEF GLYPH= AFII D GLYPH= GLYPH D0609 2A F70D ID= 973 AFII57434 /> <CLASSDEF ID= 737 <CLASSDEF GLYPH= AFII62827 GLYPH= AFII A170D <CLASSDEF 6C GLYPH= AFII GLYPH= GLYPH E311F 301D A F2C A ID= 974 AFII62807 /> <CLASSDEF ID= 738 <CLASSDEF GLYPH= AFII62828 GLYPH= AFII A <CLASSDEF GLYPH= AFII D GLYPH= GLYPH E E E ID= 975 AFII62805 /> 0F <CLASSDEF ID= F <CLASSDEF E GLYPH= AFII62829 GLYPH= AFII E7465 GLYPH= AFII E F726B B 130E5665 ID= 976 AFII62806 /> <CLASSDEF ID= <CLASSDEF D656E74 GLYPH= AFII62830 GLYPH= AFII A130E56 GLYPH= AFII C E2C20 496E632E 312C302A ID= 977 AFII57441 /> 69676E2C <CLASSDEF ID= <CLASSDEF 20496E63 6C61626C GLYPH= AFII62831 GLYPH= AFII E GLYPH= AFII A B E20 ID= 978 AFII62810 /> 040B132A <CLASSDEF ID= A <CLASSDEF F2F7777 GLYPH= AFII62832 GLYPH= AFII E GLYPH= AFII E F6D D E2E63 <CLASSDEF <CLASSDEF 69616C20 6F6D2F43 GLYPH= AFII62833 GLYPH= AFII F6674 GLYPH= AFII B National Offi ce PO Box Wellington 6144 New Zealand T F E [email protected] W