1 / 17

Method/Process = step-by-step description of the steps involved in doing a particular job

methodology or process?. Method/Process = step-by-step description of the steps involved in doing a particular job No two projects are ever identical, so method is specific to one project

ramiror
Download Presentation

Method/Process = step-by-step description of the steps involved in doing a particular job

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. methodology or process? • Method/Process = step-by-step description of the steps involved in doing a particular job • No two projects are ever identical, so method is specific to one project • Methodology = set of general principles that guide the choice of a method suited to a specific task or project

  2. Level of abstraction Example of application Typical product Task Developing a first-cut class diagram Specific version of a class diagram Technique Description of how to carry out a technique, e.g. UML class modelling Any UML class diagram Method/Process Specific techniques used on a particular project that lead to a specific software product A product costing system Methodology General selection and sequence of techniques capable of producing a range of software products A range of business software applications method/process vs methodology

  3. typical participatory design lifecycle

  4. elements of a methodology Technique: the UML class diagram Tool: Rational Rose (CASE software) Procedure: Find classes by inspecting use case descriptions Structure: Operation specifications should not be written until class model is stable (also the stages) Stages: Inception, Elaboration, Construction… Activities: Requirements, Analysis, Design… Philosophy: OO development promotes software which is robust and resilient to change

  5. Unified Software Development Process (USDP) Public domain methodology for Object-Oriented software development Main principles: Use-case driven Architecture-centric Iterative development Incremental development

  6. Unified Software Development Process (USDP) http://en.wikipedia.org/wiki/Unified_Software_Development_Process

  7. Unified Software Development Process (USDP) Agile Unified Process (AUP), a lightweight variation developed by Scott W. Ambler Basic Unified Process (BUP), a lightweight variation developed by IBM and a precursor to OpenUP Enterprise Unified Process (EUP), an extension of the Rational Unified Process Essential Unified Process (EssUP), a lightweight variation developed by Ivar Jacobson Open Unified Process (OpenUP), the Eclipse Process Framework software development process Rational Unified Process (RUP), the IBM / Rational Software development process Oracle Unified Method (OUM), the Oracle development and implementation process Rational Unified Process-System Engineering (RUP-SE), a version of RUP tailored by Rational Software for System Engineering

  8. Dynamic Systems Development Method(DSDM) = a management and control framework for Rapid Application Development Prototyping DSDM fixes resources for the project, fixes the time available and then sets out to deliver only what can be achieved within these constraints The DSDM life cycle has these phases: feasibility study business study functional model iteration (using prototypes) design and build iteration (continue with prototypes) implementation

  9. Dynamic Systems Development Method (DSDM) http://en.wikipedia.org/wiki/DSDM

  10. DSDM is based upon 9 underlying principles • Active user involvement is imperative. • DSDM teams are empowered to make decisions including refining or changing requirements without the direct involvement of higher management. • The focus is on frequent product delivery. A team delivers product(s) within a timebox (2 – 6 weeks) and adopts the most appropriate approach. • Fitness for purpose is the key criterion. DSDM is geared to delivering essential functionality at the specified time. • Iterative and incremental development is necessary to converge on an accurate business solution. Incremental development allows user feedback to inform later development.

  11. DSDM is based upon 9 underlying principles • All changes during development are reversible. This allows inappropriate iterations to be undone. • Requirements are initially agreed at a high level. These provide objectives for prototyping and can be investigated by the teams. Normally the scope of the high level requirements are not changed significantly. • Testing is integrated throughout the life cycle — this is essential with an incremental approach. Developers test for technical compliance, user team members for functional compliance. • A collaborative and co-operative approach between all stakeholders is essential. Includes resource managers and quality assurance teams.

  12. Principles of Extreme Programming (XP) Communication - XP highlights the importance of good communication among developers and between developers and users. Simplicity - XP focuses on the simplest solution for the immediate known requirements. Feedback - Feedback in XP is geared to giving the developers frequent and timely feedback from users and also in terms of test results. Work estimates are based on the work actually completed in the previous iteration. Courage - Urges the developer to throw away code that is not quite correct and start again. Essentially the developer has to leave unproductive lines of development despite personal investment in the ideas.

  13. Principles of Extreme Programming (XP) Based on user stories that describe the requirements • written by the user • the basis of project planning and the development of test harnesses Very similar to use cases though some proponents of XP suggest that there are key differences in granularity • typical user story is about three sentences with no technology indicated • developers get detailed descriptions from the customer when they start developing Best suited to projects with a relatively small number of programmers—say no more than ten Critical to maintain clear communicative code and to have rapid feedback (If these are not possible then XP would be problematic) XP not sympathetic to using UML for analysis & design

  14. XP Activities The planning game involves quickly defining the scope of the next release from user priorities and technical estimates. The plan is updated regularly as the iteration progresses. The information system should be delivered in small releases that incrementally build up functionality through rapid iteration. A unifying metaphor or high level shared story focuses the development. The system should be based on a simple design. Programmers prepare unit tests in advance of software construction and customers define acceptance tests. The programme code should be restructured to remove duplication, simplify the code and improve flexibility (refactoring).

  15. XP Activities Pair programming means that code is written by two programmers using one workstation. The code is owned collectively and anyone can change any code. The system is integrated and built frequently each day. This gives the opportunity for regular testing and feedback. Normally staff should work no more than forty hours a week. A user should be a full-time member of the team. All programmers should write code according to agreed standards that emphasise good communication through the code.

More Related