D424 - Task 2

IMPORTANT! - It's become a trend for students to write proposals using bullet points instead of writing complete sentences. These tasks are getting returned and locked. Please write in complete sentences. Use bulleted lists minimally or not at all. If you do use a bulleted list, make sure you write complete sentences for each bullet point.

Task 2 Process

  1. Download the Task 2 template.
  2. Add your content to the Task 2 template. Refer back to the explanations below as you write each section.
  3. Edit and revise as needed.
  4. Submit the Task 2 Business Proposal.

Task 2 is a fictional business proposal for your application. It is not meant to be an answer/response type submission. We strongly urge you to take advantage of the template here. It is structured so that if you provide adequate details below each subheading, in theory you will have a completed proposal. Most details are fictional, except the explanation of your app's features. It doesn't hurt to read the sample paper to get an idea of minimum standards for passing.

You can start on task 2 once an instructor has approved your project, but you can't submit task 2 until task 1 has passed evaluation.

The Business Problem

The business proposal starts by setting the scene for the "why" of your application. You'll describe the business or customer that would use your app. Provide fictional details, such as industry and company size. If the app is meant for general public, describe who you think your average end user will be. Include demographics of your target market. Then, you'll describe what they would use your app. You need to build a case for your app's necessity.

Fulfillment

This is where you describe the app's functionality. If you are modifying a past project, you need to explain what it already does and contrast it with the features you'll be adding.

SDLC Methodology

You'll describe the project methodology (ADDIE, Agile, Waterfall, etc.,) and explain why it will work well with your project. As you describe the different phases of your methodology, explain which of your specific project's tasks will belong in that phase. Do not forget the discussion of the specific tasks per phase. This is one of the most common reasons for getting a paper returned.

Deliverables

These are the goods that will be presented to the client or project manager. Include things like wireframes, technical documentation, results of testing code, and the code itself. You won't be required to produce everything on this list. This exercise is meant to make you think about all the various things beyond the code itself that may be produced in a full-blown software dev project. Project Deliverables would be those things produced internally to help support development (test plans, project timeline, technical documentation). Product deliverables are those items that would be presented to the client, such as the code and wireframe mockups if they need to approve a layout. Provide details such as, what the deliverable is for and who is responsible for creation and maintenance of the deliverable.

Deployment Plan

This is where you describe the deployment process for your application. It is not the same as a project plan to develop the app. Explain and describe the finished software product. (exp: "We will release a full-stack MVC web application developed in C# using the ASP.NET framework enables users to manage their pantry inventory through a responsive, data-driven interface. The application integrates Entity Framework for database operations and follows RESTful principles for backend communication. The system will be deployed to a live production environment and accessible to end users.")

Don't make assumptions the user will know. Sections are graded individually. Even if you described your app earlier, you still need to restate briefly what it is. Examples are provided in the template. There are known discrepancies in the wording of this section in various places in the task. In some places it is called a development plan, but this is not correct. Evaluators will look for a deployment plan. Do not forget to discuss the outcome. This involves a full description of the app itself like I mentioned earlier. Also, include additional things that will exist to support the app. Consider training materials, tech support, technical documentation, and other items. Be sure to include details about those items, such as what they are used for, where they will exist, and who would use them.

The Project Timeline

This is where you explain where each of the deliverables you described earlier is due. We provide a structured table for this in the template. Be sure to explain which tasks or deliverables may have prerequisites (and what those prerequisites are) before they can be completed. This information can be included in the description column. Include start/end dates, duration, and the role responsible for the task. The role (resources) can also be listed in the description column.

Environment and Costs

In this section, list all tools, their costs, and a justification of why they were chosen. To justify your tools, explain why you selected them. You'll also need to include an estimated cost of labor with the equation you used to calculate said costs.

Validation and Verification (Testing)

In this section, you need to list the types of testing you'll do and describe how the process will work. Most testing is cyclical. You write code, you test it, you put any fixes in place, and test it again. While you are doing all the testing yourself, this is a fictional scenario. For the purposes of your business proposal, you can assign fictional roles to handle each aspect. Explain what your internal testing processes will be. Don't forget to include how you'll handle user acceptance testing. Let the reader know when and who will be responsible for working with the user to test requirements and make sure the application meets user needs.

Do not forget to talk about what happens when bugs are found. It is important to include the act of troubleshooting, searching for the root cause of the issue, and fixing bugs. This cannot be implied or your task will be returned. Skipping from finding bugs to fixing them without discussing the process of looking for what is causing the bug will get sent back. Leaving this step out will get your submission returned. Also, inform the reader how you'll know testing is complete. Include the process for bug fixes in this description. Who is responsible for tracking them? How is a programmer assigned a specific bug? When they are done, do they simply push to live code or is there a QA process involved? Do they move it to a staging area and test it with the entire program? Is source control involved? These are the types of questions to consider as you write this section. The instructions also ask you to justify your testing methods. An explanation (justification) of why that process is used is also required in this section. Explaining why it's important to follow the methods you described is how you'll provide this justification.

But most importantly, use the template.