Group two presentation
Download as PPTX, PDF0 likes152 views
This document discusses different project approaches and methodologies. It describes various process models including waterfall, V-model, evolutionary delivery, incremental delivery, agile, DSDM, and extreme programming. It provides pros and cons of each approach. The document also discusses factors to consider when selecting a methodology, such as risk, technology used, and project deliverables. Macro and micro processes are defined, and rules of thumb for selecting between approaches based on uncertainty, complexity, and schedule are outlined.
Group two presentation
- 1. CHAPTER 4 Selection of appropriate project approach
- 2. WHAT IS A PROJECT APPROACH? An approach is a method(s) used to run the project from inception to completion. Often called Methodology. Why use project methodology? To determine how the project is going to run. To define properties of the product
- 3. WHAT METHODOLOGY TO USE? This is determined by the following factors Risk – clear requirements New technology – need to do skills transfer or research project deliverables Application type How simple is the application being built Is it accessible in all platforms In Software houses the client might be the one to determine.
- 4. TYPES OF PROCESS MODELS Waterfall ‘one-shot’ ,’once through’ Pros – ‘classical’ this mean this is a traditional model, tried and tested Gives a project structure Cannot progress till each stage is completed and signed off Cons – once stage is signed off not iterations might be done A V-process model is a kind of waterfall One side is verified against the other
- 5. TYPES OF PROCESS MODELS(CONT…) Evolutionary delivery : Prototyping – Quick , live models to test requirements and assumptions Types ‘throw away’ – proof of concept ‘ evolutionary – extend functionality Reasons Reduce cost of maintenance Improve communication Learn by doing Dangers – user confusion in role of product Expense UI changes Categories – sensitizing uses of product With small toys, little functionality
- 6. TYPES OF PROCESS MODELS(CONT…) Incremental delivery – ‘eat a cow’ Outline plan Steps – 1-5% of total, 1-3 months to produce benefit to customer Include manual steps Step dependency Benefits Benefits earlier Project might be put aside without affecting other deliverables Reduces ‘gold plating’ – polishing product over and above requirements o Disadvantages – o no economies of scale – cost of producing one product against mass production o Which step – pre-requisites, no preferred order, value to cost
- 7. TYPES OF PROCESS MODELS(CONT…) Agile – type of structure development methods Benefits can sometimes be seen as disadvantages Large unreadable documentation Updating documents time consuming Communication points increase No user involvement No delivery due to long lead times ‘You want all these benefits then ‘Agile’ is your answer’
- 8. TYPES OF PROCESS MODELS(CONT…) Dynamic System Development Method – DSDM is project management method Time-boxing – fixed schedule , fixed team. 2 -6 weeks MOSCOW priorities – have(s) Must, should, could, want. Nine core DSDM principles
- 9. TYPES OF PROCESS MODELS(CONT…) Extreme programming – Agile Process Stress customer satisfaction - customer can change solution at any point. Meet current needs only – deliver what is needed as it is needed. Test cases before design – give feedback by testing from inception and after each increment test cases are consolidated. Team work is emphasized
- 10. MACRO AND MICRO PROCESSES Macro – break huge project into phases Micro – have repeating steps in each phase. E.g. requirements gathering, testing, implementation then move to another phase
- 11. RULE OF THUMB – WHICH APPROACH? If high uncertainty – evolutionary If high complexity and low uncertainty – incremental If low complexity and low uncertainty – waterfall If tight schedule – evolutionary or incremental Can use combination of approaches one for installation and one for construction.
- 12. GRADY BOOCH’S CONCERN Is concerned with requirement driven projects in that. Conceptual integrity suffers because requirements might be vague and not give motivation to deal with software quality. Scalability Extensibility Portability Or reusability