View
215
Download
0
Tags:
Embed Size (px)
Citation preview
Systems Engineering Process Models
Chris Wallace
CPDA D6: Systems Engineering June 2005
2
3
4
ISO 15288 processes
5
5.4.2 Requirements Analysis Process
• Purpose– .. to transform the stakeholder, requirements-driven view of
desired system services into a technical view ..• Outcomes
– 1) the required characteristics, attributes, and functional and behavioural requirements for architectural design of a product solution are specified…
– 2-4• Activities
– 1. Define the functional boundary of the system in terms of acceptable organisational policies and procedures with respect to the Requirements Analysis process
– 2-8• < 2 pages in total
6
ISO 15288 Example Lifecycle
7
Alternative process models
• Contrasting process models – (links on web site)
– ISO 15288– The CADMIT process (MOD)– Boehm’s Spiral risk-driven model (Future
Combat systems)– Agile Modelling and XP (Object-oriented
Software)
8
9
Spiral Model and Theory W• negotiation techniques are the most critical success factor in
improving the outcome of software projects. • The USC Center for Software Engineering has been developing a
negotiation-based approach to software system requirements engineering, architecture, development, and management.
• Components of the approach are:– Theory W, a management theory and approach, which says that making
winners of the system's key stakeholders is a necessary and sufficient condition for project success.
– The WinWin spiral model, which extends the spiral software development model by adding Theory W activities to the front of each cycle.
– WinWin, a groupware tool that makes it easier for distributed stakeholders to negotiate mutually satisfactory (win-win) system specifications.
• the WinWin spiral model is a good match for multimedia applications and is likely to be useful for other applications with similar characteristics--rapidly moving technology, many candidate approaches, little user or developer experience with similar systems, and the need for rapid completion.
10
Some Basic Design ideas
• Christopher Alexander– Mathematician from Cambridge turned design theorist
then community architect and philosopher at Berkeley• Engineering approach to deducing a system architecture• Representation of design knowledge as Patterns• “every design problem begins with an effort to achieve fitness
between two entities: the form in question and its context. The form is the solution to the problem; the context defines the problem... The real object of discussion is not the form alone but the ensemble comprising the form and its context”
• “the form is a part of the world over which we have control, and which we decide to shape while leaving the rest of the world as it is. The context is that part of the world which puts demands on this form.. Fitness is the relation of mutual acceptability between these two..”
11
Form / Context / Ensemble
Context (Alexander)
Form (Alexander)
Context System S1 (Martin)
Intervention SystemS2 (Martin)
Ensemble (Alexander)
Fitness (Alexander)System of Interest
(ISO 15288)
Real
Mental
Formal
3 Realms
13
Context-R
Context-M
Context-F
Form-R
Form-M
Form-F
Real
Mental
Formal
Fitness-R
Fitness-F
Alexander’s model of design
14
Classic staged process
• The core design task
• The basic staged model of development
• Validation and verification – the V Model
• Traceability
• Bridging the gap
15
Fitness-F
Requirements
Constraints
Concept of Operations
Use cases and Scenarios
Domain Theories
Knowledge of materials processes mechanisms existing forms including COTS
Architecture
Models
Context-F
Goals
Form-F
Trade studies
Specifications
Design
16
Context-R
Context-M
Context-F
Form-R
Form-M
Form-F
Real
Mental
Formal
Staged Development
17
Context-R
Context-M
Context-F
Form-R
Form-M
Form-F
Real
Mental
FormalVerification
Validation
Validation and Verification
18
Context-R
Context-M
Context-F
Form-R
Form-M
Form-F
Real
Mental
Formal
Traceability
Impact analysis Derivationanalysis
Choose Fx for Cy because
…
Design rationale
Coverage Analysis
19
Context-R
Context-M
Stakeholder Requirements
Form-R
Form-M
Architectural Design
Real
Mental
FormalSystem
requirements
Intermediate Stages
20
Concurrent models
• Concurrency arises from– Hierarchical decomposition– Product lifecycle– Multiple contexts and forms
21
Hierarchy• Context / Form distinction is relative: Form at one level
becomes (part of) the Context for sub-forms
ISO 15288
22
23
Form-M
Context-R
Context-M
Form-RReal
Mental
Formal
Form decomposition
P-R1 P-R2
P-F1 P-F2 P-F3
P-R3
P-M1 P-M2 P-M3
Context-F Form-F
24
Context-RManufacture
Test
Repair
Multiple lifecycle contexts
Context-R
Context-R
Context-R
Context-R
Context-RDisposal
Use
Training
Form-R
25
Multiple Contexts and Forms
• The context comprises multiple, nested interacting ‘systems’ arbitrarily bounded
• The form comprises not just system-of-interest but also support systems, training, documentation, servicing tools…
Context-Rc Form-RContext-RcContext-R
Context-R
Context-R
Context-R
Context-R
Form-R
Form-R
Form-R
Form-R
26
Design for X 1
• Design for assembly• Design for disassembly• Design for ease of use• Design for EMC (ElectroMagnetic Compatibility)• Design for installation• Design for maintenance• Design for validation• Design for manufacture• Design for quality• Design for reliability• Design for reuse• Design for speed• Design for cost• Design for environment
1. www.betterproductdesign.net/guide/design4X.htm
27
28
Complications
• Dynamics– The role of human cognition, social behaviour
and culture– Context is not fixed– Fitness is dynamic
• Form/Context separation is a myth
• Learning and feedback process models
29
Context-M
Context-R
Context-M
Context-F
Form-R
Form-M
Form-F
Real
Mental
Formal
Human cognition in the system
30
Context-R
Context-M
Context-F
Form-R
Form-M
Form-F
Real
Mental
Formal
Context is autonomous and dynamic
Context-F Form-FContext-F Form-F
31
Context-R
Context-M
Context-F
Form-R
Form-M
Form-F
Real
Mental
Formal
Fitness is dynamic