Software Development Life Cycle

Gergő Pintér

gergo.pinter@uni-corvinus.hu

content

software development life cycle
waterfal
V model
incremental
agile
- SCRUM
kanban

waterfall model

criticism

Clients may not know exactly what their requirements are before they see working software and so change their requirements, leading to redesign, redevelopment, and retesting, and increased costs. [1] In most cases the people who comission the building of the a software system do not know exactly what they want and are unable to tell us all they know.

modified waterfall model

V model [3]

still rigid
each phase has output and a review process
- errors are found at early stage
- decreases the risk of failure
large to small: testing is done in a hierarchical perspective

iterative model

software is built incrementally,
- with each iteration adding new features or refining existing ones
possible to get feedback after each iteration
can be rigid within an iteration

agile model

continuous collaboration and fast response to change, while the iterative model takes a more gradual approach, building up the final product over multiple iterations
scrum is an agile methodology

the agile manifesto

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

agilemanifesto.org

Principles behind the Agile Manifesto

The agile does not mean a specific methodology, so SCRUM is not the only agile approach (the course will cover SCRUM later), and agile is not the only approach.
The documentation is still important, the course will cover later what and how should be documented, but the point is no matter how much documentation you have, if the software does not work as expected.
In the business world, contracts are important, especially contract violations and the penalty clauses, but customers should be treated as a partner, and collaborative communication should come first, before giving more jobs to the lawyers.
Planing is import (even having a plan B is often advisable), but the world is in constant change, so flexibility is required. Compared to the waterfall, which requires you to follow the initial plan, agile allows changes during the development. Remember, programming is more like gardening.

There are also twelve principles behind the Agile Manifesto, that provides some more detailed interpretation for the values.

1. Principle behind the Agile Manifesto

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Release early. Release often. And listen to your customers.

Eric S. Raymond: The Cathedral and the Bazaar (1997)

2. Principle behind the Agile Manifesto

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

Principles behind the Agile Manifesto

3. Principle behind the Agile Manifesto

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

4. Principle behind the Agile Manifesto

Business people and developers must work together daily throughout the project.

5. Principle behind the Agile Manifesto

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

6. Principle behind the Agile Manifesto

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

7. Principle behind the Agile Manifesto

Working software is the primary measure of progress.

8. Principle behind the Agile Manifesto

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

9. Principle behind the Agile Manifesto

Continuous attention to technical excellence and good design enhances agility.

10. Principle behind the Agile Manifesto

Simplicity–the art of maximizing the amount of work not done–is essential.

11. Principle behind the Agile Manifesto

The best architectures, requirements, and designs emerge from self-organizing teams.

12. Principle behind the Agile Manifesto

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

manifesto for software craftsmanship

As aspiring Software Craftsmen we are raising the bar of professional software development by practicing it and helping others learn the craft. Through this work we have come to value:

Not only working software, but also well-crafted software

Not only responding to change, but also steadily adding value

Not only individuals and interactions, but also a community of professionals

Not only customer collaboration, but also productive partnerships

That is, in pursuit of the items on the left we have found the items on the right to be indispensable.

agile vs. waterfall

agile	waterfall
incremental	sequential
phases repeated	phases completed exactly once
flexible	rigid
allows changes during the development	no change once the development started

agile vs. waterfall

Can waterfall work? Yes, it can, if the customer exactly knows what they want and can express it in technical terms.

Although usually the customer does not know what they want, so agile usually work better.

SCRUM

kanban

notes move from left to right
order denote priority
allways process the right- and topmost one to finish it ASAP
tool-dependent but a note can indicate:
- who’s responsible
- how much effort to do it
- etc.

kanban for job hunting

kanban in software development

SCUM + kanban = scrumban

SCRUM and kanban can coexist
quite new methodology

references

[1]

D. L. Parnas and P. C. Clements, “A rational design process: How and why to fake it,” IEEE transactions on software engineering, no. 2, pp. 251–257, 1986.

[2]

W. W. Royce, “Managing the development of large software systems: Concepts and techniques,” Proc. IEEE WESTCON, Los Angeles, pp. 1–9, 1970.

[3]

K. Forsberg and H. Mooz, “The relationship of system engineering to the project cycle,” Center for Systems Management, vol. 5333, 1991.