Software Engineering Graduate Project Effort Analysis Report Zhihao Chen Center for Software Engineering, University of Southern California, Los Angeles 90089 California, USA {zhihaoch}@cse.usc.edu Abstract: In the graduate courses CSCI577ab, graduate students apply software engineering methodologies, processes, procures, and models to manage software development. This report analyzes their activities and effort distribution from fall 2001 to spring 2004. It would be very helpful for students to appropriately arrange their time, manage their schedule and plan their projects. It would also very helpful for software engineering research. Keywords: Software Engineering, effort, software development 1 Introduction There are two software engineering graduate courses (CSCI577a and CSCI577b) in our center for software engineering for us to perform the software engineering education. In the courses, graduate students apply software engineering methodologies, processes, procures, and models to manage software development. In each semester, there are more than 20 real graduate projects with all kinds of the software engineering activities. They study software engineering knowledge, learn the processes, and plan and control their projects. With the study of their activities and effort distribution from fall 2001 to spring 2004, we try to understand the trends in e-services projects and their effort implications, and identify sources of effort reduction/increase. We also try to provide the guidelines for future software project activities. 2 Assessing Effort Data In our graduate projects, people use the Model-Based (System) Architecting and Software Engineering (MBASE) approach for software development. MBASE provides more detailed definitions of the anchor point milestone elements, and a process guide for deriving them. It has intermediate milestones to serve as commitment points and progress checkpoints with the set of anchor point milestones: Inception Readiness Review (IRR), Life Cycle Objectives (LCO), Life Cycle Architecture (LCA), Initial Operational Capability (IOC), and Product Release Review (PRR). Basically, we collect all effort data for all activities during the software development lifecycle in LCO, LCA, IOC and PRR. There are project effort data in different project life-cycle phases inception phase, elaboration phase, construction phase, transition phase and support phase; there are project effort data of win-win negotiation, project requirements, project system design, project implementation, project management; there are project effort data of product model, process model, property model, success model. Table 1 Project activities 1
In each year, there are more than 20 projects in our center. People use MBASE/RUP software process to develop the software systems. The effort of 31 development activities shown in table 1 in the projects has been collected and classified into five catalogues management, environment and configuration management, requirements, design, implementation, assessment, deployment, and other effort. Figure 1 The activity effort distribution of the median in the selected projects We select 29 continue small projects (4 to 6 persons) from fall 2001 to spring 2004 in the total 70 projects. Median effort of projects for each week is calculated. With our analysis, we found that most of the effort above the median. We use median because the effort for some projects at that week has extreme high values, and the median can be a better measure of centralness than the mean or average The figure 1 clearly shows MBASE/RUP software processes in practices in small projects. The activity effort increases close to the major milestones, in which projects were reviewed, re-planed, re-estimated, and re-controlled. The vary criteria by phase help people to make decisions. In the inception phase (LCO), the most active activities are A1 - Life Cycle Planning, A3 - Client Interaction, A4 - Team Interaction, B1 - Training and Preparation, C1 - WinWin Negotiations, C3/4 - Modeling & documenting for Operational Concept Description, C5/6 - Modeling & Documenting for System and Software Requirements Definition, and F2 - Feasibility Rationale Description. The stakeholders are working on the project scope definition, cost/schedule estimation, define / negotiate / understand /prioritize requirements, identify risks, and demonstrate architectural prototype. In the elaboration phase (LCA), the most active activities are A1 - Life Cycle Planning, A3 - Client Interaction, A4 - Team Interaction, C5/6 - Modeling & Documenting for System and Software Requirements Definition, D1/2 - Modeling & Documenting for System and Software Architecture Description and F4 - Inspection and Peer Reviews. At the end of this phase, stability of the product vision and architecture, resolution of major risk elements, adequate planning and reasonable estimates for project completion, stakeholder acceptance of the product vision and project plan, and acceptable expenditure level have been done. In the construction phase (IOC), the most active activities are A3 - Client Interaction, A4 - Team Interaction, E2 - Critical Component Implementation, F3 - Test Planning, F4 - Inspection and Peer Reviews, and other activities not-covered-here. In the transition phase, the most active activities are A4 - Team Interaction, E2 - Critical Component Implementation, G1 - Transition and Support Planning, and other activities not-covered-here. It is ready to release the products if the clients satisfy it. The clients may start the initiation of another development cycle to improve or enhance the product. 2
Figure 2 The high-level project effort distribution Shown in Figure 1/2, there is a series of iterations within each phase. The effort of the related activities is changing in each iteration. Each iteration marks a minor milestone. Project results are assessed and project plan is revised as necessary in each iteration. It illustrates how phases and iterations, or the time dimension, relates to the development activities performed, or the workflow dimension. The relative effort indicates how much of the activity is performed in each phase/iteration. Each iteration involves activities from all workflows. The relative amount of work related to the workflows changes between iterations. From another hand, we also see that, for the small projects, there are too many overheads between the team communications. The activity of team interaction are always most active. This is true in here because most of the graduate students are new to the software engineering (this is why they take the course), the team members are first time to meet each other, a lot of technologies / processes need to be studied, and team leader management skills need to be improved. In the small projects, the management effort of Life Cycle Planning, Control and Monitoring, Client Interaction and Team Interaction is still major. If we improve the management level, it will save a lot of effort. Figure 3 Major project artifact effort distributions In MBASE/RUP software process, OCD (Operational Concept Description) is to describe how a proposed new system1 will operate within its environment. For the operational stakeholders (including users, operators, administrators, maintainers, owners, general public), it enables them to understand and refine the proposed new system. It also enables them to evolve knowledgeably from their current operational concept to the new one. For the development stakeholders, it enables them to better understand and make development decisions consistent with the operational objectives and constraints. SSRD (System and Software Requirements Definition) is to describe capability requirements (both nominal and off-nominal): i.e., the fundamental services provided by the system, describe Level of Service Requirements (sometimes referred to as Non-functional requirements): i.e., the behavioral properties that the specified functions must have, such as performance, usability, etc. Level of Service Requirements should be assigned a unit of measurement, describe global constraints: requirements and constraints that apply to the system as a whole. SSAD (System and Software Architecture Description) is to document the results 3
of analyzing the organizational concept of operation for the system, designing an architecture, and designing an implementation. The SSAD serves as a bridge between the Operational Concept defined during the Inception phase and the Construction phase. The SSAD is started during the Inception phase, refined during the Elaboration phase, and completed during the Construction phase. FRD (Feasibility Rationale Description) is to ensure that the system developers have not just created a number of system definition elements, but have also demonstrated the feasibility and consistency of these elements. LCP (Life Cycle Plan) is to serve as a basis for monitoring and controlling the project's progress, to provide general information during Inception and Elaboration about those project management areas which, to serve as the basis for controlling the project's progress in achieving the software product objectives, to help make the best use of people and resources throughout the life cycle, to provide evidence that the developers have thought through the major life cycle issues in advance, and to to answer the most common questions about a project or activity: why, what, when, who, where, how, how much, and whereas. From the figure 3, OCD, SSAD and SSRD are most active in the inception phase; SSAD, LCP, SSRD are most active in the elaboration phase. During the development, LCP is always active to monitor and control the project, and ensure the project archiving the goals. 3 Conclusions With the above analysis results, people can avoid the same mistakes, solve the recurring issues, manage the software project better, and apply the similar models in different projects. It would be very helpful for students to appropriately arrange their time, manage their schedule and plan their projects. It would also very helpful for software engineering research. References 1. Barry Boehm, A Spiral Model of Software Development and Enhancement Computer, May 1988, pp. 61-72. 2. Barry Boehm, Software Risk Management, IEEE Computer Society Press, 1989. 3. Barry Boehm, Unifying Software Engineering and Systems Engineering, IEEE Computer, March 2000, pp. 114-116. 4. Barry Boehm et al., Developing Multimedia Applications with the WinWin Spiral Model, Proceedings, ESEC/FSE 97, Springer Verlag, 1997. 5. Barry Boehm et al., Using the Win Win Spiral Model: A Case Study, IEEE Computer, July 1998, pp. 33-44. 6. Barry Boehm, M. Abi-Antoun, A.W. Brown, N. Mehta, and D. Port. Guidelines for the LCO and LCA Deliverables for MBASE, USC-CSE, March 2000, http://cse.usc.edu/classes/cs577a_2004/guidelines/mbase_guidelines_v2.4.1.pdf 7. Barry Boehm et al., Theory W Software Project Management: Principles and Examples, IEEE Trans. Software Engr., July 1989. 8. Barry Boehm et al., A Collaborative Spiral Software Process Model Based on Theory W, Proceedings, ICSP 3, IEEE, Reston, Va. October 1994. 9. Barry Boehm, Dan Port, Escaping the Software Tar Pit: Model Clashes and How to Avoid Them, ACM Software Engineering Notes, January, 1999, pp. 36-48. 10. Barry Boehm, Dan Port, When Models Collide: Lessons from Software Systems Analysis, IEEE IT Professional, January/February 1999, pp. 49-56. Appending Effort Analysis for All Activities 4