#devlifecycle

Milestone 1: Form Teams

Find your people, exchange contact information and determine a time to meet up, consistently. If you are working solo, ignore some of the instructions for this section. That is not to say ignore the parts about consistency and time management. In fact, because you are working solo that should be even more important.

At the first meeting establish chat service (teams, slack, google chat, discord). Establish the frequency of the meetings and how often everyone should check their messages (ex: every 24 hours). Discuss the options about the project.

Platform: Android, django, iOS, react native, etc.

IDE: Xcode, WebStorm, VSCode, etc. Note that modern IDEs now have built-in methods for sharing your editor view with teammates: code together, code with me, etc.

Backend: firebase, postgresql, not needed, etc.

Libraries

APIs you will access

Package manager: npm, yarn, gradle, etc.

Finally, discuss the roles you all want on the team, what should one person focus on, who is the manager, editor, client rep, tester, researcher, repo master, master of specific tech, analyst etc.

Deliverables:

Add a wiki page (or more) to your repo titled "Team Organization" and list there the decisions you made from above, along with any pother pertinent information for the team.

Add a page to your wiki titled "Project Description" which should be kept updated as you make decisions about your project. It should contain these sections:

Description: a short description of your project,

Technologies: a list of the technologies you plan to use: frameworks, libraries, hosting services, etc.

Client: your client's name and contact info, if you have one, otherwise just say "Startup."

Milestone 2: Personas and User Stories

If you have a client who wants you to build the app, or you have identified a group of users for your app, then try to meet with them. Ask them what they do? (that is relevant to why they will use the app), why they want the app? how do they currently do the things they want the app to do? etc. If this is a startup answer those questions and more.

The point of this section is to better understand the users of this website. You need to make personas and user stories and record them so that you can reference them as you complete this project. It is very easy to loose sight of who will be using your product and assume they know more than they actually do.

Deliverables:

Add at least three personas to your wiki. These should cover 3 distinct user-types for your app. Each Persona must have a name, photo, and personal history.

Add a "User Stories" wiki page with at least 9 user stories covering the most common use cases for your app. They should all be of the form: As <the name of one of your personas> I want a <feature> so that I can <satisfy a need>.

Milestone 3: Design

For those that are more artsy than everyone else, now is your time to shine. Use a tool like Pencil, figma, justinmind, balsamiq, mockflow.com to design your product.

Your design should include:

An image for each of the major screens and dialogs of your app. Show all the widgets in their proper placement. Name each screen and write some text to explain how actions in one screen will lead to other screens.

In the case of a widget-free apps, you should include diagrams for all the major 'areas', animation stills that detail the most common animations and game mechanics (for example, Super Mario would have a set of drawings showing Mario jumping, punching up, and landing on a Goomba's head), as well as story boards if they are more relevant to your game.

A goal of the design is for you to think about the usability of your app. Try to 'use' the app in your mind: simulate how a user might use the app. Printing the screens into sheets of paper of the correct size and shuffling them as you pretend to use the app is a very common way to test the usability.

Another goal is to save you time. Remember that making a change now, like adding or deleting a screen, is a thousand times easier than if you wait until after you have written the code.

Deliverable: Add one page to your wiki called "Design" and add the images of your design here, along with some textual description of each screen and what it is used for.

Milestone 4: Requirements

This will be the main requirements document for your project. If you were charging a client for your work, this document would form part of that contract, specifying exactly what features your software will implement. The other part of the contract would be the payment details.

The document includes the design you made before (so, embed or add links to those images) but extends on that with detailed descriptions of all the desired features.

You will also mark each feature with one of:

Required: Core functionality of the app. Must have these for it to even start working.

Desired: Added functionality, usability, features, cosmetic features.

Aspirational: Other cool stuff you would like to add

Remember: all good programmers should understate what can be done and then over deliver. If you think something is going to take you 4 weeks, tell the client it will take 8. Then, when it inevitably takes you 6 weeks, you will seem ahead of schedule. On a similar note, if the client is asking for a lot of shit, say no. Now is not the time to be a people pleaser. If you want to please them, do it as a surprise addition, after basic functionality has been achieved.

Roughly the required features are those that need to get done first before anything else can even get started: things like logins, navigation menu, connection to backend, etc. They lay the foundation for building the app. An app that only implements the required features will at most get a passing grade in the class: 70.

The desired features are what make your app worth using. They make the app functional, attractive, and easy to use. Roughly, an app that implements all the desired features gets a 90 in the class.

The aspirational features make your app a professional-quality app. Implementing some of these moves it towards 100.

Deliverables:

Make a Requirements wiki page and list your requirements there.

Each item should succinctly explain a feature.

Each one will have a number. You can add sub-numbering, 1.1, 1.2, 1.2.1, etc. if you want.

Each one will be marked as either: Required, Desired, or Aspirational.

Add all the Proof of Concept Issues to your GitHub Issues with label:enhancement, milestone:Proof Of Concept. These are what you will implement first.

Milestone 5: Research

As a developer, you need to be intimately familiar with the technologies you are or could be using. You need to understand the pros, cons, and requirements of each library and platform that is relevant to your project. Thus, you need to be up to date on technology and, since technology seems to be always changing, this will be something you need to do throughout your career.

Specifically, you need to

Know about the various platforms available to you: their options and limitations.

Know about the various libraries that you can use to make your work easier.

Download, install, and build sample 'Hello world' apps using the most promising technologies. It is not enough to just read about it, you have to do it in order to learn.

Learn how to use the specific framework+libraries you choose to use for the project by building little apps with them.

Learn to use your package manager.

All of the above needs to be done before you start coding together with your team. Do not assume your teammates will teach you. You are responsible for learning.

This milestone will take a lot of time and work, which is why you should start working on this milestone as soon as that first meeting occurs where you discussion options.

Deliverable: Create a separate repo (I suggest naming it research-<projectname>) where you will place your sample project built using your team's chosen framework. The project will be more than just "hello world", or cut-n-paste from a tutorial. Start with tutorial code but, add you own code to their code. The app should have some minimal interactivity: user enters some data, program does something with it and shows the user.

Milestone 6: Architecture

Now that you are comfortable working with your chosen framework, you will write a document that roughly describes the big parts of your code. The structure will depend a lot on your chosen framework.

If you are building a webapp then you will probably list the set of database tables (models, for example: rails:ActiveRecords, meteor:Collections, etc), the set Views, and the set of Controllers. For webapps you should also list the of your URLs app, and what lives at each one.

If you are building an Android app then you will list your Activities or Fragments, along with their corresponding Views, as well as your model Java classes. You will also list your database tables (firebase, sqlite, localStorage, etc) if you need persistence, which almost everyone does.

Think deeply about your design. Go over the most common use-cases and check how those will be accomplished in code: which methods will be invoked? do the methods have references to all the objects they need in order to perform their job? Remember that your main goal is *de-coupling** the various classes: the fewer references (method arguments, global variables) they need, the easier your life will be.

Deliverable: Add architecture document to the wiki containing:

List all the languages/frameworks/libraries/services/APIs you plan to use. Explain how they will tie together. For example: This will be a native Android app written in Kotlin, using the android.graphics library, using firebase real-time database for cloud data, and firebase authentication for user accounts.

What package/build manager will you use? npm, gradle, yarn, flutter, pipenv, etc.

List what each person will work on. Everyone must make significant code contributions, or they will fail the class, see Syllabus.

Make sure all the images (if any) are embedded in the wiki page and hosted at GitHub.

Make sure the wiki page is easy to read.

If you are building a webapp:

Deployment How will you deploy? Which hosting provider(s)? Automation? Scripts? Explain.

Are you using Virtual Machines (vmware, vbox, etc) or Containers (docker) for development or deployment? Explain.

Is it a SPA or traditional? or mix? Explain. (My web application development lectures explain the difference.)

List of URLs you will implement. Explain any search arguments in English. Link (actual hyperlink) each URL to the page it shows in your Detailed Design milestone.

If implementing a REST API, document it. List all methods, parameters, and give English description of what they do.

The Views of your app. Embed the images from your Design Milestone. Typically, a webpage includes multiple views. For example, this webpage has a Header, Menu, and Content views (at least).

The Database schema: set of tables/documents with list of attributes and their types. Describe each table and attribute in English.

List of common queries you expect will be needed. Do any of then need to join tables?

If you are building a mobile or desktop app:

Release: How will you create and deliver a binary to testers? Explain. Note that the testers include us (the teachers of this class, when we grade your app). You must deliver a simple to install app: double-click to install.

Are you using Virtual Machines (vmware, vbox, etc) or Containers (docker) for development? If so, explain.

The Models for your app. These could be UML class diagrams, or just models with attributes (with type) and descriptions (in English).

How will your app maintain state? in memory? or database? or both? Note this in your Model Classes.

If you are using a db-backend (say firebase) then include the Database schema: set of tables/documents with list of attributes and their types.

List of common queries you expect will be needed. Do any of then need to join tables?

The Views of your app: name, describe. Embed the images from your Design Milestone. Typically, one page in the app is composed of multiple View elements.

Below will be complete as I do for my Capstone project.

Source Control

Ethical, Legal, and Security Considerations

Proof of Concept (PoC)

PoC Demo

Testing

Beta Release

RC1 Release

Quality Assurance

Website

1.0 Release