Software Processes CSC 4700 Software Engineering

Software Processes CSC 4700 Software Engineering CSC 4700

Software Development Processes CSC 4700

The software process • A structured set of activities required to develop a software system • Specification; • Design; • Validation; • Evolution. • A software process model is an abstract representation of a process. It presents a description of a process from some particular perspective. CSC 4700

The old way • The way software is engineered has evolved over the years • The “new” ways of software engineering resemble the “old” ways in a lot of ways • See if you can make out the resemblance CSC 4700

Waterfall model CSC 4700

Waterfall Model • Inflexible partitioning into distinct stages makes it hard to deal with changing customer requirements. • Only works when requirements are well-known and few changes are expected… which is rare! • The waterfall model is still used for some large, multi-site projects, but used less and less CSC 4700

Evolutionary development CSC 4700

Evolutionary development • Problems • Throw-away prototyping might waste work • Lack of process visibility • Systems are often poorly structured, evolve • Special skills (e.g. in languages for rapid prototyping) may be required • Applicability • For small or medium-size interactive systems; • For parts of large systems (e.g. the user interface); • For short-lifetime systems. CSC 4700

Incremental development CSC 4700

Process Iteration & Incremental Delivery • System requirements ALWAYS evolve in the course of development • Iteration can be applied to any of the generic process models • Break down software into “releases”, deliver incrementally (version 1.0, version 2.0, etc.) • “Freeze” requirements during a release CSC 4700

Spiral model of the software process CSC 4700

Spiral development • Process is represented as a spiral rather than as a sequence of activities with backtracking. • Each loop in the spiral represents a phase in the process. • No fixed phases such as specification or design - loops in the spiral are chosen depending on what is required. • Risks are explicitly assessed and resolved throughout the process. CSC 4700

The new way • Agile – it’s Spiderman at the keyboard • Extreme – it’s like totally radical • Scrum – what’s rugby got to do with it? CSC 4700

The Agile Approach (1) • Continuous delivery of software • Cycle is weeks rather than months • Working software is the principal measure of progress • Even late changes in requirements are welcomed • Close, daily, cooperation between business people and developers • Face-to-face conversation is the best form of communication. CSC 4700

The Agile Approach (2) • Projects are built around motivated individuals, who should be trusted • Continuous attention to technical excellence and good design • Simplicity • Self-organizing teams • Regular adaptation to changing circumstances • From the Agile Manifesto (Google it) CSC 4700

Extreme programming • Perhaps the best-known and most widely used agile method. • Extreme Programming (XP) takes an ‘extreme’ approach to iterative development. • New versions may be built several times per day • New version delivered every 2 weeks • All tests run with each build, all must pass • Doesn’t reinvent the wheel – use COTS whenever possible and affordable CSC 4700

The XP release cycle CSC 4700

Extreme programming practices 1 CSC 4700

Extreme programming practices 2 CSC 4700

Problems with agile methods • It can be difficult to keep the interest of customers who are involved in the process. • Team members may be unsuited to the intense involvement that characterises agile methods. • Prioritizing changes can be difficult where there are multiple stakeholders. • Maintaining simplicity requires extra work. • Contracts may be a problem as with other approaches to iterative development. CSC 4700

Testing in XP • Test-first development • For each and every component (class, module, whatever) you develop, add one or more tests at the same time • Building means compiling the code and running all the tests, automatically • Keeps software working all the time CSC 4700

Pair programming • In XP, programmers work in pairs, sitting together to develop code. • This helps develop common ownership of code and spreads knowledge across the team. • It serves as an informal review process as each line of code is looked at by more than 1 person. • It encourages refactoring as the whole team can benefit from this. • Measurements suggest that development productivity with pair programming is similar to that of two people working independently. CSC 4700

SCRUM Approach • Backlog – list of all of the tasks to get done • Sprint – short iteration, get current backlog items done in this time • Scrum – short, daily stand-up meeting • Planning session – start of each sprint, plan which backlog items will be done • Heartbeat retrospective – end of sprint, reflect about the past sprint CSC 4700

SCRUM stuff • Scrum Master - removes impediments to the ability of the team to deliver the sprint goal, not the team leader • Self organizing teams – magically everybody gets organized • Easily adapt to change – major benefit CSC 4700

Software Processes CSC 4700 Software Engineering