Guide for Developing the Software Development Plan

Below are the steps to complete the Software Development Plan. Use the examples and templates as a starting point.

Section 1 Product Description

  1. Now that you have taken the first cut at defining your application, describe the product and the client in general. What problem are you solving?

  2. Provide a description of the potential audience and what goals are to be satisfied with this product. Summarize the major product functionalities and salient features.

  3. This section should be 1 to 2 paragraphs

Section 2 Team Description

  1. Describe the strengths/skills needed for team members to create this application. Think about the different skills throughout development (analysis, design, user interface, coding, testing, architecture, network, hardware, etc) and which are needed for your application.

  2. Is there a need for a Subject Matter Expert (SME), someone who is familiar with the application domain and the problem you are solving?

  3. For each skill identify which team members have that skill. Multiple members can have multiple skills. Identify what expertise is missing.

  4. This description is used later in Section 5 when team responsibilities are defined.

Section 3 Software Process Model Description

  1. It is recommended to use Agile methodology for this course.

  2. Provide a description of the Agile methodology or the methodology you will use.

  3. Explain the pros and cons of this method. And contrast with another methodology

Section 4 Product Definition

  1. Define the scope of the project
    1. Identify the actors - people or systems outside the scope of your application
    2. Identify the flow of information between the actors and the application
    3. Only show high level flow at this level
      1. For example “contact information” versus “first name, last name, email”
  2. Define the personas
    1. For each actor, come up with a short (few sentences) description describing each actor so anyone reading the description gets a clear picture of this person and why / how they interact with the application
  3. Define user stories
    1. For each actor, create a list that starts with: “As a I want to….”
    2. Start with a brainstorm and list any stories
    3. Refine and add / subtract based on what you want to have in the application.
    4. You may identify some “nice to haves” as potential functionality to add later.
  4. Define the use cases. This includes both the Use Case Diagram and the Use Case Descriptions
    1. Using the scope diagram and user stories, create use cases to cover all the functionality of the application.
    2. Names are Verb Noun, for example, PurchaseTicket
    3. It may take a few iterations and discussions to get the organization of the user stories into related use cases.
    4. For each use case, create the use case description
      1. Complete all 6 sections (name, actors, entry, exit, flow of events, special requirements)
      2. The flow of events are the approximately 5-7 steps to get from the entry to the exit. This is the “Happy Path” if everything works well.
      3. Any “what about when…” or edge cases or special cases go under the Special Requirements section

Section 5 User Experience Wireframes

  1. Create first cut wireframes of the user interface screens. This is to make sure all team members are on the same page as to the overall sequence or flow for the users.

  2. Keep it simple. It does not need to have all the fields complete. It is a first cut. It can start out on a whiteboard or sticky notes. What is included in this doc should be computer drawn

A good introduction is here

Section 6. Project Organization

This section identifies the major tasks and first cut at a schedule.

Matrix of Responsibilities

  1. Based on the Team Description in Section 2, identify which team member(s) are responsible for which major tasks.

  2. While multiple team members may have the same skill, this section identifies who is accountable for the task.

  3. If there are missing expertise - who and how is that going to be handled?

  4. Include roles based on Process also. For example, Scrum has a Product owner, Scrum master, Dev team. These are additional roles and multiple people can have multiple roles

PERT / Gantt Chart

  1. Think about the entire project and the different phases or milestones:

    1. Requirements - further detailing use cases along with corresponding user interfaces
    2. Architecture - determine what hardware will application reside on
    3. Risk Management Plan - what’s the risky part of the project. Prototype this section to mitigate the risk
    4. Test Plans - how are you going to test the application. This is based on user stories and use cases
    5. High level Design - Create class diagram to organize data based on use cases.
    6. Sprints - For each 2 week sprint, determine which use cases will be implemented and tested.
    7. Testing - run the test plan tests
    8. Final Delivery - Create user manual and installation guide for the client.

  2. Estimate how long it will take to complete each phase above. Take your best guess knowing everything needs to be complete by Dec 1st

  3. We are recommending Agile, so each Sprint should be 2 weeks. Try to identify which use cases will be done in each Sprint.

Put link to draft Gantt chart in SDP; “import” Gantt chart to a project management tool (ie, GanttProject, Asana, Microsoft Project) to create the PERT chart Insert PERT or Gantt image that is readable and links to each in the SDP.

Section 7 Validation Plan / Test Strategy

  1. What is the definition of Done? Is it when all the use cases are complete? Or 4 or 5 use cases?

  2. What does success look like? When there is 1 user successfully using the application? Or 100 users? Or 1,000? Or is it when 1 person can go through the entire application from beginning to end.

Section 8 Feasibility Study

This section is to think about and identify the “we don’t know what we don’t know” parts of your application. In the responsibility and skill matrices above, are there skills missing? Is there a language or architecture you want to learn or need for this application?

Risk Identification:Brainstorm and describe all the risks.

Risk Prioritization: Now prioritize the list from highest to lowest. What are the top 3 risks? These are the ones to mitigate

Risk Mitigation: In order to ensure the success of your application, the top 3 risks should be identified and described. Of these 3 risks, choose one to prototype to verify / mitigate the risk.

Section 9 Configuration and Version Control

Specify the process and attributes for version control for all project and product artifacts.

Section 10 Tools

Provide a list of tools required for the project and their use (for example, IDE, github, docker, Figma, testing, etc.)

Section 11 Architecture

List of hardware or other subsystems required for the product.

What other software or systems will your application interface with?

Can you determine where your application will reside? What are the options? Servers? Serverless? Cloud? Devices? List what you know, and what you need to research.