Post on 13-Feb-2020
transcript
ISO/IEC 12207INTERNATIONAL STANDARD
SOFTWARE LIFE CYCLE PROCESSES
AN INTRODUCTION
TO
RAGHU SINGHFAA, WASHINGTON, DCApril 26, 1999
ISO/IEC 12207PURPOSE
ii
• To establish a common framework for the life cycle of software
- To foster mutual understanding among business parties - To acquire, supply, develop, operate, and maintain software - To manage, control, and improve the framework.
For World Trade in software:“… facilitating international exchange of goods and services …”
ISO/IEC 12207
iii
ACQUIRERS , SUPPLIERS , USERS, ...STAKEHOLDERS:
GRAVECRADLE ...LIFE CYCLE:
CORPORATE
...PRODUCTS
PROJECTSERVICES
PROJECTAPPLICATION:
**
* NOT COVERED IN 12207, BUT SOME GUIDANCE IN ISO/IEC 15271
DETAILS:
SCOPE
PROCESS DEFINITIONS &DESCRIPTIONS
METHODOLOGIES,METHODS &
METRICS
PROCEDURES,TECHNIQUES,
TOOLS &ENVIRONMENTS
PROCESSES
TOPICS
1-0
1. BACKGROUND - ISO and IEC - History of ISO/IEC 12207
2. BASIC CONCEPTS
3. THE PROCESSES
4. APPLICATION
5. RELATED AREAS
6. SUMMARY
7. FOR YOUR INFORMATION
BACKGROUND - IISO
INTERNATIONAL ORGANIZATION FOR STANDARDIZATION
• ESTABLISHED: 1947
• OBJECT: Promote the development of standardization ... in the world... to facilitating international exchange of goods and services
• MEMBERS: 87 countries (1994)
• TECHNICAL COMMITTEES (TCs): Carry out technical work
• TCs THAT MAY IMPACT SOFTWARE ENGINEERING:- TC 10: Technical Drawings- TC 20: Space and aircraft vehicles - TC 46: Information and documentation- TC 145: Graphical symbols- TC 154: Documents and data elements in administration, commerce and industry- TC 159: Ergonomics- TC 176: Quality management and quality assurance- TC 184: Industrial automation systems
1-1
BACKGROUND - IIIEC
INTERNATIONAL ELECTROTECHNICAL COMMISSION
• ESTABLISHED: 1906
• OBJECT: Standardization in electrical and electronicengineering fields
• TECHNICAL COMMITTEES (TCs):- Carry out technical work
• TCs THAT MAY IMPACT SOFTWARE ENGINEERING:- TC 45: Nuclear instrumentation- TC 56: Dependability and maintainability- TC 65: Industrial process measurement/control
1-2
BACKGROUND - IIIJOINT TECHNICAL COMMITTEE 1
INFORMATION TECHNOLOGY
1-3
IECISO
SC1 - Vocabulary
SC2 - Character sets & information codingSC6 - Telecommunications & information exchange between systemsSC7 - Software engineeringSC11 - Flexible magnetic media for digital data interchangeSC14 - Representation of data elementsSC15 - Labeling and file structureSC17 - Identification cards & related devicesSC18 - Document processing and related communication
SC21 - Information retrieval, transfer & management for OSISC22 - Programming languages, their environments & systems software interfacesSC23 - Optical disk cartridges for information interchangeSC24 - Computer graphics and image processingSC25 - Interconnection of information technology equipmentSC26 - Microprocessor systemsSC27 - IT security techniquesSC28 - Office equipmentSC29 - Coded representation of picture, audio and multimedia/hypermedia information
ESTABLISHED: 1987
OBJECT: TO CARRY ON STANDARDIZATION WORK IN INFORMATION TECHNOLOGY
JTC1
SC7CHAIRMAN: FRANCOIS COALLIER (CANADA)
SECRETARY: JEAN-NORMAND DROUIN (CANADA)
WG 2SYSTEM SOFTWARE DOCUMENTATION
CONVENER: KEN JOHNSON (UK)
WG 12FUNCTION SIZE MEASUREMENT
CONVENER: PAMELA MORRIS (AUSTRALIA)
WG 4TOOLS AND ENVIRONMENT
CONVENER: THOMAS VOLLMAN (USA)
WG 6EVALUATION & METRICS
CONVENER: MOTOEI AZUMA (JAPAN)
WG 7LIFE CYCLE MANAGEMENT
CONVENER:
WG 8SUPPORT OF LIFE CYCLE PROCESSES
CONVENER: STAN MAGEE (USA)
WG 9SOFTWARE INTEGRITY
CONVENER: DAVID KIANG (CANADA)
WG 10PROCESS ASSESSMENT
CONVENER: ALEC DORLING (UK)
WG 11Sw ENGINEERING DATA DEFINITION
CONVENER: PETER EIRICH (USA)
1-4
BACKGROUND - IV
SOFTWARE ENGINEERING
WG 13Sw PROCESS MEASUREMENT
CONVENER: JOHN McGARRY (USA)
BACKGROUND - VISO/IEC 12207
• SPONSOR:Joint Technical Committee 1 (JTC1) (Information Technology) ofInternational Organization for Standardization (ISO) andInternational Electrotechnical Commission (IEC)- Developer: Subcommittee 7 (SC7) (Software Engineering)
• HISTORY:- Proposed in June 1988- 4 Working Drafts; 2 Committee Drafts; 1 DIS- Over 6 years and 17000 person-hours expended- Published 1 August 1995
• PARTICIPANTS:- Countries: Australia, Canada, Denmark, Finland, France, Germany, Ireland, Italy, Japan, Korea, Netherlands, Spain, Sweden, UK, USA- Convener: James Roberts (USA)- Editor: Raghu Singh (USA)
1-5
TOPICS
1. BACKGROUND
2. BASIC CONCEPTS - Principles and assumptions under 12207 development - Concepts for understanding the standard
3. THE PROCESSES
4. APPLICATION
5. RELATED AREAS
6. SUMMARY
7. FOR YOUR INFORMATION
2-0
BASIC CONCEPTS - ILIFE CYCLE & ITS ARCHITECTURE
• TITLE OF 12207: Software Life Cycle Processes- Meaning: The processes in the life cycle of software
• THE ARCHITECTURING OF THE LIFE CYCLE:
2-1
LIFE CYCLE
FROMCONCEPTUALIZATION
THROUGHRETIREMENT
RULES:MODULARITY;RESPONSIBILITY
RULE:PDCA cycle
PROCESSn
PROCESS1
PROCESS...
ACTIVITY 1
ACTIVITY N
TASKS
TASKS
. . .
BASIC CONCEPTS - IIRULES FOR PARTITIONING THE LIFE CYCLE
• MODULARITY- Cohesion (Functional): Tasks in a process are functionally related.- Coupling (Internal): Linkages among the processes be minimal- Association:
- If a function is used by more than one process, then the function becomes a process in itself- If Process X is invoked by Process A and Process A only, then Process X belongs to Process A
- Exception: Only for potential future application.
• RESPONSIBILITY- Each process is under a responsibility- A function whose parts are under different responsibilities shall not be a process- Contrast it with a process for a monolithic subject - Example: Quality management
• Note: The life cycle itself was not partitioned in time, as the life cycle of software follows its parent system’s life cycle.
2-2
2-3
BASIC CONCEPTS - IIITHE PROCESS TREE
LIFE CYCLE
TAILORING
CONFIGURATION MANAGEMENTDOCUMENTATION
QUALITY ASSURANCEVERIFICATION
VALIDATIONJOINT REVIEW
AUDITPROBLEM RESOLUTION
PRIMARY
DEVELOPMENT
OPERATION
MAINTENANCE
ACQUISITION
SUPPLY
ORGANIZATIONALMANAGEMENT
INFRASTRUCTUREIMPROVEMENT
TRAINING
SUPPORTING
BASIC CONCEPTS - IVRULES FOR PARTITIONING A PROCESS
• A PROCESS IS PARTITIONED INTO PDCA ACTIVITIES- BASED THE PDCA-CYCLE PRINCIPLES
2-4
PLANTasks,
Assignments,Schedule, ...
CHECKEvaluation,Assurance
DOExecution of
plans and tasks
ACTProblem resolution,Corrective actions
PROCESS
INITIATION
CLOSURE
BASIC CONCEPTS - VACTIVITY & TASKS
• AN ACTIVITY IS DIVIDED INTO TASKS, WHICH AREGROUPED INTO SIMILAR ACTIONS
• TASK: - A what-to-do action; not a how-to-do action - Verbs used:
2-5
SHALL (requirement)
SHOULD (recommendation)
MAY (permission)
CAN (possibility, when needed)
MUST (unavoidable action), not used
WILL (self-declaration) +VERB
None of the above; present tense #
# Not a requirement. Used in preamble, assumption, or to complete the context.+ Not mentioned in the IEC/ISO Directive.
BASIC CONCEPTS - VI
• BASED ON TQM PRINCIPLES- Each party/participant has appropriate responsibility- Plan-Do-Check-Act (PDCA) cycle built into processes- Consistent with “functional” modularity and internal coupling
• ESTABLISHES LINK WITH SYSTEM- System activities are the foundation for software activities - Needs analysis, development, operation, maintenance, ... - Analysis, design, fabrication, integration, testing, ...- Software is treated as a part of the system - Necessary system context provided
- System assigns functions to software - Software extracted from, developed within,
and integrated back into the system - Software personnel participate in system activities
2-6
BASIC CONCEPTS - VII
• ORGANIZATION & PARTY - Organization: An independent body of persons - Party: One who enters into an agreement - Parties may be from the same or separate organization(s) - An organization (party) gets its name from the process it executes, and the name is functional - Acquirer executes Acquisition process
• MULTI ROLES: - A party may have more than one role - Example: A supplier with a sub-contractor is both supplier and acquirer.
• LEVELS OF APPLICATION - By a person as a self-imposed standard - By an organization internally - Between persons within an organization - Between two organizations
2-7
ORGANIZATIONB
MYSELF ORGANIZATIONA
• RANGE OF AGREEMENT: From informal to legal contract.
• LANGUAGE- General: Introductory; to complete the situation/context; ...- Agreement: To facilitate self-imposed and contractual use- Active voice when party is clearly known- Passive voice when party is not clearly known, or when it is better syntactically
• PROJECT- A project may be solo- A project may exist in pre-agreement, agreement, or post-agreement phase, or a combination of the above- A project may span full or a part of life cycle
• DESIGNED FOR ADAPTATION AND TAILORING- Adaptation by an organization- Tailoring by a project- To fit the needs, size, complexity, cost, schedule, performance
BASIC CONCEPTS - VIII
2-8
BASIC CONCEPTS - IXCOMPLIANCE & CERTIFICATION
• COMPLIANCE
Absolute level -- Default (IEC/ISO Directive 3, 4.1.2): All “shalls” and “wills” are performed.
- To claim compliance with the Standard. - Note that compliance with the full Standard may not be realistic.
Project level (ISO/IEC 12207, clause 1.4, paragraph 1): Parties develop an agreement, with which they comply.
- The agreement includes plans and tasks from 12207 and elsewhere. - Parties perform in accordance with the agreement. - 12207 itself then stays on the sidelines, its purpose served.
Organizational level (ISO/IEC 12207, clause 1.4, paragraph 2):
Organization declares public a set of clauses with which its suppliers comply.
• CERTIFICATION - Not addressed in 12207
- Note that certifying an organization to the full Standard may not be realistic.2-9
BASIC CONCEPTS - XWHAT 12207 IS NOT
• NOT PRESCRIPTIVE; NO HOW-TOs- Responsive to evolving technologies- No interference in technical decision-making
• NOT A STANDARD FOR METHODS, TECHNIQUES & MODELS:- Does not prescribe management and engineering methods- Does not prescribe computer languages- Does not prescribe software engineering environments- Does not prescribe life-cycle or development models - Waterfall; incremental; evolutionary; Spiral, reengineering, ...
• NOT A STANDARD FOR PRODUCTS- Requires specific output groups be documented- But prescribes no formats, explicit contents, or media- An organization's product standards usable with 12207
• NOT A STANDARD FOR METRICS- Many tasks need metrics and indicators- But prescribes no specific metrics/indicators- References ISO/IEC 9126 for guidance
2-10
BASIC CONCEPTS - XI• A MANAGEMENT COMPLEMENT
- 12207 complements institutionalized management - 12207 is not a substitute for systematic, disciplined management - It provides a powerful and complete but flexible set of building blocks of software life cycle for projects and organizations to use as appropriate and effective
• PREREQUISITES TO USING THE STANDARD: - Understanding of 12207 - Organization's policies - Project's requirements and characteristics - Project's life-cycle model(s) - Institutionalization of methods, procedures, techniques, tools and environment for performing the 12207 and other tasks - Trained personnel
2-11
Instill life cycle view!
BASIC CONCEPTS - XIIMAJOR ISSUES DURING 12207 DEVELOPMENT
• ARCHITECTURE:- Based on responsibilities; fix it for the parties? [U] - Acquisition, development, maintenance, ...- Monolithic topics; let the parties figure out? - Management, contracting, engineering, quality, ...
• SOFTWARE v. SYSTEM:- Include necessary system activities? [U]- Only software specific?
• LANGUAGE OF CLAUSES:- Declarative? [U]- Imperative?
• EVALUATIONS:- Assign evaluations to all parties appropriately? [C] - Do some evaluations become duplicative?- Place all evaluations under quality control?
• LEGEND: U- unanimous; C - consensus2-12
TOPICS
1. BACKGROUND
2. BASIC CONCEPTS
3. THE PROCESSES- Introductory material- Explanation of the processes and their interactions- Coverage of special topics in the processesNote: In charts, start at if shown
4. APPLICATION
5. RELATED AREAS
6. SUMMARY
7. FOR YOUR INFORMATION
3-0
THE PROCESS TREE
3-1
LIFE CYCLE
TAILORING
CONFIGURATION MANAGEMENTDOCUMENTATION
QUALITY ASSURANCEVERIFICATION
VALIDATIONJOINT REVIEW
AUDITPROBLEM RESOLUTION
PRIMARY
DEVELOPMENT
OPERATION
MAINTENANCE
ACQUISITION
SUPPLY
ORGANIZATIONALMANAGEMENT
INFRASTRUCTUREIMPROVEMENT
TRAINING
SUPPORTING
STATIC VIEW OF A PROCESS
3-2
THE LAYOUT
a.b Process name
Preamble
- Abstract of the process- Generic actions at corporate level- In present tense- No requirements- Introduces a list of activities.
Activities & Tasks
- All with shall, will, should, may, can- Except 5.1.1.1, 5.2.1.1 (present tense) - To complement the context- For project products and services
a.b.n: Activity n in process a.ba.b.n.1: Task 1 in activity n, process a.b...a.b.n.m: Task m in activity n, process a.b
PREAMBLEEMPLOY
ACTIVITIES& TASKS
CLAUSES
EMPLOY
MANAGEMENTINFRASTRUCTUREIMPROVEMENTTRAININGTAILORING
ORGANIZATIONALPROCESSES
FOR CORPORATEMANAGEMENT
OF PROCESSES
FOR PROJECTS
PRIMARYAND
SUPPORTINGPROCESSES
INSTANTIATED
X PROCESS
3-3
PROCESS EMPLOYED OUTPUTFUNCTION
MANAGEDPROJECT
PRIMARYPROCESSES
PROJECTMANAGEMENT
WITH PROCESSES
- INSTITUTIONALIZED PROCESSES- MANAGED PROCESSES- TAILORED/TOOLED PROCESSES FOR PROJECTS
CORPORATEMANAGEMENT
OFPROCESSES
[NOT OFCORPORATION]
THE WORKINGS
TAILORINGPROCESS
- FOR ADAPTATION
ORGANIZATIONALPROCESSES
SUPPORTINGPROCESSES
TAILORINGPROCESS
DYNAMIC VIEW OF PROCESSES
STRATEGY FOR EXPLAINING THE PROCESSESIN THE TUTORIAL
• 12207 BEGINS THE DESCRIPTION OF EACH PRIMARY AND SUPPORTING PROCESS AT THE CORPORATE LEVEL BY INVOKING: - MANAGEMENT PROCESS - INFRASTRUCTURE PROCESS - IMPROVEMENT PROCESS - TRAINING PROCESS - TAILORING PROCESS
• 12207 CONTINUES WITH THE DESCRIPTION FURTHER AT THE PROJECT LEVEL -- IN ACTIVITIES AND TASKS.
• THIS PRESENTATION, FOR SAKE OF SPACE AND CLARITY, WILL EXPLAIN: - FIRST, THE PRIMARY AND SUPPORTING PROCESSES AT PROJECT LEVEL - THEN, THE ORGANIZATIONAL PROCESSES AT CORPORATE LEVEL.
3-4
REQUIREMENTS
• REQUIREMENT:- An expectation/demand as a compliance/obligation/agreement- Indicated by a "shall" or a "will"- The qualifier to a requirement identifies its source and receiver; no qualifier means in local, immediate context- May contain constraints on design, interface, test, or development/test/operation/maintenance environment
• SPECIFICATION:- Technical description (form, fit, and function) of a requirement
• DYNAMICS:- A step may generate requirements for a neighboring or distant step.- Requirements/specifications typically change and expand in time.- The challenge is managing the changing requirements.
3-5
REQ/SPEC REQ/SPECREQ/SPEC REQ/SPECREQ/SPECREQ/SPECSTEP 1 STEP 2
STEP N
Without requirements, there really is no project.
EVALUATIONIt’s an elementary function!
3-6
EVALUATION
CRITERIAAt various levels:Requirements,Derived reqmts.,Ad hoc conditions,...
ENTITYProcess,Activity, Task,Inputs, Outputs,Data, Product,Plan, Contract,Report, ...
RESULTS;REPORTS
PROCESS 1 BETWEENPROCESSES
1 & 2 E VALU ATE JOINTLY
1 EV AL U AT ES 2
PURPOSECheck, Review,Audit, Verify,Validate, Assure,Inspect, Monitor,Control, Improve, ...
FORUMDiverse, Different,Formal, Informal,Peer, Independent
MOTIVECritique,Defend
INTERNALEVALUATIONS
PROCESS 2INTERNAL
EVALUATIONS
PRIMARY PROCESSES
3-7
PDCA
01: START HERE
O1, O2: THE SAME POINTS
E: EXECUTE; T: TASK; U: USE
MAINTENANCE
DEVELOPMENT
OPERATION
SUPPLYACQUISITIONT
0201E/T
T
U
ACQUISITION PROCESS
3-8
JOINTREVIEW
VERIF. VALID.AUDIT
INITIATION
SUPPLIERMONITORING
CONTRACT
& UPDATE
ACCEPTANCE& COMPLETION
RFP [TENDER]PREPARATION
PREPARATION INTERNALCONTROL
DEVELOPMENT
• COVERS PRE-CONTRACT AND CONTRACT PERIODS.
CONTRACT
T
CONTRAC
PRE-
• FOR THE ACQUIRER OF SOFTWARE PRODUCTS AND SERVICES.
TAILORING
INVOKED PROCESSINTERNAL USE
- SYSTEM REQS.- ACQ. PLAN- ACCEPTANCE CRITERIA
ACQ. REQS. INCL.- SELECTED TASKS- REFERENCES TO CONTRACT
- CONTRACT WITH SUPPLIER- CONTRACT WITH OTHERS
MONITORING &EVALUATIONRESULTS
ACCEPTEDPRODUCTS &SERVICES
ACTIVITIES OUTPUTS
ACQUISITION PROCESSACTIVITIES & TASKS
3-9
• DOCUMENT ACQUISITION REQS.• SELECT ACTIVITIES & TASKS• DEFINE REFS. TO CONTRACT• SET REVIEW MILESTONES
• PREPARE FOR ACCEPTANCE; INCLUDE TESTS• CONDUCT ACCEPTANCE REVIEW & TESTING• ACCEPT DELIVERABLES• ASSUME CM
• DESCRIBE THE NEEDS• DEFINE SYSTEM REQUIREMENTS• DEFINE SOFTWARE REQS. (MAYBE)• PREPARE ACQUISITION PLAN• DEFINE ACCEPTANCE STRATEGY
• ESTABLISH SUPPLIER SELECTION PROCEDURES• SELECT SUPPLIER• TAILOR 12207; - INVOLVE PARTIES• NEGOTIATE CONTRACT
>> CONTRACT UNDERWAY
• MONITOR IN ACCORDANCE WITH JOINT REVIEW & AUDIT• SUPPLEMENT WITH V & V
1. INITIATION
2. RFP [TENDER]
3. CONTRACT PREPARATION & UPDATE
4. SUPPLIER MONITORING
5. ACCEPTANCE & COMPLETION
SUPPLY PROCESS
3-10
• COVERS PRE-CONTRACT AND CONTRACT PERIODS.• FOR THE PROVIDER OF PRODUCTS/SERVICES. QUALITY SUPPLY CO.
INTERNAL USE INVOKED PROCESSACTIVITIES OUTPUTS
INITIATION BID DECISION
RESPONSE
PREPARATIONOF PROPOSAL
PRE-CONTRACT
SELECT ONE OR MORE
MNT.OPN.DEV. ACQ.
JT. REV. V&V QAAUDIT
MONITOR,CONTROL
CONTRACT
PLANNING
EXECUTION& CONTROL
REVIEW &EVALUATION
DELIVERY &COMPLETIO
N
CONTRACT
LC MODEL &PROJ. MGMT.
PLAN
RESULTS
REVIEW/EVALUATION
DELIVEREDPRODUCTS/SERVICES
MONITORINGRESULTS
CONTRACT
SUPPLY PROCESSACTIVITIES & TASKS
3-11
1. INITIATION
• REVIEW RFP• DECIDE TO BID; ACCEPT CONTRACT
• REVIEW ACQ REQS• SELECT LIFE CYCLE MODEL, AS NEEDED• ESTABLISH REQS. FOR PLANS• DEVELOP & DOCUMENT PROJECT MANAGEMENT PLANS [PMP; 15 ITEMS]
• COORDINATE WITH ACQUIRER• JOINT REVIEW• AUDIT• V&V• ACCESS TO ACQUIRER• QA PER QA PROCESS
• DELIVER PRODUCT OR SERVICE• PROVIDE ASSISTANCE
• PREPARE PROPOSAL
• NEGOTIATE & ENTER INTO CONTRACT WITH ACQUIRER• REQUEST MODS.
• EXECUTE PMPs• DEVELOP, OPERATE, OR MAINTAIN• MONITOR/CONTROL PROGRESS/QUALITY• MANAGE SUBS• INTERFACE WITH IVVT• INTERFACE WITH OTHER PARTIES
2. PREPARATION OF RESPONSE
3. CONTRACT
4. PLANNING
5. EXECUTION & CONTROL
6. REVIEW & EVALUATION
7. DELIVERY & COMPLETION
>> CONTRACT UNDERWAY
DEVELOPMENT PROCESS
3-12
SYS. QUALIF. TEST EVALUATIONS AUDITS
SYS. INTEGRATION EVALUATIONS INTEGRATEDSYSTEM
SW QUALIF. TEST EVALUATIONS AUDITS QUALIFIED SCIs
SW INTEGRATION EVALUATIONS JT. REVIEWS INTEGRATEDSOFTWARE (SCIs)
SW CODE/TEST EVALUATIONS SOFTWARECODE/DATABASE
SW DET. DESIGN EVALUATIONS JT. REVIEWS SOFTWAREDETAILED DESIGN
SW ARCH. DESIGN EVALUATIONS JT. REVIEWS SOFTWAREARCHITECTURE
SW REQ. ANALYSIS JT. REVIEWSEVALUATIONS SOFTWAREREQUIREMENTS
SYS. ARCH. DESIGN EVALUATIONS SYS. ARCHITECTURE- HW, SW, MO
SYS. REQ. ANALYSIS EVALUATIONS SYSTEMREQUIREMENTS
SW ACCPT. SUPPORT DELIVERABLESOFTWARE
SW INSTALLATION EVALUATIONS INSTALLED SWINSTALLATION PLAN
PROCESSIMPLEMENTATION DOCUMENTATION C.M. PROBLEM RESOLUTION
DEVELOPMENTPLANS & MODELS
• FOR THE DEVELOPER (MODIFIER) OF SOFTWARE PRODUCTS • MAY PERFORM OR SUPPORT SOME SYSTEM ENGINEERING
OUTPUTS• ACTIVITIES NOT NECESSARILY IN TIME ORDER
ACTIVITIES
ISO/IEC 9126
QUALIFIED SYSTEM
INTERNAL USE INVOKED PROCESS
(DESIGN & CODE)
DEVELOPMENT PROCESSACTIVITIES & TASKS
3-13
1. PROCESS IMPLEMENTATION
4-9, 12,13. SOFTWARE ACTIVITIES
2,3,10,11. SYSTEM ACTIVITIES
• PERFORM
• PERFORM OR SUPPORT
• SELECT/TAILOR INTERNAL METHODS/TOOLS/...• DEVELOP, DOCUMENT, EXECUTE PLANS
5. SOFTWARE ARCHITECTURAL DESIGN
8. SOFTWARE INTEGRATION10. SYSTEM INTEGRATION
• IDENTIFY COMPONENTS OF THE SOFTWARE ITEM
• PRODUCE AN ARCHITECTURE OF THE SOFTWARE ITEM
3. SYSTEM ARCHITECTURAL DESIGN• PRODUCE AN ARCHITECTURE OF THE SYSTEM• IDENTIFY HW, SW AND MANUAL OPERATIONS ITEMS
• INTEGRATE IN AGGREGATES• PARTITION AND INTEGRATION PATHS MAY BE DIFFERENT
• DEFINE/SELECT DEVELOPMENT MODEL(s) - The foundation of a project - Detailed with iterations/recursions of the activities & tasks of Development and invoked Supporting processes
• EMPLOY REGULARLY DOC, CM, AND PROB. RES. PROCESSES
• MAY USE NON-DELIVERABLES - Avoid dependency of future operations & maintenance on these
7. SOFTWARE CODING & TESTING
• CODE UNITS & DATABASES• IF NEEDED, CODE SHOULD BE COMPILABLE AND TESTABLE
ORGANIZATION OF A SYSTEM
3-14
LEGEND: CI: CONFIGURATION ITEM;HW: HARDWARE; SW: SOFTWARE; FW: FIRMWARE, PW: PEOPLEWAREPROC: PROCESS; SVC: SERVICE.
• LOWER CIs MAY BE PARTITIONED FURTHER UNTIL SUITABLE FOR INDIVIDUAL TREATMENT• THE CIs MAY BE NOT ALL DISTINCT• PARTITIONING AND INTEGRATION PATHS CAN BE DIFFERENT
AN EXAMPLE
CI-2122SW
CI-2121HW
CI-211HW
CI-212FW
CI-213SW
CI-21SUB2-SYS
CI-2221HW
CI-2222SW
CI-221HW
CI-222FW
CI-22SUB2-SYS
CI-2SUB-SYS
CI-121HW
CI-122SW
CI-11HW
CI-12PROC
CI-13HW
CI-1SUB-SYS
CI-n1SVC
CI-n2PW
CI-nSUB-SYS
SYSTEM
+
+ CONTINUED TO THE NEXT CHART
3-15
SCm
SUSU
SUSU
SC1
SOFTWARECI-2222
SC2
SUSU SU
+ SOFTWARE ORGANIZATION[CI-2222 FROM THE PREVIOUS CHART]
LEGEND:SC - SOFTWARE COMPONENT; SU -SOFTWARE UNIT
• 12207 ASKS FOR ARCHITECTURE AND DESIGN, BUT DOES NOT IMPLY STYLE, REPRESENTATION OR DERIVATION METHODS• SUs MAY BE NOT ALL DISTINCT• IF NEEDED, AN SU MUST BE COMPILABLE AND TESTABLE• DECOMPOSITION AND INTEGRATION PATHS MAY BE DIFFERENT
DEVELOPMENT PROCESSTHE HORSE
3-16
SOF. REQ. ANALYSIS>
<
SOF. QUALIF. TEST>
<
SYS. QUALIF. TEST<
>
...
SOF. ACCPT. SUPPORT>
<
SYS. REQ. ANALYSIS>
<
SYS. ARCH. DESIGN>
<
...
...
DEVELOPMENT MODEL(S); METHODS, TOOLS, ...;DEVELOPMENT PLAN(S)
MODEL & PROJECT MANAGEMENT PLAN(S)
SYSTEM REQUIREMENTS & SPECIFICATIONS
SOFTWARE REQUIREMENTS & SPECIFICATIONS[BASELINES]
SYSTEM ARCHITECTURE [HW, SW, MO]
DELIVERABLE PRODUCTS & SERVICES
ENTER
EXIT
SOFTWARE DESIGN & CODE [BASELINES];USER'S MANUALS, ...
><
SUPPLY PROCESS
>
<
PROCESS IMPLEMENTATIONDEVELOPMENT PROCESS
• ALL ACTIVITIES [TASKS] IN A PROCESS [ACTIVITY] NOT NEEDED IN EACH ITERATION OR RECURSION, BUT SHOULD BE COMPLETED BY THE FINAL ITERATION OR RECURSION
• ITERATIONS/RECURSIONS ENCOURAGED: - TO BUILD SPECIFIC MODELS - TO OFFSET DEFAULT MODELS
• PROJECTS ESTABLISH BASELINES - OF WHAT & WHEN• BASELINING AT PRE-DETERMINED REVIEWS/AUDITS - FORUM TO INVOLVE KEY PARTIES
• AT LEAST 3 BASELINED PRODUCTS: - REQUIREMENTS, DESIGN, CODE
• BASELINES INHIBIT UNPLANNED OR EASY CHANGES
OPERATION PROCESS
3-17
• FOR THE OPERATOR OF A SYSTEM CONTAINING SOFTWARE
OPERATIONALRELEASED
SOFTWARE
INTERNALTESTING &
ENSURANCE
QUALITY LINES
MAINTENANCE
[FUNCTIONSPERFORMED]
- OPERATION PLAN
- OPERATIONPROCEDURES
PROCESSIMPLEMENTATION
SYSTEMOPERATION
USERSUPPORT
OPERATIONALTESTING
- USER REQUESTS
RESOLUTIONS- PROBLEM
PROBLEMRESOLUTION
OUTPUTSACTIVITIES INTERNAL USE INVOKED PROCESS
OPERATION PROCESSACTIVITIES & TASKS
3-18
• PROVIDE ASSISTANCE TO USERS• FORWARD USER REQUESTS TO MAINTENANCE AS NEEDED• FOR TEMPORARY FIXES, PROVIDE OPTION TO USE IT
• OPERATE IN ENVIRONMENT
• PERFORM OPERATIONAL TESTING FOR EACH RELEASE• RELEASE AFTER CRITERIA MET• ENSURE CODE/DATABASE PERFORM AS PLANNED
• DEVELOP OPERATIONAL PLAN• SET OPERATIONAL STANDARDS• DOCUMENT AND EXECUTE PLAN• ESTABLISH PROCEDURES FOR/WITH PROBLEM RESOLUTIONS• ESTABLISH PROCEDURES FOR OPERATIONAL TESTING• ESTABLISH PROCEDURES FOR INTERFACING WITH MAINTENANCE PROCESS• ESTABLISH PROCEDURES FOR RELEASING PRODUCTS FOR OPERATIONAL USE
1. PROCESS IMPLEMENTATION
2. OPERATIONAL TESTING
3. SYSTEM OPERATION
4. USER SUPPORT
MAINTENANCE PROCESS
3-19
PROBLEMRESOLUTION
CMPROCESSIMPLEMENT
PROB/MOD.ANALYSIS
MOD.IMPLEMENT.
MAINT.REVIEW/ACCEPT.
MIGRATION
RETIREMENTSOFTWARE
MAINTENANCEPLANS/PROCS.
PROB./MOD.ANAL/SOLN.
MODIFIEDSOFTWARE
REVIEWRESULTS
DEVELOPMENT
INTERNALREVIEWS
HDQUALITYFIXING
• FOR THE MAINTAINER OF SOFTWARE PRODUCTS
OUTPUTSACTIVITIES INTERNAL USE INVOKED PROCESS
- RETIREMENT PLANS- ARCHIVES
INTERNALREVIEWS
- MIGRATION PLANS/REPORTS- MIGRATED SYS.
MAINTENANCE PROCESSACTIVITIES & TASKS
3-20
• Develop, document and execute plan• Establish procedures for problem reports and modifications requests• Manage modifications
• Analyze modifications for impacts• Replicate/verify problems• Implement modifications• Document and get approval
• Determine targets of modifications• Use Development Process for mods.• Supplement with testing to ensure modified and unmodified parts are correctly done
• Review with authorizing organization
• Develop/document/ execute plan• Notify users, etc.• Do parallel operations• Do post-operations for impact
• Develop/document/ execute plan• Notify users, etc.• Do parallel operations• Provide for access to retired data/products
1. PROCESS IMPLEMENTATION
2. PROBLEM/ MODIFICATION ANALYSIS
3. MODIFICATION IMPLEMENTATION
4. MAINTENANCE REVIEW/ ACCEPTANCE
5. MIGRATION
6. SOFTWARE RETIREMENT
SUPPORTING PROCESSES
3-21
QUALITYASSURANCE
PROBLEMRESOLUTION
AUDIT
JOINTREVIEW
VALIDATION
VERIFICATION
CONFIGURATIONMANAGEMENT
DOCUMENTATION
ACQUISITION
SUPPLY
DEVELOPMENT
OPERATION
MAINTENANCE
• TO SUPPORT ANOTHER PROCESS BY PERFORMING A SPECIFIC FUNCTION
ARROWS: EMPLOY/INVOKE
DOCUMENTATION PROCESS
3-22
MAINTENANCE MODIFIEDDOCUMENTS
CONFIGURATIONMANAGEMENT
PROCESS
PLAN
DOCUMENTATIONIMPLEMENTATION
PRODUCTIONDOCUMENTS
PRODUCED
DESIGN ANDDEVELOPMENT
"PREPARED"
DOCUMENTS
OUTPUTSACTIVITIES INTERNAL USE INVOKED PROCESS
• FOR ESTABLISHING DOCUMENTATION STANDARDS: MEDIA, FORMAT, OUTLINE, CONTENT, FILING, DISTRIBUTION, ... - EXAMPLES: YOUR ORGANIZATION'S USER'S MANUALS; US DOD DIDs; IEEE SRS, ...• THIS PROCESS DOES NOT PRESCRIBE ANY OF ABOVE; THE INVOKING PROCESS DOES
CONFIGURATION MANAGEMENT PROCESS
3-23
INTERNALACCESS CONTROL
& AUDIT
CONFIGURATIONCONTROL
ACCOUNTINGSTATUS
CONFIGURATION
RESULTS
CONFIGURATIONCONTROL
EVALUATION
REPORTS
CONFIGURATION
MANAGEMENT
PLAN
CONFIGURATIONEVALUATION
INTERNALEVALUATION
IMPLEMENTATIONPROCESS
RELEASE
& DELIVERY
CONFIGURATIONIDENTIFICATION
SCHEMA
CONFIGURATION
STATUS
MANAGEMENT
REPORTS
PRODUCTS
- IDENTIFICATION
- BASELININGDOCUMENT
DELIVERABLE
OUTPUTSACTIVITIES
• FOR CM OF PRODUCTS AND TASKS• INTERNAL OR EXTERNAL TO THE INVOKING PROCESS• THIS PROCESS IDENTIFIES BASELINED PRODUCTS; THE INVOKING PROCESS ESTABLISHES BASELINES
INTERNAL USE INVOKED PROCESS
QUALITY ASSURANCE PROCESS
3-24
PROCESS
IMPLEMENTATION
QUALITYASSURANCE
PLAN
V&V, JT. REVIEW,AUDIT AS TECHNIQUES
PROBLEMRESOLUTION
ASSURED
PROCESS
ASSURANCE
PROCESSES
ASSURANCEOF QUALITY
SYSTEMS
AS SPECIFIEDIN THE
CONTRACTISO 9001
PRODUCT
ASSURANCE
PRODUCTS
ASSURED
• FOR ASSURING CONFORMANCE OF PRODUCTS/SERVICES WITH REQUIREMENTS AND ADHERENCE TO PLANS• EXTERNAL, WITH ORGANIZATIONAL FREEDOM• USES THE TERM "ASSURE" INSTEAD OF "EVALUATE"
OUTPUTSACTIVITIES INTERNAL USE INVOKED PROCESS
INCLUDE RESULTS OF V&V, JT. REVIEW,AUDIT, AND INTERNAL EVALUATIONS
QUALITY ASSURANCE PROCESSACTIVITIES AND TASKS
3-25
1. PROCESS IMPLEMENTATION
2. PRODUCT ASSURANCE
• ESTABLISH QA PROCESS FOR THE PROJECT
• DEVELOP/DOCUMENT/ EXECUTE QA PLAN
ASSURE THAT:
• PLANS ARE DOCUMENTED/ COMPLIANT/EXECUTED
• PRODUCTS/DOCUMENTATION ARE COMPLIANT & ADHERENT
• PRODUCTS ARE DELIVERABLE/ ACCEPTABLE TO ACQUIRER
3. PROCESS ASSURANCE
ASSURE THAT:
• EMPLOYED PROCESSES ARE COMPLIANT & ADHERENT
• INTERNAL ENGINEERING PRACTICES ARE COMPLIANT
• PRIME REQUIREMENTS ARE PASSED DOWN TO SUBCONTRACTORS
• OTHER PARTIES ARE PROVIDED SUPPORT
• TRAINED STAFF AND TRAINING ARE IN PLACE
4. ASSURANCE OF QUALITY SYSTEM
• ADDITIONAL QUALITY MANAGEMENT PER ISO 9001
• COORDINATE WITH VERIFICATION, VALIDATION, JOINT REVIEW, AUDIT PROCESSES
VERIFICATION PROCESS
3-26
VERIFICATIONPLAN
PROBLEMRESOLUTION
PROCESSIMPLEMENTATION
- CONTRACT- PROCESS- REQUIREMENTS- DESIGN- CODE- INTEGRATION- DOCUMENTATION
VERIFICATION
VERIFIED
PRODUCTS
AND
SERVICES
EACH WITHOWN CRITERIA
ACTIVITIES INTERNAL USE INVOKED PROCESS OUTPUTS
• FOR VERIFICATION OF REQUIREMENTS IN AN ACTIVITY AGAINST THOSE IN PREVIOUS ACTIVITY• INTERNAL OR INDEPENDENT• USES THE TERM "VERIFY" INSTEAD OF "EVALUATE"• PRIMARILY FOR DEVELOPMENT PROCESS; - OPERATION AND MAINTENANCE NOT COVERED.
VERIFICATION PROCESSACTIVITIES AND TASKS
3-27
2. CONTRACT VERIFICATION• SUPPLIER IS CAPABLE• USER NEEDS ARE COVERED• HANDLING REQS CHANGES ADEQUATE• PARTIES' INTERFACES STIPULATED
3. PROCESS VERIFICATION• PLANNING ADEQUATE/TIMELY• PROCESSES ADEQUATE/IMPLEMENTED BEING EXECUTED/COMPLIANT• STANDARDS/PROCEDURES/ ENVIRONMENTS ADEQUATE• PERSONNEL STAFFED AND TRAINED
4. REQS. VERIFICATION• CONSISTENT/FEASIBLE/TESTABLE• ALLOCATIONS APPROPRIATE• CRITICALITY REQS. CORRECT BY RIGOROUS METHODS
• DETERMINE IF AND HOW MUCH NEEDED - USE CRITICALITY FACTORS• DETERMINE DEGREE OFINDEPENDENCE
1. PROCESS IMPLEMENTATION 5. DESIGN VERIFICATION• CORRECT/CONSISTENT\TRACEABLE• PROPER SEQUENCE/ALLOCATION OF EVENTS, I/O, INTERFACES, LOGIC, TIMING, SIZING, RECOVERY, ...• DESIGN IMPLEMENTS CRITICALITY REQS. CORRECTLY [SHOW BY RIGOROUS METHODS]
6. CODE VERIFICATION• CORRECT/TESTABLE\TRACEABLE• SIMILAR TO ABOVE
7. INTEGRATION VERIFICATION• COMPONENTS/UNITS INTEGRATED COMPLETELY/CORRECTLY• ITEMS INTEGRATED INTO SYSTEM COMPLETELY AND CORRECTLY• PERFORMED PER PLANS
8. DOC. VERIFICATION• ADEQUATE/COMPLETE/CONSISTENT• TIMELY• FOLLOWS CM
VALIDATION PROCESS
3-28
PROCESSIMPLEMENTATION
PROBLEMRESOLUTION
VALIDATIONPLAN
VALIDATION
OUTPUTSACTIVITIES
4/5 TASKS TESTING1 TASK: INTENDED USE
VALIDATEDPRODUCTS
ANDSERVICES
• FOR VALIDATION OF AS-BUILT PRODUCTS AGAINST SPECIFIED CRITERIA• INTERNAL OR INDEPENDENT• USES THE TERM "VALIDATE" INSTEAD OF "EVALUATE"• CONFIDENCE IN VALIDATION: THROUGH TESTING
INTERNAL USE INVOKED PROCESS
.
JOINT REVIEW PROCESS
3-29
PROCESSIMPLEMENTATION
PROBLEMRESOLUTION
PROJECTMANAGEMENT
REVIEWS
TECHNICAL
REVIEWS
REVIEW
RESULTS
RESULTS
• REVIEW OF PROJECT STATUS, PRODUCTS AND TASKS FOR COMPLETENESS, COMPLIANCE AND ADHERENCE
PROJECT STATUS
- BOTH TECHNICAL AND MANAGEMENT
• FOR JOINT REVIEWS BETWEEN REVIEWER AND REVIEWEE
- TYPICALLY BY SUPPLIER WITH ACQUIRER
OUTPUTSACTIVITIES
AGENDA, SCOPE,FORUM, ETC.
INTERNAL USE INVOKED PROCESS
AUDIT PROCESS
3-30
• FOR AUDITS BETWEEN AUDITOR AND AUDITEE
- TYPICALLY BY ACQUIRER WITH SUPPLIER
• FOR COMPLIANCE WITH REQUIREMENTS/PLANS/CONTRACT
PROCESSIMPLEMENTATION
PROBLEMRESOLUTION
AUDIT
RESULTSAUDIT
AGENDA, SCOPE,FORUM, ETC.
OUTPUTSACTIVITIES INTERNAL USE INVOKED PROCESS
PROBLEM RESOLUTION PROCESS
3-31
PROCESSIMPLEMENTATION
PROBLEMRESOLUTION
RESOLVEDPROBLEMS
OUTPUTSACTIVITIES INTERNAL USE INVOKED PROCESS
• FOR ANALYZING AND RESOLVING PROBLEMS, TAKING CORRECTIVE ACTIONS, AND DETECTING TRENDS - THE “A” OF THE PDCA CYCLE.
• NOTE: NOT EVERY PROBLEM NEEDS CORRECTIVE ACTION
• A CLOSED LOOP PROCESS: - PROBLEMS REPORTED/ENTERED - ACTION TAKEN - CAUSES IDENTIFIED/ELIMINATED - RESOLUTION/DISPOSITION ACHIEVED/RECORDED - TREND DETECTED
ORGANIZATIONAL PROCESSES
3-32
PRIMARY PROCESS
MANAGEMENTPROCESS
INFRASTRUCTUREPROCESS
IMPROVEMENTPROCESS
TRAININGPROCESS
1
2
3
4(SOME SUPPORTING PROCESS)
• FOR AN ORGANIZATION TO MANAGE AND IMPROVE ITS PROCESSES AT CORPORATE LEVEL
• THE ORGANIZATION IS RESPONSIBLE FOR ESTABLISHING AND INSTITUTIONALIZING THE LIFE CYCLE PROCESSES
1: MANAGE FOLLOWING MANAGEMENT PROCESS
3: IMPROVE FOLLOWING IMPROVEMENT PROCESS4: TRAIN PERSONNEL FOLLOWING TRAINING PROCESS
2: ESTABLISH INFRASTRUCTURE FOLLOWING INFRASTRUCTURE PROCESS
MANAGEMENT PROCESS
3-33
INITIATION
SCOPE DEFINITION&
PLANNING
EXECUTION&
CONTROL
REVIEW&
EVALUATION
CLOSURE
MANAGEMENTPLAN
[PROCESSREQUIREMENTS]
[REPORTS]
[REPORTS]
[PRODUCTS]
OUTPUTSACTIVITIES
[SERVICES]
INTERNAL USE INVOKED PROCESS
DECISION TABLE
• FOR GENERAL MANAGEMENT OF PROCESSES• IT IS THE PDCA CYCLE• IT IS INSTANTIATED IN OTHER PROCESSES
INFRASTRUCTURE PROCESS
3-34
PROCESSIMPLEMENTATION
MAINTENANCEOF THE
INFRASTRUCTURE
ESTABLISHMENTOF THE
INFRASTRUCTURE INFRASTRUCTURE
CONFIGURATIONOF THE
INFRASTRUCTURE
[RECORDS]
• INFRASTRUCTURE: PROCEDURES, STANDARDS, TOOLS, EQUIPMENT, SPACE
• FOR ESTABLISHING AND MAINTAINING INFRASTRUCTURE OF A LIFE CYCLE PROCESS
OUTPUTSACTIVITIES INTERNAL USE INVOKED PROCESS
TRAINING PROCESS
3-35
DEVELOPMENT
TRAINING PLANIMPLEMENTATION
PROCESSIMPLEMENTATION
TRAINING MATERIAL
TRAINING PLAN
TRAINING MANUALS
TRAINING RECORDS
[TRAINED PERSONNEL]
• FOR PROVIDING AND MAINTAINING TRAINED PERSONNEL
OUTPUTSACTIVITIES INTERNAL USE INVOKED PROCESS
IMPROVEMENT PROCESS
3-36
PROCESSASSESSMENT
[ESTABLISHEDPROCESS(ES)]
PROCESSIMPROVEMENT
PROCESSESTABLISHMENT
ASSESSMENTPROCEDURES
AND PLANS
[EVALUATION,HISTORICAL,
QUALITY COSTRECORDS]
• FOR ESTABLISHING, ASSESSING, MEASURING, CONTROLLING, AND IMPROVING A LIFE CYCLE PROCESS
OUTPUTSACTIVITIES INTERNAL USE INVOKED PROCESS
TAILORING PROCESSA SPECIAL PROCESS
3-37
DOCUMENTINGTAILORINGDECISIONS
& RATIONALE
IDENTIFYINGPROJECT
ENVIRONMENT
SOLICITINGINPUTS
SELECTINGPROCESSES,ACTIVITIES,
& TASKS
TAILORINGDECISIONS
& RATIONALE
PROJECT'S
SELECTEDPROCESSES,ACTIVITIES,
& TASKS
INPUTS FROMORGANIZATIONS
CHARACTERISTICS
OUTPUTSACTIVITIES INTERNAL USE INVOKED PROCESS
• FOR BASIC TAILORING OF THE STANDARD FOR PROJECTS - ADDITIONS IN AGREEMENT - ONLY 5 “SHALLS”
• TAILORING OF THIS PROCESS NOT ALLOWED
EVALUATION-BASED PROCESSES
3-38
PROCESS 2
SELF IMPROVEMENT
CONFORMANCE EVALUATIONS
SUPPLEMENTARY EVALUATIONS
INTERNAL EVALUATIO
NS
VERIFICATION & VALIDATION
QUALITY ASSURANCE
IMPROVEMENT
PROCESS 1
AUDIT
JOINT REVIEW
INTER-PARTYEVALUATIONS
• EVALUATION: BASIC TO ALL EVALUATION-BASED TASKS• PROCESS-INTERNAL EVALUATIONS: AGAINST SPECIFIED CRITERIA• VERIFICATION: AGAINST PREVIOUS ACTIVITIES• VALIDATION: AGAINST INTENDED USE• QA: ASSURANCE WITH RESPECT TO REQUIREMENTS/PLANS• JOINT REVIEW: EVALUATIONS OF STATUS & PRODUCTS• AUDIT: EVALUATIONS FOR COMPLIANCE WITH REQUIREMENTS/PLANS/CONTRACT
THE “C” OF THE PDCA CYCLE
REQUIREMENTS
3-39
• AN EXPECTATION/DEMAND AS A COMPLIANCE/OBLIGATION/AGREEMENT• A QUALIFIER IDENTIFIES THE SOURCE & RECEIVER; OTHERWISE IN LOCAL CONTEXT
• ACQUISITION REQS; SYSTEM REQS; SOFTWARE REQSACQUISITION
• NEW AND MODIFIED REQSMAINTENANCE
• FOR LOCAL ACTION ON INCOMING REQSOTHER
• ACQUISITION REQS• PLANNING REQS; CONTRACTUAL REQS; PRIME-CONTRACT REQSSUPPLY
DEVELOPMENT
• SYSTEM REQS & SPECS - ORGANIZATIONAL, USER, SAFETY, INTERFACE, QUALIFICATION, ...
• SYSTEM REQS ALLOCATED TO ITEMS: HARDWARE, SOFTWARE, MANUAL OPERATIONS
• SOFTWARE REQS FOR: ITEMS; COMPONENTS; UNITS
• TEST REQS
PROCESS TERM "REQUIREMENTS" and QUALIFIER USED
CRITICAL FUNCTIONS
3-40
ACQUISITION • INCLUDE RELATED DESIGN/TESTING/COMPLIANCE STANDARDS/PROCEDURES.
• DEFINE SAFETY/SECURITY/CRITICALITY REQUIREMENTS.
• ANALYZE IMPACT OF MODIFICATIONS ON: SAFETY/SECURITY/CRITICALITY FUNCTIONS.MAINTENANCE
• PRODUCE/STORE DOCUMENTS PER SECURITY POLICIES.DOCUMENTATION
C. M. PROCESS
• DETERMINE VERIFICATION EFFORT PER CRITICALITY REQMNTS.• VERIFY BY RIGOROUS METHODS SAFETY/SECURITY/CRITICALITY FUNCTIONS ARE ANALYZED/DESIGNED/CODED CORRECTLY.
VERIFICATION
SUPPLY• ADDRESS IN PROJECT PLANS, MANAGEMENT OF: - SAFETY/SECURITY/CRITICALITY REQUIREMENTS - RELATED POLICY/REGULATION/CERTIFICATION• SEPARATE PLANS ENCOURAGED.
DEVELOPMENT• ADDRESS PLANNING, ANALYSIS, DESIGN, AND QUALIFICATION OF SAFETY, SECURITY, AND CRITICALITY REQUIREMENTS, INCLUDING ERGONOMIC.
12207 MAY INVOKE OR MAY BE EXPANDED FOR SAFETY, SECURITY, CRITICAL STANDARDS
• CONTROL/AUDIT ACCESS TO SOFTWARE PROCESSING SAFETY/SECURITY CRITICAL FUNCTIONS.
PROCESS CRITICAL-FUNCTION RELATED TASKS
TESTING
3-41
ACQUISITION
OPERATION
MAINTENANCE
VALIDATION
SUPPLY
DEVELOPMENT
• DEFINE ACCEPTANCE STRATEGY & CRITERIA. • PREPARE TESTS AND TEST ENVIRONMENT FOR ACCEPTANCE.• IDENTIFY TEST STANDARDS & PROCEDURES FOR CRITICAL REQS.• CONDUCT VALIDATION & ACCEPTANCE TESTING.
• DEFINE OPERATIONAL TESTS.• TEST IN OPERATIONAL ENVIRONMENT.• CONDUCT OPERATIONAL TESTING FOR EACH RELEASE.
• WHEN MODIFICATION, DO DEVELOPMENTAL TESTING.• TEST MODIFIED AND UNMODIFIED PARTS.• DO MIGRATION TESTING.
• DEFINE AND CONDUCT VALIDATION TESTS.• INCLUDE STRESS TESTING.
• PLAN TEST ENVIRONMENT.• INTERFACE WITH IVV&T AGENT.• SUPPORT ACCEPTANCE & VALIDATION TESTING.
• DEFINE TESTS; PLAN AND DO TESTING: - UNITS, DATABASES, AGGREGATES - INTERNAL, INTEGRATION, QUALIFICATION, CONFORMANCE, INSTALLATION - INCLUDE STRESS TESTS AND TESTING
• SUPPORT ACCEPTANCE TESTING.• EVALUATE FOR TESTABILITY, TEST COVERAGE, TEST FEASIBILITY.
PROCESS TESTING RELATED TASKS
• TESTING SHARED AMONG THE PARTIES
3-42
SCOPE• 12207 IS NOT INTENDED FOR OTSS,
UNLESS INCORPORATED INTO DELIVERABLES
ACQUISITION
• CONSIDER OTSS AS AN OPTION IN ACQUISITION OR PARTS OF ACQUISITION • ENSURE THE FOLLOWING IF ACQUIRING OTSS: - REQUIREMENTS ARE SATISFIED - DOCUMENTATION AVAILABLE - RIGHTS ARE SATISFIED - FUTURE SUPPORT PLANNED
SUPPLY • CONSIDER OTSS IN DEVELOPMENT
DEVELOPMENT• CONSIDER OTSS IN DEVELOPMENT [VIA SUPPLY PROCESS].• NDI MAY BE USED IN DEVELOPMENT, - ENSURE OPERATION & MAINTENANCE INDEPENDENT OF NDI - OTHERWISE NDI SHOULD BECOME DELIVERABLE
PROCESS OTSS & NDI RELATED TASKS
OFF-THE-SHELF SOFTWARE (OTSS)&
NON-DELIVERABLE ITEMS (NDI)
3-43
ACQUISITION
SUPPLY
METRIC/INDICATOR NEEDED
• PROCESS MONITORING - Cost, Schedule, Technical
• PROCESS MONITORING - Cost, Schedule, Technical
• SUPPLIER SELECTION - Capability, Past performance, ...
• PROPOSAL EVALUATION - Technical, Cost, Schedule, Personnel, ...
• AGREEMENT CHANGES - No., Rate, Impact, ...
• PROBLEM STATUS - By Activity/Task/Source, Trend, ...
• JOINT ACTION ITEMS STATUS
• JOINT ACTION ITEMS STATUS
• BID DECISION
• ACCEPTANCE PROGRESS - Acceptance criteria, Conformance, Releasability, ...
• ACCEPTANCE PROGRESS - Acceptance criteria, Conformance, Releasability, ...
METRICS & INDICATORS - I
PROCESS
• 12207 NEEDS THESE, BUT DOES NOT DEFINE OR PRESCRIBE THEM
3-44
DEVELOPMENT
• JOINT ACTION ITEMS STATUS
• CHANGE STATUS: By Activity/Task, Source, Trend, ...
• PROBLEM STATUS: BY Activity/Task, Source, Trend, ...
• TRACEABILITY: - System Requirements to Acquisition Needs - System Architectural Design to System Requirements - Software Requirements to System Requirements & Design - Soft ware Architectural Design to Software Requirements - Software Detailed Design to Software Requirements - Software Unit to Software Requirements & Design - Software Design & Unit to System Requirements
• REQUIREMENTS TESTABILITY STATUS
• TEST COVERAGE
• CONSISTENCY: INTERNAL & EXTERNAL
• CONFORMANCE TO EXPECTED RESULTS
• FEASIBILITY OF OPERATIONS
• FEASIBILITY OF MAINTENANCE
• FEASIBILITY OF NEXT ACTIVITY
• QUALITY CHARACTERISTICS [ISO/IEC 9126] - Functionality, Reliability, Usability, Efficiency, Maintainability, Portability - Plus their sub-characteristics
METRIC/INDICATOR NEEDED
METRICS & INDICATORS - II
PROCESS
• 12207 NEEDS THESE, BUT DOES NOT DEFINE OR PRESCRIBE THEM
3-45
OPERATION • OPERATIONAL CHARACTERISTICS - Run time, Throughput, Availability, Responsiveness, ...
• OPERATIONAL TESTING - Coverage, Releasability, ...
• USER SUPPORT - Status of requests, support, releases, ...
MAINTENANCE • STATUS: PROBLEM REPORTS & MODIFICATION REQUESTS - Measure of classification, size, criticality, closure, ... - Impact on operations & maintenance
• TEST COVERAGE OF - Modified parts - Unmodified parts
• MIGRATION PORTABILITY
• USER SUPPORT DURING MIGRATION
• POST-OPERATION IMPACT OF MIGRATION
• USER SUPPORT DURING RETIREMENT
• IMPACT ON UNMODIFIED PARTS
METRIC/INDICATOR NEEDED
METRICS & INDICATORS - III
PROCESS
• 12207 NEEDS THESE, BUT DOES NOT DEFINE OR PRESCRIBE THEM
PROCESSES and INTERACTIONS
3-46
FM
INFRASTRUCTURE TRAINING IMPROVEMENTMANAGEMENT
ORGANIZATION
MAINTENANCE
DEVELOPMENT
OPERATION
E: 2, 3
E: 1, 2, 3
E: 3
QAE: 3
SUPPLYU: 4T
ACQUISITIONU: 4 E
FFFF
V&VE: 3
PROJECT
E
AUDIT
P
E
(T)EE: 3
E: 3
JOINTREVIEW
E: 3
(I)V&V
O1 O2
T
U
U
PDCA
CM
2PROBLEM
RESOLUTION
3DOCUMENTATION
1TAILORING
4E
E
E
E
P
T
E - EXECUTE. F - FEEDBACK. M - MANAGE. P - PARTICIPATE. T - TASK. U - USE.O1: START HERE. O1, O2 - THE SAME POINTS. ACQ - ACQUISITION. SUB - SUBCONTRACTOR.
E:N - EXECUTE THE PROCESS N. U:N - USE THE PROCESS N.
E: ACQT: SUB
TOPICS1. BACKGROUND
2. BASIC CONCEPTS
3. THE PROCESSES
4. APPLICATION - Business practices under debate - How to use 12207 in an organization and on a project - Pertinent advice and notes Note: No rules; only salient guidelines -- this presenter’s Note: In charts, start at if shown
5. RELATED AREAS
6. SUMMARY
7. FOR YOUR INFORMATION
4-0
BUSINESS PRACTICES UNDER DEBATE
4-1
INPUT
MARKET
PUBLIC
ACQUIRER
DEVELOPPERFORMANCE
SPECIFICATIONSFOR THE
PRODUCT/SERVICE
DEVELOP SOW;INCLUDE:
PERFORMANCESPECIFICATIONS& THE VERIFIEDENVIRONMENT
DECLARE/DEMONSTRATE/
CERTIFYESTABLISHEDENVIRONMENT
VERIFY SUPPLIER’SPERFORMANCE HISTORY
ANDESTABLISHEDENVIRONMENT
USETHE ENVIRONMENT
TO PROVIDETHE PRODUCT / SERVICE
DEVELOP SOW;INCLUDE:
PERFORMANCESPECIFICATIONS &12207 AND OTHER
TASKS
INPUT
+ TO BE DISCUSSED AT THE NEXT CHART
SUPPLIER (VENDOR)
+ +ONE OR BOTH
ESTABLISHAN ENVIRONMENT WITHMETHODS, TECHNIQUESAND TOOLS FOR 12207
AND OTHER STANDARDSAND FOR THE PRODUCT
AND SERVICE LINE
+ USING ENVIRONMENT OR STANDARD ...[From the previous chart]
4-2
• A total environment or the standard is general, complex, and large- Outside of a project/service context, it would appear abstract- Using all of it would be neither cost-effective nor feasible.
• Therefore, the environment or the standard should be tailoredfor the specific product/service. That is,- Selecting the activities, tasks, inputs, and outputs- Selecting methods, techniques, and tools for the above
• The following charts will discuss the factors [determinants] thatshould be helpful in:- Selecting the activities and tasks for the product or service- Selecting methods, techniques, and tools for the above is left to down-the-road decision.
• 12207 will be used as a backdrop for selecting [tailoring]processes, activities, tasks, and outputs.
GETTING STARTED
4-3
2
PRODUCT MODESERVICE MODE
3
Y
NARE YOU THEACQUIRER?
NEGOTIATE/SIGNCONTRACT WITH
THE PARTIES
PERFORM THEACTIVITIES & TASKSRESPONSIBLE FOR
COMPLETE/DELIVER THEPRODUCT OR
SERVICE
CLARIFY TASKSTHAT
REFERENCETHE CONTRACT
• THE SHADED BOXES WILL BE EXPLAINED IN THE ORDER THEY ARE NUMBERED.
1
MANAGINGPROCESSES
PROVIDINGPRODUCTS &
SERVICES
IDENTIFY YOURPRIMARY ROLE(s):
NOTE USAGE:- ONE PERSON (SOLO)- WITHIN ORGANIZATION- AMONG ORGANIZATIONS
ORGANIZATIONAL MODEMANAGE THE PROCESSES
- INSTITUTIONALIZEDENVIRONMENT
IMPROVE THE PROCESSES
DETERMINE WHICH 12207 PROCESSES
TO EMPLOY
SELECT ACTIVITIES & TASKSFROM THOSE PROCESSES
DETERMINEWHICH OTHER PROCESSES
TO EMPLOY
DEVELOP MODELS BASED ON THE
PROCESSES, ACTIVITIES, AND TASKS
TUNE, TAILORTHE INSTITUTIONALIZED
ENVIRONMENT
APPLICATION STEPS AND FACTORS[The shaded boxes 1, 2, 3 in Getting Started]
1. PRIMARY ROLES: Determine and identify
2. IN ORGANIZATIONAL MODE: 2.1 Process Management: Establish the processes (and resources) 2.2 Process Improvement: Improve the processes
3. IN PROJECT MODE: 3.1 Application Concepts: Familiarize and understand 3.2 Policies: Determine and identify applicables 3.3 Project Characteristics: Determine and identify 3.4 System Context: Select, determine, construct 3.5 Life cycle Models: Determine and identify
3.6 Specialty Areas Identify and supplement 3.7 Types of Software: Determine and identify outputs 3.8 Documentation: Determine and identify 3.9 Evaluation Categories: Determine and identify
4-4
• THE STEPS AND FACTORS ARE EXPLAINED NEXT AS OUTLINED ABOVE.
1. PRIMARY ROLES DETERMINE AND IDENTIFY
4-5
• Management • Improvement • Training• Infrastructure
ORGANIZATIONAL PROCESSES
ACQUISITION PROCESS
PROCESSDEVELOPMENT
PROCESS
SUPPLY PROCESS
OPERATION PROCESS
employemploy
use
contract
employ
use
MAINTENANCE
employ
employ
employ
employ
EMPLOYER
SUPPORTINGPROCESSES
OFSUPPORTINGROLE
MANAGERORGANIZATIONAL
ROLE
• OPERATOR • USER
OPERATINGROLE
ACQUIRERACQUISITION
ROLE
SUPPLIERSUPPLY
ROLE
• DEVELOPER• MAINTAINER
ENGINEERINGROLE
ROLE?
PR
ES
S
OC
SE
SUPPORTING
• Documentation • Validation
• Problem resolution• Verification
• Configuration management • Joint review• Quality assurance • Audit
2.1 PROCESS MANAGEMENT ESTABLISH THE PROCESSES
4-6
N
MANAGE THE12207 PROCESS
Y
MANAGE APROCESS?
IS THEPROCESSDEFINEDIN 12207?
THIS PROCESS IS DEFINEDIN 12207 AND SHOULD BE
AN INSTANTIATION OF THE MANAGEMENT PROCESS
EXECUTETRAINING PROCESSFOR PERSONNEL;
TAILORING PROCESSFOR PROJECTS
EXECUTEMANAGEMENT PROCESS
CUSTOMIZE/ SPECIALIZE/INSTANTIATETHE PROCESS
EXECUTEINFRASTRUCTURE
PROCESS
ESTABLISH/ INSTITUTIONALIZETHE PROCESS
AS AN ENVIRONMENT
EXECUTEIMPROVEMENT PROCESS
SEE THE NEXT CHART
2.2 PROCESS IMPROVEMENT IMPROVE THE PROCESSES
4-7
PROCESS
[Procedures ...]IMPROVEMENT
PROCESSASSESSMENT[Procedures ...]
PROJECT 1COMMENTS
PROCESSBASELINES
TASKS
PROCESSDEFINITIONS
PROCESSESISO/IEC 12207
DATAIMPROVEMENT
- Process improvement- Project's direction- Technology advancement- Organizational improvement
- Effectiveness- Suitability- Capability- Cost of quality
ASSESSMENTDATA
EXPERIENCEDATA BASE
- Historical- Technical- Evaluation- Quality cost data
PROJECT n
PROCESSESTABLISHMENT
[Environment, control ...]
3.1 APPLICATION CONCEPTS FAMILIARIZE AND UNDERSTAND
• DUAL USE OF 12207:- To develop, operate, and maintain application products- To use to analyze, model, or study a system - Whether or not the system would contain software.
• LIFE CYCLE MODEL:- To organize and manage the steps/phases of a life cycle in the desired order(s)- Incorporates developmental, operational, maintenance, ... models
• PROTOTYPING IN 12207:- Not listed as an activity of the Development or Maintenance- Treated as a method/technique for: - Performing studies, requirements analysis, design, etc. - Developing prototypes and mock-ups
• BUILD:- An instance of a product that meets a specified subset of the total requirements. - A build may be a prototype- A period of time during which the build is developed.
• Iteration: Iteration across activities.Recursion: "Iteration" across tasks in an activity.Note: Not every activity (task) needs to be executed in every iteration (recursion).
4-8
3.2 POLICIESDETERMINE AND IDENTIFY APPLICABLES
• CHECK POLICIES & STANDARDS AFFECTING TAILORING:- Contract type(s): Fixed price; cost plus fee; etc.- Operations and support strategies- Documentation/data/interface standards- Safety, security, risk management- Programming language(s)- Reserve requirements- Measurement/metrics- Reuse- Proprietary, usage, warranty, escrow rights- Use of IV&V agents- ...
• CHECK LAWS ON PUBLIC SAFETY, SECURITY, ENVIRONMENT, ...- Consider, interpret, and incorpoarte clauses related to the above items
• ADD CLAUSES IN AGREEMENT, IF NOT FOUND IN 12207
4-9
3.3 PROJECT CHARACTERISTICS DETERMINE AND IDENTIFY
• SIZE: of software product, of software service, number of personnel
• CRITICALITY:- Impact of a defect/malfunction on business/mission- Liability due to failure- Immaturity or unprecedentedness of technology employed- Growth/changes in technology- Unprecedentedness of products under consideration- Unavailability of needed resources/schedule
• LIFE: Duration and extent of use and maintenance
• AS SIZE OR CRITICALITY INCREASES, SO DOES:- Extent of 12207's engineering tasks - Caution: Don't delete an engineering task unless sure- Extent of technical insight: [I]V&V- Extent of management visibility: Joint Review, Audit, QA
• AS OBJECTIVITY BECOMES MORE IMPORTANT, SO DOES: - Degree of independence of V&V Processes - Degree of organizational freedom for QA Process - Degree of independence in peer evaluations
• AS LIFE OR EXPECTED CHANGE INCREASES, SO DOES:- Extent of documentation- Caution: Consult with operators, users, and maintainers
• NOTE: Even for lesser size or criticality, independent or peer evaluations are beneficial4-10
3.4 SYSTEM CONTEXT DETERMINE AND IDENTIFY
• A system is moved from cradle to grave through steps/phases
. . .STEP/PHASE 1
STEP/PHASE 2
STEP/PHASE N
4-11
• Software is one of many components in the system
SYSTEMHARDWARE
COMPUTERSOFTWARE
HUMANS
MATERIAL
• A project puts the steps/phases together: - In the sequence - In the recursions - In the iterations - To the desired extend
. . .STEP/PHASE 1
STEP/PHASE 2
STEP/PHASE N
RECURSION
ITERATION
• Software follows the system in each step/phase
. . .
STEP/PHASE 1
STEP/PHASE 2
STEP/PHASE N
SYSSW
SYSSW
SYSSW
[GENERIC; STATIC VIEW]
OPERATIONS
DEVELOPMENT
DEMONSTRATION
NEEDS DETERMINATION
CONCEPT DEFINITION
PRODUCTIONS;MANUFACTURING
DEPLOYMENT;SALES
MAINTENANCE & SUPPORT
RETIREMENT
MAINTAIN/SUPPORT PRODUCTS
OPERATE; USE PRODUCTS
DEPLOY AT SITES; SELL
PRODUCE; MANUFACTURE
DEFINE/DETERMINE NEEDS
DEFINE CONCEPTS & SOLUTIONS
DEMONSTRATE FEASIBILITY OFIMPLEMENTING SOLUTIONS
DEVELOP PRODUCiBLE PRODUCTS
RETIRE PRODUCTS
3.4.1 SYSTEM LIFE CYCLE
4-12
3.4.2 VIEWS OF LIFE CYCLE
4-13NOT TO SCALE
ND: NEEDS DETERMINATIONCD: CONCEPT DEFINITIONDem: DEMONSTRATIONDev: DEVELOPMENT
Prod: PRODUCTIONSD/S: DEPLOYMENT/SALESOpn: OPERATIONSM,S&R: MAINTENANCE, SUPPORT & RETIREMENT
SUPPORTING
MAINTENANCE
ND CE Dem Dev Prod D/S Opn M,S&R
SYSTEM’s LIFE CYCLE
PARTY
SUPPLY
OPERATION
ACQUISITION
PARTY LIFE CYCLE
DEVELOPMENT
3.4.3 LIFE CYCLE DYNAMICS [MODELS]
PRIMARY PROCESSES
SUPPORTING PROCESSES
ORGANIZATIONAL PROCESSES
M,S&RPRIMARY PROCESSES
SUPPORTING PROCESSES
ORGANIZATIONAL PROCESSES
. . .PRIMARY PROCESSES
SUPPORTING PROCESSES
ORGANIZATIONAL PROCESSES
DevPRIMARY PROCESSES
SUPPORTING PROCESSES
ORGANIZATIONAL PROCESSES
CEPRIMARY PROCESSES
SUPPORTING PROCESSES
ORGANIZATIONAL PROCESSES
ND
ACQUISITION
SUPPLY
4-14
LC DECISION FACTORS:- FUNDING & RESOURCES- SCHEDULE- FEASIBILITY- TECHNOLOGY- MARKET NEED
LC DECISION POINTS:- DO A NEXT PHASE- HOLD PROJECT- TERMINATE PROJECT- CONTINUE CURRENT PHASE- GO BACK TO A PREVIOUS PHASE
3.4.4 SYSTEM & SOFTWARE BUILDS
4-15
SYB 3
SWB 7
SYB 1
SWB 2 SWB 3 SWB 4SWB 1
SYB 2
SYB = SYSTEM BUILDSWB = SOFTWARE BUILD
SWB 5
SWB 6
• Use [Acquisition, Supply &] Development Process to install and check-out products.
• Use [Acquisition, Supply &] Operation Process to provide operation services.
• Use Development Process [fully] to build, test, and
integrate the product
• Use Acquisition & Supply Processes to trigger Development
Process.
DEVELOPMENT
• As no manufacturing is done for software, 12207 is of little use.
PRODUCTIONS;MANUFACTURING
OPERATIONS
• Use [Acquisition, Supply &] Maintenance
for maintenance, support,and retirement.
MAINTENANCE;SUPPORT;
RETIREMENT
DEPLOYMENT/SALES
CONCEPTDEFINITION
• Use [Acquisition, Supply &] Development Process to define draft system requirements, develop
prototypes, and analyze user feedback to get proposed solutions.
DEMONSTRATION
• Use[Acquisition, Supply &]Development Process
to define systemrequirements, system
architecture, draftsoftware requirements
for software items.
• Use Acquisition Process to decide
technical/operational/ economical feasibility.
NEEDSDETERMINATION
3.4.5 12207 IN SYSTEM LIFE CYCLE
4-16
3.5 LIFE CYCLE MODELS SELECT, DETERMINE, CONSTRUCT
4-17
• LIFE CYCLE MODELING IS A TOOL TO ORGANIZE/MANAGETHE STEPS/PHASES IN THE DESIRED ORDER
• A STEP/PHASE MAY HAVE ITS OWN MODELING - Examples: Development, Operation, Maintenance, ...
LIFE CYCLEMODEL
STEP/PHASE 2MODEL
. . .STEP/PHASE 1
STEP/PHASE 2
STEP/PHASE N
• ONLY [GENERIC] DEVELOPMENT MODELS WILL BE DISCUSSED NEXT.
LOWERMODEL
• GENERIC OPERATIONS OR MAINTENANCE MODELS ARE NOT KNOWN.
3.5.1 BASIC DEVELOPMENT MODELS
4-18
NOYESWATERFALL NO
YESYESNOEVOLUTIONARY
MAYBEYESYESINCREMENTAL
BUILD N = BUILD 1
BUILD N = BUILD (N-1)+ REFINED SPECS.
• THE BASIC MODELS MAY BE COMBINED TO CREATE A HYBRID MODEL
BUILD N = BUILD (N-1)+ MORE CAPABILITIES
• ITERATIONS AND RECURSIONS ARE PRESUMED
USEINTERIM
PRODUCTS?
MULTIPLEBUILDS?
REMARKS
ALLREQS.
DEFINEDFIRST?
MODELBASIC
3.5.2 BASIC DEVELOPMENT MODELS OPPORTUNITIES AND RISKS
4-19
FACTORS OPPORTUNITY RISK
1. Requirements not well clear
2. System too large to do once
3. Full capability needed at once
4. Part capability needed early
5. Phase out of old system to be gradual
6. Rapid changes in requirements anticipated
7. Rapid changes in technologies anticipated
8. Long-run staff/funds commitment doubtful
E
I, E
W
I, E
I, E
E
E
W
W, I
W
I, E
W
W
W, I
W, I
I, E
NOTE: A PROJECT MAY USE MORE THAN ONE MODEL.W= WATERFALL; I= INCREMENTAL; E= EVOLUTIONARY
3.5.3 DEVELOPMENT MODEL: WATERFALL
4-20
ITEMSHARDWARE
SYSTEMINTEGRATION
SYSTEMQUALIF.TESTING
SOFTWAREREQ.ANALYSIS
SOFTWAREARCH.DESIGN
SOFTWAREDETAILEDDESIGN
SOFTWARECODING &TESTING
SOFTWAREINTEGRATION
SOFTWAREQUALIF.TESTING
SYSTEMREQ.ANALYSIS
SYSTEMARCH.DESIGN
SI 1
SOFTWAREITEM nSI n
SOFTWAREINSTALLATION
SOFTWAREACCEPTANCESUPPORT
•••
HIs
3.5.4 DEVELOPMENT MODEL: INCREMENTAL
4-21
R: REQUIREMENTS C/T: CODING & TESTING
D: DESIGN I/AS: INSTALLATION & ACCEPTANCE SUPPORT
FEEDBACK
I/AS
BUILD 2
BUILD n
BUILD 1
R C/TD I/AS
D C/T
D C/T I/AS
3.5.5 DEVELOPMENT MODEL: EVOLUTIONARY
4-22
BUILD n
D C/TR n
I/AS
BUILD 2
D C/TR 2
R 1 I/AS
BUILD 1
D C/T
REFINEMENTS
R: REQUIREMENTS C/T: CODING & TESTING
D: DESIGN I/AS: INSTALLATION & ACCEPTANCE SUPPORT
I/AS
3.5.6 DEVELOPMENT MODEL: SPIRAL
4-23
13
4
A
A
A
A
2REQUIREMENTS
DEFINITION/ANALYSISARCHITECTURE/
DESIGN
CODING/TESTING
INTEGRATION/TESTING/
QUALIFICATION
• A: FEASIBILITY STUDY, PROTOTYPING, RISK ANALYSIS• THIS MODEL ADOPTED FROM BOEHM's• THE SECTORS MAY BE ALLOCATED TO THE 13 ACTIVITIES AS APPROPRIATE• THIS MODEL IS REDUCIBLE TO THE BASIC MODELS• MAY BE USED AS A HYBRID INCREMENTAL-EVOLUTIONARY MODEL
3.5.7 DEVELOPMENT MODEL: RE-ENGINEERING
4-24
REVERSE ENGINEERING FORWARD ENGINEERING
SYSTEMREQ.ANALYSIS
SOFTWAREDESIGN
SYSTEMDESIGN
SOFTWAREREQ.ANALYSIS
SOFTWAREDESIGN
SOFTWAREIMPLEMENT.
SOFTWAREQUALIF.TESTING
SOFTWAREREQ.ANALYSIS
SOFTWAREDESIGN
SOFTWAREIMPLEMENT.
SOFTWAREQUALIF.TESTING
SOFTWAREREQ.ANALYSIS
SOFTWAREDESIGN
SOFTWAREIMPLEMENT.
SOFTWAREQUALIF.TESTING
SYSTEMINTEGRN.
SYSTEMQUALIF.TESTING
SOFTWAREINSTALLATION
SOFTWAREACCEPTANCE
SUPPORT
SI 1
SI 2
SI 3
Determinereqs. forreeng'dsystem
Analyzeexistingproducts;derivedesign;derivereqs.
Designreeng'dsystem
TRANSLATE TO Ada (SI 1),RE-DESIGN TO OOD (SI 2),
RETARGET TO NEW COMPUTER (SI 3).
GOAL (EXAMPLE):
SOFTWAREREQ.ANALYSIS
3.6 SPECIALTY AREASIDENTIFY & SUPPLEMENT
• SPECIALTY-AREA STANDARDS SHOULD BE USED WITH 12207 - Examples of specialty standards: safety, security, ergonomics, documentation, ... - Correlate terminology and concepts - Examples: coding v. implementation; architecture v. top-level design; ... - Determine supplementary tasks from the specialty standards for each 12207 process - Example: formal methods for design and verification, ... - Add the supplementary tasks to the 12207 tasks in respective clauses
4-25
• EXAMPLE: SAFETY IN THE DEVELOPMENT PROCESS OF 12207
TASK IN 12207 SUPPLEMENTARY TASKSFROM A SAFETY SPECIALTY STANDARD
Develop system architecture, ...
Develop software architecture, ...
Test units and aggregates, ...
Develop code, ...
Document software requirements
• Isolate safety specifications in separate configuration items.
• Use structured design.• Isolate safety specifications in separate components/modules.• Use information hiding.• Derive design mathematically.• Derive code by mathematically. • Use N-version coding resulting in voting modules.
• Exercise structural coverage [of branches and paths].
• Document ... in Software Requirements Specification (SRS).
3.7 TYPES OF SOFTWAREDETERMINE AND IDENTIFY
• DIFFERENT TYPES OF SOFTWARE NEED DIFFERENT TREATMENT
• A PROJECT MAY HAVE MORE THAN ONE TYPE OF SOFTWARE
4-26
CLASSIFICATION SCHEME - I CLASSIFICATION SCHEME - II
APPLICATION:To monitor and control system functions - ATC, fire control, ...
SUPPORT:To support users - Word processors, graphics, test generator, ...
SYSTEM:To support computer operations - OS, Compiler, ...
NEW DEVELOPMENT
EMBEDDED
INTEGRALConnected within/to a system
STAND-ALONESelf-contained (viz., payroll)
OFF-THE-SHELFExists but not developed under the current project
NON-DELIVERABLEEmployed in the development/maintenance
• NO DIFFERENCES IN APPLICATIONS OF 12207 FOR CLASSIFICATION-I
• APPLICATION OF 12207 FOR CLASSIFICATION-II TO FOLLOW NEXT
3.7.1 TYPES OF SOFTWAREOFF-THE-SHELF SOFTWARE
• OFF-THE-SHELF SOFTWARE (OTSS):- Software that is available from a source, but was not developed under the current application.- Source: In-house, another part of the organization, another organization, acquirer, market, …
• HELPFUL POINTS:- Consider the OTSS as a new software for the current application.- OTSS may or may not save costs.- OTSS may enhance or compromise design and performance.- Decide which activity the OTSS needs to enter.- Ensure the following, as applicable: - The OTSS satisfies its requirements & specifications - The documentation is available - Rights, warranty, licensing, and escrow are addressed - Future support for the OTSS is available.
4-27
3.7.2 TYPES OF SOFTWARENOTES ON REUSABILITY & PORTABILITY
• REUSABILITY: Extent of use in another application
• PORTABILITY: Extent of use in another computer system
• REUSABILITY & PORTABILITY:- Quality characteristics- Specified and designed- May have inherent conflict with other quality characteristics- Universal programming language ideal
• A PROGRAM FROM ONE COMPUTER SYSTEM RARELYRUNS FIRST TIME ON ANOTHER COMPUTER SYSTEM.- Few compilers adhere to standards exactly (have extra, improved features)- Word length varies from machine to machine - The largest integer varies. Different rounding off of numbers- Smallest positive floating point number depends on the machine - Drastic effect on "iterations until x < e"- 1's complement machine may give different results from 2's complement machine- Instruction length depends on OS- The program may not fit in the machine's memory; ...
4-29“Never ever quite the same; nor ever quite another.”
3.7.3 TYPES OF SOFTWARE NON-DELIVERABLE ITEMS
• NON-DELIVERABLE ITEM (NDI):- A hardware or a software item that is not provided with
the current application software, but is employed in its development or maintenance
- Source: In-house, another part of the organization, another organization, acquirer, market
• HELPFUL POINTS: - For the suppliers: Approve and control all NDIs. - For the acquirers: - Decide whether the future operation or maintenance of the application software will depend on the NDI - Decide whether to "acquire" the NDI - Address rights, warranty, license, and escrow.
4-28
3.7.4 TYPES OF SOFTWARE ENTRY POINTS, etc.
4-30
NEW DEVELOPMENT
NON-DELIVERABLE ITEM
SOFTWARE OR FIRMWAREEMBEDDED IN OR INTEGRALTO A SYSTEM
INCORPORATING OFF-THE-SHELFWITHOUT MODIFICATIONS
STAND-ALONE SOFTWARE
EMPLOYING OFF-THE-SHELF AS IS
ADAPTING/MODIFYINGOFF-THE-SHELF
• Consider all activities.
• Full Development Process may be excessive.• Evaluate documentation and data rights needs.
• Determine support life and documentation needs.
• System activities may be excessive.
• Decide if developer performs or supports system activities.
• Determine support life and documentation needs.
• Evaluate documentation and data rights needs.
• Documentation may be unavailable/inadequate.
SYS. REQ. ANALYSIS
SW QUAL. TESTING
SW REQ. ANALYSIS
SW UNIT TESTING
CLAUSE 5.3.1.5
SW DESIGN
ENTRY POINTTYPE REMARKS
• Based on performance record
• As in above
SYS. ARCH. DESIGN
• ENTRY POINT (SUGGESTED) REFERS TO DEVELOPMENT PROCESS ACTIVITY - A PRIOR ENTRY POINT POSSIBLE• TYPES TYPICALLY DETERMINED DURING REQUIREMENTS ANALYSIS AND DESIGN
• Beware of impact on the operations and maintenance.
3.8 DOCUMENTATIONDETERMINE AND IDENTIFY OUTPUTS
• REASONS FOR DOCUMENTATION (in 12207):- Use in or across the same activity or process - Examples: Development plan; design; - Examples: Acquisition requirements; User manuals- Use in other projects - Examples: From development to maintenance; Reuse- Delivery to the acquirer - Examples: Operations manual; code
• DETERMINE PRODUCTS/DOCUMENTATION:- Which ones? -- Specifications; Design; ...- See the next chart for 12207's output categories- Format, Content, Media, ... ?- Use the Documentation Process of 12207
• HELPFUL POINTS:- Existing product standards usable with 12207 - Correlate 12207 outputs with your product standards- Involve affected persons: especially users, operators, maintainers- Life cycle cost more critical than development cost - Over 70% of life cycle cost in maintenance
4-31
3.8.1 OUTPUT CATEGORIES
4-32
PLAN
ACQUISITION, PROJECT MANAGEMENT, DEVELOPMENT, TEST, INTEGRATION, INSTALLATION, OPERATION, MAINTENANCE, MIGRATION, RETIREMENT, CM, QA, VERIFICATION, VALIDATION, MANAGEMENT, INFRASTRUCTURE, TRAINING
REQUIREMENTS &SPECIFICATIONS
SYSTEM, HARDWARE, SOFTWARE, MANUAL OPERATIONS, TEST, SYSTEM QUALIFICATION, SOFTWARE QUALIFICATION
DESIGN SYSTEM ARCHITECTURAL, SOFTWARE ARCHITECTURAL, SOFTWARE DETAILED, INTERFACE, DATA BASE
SOFTWARE CODE& DATABASE SOFTWARE UNIT, DATABASE
TESTTEST REQUIREMENTS & TEST RESULTS FOR UNITS, DATA BASE, SYSTEM/SOFTWARE QUALIFICATION, ACCEPTANCE, MAINTENANCE
MANUAL (USER'S) FOR OPERATIONS AND MAINTENANCE
EVALUATIONRESULT/REPORT
INTERNAL, QA, V&V, JOINT REVIEW, AUDIT, CM, PROBLEM RESOLUTION
SPECIAL TAILORING DECISIONS
OUTPUT CATEGORY 12207 OUTPUTS
OUTPUTS IN A CATEGORY MAY BE COMBINED INTO ONE OR MORE SETSEXAMPLE: DEVELOPMENT PLAN INCLUDES TEST, INTEGRATION, INSTALLATION AND CM
3.9 EVALUATION CATEGORIESDETERMINE AND IDENTIFY
4-33
EVALUATION OBJECTIVE
PROCESS INTERNAL EXTENT TO WHICH MEETS SPECIFIED CRITERIA
VERIFICATION
JOINT REVIEW
VALIDATION
QUALITY ASSURANCE
AUDIT
IMPROVEMENT SELF-IMPROVEMENT OF PROCESS(es)
- External- Organizational freedom and authority
ASSURE PRODUCTS & PROCESSES CONFORMTO REQUIREMENTS AND ADHERE TO PLANS
VERIFY PRODUCTS IN AN ACTIVITY AGAINSTPREVIOUS ACTIVITIES [DOING IT RIGHT]- Depth depends on criticality- Independence depends on objectivity
REVIEW OF STATUS & PRODUCTS- Inter-party [Typically acquirer-supplier]
VALIDATE AS-BUILT PRODUCTS FOR SPECIFICINTENDED USE [DONE IT RIGHT]- Depth depends on criticality- Independence depends on objectivity
COMPLIANCE WITH REQUIREMENTS, PLANS AND CONTRACT- By authorized persons [acquirer or representative]
APPLICATION -- RECAP
• WE DISCUSSED: - Role determination in a life cycle - Factors and determinants for selecting (and supplementing) processes, activities, and tasks - At project level - At organizational level.
• SUITABLE FOR EITHER BUSINESS PRACTICE OPTION: - Direct use of 12207 (including with specialty standards) - Use of an established environment (with 12207 as backdrop)
• HOPEFULLY, ACCOMMODATES DIVERSE PROJECTS, ORGANIZATIONS, AND COUNTRIES.
• NEXT, SOME ADVICE WILL BE GIVEN.
4-34
ADVICE ON SPECIFICATION PRACTICES - I
• Remember: - Without specifications, there is no further work. - Specification mistakes are of commission and omission types. - A mistake in requirements/specifications that costs $1 to fix now would cost about $75 to fix during testing and more afterwards.
• Software specifications are begun during system design - There may be a “phase lag” between system and software.
• Software [requirements and] specifications will change - The challenge is in managing those changes. - Some changes can create an “earthquake” in software development. - Baselining [builds] is one way to control changes and impacts. - Incremental, evolutionary, and Spiral models may be helpful tools.
4-35
4-36
ADVICE ON SPECIFICATION PRACTICES - II
• Make sure quality characteristics and lower characteristics are as completely specified as possible: - Pay special attention to safety, security, and privacy. - Some quality characteristics may conflict with each other. - Prioritize the quality characteristics. - Caution: Software engineering may not be mature enough to design in several quality characteristics.
• Besides what the system needs to do, specify the following: - What the software must not do. - Execution behavior at non-normal inputs - Specifications of interfaces - Test cases and associated specifications, as needed - Constraints on design, interfaces, and test environment - Target environment, as much as possible
• Use specification language, techniques, and tools
QUALITY FACTORS [CHARACTERISTICS]
C: CONFLICTING; S: SUPPORTING; BLANK: NO RELATIONSHIP Source: James McCall 4-37
EFFICIENCY
FLEXIBILITY
INTEGRITY
INTEROPERABILITY
MAINTAINABILITY
PORTABILITY
RELIABILITY
RESPONSIVENESS
REUSABILITY
USABILITY
EFFICIE
NCY
FLEXIBILITY
INTEGRITY
INTEROPERABILITY
MAINTAIN
ABILITY
PORTABILITY
RELIABILITY
RESPONSIVENESS
REUSABILITY
TESTABILITY
USABILITY
TESTABILITY
C
S
S
C
S
S
C
C
S
S
C
S
S
C
S
S
C
S C
S
C
C S
C
C
C
C
S
C
C
C
S C S S S C SC
SAFETY, SECURITY, RELIABILITY
ENGINEERING EQUIPS THE SYSTEM WITH THE ABOVE FEATURES.4-38
SAFETYPREVENTING THE SYSTEM
FROM DAMAGING ITS EXTERNAL WORLDPROTECTING THE SYSTEM
FROM DAMAGE BY ITS EXTERNAL WORLD
SECURITY
SAFETY SHIELD SECURITY SHIELD
RELIABILITYASSURANCE THAT THE SYSTEM WILL PERFORM AS INTENDED.
ERGONOMICSHUMAN WORKING
FACTORS AFFECTING WORKING HUMANS (EXAMPLES):- ENVIRONMENTS -- NATURAL, ARTIFICIAL, WORK- CAPABILITY: PHYSICAL AND MENTAL- FELLOW WORKERS; EQUIPMENT; AUTOMATION- LIGHTING, CONSOLE, SCREEN, DESK, CHAIR, TIME, FOOD, et.al.
4-39
ADVICE ON TESTING - ICONTEXT
• A programmer describes a system function to a digital computer in “precise” instructions.
• What a programmer thinks s/he instructed the computer to do and what the computer understands it has been instructed to do are rarely the same.
• A program works in digital space, which is discrete and not finite.
• Completeness of testing: - It is impractical, if not impossible, to cover the digital space completely by testing.
• Adequacy of testing: - The magic is in covering the digital space adequately, but judiciously and cost-effectively.
• Do not depend on testing only to gain confidence. Use analysis, inspection, and demonstration as well.
4-40
ADVICE ON TESTING - IIADEQUACY OF TESTING
• Modularize - Follow the rules and schema of modularization. - Ensure correct order and passing of parameters.• For each module and aggregate, compare “line-by-line” outputs with manual calculations for certain input values: - Normal -- educated, representative points - Non-normal: Boundaries; Discontinuities; Singularities; +/- delta - Smallest and largest numbers allowed by the computer.• Note: The above must be accommodated by design and in code.
• Execute with global initializations: Zero; Infinity.• Cover McCabe’s basic paths.
• Compare runs with special/deduced/known cases.
• Remember: A modification may introduce new errors.• When a module is modified, ensure other modules are not affected.
• Employ a suitable reliability growth model to determine releasability.
• Include information on the computer, OS, language, and compiler.4-41
TOPICS
1. BACKGROUND
2. BASIC CONCEPTS
3. THE PROCESSES
4. APPLICATION
5. RELATED AREAS
6. SUMMARY
7. FOR YOUR INFORMATION
5-0
REFERENCED STANDARDS
5-1
REFERENCEDSTANDARD REFERENCED AS
REASON FORREFERENCING
AFNOR: Dictionary Normative Definitionsof Computer Science
ISO/IEC 2382-1 Normative Definitions
ISO/IEC 2382-20 Normative Definitions
ISO 8402 Normative Definitions
ISO 9001 Normative Additional guidanceon quality systems
[see clause 6.3]
ISO/IEC 9126 Normative Guidance onquality characteristics
[see clause 5.3.4]
ISO/IEC 12119 Bibliography Software packages
SUPPLEMENTARY STANDARDS
5-2
STANDARD STATUS
Technical Reports (TR):
- ISO/IEC 15271, 12207 Guidebook - Under publication
- ISO/IEC 14759, Mockup & Prototype Guide
Standard:ISO/IEC 14764, Software Maintenance
Under FDIS BALLOT
PublishedStandard:ISO/IEC 15846, Software CM
CDGuide:ISO/IEC 16326 Software Project Management
Canceled infavor of ISO 9000-3
Guide:Software QA
On holdGuide:Software V&V
On holdGuide:Reviews & Audits
- TR Ballot Passes
RELATIONSHIP TO SYSTEM AREAS
5-3
SOFTWAREENGINEERING
CONVENTIONALENGINEERING
SYSTEMSENGINEERING
NOT TO SCALE; NOT EXHAUSTIVE
INFORMATIONTECHNOLOGY
OTHERS
RELATIONSHIP TO QUALITY AREAS
5-4
SOFTWARE: ISO/IEC 12207
LIFE CYCLE PRACTICES
REQUIREMENTTO MANAGE PROCESSES
SYSTEM: ISO 9001; 8402QUALITY SYSTEMREQUIREMENTS
QUALITY ASSESSMENT
SYSTEM: ISO/IEC 15288
SYSTEM: ?SOFTWARE: ISO/IEC 15504SOFTWARE: ISO 9000-3
QUALITY SYSTEMREQUIREMENTS
REQUIREMENTTO ASSESS AND IMPROVE
PROCESSES
COMPARISON WITH ISO 9001
5-5
ISO 8402 ISO/IEC 12207ISO 9001
12207 INVOKES 9001 FOR FURTHER QUALITY SYSTEM
CORPORATE VIEW OF QUALITYQUALITY SYSTEM -- CONSOLIDATEDGENERAL PROCESS COMPLIANCE
SUPPLIER QUALITY SYSTEM CAPABILITY
FUNCTIONAL VIEW OF LIFE CYCLEQUALITY FUNCTIONS -- DELEGATEDSPECIFIC PROCESS COMPLIANCE
PRODUCT DEVELOPMENT; SERVICE
SupplierAcquirer
Dev Opr Mnt
CompanyX
......
TOPICS
1. BACKGROUND
2. BASIC CONCEPTS
3. THE PROCESSES
4. APPLICATION
5. RELATED AREAS
6. SUMMARY
7. FOR YOUR INFORMATION
6-0
SUMMARY
• 12207 IS THE TOP-LEVEL ARCHITECTURE OF SOFTWARE LIFE CYCLE - Architecture built with processes - Processes have tasks and outcomes.
• PROVIDES A COMMON FRAMEWORK FOR: - Acquiring & supplying products & services - Managing & improving the processes - World trade in software
6-1
EPILOGUE
• 12207 IS NOT A SUBSTITUTE FORDISCIPLINED MANAGEMENT AND ENGINEERING
• 12207 PROVIDES MERELY THE BUILDING BLOCKSFOR CONSTRUCTING MODELS, STRATEGIES, AND PLANSFOR PROJECTS AND ORGANIZATIONS- You need to proceduralize and automate the building blocks using your organizational knowledge and experience for that extra quality, competitiveness, and success
• 12207 SHOULD BE USED BY TRAINED PERSONNEL
• PLEASE READ THE STANDARD IN YOUR SPECIFIC CONTEXT:LEARNING, PROJECT, ORGANIZATION, ...- Otherwise, it may be misinterpreted
6-2
TOPICS
1. BACKGROUND
2. BASIC CONCEPTS
3. THE PROCESSES
4. APPLICATION
5. RELATED AREAS
6. SUMMARY
7. FOR YOUR INFORMATION7-0
COST AND BENEFIT OF USING 12207
• ASSUMPTION: Basic software engineering environment instituted
• COST/TIME OF IMPLEMENTING 12207 IN ORGANIZATION- Unknown, but one-time cost- Factors: - Size/extent of software engineering environment - Size/diversity of the organization
• COST OF 12207 TO A PROJECT- Unknown, but savings through maintenance significant- Project-to-project cost should be lower- Factors: - Size/complexity of the project - Size of the personnel - Schedule and quality - Maturity levels of the acquirer and supplier
• BENEFITS:- The discipline- Reduced risk to cost, schedule and performance
7-1
ADAPTATION OF 12207 IN COUNTRIES
• Most participating countries have issued their National versions
• The USA developed its version in 3 parts -- under ANSI’s sponsorship:
7-2
ISO/IEC 12207
IEEE/EIA 12207.0(STANDARD)- ISO/IEC 12207, AS IS- A FEW CHANGES- ADDITIONAL ANNEXES: - BASIC CONCEPTS - COMPLIANCE - ERRATA
IEEE/EIA 12207.2(GUIDE)- IMPLEMENTATION GUIDELINES
IEEE/EIA 12207.1(GUIDE)- LIFE CYCLE DATA
USA
COPIES OF 12207• ISO:
1, rue de VarembeCH-1211 Geneve 20Switzerland (Suisse)
• IEC:3, rue de VarembeCH-1211 Geneve 20Switzerland (Suisse)
• ANSI:American National Standards InstituteCustomer Services11 West 42nd St,New York, NY 10036USA[Tel: +1 212 642 4900; Fax: +1 212 302 1286]
7-3
ISO/IEC 15288System Life Cycle Processes
• BACKGROUND: - Jun 94: SC7 study group on software-system relationship - Feb 95: Study group report to SC7 (Doc # SC7 N1331) - Mar 95: US ANSI New Work Item proposal to SC7 - Jun 95: SC7 acceptance of the proposal - Apr 96: JTC1 approval of the project - May 96: Work started - Dec 00: Completion
• STUDY REPORT: - The software-system relationship is poor; needs immediate attention - Software is always part of system - Hardware & software are inherently different - Hardware & software are marching almost separately - Hardware terms are often unrealistic in software - 12207 has limited effectiveness without a system context - Recommended a standard on life cycle processes for modern systems containing hardware, software, and humans
• A CHALLENGE: Analog, digital, and manual functions together!
7-4
7-5
THANK YOUfor
LISTENING
Phone: +1 202 267-3976; Fax: +1 202 267-5580E-Mail: RAGHUBANSH.SINGH@FAA.DOT.GOV
PLEASE PROVIDE COMMENTS/SUGGESTIONS TO:
RAGHU SINGHFEDERAL AVIATION ADMINISTRATIONAIR-200, ROOM-815800 INDEPENDENCE AVE, S.W.WASHINGTON, DC 20591U.S.A.
BACKUPS
B-0
• ARCHITECTURE: - The art and science of planning and building structures - A unifying or coherent form or structure
• ASSESS: Fix the value, size, importance of ...
• AUDIT: Check the authencity of ... against a baseline, especially officially
• EVALUATE: Determine the worth, amount, value, or condition of ...
• COMPATIBILITY: Usable together in harmony
• COMPLY [with]: follow/obey [rules/laws] - The builder’s construction practices comply with the state’s building code.
• CONFORM [to]: Be in accordance with [specs.] - The house conforms to the official specs. of the building code.
• CONSISTENCY: In agreement with; does not contradict.
• CRITERION: A "standard" on which judgment is based
• DESIGN: - The arrangement of elements or details in a product or work - An underlying schema that governs functioning, developing, or unfolding
• ENVIRONMENT: An organization of manual and automated methods, techniques, and toolsand personnel employed to produce products and provide services.
• EXAMINE: Test by questioning. B-1
COMING TO TERMS - I
• FORM, FIT & FUNCTION (3F): - Form: physical configuration (shape) for interchangeability and compatibility - Fit: I/O characteristics for interoperability - Function: performance characteristics for “capable of doing its job.”
• FRAMEWORK: - A skeletal structure to hold or support something constructed or stretched over it - Work done in a frame.
• INSPECT: Check critically
• PROTOTYPE: A [primitive] model that exhibits essential operational features ...
• REQUIREMENT: - Something obligatory, demanded as a condition - Something needed
• REVIEW: A general survey of ...
• SYSTEMATIC: Definite scheme/method of procedure/classification
• VALIDATE: - Confirm the validity of ... - Declare legally valid
• VERIFY: - Check the correctness of ... by comparison - Prove to be true.
B-2
COMING TO TERMS - II
I: INDEPENDENCE: - FROM THOSE PERFORMING THE TASK OR DEVELOPING THE PRODUCT
O: ORGANIZATIONAL FREEDOM: - FROM THOSE WHO HAVE MANAGEMENT RESPONSIBILITY FOR THE TASK/PRODUCT
INDEPENDENCE &ORGANIZATIONAL FREEDOM
ORG. A ORG 2
DEVDEV 1 QA OPN MNT
O
I
I I I I
O O O O ODEV 2 OPERNMAINT ...
ORG. B
...
B-3
“FAULTY” TERMSError: Difference between computed and observedFault: Incorrect step/process/data definition ...Failure: Incorrect resultMistake: Action that produces an incorrect result
B-4
Cause of Error (a result, a manifestation):- Fault in the process or the product- Mistake by the system or human
CORRECT
MISTAKE
ACTIONBY
HUMANSor SYSTEMS
PERFORMANCE
DESIRED
DEGRADED
FAILED
RESULTE = ACTUAL - EXPECTED
CORRECTE < T
T : TOLERANCE BAND
ERRORE > T
PROCESSor PRODUCTEMPLOYED
CORRECT
FAULT
VERBAL FORMS - IIEC/ISO Directive , Part 3, Edition 1989
B-5
“4.1.2 A standard does not in itself impose any obligation upon anyoneto follow it. However, such an obligation may be imposed, for example,by legislation or by a contract. In order to be able to claim compliancewith a standard, the user needs to be able to identify the requirementshe is obliged to satisfy. He needs also to be able to distinguish theserequirements from other provisions where he has a certain freedom ofchoice.
Clear rules for the use of verbal forms (including modal auxiliaries) aretherefore essential.
Annex C gives, in the first column of each table, the verbal form that shall beused to express each kind of provision. The equivalent expressions given inthe second column shall be used only in exceptional cases when the formgiven in the first column cannot be used for linguistic reasons.”
[See the next chart for specific verbs.]
VERBAL FORMS - II Annex C, IEC/ISO Directive , Part 3, Edition 1989
B-6
• 12207 defines and uses “will,” which is not yet defined by ISO/IEC Directives.• “Will” in 12207 means self-declaration and requirement.
shall is to ...
is required to
has to ...
only ... is permitted
it is necessary ...
shall not it is not allowed
is required to be not
is required that ... be not
is not to be
must used to describeunavoidable situations
VERB MEANING
REQUIREMENT
should it is recommended that
ought to
should not it is recommended that ... not
ought not to
RECOMMENDATION
VERB MEANING
can to be able to
to be in a position to
there is a possibility of
it is possible to
cannot to be unable to
to be not in a position to
there is no possibility of
it is impossible to
VERB MEANING
POSSIBILITY
may is permitted
is allowed
is permissible
need not it is not required that
no ... is required
PERMISSION
VERB MEANING
DIDs
CLAUSES:SAFETYSECURITYPRIVACYREUSEMETRICSACCESS
498
ACQUISITIONSUPPLY
OPERATIONMAINTENANCE
DOCUMENTATIONVERIFICATIONVALIDATION
TRAINING
MANAGEMENTINFRASTRUCTURE
IMPROVEMENTTAILORING
JOINT REVIEW
AUDIT
QUALITY ASSURANCECONFIGURATION MANAGEMENT
PROBLEM RESOLUTION
DEVELOPMENT
12207
12207 & MIL-STD-498
B-7
12207 & MIL-STD-498 DIDs
12207 DEVELOPMENT DOCUMENTATION DIDs of MIL-STD-498
Plans for the dev. [versions in CM] (5.3.1.4) SDP [Includes CM, QA, ...]; SVD
System requirements specification (5.3.2.1) SSS
System architecture (5.3.3.1) SSDD
Software requirements/specs. (5.3.4.1) SRS; IRS
Architecture of software item (5.3.5.1) SDD; SPS
Detailed design (5.3.6.1) SDD; IDD; SPS
Database design (5.3.6.3) DBDD
Software units and databases (5.3.7.1) SPS; DBDD
Test reqs. (5.3.5.5, 5.3.6.5, 5.3.7.4, 5.3.8.1) STP; STD; STR
Installation plan (5.3.12.1) SIP
,, STrP (Transition)
User’s manuals(5.3.5.4, ..., 5.3.9.2) SUM; SIOM; SCOM; COM; CPM; FSM
Evaluation records (5.3.2.2, ..., 5.3.11.2) Internal records
Supply process (5.2.4.5) SDP; CM; QA; [SEMP/499B]
Acquisition process (5.1.1.1, 5.1.1.8) OCD; PMP (Gov’t)
B-8
• 498 is a development & documentation standard from acquisition perspective.• 498 is a family of standards, under DOD Directives and MIL-STD-499B (Systems).• 12207 addresses the life cycle and stakeholders.
12207: USING IT IN YOUR ORGANIZATION
• Tailor at two levels:
1. Adaptation at organization level - Environment with methods, tools & techniques 2. Tailoring the “adaptation” for each project
• Involve potential contractors and the post-development personnel
• Avoid fixed-price contract for software
12207: ADAPTATION TIPS
• ADAPT ISO/IEC 12207 - Begin with IEEE/EIA 12207 -- or NATO AQAP 150 - Incorporate changes and additions for your business sector - Institutionalize the Acquisition process (12207/5.1) - Ensure all tasks are supportable with personnel and procedures
• INVOKE SPECIALTY “STANDARDS” - Invoke RTCA DO-178B for the software requirements that impact system safety. - Similarly for security and human factors
• DEVELOP “DOCUMENTATION STANDARDS”: - Similar to US DoD’s DIDs - Demilitarize (use Jt-Std 016’s) - No prescription on format, media, etc. - To manage software development - For post-development personnel (operations, maintenance, et. al.)
B-9
12207: TAILORING TIPS
• DEVELOP YOUR OWN TAILORING GUIDANCE:
- Similar to MIL-HDBK-287 (Tailoring guide for 2167A) - Base on tailoring criteria in 12207’s Annexes A and B - Automate tailoring like 2167A Tailor
- Use a combination of the following: - The contractor has implemented a 12207 environment: - Develop guidance on assessing the environment - 12207 is directly used in contract: - Develop tailoring guidance for types of projects
- Do not compromise your project for off-the-shelf software - Ensure clause 5.1.1.7 is FULLY satisfied
- Aviod non-developmental item trap; Address clause 5.3.1.5.
- Consider evolutionary models -- with baselines and builds
B-10
• A COMMON PRODUCT - Identified as a preferred item in a situation
• A WRITTEN SET OF REQUIREMENTS FOR PRODUCTS (3F): - Form: - Physical configuration for interchangeability/compatibility - Fit: - Dimensional description of i/o for interoperability - Function: - Performance characteristics for job
• AN ACCEPTED PROCESS OR PROCEDURE - A series of actions or operations
• EXCEPTIONS: - Natural phenomena - Laws or regulations mandated by governments - Health, environment, safety, security, ...
B-11
WHAT IS A STANDARD?
CONFORMITY & CERTIFICATIONSOFTWARE PRODUCT & PROCESS
ADAPTATIONSTANDARDIZATION CERTIFICATION
CONFORMITY SHOULD BE ADDRESSED SEPARATELYFOR PRODUCTS AND PROCESSES-- SO SHOULD BE CERTIFICATION
PRODUCT 3F specs. Applicable3F specs.
Meets theapplicable3F specs.
PROCESS Activities/tasks Applicable Satisfies thefor the services activities & applicablein the life cycle activities &
? - Activities/tasks performed as planned
products/services? - Provides the
as specified
taskstasks
3F: Form, Fit, Function
B-12
CONFORMANCECOMPLIANCETAILORING
Meets theapplicable3F specs.
QUALITY MODELS
QUALITYASSURANCE
JOINTREVIEWS
AUDITS
VERIFICATION
VALIDATION
PROCESSIMPROVEMENT
ACQUISITION
SUPPLY
OPERATION
MAINTENANCE MAINTENANCE
OPERATION
SUPPLY
ACQUISITION
PROCESS
9001/9000-3
EXTERNAL
SURVEILLANCE
* AGRMT EVAL* REQ. EVAL.* DES. EVAL.* CODE. EVAL.* INTG. EVAL.* PROD. EVAL.
* DOC. EVAL.* INVOKED
PROCESS EVAL
- FUNC EVAL- PROJ EVAL- VALIDATION
SYS REQSYS DESSW REQ
SW ARC DESSW DET DES
SW CODINGSW INTEGNSW Q. TESTSYS INTEGN
SYS Q. T.I/A
? VERIFICATION
SYS REQSYS DESSW REQ
SW ARC DESSW DET DES
SW CODINGSW INTEGNSW Q. TESTSYS INTEGN
SYS Q. T.I/A
DEVELOPMENTDEVELOPMENTQ. A.
INTERNAL
EVALUATIONS
IN-PROCESS
/
IMPROVEMENT
[12207]MONOLITHIC QUALITY
[DRAFT OF 12 FEB 93]DELEGATED/SHARED QUALITY
QUALITY CONTROL
B-13
HUMOR IN CODE
Once God decided to find out what the Earthlings were up to.S/he descends upon the Earth. Finds a little girl crying overa broken doll, fixes it, and consoles her. Moves on. So s/hehelps other people.
Just before departing, God sees a haggard man brooding overa piece of paper. S/he asked who he was and what wasthe problem. The man said he was a programmer,but asked whether s/he had any programming experience.S/he humbly admitted to have programmed things fromBig Bangs to Black Holes. Impressed, the man showedhis paper.
God reviewed the paper and, after a pause, said,"Son, I think this one is yours."
Anonymous
B-14
POWED!
Q. How to have a standard powed?A. Utter one of the following:
• Prescriptive "It's prescriptive."
• OOD (and Ada) "I can't use OOD (and Ada) with it."
• Waterfall "It's a Waterfall model."
• Expensive "It's expensive to use."
• Documentation "It's documentation dependent."
B-15