1 / 9

Why new software methodologies

Why new software methodologies. The classic waterfall-model based techniques are strongly based on the assumption that the requirements are reliable – however, this is sometimes an unrealistic assumption.

varana
Download Presentation

Why new software methodologies

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Why new software methodologies • The classic waterfall-model based techniques are strongly based on the assumption that the requirements are reliable – however, this is sometimes an unrealistic assumption. • The success rates of software projects are still not high enough to suggest that the ”perfect methodology” has been found. • The administration of software development has become heavy -> a need for so-called lightweight methodologies was identified. • The world of software development develops. Software Engineering 2004 Jyrki Nummenmaa

  2. Extreme Programming • Extreme programming is a software methodology, which has a set of simple rules to be followed. • Overall, the methodology emphasizes team work, customer participation and concentration in the essential. • Multiple web sites, see e.g.:http://www.extremeprogramming.org/http://www.xprogramming.com/ • As the web material is quite good, this lecture will largely be based on selective use of it. I will, however, give some lists of items of importance also on these slides. Software Engineering 2004 Jyrki Nummenmaa

  3. XP – teamwork • In XP, the work is arranged to be done in teams, which is to contain also a customer representative – this way, the customer view is always available. • Programming is done in pairs. • Pairs are re-organised when needed. Software Engineering 2004 Jyrki Nummenmaa

  4. User Stories • A little bit like Use Cases, but they should be non-technical, described completely from the users point of view (no GUI specification or such…) • Written by the customers. • Short, just a few sentences. • Used as a basis for implementation. • Used as a basis for release planning. • Used as a basis for testing. • Used as a basis for velocity estimation (1-3 weeks per user story) Software Engineering 2004 Jyrki Nummenmaa

  5. Release planning • Specifies, which user stories are to be implemented in which release. • Specifies when releases should be released. • Will be adjusted based on the estimated velocity of the project. Software Engineering 2004 Jyrki Nummenmaa

  6. Iteration planning • Each iteration is 1-3 weeks long. • For each iteration, the customer chooses the user stories to be implemented. • Rule: Choose more valuable first. (This way, you will focus on the most important parts.) • Also, choose which user stories to fix, if there are some that did not pass their acceptance tests. • Choose such an amount of user stories that based on the velocity estimates, they will be completed within the iteration. Software Engineering 2004 Jyrki Nummenmaa

  7. Task planning • Programming tasks are identified from the user stories and failed tests. • The tasks are written down on index cards. Duplicates are removed. • Developers choose tasks and estimate their duration (1-3 ideal days ie. days without interruption – shorter ones can be grouped and longer ones devided). • After this, it is possible to evaluate how full the iteration is. Software Engineering 2004 Jyrki Nummenmaa

  8. Suitability of XP / 1 • Sometimes (as in Finland with government IT projects), the requirements have to be built first, in fact, the implementation contracts are based on the requirement specifications. • In this kind of a setting, one can not really get the true benefits of XP. • In practice, it has sometimes been found that pair programming is more natural when the project is young or when big decisions are being made. Later there is more routine work and everyone knows what and how – working in pairs is not equally motivating any more. Software Engineering 2004 Jyrki Nummenmaa

  9. Suitability of XP / 2 • Sometimes test automation is really hard to achieve. This damages the basis for using XP. • Sometimes someone wants to use just some principles of XP – this may be a reasonable choice. • XP has been designed for lean development – sometimes this just is not the goal of the project. E.g. if you try to develop a highly general-purpose library for some purpose, XP may not be your choice. • More generally, if you can not identify (or reach) a good enough set of users, XP may not be a good choice. Software Engineering 2004 Jyrki Nummenmaa

More Related