CIS224 Software Projects: Software Engineering and Research Methods

1. CIS224Software Projects: Software Engineering and Research Methods David Meredith d.meredith@gold.ac.uk www.titanmusic.com/teaching/cis224-2007-8.html Lecture 2a Development Process (Based on Stevens and Pooley (2006, Chapter 4) and Fowler (2004, Chapter 2))

2. How do we build good, large systems? • Large project may take several people several months or years to complete • Don’t just tell them to deliver product when it’s finished • Might tell them we want part A finished in 1 month, part B finished after 2 months etc. • Large projects should be broken down into short phases with unambiguous milestones • How do you eat an elephant? • One spoonful at a time!

3. The need for a plan • Large project has to follow a plan • So can evaluate what has been achieved • Determine whether project is on schedule and within budget • Need to systematically document project • So that people can join and leave mid-way through • So that system can be maintained when it is delivered • Usually use a development process or methodology to manage a large software project

4. Development process and methodology or method • Development process • The type of plan and way of working adopted within a particular software project • The rules that define how project carried out • Describes documents, design models and artifacts that should be delivered and in what order • Methodology, method • techniques for developing design models • usually specifies modelling language to be used (e.g., UML) • specifies method for capturing user requirements

5. Model • an abstract representation of a specification, a design or a system, from a particular point of view • usually expressed using diagrams • represents essentials of a particular aspect of a system or project without irrelevant details • allows team members to focus on a particular aspect of project without getting side-tracked • purpose of model is to communicate • a model must have a precise and well-understood meaning

6. Modelling language • Way of expressing the different models used in a project • Defines collection of model elements which are the building blocks of the models we construct • Modelling language is usually diagrammatic • in which case, model elements will be graphical elements of diagrams (e.g., types of arrow, types of box, etc.) • Modelling language has syntax and semantics • Syntax • rules governing how the model elements can be put together to make legal models • Semantics • rules governing how a legal diagram should be interpreted

7. What makes a good modelling language? • Sufficiently expressive • need to be able to use the language to express those aspects of the project and system that we need to discuss and describe • Easy to use • needs to aid development, not hinder it • Unambiguous • model must have a precise meaning so everyone interprets it in the same way • Widely used • so that people in the industry can understand a model even if they are new to a project

8. Waterfall process • Software life-cycle broken down into 5 large phases • Assumes that once a phase has ended, we never return to it • This is nearly always impossible because we don’t always make the right decisions • e.g., if requirements change during testing, we have to revisit the analysis and design phases • Waterfall process doesn’t work because we always need to be able to revise earlier decisions

9. Iterative process • Every decision involves taking a risk - the risk that the decision is the wrong one! • Need to manage such risks in a software project • The more you build on a decision, the harder it is to go back and change it, if it turns out to be wrong • Need to find out as soon as possible whether or not a decision is right • do this by having frequent evaluation steps during the development process • One of the biggest causes of failure in software projects is requirements change or misunderstanding • Users find it easier to criticise a working system than to imagine a perfect one • better to present users with prototypes for evaluation during the development process

10. A simple spiral process See Boehm, B. (1988). A spiral model of software development and enhancement. IEEE Computer, 21(5): 61—72. Engineer: design, implement, test Evaluate Analyse requirements for this iteration Analyse risks and plan

11. Iterative process • Decomposes software into subsets of functionality • Does complete software life-cycle for each subset of functionality before going on to the next • Production quality software produced on each iteration • Beware of “pseudo-iterative” development process: • "We are doing one analysis iteration followed by two design iterations..." • "This iteration's code is very buggy but we'll clean it up at the end."

12. Time-boxing • An iteration is forced to be of a fixed duration • If necessary, must sacrifice functionality, not quality or delivery • Learning to sacrifice functionality is good practice for when have to decide at big release between sacrificing functionality or delaying release • Helps developers to prioritise requirements and identify what is really necessary

13. Rework • Iterative development implies reworking and deleting existing code • Seen as bad in manufacturing • But in software engineering, rework is not necessarily bad • Often easier and less error-prone to rework code than patch badly-made existing code • “Be prepared to throw one away” (Brooks, 1975)

14. Making rework more efficient • Automated regression • Detecting defects introduced by changes • See www.junit.org • Refactoring (Fowler, 1999) • Change existing software by making a series of small behaviour-preserving transformations • Transformations can be automated • See www.refactoring.com • Continuous integration • www.martinfowler.com/articles/continuousIntegration.html • automatic build (including test) each time a team member checks code into the code base

15. Hybrid development processes • Neither waterfall nor iterative processes are ever “pure” • Always some “back-flow” in the waterfall process • e.g., need to revisit design half way through implementation • Exploratory phase before first iteration in an iterative process • To get high-level view of requirements • Usually non-iterative phase at end of iterative development for user training, ironing out final bugs, etc. • Hybrid development processes • e.g., Rational Unified Process

16. What is a good development process? • Uses iteration to manage risk • Supports architecture-centric, component-based design • Has high level of user involvement • Should be use-case driven • Should allow users to evaluate prototypes and partial solutions frequently

17. (Rational) Unified Process (RUP) • Proposed by • Jacobson, I., Booch, G. and Rumbaugh, J. (1999). The Unified Software Development Process. Addison-Wesley. • Accepts the need for non-iterative preliminary phase for planning, risk-assessment and high-level requirements capture • Accepts the need for non-iterative phase at the end of a project for deploying software, training users and ironing out final bugs • RUP is not a process – it is a process framework • Provides vocabulary and loose structure for discussing processes • First step in using RUP is to choose a development case which is a process to use • This process may not be one of the traditional processes • RUP is essentially iterative

18. (Rational) Unified Process (RUP) • Phase 1: Inception • Business case completed • Feasibility studies completed • Decision taken to go ahead with project • Phase 2: Elaboration • Basic architectural decisions made • Outline plan for construction finalised • Major risks identified and understood • High-level user requirements captured • Phase 3: Construction • Consists of a sequence of iterations, each one probably consisting of • Analysis → Design →Implementation → Test → Evaluation • Phase 4: Transition • System introduced to users • Late-stage, non-iterative activities such as deployment, user training

19. Other processes • Object-oriented design (OOD) • Booch, G. (1991). Object-Oriented Design with Applications. Benjamin/Cummings • Object modeling technique (OMT) • Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F. and Lorensen, W. (1991). Object-Oriented Modeling and Design. Prentice-Hall. • Object-oriented software engineering (OOSE) and Objectory • Jacobson, I., Christenson, M., Jonsson, P. and Oevergaard, G. (1992). Object-Oriented Software Engineering: A Use Case Driven Approach. Addison-Wesley. • Catalysis • D'Souza, D. and Wills, A. C. (1998). Catalysis: Objects, Frameworks and Components in UML. Addison-Wesley.

20. Predictive planning • Assumes project is in two stages: • make plans - difficult to predict cost and time of this • execute plans - much more predictable • Generally, project becomes more predictable as it progresses • Requirements analysis is inherently unpredictable • Requirements churn: • changes in requirements at a late stage in a project • Two solutions: • Can freeze requirements early on, but could result in system that doesn't meet users' needs • Can put more effort into requirements analysis early on...but will this help? • Can give a fixed-price/fixed-scope contract • But will probably fail or overrun

21. Adaptive planning • Sees requirements churn as inevitable • Accepts that it is impossible to predict how requirements will change as software is developed • Developing the software changes the requirements as users become more aware of what is possible • Cannot fix scope until confident that requirements won't change • Can have fixed-price/variable-scope contract • Requires users to regularly assess functionality of product so far • Customer may cancel project if too slow • Uses iterative process

22. Agile programming • Defined by the “Agile Programming Manifesto” • www.agilemanifesto.org • Claims that we should 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 • Examples: Extreme programming (XP), Scrum, Feature-driven development (FDD), Crystal, Dynamic systems development method (DSDM)

23. Agile processes • Use adaptive planning, not predictive planning • Are people-oriented • Most important factor is quality of people and working relationships • Use short, time-boxed iterations with frequent customer and user evaluation • Low ceremony, lightweight • i.e., few written reports and control points • Embrace requirements change • Use automated testing • Avoid building in features that are not definitely required

24. Choosing the right process • Depends on • Kind of system • Technology being used • Size and distribution of team • Risks • Consequences of failure • Working style of team • Culture of organisation • Better to start simple and add complexity than start complex and simplify • Iterative development supports frequent process change and evolution

25. Retrospectives • End each iteration with an iteration retrospective • Make list with three categories: • things to keep • problems – things to get rid of • things to try • End project with a project retrospective (www.retrospectives.com) • Learn from your successes and your mistakes

26. Patterns • See • Gamma, E., Helm, R., Johnson, R. and Vlissides, J. (1995). Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley. • Complete example software designs for solving commonly encountered problems • A pattern identifies the common features in a class of good designs and incorporates them into a re-usable pattern • A pattern is a software design on which you may base a new system

27. Summary • Waterfall process and software life-cycle • cannot easily revise decisions • Iterative ("spiral") process - sequence of mini waterfalls • allows risk to be managed effectively • involves frequent user evaluation of working software • uses time-boxing to prioritise requirements and stay on schedule • rework not necessarily bad in software development • Rational Unified Process Inception →Elaboration → Construction → Transition • Predictive and adaptive planning • Agile programming • Retrospectives • Patterns