It is generally accepted that the quality of a software system largely depends on the process used through its lifecycle. To cope with the complexity of changing software development process, an organization can put in place a Software Process Improvement Program. SPI programs are long-term, expensive, and difficult, as they often require cultural, technical, organizational, and procedural changes.
The fundamental problem is that developers don't know how to work together, distribute tasks among team members, coordinate these tasks, track and report the progress. Moreover, they seem to have trouble determining what are the deliverables of each task. As a result, developers waste valuable time worrying about management and teamwork mechanics when they should be investing it in more challenging and creative activities.
The Software Engineering community is convinced that good software development habits are not being taught in the classroom, let alone reinforced by laboratory work. Most software development courses do have a loosely defined software process that the students try to use without success and, as project deadline approaches, students spend long days coding the final product in a race against time. Sometimes teams do submit their project thanks to the heroic efforts of the very few.
Teaching process for the sake of process does not help anyone. Instead, process should be viewed as a tool to help both teams and individuals attain their goals. In this talk, we introduce the basic concepts of software process and we show how these concepts are being used in the delivery of our introductory course on Software Engineering.
Colloquia Series page.