vv

Information about vv

Published on January 16, 2008

Author: Riccard

Source: authorstream.com

Content

Requirements Validation:  Requirements Validation Requirements Validation Requirements Management ?? Validation, Verification, Accreditation !!:  ?? Validation, Verification, Accreditation !! Check if evrything is OK With respect to what ? Mesurement associated with requirements Dont get lost with terminology problem Some definitions IEEE SRS EIA-632 Content:  Content What the standards say Techniques and methods Well established techniques Case study 'Validation: Are we building the right product' 'Verification: Are we building the product right' What the standard say (EIA632):  What the standard say (EIA632) 'Validation: Are we building the right product' 'Verification: Are we building the product right' What the standard say (EIA632):  What the standard say (EIA632) 'Validation: Are we building the right product' 'Verification: Are we building the product right' What the standard say (EIA632):  'Validation: Are we building the right product' 'Verification: Are we building the product right' What the standard say (EIA632) Validation:  Validation Requirements Validation is critical to successful system product development and implementation. Requirements are validated when it is certain that the subject set of requirements describes the input requirements and objectives such that the resulting system products can satisfy the requirements and objectives. The Requirements Validation Process helps ensure that the requirements are necessary and sufficient for creating design solutions appropriate to meeting the exit criteria of the applicable engineering life cycle phase and of the enterprise-based life cycle phase in which the engineering or reengineering efforts occur. 'Validation: Are we building the right product' 'Verification: Are we building the product right' Requirement 25—Requirement Statements Validation :  Requirement 25—Requirement Statements Validation The developer shall ensure that technical requirement statements and specified requirement statements, individually and as sets, are well formulated. 'Validation: Are we building the right product' 'Verification: Are we building the product right' Requirement 26—Acquirer Requirements Validation :  Requirement 26—Acquirer Requirements Validation The developer shall ensure that the set of defined acquirer requirements agrees with acquirer needs and expectations. 'Validation: Are we building the right product' 'Verification: Are we building the product right' Requirement 27—Other Stakeholder Requirements Validation:  Requirement 27—Other Stakeholder Requirements Validation The developer shall ensure that the set of defined other stakeholder requirements agrees with other stakeholder needs and expectations with respect to the system. 'Validation: Are we building the right product' 'Verification: Are we building the product right' Requirement 28—System Technical Requirements Validation:  Requirement 28—System Technical Requirements Validation The developer shall ensure that the set of defined system technical requirements agrees with the validated acquirer and other stakeholder requirements. 'Validation: Are we building the right product' 'Verification: Are we building the product right' Requirement 29—Logical Solution Representations Validation :  Requirement 29—Logical Solution Representations Validation The developer shall ensure that each set of logical solution representations agrees with the appropriately assigned subset of system technical requirements. 'Validation: Are we building the right product' 'Verification: Are we building the product right' System Verification:  System Verification The System Verification Process is used to ascertain that: the system design solution generated by implementing Requirement 19 is consistent with its source requirements (selected preferred physical solution representation); end products at each level of the system structure implementation, from the bottom upmeet their specified requirements; enabling product development or procurement for each associated process is properly progressing; and required enabling products will be ready and available when needed to perform. 'Validation: Are we building the right product' 'Verification: Are we building the product right' Requirement 30—Design Solution Verification:  Requirement 30—Design Solution Verification The developer shall verify that each end product defined by the system design solution conforms to the requirements of the selected physical solution representation. 'Validation: Are we building the right product' 'Verification: Are we building the product right' Requirement 31—End Product Verification :  Requirement 31—End Product Verification The developer shall verify that an end product to be delivered to an acquirer conforms to its specified requirements. 'Validation: Are we building the right product' 'Verification: Are we building the product right' Requirement 32—Enabling Product Readiness:  Requirement 32—Enabling Product Readiness The developer shall determine readiness of enabling products for development, production, test, deployment/installation, training, support/maintenance, and retirement or disposal. 'Validation: Are we building the right product' 'Verification: Are we building the product right' Requirement 33—End Products Validation :  Requirement 33—End Products Validation The developer shall ensure that an end product, or an aggregation of end products, conforms to its validated acquirer requirements. 'Validation: Are we building the right product' 'Verification: Are we building the product right' What the standards say (*):  What the standards say (*) Main standards IEEE P1220 EIA 632 DoD 2167A 'Validation: Are we building the right product' 'Verification: Are we building the product right' Correctness and completeness:  Correctness and completeness A correct, complete set of requirements is one that correctly and completely states the desires and needs of the sponsor. If the requirements are incorrect, the software may meet the requirements as stated, but will not do what the sponsor wants it to do. If the requirements are incomplete, the software may do only part of what the sponsor hoped it would do. 'Validation: Are we building the right product' 'Verification: Are we building the product right' Consistent:  Consistent Consistency is obtained if the requirements do not contradict each other. Inconsistency results when one requirement contradicts another. 'Validation: Are we building the right product' 'Verification: Are we building the product right' Unambiguous:  Unambiguous If a requirement is subject to more than one interpretation, it is ambiguous. Requirements should be stated simply and completely so that they are unambiguous. 'Validation: Are we building the right product' 'Verification: Are we building the product right' Functional:  Functional Requirements should state what the sponsor desires : the functions and activities to be performed by the system. They should not state how the problem is to be solved or what techniques are to be used. Such decisions should be left to the system designers. 'Validation: Are we building the right product' 'Verification: Are we building the product right' Verifiable:  Verifiable The requirements must be verifiable in two ways: * do the requirements satisfy the sponsor's needs ? * does the system satisfy the requirements? In the first case, the requirements must be compared to the sponsor's desires and needs. Do the requirements correctly and completely specify the sponsor's desires and needs? In the second case, once the system has been developed, it must be compared to the requirements. Does the system meet the requirements as they are stated? 'Validation: Are we building the right product' 'Verification: Are we building the product right' Traceability:  Traceability Traceable and easily changed. The requirements should be organized and written in a segmented, top down manner that allows for easy use (traceability) and easy modification. A numbering system is useful to label the paragraphs and parts of the manual for cross referencing, indexing, and easy modification 'Validation: Are we building the right product' 'Verification: Are we building the product right' Techniques and methods:  Techniques and methods Inspection Model Checking Simulation Prototyping Others 'Validation: Are we building the right product' 'Verification: Are we building the product right' Inspection:  Inspection Most common simple et pragmatic method and can be Manual : Human sense principal instrument Automatic (CAI tool) : for measurable issues Most evident errors/faults can be detected 'Validation: Are we building the right product' 'Verification: Are we building the product right' Inspection (example):  Inspection (example) 'Validation: Are we building the right product' 'Verification: Are we building the product right' This presentation shows how to carry out a one-half hour inspection with senior managers. The purpose is to show to make managers aware that they play a key-role in creating project delays by approving poor quality of requirements documents. The inspection results shown in this real-life example successfully predicted a project delay of 2 calendar years. Poor quality marketing requirements documents prove time and again to be a good predictor of project delays. The clue is that requirements documents with a high defect density are an indicator of a truly unprofessional engineering culture. Inspection (example):  Inspection (example) 'Validation: Are we building the right product' 'Verification: Are we building the product right' Three Rules for Requirements: 1. Unambiguous to intended Readership 2. Clear enough to test. 3. No Design (how to) mixed in with Requirements (how well) MARK Design as “D” Rules Introduce the following three rules for inspecting a requirements document: Inspection (example):  Inspection (example) 'Validation: Are we building the right product' 'Verification: Are we building the product right' A Defect is a violation of a Rule Note: If there are 10 ambiguous terms in a single requirement then there are 10 defects! Defect Explain the definition of a Defect: Inspection (example):  Inspection (example) 'Validation: Are we building the right product' 'Verification: Are we building the product right' Major: a defect severity where there is potential of high (x lost engineering hours) loss later downstream (test, field). Severity Explain: the definition of Major Defect the checkers must focus on finding Major Defects Inspection (example):  Inspection (example) 'Validation: Are we building the right product' 'Verification: Are we building the product right' Exit Conditions: (Requirements can go to Design, Test etc with little risk) Maximum 1 Major Defect/ (Logical) Page Logical Page = 300 Non commentary words. Exit? Agree with the management team on a numeric exit condition Inspection (example):  Inspection (example) The Job 'Validation: Are we building the right product' 'Verification: Are we building the product right' You have up to 30 minutes for checking One requirements Logical page from an 82 pages document Count all Rule Violations = Defects Classify Major and minor Inspection (example):  Inspection (example) 'Validation: Are we building the right product' 'Verification: Are we building the product right' Page 81: 120 majors/p Page 82: 180 Majors/p Average 150 Majors/page x 82 page = 12,300 Majors in the document. ----------------- If a Major has 1/3 chance of causing loss And each loss is avg 10 hours then total project Rework cost is about 41,000 hours loss. (This project was over a year late) 1 year = 2,000 hour 10 people Inspection (example):  Inspection (example) 'Validation: Are we building the right product' 'Verification: Are we building the product right' Boss! We have 2 options for the 82 page Requirements document. Our sample shows that we have 180 Majors/Page. We can spend 180 hours per page removing them with Inspection We can rewrite the pages at a cost of 10hours each. Or we can suffer 30% of these as bugs and fault, at an average removal cost of about 10 hours each (test and field debugging and re-testing), 1/3 of 180 x 10 = 600 hours per page if we do not rewrite (10 hours /Page) or remove before test (180 hours/Pages). We suggest rewrite (changing something to avoid defect injection rate). But you have said you are against this. So we have to tell you that your option will delay our project by 600 hours x 82 = 49,200 hours. Our project has 10 people on it, and they can do about 2,000 hours per year. So that is 20,000 work hours per year for our team. The approximate delay for your decision not to rewrite is this about 2.5 years worse Time To Market. We will of course do what you say, but we wanted to be sure that you understood what your boss will blame you for later. Your Loyal Servant, Tom Letter to Your Boss Simulation:  Simulation Abstract model of either requirements or the design solution Coverage of most scenarios 'Validation: Are we building the right product' 'Verification: Are we building the product right' Model Checking:  Model Checking Model checking is a method for formally verifying finite-state concurrent systems Specifications about the system are expressed as temporal logic formulas, and efficient symbolic algorithms are used to traverse the model defined by the system and check if the specification holds or not Extremely large state-spaces can often be traversed in minutes The technique has been applied to several complex industrial systems Site : http://archive.comlab.ox.ac.uk/formal-methods.html 'Validation: Are we building the right product' 'Verification: Are we building the product right' Model Checking and Formality:  Model Checking and Formality 'Validation: Are we building the right product' 'Verification: Are we building the product right' Model Checking and Formality:  Model Checking and Formality 'Validation: Are we building the right product' 'Verification: Are we building the product right' Models of a System Physical Prototypes Abstractions Representations (Working Models) Model Checking and Formality:  Model Checking and Formality 'Validation: Are we building the right product' 'Verification: Are we building the product right' A mathematical model is an abstract representation of a system employing mathematical entities and concepts Model should be expressive enough to capture the essential characteristics of the system being modeled If the model is intended for deductive reasoning about the underlying system, it should provide sufficient analytic power for this purpose Model Checking and Formality:  Model Checking and Formality 'Validation: Are we building the right product' 'Verification: Are we building the product right' Model Checking and Formality:  Model Checking and Formality 'Validation: Are we building the right product' 'Verification: Are we building the product right' Model is more concise and precise than natural language, pseudo-code, and diagrammatic representations Model can be used to calculate and predict system behavior Model can be analyzed using mathematical reasoning -- proving properties, deriving new behaviors, etc. Model Checking and Formality:  Model Checking and Formality 'Validation: Are we building the right product' 'Verification: Are we building the product right' Model Checking and Formality:  Model Checking and Formality 'Validation: Are we building the right product' 'Verification: Are we building the product right' Model Checking and Formality:  Model Checking and Formality 'Validation: Are we building the right product' 'Verification: Are we building the product right' A Simple String Parser: Given an input string of 0’s and 1’s, determine if the string starts and ends with a 1. S1 S2 D 1 0 1 S0 0 “dead” state 1 “accept” state 0, 1 start State Transition Function current state input 0 1 D S1 S1 D S1 S2 S2 D S0 S1 S2 D next state 0 Formality:  Formality 'Validation: Are we building the right product' 'Verification: Are we building the product right' Methods for Formal Analysis Theorem Proof Model Animation & Proving Checking Checking Simulation L 5 Formal analysis refers to tool-based techniques used to explore, debug, and verify formal specifications. our focus here Formality-Properties:  Formality-Properties 'Validation: Are we building the right product' 'Verification: Are we building the product right' Consistent -- means it is not possible to derive a statement and it’s negation within the system Complete -- means every true statement within the system is provable Decidable -- means there is an effective algorithm (e.g. computer program) for determining whether any statement formed within the system is true A system must be consistent to be useable in formal methods (or any other area). While decidability and completeness would be nice, these can not be achieved in most interesting formal systems. However, this does not prevent the effective use of these systems. Formality:  Formality 'Validation: Are we building the right product' 'Verification: Are we building the product right' A sequent is written G |- D, which means /\ G implies \/ D, where G is a (possibly empty) list of formulas {A1, …, An} and D is a (possibly empty) list of formulas {B1, …, Bn} the formulas in G are called the antecedents the formulas in D are called the succedents or consequents To restate, G |- D means A1 /\ … /\ An implies B1 \/ … \/ Bn Formality:  Formality 'Validation: Are we building the right product' 'Verification: Are we building the product right' A sequent calculus proof is a tree of sequents whose root is a sequent of the form |- T where T is the formula to be proved and the antecedent is empty The proof tree is then generated by applying inference rules of the form: G1 |- D1 … Gn |- Dn G |- D Intuitively, this rule replaces a leaf node in the proof tree of form G |- D with the n new leaves specified in the rule. If n is zero, that branch of the proof tree terminates. Formality:  Formality 'Validation: Are we building the right product' 'Verification: Are we building the product right' The Propositional Axiom (Prop_Axiom) is one of the rules of inference in the sequent calculus. It has the following form form: (G, A) |- (A, D) Intuitively, this rule indicates that a proof branch is complete when the sequent above is derived. Note that the consequent means the following: G /\ A implies A \/ D which is obviously true. Prop_Axiom Formality:  Formality 'Validation: Are we building the right product' 'Verification: Are we building the product right' The Rule for Conjunction on the Right (And_Right) is another of the rules of inference in the sequent calculus. It has the following form: G |- A, D G |- B, D G |- (A /\ B, D) This rule is typical of many sequent calculus inference rules which divide, but simplify, a branch of the proof tree. Note that the consequent is replaced by two simpler formulas which will be easier for a mechanized theorem prover to deal with. Formality:  Formality 'Validation: Are we building the right product' 'Verification: Are we building the product right' The Rule for Conjunction on the Left (And_Left) is another of the rules of inference in the sequent calculus. It has the following simple (non-branching) form: A, B, G |- D (A /\ B, G) |- D This rule is typical of several sequent calculus inference rules which simply restate the “obvious,” thereby providing a form easier for a mechanized theorem prover to deal with. And_Left Formality:  Formality 'Validation: Are we building the right product' 'Verification: Are we building the product right' The Rule for Implication on the Left (Implies_Left) is another of the rules of inference in the sequent calculus. It has the following form: G |- A, D B, G |- D (A => B, G) |- D Similar to the And_Right rule, this rule again splits the proof into two cases, each of which will be easier for the mechanical prover to deal with. Implies_Left Formality:  Formality 'Validation: Are we building the right product' 'Verification: Are we building the product right' The Rule for Implication on the Right (Implies_Right) is another of the rules of inference in the sequent calculus. It has the following form: G, A |- B, D G |- (A => B, D) This rule does not branch, but provides a form easier for a mechanized theorem prover to deal with. Implies_Right Formality:  Formality 'Validation: Are we building the right product' 'Verification: Are we building the product right' The following example proof in the sequent calculus (taken from NASA Guidebook: NASA-GB-001-97, Release 1.0, pp. 97-101) will use only the five sequent calculus inference rules we define earlier -- Prop_Axiom, And_Left, And_Right, Implies_Left, and Implies_Right. The theorem (assumed to be named “Theorem 1”) to be proved is the following: Theorem 1: (P => (Q => R)) => ((P /\ Q) => R) Formality:  Formality 'Validation: Are we building the right product' 'Verification: Are we building the product right' Theorem 1: (P => (Q => R)) => ((P /\ Q) => R) We begin the proof by forming the requisite sequent: Antecedents: none Consequents: Formula 1: (P => (Q => R)) => ((P /\ Q) => R) Formality:  Formality 'Validation: Are we building the right product' 'Verification: Are we building the product right' As our first step we apply the rule Implies_Right. This rule will decompose the entire formula. Remember there is an implied “implies” in the sequent. In other words this sequent could be written |- (P => (Q => R)) => ((P /\ Q) => R). Hence, the implies we apply the rule to is the outside implies on the right of the sequent Antecedents: Formula 1: P => (Q => R) Consequents: Formula 1: (P /\ Q) => R Formality:  Formality 'Validation: Are we building the right product' 'Verification: Are we building the product right' A second application of the rule Implies_Right will decompose the formula below the line in a similar way. Remember that rules applying to the “left” part of the sequent work on formulas above the bar; rules applying to the “right” part of the sequent work below the bar. Antecedents: Formula 1: P => (Q => R) Formula 2: P /\ Q Consequents: Formula 1: R Formality:  Formality 'Validation: Are we building the right product' 'Verification: Are we building the product right' We next apply the rule And_Left -- this rule will modify (rewrite) Formula 2 above the line. Remember that all formulas above the line are connected by AND’s; formulas below the line are connected by OR’s. Antecedents: Formula 1: P => (Q => R) Formula 2: P Formula 3: Q Consequents: Formula 1: R Formality:  Formality 'Validation: Are we building the right product' 'Verification: Are we building the product right' We next apply the rule Implies_Left -- this rule will modify Formula 1 above the line. Remember that Implies_Left splits the proof tree into two branches. We show and deal with Case 1 first, then move to Case 2 later. Case 1: Antecedents: Formula 1: Q => R Formula 2: P Formula 3: Q Consequents: Formula 1: R Formality:  Formality 'Validation: Are we building the right product' 'Verification: Are we building the product right' To modify Formula 1 above the line, we next apply the rule Implies_Left again. Again this splits the proof tree into two branches. We show and deal with Case 1.1 first, then move to Case 1.2 later. Case 1.1: Antecedents: Formula 1: R Formula 2: P Formula 3: Q Consequents: Formula 1: R Case 1.1 will now yield to an application of Prop_Axiom Formality:  Formality 'Validation: Are we building the right product' 'Verification: Are we building the product right' As noted, an application of Prop_Axiom (Step 5) completes Case 1.1. We now move to Case 1.2. This is the second case resulting from the application of Implies_Left on the Case 1 sequent. Another application of Prop_Axiom (Step 6) completes Case 1.2 (and in turn Case 1 itself). Case 1.2: Antecedents: Formula 1: P Formula 2: Q Consequents: Formula 1: Q Formula 2: R Case 1.2 will also yield to an application of Prop_Axiom Formality:  Formality 'Validation: Are we building the right product' 'Verification: Are we building the product right' Having completed the proof for Case 1, we now move to Case 2. Recall that this is the second case resulting from our first application of Implies_Left. Another application of Prop_Axiom (Step 7) completes Case 2 (and in turn the entire proof). Case 2: Antecedents: Formula 1: P Formula 2: Q Consequents: Formula 1: P Formula 2: R Case 2 will also yield to an application of Prop_Axiom Prototyping:  Prototyping Oriented to design model Dont confuse with simulation Some consider functional requirements only. Can be a partial implementation of requirements Can be an executable specification 'Validation: Are we building the right product' 'Verification: Are we building the product right' The Two V‘s and techniques:  The Two V‘s and techniques V&V in order to avoid what is >verifivation and validation : an eternal debate In either case : We check with respect to something. Consider a Petri net model of list automation Verifying Properties of Petri nets does not mean the user is satisfied 'Validation: Are we building the right product' 'Verification: Are we building the product right' V&V in EIA 632:  V&V in EIA 632 'Validation: Are we building the right product' 'Verification: Are we building the product right' V&V in EIA 632:  V&V in EIA 632 'Validation: Are we building the right product' 'Verification: Are we building the product right' Conclusions:  Conclusions Many techniques Many tools Notation oriented in some cases (formal and semi-formal methods) 'Validation: Are we building the right product' 'Verification: Are we building the product right' Next lecture:  Next lecture Standards and Case Studies Verification and Validation 'Validation: Are we building the right product' 'Verification: Are we building the product right'

Related presentations


Other presentations created by Riccard

NIC RoHS WEEE
09. 01. 2008
0 views

NIC RoHS WEEE

Chapter 4 The Colonies copy 2
10. 01. 2008
0 views

Chapter 4 The Colonies copy 2

PP066
11. 01. 2008
0 views

PP066

wedding brochure
11. 01. 2008
0 views

wedding brochure

HarlemRenaissance
11. 01. 2008
0 views

HarlemRenaissance

pakisnl
15. 01. 2008
0 views

pakisnl

CS4705phonetWEB
15. 01. 2008
0 views

CS4705phonetWEB

Spiritual Warfare
17. 01. 2008
0 views

Spiritual Warfare

Paper 16 QinetiQ
21. 01. 2008
0 views

Paper 16 QinetiQ

ACP EU 16h30 v5
22. 01. 2008
0 views

ACP EU 16h30 v5

l05a
22. 01. 2008
0 views

l05a

Symposium
23. 01. 2008
0 views

Symposium

Can you hear me Now 1
04. 02. 2008
0 views

Can you hear me Now 1

Lecture 2 Semiotics History
05. 02. 2008
0 views

Lecture 2 Semiotics History

newtech
08. 02. 2008
0 views

newtech

Narrativepwh
12. 02. 2008
0 views

Narrativepwh

APS LAX talk for web
09. 01. 2008
0 views

APS LAX talk for web

smt exam3
25. 01. 2008
0 views

smt exam3

massac1
08. 01. 2008
0 views

massac1

McDougall Crop Protection Market
28. 01. 2008
0 views

McDougall Crop Protection Market

Aquator presentation
05. 02. 2008
0 views

Aquator presentation

feeding children
06. 02. 2008
0 views

feeding children

D31831 D21461 Beowulf
07. 02. 2008
0 views

D31831 D21461 Beowulf

Unisys Migrating to MOSS
20. 02. 2008
0 views

Unisys Migrating to MOSS

sunum
20. 02. 2008
0 views

sunum

Comet
16. 01. 2008
0 views

Comet

pps 311
14. 02. 2008
0 views

pps 311

mvwzju14
28. 02. 2008
0 views

mvwzju14

the pinkle winkle
03. 03. 2008
0 views

the pinkle winkle

DVC sacred feminine
08. 03. 2008
0 views

DVC sacred feminine

dealer
12. 03. 2008
0 views

dealer

Mixed Methods Presentation
15. 03. 2008
0 views

Mixed Methods Presentation

Get Rich Quick
19. 03. 2008
0 views

Get Rich Quick

cyber attacks
20. 03. 2008
0 views

cyber attacks

The Greek Culture
15. 04. 2008
0 views

The Greek Culture

MartinArchery
16. 04. 2008
0 views

MartinArchery

sixhats
17. 04. 2008
0 views

sixhats

natural step presentation
18. 04. 2008
0 views

natural step presentation

3 Sports marketing
21. 04. 2008
0 views

3 Sports marketing

TonyWinterbottom
22. 04. 2008
0 views

TonyWinterbottom

skrzypiec2
28. 01. 2008
0 views

skrzypiec2

I3P at UCB 2005 11 17
24. 04. 2008
0 views

I3P at UCB 2005 11 17

rosenberg
08. 05. 2008
0 views

rosenberg

05 AACSB Presentation 2 6
30. 04. 2008
0 views

05 AACSB Presentation 2 6

ChallengeSMOT0706
02. 05. 2008
0 views

ChallengeSMOT0706

Web Integration
02. 05. 2008
0 views

Web Integration

German
06. 02. 2008
0 views

German

Prager at Conference
21. 01. 2008
0 views

Prager at Conference

Relationship with sports media
24. 01. 2008
0 views

Relationship with sports media

cispres
11. 02. 2008
0 views

cispres

Habitat for Humanity
23. 01. 2008
0 views

Habitat for Humanity

01 IntroduccionACsharp
21. 02. 2008
0 views

01 IntroduccionACsharp

eckhart presentation
26. 01. 2008
0 views

eckhart presentation

corporatesponsors
14. 04. 2008
0 views

corporatesponsors

13 Presentacion 2005
12. 01. 2008
0 views

13 Presentacion 2005

s Wedding
05. 02. 2008
0 views

s Wedding

eCommerce Artisans
31. 01. 2008
0 views

eCommerce Artisans

hydrogeneconomychall enges
24. 01. 2008
0 views

hydrogeneconomychall enges

BrainDrainjan11
31. 03. 2008
0 views

BrainDrainjan11

clemmons injuctions
23. 01. 2008
0 views

clemmons injuctions

Panasonic
10. 04. 2008
0 views

Panasonic

20050615report 2
25. 02. 2008
0 views

20050615report 2

Graying of the Northstate
08. 04. 2008
0 views

Graying of the Northstate