Vinod H Bachelor of Computer Application Semester - 5 BC0054 Software Project Management & Quality AssuranceFall 2012 Assignment Set 2 Roll No: 521110833 Center Code: 03011

2

BC0054 Software Project Management & Quality Assurance Set - 2 1. Explain the software configuration management process in detail. Change is inevitable when computer software is built. And change increases the level of confusion among software engineers who are working on a project. Confusion arises when changes are not analyzed before they are made, recorded before they are implemented, reported to those with a need to know, or controlled in a manner that will improve quality and reduce error. Babich [BAB86] discusses this when he states: Software configuration management (SCM) is an umbrella activity that is applied throughout the software process. Because change can occur at any time, SCM (software configuration management) activities are developed to (1) Identify change (2) Control change (3) Ensure that change is being properly implemented (4) Report changes to others who may have an interest. It is important to make a clear distinction between software support and software configuration management. Support is a set of software engineering activities that occur after software has been delivered to the customer. Software configuration management (SCM) is a set of activities to control change by identifying the products that are likely to change, establish relationships among them, defining mechanisms for managing different versions of these work products, controlling the changes imposed and auditing and reporting on the changes made. In short SCM is a methodology to control and manage a software development project. Because many work products are produced when software is built, each must be uniquely identified. Once this is accomplished, mechanisms for version and change control can be established. To ensure that quality is maintained as changes are made, the process is audited and to ensure that those with a need to know are informed about changes, reporting is conducted. A primary goal of software engineering is to improve the ease with which changes can be accommodated and reduce the amount of effort expended when changes must be made. The output of the software process is information that may be divided into three broad categories (1) Computer programs (both source level and executable forms) (2) Documents that describe the computer programs (targeted at both technical practitioners and users) (3) Data (contained within the program or external to it) These items comprise all information produced as part of the software process are collectively called a software configuration.

3

BC0054 Software Project Management & Quality Assurance Set - 2 As the software process progresses, the number of software configuration items (SCIs) grows rapidly. A system specification spawns a software project plan and the software requirements specification (as well as hardware related documents). These in turn spawn other documents to create a hierarchy of information. Change may occur at any time, for any reason. In (the First Law of System Engineering [BER80] states: "No matter where you are in system life cycle, the system will change, and the desire to change it will pen throughout the life cycle." There are four fundamental sources of change. New business or market conditions dictate changes in product requirements or business rules. New customer needs demand modification of data produced by informal systems, Functionality delivered by products. Reorganization or business growth/downsizing causes changes in project priorities Changes in software engineering team structure. Budgetary or scheduling constraints cause a redefinition of the system or product.

Software configuration management is a set of activities that have been developed to manage change throughout the life cycle of computer software. SCM can be viewed as a software quality assurance activity that is applied throughout the software process. In the sections that follow, we examine major SCM tasks and important concepts that help us to manage change.

2. What is the software risk? Explain various factors for risks. Risk is the possibility of loss. It is a function of both the probability of an adverse event occurring and its impact; the impact manifests itself in a combination of financial loss, time delay, and loss of performance. A risk is the precursor to a problem; the probability that, at any given point in the software life cycle, the predicted goals cannot be achieved within available resources. Risk cannot be eliminated from a software project, but it can be managed. Risk management is critical to the success of any software effort and is a strategic aspect of all software projects. Project risks: Project risks threaten the projects plans. It is likely that project risks will slip and that costs will increase. Projects risks identify potential budgetary, schedule, resource, customer and requirements problems and their impact on software projects. Technical risks: Technical risks threaten the quality and timeliness of the software to be produced. Business risks: Business risks threaten the viability of the software to be built Risk management and project execution. For any project, any condition, situation or event that can occur would jeopardize the success of the project constitutes a risk. Identifying a risk is therefore an exercise in envisioning that can go wrong. The methods that can aid for risk identifications include, (1) Check list of possible risks. (2) Surveys

4 (3) Meetings (4) Brainstorming (5) Review plans.

BC0054 Software Project Management & Quality Assurance Set - 2

Check list of most commonly occurring risks are probably the most common tool for risk identification. Check list details are as follows: Risk identification checklist, Product size. Risks associated with the overall size of the software to be built or modified. Business impact. Risks associated with constraints imposed by the management. Process identification Risks associated with the degree with which software process has been defined and is followed by the development organization. Technology to be used. Risks associated with the complexity of the system to be built and the newness of the technology that is packaged by the system

Project managers use their past experience and past project database to identify potential risks. Assessing the overall project risk Some of the questions found from the risk data obtained by surveying experienced software project managers, Is project scope stable? Does a project requirement stable? Is the number of employees are sufficient to do the job. Have top managers and customer mangers formally committed to support the project? Have customers are involved in satisfying the customer requirements.

If any of these questions is answered negatively, mitigation, monitoring and management steps should be instituted without fail. Risk components are defined as follows, Performance risk: The degree of uncertainty that the product will meet its requirements and be fit for its intended use. Cost risks: The degree of uncertainty that the project budget will be maintained. Support risks: The degree of uncertainty that the result software will be easy to correct, adapt and enhance. Schedule risks: The degree of uncertainty that the project schedule will be maintained and that the product will be delivered on time.

The identified risks for a project merely give the possible events that can hinder it from meeting the goal. The consequences of various risks, however, may differ. So before we proceed with management risks, project managers prioritize them so that management energies can be focused on high risks.

5

BC0054 Software Project Management & Quality Assurance Set - 2 Prioritization requires analyzing the possible side effects of the risk event in case it actually occurs. Based on the possible consequences and the probability of the risks event occurring, you can compute the risk exposure, which you can then use for prioritizing risks. In risk prioritization, each identified risk is evaluated and assigned values for the following elements: The probability that the risk condition will actually occur The impact if the risk condition does occur The risk exposure

Multiplying the risk probability by the impact would yield risk exposure, which is then compared against all other risk exposures to determine which risk will be given priority for risk mitigation. Since exposure is a relative measurement based on the numeric value assigned to risk probability and impact, consistency in assigning the probability and impact values is critical. A prioritized risks list that ranks risks by their exposure value determines the order in which risks will be addressed in risk mitigation and contingency planning. 3. What is risk prioritization? Explain risk prioritization techniques Risk Prioritization Methods The objective of Risk Prioritization is to prioritize the identified risks for mitigation. Both qualitative and quantitative methods can be used to categorize the risks as to their relative severity and potential impact on the project. To effectively compare identified risks, and to provide a proactive perspective, the risk prioritization method should consider the following factors: a) The probability of the risk occurring, b) The consequence of the risk, and c) The cost and resources required to mitigate the risk. The Risk Factor Product prioritization methodology consists of identifying project risks, assessing the probability of each risk's occurrence and the consequence of each risk's occurrence, and prioritization of the identified risks by calculating the Risk Factor (RF) Product for each risk, and mitigation of the highest risks to resolution. Once the probability of failure (Pf) and consequence of failure (Cf) factors have been determined, they can be plotted on an ISO risk contour chart to graphically portray their relative importance and impact on the project as demonstrated in the figure, below. Prioritization requires analyzing the possible side effects of the risk event in case it actually occurs. Based on the possible consequences and the probability of the risks event occurring, you can compute the risk exposure, which you can then use for prioritizing risks. Note that the location of Risk Items on the ISO risk Contour Chart (shown below) provides insight as to the most cost effective manner by which they may be mitigated. Risk A is best mitigated by a strategy that reduces the criticality of the risks occurrence, while Risk B is best mitigated by a strategy that reduces the probability of the risks occurrence.

6

BC0054 Software Project Management & Quality Assurance Set - 2

4. What are issues involved in software quality assurance? Software developers continue to believe that software quality is something you begin to worry about after code has been generated. Nothing could be further from the truth. Software quality assurance (SQA) is an umbrella activity that is applied throughout the software process. SQA encompasses (1) a quality management approach, (2) effective software engineering technology (methods and tools), (3) formal technical reviews that are applied throughout the software process, (4) a multi-tiered testing strategy, (5) control of software documentation and the changes made to it, (6) a procedure to ensure compliance with software development standards (when applicable), and (7) measurement and reporting mechanisms. Software quality assurance is related to the practice of quality assurance in product manufacturing. There are, however, some notable differences between software and a manufactured product. These differences all stem from the fact that the manufactured product is physical and can be seen whereas the software product is not visible. Therefore its function, benefit and costs are not as easily measured SQA is complicated by the complex nature of software quality an attribute of computer programs that is defined as "conformance to explicitly and implicitly specified requirements." But when considered more generally, software quality encompasses many different product and process factors and related metrics. To properly conduct software quality assurance, data about the software engineering process should be collected, evaluated, and disseminated. Statistical SQA helps to improve the quality of the product and the software process itself. Software reliability models extend measurements, enabling collected defect data to be extrapolated into projected failure rates and reliability predictions. Software development, like any complex development activity, is a process full of risks. The risks are both technical and programmatic. That is, risks that the software will not perform as intended or will be too difficult to operate, modify, or maintain are technical risks, while risks that the project will overrun cost or schedule are programmatic risks. The goal of software assurance is to reduce these risks.

7

BC0054 Software Project Management & Quality Assurance Set - 2 For example, coding standards are set to specify a minimum quality of code. If no standards are set, there exists some risk that the code will not come up to a minimum usable standard, and that the code will require rework. If standards are set but there is no explicit process for assuring that all code meets the standards, then there is some risk that some coders will produce code that does not meet the standards. The assurance process involved is quality assurance, and to have no quality assurance activity is to increase the risk that unacceptable code will be produced. Similarly, the lack of a nonconformance reporting and corrective action system increases the risk that problems in the software will be forgotten and not corrected, or that important problems will not get priority attention. The point is that software assurance activities can help to reduce risks.

5. What is SQA plan? Briefly explain it. The SQA Plan provides a road map for instituting software quality assurance. Developed by the SQA group, the plan serves as a template for SQA activities that are instituted for each software project. The purpose of creating a software assurance plan is to document/specifies the conduct of the activities that will comprise software assurance for a specific project. A standard for SQA plans has been recommended by the IEEE [IEE94], Initial sections describe the purpose and scope of the document and indicate those software process activities that are covered by quality assurance. All documents noted in the SQA Plan are listed and all applicable standards are noted. The management section of the plan describes SQA's place in the organizational structure, SQA tasks and activities and their placement throughout the software process, and the organizational roles and responsibilities relative to product quality. Effective assurance programs require planning and follow through. The plan identifies,

Evaluations to be performed Audits and reviews to be performed Standards those are applicable to the project. Procedures for error reporting and tracking Documents to be produced by SQA group

The SQA plan also identifies the tools and methods support SQA activities and tasks. It cannot simply evolve along with the project. Adequate assurance planning ensures that the assurance activities are focused on the quality requirements and risks associated with the specific project.

8

BC0054 Software Project Management & Quality Assurance Set - 2 6. What is version control? Explain how it helps to reduce too many changes. Version Control combines procedures and tools to manage different versions of c figuration objects that are created during the software process. Clam [CL describes version control in the context of SCM: Configuration management allows a user to specify alternative configurations of the software system through the selection of appropriate versions. This is supported by associating attributes with each software version, and then allowing a configuration to be specified [and constructed] by describing the set of desired attributes. These "attributes" mentioned can be as simple as a specific version number the attached to each object or as complex as a string of Boolean variables (switches) indicate specific types of functional changes that have been applied to the system. One representation of the different versions of a system is the evolution graph. Each node on the graph is an aggregate object, that is, a complete version of the software. Each version of the software may be composed of different variants. To construct the appropriate variant of a given version of a program, each entity can be assigned an "attribute-tuple" a list of features that will define whether the entity should be used when a particular variant of a software version is to be constructed. One or more attributes is assigned for each variant. For example, a color attribute could be used to define which entity should be included when color displays are to be supported. Another way to conceptualize the relationship between entities, variants and versions (revisions) is to represent 'them as an object pool [REI89]. The relationship between configuration objects and entities, variants and versions can be represented in a three-dimensional space. An entity is composed of a collection of objects at the same revision level. A variant is a different collection of objects at the same revision level and therefore coexists in parallel with other variants. A new version is defined when major changes are made to one or more objects. A number of different automated approaches to version control have been proposed over the past decade. The primary difference in approaches is the sophistication of the attributes that are used to construct specific versions and variants of a system and the mechanics of the process for construction.