CPT203小豪的笔记_sprint execution daily scrum-CSDN博客

本文链接：https://blog.csdn.net/qq_62123793/article/details/133214106

Software Engineering 1

文章目录

1. Introduction
2. SOFTWARE PROCESS
3. Agile Methods
4. Scrum Framework

1. Introduction

1.1 SOFTWARE FAILURE & SUCCESS

Software engineering is criticized as inadequate for modern software development.
Software failures are a consequence of two factors:
- Increasing demands
- Low expectations (you don’t expect the software to grow into a giant beast)

1.2 PROFESSIONAL SOFTWARE DEVELOPMENT

Amateur
- People in business write spreadsheet programs to simplify their jobs
- scientists and engineers write programs to process their experimental data
- hobbyists write programs for their own interest and enjoyment
Professional
- developed for specific business purposes, for inclusion in other devices, or as software products such as
- intended for use by someone apart from its developer
- is usually developed by teams rather than individuals
- It is maintained and changed throughout its life.
Software engineering is intended to support professional software development, rather than individual programming.
It includes techniques that support program specification, design, validation, and evolution.
Professional software usually has the following properties:
- Strict user requirements
- Required accuracy and data integrity
- Higher security standard
- Stable performance for heavy load
- Required technical support, etc.

1.3 PROFESSIONAL SOFTWARE DEVELOPMENT

1.4 TWO KINDS OF SOFTWARE PRODUCTS

Generic software products
- These are systems that are produced by a development organization and sold on the open market to any customer who is able to buy them.
Customized software products
- These are systems that are commissioned by a particular customer. A software contractor develops the software especially for that customer.
The distinction between these system product types is becoming increasingly blurred

1.5 SOFTWARE DETERIORATION

Software is a logical rather than a physical system element. Therefore, software has one fundamental characteristic that makes it considerably different from hardware: Software doesn’t “wear out.”
In theory, therefore, the failure rate curve for software should take the form of the “idealized curve” shown in Figure
Software doesn’t wear out. But it does deteriorate
During its life, software will undergo change. As changes are made, it is likely that errors will be introduced, causing the failure rate curve to spike as shown in the “actual curve”
Before the curve can return to the original steady-state failure rate, another change is requested, causing the curve to spike again.

To reduce software changes:
- Work closely with the stakeholder to ensure requirements are correctly defined
- Improve requirement study approach to achieve better requirements study
To reduce side effects after changes:
- The software should be modular so that changes will not have a lot of side effects to other part of the software
- The software must be maintainable
- Comprehensive testing should put in place to reduce errors.

##1.6 SOFTWARE ENGINEERING APPROACHES

The systematic approach that is used in software engineering is sometimes called a software process.
A software process is a sequence of activities that leads to the production of a software product.
There are four fundamental activities that are common to all software processes:
- Software specification
- Software development
- Software validation
- Software evolution

##1.7 GENERAL ISSUES THAT AFFECT MOST SOFTWARE

Heterogeneity (异构性)
- Increasingly, systems are required to operate as distributed systems across networks that include different types of computer and mobile devices.
Business and social change
- Business and society are changing incredibly quickly as emerging economies develop and new technologies become available. They need to be able to change their existing software and to rapidly develop new software.
Security and trust
- As software is intertwined with all aspects of our lives, it is essential that we can trust that software.

1.8 SOFTWARE ENGINEERING DIVERSITY

Different types of systems need different development processes.
For example, real-time software in an aircraft has to be completely specified before development begins. In e-commerce systems, the specification and the program are usually developed together.
Software engineering is a systematic approach to the production of software that takes into account practical cost, schedule, and dependability issues, as well as the needs of software customers and producers.
How this systematic approach is actually implemented varies dramatically depending on the organization developing the software, the type of software, and the people involved in the development process
2 major approaches:
- Sequential
- Iterative

1.9 APPLICATION TYPES

Stand-alone applications
- These are application systems that run on a local computer, such as a PC. They include all necessary functionality and do not need to be connected to a network.
Interactive transaction-based applications
- Applications that execute on a remote computer and are accessed by users from their own PCs or terminals. These include web applications such as e-commerce applications.
Embedded control systems
- These are software control systems that control and manage hardware devices. Numerically, there are probably more embedded systems than any other type of system.
Batch processing systems
- These are business systems that are designed to process data in large batches. They process large numbers of individual inputs to create corresponding outputs.
Entertainment systems
- These are systems that are primarily for personal use and which are intended to entertain the user.
Systems for modeling and simulation
- These are systems that are developed by scientists and engineers to model physical processes or situations, which include many, separate, interacting objects.
Data collection systems
- These are systems that collect data from their environment using a set of sensors and send that data to other systems for processing.
Systems of systems
- These are systems that are composed of a number of other software systems.

1.10 SOFTWARE ENGINEERING FUNDAMENTALS

Some fundamental principles apply to all types of software system, irrespective of the development techniques used:
- Systems should be developed using a managed and understood development process. Of course, different processes are used for different types of software.
- Dependability and performance are important for all types of system.
- Understanding and managing the software specification and requirements (what the software should do) are important.
- Where appropriate, you should reuse software that has already been developed rather than write new software.

1.11 SOFTWARE ENGINEERING AND THE WEB

The Web is now a platform for running application and organizations are increasingly developing web-based systems rather than local systems.
Web services allow application functionality to be accessed over the web.
Cloud computing is an approach to the provision of computer services where applications run remotely on the ‘cloud’.
- Users do not buy software buy pay according to use.

1.12 WEB-BASED SOFTWARE ENGINEERING

Software reuse is the dominant approach for constructing web-based systems.
- When building these systems, you think about how you can assemble them from pre-existing software components and systems.
Web-based systems should be developed and delivered incrementally.
- It is now generally recognized that it is impractical to specify all the requirements for such systems in advance.
User interfaces are constrained by the capabilities of web browsers.
- Technologies such as AJAX allow rich interfaces to be created within a web browser but are still difficult to use. Web forms with local scripting are more commonly used.

1.13 SOFTWARE ENGINEERING ETHICS

Like other engineering disciplines, software engineering is carried out within a social and legal framework that limits the freedom of people working in that area.
As a software engineer, you must accept that your job involves wider responsibilities than simply the application of technical skills.
You must also behave in an ethical and morally responsible way if you are to be respected as a professional engineer.
You should not use your skills and abilities to behave in a dishonest way or in a way that will bring disrepute to the software engineering profession.
There are areas where standards of acceptable behavior are not bound by laws but by the more tenuous notion of professional responsibility. Some of these are:
- Confidentiality
- Competence
- Intellectual property rights
- Computer misuse

1.14 SOFTWARE DEVELOPMENT RISK

Many software development projects run into difficulties
- Does not work as expected
- Over budget
- Late delivery
Much of the functionalities in the software is wasted
- Wrong requirement
- User dislike it
- There are no customer
- etc
Many software projects fail because the software developers build the wrong software. The software development team must:
- Fully understand requirement
- Validate requirement
The developer will often add technical insights and suggestions, but remember the client satisfaction is the primary measurement of success in software project.

1.15 HOW TO MINIMIZE RISK?

Communication with the client
- Feasibility studies
- Separation of requirements from designs
- Validate software requirements
- Milestones and releases
- Acceptance and user testing

2. SOFTWARE PROCESS

2.1 INTRODUCTION

There are many different software processes, but all must include four activities that are fundamental to software engineering:
- Software specification
- Software design and implementation
- Software validation
- Software evolution
In practice, they are complex activities in themselves and include subactivities
There are also supporting process activities such as documentation and software configuration management
software processes are categorized as either plan-driven or agile processes.
Plan-driven processes are processes where all of the process activities are planned in advance and progress is measured against this plan.
In agile processes, planning is incremental and it is easier to change the process to reflect changing customer requirements.

2.2 SOFTWARE PROCESS MODELS

The waterfall model - This takes the fundamental process activities of specification, development, validation, and evolution and represents them as separate process phases such as requirements specification, software design, implementation, testing, and so on.
Incremental development - This approach interleaves the activities of specification, development, and validation. The system is developed as a series of versions (increments), with each version adding functionality to the previous version.
Reuse-oriented software engineering - This approach is based on the existence of a significant number of reusable components. The system development process focuses on integrating these components into a system rather than developing them from scratch.

2.2.1 THE WATERFALL MODEL

Because of the cascade from one phase to another, this model is known as the ‘waterfall model’ or software life cycle. The waterfall model is an example of a plan-driven process
The principal stages of the waterfall model directly reflect the fundamental development activities:
- Requirements analysis and definition
- System and software design
- Implementation and unit testing
- Integration and system testing
- Operation and maintenance
In the Waterfall Model, documentation is produced at each phase. This makes the process visible so managers can monitor progress against the development plan.
Its major problem is the inflexible partitioning of the project into distinct stages.
Commitments must be made at an early stage in the process, which makes it difficult to respond to changing customer requirements.
In principle, the waterfall model should only be used when the requirements are well understood and unlikely to change radically during system development.

2.2.2 INCREMENTAL DEVELOPMENT

Incremental development is based on the idea of developing an initial implementation, exposing this to user comment and evolving it through several versions until an adequate system has been developed
Specification, development, and validation activities are interleaved rather than separate, with rapid feedback across activities.
Incremental software development, which is a fundamental part of agile approaches, is better than a waterfall approach for most business, e-commerce, and personal systems

benefits

Incremental development has three important benefits, compared to the waterfall model:
- The cost of accommodating changing customer requirements is reduced.
- It is easier to get customer feedback on the development work that has been done.
- More rapid delivery and deployment of useful software to the customer is possible, even if all of the functionality has not been included.

problems

The problems of incremental development become particularly acute for large, complex, long-lifetime systems, where different teams develop different parts of the system.
Large systems need a stable framework or architecture and the responsibilities of the different teams working on parts of the system need to be clearly defined with respect to that architecture.
This has to be planned in advance rather than developed incrementally.

2.2.3 REUSE-ORIENTED SOFTWARE ENGINEERING

There are three types of software component that may be used in a reuse-oriented process:
- Web services that are developed according to service standards and which are available for remote invocation.
- Collections of objects that are developed as a package to be integrated with a component framework such as .NET or J2EE.
- Stand-alone software systems that are configured for use in a particular environment.
Advantages
- reducing the amount of software to be developed and so reducing cost and risks.
- usually also leads to faster delivery of the software.
However, requirements compromises are inevitable, and this may lead to a system that does not meet the real needs of users.
Furthermore, some control over the system evolution is lost as new versions of the reusable components are not under the control of the organization using them.

2.3 SOFTWARE PROCESS ACTIVITIES

Real software processes are interleaved sequences of technical, collaborative, and managerial activities with the overall goal of specifying, designing, implementing, and testing a software system.
The four basic process activities of specification, development, validation, and evolution are organized differently in different development processes.
In the waterfall model, they are organized in sequence
In incremental development they are interleaved

2.3.1 SOFTWARE SPECIFICATION

Software specification or requirements engineering is the process of understanding and defining
- what services are required from the system
- identifying the constraints on the system’s operation and development.
Requirements engineering is a particularly critical stage of the software process as errors at this stage inevitably lead to later problems in the system design and implementation.

The requirements engineering process aims to produce an agreed requirements document that specifies a system satisfying stakeholder requirements.
Requirements are usually presented at two levels of detail.
- End-users and customers need a high-level statement of the requirements;
- system developers need a more detailed system specification.
There are four main activities in the requirements engineering process:
- Feasibility study
- Requirements elicitation and analysis
- Requirements specification
- Requirements validation

2.3.2 SOFTWARE DESIGN AND IMPLEMENTATION

The implementation stage of software development is the process of converting a system specification into an executable system.
It always involves processes of software design and programming but, if an incremental approach to development is used, may also involve refinement of the software specification.
A software design is a description of the structure of the software to be implemented, the data models and structures used by the system, the interfaces between system components and, sometimes, the algorithms used.

Design activities
- Architectural design, where you identify the overall structure of the system, the principal components (sometimes called sub-systems or modules), their relationships, and how they are distributed.
- Interface design, where you define the interfaces between system components. This interface specification must be unambiguous.
- Component design, where you take each system component and design how it will operate.
  - a simple statement of the expected functionalities
  - a list of changes to be made to a reusable component
  - a detailed design model (model-driven approach).
- Database design, where you design the system data structures and how these are to be represented in a database.
The detail and representation of the design output vary considerably.
- For critical systems, detailed design documents setting out precise and accurate descriptions of the system must be produced.
- If a model-driven approach is used, these outputs may mostly be diagrams.
- Where agile methods of development are used, the outputs of the design process may not be separate specification documents but may be represented in the code of the program.

2.3.3 SOFTWARE VALIDATION

Software validation or, more generally, verification and validation (V&V) is intended to show that
- a system both conforms to its specification
- it meets the expectations of the system customer
Validation techniques:
- Program testing, where the system is executed using simulated test data, is the principal validation technique
- Validation may also involve checking processes, such as inspections and reviews, at each stage of the software process from user requirements definition to program development

The stages in the testing process are:
- Development testing - The components making up the system are tested by the people developing the system. Each component is tested independently, without other system components.
- System testing - System components are integrated to create a complete system. This process is concerned with finding errors that result from unanticipated interactions between components and component interface problems.
- Acceptance testing - This is the final stage in the testing process before the system is accepted for operational use. The system is tested with data supplied by the system customer rather than with simulated test data.

2.3.4 SOFTWARE EVOLUTION

Once a decision has been made to manufacture hardware, it is very expensive to make changes to the hardware design. However, changes can be made to software at any time during or after the system development. Even extensive changes are still much cheaper than corresponding changes to system hardware
Historically, there has always been a split between the process of software development and the process of software evolution (software maintenance).
People think of software development as a creative activity in which a software system is developed from an initial concept through to a working system. However, they sometimes think of software maintenance as dull and uninteresting
Rather than two separate processes, it is more realistic to think of software engineering as an evolutionary process

3. Agile Methods

3.1 Background

IBM introduced incremental development in the 1980s (Mills et al., 1980).
The introduction of so-called fourth generation languages, also in the 1980s, supported the idea of quickly developing and delivering software (Martin, 1981).
Late 1990s with the development of the notion of agile approaches such as
- DSDM (Stapleton, 1997)
- Scrum (Schwaber and Beedle, 2001)
- extreme programming (Beck, 1999; Beck, 2000).

3.2 Rapid Software Development

The software is not developed as a single unit but as a series of increments, with each increment including new system functionality.
Fundamental characteristics:
- The processes are interleaved.
- Minimum documentation
- Developed in a series of versions, or increments, with system stakeholders involvement.
- System user interfaces are often developed using an interactive development system that allows the interface design to be quickly created
Other approaches to RAD includes: -
- Adaptive software development
- Agile methodologies
- Spiral model
- Unified software development process
Plan-driven development approach
- Large, long lived software - careful project planning, formalized quality assurance, the use of analysis and design methods supported by CASE tools, and controlled and rigorous software development processes

3.3 Agile Methods

Agile allowed the development team to focus on the software itself rather than on its design and documentation
universally rely on an incremental approach to software specification, development, and delivery.
They are best suited to application development where the system requirements usually change rapidly during the development process
They are intended to deliver working software quickly to customers, who can then propose new and changed requirements to be included in later iterations of the system.

The philosophy behind agile methods is reflected in the agile manifesto that was agreed on by many of the leading developers of these methods.

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

3.1

3.4 Agile Methods – The challenges

In practice, the principles underlying agile methods are sometimes difficult to realize:

Its success depends on having a customer who is willing and able to spend time with the development team and who can represent all system stakeholders
Individual team members may not have suitable personalities for the intense involvement
Prioritizing changes can be extremely difficult, especially in systems for which there are many stakeholders

3.5 Agile Methods – more challenges

Maintaining simplicity requires extra work
It is difficult for some organization to accept informal processes defined by development teams
The software requirements document is usually part of the contract between the customer and the supplier (software company)
Because incremental specification is inherent in agile methods, writing contracts for this type of development may be difficult.
Agile methods must rely on contracts in which the customer pays for the time required for system development rather than the development of a specific set of requirements
If problems arise then there may be difficult disputes over who is to blame and who should pay for the extra time and resources required to resolve the problems.

3.6 Agile Methods – Maintenance

Agile methods supporters argue that it is a waste of time to write this out-of-date documentation
The key to implementing maintainable software is to produce high-quality, readable code.
The key document is the system requirements document, which tells the software engineer what the system is supposed to do

3.7 Plan-driven and Agile development

Most software projects include practices from plan-driven and agile approaches.
To decide on the balance between a plan-based and an agile approach, you must answer a range of technical, human, and organizational questions:
- Detail specification and design needed?
- Is incremental strategy realistic?
- How large is the system?
- What type of system being developed?
- System life span?
- Available technologies and tools?
- Organization of the team?
- Cultural issues?
- Available skillsets?
- External regulation?

4. Scrum Framework

4.1 Overview

Scrum is not a standardized process
Scrum is a framework for organizing and managing work.
The Scrum framework is based on a set of values, principles, and practices that provide the foundation to which your organization will add its unique implementation of relevant engineering practices and your specific approaches for realizing the Scrum practices

3.2

4.2 Scrum Roles

Scrum development efforts consist of one or more Scrum teams
Each made up of three Scrum roles: product owner, ScrumMaster, and the development team
The product owner is responsible for what will be developed and in what order
The Scrum Master is responsible for guiding the team in creating and following its own process based on the broader Scrum framework
The development team is responsible for determining how to deliver what the product owner has asked for

4.2.1 Product Owner

The single authority responsible for deciding which features and functionality to build and the order in which to build them
The product owner maintains and communicates to all other participants a clear vision of what the Scrum team is trying to achieve
The product owner is responsible for the overall success of the solution being developed or maintained.
To make sure that the most valuable work is always performed
The product owner actively collaborates with the ScrumMaster and development team
Must be available to answer questions soon after they are posed

4.2.2 Scrum Master

Helps everyone involved understand and embrace the Scrum values, principles, and practices
Acts as a coach, providing process leadership and helping the Scrum team and the rest of the organization develop their own high performance, organization-specific Scrum approach
The ScrumMaster helps the organization through the challenging change management process that can occur during a Scrum adoption.
As a facilitator, the ScrumMaster helps the team resolve issues and make improvements to its use of Scrum
Also responsible for protecting the team from outside interference and takes a leadership role in removing impediments that inhibit team productivity
The ScrumMaster has no authority to exert control over the team, so this role is not the same as the traditional role of project manager or development manager
The ScrumMaster functions as a leader, not a manager

4.2.3 Development Team

Scrum defines the role of a development team, which is simply a diverse, cross-functional collection of people who are responsible for designing, building, and testing the desired product
The development team self-organizes to determine the best way to accomplish the goal set out by the product owner
The development team is typically five to nine people in size
Its members must collectively have all the skills needed to produce good quality, working software
For development efforts that require much larger team size, team members can be organized into several teams with each team nine or fewer team members

4.3 Scrum Activities and Artifacts

3.3

3.4

4.4 Product Backlog

The product owner, with input from the rest of the Scrum team and stakeholders, is ultimately responsible for determining and managing the sequence of works (product backlog items) and communicating it in the form of a prioritized (or ordered) list known as the product backlog

On new-product development the product backlog items initially are features required to meet the product owner’s vision.
For ongoing product development, the product backlog might also contain new features, changes to existing features, defects needing repair, technical improvements, and so on.
Product owner collaborates with internal and external stakeholders to gather and define the product backlog items
High-value items appear at the top of the product backlog and the lower-value items appear toward the bottom.
The product backlog is a constantly evolving artifact. Items can be added, deleted, and revised by the product owner as business conditions change, or as the Scrum team’s understanding of the product grows
In practice, many teams use a relative size measure such as story points or ideal days to express the item size

PBI Example

User Story: Online user registration
Description: As a user, I want to be able to register online, so that I can perform online shopping
Acceptance Criteria:
- User can register only if the user fills in all required fields
- The email used in the registration must not be a free email
- User will receive a notification email after successful registration
User Story: Search for customer
Description: As a marketing manager, I would like to search for customers, so that I can call them
Acceptance Criteria:
- Positive test: When I enter “Eddie” in the search box and click the search button, I will see all entries containing Eddie in a grid
- Negative test: When I enter “ABC” in the search box and click the search button, I will see no entries in the grid
- Gold plating: If no result, display a message
- Gold plating: If a large set of results being returned, display in pagination
- Gold plating: The user can click on the column heading of the grid to sort the information

4.5 Product Backlog Grooming

The activity of creating and refining product backlog items, estimating them, and prioritizing them is known as grooming

4.6 Sprint

In Scrum, work is performed in iterations or cycles of up to a calendar month called sprints
The work completed in each sprint should create something of tangible value to the customer or user
Sprints are timeboxed so they always have a fixed start and end date, and generally
They should all be of the same duration
A new sprint immediately follows the completion of the previous sprint

3.5

4.7 Sprint Planning

A product backlog may represent many weeks or months of work. To complete all the items in the product backlog, a series of sprints are to be carried out
To determine the most important subset of product backlog items to build in the next sprint, the product owner, development team, and ScrumMaster perform sprint planning
During sprint planning, the product owner and development team agree on a sprint goal that defines what the upcoming sprint is supposed to achieve
Based on the sprint goal, the development team reviews the product backlog and determines the high priority items that the team can realistically accomplish in the upcoming sprint while working at a sustainable pace
Many development teams break down each targeted feature into a set of tasks. The collection of these tasks, along with their associated product backlog items, forms a second backlog called the sprint backlog
The team provides an estimate (typically in hours) of the effort required to complete each task

In summary: Select a product backlog item (whenever possible, the next-most-important item as defined by the product owner), break the item down into tasks, and determine if the selected item will reasonably fit within the sprint (in combination with other items targeted for the same sprint). If it does fit and there is more capacity to complete work, repeat the cycle until the team is out of capacity to do any more work.

4.8 Sprint Execution

Once the Scrum team finishes sprint planning and agrees on the content of the next sprint, the development team performs all the task-level work necessary to get the features done
“done” means there is a high degree of confidence that all the work necessary for producing good-quality features has been completed.
Team members define their own task-level work and then self-organize in any manner they feel is best for achieving the sprint goal

4.9 Daily Scrum

Once the Scrum team finishes sprint planning and agrees on the content of the next sprint, the development team performs all the task-level work necessary to get the features done
“done” means there is a high degree of confidence that all the work necessary for producing good-quality features has been completed.
Team members define their own task-level work and then self-organize in any manner they feel is best for achieving the sprint goal
Each day of the sprint, ideally at the same time, the development team members hold a timeboxed (15 minutes or less) daily scrum
This inspect-and-adapt activity is sometimes referred to as the daily stand-up because of the common practice of everyone standing up during the meeting to help promote brevity
ScrumMaster facilitating and each team member taking turns answering three questions:
- What did I accomplish since the last daily scrum
- What do I plan to work on by the next daily scrum?
- What are the obstacles or impediments that are preventing me from making progress?
The purpose is for everyone to understands the big picture of what is occurring, how they are progressing toward the sprint goal, any modifications they want to make to their plans for the upcoming day’s work, and what issues need to be addressed.
Not a problem-solving activity
Talk about problems after the daily scrum and do so with a small group of interested member
Communicate the status of sprint backlog items among the development team members
It is an inspection, synchronization, and adaptive daily planning activity that helps a self-organizing team do its job better.

4.10 Definition of Done

sprint results as a potentially shippable product increment, meaning that whatever the Scrum team agreed to do is really done according to its agreed-upon definition of done
This definition specifies the degree of confidence that the work completed is of good quality and is potentially shippable.
A bare-minimum definition of done should yield a complete slice of product functionality that is designed, built, integrated, tested, and documented
“potentially shippable” does not mean that what got built must actually be shipped.
Shipping is a business decision, which is frequently influenced by things such as:
- Do we have enough features or enough of a customer workflow to justify a customer deployment?
- Can our customers absorb another change given that we just gave them a release two weeks ago?

4.11 Sprint Review

At the end of the sprint there are two additional inspect-and-adapt activities, sprint review and sprint retrospective
Sprint review is to inspect and adapt the product that is being built.
Critical to this activity is the conversation that takes place among its participants, which include the Scrum team, stakeholders, sponsors, customers, and interested members of other teams.
Focused on reviewing the just-completed features in the context of the overall development effort.
Everyone in attendance gets clear visibility into what is occurring and has an opportunity to help guide the forthcoming development to ensure that the most business-appropriate solution is created.

4.12 Sprint Retrospective

The second inspect-and-adapt activity at the end of the sprint
Frequently occurs after the sprint review and before the next sprint planning
Sprint retrospective is an opportunity to inspect and adapt the process
The development team, ScrumMaster, and product owner discuss what is and is not working with Scrum and associated technical practices.
The focus is on the continuous process improvement
At the end of a sprint retrospective the Scrum team should have identified and committed to a practical number of process improvement actions