Computer Science / Software Engineering Notes Network

Software Engineering Group Project

Matthew Barnes

Envisioning        2

Stakeholders and Personas        2

User Stories, Planning, Risk        3

User stories        3

Agile planning        4

Risk Assessment        6

Planning        7

User story estimation        8

T-shirt sizes        8

Story Points        8

Agile Planning poker        8

User story breakdown into tasks        12

Introduction to Source Control        12

Advanced Git        14

Starting to Build: Scenarios, Storyboards        15

Storyboards (static design)        15

Scenarios (dynamic design)        16

Building Applications using MVC        17

What problem does it address?        17

What is it?        18

How to implement it?        19

Where is it used / Alternatives?        20

Software Testing        24

Development testing        25

Acceptance testing        26

Teamworking        27

Other Agile Techniques        30

Agile Manifesto        30

SCRUM        31

XP        32

FDD        34

ASD        34

Kan Ban        34

Crystal methods        35

DSDM        36

Shu-Ha-Ri        37

Beyond HCI - Designing for Delight        38

TL;DR        39

Envisioning        40

Introduction to Source Control        40

Starting to Build: Scenarios, Storyboards        40

Building Applications with MVC        40

Software Testing        40

Teamworking        40

Other Agile Techniques        40

Beyond HCI - Designing for Delight        40

Envisioning

Stakeholders and Personas

User Stories, Planning, Risk

User stories

Agile planning

  1. What must be done
  2. What should be done
  3. What could be done
  4. What would be nice, but won’t have time for

Risk Assessment

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

User story estimation

T-shirt sizes

Story Points

Agile Planning poker

  1. Each participant gets a deck of estimation cards. These cards could be T-shirt sizes, square numbers, fibonacci etc.
  2. The moderator picks a user story and shows it to the team.
  3. The Product Owner answers any questions regarding the user story.
  4. Each participant picks an estimation card they think is right for the user story. They hold it face-down.
  5. When everyone is ready, they all show their estimation cards.
  6. 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.
  7. 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).

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

Introduction to Source Control

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

Advanced Git

Starting to Build: Scenarios, Storyboards

Storyboards (static design)

Scenarios (dynamic design)

  1. David opens a web browser and enters the URL of PuffinShare
  2. The home page is displayed
  3. David can enter tags into the search box
  4. When he presses the ’Go’ button, the puffinShare repository is searched
  5. Items matching the tags are retrieved and displayed in the output box on the RHS
  1. David can select one of the retrieved items and the resource page is displayed
  2. David can navigate to these pages by selecting their tab:

Building Applications using MVC

What problem does it address?

What is it?

How to implement it?

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

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

Where is it used / Alternatives?

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.

Software Testing

Development testing

Acceptance testing

Teamworking

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.

Other Agile Techniques

Agile Manifesto

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.

SCRUM

XP

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

FDD

ASD

Kan Ban

  1. Visualise work - you can see the flow of work as post-it notes move around
  2. Limit work in progress - you can limit how much work is in progress in the “doing” list
  3. 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
  4. 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

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

DSDM

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

Shu-Ha-Ri

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.

  1. You’ve just started using XP. You’re reading the step-by-step guides and doing everything by the book.
  2. 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.
  3. 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

TL;DR

Envisioning

Introduction to Source Control

Starting to Build: Scenarios, Storyboards

Building Applications with MVC

Software Testing

Teamworking

Other Agile Techniques

Beyond HCI - Designing for Delight