Supannika Koolmanojwong

WikiWinWin: A Wiki Based System for Collaborative Requirements Negotiation

Defining requirements is one of the most critical activities in the development of software intensive systems. The EasyWinWin system has been very good in capturing initial requirements involving heterogeneous stakeholders in over 150 client-developer requirements negotiations. However, it has been less easy to use in updating requirements and related information as a project proceeds and adapting to the evolving nature of the requirements. Because our clients are finding that wikis are easier to learn and use, and can organize information in a flexible and updatable manner, we have developed an initial version of a WikiWinWin system as a potential successor to EasyWinWin. We have conducted a case study of WikiWinWin, and the result shows that the initial WikiWinWin is basically good at facilitating stakeholder collaborative negotiation and learning, but has some limitations that we are now addressing.

The incremental commitment model process patterns for rapid-fielding projects

To provide better services to customers and not to be left behind in a competitive business environment, a wide variety of ready-to-use software and technologies are available for one to grab and build up software systems at a very fast pace. Rapid fielding plays a major role in developing software systems to provide a quick response to the organization. This paper investigates the appropriateness of current software development processes and develops new software development process guidelines, focusing on four process patterns: Use single Non-Developmental Item (NDI), NDI-intensive, Services-intensive, and Architected Agile. Currently, there is no single software development process model that is applicable to all four process patterns, but the Incremental Commitment Model (ICM) can help a new project converge on a process that fits their process drivers. This paper also presents process decision criteria in terms of these drivers and relates them to the ICM Electronic Process Guide.

Architected Agile Solutions for Software-Reliant Systems

Systems are becoming increasingly reliant on software due to needs for rapid fielding of “70% capabilities,” interoperability, net-centricity, and rapid adaptation to change. The latter need has led to increased interest in agile methods of software development, in which teams rely on shared tacit interpersonal knowledge rather than explicit documented knowledge. However, such systems often need to be scaled up to higher level of performance and assurance, requiring stronger architectural support. Several organizations have recently transformed themselves by developing successful combinations of agility and architecture that can scale to projects of up to 100 personnel. This chapter identifies a set of key principles for such architected agile solutions for software-reliant systems, provides guidance for how much architecting is enough, and illustrates the key principles with several case studies.

Principles for Successful Systems Engineering

Abstract This paper summarizes several iterations in developing a compact set of four key principles for successful systems engineering, which are 1) Stakeholder Value-Based System Definition and Evolution 2) Incremental Commitment and Accountability 3) Concurrent Multidiscipline System Definition and Development, and 4) Evidence-Based and Risk-based Decisionmaking. It provides a rationale for the principles, including short example case studies of failed projects that did not apply the principles, and of successful projects that did. It will compare the principles with other sets of principles such as the Lean Systems Engineering and the Hitchins set of principles for successful systems and systems engineering.

Experimental Evaluation of Wiki Technology and the Shaper Role in Rapid Interdisciplinary Requirements Negotiation

The challenges driven by multi-culture, multidiscipline stakeholders collaborating in a rapidly changing global environment necessitates an easily approachable mechanism for negotiating WinWin outcomes. Wiki has become an enabling technology for interdisciplinary collaboration. Following our initial development of a wiki-based requirements negotiation support tool – WikiWinWin, we experimented with using WikiWinWin to negotiate requirements in 20 real-client projects at University of Southern California (USC). Our initial results indicated better project outcomes were achieved as the use of the tool increased, as compared with the previous EasyWinWin tool.

Using Software Project Courses to Integrate Education and Research: An Experience Report

At University of Southern California (USC), CSCI577ab is a graduate software engineering course that teaches best software engineering practices and allows students to apply the learned knowledge in developing real-client projects. The class is used as an experimental test-bed to deploy various research tools and approaches for validation of new methods and tools. Various research data have been collected as partial basis for twelve PhD dissertations. This paper reports how research and education are integrated via project experiments and how the results strengthen future educational experiences.

A look at software engineering risks in a team project course

Risk identification, management, and mitigation are essential to the success of any software development projects. At the University of Southern California (USC), CSCI577ab is a graduate level software engineering course sequence that teaches the best software engineering practices, and allows students to apply the learned knowledge in developing real-client projects. This paper analyzes the risks encountered by teams, identifies the relationships between effective risk analysis and the success of the project, and discusses how risk patterns determine the students course of action. This paper also reports the top risks of software development in the software engineering class.

An Evidence-Based Systems Engineering (SE) Data Item Description

Abstract Evidence-based SE is an extension of model-based SE that emphasizes not only using SysML or other system models as a basis of program decisions, but also the use of other models to produce evidence that the system models describe a feasible system. Such evidence is generally desired, but often is not produced because it is not identified as a project deliverable in a Data Item Description (DID). Going forward with such unproven solutions frequently leads to large program overruns. Based on experience in developing and using such a DID on a very large project, we summarize the content and form of such a DID, and a rationale for its use. Its basic content is evidence that if a system were produced with the specified Architecture, it would:. • Satisfy the specified Operational Concept and Requirements; • Be developable within the specified Budget and Schedule; • Provide a superior return on investment over alternatives in terms of mission effectiveness; and • Provide satisfactory outcomes for the systems success-critical stakeholders. One key factor of the DID is that the content of the evidence be risk-balanced between having too little evidence (often the case today) and having too much (analysis paralysis). Thus, it is not a one-size-fits-all DID, but one which has ways to be tailored to a projects most critical evidence needs.

Educating software engineers to become systems engineers

Our two-semester USC core software engineering project course CS577ab devotes its first semester to having students learn and do systems engineering on a real-client project. This requires a good deal of just-in-time lectures, tutorials, and homework to prepare the students, and feedback in terms of mentoring, artifact grading, and live milestone reviews to help them succeed. This paper provides some initial motivation and context; discusses our approach to introduce systems engineering into software engineering relative to that in the GSwE 2009 curriculum guidelines, SEBOK draft 2010, and SWEBOK 2004; describes the course practices during the systems engineering and software engineering semesters; and summarizes the project results and conclusions.

Comparative experiences with electronic process guide generator tools

The primary objective of all software engineering courses is to help students learn how to develop successful software systems with good software engineering practices. Various tools and guidelines are used to assist students to gain the knowledge as much as possible. USCs Center for Systems and Software Engineering (CSSE) has found that the keystone course in learning software engineering is a year-long real-client team project course. Over the last ten years, CSSE has evolved a set of guidelines for the course, and has experimented with early tests for creating electronic process guides for MBASE (Model-Based (Systems) Architecting and Software Engineering) Guidelines using Spearmint/EPG. Currently, CSSE has been developing and experimenting with Eclipse Process Frameworks (EPF) to situate the LeanMBASE Guidelines. This paper reports our comparative experiences of using the earlier and current tools to generate the electronic process guidelines. In our analysis, we used the objectives defined by Humphrey and Kellner[17] to compare the process tools. The evaluation identifies some research challenges and areas for future research work.