Unit 4 Process Quality Management Human Resources Quality

Unit 4: Process Quality Management, Human Resources, Quality Assurance This unit explores how the software development process can be made predictable in terms of costs, timescale and quality of product.

Section 1: Overview of process quality The need to control the process l how we should organize our software development team and its program of work so that we do end up with a high-quality product developed to cost and timescale. l Developing software needs good management; Not Easy

Project management l Most of the important jobs a project manager must take: • planning the project schedule • finding the right people and assigning them to tasks; • making sure the team is properly trained with proper tools and work environment; • keeping project on schedule and taking action if it slips; • liaising with the customer (could be another organization); • analyzing and managing the risks; • making sure lessons learned on other projects feed into this project making sure this project’s lessons are passed on to others. l

People management l people in the development of software is important. l Software bugs are most likely from some person To rectify: improve people management of project. People management must be organizationwide management and leadership is an important part of people management

Matrix organization is a popular way of organizing a software development company, or division to accommodate people management. § People (human resources) Classified according to function § Human–computer interaction § Databases § distributed computing • • • New projects get started by business manager Functions are assigned to projects(shown by small circles on the intersections of the project and function lines. ) Each circle represents one or more people.

The matrix method allows people to be managed appropriately at an organizational level, but they also need to be managed appropriately at project level. .

Each project manager must decide how to organize project team so that the team members can most effectively collaborate to develop the software. 2 common examples of team organization a) Task-oriented team organization l The first example is separation by task. – Team is divided up into subteams, – each subteam responsible for a different software development activity

û û Based on the waterfall model of software development; each subteam may develop its own culture and may lose sight of the fact that they are part of a larger project b) Subsystem-oriented team organization • Arrange the subteams by subsyste • Assumes the breakdown into subsystems was done During analysis: Each subteam undertakes the full sequence of software development activities, and has to negotiate with other subteams about interfaces between subsystems.

l Supports parallel development: – subteams can work independently – subteams must coordinate their work û There is a danger that each subteam will develop its own ways of working, endanger the integrity of project

Quality management l Quality Management System (QMS) is total quality management (TQM), which has many good ideas, but not proved a lasting success l Takes a customer view of quality l In TQM, failure is not acceptable at any stage of a quality chain. l A quality chain is a succession of stages all of which are responsible in part for the final quality delivered to the customer. Configuration management l Solves the problem of managing different versions of items

Section 2: Project Management – process of planning a project – estimating the work content – assigning that work to people and scheduling when it will happen – monitoring the progress of that work and taking corrective action Risk analysis and risk management l No software project is risk-free, key activity for a project manager is identifying and managing risks.

• Project risks: risks directly associated with management of the project (e. g. scheduling, personnel, resources) • Technical risks: risks concerned with the development and technical aspects (e. g. design, implementation) • Business risks: risks that can negatively affect on the project but which derive from the client and user environments. (e. g. changes in policy in the client’s department)

l Risk avoidance: often the best strategy — – prevent the risk happening in the first place. – Example: ‘My staff are not fully up to speed with that new visual programming environment for Java, so we’ll use C++ instead and traditional tools, with which they are familiar. ’ – May introduce new risk!

l Risk retention – If the risk is seen as low probability and low cost, risk is unlikely to occur Accept the risk Strategy: if the costs of avoiding the risk were significantly higher than the costs of the risk event occurring.

Risk reduction commonest strategy l It is unlikely that the project manager will be able to eliminate risk entirely, but controls and counter measures can be put in place to reduce the likelihood of a risk and to reduce its impact Risk transfer l The costs resulting from an occurrence of the risk event are passed on to a third party. e. g. taking out an insurance policy.

Estimation predict the required resources and time of a project, and then update this as we learn more l System size: measured initially by the number of functions, the amount of data + number of users + number of lines of code (KLOC + volume of data) l System complexity often subjective measure – relates to the interdependencies between elements of the system. complexity depends on the type of system.

Steps in the estimation method: 1. Estimate the system size, using what you know. 2. Adjust the size to take account of the system complexity and various other ‘cost drivers’ such as the experience of the software engineers. 3. Convert the estimated LOC or into effort required. 4. Estimate optimal time to complete development. 5. Estimate other properties of the software, such as expected defect rate and quality. l – Estimates can be wrong. – Experienced project managers know and accept that their initial estimates will often be way off. – Estimates must be revised on a regular basis

Estimation methods: Estimation by analogy: If similar to software we have built before, then use previous experience l Estimation by work breakdown: work is broken down into smaller chunks & estimated by analogy. l Function point analysis(FPA): Technique for estimating the size and complexity of a software project, a measure of how much effort is required to develop the software. l

l l Fu is the count of the externally visible use cases that is connected to an actor outside the system boundary counts as an element of functionality. Fc every class in the class model of requirements counts as an element of stored data FP = Fu × Wu + Fc × Wc Wu and Wc are adjustment factors depending on personnel judgment of the complexity of the use cases and classes. Actual weights are Usually in the range 4 to 7 for use cases, and 7 to 15 for classes. - common practice to adjust the FP value for the complexity of the actual system: Where the Fi are fourteen factors, each with an (integer) 0: no influence 5: essential

Before converting function points into effort, first convert them to lines of code for the particular language being used (using Table 2. 1, p. 19). COCOMO(COnstructive COst Model) Given an estimate in KLOCs use COCOMO to find the effort COCOMO’s formula for effort E in terms of code size is(measured in person-months) a is the nominal productivity, in person-months, to produce one thousand lines of code (1 KLOC) b determines the degree of diseconomy of scale (if it is greater than 1) or economy of scale (if it is less than 1).

l COCOMO’s formula for optimal project duration (in months) in terms of effort l c is the basic duration, in months, person-month d gives a measure of the non-linearity, typically d should be less than 1. The simplest form of COCOMO 81, known as Basic COCOMO, recognizes 3 classes of software project: l l – Organic: relatively small, simple projects; – Semidetached: intermediate projects in size & complexity – embedded — complex software projects(e. g. Air flightcontrol)

Work breakdown and scheduling l Look at the distribution of effort throughout the software development process: • project planning and management, 2 to 3 per cent; • requirements analysis, 10 to 25 per cent; • design, 20 to 25 per cent; • coding, 15 to 20 per cent; • testing, integration and debugging, 30 to 40 per cent. resource balancing scheduled in a sequence that honors their interdependencies and keeps people busy without overworking

l Project plan representation • PERT charts: Activities as boxes with lines indicating interdependencies and flow of critical information Emphasize interdependencies • Gantt charts: Horizontal direction represents time and the vertical direction represents activities, Emphasize times at which things happen.

Monitoring(tracking) : Progress and replanning and resources to meet new circumstances Time-boxing: Project arranged to deliver thing of use to the customer every three to six months The project is planned as sequence of timeboxes in a short time period (less scope to go wrong) Tools Used for: l – estimation, the calculation of function points and the conversion of these to values for the effort and time – Scheduling of projects

Section 3: Quality Management An activity that takes place throughout the software development process. Cannot be added to a system at the end must be built in from the start. Adding quality to a project plan identify l For each deliverable, l – identify the quality control standards and guidelines to be applied, and the method that they are applied quality plan specifies all quality controls of project l Avoid to short-cut the quality controls if project is under resource or timescale pressure l

Quality management systems l A quality management system (QMS) is an organization-wide mechanism for building quality in projects + managing the quality control process. l The basic elements of a QMS: Quality manual: includes standards, guidelines and procedures that are applied within the organization.

l l Quality manual requires project develops its own quality plan (must comply with the guidelines in quality manual) Claim conformance to some quality standard (ISO 9001). QMS consists of a managerial structure, responsibilities, activities, capabilities and resources. Quality plan is a contract between client and developer ISO 9001 -A member of a family of international standards(ISO 9000) published by the International Standards Organization (ISO). -Applies to all steps from design to manufacturing problem: Not industry-specific, expressed in general terms and needs high degree of interpretation of diff. products

ISO 9000 -3 l Specific needs of the software development process Quality system — framework 9001 & 9000 -3 both envisage 4 components of QMS l • There must be management responsibility, Senior management must define quality policy • QMS documented as a quality manual has a set of procedures, standards …, for auditing • Must be regular internal quality audits, to judge implementation can be and improvements identified. . • Must be corrective action mechanisms, problems can be identified and corrected or avoided.

l Quality system — life-cycle activities – A life-cycle model should be used as the basis of a QMS, – All quality activities should be related to the life cycle – Suggests waterfall life-cycle model l Quality system — supporting activities – include configuration management. – QMS between organizations can be compared through the capability maturity model (CMM) and SPICE.

l Capability maturity model (CMM) – used as a measure of an organization’s corporate understanding of its development processes. – A software process is a set of activities, methods, practices and transformations used to develop and maintain software and associated products – CMM identifies five levels of software process maturity l SPICE (Software Process Improvement and Capability d. Etermination) – August 1998— ISO 15504 was released, SPICE – objective blend ISO 9000 + CMM.

Assessment software development process may suggest shortcomings motivates a process improvement strategy change the process. This continues in cycles as needed.

Section 4: Configuration Management l A typical software development project will produce thousands of separate items that are interdependent. – Documents – UML or other design models – program All easy to change l But not all versions of items will work together properly need to keep track of what works together

Configuration items l Is any elementary type of thing that is produced during a project (e. g. use case diagrams, interaction diagrams, etc. ). – will exist in many versions – possess a number of variants – Stored in machine-readable form or library or database, configuration repository checking in: Placing a version of item into repository checking out: Retrieving a version of item from the repository

Configurations and baselines l l l Configuration version: A consistent collection of versions of configuration items Build state The catalogue of configuration items and the versions used in a configuration version Configurations: consistent sets of versions of items are – The collection of configuration items that are brought together l Baselines: A configuration version that forms a foundation from which further development can progress – associated with the major milestones of a project l Releases: Is a configuration version delivered on completion of the project for use by the customer the baselines from which maintenance takes place.

Change control l freezing a baseline: forbidding any further changes disabling further check-in operations for the items in the corresponding configuration. l But that is overdoing it, and we need to have some means of updating a baseline in a controlled manner. l Achieved change control