Introduction

Software architecture diagram for the Windows NT operating system. — D. A. Solomon, "The Windows NT kernel architecture", in *Computer*, vol. 31, no. 10, pp. 40-47, Oct. 1998, doi: 10.1109/2.722284. See enlarged image.

Now that you've thought about your own reasons for choosing a project, let's look at how you should go about planning the work you will need to carry out.

How do you eat an elephant? One bite at a time! 😁 While the thought of taking on a term-long project may seem daunting, the next two weeks of planning will help you break your project into manageable, monitored steps that will help you successfully complete what you set out to do. We'll discuss the topics expected in the plan you should be striving for, up-front software engineering activities that provide a strong technical foundation, choosing tools, and how to anticipate and manage risks that could threaten your project. Then you’ll learn about scheduling your work and applying industry best practices that can steer you clear of common planning mistakes. Finally, you'll complete Assignment: Project Plan, which will show your thoughtfulness about project selection and demonstrate appropriate planning rigor. With your plan in place, you’ll be ready to start your project work!

Using Project Plan Topics to Guide Your Planning

Your project selection and goals, plus the software engineering activities you carry out, will establish what it is you want to do. The Project Plan you create will establish how you will do those things. The first step in any project plan is to start with an outline that identifies what you need to do. You'll see this list of expected topics in 🟠 Assignment: Project Plan, many of which are based on the up-front software engineering work you will do to define your technical approach for your software product:

Project Summary:

Introduction
Features and Functionality, with externally-focused graphics to illustrate some aspect of your external UX/UI
Technical Solution, with internally-focused graphics to illustrate some aspect of your internal architecture
Tools and Technologies
Software Delivery Process/SDLC Activities
Conclusion

Project Risk List

Project Schedule

This list can serve as the outline for your work, which when completed will comprise your Project Plan. As you think through what you will need to do in your project, put anything that comes to mind into this outline — that will help keep your ideas organized until you finish capturing all the planning details in the outline. The end result of this planning effort is a Project Plan that will do two important things:

Document what you are committing to deliver by the end of the term, and
Serve as your guide for the work you will do week-by-week during the project.

Don't be daunted if you don't know how to complete all these sections yet — you will learn what you need to know as you work through the course materials.

Applying Software Engineering Principles

By now, you have taken undergraduate courses in software engineering, or had equivalent experience. This planning activity is the perfect opportunity to apply those principles! That way your portfolio project also demonstrates your ability to follow a software development lifecycle. Because industry emphasizes delivering results, I personally prefer to call this a software delivery process (example below):

Placeholder screenshot for video

Isn't This a Waterfall Lifecycle?

While this delivery process may feel very waterfall-ish, that's only really true if you carry out these activities at the project level. In Agile software development like Scrum, you carry out many of these activities during each Sprint on an increment of the code. You will pull requirements (backlog items) from the Product Backlog into the Sprint Backlog, establish the architecture needed to meet those requirements, design the code to implement the architecture, write the code, then perform unit tests and code reviews and at least a preliminary integration test to confirm nothing was broken before considering that increment to be done and checked in. Some of the more time-consuming activities might have to be carried out after the Sprint is over, simply because there isn't enough time to execute them during the Sprint itself. For example, if Sprints were only two weeks long, and the full suite of manual and automated tests a big company may have for a massive code base takes 2-3 weeks to execute, that work would have to be after the Sprint was complete.)

The above example represents a far more comprehensive delivery process or lifecycle than is necessary or appropriate for your project, Nonetheless, you should spend an appropriate amount of time considering at least these areas:

Requirements
External design (UX/UI)
Architecture
Internal design (preliminary until you get deeper into the project)
Testing strategy
Version control and release management

The effort you put into these topics will lay the foundation for breaking down the work further into a set of tasks, and creating some key elements of your Project Plan. In particular, some architecture decisions you make may limit your ability to make changes later in the project, so be sure you are thoughtful about these choices.

The form below gives you a way to make a list of the software delivery process or development lifecycle activities you think you follow as you develop your personal project. Feel free to add any other SDLC development or testing activities you think are relevant to your project, such as smoke testing, security testing, or acceptance testing. You can have this list emailed to you as a reminder of the activities you thought would be useful.

Choosing the Features and Functionality for Your Product

The features and functionality you deliver will be the centerpiece of your finished product. (In terms of the software development lifecycle or software delivery process you follow, these are the requirements you want your product to meet.) No doubt you already have a sense for what you want your users to be able to do with your product; now is the time to think these through and write down these details (you will need them for your Project Plan).

Be Cautious About Your Ambitions

It's quite common for students to take on far more than is realistic to accomplish during the term, especially if your project goals include a significant amount of learning. So even at this early stage, be sure to temper your enthusiasm to provide a very large feature set and a very sophisticated UI. You have a time constraint because the Project Track should occupy more than half of your total effort in the course; most students will spend 20-30 hours on instruction, online activities, and assignments, and 50-60 hours actually working on their project. In the next explorations, you'll figure out the tasks you need to carry out to implement your features and UI, and that will be another opportunity to scale back your plans to fit the available time.

Mapping Out the User Experience for Your Product

Then you need to think about what user experience you want to provide to bring those features and functionality to life — how you want the user to interact with your product. Map that out on a preliminary basis. It doesn't have to be complete at this stage; you can work out all the nitty-gritty details as you carry out the project work. As you visualize what you want, start to capture that as well. How you document your user experience depends on what type of product you are creating:

**User Experience Documentation Approaches**
Type of Product	Examples of User Experience Documentation
Desktop app, mobile app, web app	User interface flowcharts Create mockups or prototypes User experience storyboards Can be as simple as something hand-drawn, especially for early UI concepts Can be as complex as something built with a UI prototyping tool
Command Line Interface (CLI)	Command set
Application Programming Interface (API), collection of microservices, server	How they are called Initial conditions and parameters What errors they report

Regardless of the type of product, it's important to capture that information for use as part of your Project Plan. Everything you do in this area feeds the next module in which you break down the work necessary to implement everything you hope to deliver during the term. That's what will allow your Project Plan to be a useful week-by-week guide for that work. So the more detail you capture about your features and functionality, the easier it will be to predict whether or not all of it is achievable in the available project time. You can put as much detail in your Project Plan as will be useful to you to guide your work.

Warning About Black-Hole Features

Hundreds of student projects during the Project Track for this course with a similar workload constraint have shown that certain features are difficult to implement successfully, and require a disproportionate amount of time relative to the rest of your planned functionality. I consider these features to be black holes because of the way they suck all your time away from everything else of importance to your product.

Authentication (User Login & User Accounts) — NOT Allowed

Authentication is NOT allowed as a feature in your Project Plan. This may seem rather arbitrary, but the reality is that it adds little to no value for projects in this course. Past students have generally abandoned it when it became a time-consuming distraction from more important features, and employers who see your project can easily envision how authentication would work. This also implies that the focus of your product should be use by a single user only, which is also consistent with the course workload expectations.

Exceptions are possible. For example, if your project is related to cybersecurity with authentication as the project focus, or chat functionality, where multiple independent users are required, authentication would be allowed. Exceptions to the no-authentication requirement must be approved by your instructor before your Project Plan is submitted. Not including authentication is worth 0pt in your Project Plan, and including it without preapproval will actually deduct 5pt from your total Project Plan score!

Some projects may include the goal of releasing your product for others to use, in which case you may need to support and maintain different user accounts. That support is out of scope for this course, and you will have to add that capability after the project is over.

Features Requiring Disproportionate Amounts of Time and Effort — Allowed but Not Recommended

These features are allowed, but beware! Most students who include them in their Project Plan end up scaling them back significantly or dropping them entirely before the end of the term, due their time and complexity. Be realistic about what you will be able to accomplish with the course workload constraints, and focus your project work on the things that provide meaningful value. For example, a fully working web app hosted on one of the OSU Flip servers is better than an app hosted on AWS or GCP but with incomplete user functionality because of the excessive time spent getting the cloud deployment to work.

Apps hosted or deployed on a cloud platform
Cloud storage
Web scraping
Mobile apps destined for more than one platform
Mobile apps submitted to an app store
Multiuser applications
Interactive chat apps

Stretch Goals — Recommended to Omit

Many students include "stretch goals" — features or capabilities that they really want in their product — in their Project Plan as part of their Project Schedule, in the hopes that they will have time to complete those features. Mentioning them as stretch goals may feel good, but as soon as you allocate time to work on them, they become part of the commitment made by the Project Plan. At the end of the term, part of the grade on your final assignments depends on whether or not you completed all your committed features. So you either have to not mention stretch goals if you are not committing to them, or list them as committed features if you are planning to work on them. You can't have it both ways, and you'll have to make a choice in your Project Plan.

In this course, it is wiser to omit these from your Project Plan so you don't have to drop them later if you run out of time. Instead, if you complete your committed functionality early, consider adding an additional bonus feature that you still have time to implement without compromising what you already completed.

Selecting Tools and Technologies

The tools you will use will be entirely dependent on your chosen project. You may choose some or all of your tools before your project starts, and others you may choose as part of your project work. Your tool choice may result in learning curves that you will have to factor into your time estimates. There are more software packages and APIs available than any of us can imagine. How do you know which ones to use? Do they interface with the hardware you're considering, or you're assuming the end-user has available to use?

Consider the following questions when making choices:

Are there tools, frameworks, or packages that will shorten the overall development time without simply doing the project for me?
Are there tutorials or books that I can use that will shorten my development time, even if I pay an initial investment of time and money in training and self-education?
If I have to buy anything, can it be reused, or are they single-purpose tools?
What can I do to make use of simpler tools with a lower initial investment of time and money?
Are there APIs or 3rd party offerings that I can use that will increase my enjoyment of the process? Will I avoid a boring step if I simply buy an IDE or software package?
Do I want to make my project open source? Can I use already-existing open-source software to further a particular objective I have, as long as the licenses are compatible?

Whatever tools you choose, look for those that keep your interest burning bright. Avoid those tools whose difficulty, cost, or time to learn would snuff out your desire to finish. If you are not sure which tools you want to use, some of your initial project work may have to be to make those choices. And if later on, you find out that your chosen tools don't meet your needs after all, the course provides a way to replace them under certain conditions.

Next Steps

Now is the time for you to put deep thought into the up-front software engineering required to build that technical foundation. These activities will directly correspond to topics you must cover in your Project Plan:

**Software Engineering is the Foundation for Your Project Plan**
Software Engineering Activities	Corresponding Project Plan Topics
Requirements	Features and Functionality
External design (UX/UI)	Externally-Focused Graphics
Architecture	Technical Solution
Internal design (preliminary)	Internally-Focused Graphics

You will also need this technical foundation in place so you can:

Identify a technical decision you need to make, which you'll be able to do after studying 🟠 Exploration (Optional): Making Decisions.
Assess your project risks by completing 🟠 Assignment: Identify Preliminary Project Risks, which you'll be able to do after studying 🟦 🟠 Exploration: Managing Risks to a Project.
Break down your work into tasks and schedule them to guide your work throughout the term, as described in Module 2.

You can get a leg up on your Project Plan if you look ahead to those required elements of 🟠 Assignment: Project Plan that describe your technical foundation, and let those help guide both your thought process and the notes or other artifacts you create as you go along.