USC's Two Semester Software Engineering Graduate Project Course

Transcription

1 USC's Two Semester Software Engineering Graduate Project Course A. Winsor Brown Computer Science and USC Center for Systems and Software Engineering, University of Southern California Los Angeles, CA , USA and Supannika (Sue) Koolmanojwong Computer Science, University of Southern California Los Angeles, CA USA ABSTRACT For over 12 years, USC's Computer Science (CSCI) Department has been offering a two-semester software engineering course designed by Dr. Barry Boehm and required course for the CS department's Specialization in Software Engineering. From the beginning, it has been doing real projects for real clients. The courses focus on activities not normally covered by regular computer science. While the focus is on software engineering of the projects, the project is done in the context of systems engineering, employing the Incremental Commitment Model (ICM). Project teams are self-organizing and select the projects they wish to work on. Over the years, various online tools have been developed specifically to support the courses. Keywords: Incremental Commitment Model (ICM), Electronic Process Guide (EPG), Distance Education, Real Projects For Real Clients, Systems Engineering, Software Engineering. 1. INTRODUCTION Software engineering project courses provide a way for software engineers in training to both learn about their trade and put it into practice. Such courses, especially with large enrollments, up to about 200 students for CSCI577a, require special tools to support them in addition to the expected software engineering tools for architecture and design, configuration management, and bug and issue tracking. PhD students have evolved many of the coursespecialized tools over the years as these tools have been used to gather data for their theses. [1] 2. COURSE CONCEPT For these courses, Software Engineering is defined as the disciplines that distinguish the coding of a computer program from the development of a software product. These "real projects for real clients' courses" stress the topics that are not the focus of classic computer science as shown in Figure 1. Figure 1. CS Traditional vs. SE focus From the beginning, students are told that the intent is to prepare them for software leadership careers through the 2040 s, including balancing agility with discipline and COTS/OSS, model, and service-based and network centric systems. All these considerations are integrated via Value- Based Software Engineering (VBSE), Incremental Commitment Models (ICMs) [2], and project experience. Real clients for real projects In the beginning, projects came from the USC Libraries, which often had niche systems they wanted but, with limited funding, little support from the campus-wide IT department. Other departments, also wanting niche or specialty systems heard about the projects and their "free" labor. CSSE itself has occasionally been a client for specialty projects and tools, including those for the course itself. For the last several years, however, the bulk of the clients come from the USC University Neighborhood Organizations (UNO) and other not-for-profit organizations that are part of an expanding network of contacts that UNO has developed over the years. The course also takes some for-profit small organizations who propose projects. Teams Teams are self-selecting and "bid" on projects using a preference ranking. Projects are described with three or four paragraphs of descriptions that do not explicitly identify the client contacts. Some projects are initially scoped and identified as "one-semester projects," or projects that can be completed in one semester, typically either asking for evaluations of COTS page alternatives or using COTS frameworks, although recently the course has done several projects using network centric services. Since there are invariably more projects "proposed" than teams to

2 serve them, the projects are assigned to teams on a "least regrets" basis. The teams are expected to have six-or-seven on-campus students, supplemented by one-or-two off-campus students who participate via USC's Distance Education Network (DEN). DEN provides both live and delayed streaming video of the lectures. Most of the DEN students are working professionals who are all over the country. After teams based on on-campus groupings are formed, the DEN students get to state their preferences of the selected projects. DEN student roles in the first semester are given to them. In addition to providing Independent Integrated Verification and Validations through evaluations of student documentation packages, some are asked to play the role of System/Project engineer working closely with the client (even if remote). If there are two DEN students on a project, the second one might play the role of Quality Focal Point, gathering data and analyzing "defect" data coming from various sources on the project. During the second semester, DEN students are permitted to play almost any role(s) for which they are suited. Unfortunately, with less than one-half of the students continuing into the second semester, the course has to provide additional resources. These have been coming from a pool of Directed Research (DR) and Unpaid Interns (UIs). Note: CSCI 577a and CSCI577b are four unit courses, yet most other CSCI courses are three units; many students do not want to pay for a full four units for the spring semester but want to work on helping to complete their projects, thus a two unit DR fits in quite well. For projects that continue into the spring we seldom let a project go forward with less than three of the original team members, but occasionally there are exceptions, some of which are disastrous and others are wildly successful. Occasionally, despite warnings to the students about "honoring commitment" (for which there are grade consequences) and frequent monitoring of student continuity, individual special cases arise. In an attempt to fulfill CSSE's commitment to clients who start in good faith on two semester projects, we are forced to run "off-thebooks" projects using just DR and unpaid interns students, especially when there is a critical mass DR/UI students who worked on a project during the first semester. NOTE: Those DR/UIs not selected for working on 577b projects are used by CSSE to test and enhance the CodeCount tool suite CSSE provides. Students Students in the course come from various departments on campus. The majority of the students are foreign nationals in computer science, and only some of them have had any real work experience. The other department frequently represented is Systems Architecting and Engineering which cross lists CSCI577a and CSCI577b as valid courses. Occasionally, EE graduate students will enroll, and many of them end up switching to CS with a healthy dose of software engineering courses. Process and methods It is not possible to run such a large class without having relatively uniform methods and processes, such as the ICM, and especially its adaptation for CS577ab, the Instructional Incremental Commitment Model for Software (IICM-Sw). Fortunately, a CSSE developed Electronic Process Guide (EPG) that is based on IBM/Rational's "Rational Method Composer" supports the IICM-Sw [3]. In order to grade team's work, there also needs to be a uniform set of documentation, depending on the type of project. For that, the EPG provides guidance and templates for the documents the students generate. While CSCI 577ab use relatively small projects, the students document them just enough to be like medium-sized real projects. The amount of documentation however is balanced by its use in projects that come back for enhancements or need longer transition times, as explained later. 3. LIFECYCLE MODELS Overview of the Incremental Commitment Life Cycle Model (ICM) An overview of the ICM life-cycle process (Boehm 2008) is shown in Figure 2.

3 Figure 2. Overview of the Incremental Commitment Life-Cycle Process The ICM identifies the following key process principles as critical success factors: Stakeholder Satisficing 1 : Identify and engage key stakeholders (i.e., those critical to success) early and often to validate and re-validate requirements, solutions and plans, and to discuss potential and proposed changes. Incremental and Evolutionary Growth of System Definition and Stakeholder Commitment: Establish and apply a robust framework for evolution, including stakeholder interaction and agreement processes that gradually build understanding and trust, enabling objective tradeoff analyses and resulting in incremental commitments to plans to move forward. 1 "The word satisfice was coined by Herbert Simon as a portmanteau of 'satisfy' and 'suffice' meaning to meet criteria for adequacy, rather than to identify an optimal solution. [Wikipedia; Satisficing: Iterative System Development and Definition: Iteratively refine tradeoff analyses, requirements, solutions, and plans based on new information, new needs, and new technologies. Concurrent System Definition and Development: Define, analyze, and refine requirements and solutions concurrently, especially in environments in which legacy and commercial components factor into the solution. Refine requirements as more is known about constraints on the solution and to adapt to changes in mission and business needs. Risk Management Through Risk-Driven Anchor-Point Milestones: Apply risk-driven milestones to synchronize and stabilize activities and products that are concurrent, iterative, and evolving. Evaluate business, technical, and operational feasibility by independent experts, discuss risks and risk-management plans, and decide whether or whether not to proceed. Figure 2 also shows how ICM spans the full life cycle process from concept exploration to operations. Each phase concludes with an anchor point milestone review. At

4 each anchor point, there are four options, based on the assessed risk of the proposed system. Some options involve go-backs. The sets of options result in many possible process paths. The "negligible" path means that the only activities needed for the next phase are bringing the documents, and especially the Feasibility Evidence Document, up to the level needed by the next anchor point. The total system life cycle is divided into two stages: Stage I of the ICM (Definition) has three decision nodes, each with four options per node, culminating with incremental development in Stage II (Development and Operations). Stage II has an additional two decision nodes, again with four options per node. One can use ICM risk patterns to generate frequently used processes with confidence that they will fit the situation [4]. Initial risk patterns can generally be determined in the Exploration phase. One then proceeds with definition and development approach as a proposed plan with risk-based Feasibility Evidence at the VCR milestone and each subsequent milestone, adjusting plans and updating Feasibility Evidence in later phases as necessary. Risks associated with the system drive the life cycle process. Information about the risk(s) (feasibility assessments) supports the decision to proceed, adjust scope or priorities, or cancel the program. By comparison with the software-intensive, single development increment delivery of the Rational Unified Process (RUP) by IBM/Rational Corporation [5], the ICM also addresses hardware and human factors integration. It extends the RUP phases to cover the full system life cycle, including the following anchor-point milestones: Exploration Commitment Review (ECR), Valuation Commitment Review (VCR), Foundations Commitment Review (FCR), and one or more Development Commitment Reviews (DCRs) and Operations Commitment Review (OCRs). The ICM anchor-point milestones are focused on synchronizing the high degree of concurrency surrounding complex systems development with the stakeholder commitments needed to move forward. These milestones look at concurrent activities, which may span independently developed systems or subsystems, with a view toward synchronizing, stabilizing, and assessing risk before obtaining commitment to proceed to the next phase. An Incremental Commitment Model for Software (ICM-Sw) While developing and evolving the "Model Based [System] Architecting and Software Engineering" (MBASE) software lifecycle process model, a pre-cursor to IICM-Sw, CSSE (nee Center for Software Engineering, CSE) found that the RUP was the closest commercially supported software development life cycle model. RUP had concurrent activities and phases as shown in Figure 3. While it had phases, it did not contain anchor points, where the pre-cursor of commitment reviews, Architecture Review Boards [6], could be held. The MBASE anchor points were added giving MBASE/RUP as also shown in Figure 3. Figure 3. RUP with MBASE Anchor Point For the ICM subset for Software (ICM-Sw), which is now used in USC's CSCI577ab Software Engineering project course, it was clear that system ICM's Development Phase was actually composed of RUP/MBASE's Construction and Transition phases. The concept of Transition, especially of software onto its system/hardware platform, is a separate activity like integration. This also meant a need for additional, software specific commitment review, a Transition Readiness Review (TRR). Furthermore, RUP's Inception phase was appropriately refined into Exploration and Valuation phases, as shown in Figure 4 that comes from the Electronic Process Guide [7] for CSCI577ab.

5 Figure 4. ICM-Sw Anchor Points Product, property, process and success models Value based software engineering as practiced in CSCI577ab and ICM for systems are based on even more fundamental models. These four fundamental models are shown in Figure 5. development approaches, which is dubbed "Architected Agile" in the EPG and IICM-Sw. The current version has added variants for teams that use Non-Development Items (NDI; AKA COTS and major Open Source components) or Network Centric Services (NCS) such as those that are found in cloud computing environments. Timelines The IICM-Sw had to be mapped onto the CSCI577ab time lines. This was accomplished as shown in Figures 7 and 8. Figure 5. ICM P3S Model Integration Framework The important part is the process that is used to integrate specific models for a specific project, as shown in Figure 6. Figure 7. Two Semester Projects Figure 6. ICM-Sw & P3S Model Integration Process EPG versions The first version of the EPG addressed only new project Figure 8. One Semester Projects with Artifacts

6 4. COURSE TECHNICAL CONTENT Traditional Software Engineering Tools Beyond the typical tools that students have to use, such as compilers, IDEs, and Microsoft Project, the course teaches the use of COCOMO II for cost estimation, IBM/Rational's UML 2.0 modeling tool Rational Software Modeler, Subversion for configuration management, and Bugzilla for bug tracking and (mis)used for defect and issue tracking during the early phases. Other tools Tools developed specifically for CSCI577ab include one for "Benefits Realization Analysis" using Visio Diagrams; a Twiki based WinWin negotiations tool for requirements elicitation and prioritizations (mis)named WikiWinWin; a tool to help with the (distributed) analysis of risks called DART; a tool for identifying COTS mismatches called istudio, and an effort reporting system used by project managers in their on-going monitoring of teammates effort (as well as providing a base for research). These special tools are available for any educator willing to put in the time to install on their own equipment and master them. For off-the-books projects For the off-the-books projects running in parallel with CS577b projects, special tools have been developed to decrease the amount of time put into continually updating documents and to simplify requirements negotiations. For documenting an offthe-books project, a true Wiki was developed with a hierarchical set of pages devoted to each project, and a home page that provides guidance to the users of the Project Wiki. Both for offthe-books and light-weight enhancements of projects, a Goals and Objectives WinWin Negotiation Wiki was developed, again with a base page that explains it use and a page devoted to each project called GOWiki. The teaching staff will also use the G&O WinWin Wiki prior to the beginning of the course in the fall to help correctly scope projects as well as to demonstrate prospective client's active participation. 2. Boehm, B., "System Development Process: The Incremental Commitment Model," chapter 2 of Human- System Integration in the System Development Process: A New Look, 2007, with updated 2008 terminology and charts. USC CSSE Technical Report "USC-CSSE System Development Process: The Incremental Commitment Model (Barry Boehm)" 3. Supannika Koolmanojwong, Pongtip Aroonvatanaporn, Itti Charoenthongtrakul, USC CSSE Technical Report "Incremental Commitment Model Process Guidelines for Software Engineering Class" USC CSSE Technical Report USC-CSSE ( 4. Barry Boehm, Jo Ann Lane, Supannika Koolmanojwong, "A Risk-Driven Process Decision Table to Guide System Development Rigor," INCOSE 2009 and USC CSSE Tech Report USC-CSSE Kruchten, P. (2004). The Rational Unified Process: An Introduction (3rd Ed.), Addison-Wesley, Boston MA, ISBN Maranzano, J.F.; Rozsypal, S.A.; Zimmerman, G.H.; Warnken, G.W.; Wirth, P.E.; Weiss, D.M., "Architecture reviews: practice and experience"; Software, IEEE Volume 22, Issue 2, Mar-Apr 2005 Page(s): EPG for IICM-Sw: These tools too can be made available to other academic institutions, especially ones that wish to use lighter-weight tools where possible. 4. CONCLUSIONS Over the years, CSCI577ab has evolved to use continually improving best practices for value-based software engineering of real projects for real clients. REFERENCES 1. Supannika Koolmanojwong, Barry Boehm, "Using Software Project Courses to Integrate Education and Research: An Experience Report," Proceedings of the nd Conference on Software Engineering Education and Training - Volume 00, CSEET, pp PhDs and CSCI 577ab