The Software Development Lifecycle

• Bullet One
• Bullet Two
• Bullet Three

Where does it all fit in?

• Product concept: How can we solve the problem with software?
• Product design: Epics, user stories, acceptance criteria, UI design
• Stack design: frontend, backend, data layer, integrations
• Software design (OO): Entities, objects, relationships (UML diagram)

Project Intro

The Big Design Up-Front vs Incremental Design

"Traditional Engineering"

• One step at a time
• Ensure the current step is perfect before moving onto the next one
• A big design up front
• Project can take months-years to complete

Problems with Designing Up-Front

1. The game changes
   • ​Changing market
   • Changing client expectations
   • Changing technical world
2. Evolution of Requirements
3. Too many unknown unknowns

Unknowns

Two types of unknowns:

1. Known unknowns - we know that it exists, but we don't know what it is
2. Unknown unknowns - that which we had never even thought to consider

​System Complexity

• Systems become exponentially more complex as they grow in size 
• Complexity leads to unknown unknowns
• This is why things go wrong
• Learn to deal with unknowns gracefully as they arise

Iterative Design

• Work in sprints, iterations, milestones
• 'Agile' software development
• Many variants - eXtreme programming, Rapid Application Development, Kanban, Scrum
• Design incrementally
  • Adapt to changes in requirements
  • Discover and deal with problems in design as they arise

Problems with Incremental Design

• No clear sense of direction/trajectory
• In poorly designed systems, adaptations to new requirements become smaller-scale 'workarounds' - limit functionality/decrease maintainability
• Tendency to 'make it up as we go along'

A solution?

• High Level Design
  • Design a broad overview up-front
  • A framework to begin development
  • Set the trajectory and boundaries of work at the start
• Adapt and change the design during development as needed
• Design up-front a solution that is open for extension, reusable, etc.
• Complete work in small increments and improve iteratively
• Milestone 1 

Project Management

• There is always too much work and not enough time and resources in Software Engineering
• Prioritisation - what's the most important?
• Work to complete is a Priority Queue
• Incremental development
  • Start with the most basic working app
  • Minimum Viable Product

Planning

• Breakdown of tasks
  • Use High Level Design to break work down into tickets / tasks
  • Highlight logical dependencies between tickets
  • Create tickets at the smallest possible feature level
• Determine priorities for each ticket (high, medium, low)
• Determine story points for each ticket
  • Assign points based on relative complexity

Software Delivery

• We are emphasising how you deliver your software rather than how you manage your project
• Process to follow for each ticket (See Section 12.3.1 of the spec)
• Slower today, faster forever

Best Practice PRs

• A good pull request / merge request:
  • Touches as few files as it can
  • Has a clear title and description, or links to documentation
• A bad pull request:
  • Contains irrelevant changes
  • Contains accidentally committed files
  • Contains a very large number of changes (should split PR - into sections, or work your way up the dependency tree)

Bad PR Example

Good PR Example

Assessment

• Four key areas:
  • Correctness
  • Design
  • Testing (Wednesday lecture)
  • Delivery
• Quality over quantity

Teamwork

• Everyone needs to write code and contribute to documentation (PM, UML, etc.)
• Tutor & project check-ins - mentoring & guidance
• Dealing with teamwork problems:
  • Make an active effort to resolve internally
  • Speak to your tutor
  • Email cs2511@cse.unsw.edu.au
• Individual blogging

Advice

• Please be patient
• Start today