Everand Logo

Welcome to Everand!

  • Discover millions of ebooks, audiobooks, and so much more with a free trial

    Only $11.99/month after trial. Cancel anytime.

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

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

    By Tommy Yuan, Xiaoyu Lin and Gang Lei

    ()

    Read preview

    About this ebook

    This guide is primarily designed for university instructors and students who are involved in (industrial) software engineering group projects. The aim is to provide quality assurance guidelines for carrying out and documenting the work in a standard manner.
    In addition to the 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.
    Dr. Tommy Yuan is a senior lecturer in 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/
    LanguageEnglish
    PublisherLulu.com
    Release dateJul 28, 2019
    ISBN9780244205591
    Group Project Software Management: A Guide for University Students and Instructors

    Related to Group Project Software Management

    Related ebooks

    Computers For You

    View More
    View More

    Related podcast episodes

    Related articles

    • Article

      Driven By Skills

      Mar 19, 2020

      Driven By Skills
      4 min read

    • Article

      An Introduction To Rabbitmq

      Jun 29, 2021

      RabbitMQ is a Message Broker, which means that it can safely hold messages generated by applications and make them available to other applications. The main advantages are reliability, support for clustering and high-availability queues, tracing capa

      1 min read

    • Article

      AGILE: It Is All About Trust

      Oct 22, 2019

      AGILE: It Is All About Trust
      6 min read

    • Article

      Basic Concepts

      Jul 2, 2019

      A messaging system such as Kafka enables you to send messages between processes, applications and servers. Applications connect to Kafka to send or get data. Strictly speaking, a Kafka ‘topic’ is a unit of storage in Kafka: data in Kafka is stored in

      1 min read

    • Article

      Change Sustainability Your ROI Health Check

      Mar 28, 2019

      Change sustainability programs are as unique as each of the workplace projects themselves. They can be developed either to dovetail into the end of a change program where businessas-usual kicks in, or they can be integrated into a prototype rotation

      5 min read

    • Article

      Live, Learn, Leap

      Jun 3, 2019

      Live, Learn, Leap
      10 min read

    • Article

      Principles of Technical Leadership

      Mar 1, 2022

      IT staff is more than just a number on a spreadsheet. This information is valuable, but it does not tell the whole story. We’ll also need to know about your team’s project history, current (non-hired) CV, and the skills and positions they have—and wa

      2 min read

    • Article

      A Compass for Chief Executive Officers and Chief Learning Officers

      Aug 1, 2022

      Based on a 5 year study of the executive development industry, comprising interviews with over 200 executives, CLO's, CEO's, program designers and program developers, we have ascertained that the executive development field is at a critical crossroad

      18 min read

    • Article

      2 Time Management: The Impact On Wellbeing

      Aug 28, 2022

      Guest editors: While only a relatively small number of survey respondents said that the actual nature of architectural work had affected their wellbeing, far more identified problems with how and when the work must be completed. Some noted a signific

      3 min read

    • Article

      Putting The Team First

      Feb 25, 2018

      Putting The Team First
      6 min read

    Related categories

    Reviews for Group Project Software Management

    0 ratings

    0 ratings0 reviews

    What did you think?

    Tap to rate

    Review must be at least 10 words

      Book preview

      Group Project Software Management - Tommy Yuan

      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

      Enjoying the preview?
      Page 1 of 1