Jay-Evan J. Tevis Department of Computer Science LeTourneau University Longview, TX [email protected]

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 well implemented 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

Software Engineering Directorate

Dr. Tevis

Customer Liaison

* Stephen Brown Joshua Millet

Project Management

Elijah Lofgren

Requirements Management *

Spenser James Aaron Cutbirth Josh Haines Jon Hersack Aaron Hume Erik Lindow

Configuration Management

(Contractor)

C++ Software Construction

* Robert Whiting Ben Cooley James Denton Brett Smith

Software Design

* Caleb Reinking Peter Moore Daniel Patten Gary Raduns

Java Software Construction *

Benaiah Henry Evan Allrich Dave Estes Bill Tuscher

Quality Assurance

* Kim White Silas Brill Brett Clark Austin Eyler Daniel Ferguson Michael Roettger

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 (SED) Create preliminary software development plan (SDP) (RM) Do preliminary identification of software requirements (SRS) (RM) Create interface requirements specification (IRS) (RM) Create OORA model (SRS)

Software Requirements Review (SRR)

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 (RM) Identify and record software requirements (SRS) (SED) Update software development plan (SDP) (SD) Create architectural design model (SDD)

Preliminary Design Review (PDR) Test Readiness Review (TRR)

(QA) Create validation and system test cases (STD) (SC) Do product build and integration testing (QA) Determine qualification methods for requirements (STP) (SC) Construct source code and do unit testing (SD) Create interface design description (IDD)

Critical Design Review (CDR)

(SD) Create component level design (SDD) (QA) Do validation and system testing

Test Outcome Review (TOR)

(SC) Create software version description (SVD)

Functional and Physical Configuration Audits (FCA/PCA)

(CM) Deliver software and documentation

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 Qual. Type Test Case Input Data Expected Output Actual Output Passed Test?

Initial Added Changed Deleted Analysis Demonstration Inspection 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/Software Engineering/software-engineering.html

ANY QUESTIONS?