1 / 45

Using Industry-Style Software Engineering and Project Management in a Group Project

This paper discusses the use of industry-style software engineering and project management in a group project for teaching software development principles and practices to students. It highlights the weaknesses of typical programming assignments and introduces the concept of baselining. The paper also describes a two-course sequence that incorporates software engineering and project management in the curriculum.

theola
Download Presentation

Using Industry-Style Software Engineering and Project Management in a Group Project

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Jay-Evan J. Tevis Department of Computer Science LeTourneau University Longview, TX jaytevis@letu.edu Using Industry-Style Software Engineering and Project Management in a Group Project

  2. INTRODUCTION

  3. 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)

  4. 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

  5. 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

  6. What is a Baseline?

  7. 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

  8. 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

  9. 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

  10. Sample Elements of Software Engineering • Software life cycle models • Requirements gathering and analysis techniques • Design methodologies • Standards and metrics • Specifications • Formal reviews • Testing techniques

  11. 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

  12. 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

  13. 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

  14. 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

  15. Overview of the Remaining Presentation • Group Project Organization • The Group Project in Operation • Results from Past Group Projects • Conclusion and Future Work

  16. GROUP PROJECT ORGANIZATION

  17. 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

  18. Organizational Structure CustomerLiaison * Stephen Brown Joshua Millet Software Engineering Directorate Dr. Tevis Project Management Elijah Lofgren Requirements Management* Spenser James Aaron Cutbirth Josh Haines Jon Hersack Aaron HumeErik Lindow SoftwareDesign * Caleb Reinking Peter Moore Daniel PattenGary Raduns Quality Assurance * Kim WhiteSilas BrillBrett ClarkAustin EylerDaniel FergusonMichael Roettger Configuration Management(Contractor) C++ SoftwareConstruction * Robert Whiting Ben CooleyJames DentonBrett Smith Java SoftwareConstruction* Benaiah HenryEvan AllrichDave Estes Bill Tuscher

  19. 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

  20. (SED) Discuss software needs and project scope with customer (SED) Create preliminary software development plan (SDP)‏ (RM) Identify and record software requirements (SRS)‏ (RM) Do preliminary identification of software requirements (SRS)‏ Software Requirements Review (SRR)‏ (SED) Update software development plan (SDP)‏ (RM) Create OORA model (SRS)‏ (RM) Create interface requirements specification (IRS)‏ (SD) Create architectural design model (SDD)‏ Preliminary Design Review (PDR)‏ (QA) Create validation and system test cases (STD)‏ (QA) Determine qualification methods for requirements (STP)‏ (SD) Create interface design description (IDD)‏ Test Readiness Review (TRR)‏ (SC) Do product build and integration testing (SC) Construct source code and do unit testing Critical Design Review (CDR)‏ (SD) Create component- level design (SDD)‏ (SC) Create software version description (SVD)‏ (QA) Do validation and system testing Functional and Physical Configuration Audits (FCA/PCA)‏ (CM) Deliver software and documentation Test Outcome Review (TOR)‏ 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 Task Network for the Organizational Software Development Process (Version 4)‏

  21. 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

  22. Format for the Software Requirements and Testing Table Req. ID Status Requirement Description Qual. Type TestCase Input Data Expected Output Actual Output Passed Test? Initial Added Changed Deleted Analysis Demonstration Inspection Test

  23. THE GROUP PROJECT IN OPERATION

  24. Software Requirements and Testing Table

  25. Group Project Web Page (top half)

  26. Group Project Web Page (bottom half)

  27. Use case diagram Problem-domain class diagram Artifacts from the Requirements Analysis Phase (Slide 1 of 2) System-level state diagram

  28. Interface requirements specification Artifacts from the Requirements Analysis Phase (Slide 2 of 2)

  29. Design-level class diagram Identification of attributes and methods for each class Artifacts from the Design Phase (Slide 1 of 2)

  30. Interface design description Artifacts from the Design Phase (Slide 2 of 2)

  31. Source code files Artifacts from the Construction Phase

  32. The results from performing the test cases Artifacts from the Testing Phase

  33. Updated and detailed class diagram Artifacts from the Delivery Phase (Slide 1 of 2)

  34. Corrected source code Software version description Artifacts from the Delivery Phase (Slide 2 of 2)

  35. RESULTS FROM PASTGROUP PROJECTS

  36. 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

  37. 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

  38. 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

  39. 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

  40. 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

  41. 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

  42. CONCLUSION AND FUTURE WORK

  43. 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

  44. 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

  45. GROUP PROJECT WEBSITE www.letu.edu/people/jaytevis/Software-Engineering/software-engineering.html ANY QUESTIONS?

More Related