One of the deliverables you are responsible for is the Software Development Plan section of the SDF. What you will be responsible for delivering is briefly described on the Software Development Plan web page. However, there is more to be explained than just what you must deliver.
The SDP is, next to a solid requirements document, the most important document in the set of documents in the software engineering process. Requirements, as has been stated, are critical, since they show the developer what needs to be built, show the customer what s/he is getting for the $$$$$$, and provide a trace to prove that the software is correct when it is delivered so that the contractual obligations are fulfilled. Without a solid software requirements specification, all sorts of trouble can erupt.
But that is only part of the story. Engineering the software for a project also requires a number of other things to be specified.
Remember the "5-P" principle:
All projects need good planning; software projects are no exception. Hence, the SDP. If we return to the "building a house" example, once you have specified what you are going to build (the 'requirements') you need a plan of how to build it. You wouldn't start with the roof, and then build the walls underneath it — it makes much more sense to build all the walls first, then build the roof on top. MAKE A PLAN!!
What goes in this document? If you remember the copy of the 70+ page book that I passed around in class, there are a large number of sections and subsections, each of which is there to describe a part of the development process. This page will help separate the wheat from the chaff.
For your project, you will need an introduction section. This is like the "scope" section of the SDP. This is important, because it reveals two things; first, the software project is described at an overview level, so that the reader knows what the software will do, and also know the limits of what it is supposed to do. This last is usually deduced by inference, since there is no text that says "The software will not . . .". It is always understood that what is there is what will be done, but the description is at the 30,000 foot level. There is usually a diagram of the software components, showing how they work together to create the system. This is usually a block diagram of some kind, and is NOT (unfortunately) done in UML.
Second, this section will present a preliminary idea of the development schedule, by listing the major milestones that will occur during project development. These will include the deliverables that you are responsible for in the SDF (all the sections of the notebook), but will also include the major milestones that will occur during development, such things as subsystem design completion, subsystem coding completion, unit test, integration, and so on.
The second part of your SDP document will contain the resources required by your project. There are sections for both hardware and software. Resources are project elements which are necessary for development and operation. Hardware resources include computers, any peripherals, hard drive space, memory requirements, and so on. Specify the minimums that are needed, and state that they are minimums. The same goes for the software part of this section; list the O/S, the IDE, any text editors, CM tools, and so forth. Try to be as comprehensive as possible. There are similar sections in an industry SDP, they just don't show up until later, around section 10 or so. An optional idea for this section is to list the "personnel resources", giving some idea of the availability of manpower that you think you'll need for this project.
The third part of your SDP will provide an idea of the organization of the project and its development team. What is intended here is that you plan carefully how your project will be divided up into "subsystems" (e.g., graphics, server, client, GUI, logic, evaluator, and so on). This should flow from the needs analysis and the requirements analysis that you have already performed. Also, this section of your SDP should list the people assigned to each of the subsystems. This doesn't need to be a resume, but should give some idea of expertise. Describe exactly what each of these roles entails. A person may assume more than one role, and more than one person may assume a single role. For example, the team members could be listed along with an explanation of each team member's responsibilities. Or, each team member could get a separate subsection of the document. Or, there could be subsections for each "sub-team" of the project, and the members of each sub-team and their duties could be described under each sub-heading. These are examples.
The fourth part of this SDP document will contain a detailed schedule for the project. As one of your deliverables, you are required to present a preliminary version of this. The preliminary version will be updated a couple of times during the early planning stages of the project, but by the time you reach the end of the process model phase, you should not be changing this any more. It will become the working schedule used to track development and make sure you are on track to finish on time. To get you familiar with the way this is done in industry, you should try to put your schedule into either a PERT or a GANTT chart. There are explanations on the Project Plan web page. I think the GANTT chart is easier to understand, personally, but that's just me. Use whichever you wish, but it is an interesting exercise to try to make a PERT chart, even if you don't include it in the SDP.
Section four also contains two other parts; the task/resource table, which is a breakdown of the tasks or subsystems of the project and its associated resources (including people, hardware, software, and so on); and the class schedule, which is an optional part that shows the activities scheduled for class lectures.
So that's the breakdown of your "mini-SDP", also known as the Project Plan. Here is a table that shows how the parts of your SDP relate to an industry standard like the one I showed you.
| Industry SDP Section | Your Project SDP Section |
|---|---|
| 1.0 SCOPE 1.1 Identification 1.2 System Overview 1.3 Document Overview 1.4 Relationship to Other Plans |
Section 4.1 Plan Introduction |
| 2.0 ORGANIZATIONAL DOCUMENTS | (Not used) |
| 3.0 REQUIREMENTS | (Not used) |
| 4.0 PLANS FOR MEETING GENERAL REQUIREMENTS 4.1 Software Development Process 4.2 General Plans for Software Development | Parts of Section 4.1.1 Section 4.2 |
| 5.0 PLANS FOR MEETING DETAILED REQUIREMENTS 5.1 Project Planning and Oversight 5.2 Establishing a Software Development Environment 5.3 System Requirements Analysis 5.4 System Design 5.5 Software Requirements Analysis 5.6 Software Design 5.7 Coding and Unit Testing 5.8 Unit integration and testing 5.9 CSCI Qualification Testing 5.10 CSCI/HWCI (Hardware CI) Integration and Testing 5.11 System Qualification Testing 5.12 Preparing for Software Use 5.13 Preparing for Software Transition 5.14 Software Configuration Management 5.15 Software Product Evaluation 5.16 Software Quality Assurance 5.17 Corrective Action 5.18 Joint Technical and Management Reviews 5.19 Other Activities 5.20 Other Software Development Activities |
Section 4.4.2 (resources) Most of these topics are covered in your other project documents |
| 6.0 SCHEDULES AND ACTIVITY NETWORK | Section 4.4.1 (schedule) |
| 7.0 PROJECT ORGANIZATION AND RESOURCES 7.1 Project Organization 7.2 Project Resources |
Section 4.3 |
| 8.0 NOTES | (Not used) |
| 9.0 Plans for Meeting Detailed Requirements | (Not used) |