Tutorials and Workshops

The conference is now over. This page is for the historical record.

For a graphical view of the schedule, see the main program page.

Tutorial 1: Introducing Software Economics within SWE Project Courses

Presented by Daniel Port and Barry Boehm (both of the University of Southern California)

Monday, Feb 25, 11 a.m. - 5:30 p.m. (5 hours of learning time)

Overview

In 1996, USC switched its core two-semester software engineering course from a hypothetical-project, homework-and-exam course based on the Bloom taxonomy of educational objectives (knowledge, comprehension, application, analysis, synthesis, evaluation). The revised course is a real-client team-project course based on the CRESST model of learning objectives (content understanding, problem solving, collaboration, communication, and self-regulation). We used the CRESST cognitive demands analysis to determine the necessary student skills required for applying software economics and the other major project activities, and have been refining the approach over the last four years of experience, including revised versions for one-semester undergraduate and graduate project course at Columbia.

This tutorial presents our practice of introducing software economics within a real-client based software engineering project course. This practice has helped us evolve a number of general economic-based techniques such as risk-driven specifications, domain specific simplifier and complicators, and the schedule as an independent variable (SSIV) process model. The application of these techniques have contributed significantly to our overall positive results in terms of review pass/fail rates, client evaluations, product adoption rates, and hiring manager feedback. We will cover the basic process we follow to generate and evolve the course subject areas, an overview of our model based software engineering framework (MBASE/CeBASE), and provide highlights of particular software economics related principles and practices used within our graduate level software engineering course. Plentiful examples from actual student projects will be provided, and we will conclude with a list of classroom resources.

The following is an outline of the topics that will be covered:

  1. Cognitive demands of software engineering project courses
    1. Project clients for university software engineering project courses
    2. Course stakeholders and win conditions
    3. USCıs CS 577 course CRESST model
  2. Application of MBASE/CeBASE for software engineering project courses
    1. Overview of MBASE/CeBASE
    2. Use of models
    3. Software engineering economics in MBASE/CeBASE
    4. Risk driven modeling approaches
  3. Selections of CS 577 MBASE software engineering economics
    1. Shared Vision
      WinWin. IKIWISI and early prototyping. DMR style Results Chains.
    2. Requirements, Milestones, Lifecycles
      Expectations management (Simplifiers and complicators). Lifecycle process models (Schedule as an independent variable (SAIV) and fixed schedules). Cost estimation (Student COCOMO II).
    3. Scheduling
      MS Project
    4. Business case analysis
      System life cycle costs and benefits. Return on investment.
  4. Project Approach
    1. Metrics
    2. Monitoring and control
    3. Risk management
      CS 577 Top-10 risks. Project risk management. Risk-driven product and process level of detail.
  5. CS 577 Case Studies and Examples
    1. Nature of applications (real-client e-services)
    2. Best practices
    3. Pitfalls
    4. Client evaluation results
  6. Resources for your use


Tutorial 2: Measuring, Changing, and Measuring Changes in: Students' Attitudes Toward and Understanding of Software Engineering Process

Presented by David Klappholz (Stevens Institute), Lawrence Bernstein (Stevens Institute), and Catherine Kelley (Fairleigh Dickinson University)

Tuesday, Feb 26, 1:45 p.m. - 5:00 p.m. (3 hours of learning time)

Overview

We have developed an instrument (questionnaire), the ATSE (Attitude Toward Software Engineering) to measure CS students':

  • Attitudes toward Software Engineering Process
  • understanding of Software Engineering Best Practice
The instrument, is used in conjunction with the standard Felder Learning Styles Survey and the Academic Locus of Control Scale to analyze students' attitudes toward and understanding of software engineering process, to gauge changes in both of these as a result of taking software engineering courses and to correlate both initial attitude and knowledge with factors such as preferred learning style and attitude towards university education. The purpose of the instrument is to evaluate the relative efficacies of different approaches toward teaching software engineering process/best practice. We have successfully used the instrument in evaluating a number of different approaches to SE/Best Practice education and are developing a community of users.

In this tutorial we present ATSE, review experiences using it with the various other instruments, and teach other software engineering educators how to use it in their own classes in order to evaluate and tune their teaching styles and methods. Examples of a number of the questions in ATSE are appended below.

Presenters

David Klappholz is a former software development manager at Bell Labs with 35 years' experience directing small, medium, and large projects, both industrial and military.

Lawrence Bernstein is an academic with 27 years experience teaching computer science and supervising software research sponsored by such organizations as NSF, DoE, and IBM Research

Catherine Kelley is a cognitive psychologist whose current specialty is the evaluation of educational methods and materials.

Tutorial 3: Software Quality Across the Curriculum

Presented by Massood Towhidnejad and Thomas B. Hilburn (both of Embry-Riddle Aeronautical University)

Tuesday, Feb 26, 7:00 p.m. - 10:15 p.m. (3 hours of learning time)

Abstract

This tutorial will provide an overview of software quality concepts, processes, and techniques, as related to design of undergraduate computing curricula. It provides ideas and examples of how to incorporate and integrate software quality practices into such curricula.

Introduction

Software seems to be affecting us in every aspect of our lives; unfortunately, much of todayıs software is of low quality and does not adequately meet customer/user expectations or needs. The software industry is responding to our demands by spending increasing resources to improve the quality of their products. The latest industry surveys indicate that more than fifty percent of a software projectıs budget is spent on activities that are related to increasing the quality of the software. Unfortunately, most companies spend these resources in the testing phase, chasing defects that were introduced in the front-end part of development. Industry leaders have shown that they can reduce testing and warranty costs by more than half, when they start implementing practices that forces software quality control throughout the software development life cycle, with special emphasis in the earlier stages of development.

Computer science curricula do not typically address software quality issues, and do not provide educational units on how to build high-quality software products or how to integrate quality activities into the software development process. Therefore, students graduating with a bachelor degree in computer science often lack the necessary knowledge and experience in the area of software quality. However, the first job assignment of many of these graduates is in an area that is closely related to software quality (i.e. software testing, software maintenance, etc.) Employers of these graduates often complain about a new hire's lack of knowledge in the area of software quality. This situation closely resembles the situation we as educators faced about ten years ago. At that time, the software industry was asking us to incorporate more software engineering into our curricula. Ten years later, we see that more and more computing programs are incorporating software engineering as part of their required courses, and more recently we have seen the establishment of new undergraduate degrees in software engineering. With the recognition by ABET that software engineering is a recognized curriculum area, and the forthcoming guidance from Computing Curriculum 2001 for software engineering education, it is obvious that the software engineering degree is here to stay. We as educators have the opportunity and responsibility of delivering computing and software engineering curricula that ensure that our students are capable of developing high-quality software products.

Description

One of the major areas of software engineering, as specified in the SWEBOK (SoftWare Engineering Body Of Knowledge), is software quality. This tutorial provides an overview of software quality and the related concern of how it can be incorporated into an undergraduate curriculum. We start with a discussion of the nature of quality and why it is important. The tutorial addresses two general types of quality: the quality of the process, and the quality of the product. The tutorial presents various processes and techniques that are used to increase the quality of the software development process and the products the process produces. The "V model for software development life cycle² is used to provide a pattern for integrating software quality activities throughout the software life-cycle. The tutorial shows how the Personal Software Process (PSP), and Team Software Process (TSP) use such a pattern to incorporate quality activities at each stage of development. We present the concept of reviews and inspections, and show how they affect the quality of the product before and during implementation. There is also a discussion of software testing processes, techniques, and concepts. Testing is portrayed as an activity that spans the software life-cycle Finally, the tutorial provides a set of ideas on how we can incorporate software quality concepts and practices into an undergraduate curriculum. As part of this tutorial, we will engage the participants in a dialogue about there experiences in introducing software quality issues into their courses and curricula. To summarize, the following topics will be covered in this tutorial:

  • Software quality, what is it and why it is important.
    • Ethical and Professional Issues

  • Personal Software Process (PSP SM ) and Team Software Process (TSP SM ) and how they can be used to improve the quality of software.

  • Software reviews and inspections and how they can improve the quality of the software (i.e. review and inspection of requirements, design, and code)

  • Software testing techniques and processes (i.e. requirements, design, unit, integration, system, and acceptance testing)

  • Formal methods and software quality

  • Incorporating software quality techniques and processes into an undergraduate computing curriculum.
    • quality in the beginning
    • software quality in every software course
    • a dedicated software quality/testing course
    • software quality in project courses

Presenters

Massood Towhidnejad is Professor of Computer Science at Embry-Riddle Aeronautical University. Massood has substantial academic and industrial experience in software quality and testing, and he recently completed a sabbatical with Carrier Corporation where he worked as a Software Quality Assurance Manager.

Tom Hilburn is a Professor of Computer Science at Embry-Riddle Aeronautical University. Tom has been active in efforts to integrate software engineering into academic computing programs. He is a Visiting Scientist at the software Engineering Institute, where he works in developing activities and materials for promoting the use of individual and team software processes.

Tutorial 4: Issues in Commercial Law of Interest to Software Engineering Educators

Presented by Cem Kaner (Florida Institute of Techhnology)

Tuesday, Feb 26, 7:00 p.m. - 10:15 p.m. (3 hours of learning time)

Overview

This tutorial will be focused on UCITA with additional material on Article 2 of the Uniform Commercial Code, the Digital Millenium Copyright Act, and court cases arising out of these three.

The Uniform Computer Information Transactions Act (UCITA) is being proposed for adoption in all 50 of the United States. This law is controversial. Its success in legislatures has been mixed. However, many American courts in jurisdictions that have not adopted UCITA are deciding cases as if the key rules underlying UCITA were governing law. In effect, in many more than the two states (so far) that have adopted UCITA, we are seeing a substantial rewriting of American commercial law as it applies to computers and software.

This tutorial considers UCITA from the viewpoint of a law and ethics teacher in an American university. With starkly conflicting rules across the States, what should students learn? (NOTE: This is a U.S.-centric discussion because the legislation is specifically American. There have been conflicting speculations about international implications of the law but so far, these have yet to materialize.)

The author is an outspoken critic of UCITA. However, this tutorial's goal is not a critique of UCITA, but instead a presentation of the commercial law context of UCITA, as it applies to large and small software vendors, developers, and customers.

Background

Young American software developers and Computer Science students have limited knowledge of American commercial law. Often, I see an oddly mixed vision of caveat emptor (the seller can get away with anything), randomly disrupted by marauding bands of class action lawyers.
  • This is an incorrect view. Students are often surprised both by the extent to which customers have rights and the extent to which the opportunities for class action suits are constrained and predictable.

  • It is a counterproductive view because software developers working in companies have such an inaccurate sense of the legal issues they might raise when arguing to improve practices in their companies.

  • Similarly, independent developers unwittingly expose themselves to significant liability risks because they don't understand the extent their accountability to their clients or how to manage their liability.

Because commercial law will govern every contract for the development, support, sale and license of software and digital content, it is important to teach commercial law to computer science students.

Materials

Attendees be invited to join a yahoo-groups-based mailing list and document archive that I will create for the workshop. At that site, I'll post PowerPoint and OpenOffice slides that attendees can use in their classes. I will also post links to key papers and court cases. The mail list will be moderated and restricted admission. Its focus will be discussion of teaching of UCITA and other commercial law in Law & Ethics classes. I expect to keep it open for a few months after CSEET and might maintain it for a longer time if there is sufficient interest.

Presenter

Cem Kaner is an attorney, licensed in California. He has published extensively on UCITA, including a book, Bad Software: What to Do When Software Fails. His computer law papers are available at www.badsoftware.com. In recognition of this work, Kaner was elected to the American Law Institute, one of the two bodies that co-authors the Uniform Commercial Code.

Workshop 1: Developing Software Engineering Courses using Computing Curriculum 2001 (CC 2001) Documentation

Organized by J. Barrie Thompson and Helen M. Edwards (University of Sunderland, UK)

Monday, Feb 25, 1:45 p.m. - 5:00 p.m.

Overview

In the new millennium there will be an even greater demand for Software Engineering education across the world. The market need for Software Engineering courses is already demonstrated by the shortage of highly skilled software engineers: this is frequently discussed in both the popular industry's press (such as Computer Weekly in the UK) and also in academic circles (for instance several recent issues of IEEE Computer have had articles on this topic). Moreover, in academia there is a chronic shortage of able candidates to fill research studentships and research assistant posts. This is a global shortage as has been demonstrated at software engineering meetings around the world (for instance the Software Engineering Association's London workshop in 1999, and the IEEE Conference on Software Engineering, Education and Training in New Orleans in March 1999).

Thus there is a clear need to develop Software Engineering courses to meet local, national and international needs and evaluate the usefulness of the CC2001 documentation relevant to Software engineering.

Workshop Aim and Objectives

In this workshop the prime aim will be to evaluate the use of CC20001 in the development of Software Engineering courses.

In achieving this aim the our objectives are to examine:

  • Curricula : soft and hard options
  • Core and non core subjects and the place for optionality
  • Relationship with research specialisms
  • Delivery modes and teaching and learning mechanisms
  • Assessment
  • Meeting the needs of industry: with regard to existing and new staff
  • The role of professional bodies and aspects relating to accreditation
  • The role of professional bodies and aspects relating to accreditationand licensing.

Prior and Initial Activities

To ensure the time in the workshop is spent as effectively as possible the position papers of the participants are to be circulated in advance of the conference. In coming to the workshop the delegates are expected to bring with them a list of key issues that need to be considered (some of these will be highlighted in their position papers). Delegates will also be encouraged to study the details of the CC2001 relevant to Software Engineering.

Operation of the Workshop

  1. Recap main themes of position papers, mapping of these against aim of workshop and the topics listed above for examination.

  2. Break out into activity groups: each group to examine their topic and (i) identify the issues that are important (ii) prioritise these with explicit rationale (iii) provide evidence to justify these priorities: these should also be backed up by evidence.

  3. Feedback to full group: nominated speaker to feedback themes emerging from group - initially

  4. Comparative analysis of themes from each group: in "mixed" groups analyse the results from the feedback to identify common themes, conflicts etc.

  5. Synthesis of features, in the full group: specification of components that must be addressed in establishing post-graduate Software engineering course, populated by "mini scenarios" to illustrate most pertinent points.

Final Deliverable

A final outcome of the workshop will be the production of a report detailing the major recommendations relevant to the aim and the topics considered. This will be circulated to participants and a paper based on it will submitted for journal publication.

Workshop 2: First Year Software Engineering

Organized by Lynda Thomas and Mark Ratcliffe, University of Wales, Aberystwyth

Tuesday, Feb 26, 1:45 p.m. - 5:00 p.m.

Overview

We envision this workshop as a chance for Software Engineering Educators to share their challenges, successes and failures in teaching Software Engineering concepts to First Year Students. The specifics of the workshop will depend to some extent on the interests of the participants, but as a basis for organisation and discussion we will ask all participants to fill in a questionnaire to be provided in the conference registration kits.

We will begin the workshop by sharing the basic results of the questionnaires and then ask participants to share their biggest challenges in teaching Software Engineering to beginners, what they have done that has been successful (and any things they have tried that didn't work), what students have trouble understanding, what topics may not even fit in an introductory course, ...

We will then break the group up into interest groups on particular topics (eg. reuse, programming, professionalism, design, testing...) and those groups will brainstorm about one particular issue. The workshop will end with the groups sharing ideas.

Our hope is that this workshop will not only be useful in and of itself but will also provide a springboard for participants to find colleagues with similar interests and enthusiasms.



Workshop 3: Integrating Agile Practices into Software Engineering Courses

Organized by Laurie Williams, North Carolina State University), Michael Lutz (Rochester Institute of Technology), Greg Hislop (Drexel University), Michael McCracken (George Institute of Technology), Nancy Mead (Software Engineering Institute) and J. Fernando Naveda (Rochester Institute of Technology)

Wednesday, Feb 27, 10:30 a.m. - 3:45 p.m.

Overview

Agile software development methodologies claim to be superior for adapting to the changing needs of customers and projects and to the people on the team. As a result, these methodologies are steadily gaining interest and popularity in industry. Some examples of agile methodologies are Extreme Programming, Adaptable Software Development-Crystal, and Scrum. Each of these processes comprises a set of practices, some of which are currently considered best practices and are consistent with what is taught in software engineering courses today. Other practices, however, are controversial and run contrary to the focus of most curricular materials. As educators, we must assess the academic and technical values of emerging technologies and, if convinced of their worthiness, we owe it to our students to integrate them into our curricula.

Workshop Activities

Workshop activities will be organized into three types of sessions:

  1. Four half-hour presentations on agile methodologies: Extreme Programming Scrum, FDD, and DSDM. Each of these presentations will consist of: a). A summary of the development methodology b). The speakerıs opinion of which practices of the methodology are considered current best practices and which are more revolutionary/controversial/less proven.

  2. Thought-provoking discussion led by Nancy Mead.

    Agile methodologies: Deja vu all over again?

    Agile methodologies are the latest among self-proclaimed silver bullets for software development. In an effort to get away from the so-called sweatshop or assembly line mentality, many front-end software activities are severely curtailed, and there are a lot of new buzzwords. But is there really anything new here? When you look at individual practices, you see that no time is 'wasted' on inspection, but doesn't pair programming result in a form of continuous peer review? There is little or no time spent on architecture, but over time, doesn't 'refactoring' consume as much time as developing and maintaining an architecture? We need a healthy skepticism along with actual data to decide the proper place for agile methodologies.

  3. Facilitated group discussion on the revolutionary/controversial practices, particularly those that appear frequently in the four methodologies under study. As a group, we will discuss:

    • the prudence of integrating these practices in our curricula;
    • implications on Curriculum 2001, SWEBOK and other Software Engineering education reference points;
    • any experiences participants and conference attendees might have integrating the practices into the classroom;
    • research plans for assessing the effectiveness of integrating these practices into the classroom; and
    • communication plans for those of us who are interested in integrating agile methodologies in education.

Expected Result:

The result of the workshop will be a greater understanding among workshop attendees of emerging agile methodologies. Additionally, we identify two specific desirable outcomes from this workshop:

  1. The identification of participants interested in communicating about instructing students in agile practices and a plan to implement this communication via newsgroups, wiki web sites, etc.

  2. The identification of those interested in performing research on integrating agile practices into Software Engineering education, including plans for submitting research proposals.


 Conference program         Registration page         Main page