LLT work flow: Refer to SWS-CR-0046 and work done in that CR.
LLT CR/CT assignment
write TCs as per requirement using TC template. update TC CT with implementation details. update TC CT state.
write TPs as per requirement using TP template. update TP CT with implementation details. update TP CT state.
write TRs as per requirement using TP template. update TR CT with implementation details. update TR CT state.
Create review for LLT artifacts as per peer review template. add correct checklists in the review as per plans and standards. update peer review record to right state. update all CTs state to DISPOSITIONED.
ask reviewers to conduct review and add findings, if any.
author shd fix the all findings and update findings state to implemented. finding author will verify and close the findings.
approver fill the checklist after all the findings are closed. then close the peer review record.
Close all CTs. then close CR.
change management process / change control process:
tools: JIRA-WP/WE, Clear Quest-CR/CT
100 system requirements
development ==> requirements - design - coding - integration
verification ==> reviews - testing - analysis (TCA-RBTCA+SCA)
testing ==> TC - TP & TP execute - TR (Unit Testing/Low level testing, SIT, HSIT) ==> LLT, HLT
analysis (TCA-RBTCA+SCA) 100%
RBTCA ==> requirements coverage analysis 100% (covered as a part of review of TCs)
SCA ==> code coverage analysis 100% (independence required if done manually. if we tool for SCA, tester itself can perform SCA)
SC 100%
DC 100%
MC/DC 100%
you should not change any project artifact without some CCB approved CR/CT assigned on your name.
all CR must be closed before release
all CTs under CR must be closed before closing CR
review must be completed for each CT before closing CT
CR/CT ==> new implementation / bug fixing
CCB ==> change control board
10% to 15% success rate.
CR1 ==> SYS1, SYS2 (development)
CT-HLR ==> hari
CT-Arch
CT-LLR
CT-code
CR2 ==> LLT
CT-LLT TC
CT-LLT TP
CT-LLT TR
CR3 ==> HLT
CT-HLT TC
CT-HLT TP
CT-HLT TR
CR4 ==> analysis
CT-HLR RBTCA
CT-LLR RBTCA
CT-SCA
CR2 ==>
CR3 ==>
CR4 ==>
CR5 ==>
.
.
.
CR50 ==>
CR51 ==> bug fixing
system requirements
software Planning process - PSAC, SDP, SVP, SCMP, SQAP, software requirements standards, software design standards, software code standards
change management - CR/CT (problem report)
CR - change request
CT - change task
--------------------------
Development:
HLR, HLR review
Software Architecture, Software Architecture Review
LLR, LLR review
Source Code, Source Code Review
Verification:
LLT/Unit testing - TC, TC review; TP, TP review; TR, TR review
TCA - RBTCA, RBTCA review; SCA, SCA Review.
SIT - TC, TC review; TP, TP review; TR, TR review
TCA - RBTCA, RBTCA review; SCA, SCA Review.
HLT/HSIT - TC, TC review; TP, TP review; TR, TR review
TCA - RBTCA, RBTCA review; SCA, SCA Review.
---------------------------------------
SCM,SQA,Certification
development bi-directional traceability:
system requirements <--> HLR <--> LLR <--> Source Code
verification bi-directional traceability:
requirements <--> TC <--> TP <--> TR
software
libraries - .c, .h
functions
Requirements states:
Draft - work in progress
Frozen - work completed and under review
Approved - work completed and review done.
Derived Requirements:
SYS1
SYS2
SYS3
SYS4
SYS5
-------------------------------------
HLR1 - SYS1, SYS3
HLR2 - SYS2
HLR3 - SYS4
HLR4 - SYS5
HLR5 - SYS1,SYS4, SYS5
HLR6 - SYS3, SYS4
HLR7 ==> DERIVED HLR
--------------------------------------
LLR1 - HLR1
LLR2 - HLR2
LLR3 - HLR3
LLR4 - HLR4
LLR5 - HLR5
LLR6 - HLR6
LLR7 ==> DERIVED LLR
LLR8 - HLR7
--------------------------------------
LLR requirement called as derived LLR if it does not have any traceability to HLR.
HLR requirement called as derived HLR if it does not have any traceability to SYSTEM REQUIREMENTS.
-------------------------------------
LLR ==> HIGHER LEVEL REQUIREMENTS ==> HLR
HLR ==> HIGHER LEVEL REQUIREMENTS ==> SYSTEM REQUIREMENTS
SYSTEM REQUIREMENTS==> HIGHER LEVEL REQUIREMENTS ==> CUSTOMER REQUIREMENTS
--------------------------------------
Derived requirements - Additional requirements resulting from the software development processes, which may not be directly traceable to higher level requirements.
speed()
dist_status()
time_status()
Unit Testing:
inputs:
LLR document
software architecture/data dictionary /SDD
CR/problem reports
Source Code/EOC
testing standards, SVP
Outputs:
TC file
TP file
TR file
CR created, if any
Development:
HLR (A2:1,2), HLR review (A3)
Software Architecture (A2:3), Software Architecture Review (A4:8-13)
LLR (A2:4,5), LLR review (A4:1-7)
Source Code (A2:6), Source Code Review (A5:1-6)
Verification:
LLT/Unit testing - TC, TC review; TP, TP review; TR, TR review ==> LLT TC/TP/TR development (A6:3,4), LLT TC/TP/TR Review (A7:1,2)
TCA - RBTCA (A7:4), RBTCA review ; SCA (A7:5,6,7), SCA Review.
A2 ==> development
A3 to A7 ==> verification
==> A2:7 ==> EOC
==> A3 ==> zero
==> A4 ==> zero
==> A5:7 ==> EOC
==> A6:1,2,5 ==> HLT, Target testing
==> A7:3,8 ==> HLR RBTCA, Control coupling/Data Coupling
system requirements - these are validated - correct + complete
-----------------
HLR
Arch
LLR
SC
EOC
Mukesh Ambani -
bomb
correct
review ==> subjective in nature
testing/analysis ==> objective in nature
10 000 00 0 000 ==> 1 failure
365*24 ==> 8760
RBTCA ==> not 100%
root causes: (resolution)
not tested some requirement completely ==> test requirement
missing test cases - normal/robustness ==> add missing test cases.
SCA ==> not 100% (statement coverage + decision coverage + MC/DC)
1000 test cases , 1 lac statements (100 statements not covered)
root causes:
missing test cases
missing requirements
dead code
deactivated code (type I, type II)
defensive code
tool error
autonomous driving ==> benz, bmw, maruti, honda