Subjective Q&A - 16 to 20
16. Security and Privacy of customer information are very important for e-commerce projects. Quality principles expect that management policies are a pre-requisite for good work process. Draft a policy for e-commerce security and privacy.
Or
Write a Security and Privacy policy for e-securities projects for your organization.Security—relates to the means (process and technology) by which an entity protects the privacy of any sort of data/information. Security measures keep information secured, and decrease the means of tampering, destruction, or inappropriate access.
Privacy—refers to the individual’s right to keep certain information private, unless that information will be used or disclosed with his or her permission. (more like the rights of individuals or Consent/Authorization Issues/Procedures/Processes )
Security is more related to the availability of the information and policy for that should address the same with proper checks and balances taking care of that while privacy is some thing which ensures right information to the right person.
SECURITY & PRIVACY POLICY
- XYZ Company protocols adhere to the latest standards; your information is encrypted during your e-commerce sessions with XYZ Company.
- We do not store credit card or purchasing card information on our web server, and do require a re-entry of the credit card number for each purchase. This is an added level of security, and helpful in laboratories or purchasing departments with multiple users of a central computer.
- Security audits are conducted by third parties in order to further ensure security.
This Policy relates only to our online information collection and use practices.
In short, we do the following:
- We only collect personally identifiable information that you voluntarily and knowingly provide us.
- We use the information that you provide us only for the purpose(s) for which you specifically provided it or for specific additional purposes for which we receive your prior consent.
- We do not share any information you provide us with anyone outside of XYZ Corporation, except for suppliers who assist us in maintaining and managing the activities on our site. These suppliers are legally obligated to maintain the confidentiality of any information we provide them, including your information.
- We may use a technology called “cookies” to enhance your experience on our site.
- We employ appropriate security measures to protect the loss, misuse and alteration of any information you provide us.
- We provide you with choice and control over the collection and use of any personally identifiable information that you provide us on-line, and a means for updating, correcting or removing this information .
Like many companies, we use a technology called “cookies” to enhance your experience on our site. We use cookies to store visitors preferences, record session information, such as items that consumers add to their shopping cart, record past activity at a site in order to provide better service when visitors return to our site , customize Web page content based on visitors' browser type or other information that the visitor sends.
The cookies XYZ Company uses do not contain any personally identifiable information and can not profile your system or collect information from your hard drive. You are not identified by name or e-mail address, just by a unique string of numbers that we assign the first time you come to our site.
Security
We employ appropriate security measures to protect the loss, misuse and alteration of the information under our control. For our e-commerce activities, we employ Secure Sockets Layer (SSL) software, which encrypts information you input, as an additional security measure. However, as no on-line data transmission can be guaranteed to be totally secure, we (like all web sites) cannot warrant or guarantee 100% security of any information you transmit to us at our web site.
Links To Other Sites
XYZ Company does not guarantee the content of other sites for which we provide a link.
17. Is it possible to implement too much quality control in an Organisation? Yes or No? Explain.
Implementation of too much Quality Control may have certain impediments to start with-
- First of all, it has to be driven top – down by the management
- Staff may not like too many QC points
- Staff may resist/oppose this as they may feel it will hinder the faster progress of work because of more check points
But, the term “TOO MUCH” here may depend upon many factors which may be prevailing in the organization. In cases where there are chaos all around, where there are too many complaints frequently from the customers, no. of QUALITY CONTROL points may be increased. But as the CBOK says, one of the quality management philosophy objectives is to continually improve process capability by reducing variation and rework. With this strategy quality is built into the products rather than tested at the end. As standards and Do procedures are perfected, the need for extensive quality control is reduced.
Quality control procedures are considered appraisal costs. They add to the overall cost, increase the effort required, and increase the cycle time for building products and delivering services. Where standards and Do procedures are not perfected, quality control is necessary in a process to catch defects before they affect the outcome of downstream processes. Appraisal costs are part of the Cost of Quality, which is covered in Knowledge Domain 1. The challenge is to install the appropriate amount and types of controls to minimize cost, effort, and cycle time; and to minimize the risk that defects will go undetected and "leak" into other processes.
Quality must be built-in a product and not tested in.
Too much Quality Control is not required if
- Standards are developed properly
- Processes are well defined
- Quality controls are installed at the logical points in the process to minimize the defects. Logical points are determined based on the following
- Risk severity
- Cost, effort and cycle time impact
- Availability of appropriate resources/people
- Strength of control method (Automatic, Self-Checking, Peer review, Third Party audit, Supervisory)
- Impact on overall culture
(from Hagan 1986) COQ Categories
I. Prevention Costs
- Requirements
- 1. Marketing research for customer/user quality needs
- 2. Customer/user quality surveys
- 3. Product quality risk analysis
- 4. Prototyping for customer review
- 5. User requirements/specification reviews/inspections
- Project
- 1. Project quality planning
- 2. Project process validation
- 3. Quality assessment of development platform and tools
- 4. Platform and tools development for quality
- 5. Developer quality training
- 6. Quality metrics data collection
- 7. Design for quality: software component reuse
- 8. Formal inspections / peer reviews
- 9. Project configuration management
- 10. Supplier capability assessment
- Reuse library
- 1. Salaries
- 2. Expenses
- 3. Training
- 4. Platform and tools
- Configuration management administration
- 1. Salaries
- 2. Expenses
- 3. Training
- 4. Platform and tools
- SQA administration
- 1. SQA salaries
- 2. SQA expenses
- 3. Software process and standards definition and publication
- 4. Metrology: data maintenance, analysis, and reporting
- 5. SQA program planning
- 6. SQA performance reporting
- 7. SQA education/training
- 8. Process improvement
- 9. SQA process compliance audits
- Supplied product testing
- Project appraisal costs
- 1. Verification and validation activities
- 2. Testing: planning, platforms, setup, test data generation, test execution and logging, reporting, test data evaluation
- 3. Product quality audits
- External appraisals
- 1. Process maturity evaluation
- 2. Field performance trials
- 3. Special product evaluations
- Product design defect costs
- 1. Causal analysis and reporting
- 2. Design corrective action
- 3. Rework and retest due to design corrective action
- 4. Work products wasted due to design changes
- Purchased product defect cost
- 1. Defect analysis cost
- 2. Cost of obtaining product fix
- 3. Cost of defect work-arounds
- 4. Rework
- Implementation defect costs
- 1. Defect measurement and reporting
- 2. Defect fixing
- 3. Causal analysis and reporting
- 4. Project process corrective action
- 5. Fix inspection
- 6. Retest and integration
- Technical support for responding to defect complaints
- Product returned due to defect
- Maintenance and release due to defects
- Defect notification costs
- Upgrade due to defect
- Service agreement claims (warranty expense reports)
- Liability claims (insurance and legal reports)
- Penalties (product contract reports)
- Costs to maintain customer/user goodwill due to dissatisfaction (sales reports)
- Lost sales due to quality problems (field salesperson reports)
Move towards single supplier for any one item, on a long-term relationship of loyalty and trust. To be competitive it is very important to have lower costs. We have to minimize total cost; not only the price. Remember that defective units are cost; delay in delivery is cost, excessive inventory is cost, etc. To minimize total cost long-term relationship with suppliers is really important. If you as a customer help your supplier to develop, to improve the quality, you will receive better products so you will win and your supplier too.
Deming favors the practice of working with a single supplier, where feasible, to reduce variability of incoming materials, and states that this practice should be built on a long-term relationship of trust and understanding between supplier and purchaser. In this way, suppliers can produce materials that do a better job of fulfilling the needs of the organization. To maintain long-term contracts, suppliers will be more likely to improve their own processes to provide better products or services.
Effective Subcontract Management and Oversight is a team effort and is critical for ensuring and/or improving subcontractor performance. To improve Subcontractors' Performance –
- • Perform daily walkdown of subcontractor work activities
- • Perform joint performance audits with Sub Contract Coordinator and subcontractor
- • Ensures compliance with subcontract requirements
- • Foster implementation of benchmarked programs
By comparing current performance against other contractors and the rest of the industry in all relevant areas, we can determine areas where training is needed and continuously improve business processes. We can also benchmark our subcontractor's performance across different projects and against other subcontractors and use the findings to create an effective model for predicting and preventing claims.)
- • Review subcontractor generated data
- • Support Sub Contract Coordinator in conducting subcontractor investigations
- • Provides lessons learned information to subcontractor
- • Interfaces with all Operational Managers to support Project initiatives
- • Coach subcontractor in developing and implementing corrective actions resulting from audits and self assessments
- • Assure subcontractor submits benchmark Program results
- • Identify and evaluate violations
- • Prepare notices to subcontractor
- • Sign / approve violation notices to subcontractors
- • Transmit notices to subcontractors
- • Approve subcontractor corrective actions and/or provide direction
- • Monitor close-out of quality issues
- • Chair progress review meetings
- • Assess subcontractor performance (monthly subcontractor scorecard)
Though LOC metric is easy to understand and widely used, there are certain intricacies involved which can mislead with wrong interpretations especially during the important calculations of defect density and Productivity. Now a days, Function Point metrics are getting more popular because of their normalized calculations, though it is initially difficult to understand. Both the metrics are discussed in detail here:
Lines Of Code (LOC)
The LOC metric is anything but simple. The major problem comes from the ambiguity of the operational definition, the actual counting. In the early days of Assembler programming, in which one physical line was the same as one instruction, LOC definition was clear. With the availability of high level languages the one to one correspondence broke down. Differences between physical lines and instruction statements (or logical lines of code) and differences among languages contribute to the huge variations in counting LOCs. Even within the same language, the methods and algorithms used by different counting tools can cause significant differences in the final counts. Several variations that are significant are –
• Count only executable lines
• Count executable lines + data defns
• Count executable lines + data defns + comments
• Count executable lines + data defns + comments + job control language
• Count lines as physical lines on an input screen
• Count lines as terminated by logical delimiters
When straight LOC count data is used without normalizing, size & defect rate comparisons across languages are often invalid. For productivity, the problems with LOC are more severe. A Basic problem is that the amt of LOC in a program is negatively correlated with design efficiency. Efficient design provides the functionality with lower implementation effort and fewer LOCs. In addition to the level of languages issue, LOC data do not reflect non-coding work such as the creation of requirements, specifications & user manuals. Therefore, LOC do not reflect the true productivity in this case.
Function Points
A Function can be defined as a collection of executable statements that perform a certain task, together with declarations of the formal parameters and local variables manipulated by those statements. Here, if defects per unit of functions is low, then the software should have better quality even though the defects per KLOC value could be higher – when the functions were implemented by fewer lines of code. However, measuring functions is theoretically promising but realistically very difficult.
Here, first the Function Count (FC) has to be made using the following five components with their respective weighting factors which in turn are decided by certain guidelines and standards. The five components and their usual weighting factors according to their complexities are given below (For e.g. for the External O/P Component, if the number of data element types is 20 or more and the no. of files types referened is 2 or more -> then complexity is HIGH. iIf the number of data element types is 5 or fewer and the no. of files types referened is 2 or 3 -> then complexity is LOW):
1. External I/P: Low complexity:3, Medium cmplxity:4, High cmplxity:6,
2. External O/P: Low complexity:4, Medium cmplxity:5, High cmplxity:7,
3. Logical I/P: Low complexity:7, Medium cmplxity:10, High cmplxity:15,
4. Logical O/P: Low complexity:5, Medium cmplxity:7, High cmplxity:10,
5. External Inquiry: Low complexity:3, Medium cmplxity:4, High cmplxity:6,
Then -> FC= {∑i=1to5[∑j=1to3(Wij*Xij)]}
Where Wij is the weighting factors of the five components by complexity level (low, med, high)
Xij are the numbers of each component in the application.
The second step involves a scale from 0 to 5 to assess the impact of 14 general system characteristics in terms of their likely effect on the application. The 14 characteristics are:
- Data communications
- Distributed functions
- Performance
- Heavily used configuration
- Transaction rate
- Online data entry
- Enduser efficiency
- Online update
- Cmplx processing
- Resuability
- Installation use
- Operational use
- Multiple sites
- Facilitation of change
Value Adjustment Factor (VAF) = {0.65+0.01*[∑i=1to14(Ci)]}
Where Ci is the score for general system characteristic i. Finally, the no. of FPs are calculated by:
FP = FC*VAF

1 Comments:
Hi Prasanna..
This is definitely of help to me. You have taken so much effort to put in so much stuff. Treat assured when I pass CSQA
Post a Comment
<< Home