Authored by : Hitesh Sanghavi
SEI authorized Lead Appraiser
Hitesh@cunixinfotech.com
Submitted to SEIR (SEI repository)
Legend:
TS: Technical Solution
PI: Product Integration
ICWG: Interface Control Working Group
PC: Product Component
Objectives of TS
The objective of TS is to design (developing architecture, high level and low level/detail design), develop (coding or data conversion activity for Data migration), and implement (successful deployment at the customer’s site) solutions as per agreed and documented requirements (as per the requirements management and development activities/phase). This includes products, PCs (programs or modules), and product-related lifecycle processes (user manual, design manuals etc).
Where TS applies:
TS SCOPE:
TS is applied to every product and service that the organization develops/deploys including PCs (units, modules, large programs etc), product related life-cycle process and service/maintenance of products/PCs at all levels of the product architecture. Also, the product-related life-cycle processes are developed along with the product/PC, selecting and adapting existing processes (including standard processes) for use as well as developing new processes as per the tailoring guidelines in the model and the QMS. The interfaces are identified and defined during the design phase (TS: SG2). TS is valid for various types of projects like support activities, off shore development, software maintenance, ERP implementation, data migration etc. TS has a clear focus on:
1.Evaluating/selecting “design approaches/concepts” or “prototypes/preliminary designs/Proof of concepts” that potentially satisfy an appropriate set of allocated requirements or PC prototypes or service models.
2.Implementing the designs (of product, PCs or service models) with integrated activities interactively support each other.
Inputs to TS from RD:
TS accepts requirements from RD, subsequently convert it into product architecture, PC (coding or data conversion activity for Data migration) or PC design (high or low level).
Impact on RM due to TS-PI interdependencies :
RM fundamentally controls changes to requirements are reflected in the deliverables of other engineering PA’s (due to recursive and dynamic sequence of events by RM) and subsequently in integrated project plans, activities and work products. The table of TS-PI deliverables (at the end of this document) clearly depicts the goal wise deliverables of TS and PI (i.e. the requirements generated by enacting TS-PI activities), the activities which are to be included in the project plan and managed by RM.
Differences in TS-PI Base and Advance practices. (PI does not have advance practices.)
• In TS, SP1.1-1(base practice) “Develop Alternative solutions” is there, on which TS 1.1-2, (advance practice) is built, as “Develop detailed Alternative solutions” which is relatively more demanding. Thus TS 1.1-2 is included in the staged model and it subsumes TS.SP1.1-1(base practice).
• In TS. SP2.3-1(base practice) we have “Establish Interface Descriptions” and in TS.SP2.3-3 (advance practice is built on base practice), we see” Design Interfaces Using Criteria” .Thus TS 1.1-2 is included in the staged model and it subsumes TS.SP2.3-1(base practice).
TS
TS has 3 goals (9 SPs with 2 base practices) for TS with the below Deliverables/ work products.
a) Select PC Solutions
- Alternative solution screening criteria leading to solutions.
- Evaluations of new technologies
- Selection criteria for final selection
- PC operational concepts, scenarios, and environments for all product-related life-cycle processes(e.g. operations, support, training, manufacturing, deployment and delivery)
- Timeline analyses of PC interactions using OOAD and Use cases
- PC selection decisions and rationale
- Documented relationships between requirements and PCs, Document solutions, evaluations, and rationale.
b) Develop the Design
- Product architecture, PC designs
- Technical data package
- Interface design specifications with criteria
- Interface control documents
- Rationale for selected interface design
- Criteria for design and PC reuse
- Make-or-buy analyses and Guidelines for choosing COTS PCs.
c) Implement the Product Design
- Implemented design
- End-user training materials, User's/Operator’s manual, Maintenance manual, online help etc.
SEI authorized Lead Appraiser
Hitesh@cunixinfotech.com
Submitted to SEIR (SEI repository)
Legend:
TS: Technical Solution
PI: Product Integration
ICWG: Interface Control Working Group
PC: Product Component
Objectives of TS
The objective of TS is to design (developing architecture, high level and low level/detail design), develop (coding or data conversion activity for Data migration), and implement (successful deployment at the customer’s site) solutions as per agreed and documented requirements (as per the requirements management and development activities/phase). This includes products, PCs (programs or modules), and product-related lifecycle processes (user manual, design manuals etc).
Where TS applies:
TS SCOPE:
TS is applied to every product and service that the organization develops/deploys including PCs (units, modules, large programs etc), product related life-cycle process and service/maintenance of products/PCs at all levels of the product architecture. Also, the product-related life-cycle processes are developed along with the product/PC, selecting and adapting existing processes (including standard processes) for use as well as developing new processes as per the tailoring guidelines in the model and the QMS. The interfaces are identified and defined during the design phase (TS: SG2). TS is valid for various types of projects like support activities, off shore development, software maintenance, ERP implementation, data migration etc. TS has a clear focus on:
1.Evaluating/selecting “design approaches/concepts” or “prototypes/preliminary designs/Proof of concepts” that potentially satisfy an appropriate set of allocated requirements or PC prototypes or service models.
2.Implementing the designs (of product, PCs or service models) with integrated activities interactively support each other.
Inputs to TS from RD:
TS accepts requirements from RD, subsequently convert it into product architecture, PC (coding or data conversion activity for Data migration) or PC design (high or low level).
Impact on RM due to TS-PI interdependencies :
RM fundamentally controls changes to requirements are reflected in the deliverables of other engineering PA’s (due to recursive and dynamic sequence of events by RM) and subsequently in integrated project plans, activities and work products. The table of TS-PI deliverables (at the end of this document) clearly depicts the goal wise deliverables of TS and PI (i.e. the requirements generated by enacting TS-PI activities), the activities which are to be included in the project plan and managed by RM.
Differences in TS-PI Base and Advance practices. (PI does not have advance practices.)
• In TS, SP1.1-1(base practice) “Develop Alternative solutions” is there, on which TS 1.1-2, (advance practice) is built, as “Develop detailed Alternative solutions” which is relatively more demanding. Thus TS 1.1-2 is included in the staged model and it subsumes TS.SP1.1-1(base practice).
• In TS. SP2.3-1(base practice) we have “Establish Interface Descriptions” and in TS.SP2.3-3 (advance practice is built on base practice), we see” Design Interfaces Using Criteria” .Thus TS 1.1-2 is included in the staged model and it subsumes TS.SP2.3-1(base practice).
TS
TS has 3 goals (9 SPs with 2 base practices) for TS with the below Deliverables/ work products.
a) Select PC Solutions
- Alternative solution screening criteria leading to solutions.
- Evaluations of new technologies
- Selection criteria for final selection
- PC operational concepts, scenarios, and environments for all product-related life-cycle processes(e.g. operations, support, training, manufacturing, deployment and delivery)
- Timeline analyses of PC interactions using OOAD and Use cases
- PC selection decisions and rationale
- Documented relationships between requirements and PCs, Document solutions, evaluations, and rationale.
b) Develop the Design
- Product architecture, PC designs
- Technical data package
- Interface design specifications with criteria
- Interface control documents
- Rationale for selected interface design
- Criteria for design and PC reuse
- Make-or-buy analyses and Guidelines for choosing COTS PCs.
c) Implement the Product Design
- Implemented design
- End-user training materials, User's/Operator’s manual, Maintenance manual, online help etc.
Hitesh Sanghvi, MD of Cunix, is an SEI authorized SCAMPI Lead appraiser with rich experience in IT Consulting ,S/w Test Strategies, Software Process Quality, CMM / CMMI, SPI Consulting, Training and appraisals.
Previous posts
0 Responses to “ Technical Solution”
Post a Comment