CMM Level-2 Case Study.ppt

1、CMM-2 Case Study,From Chaos to Repeatable in Four Months By Johanna Rothman,Introduction,This paper is a case study of a small product development group working as an individual division within a large software company. The software process improvement approach here used the CMM as a reference, but

2、not as a roadmap. The product is a middleware communications application. For the sake of this discussion, we will call the product Messenger.,Background Information,The Messenger management team was focused on sales and marketing issues, they were not especially interested in managing product devel

3、opment. With the original founder gone and without any software engineering process, the engineering team was in turmoil and the project was in a state of disarray. Although Messenger was part of a larger company, the product and infrastructure remained distant from the parent company. the Messenger

4、 technical staff was unable to take advantage of the engineering tools and processes.,Initial Project State,No project manager or project schedule Servicing customer calls consumed about 75% of the development staffs time (time consuming conference calls and reactive bug fixes) No public configurati

5、on management or automated public bug-tracking system No design reviews or public code reviews or walkthroughs No unit tests and inadequate system tests Too many unproductive meetings Multiple missed corporate deadlines,Initial Project State,Figure 1: Cause and effect diagram of Initial Project Stat

6、e,First Step: Role Definition via Project Planning,Schedule Development Program Manager/Project Manager: Generate a project schedule, and update it weekly. Determine project state via program and project team meetings, formal and informal weekly one-on-ones with engineering staff, of no more than 30

7、 minutes duration. As problems arose, make them visible to the team, and facilitate finding solutions. Architect: Design large components of system. Guide developers for smaller components. Developer: Design, implement, and debug components. Run walkthroughs for each component then submit them to th

8、e code czar. Code Czar: Integrate all code as written and submitted. Maintain the build system. SQA Engineer: Define and perform testing on delivered software, taking into account the product architecture and customer use of the system.,First Step: Role Definition via Project Planning,Project Plan D

9、evelopment In addition to the task list and schedule, an overall project plan was developed by the program manager in collaboration with the Messenger team. In addition to circulation among management, the project plan and all updates were distributed to all of the technical staff.,First Step: Role

10、Definition via Project Planning,Program Plan Development In addition to the technical project work, we started working on making contacts around the organization, and formed a program team (cross-functional team). The program team served the dual purposes of informing the corporation of the progress

11、 in the Messenger group, and informing the Messenger group what the expectations of the corporation were. The program team had representatives from Manufacturing, Service, Training, Product Marketing, and the local Program Manager/Project Manager.,Middle Steps: Process Definition,Process definition

12、took about four weeks to get started after the schedule, project plan, and program plan efforts started. During the weekly one-on-one meetings, the project manager discussed each technical persons role, and what that person needed to be successful. The staff was gently encouraged to think about thei

13、r problems in new ways, preferably from their stakeholders perspectives.,Middle Steps: Process Definition,Scheduling technique Layout the entire project. Understand the major milestones. Develop multiple milestones for every person for every week. Verify the individual milestone success via one-on-o

14、nes and project team meetings.,Middle Steps: Process Definition,Figure 2: Concurrent Development and Testing Process,Middle Steps: Process Definition,The architect defined an overall architecture of the product, with the additional features. A subset of developers would start the design with the arc

15、hitect. After the first design, there was an informal design review with the entire development and SQA staff. Then the detailed design and implementation started, along with the SQA development of tests. By the time the code was written and developer-tested, everyone was ready for it. All code went

16、 through an informal walkthrough before being checked in. After the code was checked in, the SQA tests started on those features.,Ongoing Steps: Continuous Learning,People recognized that their work was a process, or represented part of a larger process. This understanding was key to their ability t

17、o succeed in the organization, and for product development success. This understanding of processes allowed them to think about how to do work in general, not just what had to be done immediately.,Summary,Project State A program and project manager, whose work could be repeated. A working project sc

18、hedule, with technical staff who understood how to generate another schedule. Very few customer calls and demands for bug-fixing. A public configuration management system. An automated bug-tracking system and mechanism for fixing bugs. Design reviews on the core parts of the system. Public code walk

19、throughs on the core parts of the system. Adequate system tests but no unit tests. Short weekly project team and one-on-one individual meetings.,Summary,Process The process is flexible, and can continue to evolve as necessary. People The biggest change was in the people. The technical staff started

20、off as process cynics, but quickly became converted to doing things in a defined, repeatable way. Planning Planning was critically important. The effects of the plans made a number of issues obvious to the management and technical staff.,Appendix: Release Criteria,Beta Criteria used by the Messenger

21、 team: All code must compile and build for all platforms: (platforms removed for confidentiality.) All developer tests must pass. All available tests for Beta customer (client side part of the product) must run and pass. All current bugs are entered into the bug-tracking system. First draft document

22、ation and available, and shippable to customers. The code is frozen. Tech support training plan is in place, and people are in place. There are less than 36 open priority 0 and 1 bugs. (Priority 0 bugs are the most severe bugs - those that prevent the customer from using the product. Priority 0 and 1 bugs were not well-differentiated, so the criteria referred to both of them.),Appendix: Release Criteria,Product Shipment Criteria used by the Messenger team: All code m