Primary stakeholders: The people who actually use your system directly
Secondary stakeholders: People who do not directly use your system, but they provide input or receive output
Tertiary stakeholders: People who are affected by your system, but do not interact with it
Facilitating: People who develop, design and maintain the system

For example, for the ECS hand-in system:

Lecturers and students are primary because they directly use the hand-in system to either set work or hand in work.
The assessment team could be secondary because they are aware when the work is late in the hand-in system. They don’t directly interact with the system, but they know its results.
The Assistant Dean for Education could be tertiary because they are notified when a student is repeatedly handing in work late, or not at all. They might not even know that the system exists, but they are affected by the hand-in system on a higher level.

Persona: a stereotype of a group of users in some detail, like background, job, situation etc.
You should describe:

their background,
job function,
situation in the organisation,
objectives, beliefs, anxieties and so on,

You can also include a representative image
Scenario: how a persona interacts with the system

Why use personas?

Users are more personal
Multiple personas can represent the same user, so you can build more vast systems (it’s not too general)
Incorporate personas into stories (As a [persona] I want to [goal] so that [benefit])

User Stories, Planning, Risk

User stories

What is a user story?
A user story is one or more sentences that captures what the user wants to achieve.
It’s written in normal language; no jargon!
It should detail one thing. If the user story gets big, you should split it up into multiple user stories.

There are three steps to creating a user story:

Card: write the story on card, annotate it with notes etc.
Conversation: talk to the product owner and get more details
Confirmation: test if the story was coded correctly. If not, start again

User stories usually fall into the following template:

As a <user>
I want <goal>
So that <benefit>

So for example, a user story could go like:

As a wild swimmer
I want to know the water quality of the sea where I am going on holiday
So that I don’t catch horrible diseases

You can also refine your user stories by being a little more specific, for example instead of the quality of the “sea”, you could have “rivers” or “lakes”.

How do you write good user stories?
You INVEST! (You don’t actually invest, it’s an acronym)

Independent: your user story should achieve one goal
Negotiable: you can talk to your product owner about this
Valuable: is this user story actually any good to you?
Estimable: can you estimate the size of this user story?
Small: if it’s too complicated, it can probably be split into smaller user stories
Testable: you can get your product owner to perform this user story

User stories and use cases are not the same!
User stories are general and informal. You talk to your product owner about them.
Use cases are structured, well-documented and verbose. You use them for testing and development.

Agile planning

Before, companies used to use the waterfall model for development.
It’s systematic, sequential, and highly structured, but there was no room for flexibility. You can’t go up the waterfall (except if you’re a sicyopterus stimpsoni, which you’re not)!
Requirements change, and problems happen. Basically, waterfall development (or any linear plan) sucks.
You know what doesn’t suck? Agile development!

Agile development is an umbrella term for frameworks and practices that emphasises responses to change, typically through requirements and solutions.
Instead of doing everything at once (like the waterfall method does), agile methods like Scrum or Kanban do a little of everything all the time.

Scrum is a framework where tasks are created from user stories, which are then added to a product backlog and implemented through sprints.
After each sprint, a scrum meeting occurs where everyone states what they’ve done and checks the burndown.
Typically, after each sprint, a deliverable is available for the product owner to test.

More specifically, there are two steps to scrum:

Envision your project
Develop iteration

When you envision your project, you create a product backlog.
A product backlog is the requirements for a system, and it is expressed as a prioritised list of requirements:

functional requirements (things you can do, like buying something)
non-functional requirements (things you can’t do, like how something looks)
technical team-generated requirements (like refactoring)

It is up to the product owner to prioritise the product backlog.

So how do you make a product backlog?
First, you come up with as many tasks as you can, based on the user stories.
There will be more than enough for one sprint.
Then, more tasks can be added later on when more is learned about the product and its customers.

During a sprint planning meeting, backlog items are moved into sprints, where they might or might not be implemented into the system during that sprint.
You also need to identify the lower level tasks and estimate how long each task will take.

Now we have what we want to do in our sprint. What do we do first?
We categorise the tasks into:

What must be done
What should be done
What could be done
What would be nice, but won’t have time for

This is known as MoSCoW prioritisation.
Then, you set up a burndown chart, organise who will be doing what and each week, you need to check the sprint plan and adjust it (remember, scrum is all about responding to change).

How will you plan your sprints?

Do all of the musts as early as possible?
Balance out stories/tasks to make a really good deliverable?

You also need to focus on dependencies, for example you can’t implement a chat service before implementing any users to chat with, so implementing users might be in sprint 1 and implementing a chat service might be in sprint 2.

A burndown chart is a visual representation of tasks being completed. It allows you to estimate when all the tasks will be finished, and whether the group is going slow or fast.

How will you know how you’re doing?
You organise scrum meetings!
A scrum meeting (or scrum, on its own) is a 10-15 minute meeting where each member of the group states:

what they’ve done
what they’re going to do
what they need help on

The scrum master will keep the meeting on track and notes progress
During a scrum, the burndown will also be checked, and the backlog might be updated.
Lots of things may be considered, like:

will we achieve the deadline?
do we need to change what we will deliver?

When a sprint is over, we evaluate:

how we did
the feedback from the customer
what to change in response to that feedback

Risk Assessment

There are multiple different risks that can happen:

you lose a member of staff
the management changes and priorities are now different
requirements are now different, and it’s larger than planned
specification delays, and now it’s not available on time
everyone underestimates the size of the project
technology changes
someone else releases a competitive product
a component of the product fails
the organisation is taken over

Oh no! There’s so much that can go wrong! What will we do?
We can:

Identify the risks
Quantify the risks

severity of impact * probability of occurrence
Show stopper: a high probability risk that could ruin everything

Identify alternate strategies
Pick strategies that will minimise the risks and tackle show stoppers early

Here’s an example of risk analysis:

Risk	Probability 1 low, 10 high	Severity 1 low, 10 high	Risk exposure E = P * S	Mitigation what you’re going to do about it
Nobody talks to anyone because we’re all awkward and don’t know each other	6	5	30 Huge risk! (Show stopper)	Host events to engage people together, so that we get to know each other more
A rat infiltrates the GitHub server room, nibbles the cabling and destroys all of the repositories, including ours	3	8	24 Big risk	We will back up our project onto multiple platforms, so even if GitHub explodes, our code will be safe
A meteorite crashes onto the office building and kills everyone	1	10	10 Small risk	It probably won’t happen, but our code and documentation are stored on the cloud anyway so if anyone survives they can recover it.
An evil man earns the respect of the boss, so our boss hires his blonde-haired teen son from the 1800s only for him to knee our dogs in the face and wear a stone mask to become a vampire	0	9	0 Not even a risk	Nobody even gets these references

Planning

We should only plan for the next immediate sprint
We can plan for the next sprints a little bit, but leave plenty of room for change.
The amount of planning should decrease the further away the sprint is.

So we have our backlog, what do we put in our next increment?
Prioritise musts? Balance out musts, shoulds and coulds?
Talk to your product owner. Remember: the customer is always right!

Think about how many tasks you can complete this sprint, and plan accordingly.
Make sure you plan to have a deliverable that offers value.

RISK: If you have musts in the last increment, and you run out of time, you’ll have to sacrifice important parts of your system!
You also need deliverables that offer value, and a sustainable workload. There may also be dependencies (you can’t implement A without B).

User story estimation

How do you estimate how long user stories will take to complete?
There are various ways to do it:

T-shirt sizes

The following T-shirt sizes:

Small
Medium
Large
Xtra-Large

... can be used to label how long tasks will take.

You’re not going to guess it perfectly the first time.
You’re going to make mistakes. You’re only human!
But, as humans, we can learn from our mistakes and move on.
Therefore, label tasks the best you can. For example, you may label task #1 a Medium.
If, after the sprint, you find out that task #1 was actually a Large, you can document that and learn from that.
By keeping up this self-improvement program, you can eventually get good at estimating task durations!

Story Points

Story Points are natural numbers that also state how long a task may take.
The higher the number, the harder the task.
There are various ranges of story points, such as:

Square numbers: 1, 2, 4, 8, 16 ...
XS Small, Small, Medium, Large, XL Large (encoding T-shirt sizes to story points, which is useful if your scrum software is only compatible with story points)
Fibonacci series: 1, 2, 3, 5, 8 ...

Agile Planning poker

Agile Planning poker is a gamified estimating technique to estimate relative sizes of development goals.

How do you play agile poker?
First of all, if you’ve played normal poker, it’s nothing like that.
There are three roles:

The moderator - The one who distributes the user stories to the team and records estimates
The Product Owner - The one who answers questions about the user stories
The participants - The ones who decide and debates over estimation of user stories

Here’s how you play:

Each participant gets a deck of estimation cards. These cards could be T-shirt sizes, square numbers, fibonacci etc.
The moderator picks a user story and shows it to the team.
The Product Owner answers any questions regarding the user story.
Each participant picks an estimation card they think is right for the user story. They hold it face-down.
When everyone is ready, they all show their estimation cards.
If there is an agreement over an estimation, the moderator records that estimation for that user story and we go back to step 2 with a different user story until all user stories are estimated.
If there is a disagreement, the high and low estimators debate and defend their estimates. Afterwards, everyone picks estimates again (go back to step 4).

Let’s see an example of people playing it!

Illustration	Explanation
	Everyone is assigned T-shirt sized cards. This game, the moderator will also play as the Product Owner. We are all ready to play!
	The first user story has been presented! Everyone is picking their estimates...
	It seems everyone picked the same thing. There is an agreement! The moderator will document this estimate with this user story and move on.
	The second user story has been presented! Everyone is picking their estimates...
	Whoa! There’s some discord over the estimation. They’ve started “debating” over which is the better estimate!
	Everyone is picking estimations again...
	It seems everyone has come to an agreement, so now the moderator will document this estimate with this user story and move on. This will continue until every user story has been estimated upon.

User story breakdown into tasks

You should break your user stories down into tasks that are easy to read, understand and complete as a programmer.
The tasks should be structured such that when all tasks are complete, the user story is accomplished.
Example:

This will also help you distinguish between user stories that are small and user stories that are big.
It’s also helpful to estimate times on tasks, as they’re more atomic than user stories.

Introduction to Source Control

Source Control: the practice of tracking and managing changes to code.
It’s like a system that can track changes to your projects and allow you to see who made what changes, revert back to previous stages in the repository etc.

There’s lots of source control systems, like Git and SVN.
Use Git, though. It’s better. SVN is ancient.

Before we go over the commands, let’s see how Git actually works:
First of all, Git models your project as a series of “commits”.
A commit can be seen as one “change”. They add, remove or modify files in the repo.
These commits happen in serial, making up your project:

In terms of the “areas” of Git:

source: https://greenido.files.wordpress.com/2013/07/git-local-remote.png?w=696&h=570

First of all, you have your working directory. This is where you make all of your changes and do all of your coding.
Second, you have a staging area. Changes in this state are “ready” to be committed and confirmed as a change in the project.
A repository is an instance of Git that tracks your changes, remembers all the previous commits, can revert things back etc.
The local repository sits on your computer. The remote repository sits in some server somewhere, maybe GitHub. You can update the remote repo with commits in your local repo, or you can fetch new commits from the remote repo into your local repo.

Git has several commands:

add - stages your changes (makes your changes ‘ready’ to be committed)
commit - take all your staged changes and puts them into one big ‘change’, called a commit, and puts it in the local repo
push - updates a remote repo with commits in your local repo
checkout - updates your working directory to a commit in your local repo. It could be an early commit or a later on.
pull - updates your working directory with the latest commits in the remote repo. It’s basically calling fetch, then checkout.
clone - makes a copy of a repository

To link a remote git repository to a local one, use the “remote add” command.
There are lots of hosting services for Git, like GitHub, Bitbucket and SourceKettle.
If you want to laugh at SourceKettle, do so here: https://sourcekettle.ecs.soton.ac.uk/
Use GitHub. It’s good. Bitbucket too.

What happens when two people make changes to the same file?
Merge conflicts! Edit the file to get the changes that you want.

Advanced Git

Git also has branches, so you can branch off, implement some feature, and then merge that branch back into “master” (the main branch).

As you can see, the branch veers off into another path and has their own commits. Once the feature is fully implemented, the branch is merged back into master.

Git also has a blame feature, which is used to blame people for shit code identify who made what change and why (what commit they did it in).

Lastly, Git also has a stash feature. Stashing takes all of your uncommitted changes and puts it into a “stash”, which you can load later. It’s used for when you want to move to a different branch and want to work on something else, but you don’t want to commit unfinished work.

If you want to use all these Git features effectively, but you’re not the kind of person who likes learning tonnes of terminal commands, I suggest GitKraken. It’s a Git client with a very intuitive user interface that makes working with Git incredibly easy!
https://www.gitkraken.com/
Believe me, I write these notes; I’m definitely the kind of person who likes things laid out in a simple and easy manner.
Do you find Electron absolutely disgusting and wish it was never created? Don’t worry, there are plenty of other GUI based Git clients, such as SourceTree and SmartGit!

Starting to Build: Scenarios, Storyboards

Storyboards (static design)

Storyboards describe the functionality in a visual way.
They describe the basic view of the software from a user’s perspective.
They can show:

layout
colours
fonts
UI components (buttons, labels etc.)

It’s a static design because there’s no interaction, it’s just showing the design and explaining it.
We can use static design to describe dynamic design:

Interactions between the buttons, text boxes etc.
Starting and exiting the program.
The range of inputs that can be tolerated.
The range of outputs that will be allowed.
Details of any warning messages.
The details of the calculations.

Examples:

Scenarios (dynamic design)

Scenarios are a sequence of interactions the user has with the product in order to achieve some goal.
It’s a bit like a use case, except less formal and descriptive.
Example:

David opens a web browser and enters the URL of PuffinShare
The home page is displayed
David can enter tags into the search box
When he presses the ’Go’ button, the puffinShare repository is searched
Items matching the tags are retrieved and displayed in the output box on the RHS

If there are no matches, a message is displayed in the output box ‘no matches, please try again’

David can select one of the retrieved items and the resource page is displayed
David can navigate to these pages by selecting their tab:

Profile
Upload
About

Scenarios should be tested at each increment
However, the scenario may only be partially achievable after an increment.
Therefore, you can split the scenarios up and put them into the appropriate increments for which they can be tested.
It’s also good to link the scenarios to personas.

Building Applications using MVC

What problem does it address?

Do you remember Flappy Bird?
If you don’t, it’s time to move out of your rock apartment it was a very popular mobile game.
There were many clones (such as Flappy Knuckles, made by yours truly!)

If we were to implement it using an OOP language, the structure may look something like this:

Yikes, that’s ugly! Who’d want to look at that?
The problems with this is:

High coupling (every component is too tightly linked to each other)
Low cohesion (the classes are too broad, they’re not specific enough to their individual task)
No separation of concerns (everything is clumped together)

These problems result in these complications:

Hard to understand
Hard to extend
Hard to re-use
Hard to test

What is it?

What is MVC?
MVC (Model-View-Controller) is a software architecture that aims to decouple the data (model) and the visual presentation (view).
Basically, your software will look more like this:

Model:

Contains all the data (can be a database)
It’s usually a one-to-one mapping to real-world objects and concepts
It responds to queries and operations on its state
It should be independent of both the controller and the view

Controller:

The link between model and view
Takes the user inputs from the view and updates the model accordingly
Can also update the view when the model has changed

View:

Graphically represents the state of the model to the user
Can consist of sub-views
Typically passive: responds to model updates
Receives user input, but passes this onto controller

Why use MVC?

Clear separation of concerns
Low coupling
Easy to maintain (especially view)
Easy to test
Promotes re-use
Can support multiple views:

How to implement it?

Usually MVC goes a little something like this:

Model model = new Model();
View view = new View();
Controller controller = new Controller();

controller.setModel(model);
view.setController(controller);

The view may or may not have access to the model; it depends on the implementation.
There are also different flavours of MVC, such as:

Passive model

Model responds to state change operations, but controller is responsible for notifying view.

Active model

Model responds to state change operations and notifies view of change (using observer pattern).

iOS MVC

Extension of active model; the controller fully handles the link between model and view (similar to model-view-presenter).

Now that we have these, can we implement Flappy Bird any better?

Now there’s more structure and it’s actually readable!

Where is it used / Alternatives?

MVC is used in a lot of places.
It’s central to Apple app development, and lots of frameworks use it (source):

Zend Framework for PHP
Django for Python
Rails for Ruby
Merb for Ruby (for the experienced)
ASP.NET MVC for .NET
Seaside for Smalltalk
Catalyst for Perl
AngularJS

Before I go into the types of variants, there is something called multitier architecture, or three-tier architecture.
Three-tier architecture refers to the use of multiple architecture patterns at each layer of the system:

Presentation tier

The user interface.

Translates tasks and results into a format the user can understand.

Logic tier

Moves and processes data between the two layers.

Coordinates the application, processes commands, makes logical decisions and calculations.

Data tier

The database.

Where information is stored and retrieved by the logic tier.

There are also a number of variants of MVC that differ slightly:

MVA: Model-View-Adapter - very similar to iOS MVC, as it’s all linear and the view and model are unaware of each other

MVP: Model-View-Presenter - similar to MVA, but the presenter handles the rendering logic and the UI event handling logic. It’s more suited for UIs and commonly used in the presentation tier.

PAC: Presentation-Abstraction-Control - like MVC, but better suited for multi-tasking and multi-viewing.

Abstraction => Model
Presentation => View
Control => Controller
There are structures called “agents”, which are a triad of presentation, abstraction and control instances. These agents all belong to different hierarchies, which all communicate to each other through their control instances.
It supports concurrency better as each third in the triad can be their own thread, however it’s more complex to build.

HMVC: Hierarchical MVC - pretty much the same as PAC
MVVM: Model View ViewModel - The view binds properties in the view model. Simplifies event-driven programming. Used in React, Angular and Vue.js.

Model-Delegate - the view and controller are bundled together into one. Java Swing is like this.

Naked Objects - the user interface is entirely automatically created from the definitions of the domain objects, typically using reflection. One example of this is the Admin Bundle from Sonata, which generates admin pages based on your model classes:

Here are some design patterns you can use in MVC:

Observer

The object is updated when ‘notify’ is called. Appropriate for either view or controller.

Strategy

Multiple strategies can be used to achieve the same goal in different ways.
Appropriate for controller to seamlessly change behaviour.

Composite

Create tree structures.
Appropriate for views and sub-views.

Software Testing

Validation testing: Does the system work? (ties into user stories)
Verification testing: Does the system do as it’s supposed to? (finds incorrect behaviour)

Programming problems can cause a number of errors:

infinite loops
underflow, overflow
division by zero
logic errors
segmentation faults

There are two kinds of testing:

Development testing: continuous testing that occurs during implementation
Acceptance testing: check if the software is compliant with the business requirements and if it’s suitable for delivery

Development testing

These tests are run during implementation, and:

Usually done by same team as implementing
Tests for defects and validity
Involves:

automated tests
code inspections

Automated testing can involve:

Unit tests - tests at class level.

Typically tests an individual class, and tests methods, properties and states.
They have an input and an expected output, and it compares the two. JUnit does unit tests.
Good tests should check for:

Validation - the system should work
Defect testing - the system copes with all possible inputs

Partition testing can be performed, where inputs from all the equivalence partitions are tested (e.g. with a method that gets a classification, you could test inputs that get you a 1, 2-1, 2-2, 3, Fail and Invalid input).
Boundary testing can also be performed, where boundary inputs are tested, for example the edges of a range of numbers (99.9 out of a range from 1 to 100).
Unit tests are black box tests, which means you only need to know the system’s API to write them.
Unit tests are used in:

Regression testing - testing previous features again to make sure newly added features doesn’t affect older ones
Continuous Integration - running test cases before a pull request, ensures no bugs occur in master branch
Test driven development - where you create tests first, and you implement the system based on those tests

Component tests - similar to unit testing, but it tests a whole component of the system instead of just a unit. It’s more coarse than unit testing, but it tests ‘units’ working in conjunction with each other
System / Integration tests - the next one up from component tests, it tests the components working together, sometimes the whole system.

These tests can highlight problems caused by:

usability
missing requirements
emergent behaviour

A lot of it can be manual (e.g. UI testing)

Acceptance testing

Acceptance testing relies on acceptance criteria, which are criteria for the software born from user stories.
They’re only really done towards the end, to ensure verification of the software.
For example:

Could give the acceptance criteria:

students can log in to handin with ECS credentials
student can select COMP2211 work
on selection, there must be an option to submit a file
must be possible to submit a .zip file
student is emailed receipt
work is stored in a database for marking

Acceptance testing fits into the equation as follows:

Acceptance testing also incorporates release testing, a form of black box testing done by a separate team.
It involves:

Requirements testing - testing by a requirements specification
Scenario testing - testing by scenarios / use cases
Performance testing - testing the performance with harsh inputs and low system specs

Load testing - puts a heavy number of concurrent users interacting with the system at the same time
Stress testing - tests the system under extreme loads. Can check for memory leaks, slowness, security issues and data corruption
Soak testing - testing a system with production load over a substantial amount of time
Breakpoint testing - tests a system upon various breakpoints (e.g. screen sizes when testing responsiveness of a website)

Another form of testing is user testing, which is testing with an actual user:

Alpha testing - renaming your variables so you don’t get variable capture software tested by users within the development team
Beta testing - substituting a value with a parameter in a function call software tested by users in their own environment
User Acceptance testing - customers test the software to make sure requirements have been met

Teamworking

To work in a team, you all need to express the five extreme programming (XP) values!
Remember these, because they’re important (for the exam):

Simplicity - Keep it simple, stupid! Take simple, small steps towards your goal. Don’t be too ambitious!
Communication - Stop watching anime and talk to your team.
Feedback - Listen to your customers; they’re usually always right. Be sure to get feedback from them, too.
Respect - Respect your team members. Basically, don’t be a dick.
Courage - If someone is doing shit, tell them they’re doing shit and give reasons why. If the release estimate is longer than what the customer wants, grin and bear, and tell them the truth. Don’t worry about what it means, just write the word “courage” in the exam and you’ll be good.
Dominance - oh shit! This isn’t supposed to be here

There’s four stages to working in a team:

Forming

You’ve just met your team. You’re wearing your best suit and you’ve got your best cologne / perfume on. You grin at your team, introduce yourself professionally and make a great first impression. Then you wake up and realise you’re 20 minutes late for your first SEG meeting.

Storming

You’ve had it up to here with your shit team. Nobody ever fucking works, they’re all lazy bastards, your team’s code is so bad you feel you’d get better code pressing your arse all over the keyboard and this project makes you want to fucking jump off the Mountbatten building.
And the best part is, everyone fucking hates you too.

Norming

Alright, they’re not that bad. They get some work done, enough to get a 2-2, maybe (even though your parents push for a 1st). They could be worse.

Skydiving Performing

Your group now consists of your bestest friends! You have perfect synergy and can work together happily and friction-free! Too bad you’ll never reach this stage because after SEG finishes you’ll never talk to your group members again!

So what makes a good team?
Here’s a few:

Good communication
Trust
Equal work distribution
Adaptability
Playing to each other’s strengths
Good leadership
Motivation

Time for the really delicate subject of ‘difference’! (I’m going to be careful with my jokes here)
You’ve got to be aware of individual differences:

Difference in personality traits

I don’t care if Joe is a perfectionist, don’t give him all the work 2 days before the increment 2 hand-in.

Learning styles

It’s perfectly fine to use the slides instead of my notes for revision.

Values

An optimist says the glass is half full. The pessimist says the glass is half empty. The realist says that, according to the burndown chart, we’re not going to finish increment 3 on time for the hand-in.

Ethnicity / Race

No, it’s not OK to put all the workload on the Indian guy because he’s Indian.

Beliefs

Samantha believes in horoscopes. This doesn’t mean she’s more stupid or less of a logical thinker than the rest of her teammates.

Age

Unless you’ve got a toddler on your team, you shouldn’t even know the ages of your team members before you all enter the “performing” stage.

Interests

Just because nobody in your group is a weeb like you, doesn’t mean you should barrage them with JoJo references every time they talk to you.

Sexual orientation

Don’t call the tests “gay” because the gay guy wrote them. That’s homophobic and you should be ashamed of yourself (unless the gay guy sees it as a joke and doesn’t mind, then it’s OK).

Intelligence

“I hate these nerds! Just because I’m stupider than them they think they’re smarter than me!” - Professor Hubert J. Farnsworth, Futurama

Religion

A Christian, a Buddhist, a Hindu, a Muslim and a Sikh walk into a bar.

They all sit down and work on their laptops together peacefully because they do not discriminate by religion.

Ability

What? We’re doing it in Java FX? But I don’t know Java FX...

Gender

Yes, Joseph identifies as a 1000uF 25V Radial 105 deg Capacitor. They’re working on the unit tests.

Personal motivation

Some people do Computer Science for the money and not because they’re interested in it. It happens. It’s OK.

Physical / mental disability

Don’t ask Alex how he committed when he doesn’t have any hands. He probably used one of those foot press things or an eye-tracker thing.

“Assume difference until similarity is proven”
Basically, assume that everyone is different from you until they say / do something that is similar to yourself. That way, you can distance yourself from others and justify your anti-social behaviour avoid any risky assumptions about others.

Also, culture plays a role in these sort of things.
Did you know that, after the age of 10, your base values don’t change?
Micro-inequities - subtle differences in how people show unconscious bias

members of a minority are more likely to encounter these

In case you didn’t level up your Social Skills stat when growing up, here’s some behaviour tips when talking to other people:

Attention and listening - No interrupting. Don’t be that guy.
Equality - Take turns. Shut the talkative ones up and let the quiet ones get their turn.
Diversity - Your thoughts are equally as valid as mine. Unless you don’t like JoJo. Then your opinion is wrong.
Ease - Eliminate continuous partial attention – multi-tasking doesn’t work (basically, pay attention)
Identify untrue limiting assumptions – Sometimes the ‘elephant in the room’ (talk about stuff if it bothers you)
Feelings - Encourage assertiveness and eliminate passive-aggressiveness (please please don’t be that passive-aggressive guy in the group. We’ve all met one; we don’t want to become one)
Encouragement - Minimise competition between team members for best possible thinking (unless you use competition as a strategy for better quality work)
Appreciation rather than criticism - Don’t get salty because someone roasted you for not capitalising your class names. Take it objectively and apply that feedback.
Turn agenda items into questions that need to be answered to get things done! Basically, if you have things on your to-do list, actually do them and don’t let them pile up.

Other Agile Techniques

First, what does agile actually mean?

Nimbleness and improvisation
Balancing flexibility and structure

Basically, don’t be too stuck to a plan; be flexible and respond to changes well.

The following are all examples of process models.
What is a process model? It’s an abstraction of a software process.
What’s a software process? A software process is that set of actions required to efficiently transform a user’s need into an effective software solution.

Agile Manifesto

Before that, though, let’s see how Agile is actually defined.
You can see the principles of Agile on this website made in HTML 3.2, insinuating that it hasn’t had an update since 1997: https://agilemanifesto.org/principles.html
They’re waffly, so let me simplify a few of them for you:

Principle in waffle language	Principle in normal speaking language
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.	Make customers happy by releasing valuable deliverables early.
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.	Listen to changing requirements, because that’s how Agile works.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.	Deliver working software within reasonable times, but try for shorter timescales.
Business people and developers must work together daily throughout the project.	Business guys and techies work together.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.	Motivate everyone to work hard and work smart.

There are plenty of Agile tools, some of which are stricter than others:

SCRUM

Scrum is a framework used for complex projects.
It is:

Lightweight
Simple to understand
Hard to master

On the off-chance you’ve not done any coursework with your team, Scrum has the roles Scrum master, Team member and Product owner. It uses things like burndown charts to measure performance and backlogs to handle tasks.
Scrum also has meetings called daily scrums where everyone states:

what they’ve done
what they’re going to do
what they need help on

XP

eXtreme Programming is another agile methodology.
Like all the others, it emphasises responding to change, but what makes it different is that it incorporates:

programming in pairs or doing extensive code review
unit testing of all code
avoiding programming of features until they are actually needed
a flat management structure (no masters or middle-management)
code simplicity and clarity
expecting changes in the customer's requirements as time passes and the problem is better understood
frequent communication with the customer and among programmers

Why is it called E X T R E M E programming? What’s so extreme about it?
It’s extreme because it takes the beneficial elements of traditional software engineering practices and takes them to the EXTREEEMEEEE!!!
For example, code reviews. You look at some code. Eh, it’s alright.
Yeah, but now it’s EXTREEEMEEE!!! and now code reviews are performed while you’re still programming (continuously)! This is what pair programming is.

If you don’t know the values of XP already, it’s:

Simplicity
Communication
Feedback
Respect
Courage

But do you know the 12 core practices of XP?

The planning game - make and prioritise requirements (user stories) for the next release
Whole team - dev team has access to a real live customer
Test Driven Development - write tests before the code itself
Pair Programming - two developers working on the same computer
Small releases - start with the smallest feature set first and work your way up
Continuous integration - all tests must pass before a feature is integrated
Design improvement - throughout implementation, design should evolve and be simple (refactoring is an example)
Collective ownership - any developer can edit any code anywhere
Metaphor - everyone constructs metaphors to model the system
Simple design - keep it simple, stupid!
Coding standards - have a coding standard that everyone follows for neat, consistent code
Sustainable pace - work at a comfortable pace (used to be 40 hours a week, or 9-5)

Spike solution: a solution implemented in XP so the team knows they’re on the right track. Similar to a prototype

FDD

FDD is similar to Scrum and XP in the way that we build up a features list and implement the features iteratively.
However in FDD there are two key roles:

Chief Architect
Chief Programmer

There’s more management in FDD than other agile methodologies.

ASD

ASD (adaptive software development) replaces the waterfall cycle with a repeating series of speculate, collaborate, and learn cycles.
It’s a more iterative and shorter-interval version of RAD (rapid application development).
Like with any other agile methodology, it involves:

a lot of user involvement
integrates testing into every stage
emphasis on rapid iterating

But keep in mind that ASD predates agile software development, so it might not seem so special compared to Scrum or XP.

Kan Ban

Kan Ban is like Scrum, but less structured and more flexible.
Kanban (看板) is Japanese for “visual signal” or “card”. It was used by Toyota.
It’s literally just post-it notes on a bunch of to-do lists, labelled “to-do”, “doing” and “done”.
There are only 4 core principles of Kan Ban:

Visualise work - you can see the flow of work as post-it notes move around
Limit work in progress - you can limit how much work is in progress in the “doing” list
Focus on Flow - you can use the flow of work to your advantage and collect metrics, smooth out work and get indicators of future problems
Continuous Improvement - people can track their work flow through the movement of post-its, and this process model is flexible enough to change it to maximise your team’s effectiveness

Crystal methods

Crystal methods focuses more on the people working than the actual project itself.
Different methodologies are applied to projects of different “types”.
What are these types?

Each of these cells is a crystal method.
The size of the project (number of people working on it) is the “weight”, for example a huge project with 200 people on it would be maroon, and a small one with 5 people on it would be clear.
The criticality of the project is taken into account too, for example a project that really needs to be done (increment 3) would be in the ‘Life’ category, and a project that can be done any time would be in the ‘Comfort’ category.
These two categories are put into a pair, and that pair is the crystal method that is applied.

There are 7 properties that Crystal holds:

Frequent Delivery - release deliverables!
Continual feedback - team meets on a regular basis, team listens to stakeholder feedback
Constant communication - with small teams, they’re in the same room, but big teams are co-located in the same facility
Safety - you can speak your mind, also project safety based on criticality is considered (space shuttle system is very critical)
Focus - team members should know who’s working on what and they should be given time to do them without interruption
Access to users - team has access to end users who will use the software
Automated tests and integration - have tests

The crystal cycle goes as follows:

It’s pretty much the same as Scrum or something, where you iterate deliveries, where your stakeholders give you feedback, and after n number of deliveries it’s ready for deployment.

DSDM

DSDM is a more governed and disciplined version of RAD.
Instead of the features being fixed, it’s time, quality and cost that are fixed. This gives the software more flexibility with its features.
What’s different about DSDM is that there is a pre-project phase (envisioning)
There are more hierarchical roles (more management)
The 8 principles of DSDM are:

Focus on the business need - Ensure verification
Deliver on time - no slacking off!
Collaborate - work with others
Never compromise quality - quality over quantity
Build incrementally from firm foundations - build from something small, one bit at a time
Develop iteratively - basically what I just said
Communicate continuously and clearly - talk to others
Demonstrate control - assert your dominance

Shu-Ha-Ri

You don’t have to follow these methodologies by the book.
Eventually, you’ll use them so much that you’ll “invent” your own way of doing things without even thinking.

To explain further, let’s ask: how do we learn to do anything?
There are three phases in which we learn stuff, called Shu-Ha-Ri. It comes from Aikido.

Phase	Explanation	Example
Shu	You’re new to this stuff, and you do things by the book exactly how it’s written.	You’re just learning Java. Everything is brand new, and you’re always copy-pasting stuff and looking stuff up. If there’s something you need to do, you look it up and copy what other people have done.
Ha	You reflect upon what you’re doing. You start to question why you’re doing what you’re doing and you enter a deeper understanding of what you’re doing.	You start to spot patterns in Java and learn them by accident. Sooner or later, you’re able to code and solve problems by yourself. You’re not perfect, but you feel yourself reaching some greater point of understanding.
Ri	The student has become the master! You can now think originally and apply background knowledge of this stuff to original thoughts.	You’ve entered a higher level of understanding and now you care less about implementation and more about how you do things.

You can remember this by:

Imitate
Assimilate
Innovate
Eviscerate

Applying this to software development...

You’ve just started using XP. You’re reading the step-by-step guides and doing everything by the book.
You start to get used to it. There are things you like and things you don’t like. You start to reflect upon the XP practices. You start to bend the rules of XP a little to suit your needs.
You don’t care if you’re doing XP or not; your understanding is deep enough so that you have full control.

Beyond HCI - Designing for Delight

What does “Designing for Delight” mean?
It means that your design shouldn’t only just work; it should also be pleasant.
For example:

A clicky keyboard gets the job done, and it’s also nice to use (for some people).
Chrome’s dinosaur game is easy to start, play and is addictive (for some people).
Opening an iPhone box is satisfying and also serves its intended purpose.
The Foo Fighters home page is also a delight. (No, not this one; this one!)

Design should incorporate three factors, as stated by Sir Henry Wotton in 1624 and Vitruvius in the first century AD:

Commodity
Firmness
Delight

Pick up on the little details, like colours, fonts, etc
See things from the users perspective (this is called “charge before use”)

Like in interaction design, don’t think of people’s cognition starting and ending with their brain; they use other stuff, too!

Also, think about supporting existing information flows. Don’t try to break / change flows that people are used to. People don’t like change!
Instead, work with their work flow and they’ll appreciate your design more.

TL;DR

Banging your head against the wall because you don’t like SEG and think it’s the worst module ever because the content isn’t technical and/or logical, therefore it’s harder and more annoying to learn and as a result you feel pressured and stressed?
Chill! You can do this. You made it through Professional Development and Interaction Design (probably), so you can do this too!
Have a skim through this summary of all the content above.
Remember: read all of the above before you read this!

Envisioning

Primary stakeholders: people who use system directly
Secondary stakeholders: do not directly use but receive output / provide input
Tertiary stakeholders: are affected by system but don’t interact with it
Facilitating: developers, designers, maintainers

Persona: stereotype of a group of users
Scenario: persona interacting with system

User story: what the user wants to achieve
Writing good user stories:

Independent: your user story should achieve one goal
Negotiable: you can talk to your product owner about this
Valuable: is this user story actually any good to you?
Estimatable: you can estimate the size of the story
Small: if it’s too complicated, can split into smaller user stories
Testable: you can get your product owner to perform this user story

Agile development: frameworks and practices that emphasise response to change
Scrum: an Agile framework that uses user stories, backlogs and sprints
Product backlog: list of requirements for a system
MoSCoW prioritisation: must, should, could, would
Burndown chart: chart of how fast tasks are being completed
Scrum meeting / Scrum: 10-15 minute meeting stating what you did, what you’re going to do and what you need help on

Show stopper: high probability high severity risk

User story estimates:

T-shirt sizes: S M L XL
Story points: raw integers, can have various ranges

Agile planning poker: group activity for estimating task durations

User stories are broken down into tasks