Group Project Software Management: A Guide for University Students and Instructors

Group Project Software Management: A Guide for University Students and Instructors

TOMMY YUAN

XIAOYU LIN

GANG LEI

First Edition

July 2019

About the Author

Dr. Tommy Yuan is a senior lecturer in the Artificial Intelligence research group within the Computer Science Department of the University of York, UK. He has over ten years’ experience in teaching MSc software group project. His approach particularly focuses on the use of industrial client such as British Telecom and Omnicom Engineering, and the use of industrial software quality assurance framework. Student feedback on this module has been consistently excellent as the industrial experience greatly improves their employability.

His official site is here: https://www-users.cs.york.ac.uk/~tommy/

PREFACE

This guide is primarily designed for university instructors and students who are involved in (industrial) software engineering group projects. The aim is to provide guidelines for carrying out and documenting the work in a standard manner.

Modern software systems are very sophisticated and normally developed by a team of engineers. There has been increasing research and reports on issues related to the teaching of software engineering team projects. Woodfield and Collofello [1], for example, discussed many problems observed in the teaching of team projects, such as the evaluation of teams and individuals, project selection and team formation. Gorla and Lam [2] explored the relationship in small software teams between the team’s personality composition and its performance. Wilkins and Lawhead [3] discussed the assessment of individual student contributions to a group project. There is, however, little discussion in the literature on the use of industrial projects in an educational setting. This guide intends to fill the gap by sharing our over many years practice in the use of industrial projects as a means for assessment and learning.

Prior to the adoption of industrial projects, project specifications were normally prescribed by the lecturer. This is fine as an academic exercise but students gained very little in terms of employability experience. To address this, an industrial contact was established who would prepare a few project briefs each year. The appropriateness of the projects was assessed by the academic staff against the cohort level and expected learning outcomes. The size of the project is typically designated to be around 400-500 person-hours, and this requires each student to work around 100 hours in order to earn the module credits.

A successful software team typically contains 4-6 students. Too many may cause communication overheads and too few might lead to skills shortage. Skill set is one of the more important considerations for team formation. Too often, teams with strong engineering skills may lack communication and leadership skills, while teams with every member confident to lead may find themselves struggling with programming. These are typical examples of unsuccessful team formation. Ideally, teams are formed with mixed and balanced skill sets, however creating balanced teams in practice is challenging – especially when there are a large number of students and the tutor does not yet know them well. To address this issue, we have devised and experimented with a few useful metrics for team formation.

First, as well as students’ grades for their programming test, students are asked to complete a self-assessment survey on their strengths and weaknesses in the areas of leadership and communication, analysis, design, coding and time management. The results of the survey, while not infallible, can be used as metrics for uniform distribution of skills to the teams. According to DeMarco and Lister’s [4] guidelines for creating productive teams, female members often play vital roles in making a team gel. Gender is therefore considered as one of the team formation metrics as well. DeMarco and Lister also considered the benefits of self-organized teams, but this might be difficult to achieve in an educational setting for reasons of fairness. However, we have experimented with this in adding an extra entry to the survey: namely, a small wish. The entry allows a student to name a single person he/she would (not) like to work with, and this worked out very well. Further, taking advantage of the diversity of our multinational postgraduate cohort, we normally form teams composed from at least three different backgrounds; this provides students with opportunities to experience different cultures. For students from different cohorts, mixed cohort might be used as a metric as well. In practice, though, it is not necessary to satisfy all of these possibilities as long as the skills sets are well spread out.

A potential issue with team software projects is the definition of a fair marking policy to motivate individual team members. On the one hand, Demarco and Lister [4] suggest that joint product ownership prompts good team unity, and this implies that each member should receive the same mark for the group delivery. On the other hand, this may not reflect an individual member’s true effort or contribution to the project. It does tend to happen each year that a few struggling students rely on their teammates to pass this module, and here individual discrimination might be needed. To achieve the right balance is not easy in practice. One way to address this is to use peer assessment together with a reflective individual report from students on their team project experience. From our experience, team members are well motivated under this policy.

We have adopted and made use of industrial software projects for a number of years. Teams were well motivated to tackle industrial problems by interacting with industrial clients. The effectiveness of using industrial projects for assessment and learning is apparent. All our teams performed well with excellent cohort average grades, and student feedback scores for the module are also outstanding. The success of these, we believe, is built on good practices for team formation and a fair marking policy, as well as a good quality assurance framework on the process and product standard for a group software project. 

The book intends to share our quality assurance framework with you. The remainder of the book is organised as follows：

●       Chapter 1 - QA Planning specifies the working procedures that will lead to the production of a quality software system.

●       Chapter 2 - Project management provides a frame of reference for project management activities.

●       Chapter 3 - General Documentation Standard specifies the information that a document should contain.

●       Chapter 4 - Requirement Specification Standard describes the format of, and information which must be supplied in, requirement specifications produced in a software engineering group project.

●       Chapter 5 - Design Specification Standard is to be used to aid the production of a design specification which is a complete and accurate translation of the client’s requirements into a description of the design elements necessary for the implementation phase.

●       Chapter 6 - Test Procedure Standard is to provide instructions to the production of good quality test documentation.

●       Chapter 7 - Review Standards is to specify the conditions for the successful conduct of reviews of significant project items.

●       Chapter 8 - Operating Procedure & Configuration Management Standard is to specify procedures enabling all items produced by a group project to be properly controlled.

●       Chapter 9 - Java Coding Standards is to provide a set of rules and guidelines for the production of high quality Java programs.

●       Chapter 10 - Producing a Final Group Report specifies the format of the end of project group delivery.

●       Chapter 11 - Producing a Final Individual Report provides guidelines for the length and format of the individual report.

In addition to the quality assurance guidelines, this book also provides a case study in the appendix in order to provide readers with a more intuitive and quick grasp of the idea and operation of software project management.

ACKNOWLEDGEMENTS

A large number of people have contributed to the evolution of this guide over the years. We would like to thank everyone who have commented on previous edition and made constructive suggestions for changes. We would particularly like to thank our families, for their love, help and support while we are working on this book.

CONTENTS

About the Author

PREFACE

Chapter 1 Quality Assurance Plan

1.1 Introduction

1.2 Project Organisation

1.3 Meetings and Reviews

1.4 Documentation

1.5 Software Configuration Management

1.6 Problem Reporting and Corrective Action

1.7 Tools, Techniques and Methodologies

1.8 Summary of QA Manager’s Responsibilities

Chapter 2 Project Management

2.1 Introduction

2.2 Organisation

2.3 Major Activities

2.4 Project Planning

2.5 Project Monitoring

Chapter 3 General Documentation Standards

3.1 Introduction

3.2 Minutes of Meetings

3.3 Documents

3.4 Production and Inclusion of Diagrams

3.5 An Example Minutes

Chapter 4 Requirement Specification Standards

4.1 Introduction

4.2 Relevant QA Documents

4.3 General Approach to Requirement

4.4 Outline Structure

4.5 Decomposition Description

Chapter 5 Design Specification Standards

5.1 Introduction

5.2 Relevant QA Documents

5.3 Outline Structure

5.4 Decomposition Description

5.5 Dependency Description

5.6 Interface Description

5.7 Detailed Design

Chapter 6 Test Procedure Standards

6.1 Introduction

6.2 Relevant QA Documents

6.3 General Approach to Testing

6.4 Test Plan

6.5 Test Specifications

6.6 Test Result Reporting

6.7 Baselines

6.8 An Example of Test Log Form

Chapter 7 Review Standards

7.1 Introduction

7.2 Review Overview

7.3 Selecting a Review Team and Arranging a Meeting

7.4 Distribution of Relevant Documents

7.5 Conduct of the Review

7.6 Checklist for All Documents

7.7 Design Specification Review

7.8 Test Specification Review

7.9 Software Verification Review

Chapter 8 Operating Procedures & Configuration Management Standards

8.1 Introduction

8.2 Software Configuration Management

8.3 Problem Reporting and Corrective Action

Chapter 9 Java Coding Standards

9.1 Introduction

9.2 Code Organisation

9.3 Identifier Naming Conventions

9.4 Class Organisation

9.5 Comments

9.6 Indentation

9.7 Language Features

Chapter 10 Producing a Final Group Report

10.1 Introduction

10.2 Documents Produced for The Final Delivery

10.3 Structure of The Final Delivery

Chapter 11 Producing a Final Individual Report

11.1 Introduction

11.2 The Individual Report

11.3 Submission Method

References

Appendix Case Study

A.1 End of Project Report

A.2 Requirements Catalogue

A.3 Test Report

A.4 Project Maintenance Manual

A.5 User