There are a number of approaches to software development or software development life cycles (SDLC). In this course we only examine three possibilities: Waterfall, Spiral, and Agile.
All approaches need to perform the same tasks from the VCAA Problem Solving Methodology (PSM); however, they emphasize different aspects and complete them in different sequences.
This model steps through the Stages of Software Development in Sequence without going back a stage.
This requires that every stage is completed perfectly as the designers will have to trust the requirements passed to them and the software engineers will follow the designs passed to them etc...
After maintaining the software for a while, if it is not or no longer meeting the requirements of the users then the process starts again from the top.
Inherited from more traditional engineering disciplines where it makes a lot of sense. e.g., building a bridge.
Where it is used:
large projects with a big team and big budget
where the scope and requirements are clearly defined;
Clear summary at guru99.com: What is the waterfall model & Pros and Cons
Software that requires more exploration, user feedback and continual change, e.g., Web Apps like Facebook, are not suited to such clearly defined and separated phases.
NASA's Recommended Approach - looks waterfall-ish...
...but these are not separated phases!
A risk-driven approach to software development. For large software that requires both ongoing evolution and development as well as reliability and security.
Clear summary at: guru99: What is spiral model & when to use it
Example: The Microsoft Solutions Framework with interim milestones is a security focused spiral approach to the SDLC. For many aspects of development, Microsoft is now using a much more agile approach, but still with a security focus with their SDL.
The name "Agile" became attached to a range of iterative development methods where requirements and solutions evolve through collaboration between development teams and users. The Agile Manifesto (right) written in 2001 is a clear response to some of the problems with the Structured/Waterfall approach.
The agile cycle time can range from a day to months.
Clear notes at guru99: What is Agile Software Development Model?
Variants / Aspects of Agile Programming to investigate: Lean Software Dev, Scrum, Extreme Programming, Kanban, Test Driven Development, etc...
Characteristics of the agile approach include:
It is quick to get initial version to market
Iterative improvements with working versions delivered after each iteration
Continual interaction between the developer and clients throughout the development process
Responds well to changing requirements or where the requirements are initially unclear
Suitable for many webapps as it is easy to push new versions (c.f., updating desktop software).
Disadvantages include:
Uncertainty in time & cost of building the software
Often does not produce good documentation of the project
Not suited to large, monolithic projects
Facebook - Rapid release at massive scale
Microsoft - How Microsoft Builds Software (1997), Solutions Framework (2007), Security Development Lifecycle (Current), etc...
How Microsoft dragged its development practices into the 21st century
A history of Software Development Methodologies from a Computer Science and Engineering presentation at USC.
Second half of the video is case studies (NASA, Microsoft, Facebook, Google, Linux, Valve, etc...)
Has lots of engineering and design principles, but not really a fixed development approach/structure. This has changed over time...
Quoted from Good Agile, Bad Agile (a long blog post)
"From a high level, Google's process probably does look like chaos to someone from a more traditional software development company. As a newcomer, some of the things that leap out at you include:
there are managers, sort of, but most of them code at least half-time, making them more like tech leads.
developers can switch teams and/or projects any time they want, no questions asked; just say the word and the movers will show up the next day to put you in your new office with your new team.
Google has a philosophy of not ever telling developers what to work on, and they take it pretty seriously.
developers are strongly encouraged to spend 20% of their time (and I mean their M-F, 8-5 time, not weekends or personal time) working on whatever they want, as long as it's not their main project.
there aren't very many meetings. I'd say an average developer attends perhaps 3 meetings a week, including their 1:1 with their lead.
it's quiet. Engineers are quietly focused on their work, as individuals or sometimes in little groups or 2 to 5.
there aren't Gantt charts or date-task-owner spreadsheets or any other visible project-management artifacts in evidence, not that I've ever seen.
even during the relatively rare crunch periods, people still go get lunch and dinner, which are (famously) always free and tasty, and they don't work insane hours unless they want to."