Jay-Evan J. Tevis
Department of Computer Science
LeTourneau University
Longview, TX
jaytevis@letu.edu
Use of a Group Project



A group project may be added as a component of
a software engineering course or course sequence
Its goal: Students work as a team to design and
build a large software system for a real-world
situation
Probable result: Because of the students’ lack of
real-world project experience, they will most likely
handle the project as a typical programming
assignment (that, in this case, lasts the whole
semester)
Characteristics of a Programming
Assignment Approach
Students are loosely-organized into a team
 They are given some general directions on the
software to build
 They heroically attempt to build the software without
any established requirements or a design
 They struggle to make it all look like a wellimplemented and tested software application

Key Weaknesses of an Application
Built using this Approach
Has not satisfied any baselined requirements
(because none exist)
 Has not followed a baselined design (because none
exists)
 Has not been adequately tested because of the lack
of baselined requirements and test cases
 Could not be built again the same way

 Lack of any project planning
 Lack of any project tracking and oversight of the time and resources
needed to accomplish the project
What is a Baseline?
Definition of a Software Baseline



A configuration management concept that helps
practitioners to control change without seriously
impeding justifiable change
IEEE Definition: A specification or product that has
been formally reviewed and agreed upon, and that
thereafter serves as the basis for further
development, and that can be changed only
through formal change control procedures
It is a milestone in the development of software
and is marked by the delivery of one or more
artifacts that have been approved as a
consequence of a formal technical review
A Different Approach for a
Group Project


We use an approach that goes beyond the
concepts and skills taught in a traditional computer
science curriculum
Our approach incorporates software engineering
and software project management, and does so
from an industry perspective
A Software Engineering Approach


Software engineering is defined as “the application
of a systematic, disciplined, quantifiable approach
to the development, operation, and maintenance
of software; that is, the application of engineering
to software” (Pressman)
Software engineering requires the use of specific
processes, methods, and tools with a quality focus
foundation in order to develop software
Sample Elements of
Software Engineering
Software life cycle models
 Requirements gathering and analysis techniques
 Design methodologies
 Standards and metrics
 Specifications
 Formal reviews
 Testing techniques

Emphasis on Key Process Areas of
Project Management (SW-CMM, Level 2)





Project planning
Project tracking and oversight
Requirements management
Configuration management
Quality assurance
5 - Optimized
4 - Managed
3 - Defined
2 -Repeatable
1 - Initial
Objectives for Using These Practices


Take advantage of the synthesis of computer
science, engineering, and project management
Build a quality product that
 Meets user requirements
 Has a robust design
 Is adequately tested
 Finished on time and within budget
Two-Course Sequence: First Course
 Software engineering process, the SW-CMM, and
software life cycle models
 Object-oriented requirements analysis and design
of a board or card game
 Creation of a requirements specification and a
UML-based design
 Translation of the requirements and design into a
completed software application
Two-Course Sequence: Second Course
 Software testing techniques
 Group project that is six to seven weeks long
 Software project management
○ Software metrics
○ Estimation for software projects
○ Risk management
○ Quality management
○ Change management
Overview of the Remaining
Presentation
Group Project Organization
 The Group Project in Operation
 Results from Past Group Projects
 Conclusion and Future Work

Objective of the Group Project




Given a software development problem and a
software development group …
the student will apply software engineering and
software project management principles and
practices …
in various assigned roles …
required to complete the …
 Object-oriented requirements analysis
 Object-oriented design
 Construction
 Testing

for a software product
Organizational Structure
Project
Management
Elijah Lofgren
Software Engineering
Directorate
Customer
Liaison
Dr. Tevis
* Stephen Brown
Joshua Millet
Requirements
Management
Software
Design
Quality
Assurance
* Spenser James
Aaron Cutbirth
Josh Haines
Jon Hersack
Aaron Hume
Erik Lindow
* Caleb Reinking
Peter Moore
Daniel Patten
Gary Raduns
* Kim White
Silas Brill
Brett Clark
Austin Eyler
Daniel Ferguson
Michael Roettger
Configuration
Management
C++ Software
Construction
Java Software
Construction
(Contractor)
* Robert Whiting
Ben Cooley
James Denton
Brett Smith
* Benaiah Henry
Evan Allrich
Dave Estes
Bill Tuscher
Role of Project Manager







Based on the task network, the organizational responsibilities, and
the project objectives, construct an initial timeline chart for the
project
Maintain the timeline chart over the life of the project by getting
subtask information from the team leaders and updating the status
of all tasks as information becomes available
Submit updated timeline charts to the Software Engineering
Director before each directorate meeting and as requested
Use the timeline chart to brief the current status of the project at
each directorate meeting
Report any project abnormalities, problems or delays to the
Software Engineering Director
Collect artifacts after each formal review from Requirements
Management, Software Design, Software Construction, and Quality
Assurance that need to be baselined
Submit these artifacts to Configuration Management for baselining
Task Network for the Organizational
Software Development Process (Version 4)
(SED) Discuss software
needs and project scope
with customer
Test Readiness
Review (TRR)
(QA) Do validation and
system testing
Note: If formal approval does not
occur following a review or audit,
this will require an implied return
to the previous non-review
step in the process
(SED) Create
preliminary software
development
plan (SDP)
(RM) Do preliminary
identification of
software
requirements (SRS)
(RM) Identify and
record software
requirements (SRS)
(RM) Create interface
requirements
specification (IRS)
(RM) Create OORA
model (SRS)
(SED) Update software
development
plan (SDP)
Software
Requirements
Review (SRR)
(SD) Create
architectural
design model (SDD)
(QA) Create validation
and system
test cases (STD)
(QA) Determine
qualification methods
for requirements (STP)
(SD) Create interface
design description
(IDD)
(SC) Do product build
and
integration testing
(SC) Construct source
code
and do unit testing
Critical Design
Review (CDR)
(SD) Create
componentlevel design (SDD)
Test Outcome
Review (TOR)
(SC) Create software
version description
(SVD)
Functional and
Physical
Configuration
Audits (FCA/PCA)
(CM) Deliver
software and
documentation
Preliminary Design
Review (PDR)
List of Formal Reviews
Software Requirements Review
 Preliminary Design Review
 Critical Design Review
 Test Readiness Review
 Test Outcome Review
 Functional Configuration Audit
 Physical Configuration Audit

Format for the
Software Requirements and Testing Table
Req. ID
Status Requirement
Description
Initial
Added
Changed
Deleted
Qual. Test
Type Case
Analysis
Demonstration
Inspection
Test
Input
Data
Expected Actual
Output
Output
Passed
Test?
Use case diagram
Problem-domain
class diagram
System-level
state diagram
Interface requirements specification
Design-level class diagram
Identification of attributes
and methods for each class
Interface design description
Source code files
The results from performing the test cases
Updated and detailed class diagram
Corrected source code
Software version description
Reasons for Adapting the Group
Project



Number of students enrolled in the course
Lessons learned from previous projects
Feedback from the students on the group project
Example Adaptations



The course needs to be held on MWF rather than
T-Th to accommodate the scheduling of the formal
reviews
The project needs to have a written policy on the
use of laptop computers during the class meetings
To create more robust teams, we assign students
to a team based on student preferences and on
their performance in previous computer science
courses
The Software Engineering Director



This position is filled by the course instructor
The role needs to be performed sincerely and
completely as an integral part of the software
development company
The director should be able to
 Act as the moderator at class meetings and formal reviews
 Make decisions on the direction of the project as it occurs
 Approve changes in the schedule
 Baseline project artifacts
 Handle dissatisfied employees (i.e., students) in the company
 Reassign team leaders or members if a team fails to fulfill its
responsibilities or needs help
Major Keys to Success of the
Group Projects
A prescribed software process
 Clearly defined team roles
 Good organizational skills of the project manager
 Good performance by the team leaders

Example Experiences Gained by
each Student






Depends on the role of each team
Project manager – learned about the challenges of
teams not completing their tasks on time
Requirements management team – learned about the
effort to gather and document user requirements
Design team – learned about the chore of creating a
design based on pages of user requirements
Construction team – learned about the difficulties of
translating a design into source code
Quality assurance team – learned about the
importance of well-defined and quantified requirements
and well-written test cases
Skills that are Learned and
Practiced






Communication skills by speaking in front of a group
Travel skills from planning a hypothetical trip to a
location for a formal review
Coordination skills from working as a team and with
other teams
Leadership, followership, and delegation skills working
as a team leader or team member
Time management skills by following a timeline chart
and finishing tasks on schedule
Discussion skills in handling comments, questions,
arguments, and compromises in a formal review
Summary



A group project should be more than just a semester-long
programming assignment
It can be an opportunity for students to learn, experience,
and use industry-style software engineering and software
project management techniques
We have described our approach for doing this
 Group project organization
 The group project in operation
 Results from past group projects

In this group project approach, students experience some
of the responsibilities, events, stress, and elation that
come with project work in industry
Future Plans

Continue incorporating
 Industry processes, methods, and tools into the group project
 Lessons learned from students and recommendations from
industry professionals

Include accounting students in the next group project
 Provide a prediction of project costs
 Establish a budget
 Track the actual dollar costs of the software development effort
as the project proceeds
 Bring cost data into the decision-making discussions of the
project
GROUP PROJECT WEBSITE
www.letu.edu/people/jaytevis/SoftwareEngineering/software-engineering.html
ANY QUESTIONS?