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

Make sure clients are getting what they want early and regularly

Welcome changing requirements

Don’t be frustrated with change

Deliver working software frequently

Work on a little chunk and then deliver it

Collaborate daily

Talking to clients and working with teammates daily

Motivated individuals

Place trust in team. Let each member do what they need to do to make the project successful

Face-to-face conversation

Look at client/team when talking to them. Pick-up on non-verbal cues

Measure of Progress through working product

Lok at what you achieved, not where you are on the plan

Promote sustainable development

Important for team members to work consistently, but also good to spread them around different projects

Continuous attention to technical excellence

Lots of models to help manage this

Simplicity is essential

Focus on what client wants and do it really well

Self-organising teams

Give teams responsibility to manage themselves

Regularly reflect on continuously improving

Don’t complete something and then move on to the next stage. Go back and learn from it

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.