General

Software Process Definition & Improvement: An Industry Report

Categories
Published
of 10
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Related Documents
Share
Description
Software Process Definition & Improvement: An Industry Report Michael Jester, Herb Krasner, and Dewayne E. Perry Empirical Software Engineering Lab (ESEL) ECE, The University of Texas at Austin
Transcript
Software Process Definition & Improvement: An Industry Report Michael Jester, Herb Krasner, and Dewayne E. Perry Empirical Software Engineering Lab (ESEL) ECE, The University of Texas at Austin {hkrasner, ABSTRACT We present highlights of an process improvement project at a software center in preparation for CMM Level 3, with applicable examples given that relate to CMM level 2, level 3, and the effort needed in transitioning between level 2 and 3. For the efforts taken at this particular software center, the work documented is divided into two parts: the process definition and the process database. Finally, some qualitative and quantitative analysis, suggestions for future work, and conclusions regarding overall lessons learned from the experience are provided. Categories and Subject Descriptors D.2 [Software Engineering]: D.2.9 Management General Terms Process improvement, CMM, Process Experience Keywords Software Engineering, Process Improvement 1. INTRODUCTION For the sake of non-disclosure, the specific details about the company and the projects and technologies being developed in them are intentionally left vague and ambiguous. What can be said is this: the company is not involved in the business of selling mass-marketed software to the general public. Their primary customers are other corporations, and while software is not their end-product per se, the technologies developed by the company almost always require a strong software component. As a multinational corporation, this particular company has several centers of excellence in different parts of the world, each with individual focus. The focus for this particular center is the development of software that interacts with or supports the tools and technologies developed at other centers. The center is a relatively new center (compared to the other centers within the company), having been established in Beijing, China in 1997 (starting with only a handful of engineers, but growing steadily in numbers). The typical project engineer is relatively young in their career (typical work experience of 2-3 years, with several fresh graduates), and many of the projects require a high level of interaction with other centers around the world. For these reasons (among others), having a viable software process is a center-wide objective, with formal CMM level assessment being used as the yardstick to measure progress toward that objective (in fact, every employee s year-end bonus in 2004 was contingent upon passing the CMM Level 3 assessment). Upon joining the software center in August of 2003, certification for CMM level 2 had already been obtained (in the previous calendar year) and efforts were already underway to receive CMM level 3 certification by the end of Some of the challenges related to transitioning from CMM Level 2 to CMM Level 3 included: Defining new procedure documents and templates related to CMM level 3 KPAs Revising existing process documents and templates (related to CMM level 2) in order to comply with CMM level 3 requirements Establishing a process database (to use historical data for project planning, among other reasons) These challenges will be explained in turn in more detail in the subsequent sections. 2. LEVEL 2 BASES There are several important KPAs that are critical for moving to Level 3: software quality assurance, project planning and project tracking. 2.1 Software Quality Assurance Software Quality Assurance is one of the KPAs for CMM level 2 and essentially is a mechanism that helps ensure each individual project is following the defined process the way they are supposed to [7,8]. It is a sort of police system for checking up on project managers and their teams. In getting prepared for the level 3 assessment, the process-related strengths and weaknesses as reflected in SQA reports served as an important indicator for how prepared the center was for the assessment (and what gaps had to be filled before the assessment). Selection and General Duties of SQA Engineers The software center had approximately 20 software projects under development organized under three different areas (where each area produced related software products). For each project, an engineer from another project would be assigned to act as the SQA engineer. In general, the duties were not supposed to take more than two calendar days per month (since the SQA engineers still had their own projects that they were responsible for). General SQA duties included participating in peer review (including pre-reviewing documents before wide distribution and serving as a moderator during review meetings), moderating particular milestone meetings, performing periodic (i.e., monthly) checks to identify issues (and following up on the project team to ensure they were resolved properly), and (occasionally) helping the project team perform testing. Playing the role of an SQA engineer brings to mind the phrase it s a tough job, but somebody s got to do it. Much like software testers, SQA engineers typically only brings bad news to the project managers (in the form of a list of process non- compliances). This was not particularly enjoyable for either the project manager or the SQA engineer. SQA Reporting At one point during the process improvement project, it had been decided to merge the previously mentioned tailoring form and the SQA report into one template (See Figure 3). More than just a move to reduce the number of documents by one, the idea was to minimize the confusion between SQA engineers and project managers as to what was considered fair game for the monthly SQA audit and what was not. For example, if the approved version of the tailoring form reflected that a particular artifact needed a formal review (rather than an informal review which was used for shorter and/or less critical documents), then the SQA engineer would know from the form that they should look not only for the document itself but also the review record associated with the document (as well as checking up to see that all issues uncovered during the review were properly resolved). Alternatively, if an artifact was waived by the manager (e.g., a design document was waived because it was combined with an architecture document), then the SQA engineer would not need to waste time looking for an artifact that did not exist and was not supposed to exist. In short, combining the tailoring form and SQA report helped project managers know what SQA engineers would be checking for and help SQA engineers ensure that the project was following the project-specific (tailored) process. The general goal was that the SQA coordinator would be able to have a compiled list of non-compliances from all projects in the center and try to prioritize them. Much like a software product manager tries to systematically organize and prioritize software defects so that the most important ones are fixed in a timely manner, the SQA coordinator needs to have the judgment to do the same with software process defects (again, Osterweil s claim that Software Processes are Software Too applies). In this regard, the SQA coordinator often acted as a resource to the SQA engineers whenever there was disagreement or misunderstanding as to how a process non-compliance should best be handled. 2.2 Project Planning and Tracking Project planning and tracking spans two KPAs within CMM level 2. Besides being critical for CMM level 2, project planning and tracking is important for CMM level 3 in the sense that estimates of effort and schedule had to be made on historical data (there is where a project database comes in, to be discussed in more detail later). In order to have a consistency of data quality, having a standardized template for collecting project effort and calendar data was critical. A template using an excel spreadsheet (portion of it shown in Figure 1 and 2) had been used and was in circulation but had been deemed by most project engineers as being less than user-friendly. To help facilitate this, a new template was developed using Microsoft Project. Figure 1. An example Tailoring form/sqa Report (only Inception phase shown). A complete report would list artifacts from all phases, although only artifacts from the current phase would be audited. Role of the SQA Coordinator At any given time one of the two full-time process engineers acted as an SQA coordinator. The responsibilities basically included making sure that the SQA engineers were trained properly, collecting and reviewing monthly SQA reports, and helping follow-up on unresolved process non-compliances from the previous month (for example, if a reported process noncompliance was not resolved within the specified time frame agreed upon between the SQA engineer and the project manager, the SQA coordinator might escalate issues by going to the project manager and/or their supervisor). Figure 2. Portion of an example list of tasks for a Project Plan Template (MS Excel shown above; both Excel and MS Project were implemented). Several pilot projects starting using Microsoft Project before it was distributed center-wide (in order to minimize deployment issues in tailoring the template to be useful across the whole center). The template had all of the tasks dictated by the official process as well as important associated subtasks. If the project s tailored process had fewer required artifacts (and thus fewer required tasks) specified in the afore-mentioned tailoring form, the user would have to delete some tasks, but it was generally agreed upon that it was a better problem to have a project plan template with more tasks listed than necessary (and let users delete them as needed) than not enough (which would run the risk of having critical tasks overlooked). Note that the final version of the template was considered fairly complete, with over 100 tasks and sub-tasks listed in the template. 2.3 Other Key Process Areas The above sections highlight some major efforts taken to prepare the center for the CMM Level 3 assessment. Note that not all of the Key Process areas from CMM level 2 and 3 are mentioned. The omitted are not mentioned because they were either not applicable or needed very little adjustments. For example: Peer Review mostly involved minor tweaking to the peer review templates and making sure people were following the peer review process properly Requirements Management relatively few changes since CMM level 2 had been achieved. Subcontract Management was not really applicable since there were not any outside subcontractors (and those working inside the center were treated as normal employees in terms of following the software process). Software Configuration Management relatively few changes since CMM level 2 had been achieved. Training Program was coordinated by the human resources group rather than the Software Process Group (with SQA training being a notable exception). Intergroup Coordination had a procedure drafted to be reviewed by other centers but never reached formal agreement from the other centers that were involved in crosscenter projects. Part of the problem was that we were the only center trying to achieve CMM. However, the fact that other centers were following the same high-level product development procedure did help with Intergroup coordination. This concludes our discussion of the software process definition project, and we will now turn our attention to the process database. 3. PROCESS DEFINITION The tasks for redefining the organizational process were organized as a project, with two full-time process engineers and some part-time help from some of the other project engineers. The major activities involved some definition of new processes and rework of existing processes. We will take a few of those CMM level 2 and 3 KPAs (Organization Focus, Software Quality Assurance, Project Planning and Tracking, and Peer Review) and discuss them in more detail [2,3]. 3.1 Organizational Process Focus and Definition Most of the documents revised or created during the life of the project were divided into three categories: high-level policies (broad in scope, giving the big picture view), procedure documents (providing a clear set of expected process inputs, outputs, steps, and measurements, if applicable), and templates (ready-to-go documents for project engineers to fill in the blanks with their project specific data). Of these documents, the most important were the templates in the sense that the templates were used the most by project engineers; the artifacts that were created during the life of the projects were based on the templates. The policies and procedures were mostly for reference. The templates were intended to be as consistent with the policy and procedure documents to the highest degree possible (the rationale being that taking this approach would lessen the learning curve required by project engineers to learn the new process; as long as they were filling in all the required fields in the templates, they would be in compliance with the official process). Another purpose of the high-level policy documents was to serve as an interface between this software center and the rest of the company (spread worldwide). The company (which is a worldwide organization) had its own an official product development procedure that was imposed upon all centers; each center is required to have a process compliant with the company standard (note that not all of the other centers are software centers, or are trying to become CMM certified). Externally, the highest-level policies gave some evidence and assurance to higher-level organizations that the center was compliant with the company-wide standard. Internally, the policies served as a sort of constitution for all of the procedure and template documents to be developed; lower-level documents discovered to be in conflict with the high-level policies would have to be reworked (in practice this was rarely a problem, since the high-level policies allowed ample room for flexibility in process definition). Although peer review is not a CMM requirement until level 3, a fairly mature and established review procedure was already in place (it had long been part of the company culture long before the center had any interest in CMM). This was a valuable asset when trying to revise the overall process, since it greatly facilitated valuable feedback from the end-users of the new process (i.e., project engineers, project managers, and resource managers). 3.2 Process Deployment After process documents and templates were approved, they were made widely available via a website on the local intranet, where any engineer on the company network could view and download them. Ideally, a newly revised process document (whether a procedure or a template) would go through a beta phase before being made available for wide distribution. Specifically, a small number of projects would experimentally use a new template or procedure document, provide feedback, and necessary revisions to the document would be incorporated before widely publishing the new document. Due to time constraints, this was not always possible (i.e., there had to be evidence of certain processes being in use over a certain period of time before the assessment). However, since many of the documents were simply newer versions of existing documents, the risk associated with not having a trial period was low. Also, the risk exposure caused by not having a beta phase for a given document was lessened by the fact that only a small percentage of projects would be in the same phase at any given time. For example, if major revisions were made to the project plan template, there might be only two or three projects in the planning phase at the time of deployment (who would often give feedback on the new processes). Furthermore, a website was provided where any engineer could log on and make a suggestion for process improvement (which was either an enhancement or a true defect). These suggestions would intermittently be examined, classified and prioritized by a process engineer or another AIT member (and if appropriate, incorporated into the process documents). The practice of reviewing the process defects and enhancement suggestions, very similar to the procedure followed for defects filed against an actual software product, brings to mind Lee Osterweil s contention that software processes are software too [4]. Besides posting new documents on the process webpage, weekly meetings served as a means to make center-wide, process-related announcements (e.g., if a new procedure was in place). While these served a means for broadcasting information, often it was necessary to have follow-up sessions with a small group of engineers with more time for Q&A to effectively train engineers that were using a new process document (for example, making sure that a project team using a beta version of a document clearly understood the new procedure and the expectations associated with acting as a pilot project ). In order to give the groups within the center more ownership, two engineers from each discipline were assigned by their managers part-time (i.e. two days a month) to serve on the previously mentioned Action Improvement Team. This essentially amounted to part-time supplemental workers for the two full-time process engineers and helped tremendously during process definition and process deployment. For example, several of the action improvement team members were project managers themselves, so having a deeper understanding of the process (by having helped contribute during the definition stage) greatly facilitated their ability to explain the process in turn to their team members. 3.3 Similarity to RUP The process being followed was very similar to the Rational Unified Process (RUP see figure 3). For example, there were very distinct phases throughout the life-cycle of each project (inception, elaboration, construction, and transition), each with an associated set of phase-specific activities, and demarcated with distinct milestones that marked the end of one particular phase and the beginning of the next. Within each phase, a certain set of artifacts had to be produced before moving on to the next phase; for example, having a formally reviewed and approved requirements document might be a requirement before moving from the elaboration phase to the construction phase. Figure 3. Model of the Rational Unified Process. Different disciplines have different levels of activity depending on the phase of the project. Figure 4 shows a graph generated with historical data from an actual project using the process database. We discuss the process database in more detail in below; however, this graph is shown here to show the similarity to the RUP process, in that there are different disciplines (both development and support disciplines) spread across four different phases, with different levels of activity during each phase. For example, the R&S (Requirements and Specification) task type shows the highest amount of activity during the Inception phase, while COD (coding) shows the most amount of effort in the second and third phases (both of these examples are about what one would expect). Note that this type of view from the process database could give a higher-level manager an idea of how people were spending their time [5] (for example, if the inception phase showed little effort in Requirements and Specifications, and significant effort in coding, it could be an indicator that the project team was starting too early into development without a stable set of requirements). Figure 4. Task Effort (in person-weeks) for an actual project within the center. Phase (e.g. Inception, Elaboration) shown along the x-axis, effort (in person-weeks) shown along the y- axis, and activity type (e.g. coding, documentation, etc.) shown along the z-axis. 3.4 Tailoring Form One of the high-level policy documents would specify which artifacts we
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks