• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
download
 

download

on

  • 336 views

 

Statistics

Views

Total Views
336
Views on SlideShare
336
Embed Views
0

Actions

Likes
0
Downloads
1
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft Word

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    download download Document Transcript

    • Quality Management Plan (QMP) Description Purpose In value-based software engineering (VBSE) and LeanICM, “quality” is defined as the degree of success –critical stakeholders’ satisfaction. As these are generally several project stakeholders, the purpose of quality management (QM) involves balancing their mutual satisfaction along the lines negotiable by the stakeholders in their win-win negotiations. One aspect of quality that is important to developers and clients is development efficiency. This implies that QM functions also need to be lean in avoiding excess overhead work in processing QM traffic. Thus, generating many low-impact concerns that need to be processed about such things as low-impact concerns that need to be processed about such things as English grammar usage to readers, it is better to package as English usage markup of an artifact as a single quality concern, and net to require developers to respond to each marked-up item. A seeming exception to this is the need to turn in the results of quality activities, as these appear not to enhance product value around stakeholder satisfaction. However, analysis of quality data can often lead to significant value- adding project improvements. And, since the faculty is success-critical stakeholders who need the data to make future course improvements, it needs to be done (but not overdone). Quality Focal Point As with everything else VBSE and LeanICM, QM involves balancing multiple conflicting objectives and strategies. One such conflict involves balancing two conflicting QM-related principles: QM-1: Quality is everyone’s business. QM-2: If you want something to happen, make somebody specifically responsible for it. In principle, QM-1 should be sufficient. But on complex projects being done by people with additional responsibilities, it is all too easy for aspects of quality to get below people’s action thresholds. Since quality (stakeholders’ satisfaction) is important, QM-2 ensures that at least one project member is continually monitoring quality and reminding people to bring it back above their action threshold when necessary. Thus, although everyone remains responsible for the quality of their work, the Quality focal Point function has the responsibility of keeping all aspects of stakeholder satisfaction above people’s action thresholds. This should be considered as a constructive stakeholder-advocate function and not as bureaucratic, adversarial “find the guilty” function. Particularly important responsibilities of the Quality focal Point person are defect prevention, detection, and removal; levels of service achievability; thoroughness of plan execution; coordination of changes with affected stakeholders; and coordination of developers and IIV&Ver activities. An additional compatible function is that of being project’s Learning Coordinator.
    • Additional Information 577b Guidelines: For CS 577b, this document should help the members of the project team understand each person’s contribution to quality. Each team has the flexibility to choose their own standards for quality management and should take the initiative in defining additional quality mechanisms as dictated by project requirements. For instance it should include the related trade offs as the degree of testing decreases and reviews increases, the methodology used to control injection and removal of defects etc. It should be clear from the plan that is primarily responsible for the implementation of the various parts of the plan. High-Level Dependencies The Quality Management Plan has high dependencies with System and Software Requirements Definition (SSRD) and Life Cycle Plan (LCP) Completion Criteria This section describes the amount of information to be included and their levels of details required for each phase. Exploration Phase • You will start developing the QMP document after VCR Valuation Phase • Identify the following strategies for the whole project life cycle such as defect prevention strategies, defect detection strategies and defect removal tracking. • Illustrate how to achieve level of service requirements defined in SSRD • Explain how to use plan, standard and software development process to assurance quality of development project • Explain how to coordinate between development team and V&V team • Prepare for Foundations Commitment Review Foundations Phase • Identify the approach on Configuration and change policy • Define the strategy in storing, updating, and managing the project artifacts • Prepare for Development Commitment Review and Rebaselined Development Commitment Review Development Phase • Update the plan as appropriate Sections of the QMP document The followings are the sections for a typical Quality Management Plan document. It can be tailored to fit with your project. If you tailored the structure of this document by adding or removing a section or sub section, you should note in your Supporting Information Document (SID) about the tailoring. The objective of this QMP document is to encourage the team to ensure the quality of the project. Since, we have a very small team, so your quality management plan should not be too big, but plan only what you can do.
    • Purpose Purpose of the document Summarize the purpose and contents of this document with respect to the particular project and stakeholders involved. Status of the document Summarize the major changes of project that affects the quality management approach. For example, discontinuation of team member, introducing a new quality-related management tool to the project, and etc. Quality Management Strategy This document should focus on the projects’ strategic decisions on quality management. There will be separate documents that cover detailed test plans and procedures and peer reviews. The projects’ quality management strategy should follow the Software Quality Opportunity Tree as shown below. A value/risk-based quality “defect” is any product characteristic that reduces the value of the product to its stakeholders. Defects can include missing requirements, poor COTS choices, inconsistent architecture and design specifications, inadequate handing of off-nominal requirements and exceptions, shortfalls in achieving level of service requirements, and lack of traceability among requirements, architecture, design, code and test artifacts. A value-based software quality strategy will reflect the relative priorities of product capabilities and levels of service. It will also reflect the fact that early defect detection and removal is usually much more cost effective than late defect detection and removal
    • Figure 10: Software Quality Opportunity Tree For CS577, projects should focus on strategies for defect prevention, detection and removal and value-risk based defect impact reduction. Working with clients on operational practices for input screening, manual back up, and rapid recovery from failures is also recommended. It is also valuable for the Quality Focal Point to determine root causes of defects and work out improved quality management practices. Defect Prevention Strategies This section should identify the defect prevention strategies that your team is using. This section will help Quality Focal Point person plan and identify the strategy and approach that will prevent possible defect, hence ensure the project’s quality. Candidate strategies include: • People practices • IPT, JAD, win-win , etc
    • • PSP, Cleanroom, Dual development, etc • Manual execution, scenarios, etc • Staffing for dependability • Standard • Requirements, design, code, etc • Interfaces, traceability, etc • Checklists • Languages • Prototyping • Modeling and Simulation • Reuse • Root cause analysis Below is examples of defect prevention strategies, you can use this as a reference and tailor to fit with your project. Table 1: Defect Prevention Strategies Strategy Priority Description Win-Win High The win-win methodology will be used to ensure that all stakeholders' win conditions are met with the final implementation. Incremental High By using the Incremental Commitment Model templates and Commitment guidelines, the artifacts produced should have the correct format Model Standard and substance. Prototyping High Iterative cycles of prototyping will help make sure the client’s user interface expectations are understood early on and incorporated. We will meet with the client regularly to provide demos as features are implemented. Dry run High We will do dry run before every presentation in order to double check the project and to sharpen up the presentation. Code Review High It will be used to enforce standard and to avoid most defect. Database Standard High Since we have to use the same database with Team 1 and 2, to define Database standard is a very important strategy to prevent future defect. Defect Detection Strategies Identify the project’s primary defect detection strategies and priorities. The following tables illustrate candidate levels of application of defect detection tools, reviewing, and testing. Particular consideration should be given to the agile quality practices of test-first, pair programming, and continuous integration. Table 2: Defect Removal Profiles Rating Automated Analysis Peer Reviews Execution Testing and Tools Very Low - Simple complier syntax - No peer review. - No testing. checking. Low - Basic compiler capabilities - Ad-hoc informal walk- - Ad-hoc testing and for static module-level throughs debugging. code analysis, syntax, type-
    • checking. - Minimal preparation, no - Basic text-based debugger. follow-up Nominal - Some compilers extensions - Well-defined sequence of - Basic unit test, integration for static module and inter- preparation, review, test, system test process. module level code analysis, minimal follow-up. - Basic test data syntax, type-checking. management, problem - Informal review roles and tracking support. - Basic requirements and procedures. design consistency, - Test criteria based on traceability checking. checklists. High - Intermediate-level module - Formal review roles with - Well-defined test sequence and inter-module code all participants well-trained tailored to organization syntax and semantic and procedures applied to (acceptance/ alpha/ beta/ analysis. all products using basic flight/ etc.) test. checklist, follow up. - Basic test coverage tools, - Simple requirements/ test support system. design view consistency - Basic test process checking. management. Very High - More elaborate - Formal review roles with - More advanced test tools, requirements/ design view all participants well-trained test data preparation, basic consistency checking. and procedures applied to test oracles support, all product artifacts and distributed monitoring and - Basic distributed- changes (formal change analysis, assertion processing and temporal control boards). checking. analysis, model checking, - Basic review checklists, symbolic execution root cause analysis. - Metrics-based test process - Formal follow-up. management. - Use of historical data on inspection rate, preparation rate, fault density. Extra High - Formalized* specification - Formal review roles and - Highly advanced tools for and verification. procedures for fixes, test oracles, distributed - Advanced distributed change control. monitoring and analysis, processing and temporal - Extensive review assertion checking analysis, model checking. checklists, root cause - Integration of automated Symbolic execution. analysis. analysis and test tools. - Continuous review process - Consistency-checkable pre- improvement. - Model-based test process condition and post- management. conditions, but not - User/Customer mathematical theorems involvement, Statistical Process Control Table 3: Software Defect Detection Automated Analysis Reviewing Testing - Completeness checking - Peer review, inspections - Requirements and design - Consistency checking - Architecture Review board - Structure - Views, interface, behavior, pre/ - Operational profile post conditions - Pair programming - Usage (Alpha/ Beta) - Traceability checking - Regression - Value/ risk – based - Compliance checking- Models, - Test automation
    • assertions, standards. Automated Analysis In this section, describe which kinds of automated analysis technique that your team uses in defect detection, priority level of each technique and how do you use it. You can use the techniques described in the table above and tailor to fit with your team. People Review In this section, describe which kinds of people review technique that your team uses in defect detection, priority level of each technique and how do you use it. You can use the techniques described in the table above and tailor to fit with your team. Execution Testing In this section, describe which kinds of execution testing technique that your team uses in defect detection, priority level of each technique and how do you use it. You can use the techniques described in the table above and tailor to fit with your team. Defect Removal Tracking This section should state the methods to be used for Problem, Issue and Defect reporting and tracking. • Identify the system for receiving reports from the team or IIV&Vers or quality focal point personnel. • Identify how the reports will be monitored and by whom, including frequency of analysis, and weekly summary report generation. Level of Service Achievement Monitoring The Quality Focal Point or his/her designate needs to monitor progress towards slowing architectural achievability of level of service requirements in Feasibility Evidence Description (FEP), and progress towards actual achievability of level of service requirements in integration and testing. Identify roles, responsibilities, and processes for these functions. Process Assurance The objective of software quality management is to ensure the delivery of a high-quality software product. This section should elaborate on Level of Services, and roles & responsibilities of team members in achieving them. Traditional quality assurance functions listed below can be used and tailored as per project. • Auditing the project's compliance with its plans, policies, and procedures; • Monitoring the performance of reviews and tests; • Monitoring corrective actions taken to eliminate reported quality related deficiencies
    • Due to the significant schedule constraints, no explicit process assurance related activities are done by the teams. The instructional staff does provide some process assurance in terms of scheduling deliverables, tasks and assignments IIV&V Coordination Identify roles, responsibilities, and processes for timely delivery of drafts and artifacts to IIV&Vers, and rapid response to IIV&Vers concerns. Configuration and Change Management During the project various versions of documents and software product are created. In order to avoid costly re-work, hidden defects, and deliver a software system consistent with the stage of development and traceable to the needs of the customer, configuration management is needed. 577 Guidelines: Up to Development Commitment Review time, it will be sufficient to identify: • Which items will be baselined when • How changes to the baseline will be coordinated with the client (e.g., meeting for major changes, email for moderate changes, none for trivial changes) • How outstanding problem reports will be tracked • Who will be the custodian of the master baselined versions, and how he/she will preserve the integrity and recoverability of the master versions • Who will be the Configuration Manager and how will he/she ensure that a version control is maintained. Product Element Identification The product elements to be identified should include the project deliverables enumerated in Life Cycle plan document, as appropriate, and any other elements that stakeholders may consider important (e.g. operational procedures, project critiques). Each product element should have an owner and a unique identifier. Each individual sub element of the OCD, SSRD, SSAD, and delivered software package should have a unique identifier, enabling traceability relations to be established among these sub elements. Those product elements to be placed under baseline configuration management (CM) should be identified, along with the project milestones at which they enter the CM process. You should describe the identification system used, in particular the naming convention for various versions of all the artifacts. In addition, describe the priority level of each document in each phase, so it could help the development team to identify which document that you should pay more attention to in each period of time. It is sufficient to mention which product elements will be considered as strong baselines along which project milestone. Note: Strong baselines are those changes that are suggested by the client that if made could affect the design and the system significantly. The details of these changes can be viewed in the artifacts version history or the configuration history and the minutes of the meetings between the team and the client. These can also be viewed from the review forms that clients use to log multiple concerns
    • Configuration Items and Rationale Each project churns out a number of documents, but not all are required for continued development and system maintenance. Provide a list of configuration item (includes both documents and software), rationale behind the selection of the item, volatility and impact severity. Artifacts suited for configuration control include plans, specifications, designs, code, tests, manuals, object code, defect reports and change requests. The following table is an example of how you describe the operational concept description and its rationale, volatility, and impact severity. Table 4: Rationale of Operational Concept Description Configuration Description Rationale Volatility Impact Severity Item OCD Operational Concept Major artifact for Volatile during Very severe - if the Description overall system's Exploration and overall system's shared vision among Valuation, but vision changes then stakeholders should become the requirements, more stable during design, code, etc. Foundations, could all be development and incorrect. operation. Configuration Change Management Provide a flow chart indicating the sequence of tasks and decisions involved in submitting, analyzing, approving, and implementing proposed changes to software baseline items. Provide the associated change control forms and procedures, and a chart indicating what level of management is responsible for approving the various classes of proposed changes. Please note that in CSCI577ab, most of request changes are from the Architecture Review Board (ARB), so your flow chart should reflect the reality. Project Library Management Describe how your team is going to manage all your project files, organizational responsibilities, library contents, services provided, operational procedures for general usage, storage and release of master copies, security, backup and recovery, library facilities and support services, and staffing and resource requirements. Provide Links to Project Library 577 Guidelines: The weak/informal baselined project elements along different project milestones, if any, need to be identified here. Also any of the other project elements that are not configured but need to be stored are to be mentioned in this section.
    • Note: The weaker less defined baselines are those that can be changed by the team members independently. The informal baselines, are the changes that are suggested by the ARB, peer-reviews etc that are discussed by the team or informally with the client. The details of these changes can be viewed in the artifacts version history and change summary or the configuration history. Resources and Personnel Identify the software and human resources required to perform configuration management (CM) functions, Quality Focal Point activities or verification and validation. Designate specific project personnel to perform the tasks of CM and main project librarian or archivist. Tools Each of the tasks mentioned above may necessitate the use of tools for efficiency and effectiveness. If you are using any tool, list the tool and how are you going to use it to support your project.