System Development - Seminar 2

Predictive SDLC

A life cycle where the requirements are well understood and define. This poses a low technical risk to the team and they can generally start right away.

Adaptive SDLC

A life cycle where the requirements and needs are uncertain. This could be due to a few different reasons such as the client not know their needs or the technology being used being relatively new. There’s a higher technical risk associated with this, despite this however, most software development projects fall on this side of the spectrum

Frameworks

Provide structure and direction on a preferred way to do something. These are very broad and offer more flexibility.

Methodologies

Set of principles, tools and practices. Conventions that a team agree to follow to achieve a particular goal.

Traditional Predicative Thinking

Do one phase and go onto the next one in a series of sequential stages. There’s no going back to previous stages with this. An example of this thinking is the Waterfall framework. Provides little opportunity for change and needs to have a lot of documentation.

Adaptive Thinking

This offers a more flexibility and implements more analysis and design along the way. There’s also a closer relationship the client as this offers more frequent and short interactions with them. Issues are found more frequently and the ability to meet deadlines increases due to shorter amount of time spent on project.

Agile

An iterative approach to software development. Project consists of small iterations, each of which sees new features being added to the final product. Chances of not delivering what client wants reduces significantly.

Agile Manifesto (Values)

• Working software over comprehensive documentation

• Individuals and interactions over process and tools

• Customer collaborations over contract negotiations

• Responding to change over following a plan

Working software over comprehensive documentation

Understand requirements through user stories. Not about no documentation, just not excessive documentation.

Individuals and interactions over process and tools

Understanding that individuals involved and communication styles are key to this project.

Customer collaborations over contract negotiations

See the customer as part of the team and constantly collaborate with them.

Responding to change over following a plan

Don’t immediately say no to change. Instead look at it and see how to work with it.

Satisfy the customer

1st Agile Principle

Welcome changing requirements

2nd Agile Principle

Deliver working software frequently

3rd Agile Principle

Collaborate daily

4th Agile Principle

Motivated individuals

5th Agile Principle

Face-to-face conversation

6th Agile Principle

Measure of Progress through working product

7th Agile Principle

Promote sustainable development

8th Agile Principle

Continuous attention to technical excellence

9th Agile Principle

Simplicity is essential

10th Agile Principle

Self-organising teams

11th Agile Principle

Regularly reflect on continuously improving

12th Agile Principle

Product owner

Client’s representation, defines what has to be provided for this project, accept and reject work items and decide how team moves forward.

Scrum Master

Ensures that principles of Agile are being followed and that team is productively building the system

Development team

Small, cross-functional team that’s responsible for developing the system. Generally have specialists for different fields but each member can do work related to the system that’s outside their specialisation.

Product Backlog

Single source of requirements for system. This is constantly changing and can contain things that aren’t mandatory (things are prioritised to maximise value).

Sprint Backlog

List of things that are going to delivered at each Sprint. Product owner sits with team and decides which bit of functionality they should work on next. After this, they discuss how they will deliver the functionality.

Product Increment

End product for each sprint. This needs to be of high enough quality to meet user’s requirements and meet the Scrum team’s definition of DONE.

Burndown Chart

Way of seeing the total estimated work remaining for the entire forecasted sprint backlog against time. Can make predictions about how the team will progress based on how they’re tracking currently.

Kanban board

Displays live status of progress on the system and how each member of the team is going.

Project sponsor

The ones selling the project to the rest of the organisation. Usually a very senior person.

High influence - low interest

Keep these people on your radar and make sure that they’re happy and continue to have little interest. If they have interest, that means something has gone wrong.

High influence - high interest

Manage these people very closely as they’re the ones who really want this to succeed.

Low influence - low interest

Nothing to worry too much about, but they’re still impacted somehow.

Low influence - high interest

Good to keep them informed as they also want this to succeed, but ultimately have no power within the organisation and how the system is deployed.