Concurrent Software Engineering Project
Authors: N. Stankovic; T. Tillo
Year: 2009

Introduction Most engineering problems are not tame but wicked (Rittel & Webber, 1973) or unbounded, meaning that there is no right or wrong solution such that quality becomes hard to assess before implementation. The design processes becomes complex due to new technologies, task interdependencies, and communication and coordination needs between people; so projects have to repeatedly search for satisfying solutions and deal with uncertainty. These present technical and nontechnical challenges that, in turn, require educated and experienced professionals who can produce quality products on schedule (Nikkei Business Publications, 2003). A crucial factor in successful projects was ongoing client participation and commitment (Terry & Standing, 2004), as was mutual respect and synergy between team members. The impact of interpersonal conflict was negative, regardless of how it was managed or resolved (Barki & Hartwick, 2001). Of course, good domain knowledge and technical skills are important, too. Unfortunately, the type of training being provided to software engineering managers at the university level results in students knowing how to use the tools, but not necessarily knowing why they are important, or what their role is within the effort (Peters, 2003). Process and project management and organizations are knowledge areas in the software engineering curriculum (e.g., The Joint Task Force, 2004), so similar problems and outcome can be expected there, as well as in other knowledge areas. For example, learning to program is essential for every engineer but generally considered hard, so programming courses often suffer high dropout rates. It might take up to ten years for a novice to become an expert programmer (Soloway & Spohrer, 1989). Even on a much smaller time scale of days and weeks, acquisition of knowledge is not linear. It is an opportunity driven process different for each person and affected by social complexity (Figure 1.) (Conklin, 2006). Successful designers iterate frequently through various design stages rather than using a linear (i.e., waterfall) process in which a downstream activity follows the immediate predecessor only when it has become completed (Guindon, 1990). The frequency of the iterations depends on the person's familiarity with the problem and solution domain (Cross, 2004). The process of engineering design is not a totally formal affair, and drawings and specifications come into existence as a result of a social process (Ferguson, 1992). However, managers and engineers are trained to plan for one activity or task at a time instead of a set of concurrent activities, so they assume linear progress (Figure 1), and apply feed-forward project planning methods, such as PERT or Critical Path. [FIGURE 1 OMITTED] Linearization is also found in education where we simply proceed from one topic to another as appropriate. That is not negative by itself because some courses may not require much creative thinking or reflection, but it creates an expectation that all coursework is a simple transaction between the instructor and the student. In a transactional system, most students act in response to the extrinsic motivation by simply working on their assignments as they come and performing the best they can at that moment. Courses that deal with complex problems and processes benefit from rework because this directly links together the phases and work products that have been worked on. Those courses should be accompanied by a transformational approach to coursework, and students should be encouraged to revisit and improve their past coursework and resubmit it. By looking back, students form a deeper understanding and learn that rework and constant improvements are important in real world projects. Active learning, or learning by doing, has been used in academia and training for a long time. Learning becomes active when students employ their creative skills during the learning process. …