Unit 16 : Software Development Standards O b jec t ive T o p r o v id e a gu ide on ho w t o ac h iev e so f t wa r e p r o cess improvement through the use of software and systems engineering standards. To give an understanding of what standards are and what they can deliver. To examine the standardisation process and issues arising from the control and evolution of standards. To show how standards can be selected and tailored. What are Standards? ÒStandards are documented agreements contain in g technical specifications or other precise criteria to be used consistently as rules, guidelines, or definitions of characteristics, to ensure that materials, products, processes and services are fit for their purpose.ó [ ISO 1 9 9 7] Standards are about providing ru le s, g u id e lin e s a n d heuristics which, if fo lowed, deliver an assurance of Ògood p r ac t ice Ó - t h e y a r e n o t in te n d ed to b e a b ou t Òb e s t p r ac t ice Ó 16Ñ1

Documented & Precise! To qualify as a s t a nd a r d t h e a g re e m e nt m us t b e d o cu m e nt e d o r a t a n y r a t e e x p lic it, it m us t b e o p e n t o s c r u t in y. Standards aspir e t o pr e c isio n e v e n if t h e y r a re ly a c h ie ve it (they are commonly incomplete and ambiguous), they must be p r e s en t e d in s u c h a wa y t h at it c a n b e in d ep e n de n t ly determined if the standard has been fo lowed. Agreements - types De jur e & D e f a ct o De jur e - t h r ou g h a f o r ma l p r o ce s s of ag r e em e n t tend to take a lo n g t im e t o re a ch tend to la s t a re a s on a b ly lo n g t im e De facto - through an im p lic it p r o ce s s of a g r ee m e n t can be achie v e d r e lat iv e ly r a p idly die quickly 16Ñ2

Agreements - parties Intra organisational Inter organisational commercial consortia (e.g. OMG, OpenGroup) professional bodies (e.g. IEEE) Procurer-lea d government (e.g. D o D) large purchaser (e.g. NASA, ESA) Standards bodie s national (e.g. ANSI, DIN ) international (e.g. ISO, ITU) Open network Ôinternet styleó Agreements - nature Volu n t ar y and consensus-based Standards refle c t m a t ur a t io n p r o ce s s of s o f tw a r e e n g in e e r in g as a formal discipline. f ro m a n a rt t o a c r af t? 16Ñ3

Why adopt a Standard? As a means of transferrin g 'good pract ice ' in s of t wa r e e n g in e e r in g As a result o f t h e d e m an d s o f c lie n t s o r p r o cu r e m en t ag e n c ie s ( who may themselves be doing so because of standards that they have adopted) As a safety net As result o f t h e a d op t ion of o t h er s t an d ar d s ( IS O9 0 00 a n d similar) or software process improvement initiatives. As a knock-on consequence of product certifica t io n r e q u ir e m en t s. Standardisation Processes Varies according to bodies engaged in standardisation. Process may be set down in ( m e t a) s ta n da r d e.g. DoD 4120.3-M Most sophis t ica t ed ar e in t e rn a t io n a l ( IS O/ IE C) s t an d ar d s. 16Ñ4

Structure e x am p le International Organisation for Standardisation (ISO) and International Electrotechnical Commission (IEC) develop and promulgate standards worldwide. To cover IT t he y ha v e f o rm e d a J o int T ec h n ic a l C o mm it t ee ( J C T1). JCT1 is div ide d in to s ub c o mm it t ee s (S C ) a n d w o r k in g g r oups ( W G ). Each WG is c ha r g ed w it h t h e d e v e lo pm e n t o f s t a nd a r ds in a specialised area (there are currently 12 WGs in software e n g in e e r in g ). D o cu m e nts e x am p le IS O p r o du c e t w o m a in ty p e s o f e n d d oc u m e nt s the international standard (IS ) and the technical reports (TR) ÒThe socia l a n d e c o no m ic lo ng - t er m b en e f it s of a n IS s h o u ld justify the total cost of preparing, adopting and maintaining the standardó. it must be demonstrated that the proposed standard is technically feasible, timely and unlikely either to be made obsolete quickly or to inhibit the benefits of technology to the u s e r s 16Ñ5

Process e x am p le Six stages to ensure ample discussion outside ISO International standards are reviewed every 5 years the result may be : retention without change revision to reflect the current state of the technology withdrawal without replacement Software Engineering Standards Normative and informative reference defining how to develop software or software intensive systems Document centred Scope for adaptatio n t o organisation /or project needs 16Ñ6

Key Examples Int. Software Engineering Standards PSS-05 (ESA) IS O- 1 2 20 7 Important American Standards DoD Mil- St d 2 9 1 5 IEEE 1074-1995 Software Process Imp r o ve m e nt St a n da r d s PSS- 05 ( ESA) A Detailed Lo ok Mandatory for all in - house development at European Space Agency all ESA contractors Also adopted outside ESA Motorola General Motors, Ford UK Defense Research Agency 16Ñ7

What Does PSS-05 Do? PSS-05 defines practices for : production phases, software lif e cy c le a n d management phases. A PSS-05 practice can be : mandatory (ÒshallÓ ), recommended (ÒshouldÓ ) a n d guiding ( ÒmayÓ ). PSS-05 Production Phases User requir e m en t s ( U R ) Software requir e m e nt s (S R ) Archit e ct u r a l de s ig n ( A D ) Detailed design & production of code (DD) Transfer of software to operatio n s ( T R ) Operations and maintenance ( OM) 16Ñ8

PSS-05 Production Phases A Detailed Lo ok PSS-05 practice s de t e r m in e f or e ac h p h a se : Input documents Activities to be conducted Output documents PSS-05 Example Practices Example practices related to the SR Phase : For in cr e m e nt a l d e liv e r y, ea c h s o f tw a r e r e q u ir e m en t sh a l include a measure of priority so that the developer can decide the production schedule Critical functions should be identified. The SRD shal be c om p ile d a c co r d in g t o th e ta b le o f contents provided in Appendix C. 16Ñ9

PSS-05 Software Lif e cy c le Three life c yc le a p pr o a ch e s a r e p r e sc r ib ed Process Engin e e r c a n s e lec t on e o f Waterfall Incremental Delivery Evolutionary Development the person responsible for ÒengineeringÓ the development p r o ce s s PSS-05 Waterfa l Approach U R S R A D DD TR O M 16Ñ10

PSS-05 Incremental Delivery Approach PSS-05 Incremental Delivery UR SR AD DD 1 TR 1 OM 1 DD 2 TR 2 OM 2 PSS-05 Evolutionary Development U R 1 S 1 R A D 1 U R 2 DD 1 TR 1... S R 2 A D 2 DD 2 O M 1 TR 2 O M 2 16Ñ11

PSS-05 Management Phases software proje ct m an a ge m e nt ( SP M ) software config u r at ion m an a ge m e n t ( S CM) software verif ic a t io n a n d v a lid at ion ( SV V ) software qualit y a s s u ra n ce ( SQ A ) PSS-05 Document Templates Standard in c lu d es a d o ze n d o cu m e n t t e m p la t es Documents have to conform to structure of templa t es PSS-05 templa te s ar e ba s e d o n IE E E St d s. 7 30, 82 8, 8 2 9, 830, 1012, 1016, 1058 and 1063. 16Ñ12

PSS-05 Template Sample : SRD 1 1 In In tr tr o o du du c c t t ion ion 2 2 General General D D es es c c r r ip ip t t io io n n 2.1 2.1 Relation Relation to to current current projects projects Describe Describe the the relationship relationship to to other other projects projects É 3 3 Specif Specif ic ic Re Re q q u u ir ir em em en en t t s s List List the the specific specific,, with with attributes attributes.. Subsections Subsections may may be be regrouped regrouped around around highlevel highlevel functions functions.. 3.1 3.1 Functional Functional 3.2 3.2 Performance Performance 3.2 3.2 Interface Interface 3.3 3.3 Operational Operational 3.5 3.5 Resource Resource 3.6 3.6 Verification Verification É...... Software Process Improvement Standards SEI/ Capability Maturity Model Bootstrap ISO- 15504 ( SPICE ) R e me m be r... the Unit on Software Process Improvement? 16Ñ13

Selection of Software Engineering Standards There is on ly a s m a ll s e t o f in te r n at io na lly re c o gn is ed s t a nd a rd s. Identify key for standard ; Negotiate with c u s t om er p r o cu r e r c o nt r a ct o r ; Evaluate standards against ; Select most appropriate standard and Tailor it Monitor use and feedback Tailoring of Standards Need for Customisa t ion Adoption to project of different size Integration with standards demanded by different procurers Integration with standards used by different developers Standards le av e s p a ce fo r ta ilo r ing Standards provide g u id e lin es ab o u t mandatory and optio n a l pr a c t ic e s the customis at ion pr o c es s its e lf 16Ñ14

Tailoring PSS-05 PSS-05 le av e s s u f f ic ie n t s p a ce fo r ta ilo r ing : Generic practices Example :A recognised design method should be selected. Mandatory vs. Re c o mm e n de d v s. Gu id in g p r ac t ices. PSS-05 Selection at DERA Case Study Coverage of whole lif e c y c le ; Coverage of all t yp e s o f s o f tw a re ; Partition of the lifecycle into phases with outputs, plus checklists for o u tp u ts ; Distinction between user and software ; Integrated approach to management Provision of a light - weight framework ; Functional definition of management roles ; Encouragement of ite r at ive de ve lo pm e n t; Treatment of contractual is su e s a s ov er la y. 16Ñ15

Customisation of PSS-05 at DERA Case Study Deal with smaller size projects Maintaining basic integrity of ESA approach Taking a system engineering perspective Integration with ISO 9000-3 Training for managers and developers Managing Standards Compliance ÒCompliance is the extent to which software developers have acted in accordance with practices set down in the standardó Consistency between actual development process and normative models embedded in standards. There is no us e ad op t ing a s t a nd a rd if yo u d on Õt mon it o r ( a nd manage) compliance to the standard! UCL Research! 16Ñ16

Future: IS O -15 2 8 8 ISO Standard for ÒSystems Engineering Lifecycle ProcessesÓ Extends IS O- 1 22 0 7 t o sy s t e m e n g in e e r in g p r oc e s s e s Reflects composition of systems from systems, where each system has its own lifecycle. To be comple t e d b y 2 0 00 / 01 Watch this space! Key Points Standards are about good practic e, n ot ne c e s s ar ily b e s t practice. If carefully targetted the adoption of standards can yield significant process improvements - CHEAPLY. Even where s t a nd a rd s ar e no t ad o pt e d t h e y c a n b e u s e d a s a b e n c hm a r k You cannot expect to adopt a standard without significant work in tailoring and customisation You need to feedback inf o rm a t io n o n t h e u s e o f t h e s t a nd a rd into the selection, adoption and tailoring processes. You need t o p lay a p a rt in t h e d e ve lop m e n t a n d e v o lu t io n o f t h e standards themselves 16Ñ17