Process Improvement Issues Throughout Superlative 1 2 example essay topic

2162 CIT - Software Quality Principles Semester 2-2002 Assignment 2 - Strategic Action Plan Due: 5.00 pm, 25 October 2002 Team Members: Billy Bloggs Student Id: 123456 Jane Doe Student Id: 234567 Contents 1. Introduction 4 1.1. Purpose 4 1.2. Acronyms 4 1.3. Reference 4 2. Overview 5 3.

Executive Summary 6 4. Business Case for SPI Initiative 7 4.1. Business Rationale 7 4.2. Guiding Principles 7 5. Process Improvement Goals 9 5.1. Short-Term Goals 9 5.2.

Long-Term Goals 9 6. Assumptions, Risks and Barriers 10 6.1. Assumptions 10 6.2. Risks 11 6.3. Barriers 11 6.4.

Organisational Scope 12 6.5. Management Steering Committee 13 6.6. Software Process Improvement Leader 13 6.7. Software Engineering Process Group 13 6.8. Working Groups 13 6.9. Process Owners 13 6.10.

SPI Consultant 13 7. Criteria for Success 14 Configuration Management Process (Edward) 14 Quality Assurance Process 14 Problem Resolution Process (Tony) 14 Project Management Process (Elbert) 14 Risk Management Process (Wendy) 14 8. Improvement Agenda 15 8.1. Selection of SPI Activities 15 8.2. Current SPI Activities 15 8.2. 1.

Requirements Gathering 15 Current improvement efforts 15 Resources 15 Comparison with recommendations 16 8.2. 2. Software Development 16 Current improvement efforts 16 Resources 16 Comparison with recommendations 16 8.2. 3.

Configuration Management 16 8.2. 3.1. Resources 16 8.2. 3.2. Comparison with recommendation 17 8.3. Process Improvement Roadmap 18 8.3.

1. Process Establishment (Troy) 18 8.3. 2. Problem Resolution 18 9.1.

1. Identify and prioritize improvement areas 22 1. Introduction 1.1. Purpose This plan provides an introduction to the software process improvement (SPI) initiative for the software development projects at Superlative Software, describes the infrastructure to manage the initiative, and defines an approach for identifying and addressing the process improvement issues throughout Superlative. 1.2. Acronyms The following are acronyms used in this document. Acronyms Definitions CMM Capability Maturity Model MSC Management Steering Committee SEPG Software Engineering Process Group SPI Software Process Improvement 1.3.

Reference 2. Overview Superlative Software is a medium-sized software development company targeting on development of network management software in telecommunications industry. Currently, Superlative Software is undertaking joint commercialisation projects with Telstra. Under the substantial constraints on delivery time, Superlative Software has adopted a 90-day release cycle for relevant products.

There is a significant focus on the business needs and timeframes of the customers. This has led to a change on the role of engineering personnel, who now have more direct contact with the customers. Robustness, reliability and scalability of the software are paramount... Software Quality Assessments Pty Ltd conducted the assessment; the site visit was held on Friday 13 September 2002. The assessment team comprised John Terwilliger (as Team Leader) and Bernadette Twigg. Sponsor: The owner of the assessment is a management role within the organization that has the authority to ensure that the assessment can be carried out effectively, and takes ownership of the assessment output. qualified assessor: John Terwilliger 3.

Executive Summary This strategic action plan is intended to integrate all software process improvement activities within Superlative Software. It describes the goals, motivation for improving, the commitment required by various parties, the assumptions that are being made, the overall process to be applied in managing this initiative, and the infrastructure required to facilitate the initiative. This document serves as the project plan for the SPI initiative, indicating an overall agenda, roles and responsibilities, assumptions and risks, key tasks, success criteria, key milestones, and how this initiative will evolve over multiple iterations of the continuous improvement cycle. A separate detailed schedule will be developed and used to manage the SPI initiative.

Management commitment to this effort is a critical success factor. Evidence of commitment includes: - allocating appropriate and adequate resources; - setting realistic expectations and expecting accountability for realistic results; - providing clear, consistent, and public communications about the importance of the SPI initiative and the progress that is being made; - providing rewards and recognition for those exhibiting the desired process improvement related behaviour; - defending software engineering based process discipline as the way that software development will be done in Superlative Software; Software engineers should be both permitted and expected to follow sound software engineering principles and practices to meet their project expectations. - What are our goals for the SPI program? - What is our motivation to improve? - What assumptions are we making?

- Who are the players? - How will we measure successes? - How will we continue to improve? 4. Business Case for SPI Initiative 4.1. Business Rationale In recent years, Superlative software has been under significant resource pressure, reflecting pressures within the industry generally.

The concern was driven by the need to significantly improve productivity to meet the business objectives of the new company strategy. Therefore, the business motivation of the improvement process is to achieve the following: . cycle time reduction. quality improvements in the delivered products. improved schedule performance because of more realistic estimates and reduced feature creep. reduced internal rework and wasted effort. reduced staff turnover and increased morale. the ability to facilitate movement of people from one project to another because of common software development practices. From glenn. Increased system productivity and therefore efficiency... Maintenance or improved quality control... Make special allowance for risks relating to the substantial delivery time and significant improvement in productivity which contain safety-critical elements.

This can most effectively be done by addressing the following areas that a dealt with within this report: . Better documentation methods throughout projects so data can be collected, processed, stored, and hopefully learnt from for developments of future projects... Improved schedule performance because of more accurate estimates based on collected historical data and better management of feature creep... Cycle time reduction, through better and more accurate time management. This requires better time management techniques through the use of predefined methods that can be implemented and designed by reviewing past projects, which should lead to less reduced internal rework and wasted effort... Put in place overall processes for problem resolution to be clearly followed across projects, with the approach relying upon a predefined structured risk management plan...

Development of formal criteria for customer acceptance of developed products needs to be developed according to a standard. Better ability to facilitate movement of people from one project to another through the application of uniform software development practices and guidelines. From Elbert. Reduce software development and maintenance cost is to avoid any reworks throughout the development procedures.

(Case study). Improves customer satisfaction. It is because the customer satisfaction is the only way of improving company image. Because no customer is happy with a product that contains many problems. (Case study).

Improves professional staff. This process is developing to improve employee moral, and increase the confidence of developers or programmers. The advantage of this process is to ensure that less overtime, less employee turnover, and improving competitive edge. (Case study). Quality must build in to products. Therefore, the process improvement shall have an effective process that helps Superlative produce the right product and helps company determine what the company needs.

Quality is another issues that needed to be addressed. This process should provide a very clear message to developers and users that all the respect functions should function correctly with respect to the characteristics of software. In other words, quality can also be addressed as part of the software quality requirements. The software quality requirements must be clearly stated and it cannot be misunderstood throughout the software process improvements.

These software quality requirements are including: . Performance quality: it is usually regard as the product fulfilling its functional specification... Reliability: a process of measure of how often the software fail to performance as required. It is sometimes called mean time between failures.

Missing: [Any projection of benefits to be obtained should be supported by references to pertinent literature, and caveats about the conditions that must exist for the projected results to be achieved. The needs and business goals of an organization are often centred around achieving enhanced customer satisfaction and greater competitiveness. For organizations with a dependence on software, these key management concerns become drivers that initiate software process improvement throughout the organization with goals of higher software quality, lower development and maintenance costs, shorter time to market, and increased predictability and controllability of software products and processes 4.2. Guiding Principles The guiding principles for the SPI effort or the SEPG are followings: .

The SPI initiative is intended to address business, technical, project management, and quality of life issues that are worth improving. The organization should be able to explain to stakeholders why a proposed activity or deliverable is important... Process oriented work products must be concise, must add value, and must be usable. There is no intent to produce reams of documentation... The appropriate mindset for process change is to understand "what's in it for us" as a project team, an organization, or a company and its customers, not just what's in it for any individual... The initiative will emphasize the importance of leveraging existing examples and templates.

The organization must avoid the "not invented here" syndrome, choosing instead to borrow, buy, or adapt appropriate artifacts (Is it architect?) that already exist. 5. Process Improvement Goals 5.1. Short-Term Goals Requirements Elicitation Process Goals 1. Formal requirements baseline will be established Software Development Process Goals 2. Formal criteria for customer acceptance of all developed products will be defined.

3. Standards for different work products will be consistent Configuration Management Process Goals 4. Product baseline definition at different stages of the life cycle will be applied 5. There will be consistency in the quality of release notes for products developed.

6. Specific plans for configuration management will be defined 7. Tools supporting full life cycle control of configurations will be deployed within the unit 8. Full configuration management will be applied to all documentation 9.

Responsibilities of team players involved and authority between them will be defined. 10. Process will be managed to successfully meet the process objectives. 11. Work products will be appropriately documented, controlled, and verified.

This will include: . Defining work product requirements. Defining requirements for documentation and control of work products. Identifying dependencies among controlled work products.

Identifying and documenting work products and controlling changes. Verifying and adjusting work products to meet the defined requirements Problem Resolution Goals 12. A process for problem resolution will be established. 13.

The problem resolution activities will be identified 14. A mechanism for recognising and acting on trends in problems identified will be provided 15. A mechanism to improve the problem resolution process will be provided 16.17. 18. This will include: .

Verifying and adjusting work products to meet the defined requirements Project Management Goals 19. Schedule and cost estimations will be more realistic 20. There will be frequent comparisons between planned activities to actual results 21. Objectives for schedule control and overall project management will be formally documented 22. Project management activities will be consistently planned 23. Dependencies between different planning products will be clearly identified 24.

Project management documentation will be under full configuration management 25. Key staff will have access to project management training 26.27. 28. This will include: . Verifying and adjusting work products to meet the defined requirements Risk Management Goals 29.

A process to collect data in order to monitor risks, or assess the performance of the risk management process will be defined 30. The scope of risk management to be performed for the project will be determined 31. Appropriate risk management strategies will be defined and implemented 32. Risks to the project will be identified in the project plan in the beginning and as they develop during the conduct of the project. 33. Risks will be analysed and prioritised 34.

Activities associated with managing risks, including formal prioritisation of risks will be in the project plan 35.36. 37. This will include: . Verifying and adjusting work products to meet the defined required 6. Assumptions, Risks and Barriers This section addresses assumptions underlying the motivations for SPI, the way SPI will be pursued, the existence of elements necessary for success, the barriers to being successful over the long term with SPI and risks inherent in the plan. 6.1.

Assumptions The followings address assumptions underlying the motivations for SPI and the way SPI will be pursued: A 1. The motivations for SPI is to satisfy the business needs by improving the processes that measured by the assessment (conducted on 13th September 2002). Assume that assessment can effectively reflect the problems in the current processes of the Superlative Software. A 2. SPI will be initiated after agreement of the top management of the Superlative Software. The plan schedule of SPI will initiate at 23rd October 2002.

A 3. SPI will initially concentrate on improving processes with the top priority. A 4. SPI will be continuously monitored over a long term; conscious effort and periodic reinforcement are required for management team. A 5. Training is required for staff with insufficient knowledge in processes improvement.

A 6. Management should approve the areas for improvement, the goals and targets, and the action plan, thereby committing the organization to undertake the planned improvements. The decision should be clearly communicated to all affected staff. A 7. Measurement is used to determine effectiveness of each improve process. Recognition and reward are given for encouragement. 6.2.

Risks The following are the major risks inherent in the plan: ID Risk Item P L E Mitigation Approaches Who Date Due Risk 1 The duration of the SPI is underestimated 8 8 64 Objectively measuring process performance and making decisions based on realistic metrics agreed by all parties in the organization. John Terwilliger 23rd October 2002 Risk 2 The commitment of middle management is low. 7 7 49 Training initiatives to ensure that senior management is committed to the costs and impact of process assessment activities and improvement actions on the projects to which they are applied. Katherine Hepbum, John Terwilliger A week before starting of each SPI item.

Risk 3 Staff unable to adapt new processes. 5 6 35 Monitor staff performance. Review suitability of the new processes and make change if necessary. configuration manager. John Terwilliger Contin-uo us Risk 4 Key persons are unavailable to perform their tasks. 3 7 21 Assign persons to back up sponsor, assessors, team leader and other key persons involved. Katherine Hepbum, John Terwilliger 23rd October 2002 P = probability of occurrence (0 to 1) L = relative loss factor (0 to 10) E = risk exposure = P L 6.3.

Barriers Lack of communication and teamwork decreases the effectiveness and efficiency of the software process. Poor teamwork skills increase the time to perform activities with the high degree of parallel work typical of software projects. Training should be considered as a means of improving the quality and effectiveness of teamwork skills. The training can include process improvement concepts, specifically, will increase the organization's readiness for process improvement. Important concepts that should be covered include process and quality concepts, process improvement concepts, process management skills, tools and techniques for process improvement, cultural change skills and supporting skills. Low co-operative between staffs and assessors can slow down the improvement process.

Therefore, SPI will be pursued with the strong support of the top management of the organisation. Also, Process assessment concepts should be explained to all levels of the organization (from management to staff) being assessed. The assessors should fulfil the basic educational requirements and receive training to ensure having adequate skills. Untrained assessors are less likely to produce objective, consistent and reliable results on which to base a successful process improvement programme. Barriers in the organisation include human and cultural factors. The following should be considered: - Business conflict as in conflicts between developers and client, conflict between staffs and conflict between departments.

- Personal conflict as in staff's personal conflict such as family and friends. This can affect a staff's working behaviour and hinder his / her performance. - Degree of acceptance by individuals (Management and Staff) of Software Process Improvement efforts. - Experience level within the organization with current processes. - The stability of organization structure and management. - Participation of organization members.

- Restructuring of organization may lead to staff disapproval organisation for Process Improvement. Therefore, regular measurement on the improvement processes is necessary to determine the progress of each process. Make changes that can address the problems and bring the improve process back on the track. Organisation for Process Improvement Organisational Scope The strategic action plan being developed for Superlative Software Pty Ltd encompasses principally the improvement project for Superlative Software's software development and project management processes in order to address their current productivity issues, meet customer delivery time constraints and the expectation to "do more with less" as far as resources go. The Organizations involved in this process improvement plan are: .

Software Quality Assessments Pty Ltd. Corporate Development Manager Management Steering Committee The goal of the management steering committee is to indicate that process improvement is a management priority and in so doing assist the improvement process by overcoming resistance from employees within the organisation. The management steering committee will consist of the following people... Katherine Hepburn (Corporate Development Manager). Frasier Crane (Engineering Manager).

Glenn Turner (Business Development Manager). John Wayne (Project Manager). Robin Williams (Project Manager). Charles Schultz (Project Manager).

Rita Hayworth (Project Manager) The management steering committee meets regularly once every fortnight unless there are pressing issues which require their immediate attention. Regular activities addressed by the committee include: . Risk Management. Resource and Time constraints. Personal Improvement Goals.

Monthly Summary from the SPI leader. Suggestive actions... Assessment Reviews. Plan approvals. Work group chartering, monitoring, and resource assistance. Software Process Improvement Leader The software process improvement leader has the task of coordinating and leading the Software Process Improvement initiative.

The responsibilities of the Software Process Improvement Leader include: . Documenting the organization's strategic action plan (this document)... Creating a schedule identifying activities, resources, and effort... Tracking progress against the plan... Reviewing project team and working group action plans...

Collecting status biweekly from the project teams and working groups... Summarizing and reporting status monthly at the MSC meeting... Suggesting corrective action to the MSC when actual progress deviates too far from the plans... Acquiring and coordinating resources for training and consulting.

Working Groups The working group consists of a team of technicians who, produce, review, and assist with the piloting of a new software process deliverables and tools in a specific, focused improvement area. The working groups will be established by the Process owners when needed. Working group team members are expected to participate in the activities of piloting deliverables and in roll outs of new processes. Responsibility for each milestone in the SPI Roadmap will be undertaken by an employee with the necessary ability and will serve as leader for a working group to address the improvement recommendations in that milestone. These leaders will establish working groups of between 2 and 4 others as required to evaluate the inadequacies of the current process, and collect existing artefacts from throughout the Superlative Software company, develop new process assets, conduct pilots, modify the processes and deliver the new process assets out to the affected departments / groups.

Process Owners The process owners of the following process improvement areas have a responsibility to give feedback on the application of new processes as well as handle process change requests for the new processes themselves. Process owners also have to charter work groups, and evaluate the extent the new processes are being applied and how well they are working. Process Owner Improvement Area Process (s) Responsible For Frasier Crane Requirements Elicitation, Software Development John Wayne Configuration Management, Quality Assurance Robin Williams Problem Resolution Charles Schultz Risk Management Rita Hayworth Process Establishment, Project Management SPI Consultant The SPI consultant used for this improvement plan was the Software Quality Assessments Pty Ltd. They were responsible for conducting a rapid assessment of process capability for Superlative Software Pty Ltd. The assessment report was based on the ISO / IEC 15504-5 standard and was performed on the 16th September 2002. The assessment report was generated for use as the basis for the development of this strategic action plan.

Their main responsibility are: . to propose recommendations based on current SPI activities to conduct an analysis of the current capability of the organization 7. Criteria for Success Requirement Elicitation Process Measurement on successful SPI initiative: Related Goals Measures for success identified: a decrease in product defects Change activity for the allocated requirements; Cumulative number of changes to the allocated requirements, including number of changes proposed, open, approved, and incorporated into the system baseline. Software Development Process Configuration Management Process (Edward) Quality Assurance Process Problem Resolution Process (Tony) Project Management Process (Elbert) Risk Management Process (Wendy) Process Establishment (Troy) 8. Improvement Agenda 8.1. Selection of SPI Activities This section describes the software engineering and management areas to be addressed by SPI work will be selected and prioritised.

(See Appendix A) Procedures: 1. Determine organisation's needs and business goals. 2. Assess the current practices.

3. Analysis & Evaluation of the assessment report. 4. Prioritised & select the SPI activities. Lastly, priorities all the SPI activities and selects the SPI activities with agreement with top management in the company. Prioritised SPI activities (refer to 8.3 Improvement roadmap) 8.2.

Current SPI Activities 8.2. 1. Requirements Gathering Current improvement efforts Currently, a new process called "Bid Review Board" which use for review and justify for investment. The aim is to improve the understanding of the customer's requirements through the process of bid development. The needs of the customers are monitored through regular reviews; a research function within the company ensures good awareness of new technologies relevant to key customers. Resources - "Bid Team" comprising Business Development, Project Management and key technical staff.

- The ATD Group. - Customers' feedback Comparison with recommendations Actions within the bid team are monitored, and the process is well institutionalized. The requirements documents follow defined standards, and are controlled and reviewed, both internally and with the customer. Measures of effort and cost relating to requirements gathering are collected, and experiences with individual projects are identified through post-project reviews. Mentoring is used as the major approach to ensure that company personnel have the skills needed for effective gathering of requirements. How to map to RoadMap 8.2.

2. Software Development Current improvement efforts A standard process for software development exists, and is tailored for each project. The extent and nature of tailoring depends on the expertise of the project manager rather than on specific guidelines. New approaches to the standard process are trialed when the opportunity arises. The post project review provides significant understanding of the standard process; however, the range of measures collected is limited. Resources - Project manager.

- Software Architect. - A tool called "Common Tool Library". Comparison with recommendations 8.2. 3. Configuration Management The company currently standardizes the source code control by adopting CVS as the standard.

The Project Filing System is formally documented; a defined process for using CVS has been developed and is in the course of review. No specific performance data relating to the organizational performance in configuration management is collected. 8.2. 3.1. Resources - Configuration Manager. - CVS 8.2. 3.2. Comparison with recommendation 8.3. Process Improvement Roadmap The roadmap consists of several sequences of improvement areas: Process interactions As the organization is a medium-size software development company (with staff 65).

Improvement items are hardly concurrently initiated. And the schedule is based on the priority of improvement area and the size of the organization. The first project looked initially for possible changes in the organization, and then to the establishment of a clear procedure to communicate user expectations to the development group. The second project set out to collect the good practices from the Pink square project and to generalize them for transfer to other projects. The third project hired an experienced consultant to brief them about the practical experiences in putting reviews in place within industrial organizations and to help them to identify the best way of introducing reviews within Movie Views. Each of the improvement projects was piloted in one of the three product development projects and measurements were taken to get preliminary confirmation of the benefits derived from the selected improvement actions. 8.3.

1. Process Establishment (Troy) Duration 3 months Staff Responsible Team Leader (Market Consultant), Team Leader (Software Development), Analyst Designer, Programmer Objective (s) Problem resolution processes to be consistently used; managed; work products produced; standardized; and deployed; Milestones Target date Recommendations Fully achieveProcess attribute 1.1 at Level 1 e.g. (13 Oct 2002)? 2.1? 2.2? 3.1? 3.2? 8.3.

2. Problem Resolution Duration 3 months Staff Responsible Team Leader (Market Consultant), Team Leader (Software Development), Analyst Designer, Programmer Objective (s) Problem resolution processes to be consistently used; managed; work products produced; standardized; and deployed; Milestones Target date Recommendations Fully achieveProcess attribute 1.1 at Level 1? Brief staff on the problem resolution process and need to use the formal process consistently in all projects. 2.1?

Develop a resource allocation plan based initially on historical data.? Record assigned responsibility's in the project plan.? Include task identification statements in the project plan.? Develop schedule's containing time estimates using historical data / trends outlined and reviewed regularly. 2.2? Creation of Problem Resolution reports & reviews (escalation process review).?

Develop and utilise trend analysis documents based on historical information.? Develop Mitigation / acceptance plans. 3.1? Creation and documentation of a formal / standard process reflecting the current practices performed in the Problem Resolution process.? The validation, review, testing, and approval of the standard process and documentation.? Delivery of standardized process documentation copies to staff involved in problem resolution.

3.2? The implementation of the standard Problem Resolution process throughout the organisation.? Training programs to ensure an understanding of the standardized process and to test performance levels of defined tasks.? Enforcement / Adherence checks of problem resolution work products and processes.

Risk Management Duration 3 months Staff Responsible Advisory Council, project manager Objective (s) To expand number of risk considered boundaries. Create formal risk identification measurement. Create documentation method for risk management. Document all risks identified. Milestones Target date Recommendations Fully achieveProcess attribute 1.1 at Level 1 e.g. (13 Oct 2002)?? Risk identification are given from experience project manager.

2.1?? Create risk identification measurement.?? Develop documentation method for risk management.?? Document all risks that are identified. 2.2?? Apply the risk documentation method.??

Expand number of risk considered boundaries. Configuration Management Duration 3 months Project manager, Configuration manager Objective (s) Standardise configuration management process. Software product are controlled and documented. Organisation performance in configuration management is measured. Configuration management is performed and monitor in all projects.

2.1?? A CM plan is prepared for each software project according to a documented procedure.?? Documented and approved CM plan is used for CM activities. 2.2?? CM activities is identified and tracked through the work breakdown structure.?? Collect performance data to measure the perform the configuration management in the projects.??

Provide adequate resources for perform the CM activities. 3.1?? Standardised the CM process by adopting CVS as the standard. 3.2?? Software requirements document is placed under configuration management.?? Enforcement of standard can be done by formal review of project manager.

Project Management Duration 3 months Staff Responsible Objective (s) Milestones Target date Recommendations Fully achieveProcess attribute 1.1 at Level 1 e.g. (13 Oct 2002) 2.1 2.2 9. Appendix A 9.1. 1. Identify and prioritize improvement areas Improvement areas should be identified and prioritized based on a number of factors as outlined in figure 3.

The factors in detail are: - The assessment output, which shows weak and strong areas of the assessed processes and process instances; - The organization's needs, which provide general improvement goals to be achieved through the improvement programme; - Effectiveness measures, which, if already in place, identify improvement priorities for the organization generally related to the improvement drivers; - Industry norms and benchmarks that provide a basic comparison framework for assessment results; - Risks related to either not achieving the stated improvement goals or failure of improvement actions. Figure 3 - Identifying and prioritizing the improvement areas.