CSE 7315: PLANNING AND MANAGING A SOFTWARE PROJECT
Syllabus
Course Description/Objective:
This course covers the process of planning and managing a software development project. Primary topics include planning, risk management, and estimating of cost, size and schedule. Additional topics addressed include the software development process, the SEI Capability Maturity Model, software lifecycle models, configuration management, quality assurance, metrics, and continuous process improvementInstructor: Dr. Dennis J. Frailey Adjunct Professor 972-344-8366 (voice) 972-344-7701 (fax) CSE7315@seas.smu.edu (internet) |
SMU Contact: Ms. Debra McDowellDepartment of Computer Science & Engineering 214-768-3080 debramcd@engr.smu.edu |
Course Handouts and Other Info
: http://www.seas.smu.edu/~frailey/cse7315/Office Hours: By appointment and by internet conversation.
(No Appointment Required for brief meetings after class)
____________________________________________________________________________
Mailing Addresses for Assignments and Exams:
|
For U.S. Mail: Southern Methodist University Computer Science and Engineering attn: Grader, CSE7315 P. O. Box 75275-0122 Dallas TX 75275-0122 |
For Overnight Mail: Southern Methodist University Computer Science and Engineering attn: Grader, CSE7315 6425 Airline Dallas TX 75275 |
____________________________________________________________________________
Schedule: Depends on Specific Section and Format. See web site:
http://www.seas.smu.edu/~frailey/cse7315
Exams: Midterm: 25% of grade
Final: 25% of grade
Text: Humphrey, Watts, Managing the Software Process. Reading, Mass.: Addison-Wesley Publishing Company, 1989. ISBN 0-201-18095-2.
Grading: 25% for software development plan (assignments 2 [draft] and 5 [final])
25% for each exam;
25% for assignments 1,3, and 4
Policy for Late Work: Short version: If you turn it in late, I grade it late.
Long version: As in the real world, the effect of late work is a function of the customer need. In this case, I (your customer) have scheduled time for grading of all assignments. If you do not get the assignment to me on time, I need to find some other opportunity to grade it. You get bottom priority, compared with students who turned their work in on schedule, and my time is limited. Therefore, the following "penalties" apply to late work:
- Grading may be late by an indefinite amount of time. In particular, results of assignments may not be returned when you want them -- in many cases, they will not be graded until well after the end of the semester, and perhaps not returned at all. This means it will be more difficult for you to gauge how well you are doing.
- A grade of Incomplete may be assigned, if work is not done by the end of the semester. NOTICE: if you intend to request a grade of Incomplete, you MUST turn in an incomplete request form no later than the last day of class. This form is available from the instructor.
- A grade of Failure (F) will be assigned if work is not completed within 1 year of the due date (university policy).
Due dates for each course offering are found in the assignment delivery schedule, downloaded from the web site.
Assignments: There are 5 Assignments, including 1 draft Software Development Plan; 1 final Software Development Plan; 2 estimating spreadsheets and 1 library search. A separate statement of work is provided for each assignment (downloaded from the web site). Each assignment has its own special cover sheet, found as the last page of the corresponding statement of work. Most assignments also utilize supplementary materials, also downloaded from the web site.
The main assignment in the course is for each student to develop a Software Development Plan (SDP). The instructor will provide a statement of work outlining the details of the plan. A draft of the Plan is submitted as assignment 2 and the final Plan is submitted as assignment 5.
Grading Scale and Expectations:. A: 93-100; A-: 90-92; B+: 88-89; B: 83-87; B- 80-82; C+: 78-79; C: 73-77; C- 70-72; and so forth. No curve is used. In grading, I focus on evidence that the student has learned the concepts taught in the class and applied them to the problem presented in the examination or assignment. Rote memorization will not help the student as much as seeking to understand the concepts through study, discussion and application. I welcome dialog with students on these concept and encourage discussion of the concepts among students (for example, study groups), so long as students do not discuss specific details of assignments and examinations.
Recommended Readings: (not required, but probably helpful)
Adams, Scott, The Dilbert Principle, New York, HarperCollins Publishers Inc., 1996. ISBN 0-88730-787-6.
Boehm, Barry W., Software Engineering Economics, Englewood Cliffs, NJ: Prentice-Hall, 1981.
Brooks, Frederick, The Mythical Man-Month (Anniversary edition), Reading, Mass.: Addison-Wesley Publishing Company, 1995. ISBN 0-2-1083595-9.
DeMarco, Tom & Timothy Lister, Peopleware, Dorset House, 1987, ISBN 0-932633-05-6.
Department of Defense, Cross Talk - The Journal of Defense Software Engineering, Ogden ALC/TISE, Hill AFB, Utah 84056-5205.
Department of Defense, Defense System Software Development, Dod-STD-2167A, 29 Feb. 1988, Department of Defense, Washington D.C., 20201. (This is an important, fundamental document that provides the foundation for many software process models. It has been replaced by Mil-STD-498 and ISO/IEC 12207, but is still important to have.)
Department of Defense, Software Development and Documentation, Mil-STD-498, Dec, 1994. Available for download at http://www.itsi.disa.mil/cfs/std498.html. (Commercial version is IEEE/EIA J-STD-016-1995, which in turn was later replaced by IEEE-US 12207, which is the U.S. version of ISO/IEC 12207 [international standard for software development].) Expect further developments in this volatile (and non-standard!) standards scene.
Humphrey, W.S., "Characterizing the Software Process: A Maturity Framework," IEEE Software, Vol. 5 #2 (March, 1988), pp. 73-79.
IEEE, Standard for Developing Software Life-Cycle Processes, IEEE-STD-1074-1991. IEEE Computer Society, New York.
Paulk, Mark, et. al., Capability Maturity Model for Software, Version 1.1, Software Engineering Institute, CMU/SEI-93-TR-2, February, 1993.
Reifer, Donald, Tutorial: Software Management (third edition), IEEE Computer Society, order # 678, ISBN 0-8186-0678-9, IEEE catalog # EH0243-6
United States Air Force, Software Management Guide, Software Technology Support Center, OO-ALC/TISE, Hill AFB, Utah 84056.
OUTLINE
PLANNING AND MANAGING A SOFTWARE PROJECT
Text Chapter(s)
I INITIAL PLANNING
1. Introduction
1.1 Course Overview
1.2 Software Process as the Framework for Software Engineering Preface
1.3 Facts and Myths about Software Engineering
1.4 Overview of the Planning Process
2. Lifecycle Models
2.1 A General Model of a Lifecycle
2.2 The Project Lifecycle
Concept Exploration
Engineering Development
Final Product Development
Production and Maintenance
Sustaining and Updating
2.3 The System Engineering Lifecycle
Analyzing and Specifying Requirements
Developing a System Architecture
Decomposition into Subsystems and Sub projects
Selection of Products and Allocation of Requirements
2.4 The Software Development Lifecycle
Waterfall Model
Spiral Model
RAD (Rapid Application Development)
Tornado Model
3. Initial Planning 6
3.1 Overview
3.2 Understanding the Customer and the Requirements
3.3 Defining the Approach
3.4 Analyzing the Environment
Lifecycle Analysis
Complexity Analysis
Roles and Communication Analysis
3.5 Selecting Process and Methods
II. DETAILED PLANNING 6
4. Detailed Planning Overview and The Work Breakdown Structure
5. Size Estimates -- Lines of Code / Function Points
6. Effort and Cost Analysis
7. Scheduling
8. The Software Development Plan
8.1 Contents of a Software Development Plan
8.2 Documentation
III OTHER MANAGEMENT ACTIVITIES
9. Risk Management 5,6
9.1 Risk Management Process
9.2 Risk Assessment
9.3 Risk Control
9.4 Risk Examples
9.5 Risk Management Plan
10. Measuring and Monitoring 6,15
10.1 Overview
10.2 Basic Issues
10.3 Selection of Metrics
10.4 Recommended Metrics for a Software Manager
10.5 Issues with Metrics
11. Configuration Management 7, 12
11.1 The Need for Configuration Management
11.2 Configuration Management Functions
11.3 Configuration Management Responsibilities
11.4 Practical Problems
12. Software Quality Engineering and Assurance 8
Managing Quality 16
Engineering Quality 9,10
Software Testing 11
IV SOFTWARE PROCESS MATURITY
13 Software Process Maturity, Assessment and Improvement 1,2,3,4
13.1 Software Process Maturity
13.2 The SEI Capability Maturity Model (CMM)
13.3 Reviewing the Five Levels
13.4 Details of Level 2
13.5 Assessment
14 Continuous Process Improvement 13,14,17